What is a vulnerability remediation worksheet?

A vulnerability remediation worksheet is a structured per-finding record that captures everything needed to drive a single vulnerability from triage through verified close. It pairs the finding identifier and CVSS severity with the named remediation owner, the agreed SLA, the planned fix, the evidence required to verify the fix, the retest outcome, and the closure timestamp. The point is to make every step visible on one record so the work cannot quietly stall in a Slack thread or an engineering ticket queue.

How is a remediation worksheet different from a vulnerability scanner report?

A scanner report is the input. The remediation worksheet is the operating record that runs the work after the scan. The scanner gives you a finding, severity, and detection evidence. The worksheet adds the owner, the SLA target, the planned fix, the verification evidence, the retest pair, and the closure record. Scanners do not assign owners, do not enforce SLAs, do not pair retests to original findings, and do not produce auditor-ready closure timelines. The worksheet is the layer where remediation actually happens.

Who fills in the remediation worksheet?

The triage owner fills in the identification, severity, and asset impact sections at the moment the finding is logged. The named remediation owner fills in the planned fix, working notes, fix evidence, and the retest request. The verifier (a tester, the original analyst, or a peer reviewer) fills in the retest outcome and the closure decision. For accepted-risk outcomes, the risk owner and the security approver sign the dedicated risk acceptance section instead. Every section has a named owner so the worksheet is never stuck on "someone".

What fields should a vulnerability remediation worksheet always include?

At minimum: a finding identifier paired to the source engagement or scan, a CVSS 3.1 vector with severity, the affected assets and their data classification, the named remediation owner and their team, the SLA target date by severity, the planned fix or compensating control, the evidence required to verify the fix, the retest pair (date, tester, outcome), the closure or acceptance decision with a timestamp, and the audit trail of status transitions. The worksheet should also reference the original finding record so a successor reviewer can reconstruct the decision without speaking to anyone who worked on it.

What SLAs by severity does the worksheet expect?

A reasonable starting ladder is critical within 7 days, high within 30 days, medium within 90 days, low within 180 days, and informational on best effort. Tune the targets to your business risk tolerance, your release cadence, and any framework expectations (PCI DSS Requirement 6, ISO 27001 Annex A.8, SOC 2 CC7, CISA KEV cadence). The worksheet captures the agreed SLA on each finding so the audit trail records both the policy and the per-finding deviation rather than leaving them implicit.

How does the worksheet handle findings that cannot be remediated inside the SLA?

Use the dedicated risk acceptance section, or pair the worksheet to a separate risk acceptance form. Either way, the worksheet records that the finding breached its SLA, the named risk owner and security approver who accepted the residual risk, the compensating controls in place, the trigger conditions that would invalidate the acceptance, and the hard expiry. The point is to make accepted risk explicit and time-bound rather than letting it become a forever-deferral hidden in the queue.

How does the worksheet support audit evidence for ISO 27001, SOC 2, or PCI DSS?

Auditors want to see four things per finding: severity at detection, the named owner, the closure or acceptance evidence, and the timeline against the agreed SLA. The worksheet records all four on one record, which is what an ISO 27001 Annex A.8 control review, a SOC 2 CC7 evidence pack, or a PCI DSS Requirement 6 walkthrough actually asks for. Run the worksheet inside a workspace that captures the activity log automatically and the evidence is the byproduct of the work rather than a separate report you have to assemble.

Can the worksheet be used by both internal security teams and external pentest firms?

Yes. Internal AppSec and vulnerability management teams use it to track findings that originate from internal scanners, code reviews, threat models, and third-party assessments. External pentest firms and security consultancies use it to give clients a per-finding record they can update in a branded portal rather than receiving a static PDF that ages out the day after delivery. The fields are the same in both cases. The difference is who fills in the owner column.

How does this worksheet pair with a remediation SLA calculator and a risk acceptance form?

The SLA calculator sets the target close window per severity at the policy layer. The worksheet records what actually happened on each finding against that target. The risk acceptance form covers the structured exception when the worksheet shows a finding will not meet its SLA. The three sit together: the policy (SLA calculator), the operating record (this worksheet), and the structured exception (risk acceptance form). Together they replace the ad hoc trail of email, spreadsheets, and slide decks that most programmes still rely on.

How long should a closed remediation worksheet be retained?

