Authorization comes first
No testing starts without a written authorization signed by someone with authority over the systems. It is a short document, and every line in it gets used during the engagement:
- Assets in scope, listed one by one: each domain, subdomain and IP address. No wildcards and no "related systems".
- Exclusions: hosts, paths or functions that must not be touched.
- Testing window: start and end dates, and permitted hours where the client needs them.
- Permitted and prohibited activity: denial of service, destructive actions and social engineering are out unless they are contracted separately.
- Contacts on both sides for stopping the test and for escalating a critical finding.
A signature does not prove control. Before the window opens we check each listed asset against registration data, DNS records and the network that hosts its IP address. Shared hosting, CDNs and third-party SaaS are the usual problem: the client uses the service but does not own the machine. Those assets are tested only as far as the provider's policy allows, or they come out of scope. Anything that fails the ownership check goes back to the client before testing starts.
Passive reconnaissance
The first phase uses public sources only, with no traffic sent to the client's systems: DNS records, certificate transparency logs, public subdomain datasets, search engine indexes, public code repositories and exposed email addresses.
The output is an inventory of what the organisation exposes to the internet, compared line by line with the signed scope. The comparison usually cuts both ways. We find hosts the client did not list, and listed hosts that turn out to belong to a provider. Unlisted hosts are reported as discovered and stay untested until the client amends the scope in writing.
Active enumeration, in order
Active work runs inside the agreed window and in a fixed order. Each step limits a specific risk.
| Step | What we do | Risk it controls |
|---|---|---|
| 1. Target confirmation | Resolve every in-scope name again and compare the addresses with the signed scope | DNS changed since signing and now points at a third party |
| 2. Service identification | Rate-limited port and service detection | Disruption of fragile hosts; unknown services reaching later steps unexamined |
| 3. Web fingerprinting | Identify the technology stack and any WAF or CDN in front of it | Reading a filter's responses as the application's; getting blocked mid-test and losing coverage |
| 4. Content and subdomain discovery | Throttled enumeration of paths and hostnames | Load on the application; wildcard DNS leading to hosts outside scope |
| 5. Known-vulnerability checks | Template-based checks, non-destructive ones only | Checks that change data or state on a production system |
| 6. TLS and header review | Certificate, protocol and security header configuration | Low risk; completes the configuration baseline |
Anything a step turns up is checked against the scope again before the next step uses it.
Validation: scanner output is a lead
Automated tools report candidates. A version banner that matches a vulnerable release is the most common false positive, because vendors backport fixes without changing the version string.
Each candidate is reproduced by hand before it is called a finding. We take the smallest action that proves the issue exists and stop there: one record to show data exposure, never a full extraction. For each confirmed finding we keep the request, the response and the timestamp, so the client can match it to their own logs.
What we cannot confirm is listed separately as unconfirmed, with the reason. It does not get a severity rating.
Reporting and retest
Critical findings do not wait for the report. They go to the agreed contact the day they are confirmed, with enough detail to act on.
The report has an executive summary for the people who decide on budget, and one entry per finding for the people who fix it: affected asset, evidence, severity with its reasoning, and remediation steps. It describes what was found. It is not an inventory of tools.
After the client applies fixes, we repeat the exact validation for each finding and mark it closed or still open. An engagement ends when every finding has one of those two states.
Where AI assistance fits
We use AI assistance for the parts of the work that are volume, not judgment: sorting and correlating reconnaissance output, suggesting which leads to check first, and drafting report text from validated evidence.
The rule is the one that applies to every tester: nothing runs against a system the signed scope does not cover. The model works inside the same scope and window as the analyst, a person decides what gets run against a target, and no finding reaches a report without manual validation. AI makes the process faster. It does not change who is accountable for it.