Security Exception, Waiver & SoD Toolkit — Guide
- Version 1.2
- Updated
- 9 documents
- Word, Excel
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; accepted structural conflicts are named separately) | Zero; each one reported by name |
| Unmitigated SoD conflicts (High, with no compensating control reviewed last quarter) | Zero |
Everything in the pack
- Word
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
- Excel
Security Exception Register
The record of every live exception
- Excel
Segregation of Duties Conflict Matrix
The duty combinations that break most often, ready-made
- Word
Conflict Review Procedure
What to do when you are too small to separate roles
- Excel
Responsibility Matrix
Who requests, assesses, approves and monitors
- Excel
Ageing & Expiry Dashboard
Where expired and repeatedly renewed exceptions pile up
No document matches those words.
Adapting it
- Small organisation: you will not separate every duty, and that is acceptable if each conflict is recorded and checked. A conflict that will last as long as the team stays this size is recorded as an accepted structural conflict (SD-08): decided for at most a year, with a named control reviewer, and not counted as chronic. A temporary conflict stays an exception. An external reviewer can stand in for internal audit. Review High conflicts quarterly and Medium ones every six months. Where no board can decide a Critical exception in time, one named person who is not the requester decides in writing within the same window.
- 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-01 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).