The Register Is the Deliverable: Governing Penetration Test Findings Beyond the Report

Penetration testing is often commissioned as an assurance event. A scope is agreed, testers work, a report is issued, and the document is circulated to a distribution list. The organisation has, in a narrow sense, completed the exercise. It has not necessarily reduced risk. The gap between a finding being recorded and a weakness being corrected is where most of the value is lost. A remediation register closes that gap by turning the report into a controlled operational record with named owners, deadlines and evidence of closure.

The report is a snapshot; the register is the control

A penetration test report is a point-in-time narrative. It reflects the estate as it was during the test window, the tester's method and the context available at the time. That is useful, but it is not a management system. Findings need to move into a live register that persists after the report has been filed. The register should be the authoritative view of what remains open, who is accountable and what evidence will be accepted as closure. Without it, remediation depends on memory and inbox discipline.

The register does not need to be elaborate. It needs to be consistent, accessible to the right people and maintained as a controlled record. A spreadsheet can work for a small estate, but it should still have defined fields, version control and an owner. Larger organisations should place the register in an ITSM or GRC platform where tickets, changes and evidence can be linked. The important point is that the register, not the report, becomes the thing that is reviewed.

Fields that make a finding actionable

A finding should enter the register with a unique identifier and a link to the source report. Record the test date, scope and tester. Capture the affected asset or service, the weakness and the potential business impact. Severity should be retained, but it should be accompanied by a local risk rating that reflects exposure, data sensitivity and operational dependency. A high-severity finding on an isolated test system is not equivalent to a medium finding on an internet-facing service holding customer records.

Each entry needs a named owner. A team name is not ownership. The owner should have the authority and capacity to commission the fix, even if delivery is delegated. Record the treatment decision: remediate, mitigate, transfer or accept. For acceptances, record the approver, the rationale, the compensating controls and a review date. Record the due date and the evidence required for closure. If a retest is needed, state that in advance. Link the register entry to the change record or ticket that will deliver the work.

Deadlines, exceptions and the risk of permanence

Remediation deadlines should be risk-based and agreed before the test, not negotiated after findings arrive. A common model sets shorter windows for critical and high findings, with longer windows for medium and low items. The exact intervals should reflect the organisation's risk appetite, regulatory context and ability to deploy change. What matters is that the clock starts when the finding is accepted into the register, and that overdue items escalate through a defined route.

Exceptions are necessary, but they should not become the default. A risk acceptance should have an expiry date and a review trigger. If the underlying condition changes, the acceptance should be revisited. Permanent exceptions are a warning sign: they often indicate that the fix is underfunded, the owner is unclear or the business has chosen to live with a risk it has not genuinely assessed. The register should make that choice visible rather than allowing it to disappear into a report appendix.

Evidence for UK compliance and audit

UK organisations are often asked to demonstrate that security findings are managed, not merely received. Cyber Essentials is a point-in-time certification, but the wider assurance conversation increasingly looks for evidence of ongoing control. GDPR Article 32 requires appropriate technical and organisational measures, and accountability expectations mean an organisation should be able to show how it identifies and addresses weaknesses. The ICO does not prescribe a remediation register, but a coherent record of finding, action and closure is stronger than a filed report with no trail.

Closure evidence should be proportionate and verifiable. Depending on the finding, it might be a configuration export, a change record, a screenshot with a timestamp, a retest result or a signed confirmation from the owner. The register should record who accepted the evidence and when. For findings that are not retested, state why and what alternative assurance was obtained. Retain the register and its evidence for a period consistent with audit and legal requirements. The record should be readable by someone who was not involved in the original test.

An operating rhythm that keeps findings moving

A register only works if it is reviewed. Intake should happen within days of report receipt, with a triage session that confirms severity, ownership and due dates. A weekly or fortnightly ageing review should focus on overdue items and items approaching their deadline. A monthly risk review should consider accepted risks and systemic patterns. A quarterly summary to senior management should show open findings by severity, ageing profile, remediation performance and the status of exceptions. Avoid reporting only the number of findings closed; report whether risk has actually reduced.

The register should connect to vulnerability management, change management and asset management. If the same weakness appears across multiple systems, the register should reveal the pattern rather than treating each finding as an isolated ticket. If an asset is decommissioned, the related finding should be closed with evidence of retirement, not left open indefinitely. If a fix is deployed but not verified, the entry should remain open until verification is recorded.

The discipline is the deliverable

A penetration test is most valuable when its findings change something. In 2026, the pressure is less about commissioning more tests than about demonstrating that previous findings were handled. The report provides the evidence of what was found; the remediation register provides the evidence of what was done. For UK organisations operating under scrutiny from regulators, auditors, customers and boards, that distinction matters. The objective is not a tidier report. It is a defensible record that shows findings were owned, prioritised, treated and verified. That record is the deliverable.