Retain the worksheet for at least the audit window of the strictest framework that governs the affected asset. For SOC 2 the typical window is 12 months of audit period plus retention beyond. For PCI DSS the expectation is 12 months minimum with three months immediately available. For ISO 27001 retention is set by the organisation. For HIPAA and many financial regulators the window is six years or longer. Default to the longest applicable window, store the worksheet against the source finding, and make sure status transitions, evidence, and approvals are captured by the activity log.

Free Tool

Vulnerability Remediation Worksheet
drive each finding from triage to verified close

A free, copy-ready vulnerability remediation worksheet. Ten structured sections covering finding identification, severity at detection, affected assets, remediation ownership and SLA, the remediation plan, fix evidence, the retest pair, the closure or risk acceptance decision, SLA performance and audit trail, and linked records. Pairs to the underlying finding rather than replacing it so a successor reviewer can reconstruct the timeline without speaking to anyone who worked on it. Aligned with ISO/IEC 27001 Annex A.8 and Clause 8.3, SOC 2 CC7, PCI DSS Requirement 6, NIST SP 800-40, NIST SP 800-53 RA-5 and SI-2, and CISA KEV remediation cadence.

Get Started Free

No credit card required. Free plan available forever.

Full worksheet

Copy the full vulnerability remediation worksheet

Ten structured sections, paired to the underlying finding rather than replacing it. Aligned with ISO/IEC 27001 Annex A.8 and Clause 8.3, SOC 2 CC7, PCI DSS Requirement 6, NIST SP 800-40, NIST SP 800-53 RA-5 and SI-2, and the CISA KEV cadence. Replace every {{PLACEHOLDER}} before the worksheet is signed off as closed.

1. Finding identification and source

Pair the worksheet to the underlying finding record. A successor reviewer should be able to reconstruct the entire remediation timeline without speaking to anyone who worked on it. ISO/IEC 27001 Annex A.8, SOC 2 CC7, and PCI DSS Requirement 6 all expect the source record to be traceable.

Worksheet reference: {{WORKSHEET_REFERENCE}}
Finding identifier (canonical record): {{FINDING_ID}}
Source engagement, scan, or report: {{SOURCE_REFERENCE}}
Detection method (authenticated scan, external scan, code scan, manual review, third-party pentest, bug bounty, internal report): {{DETECTION_METHOD}}
Date detected: {{DATE_DETECTED}}
Date triaged: {{DATE_TRIAGED}}
Status: New / Triaged / In Progress / Awaiting Retest / Resolved / Accepted / Reopened

2. Severity and impact at detection

Capture the severity at the moment of detection so the audit trail is unambiguous. Severity does not change as work progresses. Closure does not lower severity, only the residual risk after the fix or compensating control.

CVSS 3.1 vector: {{CVSS_VECTOR}}
CVSS 3.1 base score: {{CVSS_BASE_SCORE}}
Severity: Critical / High / Medium / Low / Informational
CWE / OWASP mapping: {{CWE_OWASP_MAPPING}}
KEV listing (CISA Known Exploited Vulnerabilities): Yes / No / Not applicable
EPSS score (if applicable): {{EPSS_SCORE}}

Impact statement (one paragraph in plain language):
{{IMPACT_STATEMENT}}

Exploitation prerequisites:
{{EXPLOITATION_PREREQUISITES}}

3. Affected assets and scope

List every system, service, repository, or business process the finding touches. A worksheet that names only one asset when three are affected leaves the other two unprotected once the first is closed.

Affected systems / applications / repositories: {{AFFECTED_ASSETS}}
Environment (production, staging, pre-production, development): {{ENVIRONMENT}}
Data classifications in scope: {{DATA_CLASSIFICATIONS}}
Business processes impacted: {{BUSINESS_PROCESSES}}
Regulatory scope (PCI DSS, ISO 27001, SOC 2, HIPAA, GDPR, NIS2, DORA, FedRAMP, CMMC, other): {{REGULATORY_SCOPE}}
Internet-facing exposure: Yes / No / Partial
Compensating control already in place: {{COMPENSATING_CONTROL_AT_DETECTION}}

4. Remediation ownership and SLA

A finding without a named owner is a finding that nobody fixes. Pair every worksheet with an accountable remediation owner, a stakeholder who can authorise the work, and an SLA target the team has agreed in advance. "The platform team" is not an owner; a named person is.

