Executive summary
Risk in English. Severity mix. What to tell the board this month versus next quarter.
BoardRisk
Coverage
What we will not put on the PDF
Technical volume
Each finding: CVSS v3.1, affected asset, steps, evidence, fix, references.
CVSSPoC
Control mapping
OWASP, ISO/IEC 27001 Annex A, NCSC CAF objectives — applied where they are honest, omitted where they are not.
CAFISO 27001
Re-test & attestation
Free verification of confirmed issues. Optional letter stating independent VAPT was performed, with dates and scope.
Re-testAttestation
No CREST logo. No fake CHECK number. If a tender requires CREST or NCSC CHECK, say so on the scoping call and we will tell you we are not the supplier.
Why it matters
The deliverable is the product
Most pentest reports fail their readers
A tool export with 300 informational findings, no exploitability assessment and a severity column copied from a CVSS calculator does not help anybody. Your board cannot act on it, your developers do not trust it, and your customer’s procurement team cannot accept it. The test is the work; the report is what you actually bought.
Three readers, one document
A director needs to know the business exposure and the cost of fixing it. A developer needs the exact request and the specific line to change. An auditor needs traceability from finding to control to verification date. We write for all three in one document rather than producing something that satisfies none of them.
Severity that means something
CVSS v3.1 as a baseline, then adjusted for your context and stated plainly: an authenticated-only finding in an internal tool is not the same risk as the same bug on a public sign-up flow. We show the vector, and we explain any adjustment rather than quietly inflating a score.
Honest mapping, or none
Findings map to ISO 27001 Annex A, NCSC CAF outcomes, OWASP and PCI DSS where the mapping genuinely holds. Where a finding evidences nothing in a framework, the report says so. Padded mappings get noticed by good auditors and cost you credibility at exactly the wrong moment.
This engagement is available two ways: as the reporting stage of any test we run, or as a standalone service that takes findings you already have — from another supplier, a bug bounty programme, or your own team — and turns them into a document that survives scrutiny.
How it runs
The engagement, step by step
Intake
Either the findings from an engagement we ran, or your existing material: another supplier’s report, bug bounty submissions, scanner output, internal tickets. We start by working out what is actually true.
Validation
Every finding we did not produce ourselves is re-checked. Unreproducible findings are marked as such rather than passed along. False positives are removed, and we say how many there were.
Severity and context
CVSS v3.1 vectors, then contextual adjustment against your architecture, exposure and data. Every adjustment is stated and justified in the finding itself.
Control mapping
Against ISO 27001 Annex A, NCSC CAF, OWASP ASVS or API Top 10, and PCI DSS where relevant, with explicit gaps where no honest mapping exists.
Writing
Executive summary, technical findings, remediation plan sequenced by effort against risk, and an appendix with the raw evidence. Plain English throughout, British spelling, no filler.
Walkthrough and re-test
A call with your engineers to work through the findings, then a re-test of what you have fixed and a statement of what is now closed.
Deliverables
What lands on your desk
Executive summary
Two pages a non-technical director reads once and understands: scope, exposure in business terms, remediation cost, and a clear statement of whether we would sign this off.
Technical findings
Severity with CVSS vector, affected components, reproduction steps, evidence, impact and specific remediation. Written so a developer never has to email us to understand a finding.
Remediation plan
Sequenced by risk reduced per unit of effort, not by severity label. The first three items are usually where most of the real exposure goes, and saying so is more useful than a flat list.
Attestation letter
A one-page letter naming scope, dates, tester and outcome, suitable for a customer, an insurer or a procurement portal — the document most people are actually chasing when they ask for the report.
Scoping
What we need from you to start
- The findings you already have, in whatever form they exist — a PDF, a spreadsheet, a bug tracker export, or raw scanner output.
- Enough environment access to revalidate them, or an honest statement that revalidation is not possible.
- Your architecture context: what is internet-facing, what holds personal data, who the users are.
- The frameworks you are being assessed against, and by whom.
- Who the report is for — a board, a customer, an auditor, an insurer — because it changes the emphasis, though never the facts.
- Any prior report, so remediation progress can be shown over time rather than presented as a fresh start.
Where findings cannot be revalidated, they are included and clearly marked as carried forward and unverified. We will not restate somebody else’s unverified claim as though we had proven it.
UK compliance
Where this sits in a UK compliance programme
ISO/IEC 27001
The report is structured for an audit: finding, control, remediation, verification date. Your auditor can follow the thread without a meeting, which is usually the difference between a smooth surveillance visit and a long one.
UK GDPR, Article 32
Documented testing with a documented re-test is the evidence Article 32 expects. The attestation letter is what you send when a customer’s DPO asks whether you test.
NCSC CAF
Findings map to CAF outcomes for organisations in scope of NIS regulations or working with the public sector, with explicit gaps where a test cannot evidence an outcome.
PCI DSS v4
Where card data is involved, the report is written to the evidence expectations of Requirement 11.4, including scope statement, methodology and re-test.
Questions
What UK buyers ask before signing
Yes, and it is a fair amount of what this service is. We revalidate what we can, remove false positives, re-score against your actual context and rewrite for the audience. Anything that cannot be revalidated is carried forward and clearly marked as unverified rather than quietly restated as fact.
A one-page letter stating that an independent penetration test was carried out, by whom, over what scope, on what dates, and what the outcome was. It is what most enterprise procurement teams actually want when they ask to see your pentest report, and it lets you share evidence without handing over a document full of your own vulnerabilities.
Yes. If you have findings from elsewhere and need independent verification that they are fixed, we can re-test and issue a closure statement without redoing the original engagement.
A draft within two to three working days of the testing window closing, then a walkthrough call, then the final document. Genuinely critical findings are not held for the report — you hear about those the day we confirm them.
That is the point of the executive summary: exposure in business terms, what it costs to fix, and a plain statement of whether we would sign it off. If a director cannot make a decision from the first two pages, the report has failed and we would rather rewrite it.
Related
Engagements that usually run alongside
01
02
03
Web application VAPT
Authorisation, session, injection and business logic in the applications your UK customers log into.
02
Network penetration testing
External perimeter and internal Active Directory, from first foothold to domain impact.
03
Cloud security VAPT
IAM, storage, network boundaries and the CI/CD path into your AWS, Azure or GCP estate.
Ready to scope a UK engagement?
A thirty-minute call. Assets, timeline, a quote in pounds sterling.
Request a quote