Assessment
The testing itself, against a scope and authorisation agreed beforehand. What is in scope is decided at the start, not assumed.
A calm, rigorous way through uncertainty.
Approach
We make security work legible: what we found, why it matters, and what a sensible next step looks like.
How we work
Clear thinking, close collaboration.
Most engagements follow these six steps. The emphasis shifts with the work — an assessment and an advisory engagement do not run identically — but nothing is tested before scope and rules of engagement are agreed in writing.
We learn your environment, objectives and constraints, and propose a scope that fits them.
Consultation & scoping
- Understand the systems, users and data involved
- Agree objectives and the questions the work should answer
- Identify constraints: environments, timing, sensitivities
OutputA proposed scope and approach
Scope, rules of engagement and testing windows are agreed in writing before any testing starts.
Written authorisation
- Confirm the systems in scope and those explicitly out of it
- Agree rules of engagement and testing windows
- Name points of contact on both sides
OutputWritten authorisation and agreed rules of engagement
We test the agreed attack surface with a structured methodology and record evidence as we go.
Assessment & evidence
- Test only the agreed attack surface
- Work through authentication, authorisation, business logic and input handling
- Record reproducible evidence for every candidate finding
OutputEvidence for each candidate finding
Each finding is confirmed, then ranked by how exploitable it is and what it would affect.
Validation & prioritisation
- Confirm each finding is real and reachable
- Determine practical exploitability and what it would expose
- Rank by risk, not by the order findings were found
OutputA validated, prioritised list of findings
You receive an executive summary, technical findings and remediation guidance your engineers can act on.
Reporting & remediation
- Executive summary for leadership
- Technical findings with evidence and severity
- Remediation guidance written for the engineers who will fix it
OutputThe assessment report
Where the engagement includes it, we verify that identified issues have been addressed.
Retest & closure
- Re-test previously identified findings
- Confirm which are resolved and which remain open
- Retesting verifies fixes; it is not a new assessment
OutputUpdated finding status
What each stage produces
Findings, recommendations and fixes are not the same thing.
Being explicit about where our work ends and yours begins avoids the most common misunderstanding in security engagements.
Findings
What was actually found, with the technical evidence behind it and the impact it creates. A finding is only reported once it has been validated.
Recommendations
What we would change, prioritised and written for the engineers who will act on it — not a list of generic controls.
Implementation
Carried out by your team. O&D Cyber implements changes only where a service explicitly covers hands-on work and it has been scoped and authorised.
Retesting
Verifying that previously identified findings have been remediated. Performed where the engagement includes it, and not a fresh assessment.
What this looks like in practice: an example finding, an attack path, and a sample report. The principles behind the work are on About.
Start with scope
Tell us what you need assessed.
Describe the system, the requirement, or the uncertainty you want examined. We'll review the context and come back with a proposed scope before any work starts.