Remediation owner (named individual): {{REMEDIATION_OWNER}}
Owner team / business unit: {{OWNER_TEAM}}
Stakeholder approving the work: {{STAKEHOLDER_NAME}}
Date assigned to owner: {{DATE_ASSIGNED}}

SLA target by severity (default ladder, tune to your programme):
- Critical: 7 days from detection
- High: 30 days from detection
- Medium: 90 days from detection
- Low: 180 days from detection
- Informational: best effort

Agreed SLA target date for this finding: {{SLA_TARGET_DATE}}
Framework alignment for the SLA (PCI DSS Requirement 6, ISO 27001 Annex A.8, SOC 2 CC7, CISA KEV cadence, internal policy): {{SLA_FRAMEWORK_BASIS}}
Linked engineering ticket (if any): {{ENGINEERING_TICKET_REFERENCE}}

5. Remediation plan and working notes

The plan describes how the finding will be fixed (or compensated for), what changes, and who reviews the change before it ships. Working notes capture the rolling diary of the remediation so reviewers and auditors can see the path from triage to fix.

Planned remediation type: Code fix / Configuration change / Patch / Architectural change / Compensating control / Acceptance / Deferred to vendor
Description of planned fix:
{{REMEDIATION_DESCRIPTION}}

Affected components or files (paths, modules, services):
{{AFFECTED_COMPONENTS}}

Change review path (security review, code review, change advisory board, none):
{{CHANGE_REVIEW_PATH}}

Working notes (rolling diary, append entries with date and author):
- {{DATE}} - {{AUTHOR}} - {{NOTE}}
- {{DATE}} - {{AUTHOR}} - {{NOTE}}
- {{DATE}} - {{AUTHOR}} - {{NOTE}}

Blockers encountered:
- {{BLOCKER_1}}
- {{BLOCKER_2}}

6. Fix evidence and verification artefacts

Evidence is the proof a successor reviewer would need to confirm the fix landed. A configuration excerpt, a commit hash, a change ticket reference, a screenshot of the corrected behaviour. Vague claims like "fixed in production" are not evidence.

Fix landed in (environment): {{FIX_LANDED_ENVIRONMENT}}
Fix landed on (date): {{FIX_LANDED_DATE}}
Commit, change ticket, or release reference: {{COMMIT_OR_CHANGE_REFERENCE}}

Evidence required to verify the fix:
- Configuration excerpt or diff: {{CONFIG_EVIDENCE_REFERENCE}}
- Code change reference: {{CODE_EVIDENCE_REFERENCE}}
- Test or scan output showing the previously vulnerable behaviour is no longer present: {{TEST_EVIDENCE_REFERENCE}}
- Screenshot of the corrected behaviour (if user-visible): {{SCREENSHOT_REFERENCE}}
- Logging or detection rule that would surface a regression: {{DETECTION_RULE_REFERENCE}}

Side effects or regressions introduced by the fix:
{{SIDE_EFFECTS_NOTES}}

7. Retest pair

A retest is what turns "fixed" into "verified". Pair the retest to the original finding so the close-out record captures the original scope, the fix, the retest evidence, and the final outcome on a single timeline. Without a retest pair, closure is an assertion rather than a verified fact.

Retest scheduled date: {{RETEST_SCHEDULED_DATE}}
Retest performed date: {{RETEST_PERFORMED_DATE}}
Tester or verifier (named individual, not the same person who wrote the fix): {{TESTER_NAME}}
Verification method: Manual reproduction / Automated test / Authenticated scan / External scan / Code review / All applicable
Retest outcome: Verified Closed / Partial (residual issue) / Failed (issue still present) / Regressed (re-emerged)

Retest evidence references:
- Reproduction steps used during retest: {{RETEST_REPRO_STEPS_REFERENCE}}
- Output of automated test or scan: {{RETEST_AUTOMATED_OUTPUT}}
- Notes on residual or partial issues:
{{RETEST_RESIDUAL_NOTES}}

8. Closure decision or risk acceptance

Closure is one of: verified close, accepted risk with a structured form, or false positive with a documented reason. "Closed by the team" without a decision type is not a closure. Pair every closure with a timestamp and a named decision maker.

