We show our work. Here is what that means.
The question
The usual way
With us
When do I see the first finding?
Week six, with the report
Day one, as soon as it is confirmed
When can my team start fixing?
After the engagement has closed
Week one, while testing continues
What does a retest cost?
A second engagement
Included, on request
When can I get the report?
When it is written, at the end
Any time, in the format you need
The anatomy of a finding
This is one finding.
Not a report - one finding, exactly as it appears in the platform. Every field it carries, and why each one is there. Yours will look like this.

What each field is for.
- Title
- what it is, in your engineers’ words
- Affected asset
- the specific endpoint of the application
- Severity
- computed from the vector, never chosen by hand
- Evidence
- the request, the response and screenshots, attached to the finding
- Request
- the raw exchange, so your engineer can reproduce it
- Response
- what came back, unedited except for a client’s data
- Impact
- what it costs you, not what the CVE says
- Remediation
- for your stack, not “apply vendor patches”
- Retest
- a tester’s verdict, not your self-assessment
This is the format, not a client’s work - it is written against the demonstration environment we run for the purpose, and a real finding also carries screenshots of the issue alongside the request and response. We don’t publish client findings, redacted or otherwise. If you want to see a real one, email us and we’ll send a redacted sample.
Methodology
What we test against
Named with versions, so the coverage claim is something you can check rather than something you have to take on trust.
- OWASP WSTG v4.2
- Web application testing - the 11 categories, from configuration through to client-side.
- OWASP ASVS
- Verification depth: what "tested" means for a given control, at a stated level.
- OWASP API Security Top 10 (2023)
- Authorisation, object-level access and the flaws that only exist in APIs.
- OWASP MASVS
- Mobile, from the binary through to the backend it talks to.
- PTES
- The shape of the engagement itself - intelligence, modelling, exploitation, reporting.
- NIST SP 800-115
- The technical assessment framework auditors most often recognise by name.
Tooling and people
Where a scanner stops.
We run tooling for coverage. Then a person exploits what it found, chains it with what it missed, and confirms every finding by hand before it reaches you.
Scanner
Finds what is there
- Open ports and services
- Publicly known vulnerabilities (CVEs)
- Default passwords
- Weak TLS, missing headers
- Outdated software
Fast, and worth running.
Tester
Finds what is broken
- One customer reading another’s data
- A regular user granting themselves admin
- A password reset that takes over an account
- A price changed in the browser and trusted
- Two safe steps chained into an attack
This is where the real risk is.
Claiming a test is 100% manual would not be true, and you should not believe anyone who says it. What matters is which half does which job.
Rules of engagement
What we will and will not do to your systems
We agree the window before we start
Testing dates, out-of-hours windows if you need them, and the systems that are explicitly out of scope. All of it in writing, signed by someone who can authorise it.
We do not knowingly break your production system
No denial of service, no destructive payloads, no automated exploitation that could corrupt data. Where proving an issue would cause damage, we prove it far enough to be certain and stop there.
You get a contact who can stop the test
A named tester and a number, from the first day to the last. If something looks wrong at two in the morning, you call and it stops.
Your data leaves when the engagement does
Evidence is kept for the retest and the period we agree with you, then destroyed. Findings never appear in another client’s report, and no client work is ever published.
Scoping
What we ask on the scoping call.
All of it, so there is nothing to prepare for and no surprise in the price. Thirty minutes is usually enough.
What is being tested, by URL or by hostname?
Scope is a list of things, not a description. “The production environment” cannot be tested or quoted.
How many distinct user roles are there, and can we have one of each?
Most of what matters is behind a login, and a role we cannot sign into is a role we cannot test.
Is there an API, and is it documented?
An API is usually a larger surface than the interface in front of it, and it is where authorisation flaws live.
Are we testing production, or a staging copy?
It changes what we are allowed to do. A staging copy that differs from production changes what the results mean.
Is anything explicitly out of scope?
Third-party services, a payment provider, a legacy host somebody else owns. Better named now than discovered mid-test.
Who is asking for this, and what will they accept?
An auditor, a customer’s questionnaire or an insurer each want a different format. It decides the report, not the testing.
When does it need to be finished?
A date somebody else set is the most common reason a test is booked, and it decides whether we are the right firm for it.
Who do we call if something goes wrong at 2am?
Testing a production system carries a small risk of disruption. We agree the kill-switch contact before we start, not after.
What you receive
One engagement, exported for whoever is asking
The same testing, rendered for the person who has to read it. Generated on demand rather than quoted as extra work.
Comprehensive
Your engineering team
Every finding at every severity, with full technical detail, evidence and remediation guidance.
Executive summary
Leadership and the board
Risk posture and the findings that matter at that altitude, with informational and low-severity observations excluded.
PCI DSS v4.0
Your QSA
Findings mapped to PCI DSS requirement areas, with the software weakness classes the standard enumerates at 6.2.4.
SOC 2
Your auditor
Findings mapped to the Trust Services Criteria, for the security evidence an examination asks for.
ISO/IEC 27001:2022
Your certification body
Findings mapped to Annex A control areas, supporting the technical testing evidence the standard expects.
HIPAA Security Rule
Your compliance officer
Findings mapped to the Security Rule safeguards, for the evaluation requirement under §164.308.
A penetration test is evidence that may support an assessment. It is not a certification or an attestation, and no report produced here claims to be one. Your assessor decides what satisfies the standard.
We don’t publish client reports. Email us and we’ll send a redacted one
Fair questions
What people ask before booking
Is this an automated scan or a manual penetration test?
Manual. Certified testers work through your application by hand, chaining multi-step issues and abusing business logic - the things a scanner cannot reach. Automated scanning is available inside the platform between engagements, and its results are kept separate from the findings a tester wrote so you always know which is which.
How much does a penetration test cost?
It depends on scope, which is why we quote after a 30-minute call rather than publishing a figure. What drives the number is the number of applications, how many distinct user roles need testing, whether an API and a mobile client are in scope, and whether internal network testing is included. What we can commit to before you speak to us: the price is fixed before work starts, it is priced on scope rather than hours, and if we find more attack surface mid-engagement we tell you rather than invoice you.
How long does an engagement take?
Typically five to ten working days from kickoff to final report. Because findings publish to the platform as they are confirmed, your engineers usually start fixing critical issues within the first two days rather than waiting for the report.
Do you charge extra to retest after we fix something?
No. Retests are included in the engagement. You mark a finding fixed and request a retest from the same screen; a tester verifies it by hand and records whether it passed or failed.
Will the report satisfy our SOC 2 or ISO 27001 auditor?
The platform generates reports mapped to PCI DSS v4.0, SOC 2 Trust Services Criteria, ISO 27001:2022 Annex A and the HIPAA Security Rule, grouping findings under each framework’s own requirement areas. A penetration test is evidence that may support an assessment - it is not a certification, and your assessor decides what satisfies the standard. In practice this is the technical testing evidence those standards ask for.
Where is our data stored, and will you sign a DPA?
The platform and your engagement data are hosted in the United Kingdom, which the European Commission recognises as providing adequate data protection. Findings are visible only to the people on your engagement. Test credentials and raw evidence are purged within 30 days of close; your findings and reports stay in the platform while your account is active so reports can be regenerated and retests requested. For EU and UK clients we act as your data processor and will sign a Data Processing Agreement on the Standard Contractual Clauses on request, at no charge.
Tell us what needs testing.
A sentence is enough. If somebody asked you for this, paste what they sent and we’ll tell you whether a test answers it. Either way you get the scope and what it would cost. No obligation and no sales sequence.