Approach
How an engagement runs.
Clear scope, controlled testing, evidence your team can use. The process is deliberately boring, so the findings can be taken seriously.
Principles
The standard does not change with the size of the engagement.
The same four commitments apply to a two-day API review and a multi-week red team operation.
Manual first
Scanners find patterns. The work is following the paths they miss: chained access, business logic and the assumptions between systems.
Scope you can audit
Written scope, named targets, clear exclusions and a single point of contact, agreed before a packet is sent.
Evidence over noise
Every finding includes reproduction steps, realistic impact and a remediation path your team can implement.
No theatre
No inflated severity, no copy-pasted scanner output, no finding that disappears when you ask for a reproduction.
Lifecycle
Four phases, no hand-offs.
The same person scopes the work, performs the testing and writes the report.
Scope
We agree what is in scope, what is off-limits, how we communicate and what a successful engagement looks like.
Test
Manual, exploit-led testing with controlled risk, clear check-ins and an emergency contact available throughout.
Report
Prioritised findings with evidence, business impact and a specific fix your engineers can act on.
Retest
You fix. I verify. A finding is only closed when the remediation has been confirmed.
What is agreed before testing starts.
- Written scope with named targets and explicit exclusions.
- A named emergency contact on both sides.
- Testing window, check-in cadence and communication channels.
- Stop conditions and the process for handling unexpected impact.
- Data-handling, evidence-retention and deletion rules.
- Written authorisation for any third-party or cloud-hosted target.
How findings are written.
- Severity with context, not just a CVSS number.
- Affected assets and the prerequisites required to exploit the issue.
- Reproduction steps and evidence that can be verified independently.
- Business impact in plain language for decision-makers.
- Specific remediation and verification guidance for engineers.
- A retest that confirms which findings are actually closed.
Inputs
What I need from you.
A good engagement is a collaboration. These inputs remove ambiguity and make the testing time count.
A technical contact
Someone who knows the systems and can answer questions during the testing window.
Test accounts
Accounts at each relevant role, so access control and business logic can be tested properly.
Architecture context
Diagrams, network ranges or a short walkthrough of how the target is put together.
A clear objective
The decision or risk the engagement is meant to address, not just a list of hosts.
Compliance requirements
Any customer, auditor or regulatory requirements that should shape the report.
Timing and constraints
The testing window, change freezes and any periods that must be avoided.
See how the process fits your team.
Tell me what you need to test and what decision the result should support. I will reply with a practical scope.