Our penetration testing process
A tester leads every step, from the agreed scope to the retest. AI speeds up recon, triage and reporting, and a person reviews every finding before it reaches you.
- POST /api/checkoutThe tester's call: FindingHigh, in your report.
- GET /search?q=The tester's call: No finding
- OPTIONS /api/*The tester's call: No finding
What does the report contain?
Each finding carries its proof, its business risk and a fix, and leadership receives an executive briefing. The sample shows each part as it reads.
A plain-language report
Written for the engineers who fix and the leaders who fund the fix.
An executive briefing
What to fix first, written for leadership. Included with every test.
The business risk, ranked
Who could exploit it, how easily, and what they would reach.
Proof of exploit
The exact request and response, so your team can replay it.
A fix for each finding
Written for the engineer who makes the change.
Summary for leadership
Fix the checkout price first.
Findings
- Customers can change the price at checkoutHigh
- Who
- Any signed-in customer
- Effort
- Edit one field
- Reach
- Every order you take
- Sessions stay valid after sign-outMedium
Request
POST /api/checkout HTTP/2
Cookie: session=<customer>
{
"cart": "c_2291",
"total": 0.01
}Response
HTTP/2 201 Created{ "order": "o_7731", "charged": 0.01}Fix plan
- Fix firstPrice every order on the serverHigh
- Fix nextEnd sessions on sign-outMedium
From agreed scope to retest, in five steps
Testing starts once we agree the scope with you in writing. Each step names who does the work, your part and what you receive.
The scope
- target
- portal.acme-corp.com
- out of scope
- the payment provider
Test accounts
- accounts
- for each role in scope
Testing windows
- environment
- live, by default
- windows
- agreed with you
- limits
- no destructive actions
Sign-off and a contact
- sign-off
- in writing
- contact
- one named person
Testing starts once you agree it.
Recon
We map the hosts, routes and roles in scope and use the product as each kind of user. AI sorts the surface, and the tester picks the leads.
- Who does it
- A tester, with AI sorting the surface
- Your part
- Confirm each test account signs in
- What you get
- Nothing to act on yet
Exploit
The tester works each lead by hand. They replay requests as another role, probe authorisation and business logic, and chain small flaws into one attack path.
- Who does it
- A tester, by hand
- Your part
- Stay reachable through your named contact
- What you get
- Testing inside your windows, with no destructive actions
Prove
A lead becomes a finding only when a working exploit shows what it reaches. The tester follows it to the data or action at risk and records each step.
- Who does it
- A tester
- Your part
- Nothing, unless we ask to check a result
- What you get
- Proof of exploit for every finding
Report
Each finding is written up with its proof, the business risk in plain language and a fix. Findings run most serious first, rated Critical, High, Medium or Low.
- Who does it
- A tester, with AI speeding up the write-up
- Your part
- Read the findings and plan the fixes
- What you get
- The report and an executive briefing
Retest
Once your fixes are live, a tester reruns the exploit behind each reported finding. The retest record shows whether each fix holds.
- Who does it
- A tester
- Your part
- Tell us when the fixes are live
- What you get
- One retest, within 30 days of the report
After the report: fix, then retest
Your engineers fix from the proof in the report. At the retest we rerun the original request, so the record shows the response before and after the fix.
The retest sent the request that proved the finding. The order is now refused.
In the report
HTTP/2 201 Created"charged": 0.01At the retest
HTTP/2 422"error": "price_mismatch"Fixed, verified
Preparing for a penetration test
We need four things before testing starts. The checklist covers the jobs on your side that keep a test of live systems on plan.
What we need from you
- The scopeThe systems to test, and anything to leave alone.
- Test accountsAccounts for each role we test as.
- Testing windowsWhen we may test your live systems.
- Sign-off and a contactWritten approval, and one named contact on your side.
Before testing starts
- Tell your on-call and security teams the windows, so alerts are expected.
- Sign in with each test account and confirm it sees what that role should.
- Tell us about any release planned during the testing windows.
- Send API specs, diagrams or an earlier report if you have them.
- Decide who on your side reads the report and the briefing.
- Set engineering time aside for fixes, so the retest can follow.
Scope, safety and method
Do you test live systems?
Yes, by default. We test inside windows agreed with you, with a named contact on your side and no destructive actions.
What happens to leads that do not hold up?
They are closed and left out. Only findings proved with a working exploit reach your report.
Who does the testing?
Testers with blue team, red team and penetration testing experience. AI never decides what counts as a finding; a tester does.
Is a retest included?
Yes. Every test includes one retest of the findings we reported, within 30 days of the report.
Do you tell us how to fix each finding?
Yes. Each finding includes a fix written for the engineer who makes the change, and the retest checks that it holds.
How does continuous testing fit our releases?
Continuous testing runs a full test each quarter, with checks between rounds on request as you ship. Each round brings its own report, briefing and retest.
Which standards is your testing aligned with?
OWASP Top 10, OWASP ASVS, NIST SP 800-115, CWE Top 25 and MITRE ATT&CK. Our testing is aligned with them. None of them certifies us, and we never claim one does.
How is a test priced?
On its scope, after a scoping conversation. We publish no list prices. Tell us what you run and we reply within one business day.