Exceptions & Risk Acceptance

Govern a real security finding when immediate remediation is not appropriate.

Organizations do not fix every security condition immediately. There may be business dependencies, release constraints, legacy applications, compensating controls or documented risk decisions. The important question is not whether risk is ever accepted — it is whether accepted risk remains visible, justified, approved, time-bound and reviewable.

Where to find Exceptions

The current Exceptions view manages accepted-risk requests associated with IAM findings. Exception requests originate from the finding detail view.

Request an exception

The current exception request requires:

Justification

Why is this risk being accepted?

Compensating controls

What reduces the risk while the technical condition remains?

Expiry

When must the decision be reviewed again?

Requested

After submission, the exception is Requested. The finding remains actionable while the request awaits an approval decision.

Finding
  ↓
Request Exception
  ↓
Requested
  ↓
Approval decision

Approve

An authorized approver can approve the request. After approval:

• the exception becomes Accepted risk
• the associated finding becomes exception-approved
• it leaves the immediate active work queue
• the underlying technical condition still exists
• it remains part of gross technical risk

Gross technical risk

This distinction is central to Securitain. A finding can be accepted without being fixed.

Accepted Risk
     ≠
Remediated Risk

An exception-approved finding remains part of gross technical risk until the technical condition is later verified remediated, or the finding is validly classified as false positive.

Compensating controls

A compensating control reduces or manages risk without removing the original condition. Examples include network restrictions, stronger monitoring, approval workflows, limited source ranges and temporary operational safeguards. A compensating control does not erase the original technical finding — it provides context for why the business is accepting the risk.

Expiry

Every exception request requires an expiry in the current workflow. This prevents accepted risk from becoming forgotten indefinitely.

Accepted Risk
    ↓
Expiry date reached
    ↓
Finding returns to Open

Rejected

An exception request can be rejected. A rejection requires a reason. The finding remains actionable. A rejected exception is governance history — not remediation.

Revoked

An approved exception can later be revoked. Revocation:

• ends the accepted-risk decision
• requires a revocation reason
• returns the finding to actionable/Open

Example reasons: compensating control removed, business owner changed, risk posture changed, remediation is now feasible, exception was approved in error.

Expired vs revoked

Both return the technical finding to the active work queue.

Exception status model

The current exception workflow uses five statuses:

Exception vs temporary suppression

Exception vs False Positive

Example: legacy integration

Suppose a production application depends on broader cross-account trust than the security team would normally allow, and immediate remediation could break the application. A governed workflow:

Finding
  ↓
Document legacy dependency
  ↓
Document compensating monitoring
  ↓
Set expiry
  ↓
Request exception
  ↓
Security approval
  ↓
Accepted risk
  ↓
Remediation project before expiry

The technical finding remains visible throughout the accepted-risk period.

Example: release freeze

A high-risk IAM policy is scheduled to be narrowed, but the organization is in a production freeze. A temporary suppression may be more appropriate than a formal long-lived exception — this is why Securitain provides different governance paths.

Reviewing accepted risk

Security leaders should periodically ask:

• Which exceptions are active?
• Which are expiring soon?
• Which findings are Critical or High severity?
• Which accounts contain the accepted risk?
• What compensating controls were documented?
• Who approved the decision?
• Is the justification still valid?

The Exceptions view includes summary context such as Requested, Active (accepted risk), Expiring within 30 days and Expired or revoked.

How to use the exception workflow

1. 1

   Open the finding

   Confirm the condition is real and remediation is not immediately feasible.

2. 2

   Decide whether remediation is currently feasible

   If yes, prefer remediation. Use the exception workflow for genuine governance decisions.

3. 3

   Document justification

   Explain the business and technical reason the risk is being accepted.

4. 4

   Document compensating controls

   State what is in place to reduce the risk while the condition remains.

5. 5

   Set an expiry

   Choose a review deadline — not an indefinite acceptance.

6. 6

   Submit the request

   The exception status becomes Requested pending approval.

7. 7

   Approval decision

   An authorized approver approves or rejects the request.

8. 8

   Track expiring exceptions

   Monitor accepted risk approaching expiry to avoid automatic return to Open without a plan.

9. 9

   Revoke or remediate

   End the exception when it is no longer justified, then follow the remediation workflow.

Evidence and limitations

Exception approval represents organizational risk acceptance. It does not prove:

• the risk is safe
• the finding is technically resolved
• a framework requirement is satisfied
• a compensating control is independently effective

Securitain records the decision and keeps the underlying technical risk visible.

Related guides