Risk acceptance in ASPM should record a reason, a named approver who is not the requester, the compensating controls, and an end date after which the item returns for review. An exception without an expiry is a permanent decision made by accident.
What risk acceptance is
Sometimes the right call is not to fix a finding now. The patch breaks something, the component is not exposed, or the fix is scheduled for next quarter. Accepting the risk means a responsible person decides to live with it for a stated period. That decision should be visible and reversible.
Fields every exception needs
| Field | Why |
|---|---|
| Finding and asset | Says what is accepted and where |
| Reason | Gives the future reader the context |
| Compensating control | Names what reduces the risk meanwhile |
| Requester | Who asked |
| Approver | Who said yes, and is not the requester |
| Expiry date | Forces a review |
| Review trigger | Events that reopen it early, such as exploitation news |
Choosing expiry periods
Match the period to the priority. Higher risk items should expire sooner. Ask for a shorter review for anything that appears in the CISA KEV catalog, because CISA describes that catalog as the authoritative source of vulnerabilities exploited in the wild, and the situation can change quickly. Pick specific periods that fit your own risk appetite and write them into the policy, instead of copying a number from an article.
Early reopen triggers
A date is not the only reason to look again. Set the platform to reopen an exception when:
- The vulnerability is added to a known exploitation list.
- A public exploit is reported.
- The exploitation probability published by FIRST in EPSS rises sharply.
- The service becomes internet facing.
- The compensating control is removed.
EPSS publishes a daily probability between 0 and 1 for each CVE, so a jump is easy to detect when the data is imported regularly.
A lightweight approval flow
- Developer or security analyst proposes the exception in the platform.
- The service owner confirms the technical reason.
- A designated approver, such as an engineering director, approves or rejects.
- The platform sets the expiry and a reminder two weeks before.
- On expiry, the item reopens automatically and notifies the owner.
Common pitfalls
- Renewal by default. If every exception is renewed without thought, the expiry is meaningless. Require a fresh reason each time.
- Bulk approvals. Approving fifty items at once shows nobody read them.
- No audit trail. If you cannot show who approved what, auditors and customers will treat the exception as unmanaged.
- Hidden exceptions. Keep accepted items visible in reports, in a clearly labeled group.
Reporting on exceptions
Show leadership the count of active exceptions, how many expire this month, and how many were renewed. A rising renewal rate is an early warning that remediation is stuck.
A worked example of an exception record
Here is a filled in record for a hypothetical case.
| Field | Value |
|---|---|
| Finding | Vulnerable image processing library in the internal reporting tool |
| Reason | Upgrade requires a major version change and a coordinated release next quarter |
| Compensating controls | Tool is behind single sign on and not reachable from the internet; upload feature disabled |
| Requester | Reporting team lead |
| Approver | Engineering director |
| Expiry | End of next quarter |
| Reopen triggers | Added to a known exploited list, tool exposed externally, upload feature re enabled |
A future reader can understand the decision in under a minute. They can also see what would change it.
Step by step: running the monthly exception review
- List exceptions expiring in the next thirty days.
- For each, ask the owner whether the reason still holds and whether the work is scheduled.
- Check whether any reopen trigger has fired, such as new exploitation data.
- Decide: close because fixed, renew with a fresh reason, or escalate.
- Record the decision and the date.
- Report counts to the policy owner.
Linking exceptions to the work
An exception is not a substitute for a plan. Ask each requester to attach a ticket for the eventual fix, with a target date. If there is no plan, say so clearly in the record and ask the approver to decide whether that is acceptable. This stops exceptions from becoming a way of deferring indefinitely.
Levels of approval
Not all exceptions need the same approver. A simple scheme is:
| Priority of finding | Approver |
|---|---|
| Lower | Team lead |
| Medium | Engineering manager and security |
| High | Director level and security |
| Known exploited | Director level, with a short expiry and weekly check |
Adjust this to your organization, and write it into the policy.
Handling customer commitments
If a contract or customer promise sets remediation timelines, an exception may conflict with it. Ask your legal or contracts owner before approving anything that touches a commitment, and record that you did. That review is a business decision, outside the platform.
Where Safeguard fits
Safeguard provides policies, gates and guardrails and compliance and evidence automation, which can record exceptions alongside the decisions that led to them. A free scan is at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Consider which signals should reopen an accepted item.
Quick check
Can the requester approve their own exception?
No. A second person should approve, so the decision is independently checked.
What happens when an exception expires?
The finding returns to the open list and the owner is notified.
Is there a maximum length for an exception?
Set one in your policy. Many organizations cap it at a number of months by priority and require a fresh reason for each renewal.
Sources
Last reviewed: 19 October 2026.
