Most penetration test findings are not lost because nobody read the report; they are lost because they never got an owner, a date and a retest, so the same issue appears again in next year's report. This template gives security and IT teams a ready-to-use tracker for penetration test findings, from intake through owner assignment, risk decision, remediation, retest and formal closure. It follows the NCSC position that risk decisions on fixes stay with the organisation, uses CVSS v4.0 nomenclature for severity, and maps to the NIST plan of action and milestones controls. It is written for vulnerability management and security assurance leads who run the tracker, and for system owners who work from it. Adapt the bracketed text before adoption.
How to use this template
- Bracketed timings, durations and thresholds are NHI Mgmt Group recommendations; adjust them to your risk appetite, policies and contracts.
- Replace text in square brackets, such as [Organisation], [Assurance Lead] and [Ticketing System], with your own names and values. "Must" is mandatory; "should" is recommended.
- Section 5 is the tracker itself: copy its fields into a spreadsheet or your ticketing system. Sections 1 to 4 and 6 to 9 govern how it is run.
- Decision points are marked D1 to D4.
- Reviewing the report itself (quality checks, challenging severities, triage) is covered in the Penetration Testing Guide. Setting remediation deadlines and exceptions across all vulnerability sources is covered in the Remediation SLAs and Vulnerability Exceptions Guide. This template applies those decisions to pen test findings.
1. Purpose
1.1 This tracker ensures every finding from a penetration test, red team exercise or authorised security assessment of [Organisation] is assigned, decided, fixed or formally accepted, verified by retest, and closed with evidence.
1.2 It provides the audit trail that assessors, customers and insurers ask for when they request proof that test findings were acted on.
2. Scope
2.1 In scope: external and internal infrastructure tests, web, API and mobile application tests, cloud configuration reviews, social engineering and physical tests, red team and threat-led tests, and bug bounty or researcher reports accepted as valid.
2.2 Findings from automated scanners stay in the vulnerability management system unless a tester confirmed them as exploitable; in that case they are tracked here and cross-referenced.
2.3 Informational observations are logged with status "Noted" and need no retest, unless the [Assurance Lead] decides otherwise.
3. Roles and responsibilities
| Role | Responsibility |
|---|---|
| [Assurance Lead] | Owns the tracker, imports findings within [5] working days of the final report, chairs the review, requests retests |
| [System Owner] | Accountable for each finding on their system: accepts ownership, agrees the plan and due date, provides closure evidence |
| [Remediation Owner] | Engineer or team doing the fix; named on the ticket |
| [Risk Owner] | Business owner who signs risk acceptance where a finding will not be fixed by its due date |
| [Test Provider] | Clarifies findings, performs retests, issues retest evidence |
| [CISO] | Approves acceptance of Critical and High findings, receives the monthly report |
4. Intake and triage
4.1 The [Assurance Lead] must create one tracker record per finding per affected asset group. A finding affecting [20] servers with the same fix is one record with an asset list; a finding with different owners is split by owner.
4.2 At intake, record the tester's severity unchanged. The organisation's own rating goes in a separate field (5.1, field 9). The NCSC notes testers may rate issues higher or lower than you would because they lack business context, and that this review is to understand risk, not to downplay findings.
4.3 D1: severity adjustment. An organisational rating lower than the tester's must record the reason (for example, compensating control or asset not reachable from the tested position) and be approved by the [Assurance Lead]. Where the tester gave a CVSS score, record which nomenclature it is: CVSS-B (Base only), CVSS-BT, CVSS-BE or CVSS-BTE. Environmental and threat context belong in the score, not in a silent downgrade.
4.4 Raise priority where the finding involves a vulnerability on the CISA Known Exploited Vulnerabilities catalogue, an internet-facing asset, or a credential: default passwords, hardcoded secrets, over-privileged service accounts, reusable tokens. Credential findings must also go to the secrets or identity owner for rotation. See the Non-Human Identity (NHI) Guide.
4.5 Hold a debrief with the [Test Provider] before assigning, so owners can ask questions while testers still remember the context.
5. Tracker fields
5.1 Each record must hold the following fields.
| # | Field | Content | Example |
|---|---|---|---|
| 1 | Tracker ID | Unique, never reused | PT-[2026]-[014]-03 |
| 2 | Engagement | Test name, provider, report reference and date | [External infrastructure Q3], [Provider], report v1.0 |
| 3 | Tester finding ID and title | As written in the report | EXT-07 Outdated TLS configuration |
| 4 | Affected assets | Hostnames, URLs, accounts, cloud resource IDs | [vpn.example.com] |
| 5 | Category | Configuration, patching, authentication, authorisation, credential exposure, injection, logic, physical, people | Credential exposure |
| 6 | Identity involved | Human, service account, API key, token, certificate or none | Service account [svc-backup] |
| 7 | Tester severity | As reported, with scheme | High, CVSS-B 8.1 |
| 8 | Exploitability context | KEV listed, internet-facing, chained in attack narrative | Chained with EXT-04 to reach domain admin |
| 9 | Organisational priority | P1 to P4 per section 6, with D1 reason if lowered | P1 |
| 10 | System Owner | Named person, not a team | [Name] |
| 11 | Remediation Owner and ticket | Link to change or work ticket | [CHG-12345] |
| 12 | Treatment | Fix, mitigate, accept, transfer, false positive | Fix |
| 13 | Plan | What will be done, including interim mitigation | Disable account, rotate password, move job to managed identity |
| 14 | Due date | From section 6, counted from report date | [2026-11-24] |
| 15 | Status | Per section 7 | Awaiting retest |
| 16 | Fix evidence | Screenshot, config diff, scan result, commit | [Link] |
| 17 | Retest result and date | Pass, fail, partial; retest reference | Pass, retest letter [ref] |
| 18 | Risk acceptance | Reference, approver, expiry date | [RA-2026-09], expires [date] |
| 19 | Root cause and repeat flag | Why it existed; seen in a previous test? | Repeat of PT-2025-011-02 |
| 20 | Closed by and date | [Assurance Lead] sign-off | [Name, date] |
6. Priority and due dates
6.1 Default due dates below are NHI Mgmt Group suggestions; replace them with [Organisation]'s approved remediation SLAs so pen test findings follow the same clock as scanner findings.
| Priority | Typical trigger | Suggested due date | Acceptance approver |
|---|---|---|---|
| P1 | Critical, or High with KEV listing, internet exposure or exposed credential | [7] days; interim mitigation within [48] hours | [CISO] |
| P2 | High | [30] days | [CISO] |
| P3 | Medium | [90] days | [Risk Owner] |
| P4 | Low | [180] days or next release | [System Owner] |
6.2 Contractual or regulatory deadlines that are shorter override this table. Record the source in field 14.
6.3 D2: due date extension. An extension must be requested before the due date, state the reason and the interim mitigation, and is approved at the acceptance approver level. A second extension converts to a risk acceptance (section 8).
7. Status, retest and closure
| Status | Meaning | Exit condition |
|---|---|---|
| New | Imported, not yet assigned | System Owner accepts ownership |
| Assigned | Owner and due date set | Plan recorded (field 13) |
| In progress | Remediation under way | Fix evidence attached |
| Awaiting retest | Owner states it is fixed | Retest result recorded |
| Retest failed | Issue still present or partly fixed | Back to In progress; due date unchanged unless D2 approved |
| Risk accepted | Formally accepted with expiry | Expiry reached: back to Assigned |
| False positive | Shown not to be a real issue | Evidence and [Test Provider] agreement recorded |
| Closed | Verified fixed | Final |
7.1 A finding must not move to Closed on the owner's word alone. P1 and P2 findings need a retest by the [Test Provider] or an independent internal tester; P3 and P4 may be closed on documented evidence reviewed by the [Assurance Lead].
7.2 D3: retest batching. The [Assurance Lead] should batch retests to fall within the provider's retest window, where the contract includes one, and must not hold a P1 retest for a batch.
7.3 Credential findings close only when the credential is rotated or removed and the rotation is confirmed, not when the exposed copy is deleted.
8. Risk acceptance
8.1 Acceptance records must state: the finding, why it cannot be fixed by the due date, compensating controls, residual risk, approver at the level in section 6, and an expiry no longer than [6] months for P1 and P2 or [12] months for P3 and P4.
8.2 D4: acceptance refused. If the approver refuses, the finding returns to Assigned with a new due date set by the approver.
8.3 Accepted findings must be listed in the scope briefing for the next test so testers can check whether compensating controls hold.
9. Reporting and review
9.1 The [Assurance Lead] must report monthly to the [CISO] and [security committee]:
- Open by priority and age: with overdue items named by owner.
- On-time closure rate: per priority, against section 6.
- Retest first-time pass rate: a low rate means fixes are being declared done too early.
- Repeat findings: count of findings flagged in field 19, the clearest sign of a process gap.
- Active acceptances: with expiry dates in the next [60] days.
9.2 After each engagement closes, review root causes across its findings and feed systemic fixes (build standards, secret scanning, identity lifecycle) into the security plan.
Implementation guidance
- Pick the home: use your existing ticketing or vulnerability platform if it can hold all twenty fields and an audit trail; a spreadsheet works for small organisations with fewer than [three] tests a year.
- Agree the contract terms first: ask providers for findings in a machine-readable export with stable finding IDs, and for a retest window, so intake and retest are not manual. See the Penetration Testing Services RFP Template.
- Pilot on one engagement: import, run the debrief and track to closure, then adjust fields and due dates before rolling out to all tests.
- Link to the vulnerability programme: use the same priorities, SLAs and acceptance process, so owners see one queue. See the Vulnerability Management Guide.
- Roll back if needed: if the new process stalls intake, keep the field set but relax retest evidence for P3 and P4 temporarily, never for P1 and P2.
| Framework | Reference |
|---|---|
| NIST SP 800-53 Rev. 5 | CA-8 Penetration Testing; CA-5 Plan of Action and Milestones; PM-4 Plan of Action and Milestones Process; SI-2 Flaw Remediation; RA-5 Vulnerability Monitoring and Scanning |
| NIST SP 800-115 | Analysing findings and developing mitigation strategies after technical testing |
| CIS Controls v8.1 | Control 18 Penetration Testing; see the CIS Control 18 Penetration Testing Guide |
Common failure patterns: closing on the owner's word without retest; downgrading tester severity with no recorded reason; deleting an exposed secret without rotating it; acceptances with no expiry; and tracking per report rather than per finding, so partial fixes hide the remainder.
Standards and references
- NCSC: Penetration testing
- NIST: SP 800-115, Technical Guide to Information Security Testing and Assessment
- NIST: SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations
- FIRST: Common Vulnerability Scoring System v4.0
Related NHI Mgmt Group resources: Penetration Testing Guide · CIS Control 18 Penetration Testing Guide · Remediation SLAs and Vulnerability Exceptions Guide · CVSS v4 Guide · Penetration Testing Policy Template