Register
Create one durable record with first-seen time, source, affected asset, business service, owner, exposure, and scan quality. Map duplicates without resetting age.
Exit evidence: stable finding and asset identity.
Remediation governance and verified closure
Build a Vulnerability Remediation SLA That Ends in Verified Closure
A vulnerability remediation SLA should define ownership, risk-based clocks, escalation, temporary mitigation, exception expiry, rescanning or retesting, closure evidence, and the conditions that reopen a finding.
Start the right clocksPreserve first-seen age and separate acknowledgement, validation, mitigation, remediation, and verification
Govern exceptionsRequire evidence, compensating controls, an owner, approval, review, expiry, and trigger events
Prove closureVerify the exact asset and attack path with equivalent or better visibility before closing
“Ticket closed” is an administrative event—not technical proof.
A finding should reach “Remediated — Verified” only after the affected condition is corrected and suitable evidence confirms that the asset, scope, authentication, scanner content, attack path, and test method were sufficient. Mitigated, accepted, not affected, false positive, removed, and verified remediated are different outcomes and should remain distinguishable.
Six controlled gates
Move every validated finding through a traceable lifecycle
This page begins after the scan and finding have been validated. The separate scan report validation guide explains how to establish that starting evidence.
Validate
Confirm applicability and classify true positive, false positive, not affected, or inconclusive. Branch to incident response when compromise may have occurred.
Exit evidence: technical disposition and analyst rationale.
Prioritize and assign
Apply the approved tier, external requirement, local risk context, accountable owner, implementation team, and escalation path.
Exit evidence: decision, clock trigger, owner, and deadline.
Respond
Patch, configure, upgrade, isolate, remove, mitigate, or formally accept residual risk. Temporary mitigation receives its own test and expiry.
Exit evidence: change, mitigation, or approved exception.
Verify
Use an authenticated rescan, targeted retest, configuration evidence, decommission proof, or a combination suited to the original condition.
Exit evidence: successful verification with adequate coverage.
Close and monitor
Record the final state, verifier, remaining limitation, retention location, monitoring, recurrence risk, and reopening trigger.
Exit evidence: approved closure record and audit trail.
Use several clocks, not one number
Define what starts, escalates, and stops each remediation clock
NIST uses organization-defined response periods based on risk; it does not prescribe one universal deadline. External legal, regulatory, contractual, insurer, customer, or directive requirements may impose a faster and controlling deadline.
Acknowledge and assign
Measure time from the policy-defined trigger until an accountable owner accepts the record and the implementing team is identified.
Stops when: ownership and escalation route are confirmed.
Validate applicability
Measure time to confirm the asset, product, version, feature, detection evidence, and affected condition.
Stops when: a supported technical disposition is recorded.
Contain or mitigate
Measure time to reduce urgent exposure or deploy a tested temporary control when permanent remediation cannot be immediate.
Stops when: the compensating control is operating and evidenced.
Permanent remediation
Measure time to patch, configure, upgrade, replace, remove, or otherwise eliminate the vulnerable condition.
Stops when: the approved change is deployed—not when the ticket is merely updated.
Verify effectiveness
Measure time from deployment to a suitable rescan, retest, configuration check, or independent verification.
Stops when: coverage and result meet the closure criteria.
Exception review and expiry
Measure the active-risk period, scheduled reviews, renewal count, milestones, and the hard expiry or trigger that requires reapproval.
Stops when: risk is remediated, avoided, or freshly reauthorized.
Do not reset age through reassignment, scanner changes, duplicate tickets, rediscovery, a failed remediation attempt, or an exception renewal. Preserve first seen, validation date, each response date, and the current clock so reports cannot make an old risk look new.
Policy-defined tiers
Choose local targets from risk, obligations, and operating reality
Use tier names such as Emergency, Accelerated, Standard, and Planned, then approve acknowledgement, mitigation, permanent remediation, verification, and escalation targets for each. Do not label an internal number “NIST-required.”
Compromise or urgent active exploitation
Immediate incident coordination, exposure reduction, evidence preservation, remediation, and verified recovery as authorized.
High-likelihood or high-consequence path
Confirmed affected asset with material exposure, KEV or credible exploit activity, privilege, lateral-movement, or critical-service impact.
Validated, material, and controllable risk
Owned finding with a supported fix and no condition that requires emergency or accelerated handling.
Lower urgency or coordinated lifecycle work
Validated issue scheduled through a documented maintenance, upgrade, replacement, or root-cause plan with monitoring.
SLA policy worksheet
Define the rule and the proof for every clock
The example fields remain technology neutral. Each organization should approve its own targets and external overrides.
All policy fields remain available inside this scroll frame. Use the visible right and bottom scrollbars on smaller screens.
| Policy field | Required definition | Evidence to retain | Common failure | Escalation or override |
|---|---|---|---|---|
| Triggering event | First reliable detection, validated finding, vendor fix release, KEV addition, exposure change, or other approved trigger | First seen, validation date, source timestamps, catalog/advisory date | Clock starts only when a team opens a ticket | Use the earliest applicable internal or external trigger |
| Scope and identity | Stable finding, CVE/check, asset, interface, environment, owner, and business service | Inventory, scan source, authentication, package/configuration evidence | DHCP, cloud replacement, or duplicate tickets reset identity | Escalate unresolved ownership and asset-correlation gaps |
| Priority tier | Risk inputs, decision rule, approver, response targets, and rationale | Severity, exploitation, exposure, impact, controls, obligations | CVSS alone becomes the deadline | Binding external requirement or incident evidence overrides slower tier |
| Acknowledgement | Accountable owner and implementing team accept the record | Assignment time, response, escalation, and service ownership | Finding sits unowned while the remediation clock appears healthy | Escalate to service and business leadership |
| Temporary mitigation | Control, deployment target, owner, effectiveness test, monitoring, and removal date | Configuration/change record and functional control test | Mitigation is reported as permanent remediation | Move to exception or escalate when the control fails |
| Permanent remediation | Approved corrective action, dependencies, maintenance window, and target | Patch/build/version, configuration diff, commit, replacement, or removal record | Ticket status substitutes for implementation evidence | Escalate blockers before the deadline |
| Verification | Rescan, retest, configuration proof, decommission proof, verifier, and time limit | Tool/method, scope, credentials, content date, result, limitations | Finding disappears because visibility decreased | Reopen on failed or inconclusive verification |
| Exception | Residual risk, constraint, controls, approvals, milestones, review, and hard expiry | Full exception packet and immutable approval history | Indefinite renewal silently closes the finding | Trigger reapproval on KEV, exploit, exposure, control, or role change |
Time-limited exception governance
Carry residual risk transparently—do not disguise it as remediation
A false positive is a validation outcome. An exception is an authorized decision to carry a confirmed, unresolved condition for a defined period under documented controls and oversight.
TraceabilityException ID linked to finding, CVE/check, asset, owner, change, and first-seen records.
ConstraintExact technical, safety, availability, warranty, vendor, funding, or dependency reason remediation cannot occur now.
Residual riskExposure, threat, business consequence, uncertainty, and what remains possible after the temporary control.
Compensating controlControl owner, target assets, configuration, deployment proof, effectiveness test, monitoring, and failure alert.
Permanent planCorrective action, milestones, dependencies, budget or procurement owner, target window, and removal of the temporary control.
ApprovalsRequestor, service/business owner, security reviewer, compliance reviewer when applicable, and authorized risk approver.
Review and expiryApproval date, review cadence, hard expiry, renewal count, evidence date, and escalation route.
Trigger eventsKEV addition, credible exploit, exposure or asset-role change, control failure, compromise evidence, or new obligation.
Rescan, retest, or both
Match closure proof to the condition and corrective action
A negative scanner result is not closure when credentials failed, the asset changed identity, the test omitted the vulnerable interface, or the compensating control merely hid the detection.
All verification cases remain available inside this scroll frame. Use the visible right and bottom scrollbars on smaller screens.
| Finding or response | Primary verification | Coverage controls | Closure evidence | Do not accept |
|---|---|---|---|---|
| Patch or standard configuration change | Authenticated rescan plus installed version or configuration evidence | Same asset, interface, credentials, privileges, current content, and reachable scope | Change record, package/build/configuration, scan result, verifier, and timestamp | Uncredentialed “not detected” result when local evidence was required |
| Web authorization or business-logic flaw | Targeted manual retest; application-aware automation may supplement it | Same role, tenant, object, route, method, prerequisites, workflow, and negative case | Sanitized request/response or equivalent proof and specific retest case | Generic infrastructure rescan as proof of application-logic closure |
| WAF, segmentation, or access-control mitigation | Functional retest of the blocked attack path plus relevant scan | Source/destination, identity, protocol, rule order, bypass paths, logging, and failure mode | Configuration, test result, monitoring, owner, expiry, and permanent plan | Policy screenshot without a functional effectiveness test |
| Penetration-test finding or exploit chain | Repeat the original technique or an equivalent authorized attack path | Same preconditions, privileges, chained steps, data/impact boundary, and safe rules of engagement | Retest narrative, evidence, tester, date, result, and remaining limitation | Closing the chain because one scanner plugin disappeared |
| Asset or service decommissioning | Inventory, discovery, DNS/cloud/configuration, and reachability evidence | All addresses, interfaces, replicas, regions, backups, routes, and replacement assets | Removal/change record and independent evidence that the service no longer operates | CMDB status alone while the asset remains reachable |
| Claimed false positive | Authoritative advisory plus authenticated inspection or other independent technical method | Exact asset instance, build/backport, feature, scanner logic, and review trigger | Original result, evidence, analyst, approval, date, and rationale | Deleting or suppressing the result without preserved evidence |
| High-risk external vulnerability | External rescan and targeted validation; independent review when practical | Same public asset, hostname/address, port, service, TLS/application path, and source perspective | Before/after evidence, change, rescan, retest, verifier, and exposure statement | Internal-only verification of an internet-facing condition |
Equivalent or better visibility is the minimum. A verification scan should use current content, successful expected authentication, stable asset identity, complete job status, and the same affected surface. Open newly discovered findings separately; do not let them erase proof that the original condition was fixed.
Closure states that preserve meaning
Replace one generic “Closed” label with explicit outcomes
Clear states help executives and auditors distinguish corrected risk from temporary mitigation, accepted residual risk, invalid detection, service removal, and failed verification.
Open — Validation PendingConfirmed — AssignedMitigated — Permanent Fix PendingException Active — ExpiringRemediated — Verification PendingRemediated — VerifiedNot Affected — Evidence RecordedFalse Positive — Evidence RecordedAvoided — Removal VerifiedReopened
Audit-ready closure package
Retain enough evidence to reproduce the decision and the verification
Closure evidence should survive scanner changes, ticket migration, staff turnover, audits, and the next recurrence of the same root cause.
Identity and risk
- Stable finding, source, first-seen date, and affected asset/interface
- Owner, environment, business service, exposure, and data/impact context
- Validation evidence, priority tier, internal SLA, and external deadline
- Exception and mitigation history, residual risk, and approvals
Implementation
- Selected risk response and approved corrective action
- Change authorization, deployer, date, and maintenance window
- Patch/build/version, configuration diff, commit, upgrade, replacement, or decommission record
- Predeployment test, operational constraint, and rollback evidence where applicable
Verification and monitoring
- Rescan/retest method, tool, scope, credentials, content date, and timestamp
- Successful result and proof the correction—not visibility—changed
- Verifier or closure approver, remaining limitation, and monitoring
- Root-cause action, related systemic findings, retention location, and reopen trigger
Three realistic closure paths
The same policy must handle urgent, constrained, and compliance-scoped work
These examples demonstrate governance decisions; they do not impose universal deadlines.
Edge appliance with active exploitation evidence
- Validate exact model/version, exposure, and CISA required action.
- Preserve evidence and perform compromise-oriented triage when required.
- Reduce exposure, patch, upgrade, or remove the product.
- Verify version/configuration, rescan externally, and test the exposed service.
- Retain KEV/catalog date, BOD 26-04 applicability when relevant, change, triage, and closure evidence.
Clinical or operational device with no safe immediate fix
- Record safety, vendor-support, availability, and operational constraints.
- Isolate communications, restrict access, strengthen monitoring, and test those controls.
- Approve a time-limited exception with replacement milestones and funding ownership.
- Reassess on KEV status, exploit evidence, control failure, exposure change, or expiry.
- Keep it “Exception Active,” not “Remediated.”
Quarterly scan with findings and follow-up evidence
- Cover all in-scope systems, address vulnerabilities, and rescan affected systems.
- Retain the initial and follow-up reports as a collection showing coverage and resolution.
- Apply PCI DSS critical-patch timing only to applicable in-scope requirements.
- Do not backdate a missed periodic activity or call a later control retroactive compliance.
- Confirm scope and conclusions with the organization’s compliance-accepting entity or assessor.
Metrics that expose program health
Measure the delay and evidence quality behind the headline
Aggregate “percent patched” can hide old, exposed, unowned, or unverified risk. Segment metrics by tier, exposure, asset group, owner, root cause, and verification state.
Validation latency
Median and 90th-percentile time from detection to supported disposition.
Mitigation and remediation time
Separate temporary exposure reduction from permanent correction.
Verification lag
Time from deployment to adequate rescan or retest.
Overdue exploitable risk
KEVs and credible exploitation by exposure and business criticality.
Exception health
Active, expired, repeatedly renewed, missing-control, and overdue milestones.
Authentication failure
Findings and assets whose verification lacks expected local depth.
Reopen and recurrence rate
Failed fixes, recurring configurations, and unresolved root causes.
Closure completeness
Records with required implementation, verification, approval, and monitoring evidence.
Current directive and compliance examples
External clocks must be scoped, current, and recorded separately
Policies change. Verify the live authoritative source and the organization’s applicability before copying a public deadline into a private-sector SLA.
CISA BOD 26-04
- Issued June 10, 2026 for Federal Civilian Executive Branch systems.
- Uses Asset Exposure, KEV Status, Exploit Automation, and Technical Impact.
- Includes dynamic remediation timelines and forensic-triage conditions.
- Superseded and revoked BOD 22-01 and BOD 19-02.
- Not an automatic universal private-sector SLA.
PCI DSS examples
- Requirement 6.3.3 requires applicable critical security patches within one month of release.
- Other patch timeframes are aligned to the entity’s documented risk ranking.
- Vulnerability scanning follows a scan-remediate-rescan cycle for in-scope systems.
- A missed periodic activity cannot be retroactively performed or backdated.
- Applicability remains PCI-scoped; it is not a universal rule for every asset.
Internal policy
- Define organization-approved clocks for every risk tier and response stage.
- Record the external source, scope, due date, and controlling obligation separately.
- Use the faster applicable requirement when an external obligation overrides policy.
- Review changes in exposure, KEV status, exploitability, technical impact, and asset role.
- Never describe an internal target as NIST-mandated.
Reviewed from security and infrastructure perspectives
A remediation SLA must work in governance and in production
Ali Hassani is a CISO and cybersecurity/IT consultant with 25+ years of experience across vulnerability management, network and Microsoft infrastructure, cloud security, compliance auditing, patching, operations, change control, and executive risk decisions. His certifications include CISSP, CCISO, CCNP, CCNA, MCSE, MCSA Security, MCITP, MCP, and MCTS. Review Ali Hassani’s professional background.
Authoritative basis: NIST SP 800-40 Rev. 4 treats remediation as a risk-response lifecycle and supports planned, implemented, verified, and monitored responses. NIST SP 800-53 Rev. 5 uses organization-defined response periods based on risk and calls for remediation, measurement, plans of action, and monitoring.
CISA BOD 26-04 provides the current federal risk-based remediation directive, and its implementation guidance addresses forensic triage and response. It superseded and revoked BOD 22-01 and BOD 19-02 on June 10, 2026.
PCI SSC FAQ 1597 explains current risk-ranking and patch-timing expectations, FAQ 1152 describes the scan-remediate-rescan cycle, and FAQ 1572 explains why a missed periodic activity cannot be retroactively performed.
Guidance limitation: This page provides initial guidance and does not replace a professional cybersecurity audit, vulnerability assessment, penetration test, incident investigation, or legal/compliance review.
Remediation SLA questions
Make the clock, exception, and closure decision explicit
When should a vulnerability remediation SLA clock start?
At the event defined in the approved policy, such as first reliable detection, validation, vendor fix release, KEV addition, or exposure change. Preserve first-seen age and never reset it through duplicates, reassignment, scanner changes, or failed fixes.
Does an approved risk exception mean the vulnerability is closed?
No. It means authorized residual risk is being carried until a defined expiry or trigger event. The unresolved technical condition should retain monitoring, milestones, controls, review dates, and reapproval requirements.
When is a vulnerability rescan enough?
A reliable authenticated rescan may be sufficient for a conventional patch or configuration finding when it reaches the same asset and interface with current content and successful expected credentials. Business logic, authorization, compensating controls, and exploit chains usually need targeted retesting.
Can a compensating control stop the remediation clock?
Only if the approved policy and applicable obligation allow it and the control is implemented, tested, monitored, and formally approved. The state should normally be “Mitigated” or “Exception Active,” not “Remediated.”
What evidence should exist before a vulnerability is closed?
Finding and asset traceability, risk and deadline, implementation proof, change approval, successful rescan or retest, exception history, verifier approval, remaining limitation, monitoring, and a clear reopen trigger.
Are CISA BOD 26-04 or PCI DSS deadlines universal?
No. BOD 26-04 applies to covered Federal Civilian Executive Branch systems, and PCI DSS requirements apply to the relevant payment-card environment and validation scope. Other organizations may adopt aggressive targets, but must identify the actual source and applicability.
Close vulnerabilities with evidence—not optimism
OC Security Audit can help validate findings, design risk-based remediation governance, review exceptions, assess rescan and retest evidence, and determine whether a closure record supports the claimed reduction in risk.