Security Exception, Waiver & SoD Toolkit — Guide
- Version 1.1
- Updated
- Next review
Security Exception & Segregation of Duties Pack
Every organisation has gaps it cannot close today: a server that cannot be patched, a supplier that cannot use multi-factor sign-in, an administrator who both makes changes and approves them. The danger is the gap nobody wrote down, nobody owns and nobody revisits. This pack gives you the documents to record each gap, decide who may accept it, and make sure it ends.
Is this for you?
This pack is for you if:
- people ask you to “sign off” a gap and there is no rule for who may;
- old exceptions sit in email threads with no end date;
- your team is too small to keep every duty separate, and an auditor has noticed.
Why exceptions and duty conflicts belong together
A segregation of duties (SoD) conflict is one person holding two roles that should be kept apart, such as raising a payment and approving it. If you can separate the roles, do. If you cannot, you are accepting a known gap in a control, and that is an exception.
Both need the same things: a named owner, a compensating control, and an end or review date. So this pack runs them through one standard, one approval route and one register.
Start with these three
- Security Exception & Waiver Standard — when an exception may be granted, who approves it and how long it may last.
- Request & Approval Form — asks for enough up front that an approver can decide without a meeting.
- Security Exception Register — every live exception, with owner, compensating control and expiry date.
Each exception is scored for impact and likelihood, 1 to 4 each, after compensating controls. The score sets who approves and how long it may run:
| Score | Band | Who approves | Longest it may run |
|---|---|---|---|
| 1–3 | Low | Control owner | 365 days |
| 4–6 | Medium | Head of Information Security | 180 days |
| 8–9 | High | Head of Information Security and the accountable executive | 90 days |
| 12–16 | Critical | The board or its equivalent: the board, or a board risk committee it has delegated this to; in a two-tier structure, the management board; where there is no board, executive management | 30 days |
A four-week plan
| When | What to do | You’re done when |
|---|---|---|
| Week 1 | Name your approvers in the Standard. List every exception you already know about. | Management has agreed who approves what. |
| Week 2 | Put each known exception through the form, score it and register it with an expiry date. | Nothing lives only in an email. |
| Week 3 | Check who holds which duties in your core systems against the conflict matrix. Separate what you can; record the rest as exceptions. | Every High conflict is removed or recorded. |
| Week 4 | Hold the first monthly register review and run the dashboard. | Management has seen the four numbers below. |
Four numbers to report
| Number | Target |
|---|---|
| Open exceptions by band | Trend down; no unexplained rise in High or Critical |
| Expired exceptions (past expiry, neither closed nor renewed) | Zero High or Critical; below 5% of all open |
| Chronic exceptions (renewed more than the band allows) | Zero; each one reported by name |
| Unmitigated SoD conflicts (High, with no compensating control reviewed last quarter) | Zero |
Everything in the pack
| Document | What it does | Format |
|---|---|---|
| Security Exception & Waiver Standard | The rules management approves | Word |
| Exception Lifecycle Procedure | One exception’s path from request to closure | Word |
| Request & Approval Form | Everything an approver needs, on one form | Word |
| Risk Scoring & Expiry Model | Turns “how risky is this?” into a repeatable score | Word |
| Security Exception Register | The record of every live exception | Excel |
| Segregation of Duties Conflict Matrix | The duty combinations that break most often, ready-made | Excel |
| Conflict Review Procedure | What to do when you are too small to separate roles | Word |
| Responsibility Matrix | Who requests, assesses, approves and monitors | Excel |
| Ageing & Expiry Dashboard | Where expired and repeatedly renewed exceptions pile up | Excel |
Adapting it
- Small organisation: you will not separate every duty, and that is acceptable if each conflict is recorded and checked. An external reviewer can stand in for internal audit. Review High conflicts quarterly and Medium ones every six months.
- Regulated entity (NIS2, DORA): DORA’s technical standards expect your policies to record exceptions and set out how duties are separated. The register and conflict matrix are that record; take the dashboard to your management body.
- IT run by an outside provider: make the provider raise exceptions through your form, and include its administrators in the conflict matrix.
Where it maps
- ISO/IEC 27001:2022 — Annex A 5.36 and 5.3.
- NIST CSF 2.0 — GV.PO-02 and PR.AA-05.
- NIS2 — Article 21(2)(a) and (i).
- DORA — Article 6(4); Delegated Regulation (EU) 2024/1774, Article 2(2)(c) and (g), and Article 21(b).
What changed
Each change to this pack's documents since it was published, newest first.Changes across all packs
Privileged and emergency access is reviewed within 1 working day of use, not 2, the same deadline the privileged access standard sets for break-glass use (SD-06).
- Security Exception & Waiver Standard 1.2 → 1.3
Stage 4 sends a Critical exception to the board or its equivalent, named by how the organisation is governed as the Standard names it, instead of a placeholder for the management body or its risk committee.
- Exception Lifecycle Operating Procedure 1.2 → 1.3
Emergency and privileged access is reviewed within 1 working day of use, not 2, as the Standard now says (SD-06, E4).
Emergency and privileged access is reviewed within 1 working day of use, not 2, as the Standard now says (SD-06).
- Exception & SoD Responsibility Matrix 1.2 → 1.3
A chronic exception is no longer accepted at the next approval level up; management funds the fix or retires the system, or changes the rule first and accepts any remaining risk in the risk register, as the Standard says. The Instructions and the Metric Definitions say so.
- Exception Ageing & Expiry Dashboard 1.1 → 1.2
The Critical band's approver is the board or its equivalent, by how the organisation is governed: the board or a board risk committee it has delegated to, the management board in a two-tier structure, or executive management where there is no board, instead of executive management.
- Guide 1.0 → 1.1
Renewal is due before expiry, and the grace period after expiry is for a late renewal, which is reported (EX-08, EX-10); a gap kept for good means changing the rule first, then accepting any remaining risk in the risk register.
- Security Exception & Waiver Standard 1.1 → 1.2
The grace period after expiry is for a late renewal, which is reported, since renewal is due before expiry; the worked example is returned for a missing remediation date, not for untested control evidence, which is scored with the model's default.
- Exception Lifecycle Operating Procedure 1.1 → 1.2
The Critical signature is the decision of the board or its equivalent, as the band table names it by structure; field guidance says which weak answers return a request and which are scored with the model's defaults.
An unknown input with a default is scored with that default, and a request missing any other input is returned; a gap kept for good means changing the rule first, then accepting any remaining risk in the risk register.
- Exception Risk Scoring & Expiry Model 1.1 → 1.2
The As-at date is a fixed date (the example rows' date) instead of TODAY(), so the example statuses do not change from day to day; adopters set today's date or type =TODAY(). The Critical example is decided by the board risk committee, the top body the Standard names for an organisation with a board.
- Security Exception Register 1.1 → 1.2
A conflicted approver's decision passes to the next level up, as the Standard requires (SOD-EM-02, EX-05); the As-at date is a fixed date (the example rows' date) instead of TODAY(), so the example statuses do not change from day to day.
- Segregation of Duties Conflict Matrix 1.0 → 1.1
Writing and deploying your own code is a High conflict, as the conflict matrix rates it (SOD-IT-05); a rating is lowered only with a recorded reason and a working review.
A chronic exception is fixed, or the rule is changed first and any remaining risk accepted in the risk register; a permanent exception is a rule that no longer reflects policy.
- Exception & SoD Responsibility Matrix 1.1 → 1.2
A Critical exception is decided by the board or its equivalent, named by how the organisation is governed: the board or a board risk committee it has delegated to, the management board in a two-tier structure, or executive management where there is no board. Executive management approves Critical exceptions itself only where there is no board, and a Critical renewal beyond its limit goes to the full board or its equivalent (EX-08).
- Security Exception & Waiver Standard 1.0 → 1.1
Executive management approves Critical exceptions only where there is no board, otherwise taking them to the board or its equivalent, named by how the organisation is governed; a Critical renewal beyond its limit goes to the full board or its equivalent (EX-08); and the note on deciding between meetings speaks of the Critical approver, not the management body.
- Exception Lifecycle Operating Procedure 1.0 → 1.1
The Critical band's approver is the board or its equivalent, named by how the organisation is governed (the board or a board risk committee it has delegated to, the management board in a two-tier structure, or executive management where there is no board), instead of executive management.
The Critical band's approver is the board or its equivalent, named by how the organisation is governed, instead of executive management, and the next level up for a Critical renewal is the full board or its equivalent; the worked example's approver and renewal route read the same way.
- Exception Risk Scoring & Expiry Model 1.0 → 1.1
The band list and the definitions of Approver required and Renewal limit name the Critical approver as the board or its equivalent, named by how the organisation is governed, instead of executive management, and the next level up as the full board or its equivalent.
- Security Exception Register 1.0 → 1.1
The decision on a Critical exception is for the board or its equivalent, named by how the organisation is governed; executive management approves Critical exceptions only where there is no board, and the next level up above Critical is the full board or its equivalent.
- Exception & SoD Responsibility Matrix 1.0 → 1.1
The Critical band's approver is the board or its equivalent, named by how the organisation is governed, instead of executive management.
- Exception Ageing & Expiry Dashboard 1.0 → 1.1
Published. The guide and nine documents, at 1.0.