# 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*.

<!--
Guidance: How to use this template
- Use one record per exception: one requirement, one scope, one expiry.
  Bundling unrelated gaps into a single request hides risk.
- An exception is a temporary, approved deviation. If the requirement
  is wrong for the whole organisation, change the policy instead
  (security/vulnerability-management-policy and other policies point
  here for the exception route).
- Fill sections 1 to 3 as the requester, sections 4 to 6 with the
  security team, then route to the approver tier in section 7.
- Every approved exception goes into the risk register
  (compliance/risk-register) with the same ID, and its expiry is
  tracked like any other due date.
- The most common pitfall is an exception with no end date. "Until the
  replacement project finishes" is not an expiry: write a calendar date
  and a review trigger.
-->

## Document control

<!-- Guidance: The ID links this record to the risk register, the ticket and any audit evidence. Keep the status current; auditors sample expired and renewed exceptions first. -->

| 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

<!-- Guidance: State in two or three sentences what cannot be done, where, and for how long. A reviewer should understand the request without reading the rest. -->

| 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

<!-- Guidance: Explain why the requirement cannot be met now, what it would cost to comply immediately, and what the business loses if the request is rejected. "Not enough time" without a plan is a weak case. -->

- **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

<!-- Guidance: Describe the inherent risk of the gap using your organisation's risk method (compliance/risk-methodology). Name the threat, the vulnerability and the impact. Use the same likelihood and impact scales as the risk register. -->

| 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

<!-- Guidance: List the controls that reduce the risk while the requirement is not met. Each needs an owner, a way to prove it is working, and a date it is in place. A compensating control that already existed before the request rarely reduces the gap. -->

| 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

<!-- Guidance: Rescore the risk with the compensating controls working. The approver accepts this residual risk, not the inherent one, so make the reasoning for each change explicit. -->

| 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

<!-- Guidance: The security assessor gives an independent view: is the justification real, are the controls enough, is the duration as short as it can be? Record disagreements rather than smoothing them over. -->

| 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

<!-- Guidance: Set the tiers once in your risk management strategy (NIST SP 800-53 PM-9 asks for one) and copy them here. The approver must own the risk and have authority to accept it, which ISO/IEC 27001:2022 clause 6.1.3 ties to risk owners. Bands below match the example method in compliance/risk-methodology; adjust them to your own scale. -->

| 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

<!-- Guidance: Record the decision exactly as made, including any conditions the approver added. A conditional approval is only valid while every condition holds. -->

| 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

<!-- Guidance: Track the exception from request to closure. Renewals are new decisions with fresh evidence, not a date change. Limit the number of renewals in policy. -->

```mermaid
stateDiagram-v2
  [*] --> Draft
  Draft --> InAssessment: submitted
  InAssessment --> Rejected: controls insufficient
  InAssessment --> Approved: tier approver accepts
  Approved --> Closed: requirement met before expiry
  Approved --> Expired: expiry date reached
  Expired --> InAssessment: renewal request
  Expired --> Closed: gap remediated
  Rejected --> [*]
  Closed --> [*]
```

| 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

<!-- Guidance: Keep the terms consistent with the information security policy and risk method. -->

| 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.