> find /compliance/evidence/ -name 'pentest_report*' -mtime +365 && echo 'still relevant'_
A penetration test engagement concludes on a Friday. The tester's VPN is disconnected. Test accounts are deactivated. Shells are closed. By Monday, the engagement is a memory. By the following month, the tester is deep in another client's environment and couldn't reconstruct your network topology from memory if they tried.
The report, however, is just beginning its journey. Over the next twelve to thirty-six months, it will be reviewed by the internal audit team preparing for ISO 27001 surveillance. It will be submitted to the cyber insurance underwriter during policy renewal. It will be referenced by the compliance manager responding to a client's security questionnaire. It will be disclosed — partially or fully — to a regulator investigating the organisation's security posture. And if a breach occurs, it will be produced as evidence in the investigation, the regulatory notification, the insurance claim, and potentially the litigation.
Most pen test reports are written for the IT team. The IT team reads the report for two months. The regulatory, legal, and insurance audiences read it for years. A report that serves only its immediate technical audience misses the majority of its lifetime value — and may actively harm the organisation if it's poorly structured, vaguely evidenced, or carelessly worded when it enters these secondary contexts.
Regulators and auditors don't read pen test reports the way the IT team does. They're not looking for GPO paths or remediation commands. They're looking for evidence that the organisation takes security seriously: that testing was performed by competent professionals, that findings were identified and risk-rated, that remediation was tracked and completed, and that the testing scope was appropriate for the organisation's risk profile.
| Framework | Pen Test Requirement | What the Report Must Demonstrate |
|---|---|---|
| PCI DSS 4.0 | Requirement 11.4: internal and external pen testing at least annually and after significant changes. Segmentation testing every six months for environments using network segmentation to reduce scope. | Scope covering all in-scope systems and networks. Methodology documented (PTES, OWASP, CREST). Internal and external testing confirmed. Findings with severity ratings. Evidence that critical and high findings were remediated and retested. If segmentation is used, confirmation that segmentation controls were tested and effective. |
| ISO 27001:2022 | Annex A control A.8.8: management of technical vulnerabilities through regular assessment including penetration testing. Clause 9.1: monitoring, measurement, analysis, and evaluation of the ISMS. | Evidence that pen testing is part of the organisation's vulnerability management process. Findings integrated into the risk treatment plan. Remediation tracked through the ISMS corrective action process. Testing frequency appropriate to the organisation's risk profile. |
| UK GDPR / Data Protection Act 2018 | Article 32: appropriate technical and organisational measures to ensure a level of security appropriate to the risk, including "a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures." | Evidence that the organisation regularly tests its security measures. A pen test report is one of the strongest forms of evidence that Article 32 obligations are being met — particularly if it demonstrates a cycle of testing, finding, remediating, and retesting. |
| NIS2 Directive | Article 21: essential and important entities must implement risk-based cybersecurity measures including security testing. Member states may define specific testing requirements. | Evidence of risk-based security testing. The report should demonstrate that testing was scoped based on the organisation's risk assessment, not performed as a checkbox exercise. Findings mapped to the organisation's critical services and systems. |
| FCA / PRA (Financial Services) | SYSC 13 (operational resilience) and the Senior Managers and Certification Regime (SM&CR). Firms must manage operational risk including cyber risk. Senior managers bear personal accountability. | Evidence that the firm identified, assessed, and managed cyber risks through regular pen testing. A report that identifies critical findings which remain unremediated creates potential personal liability for the accountable senior manager under SM&CR. |
| Cyber Essentials Plus | External vulnerability assessment and internal testing performed by a certified assessor as part of the certification process. | Assessment results demonstrating that critical and high vulnerabilities are remediated within the certification window. Clear pass/fail determination against the Cyber Essentials technical controls. |
In every framework, the report is the evidence. The auditor doesn't watch the tester work. They review the report. If the report is vague, lacks methodology documentation, or doesn't demonstrate a testing-remediation-retesting cycle, the compliance requirement may be considered unmet — regardless of how thorough the actual testing was.
Cyber insurance underwriters increasingly request evidence of penetration testing during application and renewal. Some policies explicitly require regular pen testing as a condition of coverage. The pen test report is one of the artefacts the underwriter uses to assess the organisation's risk profile — and the quality of the report directly influences the outcome.
| What the Underwriter Sees | The Good Outcome | The Bad Outcome |
|---|---|---|
| Testing performed regularly — annual or more frequent pen tests with consistent scope | Demonstrates mature security programme. Supports favourable risk assessment. May contribute to reduced premiums. | No evidence of regular testing. The underwriter assumes the organisation doesn't know its risk posture. Higher premiums or additional conditions imposed. |
| Findings identified and remediated — the report shows findings with a remediation tracker demonstrating closure | Demonstrates the testing-remediation cycle: risks are found and fixed. The organisation is actively managing its attack surface. | Critical findings identified but no evidence of remediation. The underwriter sees known, unaddressed risk — potentially leading to coverage exclusions for incidents related to known vulnerabilities. |
| Improvement over time — successive reports showing reduced finding counts, faster remediation, and improved detection | Demonstrates a trajectory of improvement. The organisation is getting safer. Risk is reducing. The underwriter's exposure is decreasing. | Successive reports showing the same findings recurring year after year. The organisation is paying for testing but not acting on it. The underwriter questions whether the investment in coverage is justified. |
| Report quality itself — is the report comprehensive, well-structured, and evidenced? | A professional, evidenced report suggests the organisation engaged a competent provider and takes security testing seriously. | A thin, poorly structured report with generic findings suggests a checkbox exercise. The underwriter doubts the testing was rigorous enough to reveal the organisation's true risk. |
A pen test report that identifies critical vulnerabilities creates a record that the organisation knew about them. If those vulnerabilities are not remediated and a breach subsequently exploits them, the report becomes evidence that the organisation knowingly accepted the risk. Some insurers may use this to dispute claims — arguing that the organisation failed to take reasonable steps to mitigate a known risk. This is not an argument against pen testing. It's an argument for remediating what pen tests find.
If the organisation suffers a data breach, the pen test report enters an entirely different context. It becomes part of the incident investigation, the regulatory notification to the ICO (under UK GDPR, within 72 hours), the insurance claim, and potentially civil litigation by affected data subjects or contractual counterparties. What the report says — and what it recommended — matters enormously.
| Scenario | How the Report Helps | How the Report Harms |
|---|---|---|
| Breach exploits a vulnerability the pen test identified and the organisation remediated | The report demonstrates due diligence: the organisation identified the risk, acted on it, and implemented the recommended fix. The breach exploited a different vector. This is the strongest defensible position. | N/A — if the vulnerability was remediated, the report supports the organisation's position. |
| Breach exploits a vulnerability the pen test identified and the organisation did NOT remediate | Limited. The report demonstrates that testing was performed (better than no testing), but the unremediated finding creates a difficult question: the organisation knew about the vulnerability and chose not to fix it. | The report becomes evidence of wilful negligence — the organisation was informed of the risk, provided with specific remediation guidance, and failed to act. This is the weakest legal and regulatory position. |
| Breach exploits a vulnerability the pen test did NOT identify | The report demonstrates that the organisation commissioned regular security testing — evidencing a proactive security posture even though this specific vulnerability was missed. The scope and methodology sections demonstrate what was tested. | If the vulnerability was clearly in scope and should have been found, the question shifts to the pen test provider's competence. The organisation may have a claim against the provider for failure to identify a vulnerability within the agreed scope. |
| Regulatory investigation into the organisation's security posture | A well-structured report with regular testing cadence, demonstrated remediation, and improving metrics evidences mature risk management. The ICO and FCA look favourably on organisations that can demonstrate a cycle of testing, finding, fixing, and retesting. | A thin report, or no report at all, suggests insufficient investment in security testing. A report with critical findings and no remediation evidence suggests the organisation identified risks and ignored them. |
The IT team needs GPO paths and code examples. The regulatory, legal, and insurance audiences need different qualities — and a report that lacks these qualities may fail the organisation precisely when it matters most.
A pen test report is simultaneously one of the organisation's most sensitive documents and one of its most important compliance artefacts. It contains a detailed roadmap for compromising the organisation — and it's the evidence that the organisation is managing its security risk. Managing this tension requires deliberate policy.
| Policy Area | Recommendation | Rationale |
|---|---|---|
| Access control | Restrict access to the full report to named individuals: CISO, IT manager, lead remediation engineer, internal audit. Provide the executive summary separately to the board. Provide individual finding excerpts to the teams that need to remediate them. | The full report is a complete attack guide for the organisation. It should be treated as confidential and access-controlled. Not everyone who needs to act on a finding needs access to the entire report. |
| Encryption | Store reports encrypted at rest. Transmit via encrypted channels only — never via unencrypted email. Use password-protected PDFs as a minimum, with the password communicated via a separate channel. | The report contains the keys to the organisation's security weaknesses. If the report is intercepted or accessed by an unauthorised party, it becomes an attack playbook. |
| Retention | Retain reports for a minimum of three years — or longer if required by the organisation's regulatory framework (PCI DSS, FCA, etc.). Maintain a clear archive with version control and access logging. | Auditors may request reports from previous years. Insurance claims may reference testing performed years earlier. Legal proceedings may require disclosure of historical testing records. Reports that were deleted or lost cannot serve as evidence. |
| Remediation record | Maintain a remediation tracker alongside each report. For every finding: status (remediated, in progress, accepted risk, deferred), date of remediation, evidence of fix, and the name of the individual who confirmed it. | The report alone shows what was found. The remediation record shows what was done about it. Together, they demonstrate the complete testing-remediation cycle that regulators, insurers, and legal counsel evaluate. |
| Legal privilege | Consult legal counsel on whether pen test reports should be commissioned under legal privilege. In some jurisdictions and circumstances, commissioning the report through external legal counsel may protect it from disclosure in litigation. | This is a complex legal question that varies by jurisdiction and circumstance. The decision should be made by the organisation's legal team before the engagement is commissioned — not after findings are reported. |
The penetration test report is not a technical document that expires when the findings are remediated. It's a legal, regulatory, and insurance artefact that persists for years — reviewed by auditors during certification, submitted to underwriters during renewal, disclosed to regulators during inquiries, and produced as evidence if a breach occurs. Every audience evaluates the report differently: the auditor checks for methodology and remediation tracking, the insurer assesses the risk trajectory, and the legal team determines whether the report demonstrates due diligence or creates liability.
A report that serves only the IT team — with technical findings and remediation commands but no methodology documentation, no compliance mapping, no timestamped evidence, and no remediation tracking — misses the majority of its lifetime value. A report that serves all audiences — with clear dates, documented scope, justified severity ratings, timestamped evidence, specific recommendations, and a structure that supports remediation tracking — is an asset that protects the organisation across regulatory, legal, and insurance contexts for years after the test is complete.
The test lasts two weeks. The report lasts years. Write it, store it, and manage it accordingly.
Our reports include documented methodology, compliance framework mapping, timestamped evidence, severity justifications, and remediation tracking support — because the report's most important audience may not read it until years after the test is complete.