Closure decision: Verified Closed / Accepted Risk / False Positive / Duplicate / Out of Scope / Will Not Fix
Closure timestamp: {{CLOSURE_TIMESTAMP}}
Decision maker (named individual): {{CLOSURE_DECISION_MAKER}}

If Accepted Risk:
- Linked risk acceptance form reference: {{RISK_ACCEPTANCE_REFERENCE}}
- Compensating controls in place: {{COMPENSATING_CONTROLS}}
- Hard expiry of acceptance: {{ACCEPTANCE_EXPIRY_DATE}}
- Cancellation triggers: {{ACCEPTANCE_CANCELLATION_TRIGGERS}}

If False Positive:
- Reason: {{FALSE_POSITIVE_REASON}}
- Reviewer who confirmed false positive: {{FALSE_POSITIVE_REVIEWER}}
- Detection rule or scanner signature suppressed (if any): {{SUPPRESSED_RULE_REFERENCE}}

If Duplicate or Out of Scope:
- Linked canonical finding or scope statement: {{LINKED_CANONICAL_OR_SCOPE_REFERENCE}}

If Will Not Fix:
- Rationale, named approver, and review date: {{WILL_NOT_FIX_RATIONALE_AND_APPROVER}}

9. SLA performance and audit trail

Auditors ask for four things per finding: severity at detection, named owner, closure or acceptance evidence, and timeline against the agreed SLA. Capture them on one record and the export is the audit artefact.

SLA target date: {{SLA_TARGET_DATE}}
Actual closure or acceptance date: {{ACTUAL_CLOSURE_DATE}}
SLA outcome: Met / Missed / Extended (with reason) / Accepted (with reason)
SLA breach reason (if applicable): {{SLA_BREACH_REASON}}

Status transition log (timestamp, user, from-status, to-status):
- {{TIMESTAMP}} - {{USER}} - {{FROM_STATUS}} -> {{TO_STATUS}}
- {{TIMESTAMP}} - {{USER}} - {{FROM_STATUS}} -> {{TO_STATUS}}
- {{TIMESTAMP}} - {{USER}} - {{FROM_STATUS}} -> {{TO_STATUS}}

Reviewer for audit handover (named individual): {{AUDIT_REVIEWER}}
Audit handover date: {{AUDIT_HANDOVER_DATE}}
Worksheet retention period: {{RETENTION_PERIOD}}

10. Linked records and framework citations

Attach everything a successor reviewer needs to reconstruct the decision. Pair the worksheet to the original finding, the engagement, the retest, the risk acceptance form (if any), and the framework controls the work supports.

Linked records:
- Original finding record: {{LINK_TO_FINDING}}
- Engagement, scan, or report record: {{LINK_TO_ENGAGEMENT}}
- Retest record: {{LINK_TO_RETEST}}
- Risk acceptance form (if applicable): {{LINK_TO_RISK_ACCEPTANCE}}
- Engineering ticket (if applicable): {{LINK_TO_ENGINEERING_TICKET}}
- Vendor advisory or third-party reference: {{LINK_TO_VENDOR_ADVISORY}}

Framework citations supporting this remediation worksheet:
- ISO/IEC 27001:2022 Annex A.8 technological controls and Clause 8.3 information security risk treatment
- SOC 2 Trust Services Criteria CC7.1, CC7.2, CC7.3 system operations and change management
- PCI DSS v4.0 Requirement 6 develop and maintain secure systems and software
- NIST SP 800-40 patch management programme guidance
- NIST SP 800-53 RA-5 vulnerability monitoring and scanning, SI-2 flaw remediation
- CISA KEV cadence for known exploited vulnerabilities
- OWASP ASVS verification requirements (where applicable)

How to use this worksheet

Confirm the underlying finding has a CVSS 3.1 vector, evidence at detection, and remediation guidance recorded against it. The worksheet is the operating record that runs the work after the scan, not a substitute for the finding record itself. Use the SecPortal findings management feature so the worksheet, the finding, and the closure timestamp share one record.
Replace every {{PLACEHOLDER}} with the values for this specific finding. Avoid copy-paste working notes across multiple findings: every worksheet should stand on its own evidence.
Set the SLA target in Section 4 against a documented severity ladder, not a per-finding negotiation. Use the free vulnerability remediation SLA calculator to produce a defensible ladder tied to PCI DSS, ISO 27001, SOC 2, or CISA KEV expectations, then apply it consistently across the worksheet population.
Pair the retest in Section 7 to the original finding so the close-out record captures the original scope, the fix, the retest evidence, and the final outcome on one timeline. A separate retest spreadsheet is the most common reason closure timestamps drift.
For findings that cannot meet their SLA, pair the worksheet to a structured risk acceptance form and run the lifecycle inside the SecPortal vulnerability acceptance and exception management workflow so accepted risk does not become a forever-deferral hidden in the queue.
Capture status transitions with timestamps so the audit log in Section 9 is a byproduct of the work rather than a separate task. The SecPortal workspace activity log records every status change, comment, evidence upload, and approval against the finding record so the audit trail does not depend on anyone remembering to log it.

