The principle
A penetration test is only as valuable as the depth behind it. Automated tooling sends known payloads at known patterns; it cannot authenticate as two different users and compare what each can reach, and it has no model of what your application is supposed to enforce. The vulnerability classes that compromise businesses: broken access control, business logic flaws, privilege escalation, chained exploits: are deviations from intent, and intent has to be understood before it can be violated.
So the work starts with a feature map, not a vulnerability map. Roles, plans, tenancies, invitation flows, billing states, admin surfaces and feature flags are mapped first. Only once the state machine is understood does testing begin, and it targets the transitions between states, which is where the expensive findings live.
Tooling contributes coverage. It never contributes findings. Engagement standard
Five phases
Scoping and threat modelling
Map the asset, the attacker profile, and what “compromised” actually means for this business. Rules of engagement, testing windows, excluded techniques and an escalation contact are agreed in writing before anything is sent.
Reconnaissance and surface mapping
Enumerate everything reachable: subdomains from multiple passive sources, every endpoint referenced in JavaScript bundles, exposed services, third-party integrations, and the assets nobody remembers deploying. Coverage is recorded per host, so what was not tested is as visible as what was.
Manual exploitation
Authenticated testing from every role, with at least two accounts per role. Business logic, authorisation boundaries, injection, race conditions and state transitions, with each candidate reproduced live before it is written down. Automated tooling contributes coverage; it never contributes findings.
Verification and impact
Every finding is reproduced in a fresh session, isolated to the single parameter that causes it, and pushed to its maximum realistic impact. A finding that cannot survive a clean-room reproduction does not appear in the report.
Reporting and retest
The report is written twice over: once for the engineer who has to fix it, once for the auditor who has to file it. A walkthrough session follows, then a retest of every finding, closed only when re-exploitation fails.
The coverage rule
Testing apex domains only is the most common cause of missed findings in this industry. Every live host discovered during reconnaissance is tested against the full vulnerability class list, not sampled, and coverage is tracked per host, per class, so the report can state what was tested and what was not.
That distinction matters more than it sounds. A report that lists ten findings tells you what was found. A report that also shows forty-one classes checked against every host tells you what the absence of a finding means.
Coverage commitments
- Subdomain discovery
- Minimum seven independent passive sources, merged and de-duplicated
- Host probing
- Every discovered host probed and classified, including 4xx and 5xx responses
- Client-side analysis
- Every JavaScript bundle pulled and analysed for endpoints, secrets and role logic
- Authenticated coverage
- Every role, with bundles re-pulled per role and diffed for hidden surfaces
- Per-host tracking
- Vulnerability classes tracked per host, so gaps are visible rather than implied
- Evidence retention
- Raw tool output retained and available on request for the engagement’s duration
The false-positive gate
Every medium-severity finding and above passes eight checks before it is written into a report. A finding that fails any one of them is investigated further or dropped. It is never reported with a hedge.
This is the difference between a report your engineers act on and a report they learn to discount. The first false positive costs you an afternoon; the third costs the report its credibility.
| Check | Pass condition |
|---|---|
| Fresh reproduction | Reproduced from a clean session with no prior state |
| Second account | Impact confirmed from the victim account’s own session, not inferred |
| Parameter isolation | Only the suspect parameter changes; everything else held constant |
| Manual verification | Any tool output confirmed by hand before it is written down |
| Environment noise | Consistent across at least three attempts; timing findings timed three times |
| Real impact | Actual data read, actual action performed, or actual session obtained |
| Not a proxy artefact | Response confirmed to come from the application, not a WAF or cache |
| Not a duplicate | Checked against previously reported findings for the same asset |
Standards and references
Engagements follow established public methodology rather than a proprietary black box, which is both better practice and a requirement of frameworks such as PCI DSS 11.4.1.
- PTES, Penetration Testing Execution Standard, for overall engagement structure
- OWASP WSTG, Web Security Testing Guide, for web application coverage
- OWASP API Security Top 10, for API engagements
- OWASP MASVS and MASTG, for mobile applications
- OWASP ASVS, as the verification standard findings are mapped against
- NIST SP 800-115, technical guide to information security testing
- CIS Benchmarks, for cloud and infrastructure configuration review
- MITRE ATT&CK, for describing post-compromise behaviour
Reporting
Every report is written for two readers who need different things from the same finding. The engineer needs the request, the response, the reproduction steps and the specific fix for their framework. The auditor needs scope, methodology, severity, control mapping and evidence of closure. Trying to serve both in one voice fails both.
Executive summary
One page for the people who approve budget: what was tested, what was found, what it means in business terms.
Technical findings
Each finding with severity, CVSS, affected component, full request and response, reproduction steps and a working proof of concept.
Attack chains
Where findings combine, the chain is written out end to end, from first request to demonstrated impact.
Remediation guidance
A specific fix for your stack and framework, with the corrected pattern, not a link to a generic reference page.
Audit mapping
Findings mapped to SOC 2, ISO 27001, PCI DSS, HIPAA and OWASP ASVS as applicable, so the report drops straight into an audit pack.
Retest and attestation
Every finding retested in a clean session after remediation, with a signed attestation letter for customers and auditors.
Questions
How long does a penetration test take?
Five to fifteen working days for a typical web application and API engagement, plus two to three days for reporting. Network engagements scale with host count; mobile adds roughly five days per platform. Add one to two weeks of lead time from signed scope to start, and allow for a retest two to four weeks after delivery once fixes are in.
What do you need from us to start a penetration test?
A defined scope and written authorisation, test accounts (at least two per role, and two tenants if the product is multi-tenant), a staging environment where possible, and a technical contact for questions. API documentation, architecture notes and source access all help but are not required.
Will penetration testing break our systems?
Denial-of-service and resource-exhaustion techniques are excluded by default. Exploits with known stability risk are flagged during scoping and run only with approval at an agreed time. Every request sent is logged, so any anomaly can be traced to the exact payload that caused it. Destructive actions against existing data are never performed without written approval.
What happens if you find something critical mid-test?
You are told the same day, by the escalation contact agreed at scoping, with enough detail to act rather than waiting for the report. Critical findings that expose customer data or allow account takeover are not held back for a scheduled delivery date.
Is a retest included?
Yes. Every finding is retested in a clean session after remediation and closes only when re-exploitation fails. A signed attestation follows, recording what was raised, what was fixed and what was verified. Retesting is part of the engagement, not a separate line item.
Can you run a penetration test on production systems?
Yes, with agreed rate limits, testing windows and a documented rollback path. A staging environment mirroring production is preferred, same authentication stack, comparable data volumes. Production testing is routine for read-heavy surfaces and handled more carefully where write operations are in scope.
What is included in a penetration test report?
Three documents. A technical report for your engineers with every finding, its severity, the full request and response, reproduction steps and a working proof of concept. An auditor-facing summary with scope, methodology, dates and outcomes. A redacted attestation letter with no exploitation detail, written to be shared with customers under NDA. Findings are mapped to whichever framework you agreed at scoping.
How do we prepare for a penetration test?
Provision the accounts first: at least two per role, and two tenants if your product is multi-tenant, because a single account cannot demonstrate a boundary between two. Then confirm the scope in writing, name an escalation contact, and tell us about anything fragile. Account provisioning is the most common reason an engagement starts late, so it is worth doing before the kickoff call.
Is penetration testing legal?
Yes, when it is authorised in writing by a party entitled to grant that authorisation. Unauthorised access is a criminal matter in every market we work in, which is why every engagement runs under a signed letter naming the systems, the testing windows and the techniques excluded. Where you are not the asset owner, we require the owner's written authorisation before active testing begins.
What happens after the penetration test?
You get the report and a readout session with the people who did the testing, then you remediate, then every finding is retested in a clean session and closed only when re-exploitation fails. A signed attestation follows, recording what was raised, what was fixed and what was verified. That attestation is usually the document your auditor or enterprise buyer actually wants.