Security Exception Request: [Exception title]
Request, assessment and decision record for a time-limited exception
to a security policy, standard or control, with the residual risk
formally accepted by the right person. It records the requirement
that cannot be met, the business reason, the risk with and without
compensating controls, the approver tier, the expiry date and the
exit plan. Structure aligned with the risk treatment and risk
acceptance requirements of ISO/IEC 27001:2022 (clauses 6.1.3 and
8.3, cited by number only) and with NIST SP 800-53 Rev. 5 (Release
5.2.0) controls PM-9 Risk Management Strategy and RA-7 Risk Response.
Replace every [bracketed] value and every row marked Example.
Document control
| Field | Value |
|---|
| Exception ID | [EXC-YYYY-NNN] |
| Version | [0.1] |
| Status | [Draft / In assessment / Approved / Rejected / Expired / Closed / Renewed] |
| Requester | [@requester], [team] |
| Asset or service owner | [@owner] |
| Security assessor | [@security-assessor] |
| Risk register ID | [RSK-NNN] |
| Requirement source | [Policy or standard name, section] |
| Requested start date | YYYY-MM-DD |
| Expiry date | YYYY-MM-DD |
| Classification | [Internal / Confidential] |
| Last updated | YYYY-MM-DD |
Approvals
| Role | Name | Decision | Date |
|---|
| Security assessor | [@name] | [Recommend approve / Recommend reject] | YYYY-MM-DD |
| Risk owner (approver tier from section 7) | [@name] | [Accept residual risk / Reject] | YYYY-MM-DD |
| CISO or delegate (Tier 2 and above) | [@name] | [Decision] | YYYY-MM-DD |
Revision history
| Version | Date | Author | Change summary |
|---|
| 0.1 | YYYY-MM-DD | [@name] | Request raised |
| 1.0 | YYYY-MM-DD | [@name] | Example: Approved at Tier 2 with three compensating controls |
| 1.1 | YYYY-MM-DD | [@name] | Example: Mid-term review, controls confirmed effective |
1. Request summary
| Item | Value |
|---|
| Requirement not met | Example: Secure Configuration Standard SCS-4.2: operating systems in production must be on a vendor-supported release |
| Scope (assets, environments, data) | Example: Two warehouse label-printing servers (wh-lbl-01, wh-lbl-02) running an operating system that left vendor support, in the Kestrel Row distribution centre of Norrowind Retail |
| Data handled | Example: Shipping labels: customer name and delivery address |
| Duration requested | Example: 2026-11-02 to 2027-03-31 (149 days) |
| Type | [Policy exception / Standard exception / Control deviation / Audit finding risk acceptance] |
| First request or renewal | [First / Renewal number N of EXC-ID] |
2. Business justification
- Reason the requirement cannot be met: Example: The label-printing software is certified by the carrier only on the current operating system. The certified version for the supported release ships in January 2027.
- Impact of immediate compliance: Example: Switching off the servers stops outbound parcel labelling at one site, about 18,000 parcels a day.
- Alternatives considered and why rejected: Example: Manual labelling (error rate and staffing), moving labelling to another site (capacity), running uncertified software (carrier contract breach).
- Exit plan: Example: Upgrade to the certified software and the supported operating system in change CHG-2027-014, target 2027-02-28, with one month of contingency before expiry.
3. Risk without the exception controls
| Field | Value |
|---|
| Threat scenario | Example: An attacker on the warehouse network exploits an unpatched operating system flaw on a label server and moves laterally to the order database |
| Vulnerabilities | Example: No security updates from the vendor; known exploitable flaws published after end of support |
| Likelihood (1 to 5) | Example: 3 |
| Impact (1 to 5) | Example: 4 |
| Inherent risk score (likelihood x impact) | Example: 12 (High) |
| Affected objectives | [Confidentiality / Integrity / Availability], Example: all three |
4. Compensating controls
| Control ID | Control | Owner | Evidence of operation | In place by |
|---|
| CC-01 (Example) | Servers moved to an isolated network segment, allow-list of two inbound flows (print queue, management jump host) | [@network-lead] | Firewall rule export, quarterly segmentation test | 2026-11-02 |
| CC-02 (Example) | Application allow-listing enforced in block mode on both servers | [@endpoint-lead] | Weekly policy compliance report | 2026-11-02 |
| CC-03 (Example) | Enhanced logging forwarded to the SIEM with a detection rule for new processes and outbound connections | [@soc-lead] | Detection rule ID and last test date (security/detection-rule-spec) | 2026-11-09 |
5. Residual risk
| Field | Value |
|---|
| Residual likelihood | Example: 2 (segmentation and allow-listing remove most attack paths) |
| Residual impact | Example: 4 (impact on the label data and site operations is unchanged) |
| Residual risk score | Example: 8 (Medium) |
| Within risk appetite? | Example: Yes, Medium is acceptable for up to six months with Tier 2 approval |
| Conditions that void the exception | Example: Any compensating control fails for more than 72 hours, or a flaw affecting the system is listed in CISA KEV |
6. Security assessment
| Question | Assessor answer |
|---|
| Is the requirement correctly identified? | [Yes / No, comment] |
| Is the scope as narrow as possible? | [Answer] |
| Are the compensating controls proportionate to the gap? | [Answer] |
| Is the duration the shortest workable? | [Answer] |
| Does this exception combine with others on the same assets? | [List EXC-IDs or "None"] |
| Recommendation | [Approve / Approve with conditions / Reject] |
7. Approver tiers
| Tier | Residual risk | Maximum duration | Approver |
|---|
| Tier 1 (Example) | Low (1 to 4) | 12 months | Asset owner plus security assessor |
| Tier 2 (Example) | Medium (5 to 9) | 6 months | Business unit head plus CISO or delegate |
| Tier 3 (Example) | High (10 to 16) | 3 months | Executive risk committee |
| Not permitted (Example) | Critical (20 to 25), or a legal or contractual obligation | Not applicable | Not approvable: treat or stop the activity |
The worked example has a residual score of 8, so it sits in Tier 2, and its 149-day duration is inside the six-month limit.
Exceptions to requirements that come from law, regulation or contract (for example PCI DSS for card data, or a regulator's rule) usually cannot be accepted internally. Ask your legal or compliance team which route applies; this template is not legal advice.
8. Decision and conditions
| Field | Value |
|---|
| Decision | [Approved / Approved with conditions / Rejected] |
| Conditions | Example: Monthly status update on CHG-2027-014 to the CISO |
| Approved expiry date | Example: 2027-03-31 |
| Review dates | Example: 2027-01-15 (mid-term), 2027-03-01 (pre-expiry) |
| Plan of action reference | Example: POA-2026-077 (NIST SP 800-53 CA-5 tracking) |
9. Lifecycle
| Event | Date | By | Note |
|---|
| Mid-term review (Example) | 2027-01-15 | [@security-assessor] | CC-01 to CC-03 evidence checked, all effective |
| Closure (Example) | 2027-03-02 | [@owner] | Upgrade done in CHG-2027-014, scan confirms supported release |
10. Glossary and references
| Term | Meaning |
|---|
| Exception | Approved, time-limited deviation from a stated requirement |
| Compensating control | Alternative measure that reduces the risk the original requirement addressed |
| Residual risk | Risk remaining after the compensating controls are applied |
| Risk owner | Person accountable for a risk and authorised to accept it |
| Risk appetite | Amount of risk the organisation is willing to accept to meet its objectives |
References (check the current official versions):
- ISO/IEC 27001:2022 Information security management systems, Requirements, with Amd 1:2024, clauses 6.1.2 (risk acceptance criteria), 6.1.3 (risk treatment and risk owner acceptance of residual risk) and 8.3 (implementing risk treatment). Official text: ISO, purchase or licensed access: https://www.iso.org/standard/82875.html
- NIST SP 800-53 Rev. 5, Release 5.2.0: PM-9 Risk Management Strategy, RA-7 Risk Response, CA-5 Plan of Action and Milestones, PM-4 Plan of Action and Milestones Process: https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final
- Related templates: compliance/risk-register, compliance/risk-methodology, compliance/risk-treatment-plan, compliance/information-security-policy, compliance/statement-of-applicability, security/vulnerability-management-policy, ops/change-request
Standard and licence note
Structure aligned with ISO/IEC 27001:2022 (with Amd 1:2024) clauses
6.1.2, 6.1.3 and 8.3, cited by number only; no text of the standard is
reproduced. Official text: ISO, purchase or licensed access at
https://www.iso.org/standard/82875.html. Based on NIST SP 800-53 Rev. 5
(Release 5.2.0) controls PM-9, RA-7, CA-5 and PM-4, a US government
publication. The template text, tiers and examples are original; all
organisations, systems and figures are fictional. Check the current
official versions before use. Template licence: MIT.