Framework references

ISO/IEC 27001:2022 Annex A.8 technological controls and Clause 8.3 information security risk treatment. See the SecPortal ISO 27001 framework page for evidence expectations on remediation and risk treatment.
SOC 2 Trust Services Criteria CC7.1 (system operations), CC7.2 (monitoring), and CC7.3 (incident response and change management). See the SecPortal SOC 2 framework page for the evidence pack structure.
PCI DSS v4.0 Requirement 6 develop and maintain secure systems and software. See the SecPortal PCI DSS framework page for remediation cadence expectations inside the cardholder data environment.
NIST SP 800-40 guide to enterprise patch management planning, NIST SP 800-53 RA-5 vulnerability monitoring and scanning, and NIST SP 800-53 SI-2 flaw remediation. See the SecPortal NIST SP 800-53 framework page for control-level mapping.
For severity-driven SLA design that the worksheet records against, see the vulnerability remediation SLA calculator and the severity calibration research.
For the analytical view of how findings age past SLA and turn into risk debt across PCI DSS, ISO 27001, SOC 2, and CISA KEV programmes, see the research on aging pentest findings.
For the workflow that runs SLA policy on the engagement record (timer per finding, breach escalation by severity, audit-ready reporting), see the vulnerability SLA management workflow and the remediation tracking workflow.
For findings management and CVSS scoring inside each worksheet, see the SecPortal findings management feature and the CVSS scoring guide.

This worksheet is provided as a starting point for documenting the remediation of a single vulnerability. It is not legal advice and is not a substitute for your organisation's vulnerability management policy, internal audit procedures, or regulator-specific evidence requirements. Have the final worksheet structure reviewed against the policies and frameworks that govern your programme before it is rolled out.

Loading tool...

Related features

Vulnerability management software that tracks every finding

Orchestrate every security engagement from start to finish

Compliance tracking without a full GRC platform

Every action recorded across the workspace

Your brand. Your portal. Your clients love it.

Remediation tracking

Vulnerability SLA management

Vulnerability acceptance and exception management

Security testing program management

Compliance audits

Run the worksheet inside the finding record, not in a spreadsheet

SecPortal stores severity, owner, SLA, retest evidence, closure timestamp, and the activity log against each finding so the worksheet is the byproduct of the work. Free plan available.

Get Started Free

No credit card required. Free plan available forever.

Vulnerability Remediation Worksheetdrive each finding from triage to verified close

Copy the full vulnerability remediation worksheet

1. Finding identification and source

2. Severity and impact at detection

3. Affected assets and scope

4. Remediation ownership and SLA

5. Remediation plan and working notes

6. Fix evidence and verification artefacts

7. Retest pair

8. Closure decision or risk acceptance

9. SLA performance and audit trail

10. Linked records and framework citations

How to use this worksheet

Framework references

Related features

Vulnerability management software that tracks every finding

Orchestrate every security engagement from start to finish

Compliance tracking without a full GRC platform

Every action recorded across the workspace

Your brand. Your portal. Your clients love it.

Remediation tracking

Vulnerability SLA management

Vulnerability acceptance and exception management

Security testing program management

Compliance audits

Run the worksheet inside the finding record, not in a spreadsheet

Copy the full vulnerability remediation worksheet

1. Finding identification and source

2. Severity and impact at detection

3. Affected assets and scope

4. Remediation ownership and SLA

5. Remediation plan and working notes

6. Fix evidence and verification artefacts

7. Retest pair

8. Closure decision or risk acceptance

9. SLA performance and audit trail

10. Linked records and framework citations

How to use this worksheet

Framework references

Vulnerability Remediation Worksheet
drive each finding from triage to verified close