Vulnerability acceptance and exception management
on the engagement record, not in a forgotten spreadsheet
Some findings will not be remediated on the standard SLA. The risk is accepted with a compensating control, the fix is deferred to a planned release, or the remediation cost exceeds the residual exposure. Run the acceptance workflow on the engagement record so every accepted exception carries a named owner, a documented rationale, an expiry date, and a review cadence. Accepted risk that drifts into permanent exposure is the failure mode this workflow exists to prevent.
No credit card required. Free plan available forever.
Run vulnerability acceptance and exception management on the engagement record
Some findings will not be remediated on the standard SLA. The risk is accepted with a compensating control, the fix is deferred to a planned release, the cost outweighs the residual exposure, the asset is on a retirement path, or the issue lives inside a vendor product the buyer cannot directly fix. Exceptions are part of any mature vulnerability programme; the question is whether each one carries the audit trail that lets the firm defend the decision a year later, or whether it sits in an email thread nobody can find.
SecPortal records every exception against the persistent finding identifier on the findings record so the lineage survives report regeneration and retest cycles. The eight required fields are captured before review; routing follows residual severity rather than original severity; the exception sits visibly on the branded client portal alongside the finding; renewals land as new versions against the same finding so the history is reconstructable. The exception register reads as audit evidence rather than as a folder of approvals nobody revisits.
Exception management is the deferred-risk track for findings on live assets. When the underlying asset is gone (a cloud account closed, a repository archived, a domain expired, a workload migrated, a service reached end-of-life), the finding belongs on the asset decommissioning and finding retirement workflow instead. Mixing retirement into the exception register lets dead-asset findings sit there forever; keeping the two workflows separate means audits read each as the right kind of decision rather than blurring disposition into deferred risk.
Six exception classes the workflow has to recognise
Exceptions are not a single category. The rationale, the compensating mechanism, and the review cadence vary by class, and a workflow that treats them uniformly produces records that audit cannot read. Naming the classes up front means the firm and the client share a vocabulary for which kind of exception is on the table.
Compensating-control acceptance
The vulnerability stays in place but a layered control reduces the residual risk to a level the business is willing to carry. Common patterns are WAF rules in front of an application bug, network segmentation in front of an unpatched service, or session policies in front of an authentication weakness. The exception names the control, the residual likelihood and impact after the control applies, and the trigger that would invalidate the control (rule disabled, segmentation removed, policy relaxed).
Time-bound deferral
The fix is planned but cannot ship inside the current SLA window. The deferral is bounded by an explicit expiry tied to a release, sprint, or hardware refresh date. A deferral with no expiry is not a deferral; it is a silent acceptance the audit will read as an unmanaged exposure. The expiry is the contract that converts deferral into either a closed finding or an escalation by a date the business agreed to up front.
Cost-versus-residual acceptance
The fix is feasible but the cost of remediation outweighs the residual risk after compensating controls. Examples are deeply embedded library upgrades on legacy services scheduled for retirement, or retrofits on systems with limited business value remaining. The exception names the cost-versus-residual rationale, the retirement or replacement path, and the review trigger that would force reassessment if the underlying assumptions change.
Vendor-dependency acceptance
The vulnerability lives inside a vendor product or a managed service the buyer cannot directly remediate. The exception names the vendor advisory status, the case number opened with the vendor, the compensating control applied while the vendor patches, and the review cadence aligned to the vendor remediation timeline. A finding marked as a vendor issue with no follow-up is the most common path to a stale exception in a register that nobody reads.
Out-of-scope reclassification with residual visibility
The finding belongs to an asset, environment, or third-party dependency outside the engagement scope. Rather than dropping the finding silently, the exception records why it sits outside scope, the owner who carries the residual risk (often a different team or a vendor), and the visibility path so the asset owner sees the finding even though the engagement does not remediate it. The finding stays in the engagement record for lineage rather than disappearing.
Risk-transferred acceptance
The residual risk is transferred to a third party through contract, insurance, or a service-level agreement. Common patterns are cyber insurance covering a specific class of breach, or a vendor contract that puts liability on the vendor rather than the buyer. The exception names the transfer mechanism, the policy or contract reference, the coverage limits, and the trigger that would force the buyer to absorb the risk again (policy cancellation, contract change, coverage exclusion).
Where exception management usually breaks down
Six failure modes recur whenever exceptions are treated as a side document rather than as a record-level event on the finding. Each failure mode is invisible at the time and visible at the next audit, retest, or post-incident review.
The exception lives in an email thread
A senior engineer asks the security lead "are we okay if we leave this for now?" and the lead replies "yes for the next quarter, document it." Three months later nobody can find the email, the finding is open in the queue, and the audit asks for the documented acceptance. The reconstruction reads weaker than the contemporaneous record would have, and the firm loses the credibility of the original decision.
No expiry, no review cadence
An exception is approved with no expiry date and no review trigger. The finding sits in an exception status indefinitely; the owner moves teams; the compensating control is silently disabled during a refactor. By the time anyone notices, the residual risk profile bears no resemblance to the one originally approved. Permanent exceptions are the slowest path to a critical incident.
Routing every exception to the CISO
A flat routing rule sends every exception request to the head of security regardless of residual severity. The CISO becomes the bottleneck, low-residual exceptions wait weeks for sign-off, and engineering teams stop bothering to file exceptions for genuinely small risks. The work moves into shadow acceptance: findings stay open without status because the queue feels worse than the silence.
Compensating controls without proof
An exception names a WAF rule, a network segmentation, or a monitoring alert as the compensating control without naming the rule ID, the segment policy, or the alert query. When the exception is reviewed later, no one can verify the control is still in place. A control named generically is a control that may or may not exist; the audit reads the absence of proof as the absence of the control.
Acceptance recorded against the report rather than the finding
A spreadsheet lists "accepted findings" by report ID rather than by finding ID. Two retests later the finding numbering has changed, the spreadsheet rows do not map cleanly, and the lineage from the original acceptance to the current finding is broken. The fix is recording the acceptance against the persistent finding identifier so it survives report regeneration and retest cycles.
The client portal hides the exception from the client
An exception is approved internally but the client portal still shows the finding as open with no visible exception status. The client either does not realise the firm has accepted the risk on their behalf (governance gap) or sees the finding sit untouched and loses confidence in the queue. The fix is surfacing the exception status visibly alongside the finding so both sides read the same record.
Eight fields every exception has to capture before review
A defensible exception is eight concrete fields on the finding record, not an abstract approval. Anything missing from the list below is a known gap in the audit trail rather than something a reviewer will spot in time.
Linked finding identifier
The persistent finding ID this exception applies to. Recording against the finding rather than against the report means the exception survives report regeneration, retest cycles, and version reissues without the lineage breaking.
Plain-language risk summary
A two-sentence description of the risk in business language. The summary is what a non-technical approver reads to decide whether the residual risk is acceptable; if the summary needs CVSS jargon to make sense, the finding has not been translated for the approver.
Original CVSS severity and vector
The original CVSS 3.1 vector and base score on the finding before any compensating controls apply. The vector lets a reviewer see the attack-surface assumptions (vector, complexity, privileges, interaction, scope, impact) rather than just the headline number.
Compensating controls and proof
The specific controls reducing the residual risk, named precisely (WAF rule ID, network segmentation policy reference, alert query, session timeout configuration). Each control names the proof that demonstrates it is active; a control without proof is a claim, not a control.
Residual likelihood and impact
The residual risk after compensating controls apply, on the firm risk scale (low / medium / high / critical). The residual feeds the routing decision (who approves) and the review cadence (how often the exception is revisited). Approving without recording the residual is the most common cause of routing failures.
Business rationale
The reason the business accepts the residual risk, documented in non-technical terms. Common rationales are scheduled retirement, dependency on a vendor patch cycle, cost-versus-residual trade-off, or scope misalignment. The rationale is what the audit reads to decide whether the acceptance was reasoned or merely permitted.
Expiry date and reassessment trigger
The date by which this exception expires unconditionally and the events (retest, vendor patch, asset retirement, contract change) that would trigger reassessment before the expiry. Exceptions without expiry dates become permanent risk; exceptions without reassessment triggers miss the events that should have closed them earlier.
Approver record and rationale
The named approver, the date of approval, and the rationale they recorded against the decision. The approval is recorded against the specific exception request, not against the report or the engagement generically; later audit reads can point at the approver and the rationale rather than reconstructing the decision from memory.
Vulnerability acceptance and exception management checklist
Before any exception is approved and after every renewal or closure, the engagement lead and the requesting owner walk through a short checklist. Each item takes minutes; missing any one of them is the source of the failure modes above and the audit gaps that follow.
- Every exception is opened against a specific finding identifier rather than against the report or the engagement.
- The eight required fields are captured before review (finding, summary, severity, controls, residual, rationale, expiry, reassessment trigger).
- Routing follows residual severity, not original severity, so the right approver sees the right exceptions.
- Compensating controls name the specific rule, policy, or configuration so a reviewer can verify the control is still active.
- The expiry date is on the exception record itself, not in a separate calendar or reminder system.
- The review cadence (quarterly, semi-annually, on retest) is recorded and triggers a fresh review at the cadence interval.
- Approvers read and approve specific exceptions, not generic "accepted findings" lists.
- The branded client portal shows the exception status visibly alongside the finding for the engagement.
- Renewals land as new exception versions against the same finding so the history is reconstructable.
- Closure (because the fix shipped) lands as a status event on the finding and the exception, not as a silent deletion.
- No exception lives only in an email thread; the email is supplementary to the record, not the record itself.
- Out-of-scope findings sit as exceptions with residual-visibility status rather than being silently dropped.
How exception management looks in SecPortal
Exception management is one workflow stitched into four feature surfaces: the findings record, the engagement record, the branded client portal, and team management for the approval routing. The work that has to happen at each stage is the same work the platform already supports for everyday findings operations; the exception lifecycle just makes the decision and its review cadence explicit.
Exception opens against the finding
Acceptance starts as a state event on the findings record, not in an email thread. The eight required fields are captured before the request reaches review, and the request itself is a record-level event with a timestamp and named requestor.
Routing follows residual severity
The residual likelihood and impact after compensating controls feed the routing decision. Critical and high residual route to a senior approver; medium routes to the engagement lead; low routes to the application owner. Routing on residual rather than original severity puts each decision at the authority level that should be making it.
Approver record is provable
Approvals land against the specific exception request, with the named approver, the date, and the rationale. Role-based access in team management controls who can approve at which severity tier, so the approval authority structure is enforced rather than implied.
Expiry and review cadence on record
Each exception carries an expiry date and a review cadence directly on the record. The review cadence triggers fresh review at the cadence interval; the expiry triggers either renewal or closure. Exceptions cannot become silently permanent because the record itself drives the review schedule.
Visible on the branded client portal
The exception sits visibly on the finding inside the branded client portal, so the client and the firm read the same record. The client sees the residual exposure rather than a finding that quietly slipped out of the queue, and the engagement lead does not have to repeat the rationale every status meeting.
Renewals land as new versions
When an exception reaches expiry or hits a review trigger, the renewal lands as a new version against the same finding rather than as a fresh exception with no history. The previous version remains accessible for audit so the trail from first acceptance through every renewal reads as one continuous record.
What auditors expect from a vulnerability exception register
Vulnerability acceptances show up in audit evidence whenever an external assessor reads the security programme. The frameworks below all expect a recorded register of accepted risks with rationale, residual analysis, named approver, and review cadence rather than a spreadsheet of approvals nobody revisits.
| Framework | What the audit expects |
|---|---|
| ISO 27001:2022 | Annex A 5.7 (threat intelligence) and Clause 6.1.3 (information security risk treatment) expect documented decisions on how each identified risk is treated, including formally accepted risks with named owner and reassessment plan. Vulnerability acceptances recorded against findings with the eight required fields satisfy the risk treatment evidence directly; verbal acceptances do not. |
| SOC 2 | Common Criteria CC9.1 (risk mitigation) expects the entity to mitigate risks from identified vulnerabilities or document the rationale for accepting them. Recorded exceptions with compensating controls, residual analysis, approver, and review cadence are the artefacts CC9.1 audits read; an exception register without expiry dates and review evidence reads as a process gap. |
| PCI DSS | Requirement 6.3 (vulnerability management) and 12.3 (compensating controls) expect compensating controls to be documented, reviewed annually, and tied to a specific business or technical constraint. Acceptances that name the constraint, the control, the residual risk, and the review cadence fit the compensating control worksheet expectations cleanly. |
| NIST SP 800-39 | NIST SP 800-39 (managing information security risk) expects risk acceptance decisions to be made at the right level of authority and recorded with rationale, residual risk, and reassessment plan. Routing on residual severity rather than original severity puts the decision at the right authority level; recording the rationale, residual, and reassessment plan satisfies the documentation expectation. |
| NIST SP 800-53 | Control RA-3 (risk assessment) and PM-9 (risk management strategy) expect risk responses including risk acceptance to be documented, tracked, and reassessed at defined intervals. Exceptions with expiry dates and review cadences feed the control evidence; a register that holds approvals but does not show review activity over time reads as incomplete. |
Where exception management sits across the vulnerability lifecycle
Exception management composes with the rest of the vulnerability lifecycle on the same engagement record so the lineage of every accepted risk stays connected to the work that produced the finding and the work that will eventually retest it.
Upstream and adjacent
Exception management depends on remediation tracking naming the SLA the exception is deferring against, on vulnerability SLA management for the deadline policy and breach escalation chain the exception sits beside, and on finding dispute resolution for cases where the request is really a severity dispute rather than a true acceptance. It feeds retesting because retest cycles surface accepted findings for fresh review.
Document and report linkage
The risk acceptance form template is the document artefact that records one acceptance at one point in time; the security exception register template is the org-wide ledger that lists every approved exception in one place; report version control keeps the exception status reflected in each report version so the deliverable matches the live record.
Pair the workflow with the long-form guides and the framework references
Exception management is operational; the surrounding guides explain the prioritisation logic that decides which findings warrant acceptance in the first place and the framework clauses that mandate the register. Pair this workflow with the vulnerability prioritisation framework for the upstream decision logic, the vulnerability management programme guide for the broader programme context, and the aging pentest findings research for what unmanaged exceptions cost over time. For supplier-side findings where the upstream vendor publishes a not-affected exploitability assertion, the VEX guide explains how the four CISA status values and the five not-affected justifications turn into an audit-defensible disposition that either suppresses the finding outright or feeds the exception register at a lower trust tier when the supplier statement cannot be fully relied on. The framework references that mandate the register include ISO 27001 for risk treatment evidence, SOC 2 for risk mitigation under CC9.1, PCI DSS for compensating control documentation under requirement 12.3, and NIST for SP 800-39 risk management documentation expectations.
Buyer and operator pairing
Exception management is the workflow dedicated vulnerability management teams run alongside their backlog, internal security teams run alongside vulnerability assessments, and compliance consultants run on behalf of clients. vCISOs carry the approver role for residual-critical and residual-high decisions, and consulting security consultants run the workflow on behalf of clients who do not have an internal exception process yet.
What good vulnerability acceptance feels like
No silent exceptions
Every accepted risk is a record-level event with eight required fields, a named approver, and a review cadence. Exceptions cannot live in an email thread because the request itself is a record event. Silent acceptance simply does not happen because silence does not register a state change on the finding.
Audit-ready register
ISO 27001, SOC 2, PCI DSS, and NIST audits can read a register that names the rationale, the residual analysis, the approver, and the review cadence on every exception. The register is the artefact the audit expects rather than a reconstructed list assembled the week before the assessor visits.
Exceptions do not become permanent
The expiry date is on the record; the review cadence triggers fresh review at the cadence interval; retest cycles touch the underlying finding and force reassessment. Exceptions stay accepted only as long as the rationale still holds, not as long as nobody happens to look.
Approval authority matches residual
Routing on residual severity puts each decision at the authority level that should be making it. The CISO is not the bottleneck for low-residual exceptions; the application owner is not signing off critical residuals on their own. The approval flow matches the risk the firm is actually carrying.
Vulnerability acceptance and exception management is the workflow that decides whether deferred risk stays visible or quietly drifts into permanent exposure. Run it on the engagement record, and every accepted exception carries the audit trail from first request through approval, periodic review, and either renewal or closure that the firm and the audit both expect.
Frequently asked questions about vulnerability acceptance and exception management
What is vulnerability acceptance and exception management?
Vulnerability acceptance and exception management is the workflow that captures, approves, tracks, and reviews findings the business has chosen not to remediate on the standard SLA. The workflow records the linked finding, the residual risk after compensating controls, the named owner, the rationale, the expiry date, and the review cadence. The goal is for every accepted exception to carry an audit trail from the first request through approval, periodic review, and either renewal or closure.
How is exception management different from a risk acceptance form?
A risk acceptance form is the document artefact that captures one acceptance at one point in time. Exception management is the lifecycle workflow around the form: who can request, who approves, how the request is routed, where it sits while it is open, when it is reviewed, and how it closes or renews. The form is the record; the workflow is how the record gets created, reviewed, and updated over time. Both are needed; the form alone without the workflow turns into a folder of approvals nobody revisits.
Why does routing on residual severity matter more than original severity?
Original severity tells the business how bad the finding is unmitigated. Residual severity (after compensating controls apply) tells the business how bad the finding is given what is actually in place. Routing every original-critical exception to the CISO regardless of residual creates queue pressure on the highest authority and slows acceptance for low-residual exceptions; routing every original-low to the application owner regardless of residual misses cases where compensating controls do not actually reduce the risk much. Residual severity routes the request to the authority level that should be making the call.
What goes wrong when exceptions have no expiry date?
Exceptions without expiry become permanent. The compensating control silently degrades during a refactor; the owner moves teams; the asset is retired and the exception is forgotten on the new replacement; the assumption underlying the original acceptance is no longer valid. Permanent exceptions are the slowest path to a critical incident because the residual risk slowly drifts away from the residual the approver actually approved. The expiry is the contract that forces a fresh look at the exception while the original context is still recoverable.
How often should approved exceptions be reviewed?
Three signals drive review cadence. Critical and high residual: quarterly. Medium residual: semi-annually. Low residual: annually or on retest of the underlying finding. Three event-based triggers also force review regardless of cadence: the expiry date arrives, a retest cycle touches the finding, or the asset materially changes (technology refresh, scope expansion, ownership transfer). Cadence-driven reviews catch slow drift; event-driven reviews catch material change.
How are exceptions tracked when findings are renumbered between reports?
Exceptions are recorded against the persistent finding identifier on the engagement record, not against a report-specific finding number. When the report regenerates or a retest delta lands as a new report version, the finding identifier stays the same, the exception still references the same record, and the lineage from original acceptance through retest does not break. Recording acceptances against report numbers rather than findings is a common cause of broken exception lineage.
What about findings the firm cannot remediate because the vendor owns the fix?
Vendor-dependency acceptances are a recognised exception class. The exception names the vendor advisory status, the case number with the vendor, the compensating control applied while the vendor patches, and the review cadence aligned to the vendor remediation timeline. The compensating control is what the firm operates today; the vendor patch is the planned closure path. A vendor-dependency exception with no review cadence becomes a stale acceptance the moment the vendor ships the patch and the firm does not notice.
How should compensating controls be documented?
Each compensating control names the specific rule, policy, or configuration that reduces the residual risk: the WAF rule ID, the network segment policy reference, the monitoring alert query, the session timeout setting. Generic descriptions ("we have a WAF") are claims, not controls. The control description should be specific enough that a reviewer six months later can verify it is still active without asking the original author to remember the configuration.
Should clients see exceptions on findings in the branded portal?
Yes. The exception status on a finding is information the client needs alongside the finding itself. Hiding the exception from the client portal creates a governance gap (the client does not see the residual exposure) or a confidence gap (the finding looks open with no progress). Surfacing the exception status visibly, with the linked rationale and expiry date, gives the client and the firm the same view of the engagement.
How does SecPortal support vulnerability acceptance and exception management?
SecPortal records exceptions against persistent finding identifiers on the engagement record so the lineage survives report regeneration and retest cycles. Each exception captures the eight required fields, lands as a state event on the finding, and routes review based on residual severity. The exception sits visibly on the branded client portal alongside the finding so both sides see the same record. Renewals land as new versions against the same finding; closure is a deliberate status event rather than a silent deletion. SecPortal does not write the rationale for the firm; it makes auditable, lifecycle-aware exception management the path of least resistance.
How it works in SecPortal
A streamlined workflow from start to finish.
Open the exception against the finding, not in a side document
Acceptance starts at the finding itself. The requestor (engineering lead, application owner, or business stakeholder) opens an exception request against the specific finding with a one-line summary of what they are asking to accept and why. The request lands as a state event on the finding rather than as an email thread, so the audit trail starts from the first request rather than from the eventual approval.
Capture the eight required fields before review
A defensible exception names eight fields: linked finding ID, plain-language risk summary, original CVSS severity, proposed compensating controls, residual likelihood and impact after controls, business rationale, expiry date, and review cadence. Missing fields block the request from reaching review. Frameworks like NIST SP 800-39, ISO/IEC 27005, and SOC 2 CC9.1 read this record more than the approval signature.
Route review to the right approver based on residual severity
Critical and high residual severities route to a senior approver (CISO, head of security, named risk owner). Medium residual routes to the engagement lead or product security lead. Low residual routes to the application owner. Routing on residual severity rather than original severity stops every exception ending on the CISO desk and stops low-severity exceptions skipping a named approver.
Approve, reject, or return for more evidence
The approver reads the eight fields and one of three outcomes lands on the exception: approved with the recorded rationale, rejected with the reason, or returned for evidence (compensating control proof, business case, residual impact analysis). Approval is a deliberate action against the specific exception request, not a forwarded email. The audit trail records who approved what, when, and on what basis.
Track the exception alongside the finding through expiry
An approved exception is never the end state. The finding stays open with an exception status, the expiry timer counts down, and the review cadence (quarterly, semi-annually, on retest) surfaces the exception for re-review. The branded client portal shows the exception alongside the finding so the client and the firm both see the open exposure rather than a finding that quietly slipped out of the queue.
Reassess on retest, expiry, or material change
Three triggers force a fresh review: the expiry date arrives, a retest cycle reaches the underlying finding, or the asset materially changes (technology refresh, scope expansion, ownership transfer). The reassessment either renews the acceptance with a fresh rationale, closes it because the fix has shipped, or escalates it to remediation if the residual risk has shifted. Every renewal lands as a new exception version against the finding so the history is reconstructable later.
Manage vulnerability acceptances and exceptions on the engagement record
Capture rationale, owner, expiry, and review cadence on every accepted exception. The audit trail is provable rather than implied. Start free.
No credit card required. Free plan available forever.