> cat risk_register.csv | grep 'pen_test' | wc -l && echo 'connected, not isolated'_
A penetration test report is delivered. It contains 34 findings, an attack narrative, and a remediation roadmap. The IT team reads it, remediates the quick wins, and schedules the larger items. The report is filed in a shared drive. The CISO mentions the headline results in the quarterly board update. Twelve months later, the next test is commissioned.
At no point did the findings enter the organisation's risk register. At no point were they assessed against the organisation's risk appetite. At no point did the governance framework — the risk committee, the audit committee, the board — formally evaluate the identified risks, approve the treatment decisions, or track the remediation to closure. The pen test existed in a parallel universe to the organisation's risk management process.
This is common. Penetration testing is often treated as a technical activity that produces a technical report for a technical audience. It's managed by the IT security team, discussed within IT, and resolved (or not) within IT's operational processes. The governance structures that exist to manage organisational risk — the risk register, the risk committee, the audit function, the board — never engage with the findings in a structured way.
The consequence is that pen test findings compete for remediation resources against operational priorities, without the governance authority that formal risk management provides. A finding in a pen test report is a recommendation. A finding in the risk register, assessed against the organisation's risk appetite and approved for treatment by the risk committee, is a mandated action with accountability, a deadline, and board-level visibility.
Penetration testing is an assurance mechanism — it provides evidence about the organisation's security posture. Risk management is the framework that evaluates that evidence and decides what to do about it. Governance is the structure that ensures the decisions are made by the right people, at the right level, with appropriate accountability.
| Layer | Function | How Pen Testing Connects |
|---|---|---|
| Assurance (pen testing, vulnerability scanning, red teaming, audit) | Identifies risks. Provides evidence of the current state. Tests whether controls are effective. | Pen testing is one of several assurance mechanisms. It produces findings — evidence of specific risks — that feed into the risk management layer. |
| Risk management (risk register, risk assessment, risk treatment) | Evaluates identified risks against the organisation's risk appetite. Determines the treatment: mitigate, accept, transfer, or avoid. Assigns ownership and tracks treatment to completion. | Pen test findings are assessed, risk-rated in the organisation's context, and entered into the risk register. Treatment decisions are made formally — not left to the IT team's discretion. |
| Governance (risk committee, audit committee, board) | Ensures risk management is operating effectively. Reviews the risk register. Approves risk appetite. Provides oversight and accountability for risk treatment decisions. | Pen test results are reported through the governance structure. The board sees the risk trajectory. The audit committee verifies that findings are being managed. Accountability is assigned at the appropriate level. |
Not every pen test finding needs to be a separate entry in the risk register — but every significant finding should be assessed against the organisation's risk framework and either entered individually or aggregated into a broader risk entry.
| Step | Who | What Happens |
|---|---|---|
| 1. Finding identified | Pen test provider | The finding is documented in the pen test report with evidence, severity rating (CVSS and contextual), business impact, and remediation recommendation. |
| 2. Risk assessment | CISO / risk manager | The finding is assessed against the organisation's risk framework. What is the likelihood of exploitation? What is the business impact if exploited? What is the current residual risk after existing controls? The assessment produces a risk rating in the organisation's own terms — not just the pen test severity. |
| 3. Risk register entry | Risk manager | The assessed risk is entered into the risk register. Critical and high pen test findings typically become individual entries. Medium findings may be aggregated (e.g. "multiple broadcast protocol misconfigurations" as a single risk). Low and informational findings inform existing risk entries without creating new ones. |
| 4. Treatment decision | Risk committee / CISO | For each risk: mitigate (implement the remediation), accept (document the rationale, apply compensating controls, set review date), transfer (ensure insurance coverage addresses this scenario), or avoid (decommission the vulnerable system or service). The decision is recorded with the rationale. |
| 5. Treatment implementation | IT / engineering teams | The approved treatment is implemented within the agreed timeframe. Self-verification confirms the fix. Progress is reported against the risk register. |
| 6. Validation | Pen test provider (retest) | Independent retesting validates that the treatment is effective. The risk register is updated: risk status moves from "open" to "treated" with evidence of validation. |
| 7. Governance reporting | CISO → risk committee → board | The risk committee reviews the updated register. The board receives a summary: risks identified, treatments approved, treatments completed, validation results, and residual risk assessment. |
This flow transforms a pen test finding from a technical recommendation into a governed risk with ownership, treatment, validation, and board-level visibility. The finding isn't sitting in a PDF waiting for someone to action it — it's in the risk register, assigned to a risk owner, tracked through treatment, and reported upward through the governance structure.
| Treatment | When Appropriate | Governance Requirement |
|---|---|---|
| Mitigate — implement the remediation to reduce the risk | The default for most pen test findings. The remediation is technically feasible, the cost is proportionate to the risk, and the implementation doesn't create unacceptable operational impact. | Risk owner assigned. Remediation deadline agreed. Self-verification and independent retest scheduled. Status tracked in the risk register. |
| Accept — acknowledge the risk and choose not to remediate | The remediation is disproportionately expensive, technically infeasible (legacy system), or the risk is within the organisation's stated appetite. Compensating controls are applied where possible. | Formal acceptance by a named individual at the appropriate seniority — typically the risk owner or a senior manager. Rationale documented. Compensating controls documented. Review date set (typically quarterly). Board informed. |
| Transfer — shift the financial impact to a third party | The risk cannot be fully mitigated and the financial impact of a breach would be significant. Cyber insurance transfers the financial consequence (not the operational or reputational impact). | Insurance policy reviewed to confirm the scenario is covered. The pen test report may be required by the insurer. Accepted risks should be disclosed to the insurer to avoid coverage disputes. |
| Avoid — eliminate the risk by removing its source | The vulnerable system, service, or process is decommissioned. The risk ceases to exist because the asset that carries it is removed from the environment. | Decommissioning approved through change management. Dependencies identified and addressed. Confirmation that the asset is removed and the risk is no longer present. |
Risk acceptance is a legitimate governance decision — but it must be formal, documented, and owned. A finding that's simply not remediated because it was deprioritised is not an accepted risk — it's an unmanaged risk. The difference matters legally, regulatorily, and commercially: a formally accepted risk with documented rationale and compensating controls demonstrates governance. An unremediated finding with no formal decision demonstrates negligence.
| Framework | Relevant Clause | How Pen Testing Supports It |
|---|---|---|
| ISO 27001:2022 | Clause 6.1 — Actions to address risks and opportunities. Clause 8.2 — Information security risk assessment. Clause 8.3 — Information security risk treatment. Annex A, A.8.8 — Management of technical vulnerabilities. | Pen testing provides the evidence for risk assessment (6.1, 8.2). Findings feed the risk treatment plan (8.3). A.8.8 explicitly requires technical vulnerability management including penetration testing. The retest validates treatment effectiveness. |
| ISO 31000:2018 | Clause 6.4 — Risk assessment (identification, analysis, evaluation). Clause 6.5 — Risk treatment. Clause 6.6 — Monitoring and review. | Pen testing is a risk identification and analysis activity (6.4). Findings are evaluated and treated (6.5). Retesting and longitudinal tracking provide monitoring and review (6.6). The pen test programme feeds the continuous improvement loop ISO 31000 requires. |
| ISO 27005:2022 | Clause 7 — Information security risk assessment. Clause 8 — Information security risk treatment. Clause 10 — Monitoring and review. | ISO 27005 provides the specific methodology for information security risk assessment within the ISO 27001 framework. Pen test findings are direct inputs to the risk identification and analysis phases (Clause 7). Treatment decisions follow the ISO 27005 options: modification, retention, avoidance, sharing. |
The board doesn't need to see individual findings. They need to see risk — assessed in terms they understand, managed through a framework they trust, and reported with the metrics that demonstrate the programme is working.
Penetration testing produces evidence. Risk management evaluates that evidence and decides what to do about it. Governance ensures the decisions are made, owned, tracked, and reported. Without the connection between these three layers, pen test findings exist in a technical silo — competing for remediation resources without formal authority, accountability, or board-level visibility.
Within the governance framework, pen test findings become entries in the risk register with assigned owners and formal treatment decisions. Remediation is tracked through the same process as every other organisational risk. Accepted risks are documented, compensated, and reviewed. The board sees the risk posture, the improvement trajectory, and the return on security investment. The audit committee can verify that identified risks are being managed. And the regulator, if they ask, sees a functioning risk management process — not a collection of disconnected PDF reports.
The pen test finds the risk. Governance ensures something is done about it.
Our reports include risk-framework-aligned severity ratings, business impact assessments, treatment options with cost estimates, and longitudinal metrics — providing the inputs your governance framework needs to turn identified risk into managed risk.