Residual Risk Acceptance Policy
1. Objective
This policy defines the formal process for accepting residual risk in applications developed or operated by the organisation.
Residual risk is the risk that remains after the security controls defined for the application's criticality level have been applied. Accepting it is not, in itself, a failure - it is an informed management decision, provided that it is formalised, approved by the appropriate approval authority, time-bound and traceable.
The absence of a formal risk acceptance process leads to risk decisions being taken implicitly, without visibility, without assigned responsibility and without a review mechanism.
2. Scope
This policy applies to all situations in which there is identified and accepted residual risk, including:
- Mandatory controls for the criticality level that have not been applied
- Security findings (SAST, DAST, IAST, SCA, fuzzing, pentest) that have not been fixed
- Threats identified in threat modelling for which no mitigation has been implemented
- Architectural exceptions with an impact on the security posture
- Dependencies with known vulnerabilities for which no fix is available or viable
3. Types of residual risk
| Type | Origin | Examples |
|---|---|---|
| Control not applied | SbD-ToE control matrix | Mandatory requirement for the level not implemented |
| Unfixed finding | SAST, DAST, IAST, SCA, fuzzing, pentest | Identified vulnerability without remediation within the SLA |
| Accepted threat | Threat modelling | Documented STRIDE threat without a technical mitigation |
| Architectural exception | Architecture review | Insecure pattern kept because of a technical or business constraint |
| Vulnerable dependency | SCA / SBOM | Active CVE with no fix available or with an impact assessed as acceptable |
4. Criteria for risk acceptance
A residual risk may only be formally accepted if it meets all of the following criteria:
- The risk is compatible with the criticality level of the application (L1, L2 or L3)
- The residual risk is within the defined thresholds for acceptance at the level concerned
- There is sufficient evidence of the controls applied that reduce the risk to the residual level
- A compensating mitigation has been identified and documented, where technically feasible
- The acceptance decision is time-bound - with an expiry and reassessment date
- The decision is formally approved by the approval authority appropriate to the risk level
Risk acceptance does not replace remediation. It is a temporary, documented decision, not a permanent solution. All accepted risk must have an expiry date and a reassessment mechanism.
5. Acceptance thresholds by level
| Level | Maximum severity acceptable without escalation | Maximum acceptance period |
|---|---|---|
| L1 | High (with justification and compensation) | 90 days |
| L2 | Medium without escalation; High requires AppSec approval | 60 days (High: 30 days; Policy 05 §7) |
| L3 | Medium requires AppSec; High requires CISO; Critical is not acceptable | 30 days (High: 14 days; Policy 05 §7) |
Findings of Critical severity may not be accepted as residual risk at any level without an active remediation plan with a defined deadline. Accepting a Critical finding is a last-resort exception, subject to CISO approval and formal recording with a maximum period of 7 days.
6. Acceptance process
6.1 Mandatory steps
- Identify the residual risk - origin, type, severity and technical context
- Assess the impact - the real consequence in the context of the application and the business
- Define a compensating mitigation - an alternative control active during the acceptance period
- Document the technical justification - why the control was not applied or the finding was not fixed
- Define the validity period - expiry date of the acceptance and reassessment date
- Obtain formal approval - by the approval authority appropriate to the risk level (see section 7)
- Record - in the application's exception repository or GRC platform
6.2 Checklist per accepted-risk record
- Unique identifier of the record
- Type of risk (control not applied / finding / threat / architectural exception / dependency)
- Technical description of the risk and its origin
- Assessed severity (Critical / High / Medium / Low)
- Evidence of the existing controls that reduce the risk
- Compensating mitigation defined and active
- Technical and business justification for the acceptance
- Start date of the acceptance
- Expiry date (sunset)
- Risk owner (responsible for follow-up)
- Formal approval (name, role, date)
- Scheduled reassessment date
7. Approval authorities
| Severity | L1 | L2 | L3 |
|---|---|---|---|
| Low | Tech Lead | AppSec Engineer | AppSec Engineer |
| Medium | AppSec Engineer | AppSec Engineer | AppSec Engineer + GRC |
| High | AppSec Engineer | AppSec Engineer + Management | CISO |
| Critical | Not recommended - remediation plan mandatory | Not acceptable without CISO | Not acceptable |
8. Reassessment and expiry
Every accepted-risk record has an expiry date. On the expiry date, the team must:
- Reassess the risk - has the context changed? Is the compensating mitigation still effective?
- Decide: fix / renew the acceptance / escalate
- Renew with new approval if the acceptance is maintained - no automatic renewal
- Record the decision with a new expiry date and updated approval
Expired records without a documented reassessment are treated as unmanaged risk and must be escalated to AppSec.
9. Integration with the development lifecycle
| Moment | Expected action |
|---|---|
| Release / go-live | Check all active accepted risks; confirm that they are within their deadline and approved |
| Sprint review | Review the status of accepted risks with associated findings |
| Risk classification review | Review whether the accepted risks remain compatible with the level |
| Security incident | Check whether any accepted risk contributed to the incident; force immediate reassessment |
10. Artefacts
| Artefact | Suggested location | Retention |
|---|---|---|
| Accepted-risk record | docs/security/risk-acceptance/ or GRC platform | 1 year (L1), 2 years (L2), 3 years (L3) after expiry |
| Evidence of compensating mitigation | Attached to the record | While the risk is active |
| Formal approvals | Attached to the record (PR, issue, signed document) | 1 year (L1), 2 years (L2), 3 years (L3) after expiry |
11. Responsibilities
| Role | Responsibility |
|---|---|
| Developer / Tech Lead | Identify and report residual risks; initiate the acceptance process |
| AppSec Engineer | Assess, validate and approve acceptances; monitor active records |
| GRC / Compliance | Ensure the traceability and compliance of the register; issue periodic reports |
| CISO | Approve high-risk acceptances; oversee the residual risk management programme |
| Product Management | Take part in acceptance decisions with a business impact |
12. Review and audit of this policy
This policy must be reviewed annually or after any of the following events:
- Security incident originating in a previously accepted risk
- Change to the organisation's risk tolerance thresholds
- Regulatory change with an impact on the acceptance criteria
The register of accepted risks must be made available in full in internal and external security audits.
13. Normative and technical references
| Reference | Relevance |
|---|---|
| SbD-ToE Ch. 01 - Application Classification | Risk acceptance criteria by level |
| SbD-ToE Ch. 03 - Threat Modelling | Formal justification of accepted risk in threats |
| SbD-ToE Ch. 10 - Security Testing | Risk acceptance for test findings |
| SbD-ToE Ch. 14 - Governance and Contracting | Formal exception process with approval authorities |
| ISO/IEC 27001 - Clause 6.1.3 | Information security risk treatment |
| NIST SP 800-30 | Guide for Conducting Risk Assessments |
| SSDF PW.4 | Software review for risk management |