Chapter 9 — Exceptions and risk acceptance
Lesson map
Lesson 09 published. Map, example, EX041.
flowchart TD
N0["Learning outcomes"]
N1["9.1 Register"]
N2["9.2 Approval"]
N3["9.3 Review"]
N4["9.4 Reporting"]
N5["Writing a good exception"]
N6["Residual risk reporting"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX041"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["9.1 Register"]
N2["9.2 Approval"]
N3["9.3 Review"]
N4["9.4 Reporting"]
N5["Writing a good exception"]
N6["Residual risk reporting"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX041"]
[Learning outcomes]
|
v
[9.1 Register]
|
v
[9.2 Approval]
|
v
[9.3 Review]
|
v
[9.4 Reporting]
|
v
[Writing a good exception]
|
v
[Residual risk reporting]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX041]
Learning outcomes
You will (1) run an exceptions register; (2) review quarterly; (3) report residual risk.
9.1 Register
Each exception records device, setting, reason, compensating control, owner and expiry. Recording all six fields turns an exception into a decision that can be checked later. The reason explains why the standard cannot be met, the compensating control shows how risk is reduced meanwhile, and the expiry date forces a fresh decision. At Marlowe, the first entries are the two Linux servers with the older library and the two old warehouse PCs without the detection agent. By month six the register holds twelve exceptions, all in date.
9.2 Approval
Business owners approve; IT advises. IT can explain the risk and the options, but the decision to accept a risk belongs to the people who own the business process, such as a warehouse manager for warehouse PCs or the operations director for servers. Seun's approval form asks the owner to confirm they understand the reason, the controls and the expiry date. Each approval is signed and dated, and it is filed in the register beside the exception. IT records its advice on the form, so a later reader sees both views.
9.3 Review
Quarterly reviews renew, close or escalate. At each review, every exception is checked against its expiry date and its reason. An exception is renewed if the reason still holds and the controls are still in place, closed if the device now meets the standard or has been replaced, and escalated to the operations director if the risk has grown or the controls have lapsed. Seun records each decision with the date and the approver, so the register shows its own history.
9.4 Reporting
The register summary goes to the operations director. The summary shows the number of exceptions, how many are in date, which expire before the next review and which have been escalated. This lets the director see whether exceptions are being cleared or are accumulating. Seun includes a sentence on any exception that needs a decision, such as funding a replacement for an old warehouse PC. The summary is part of the evidence pack and is presented with the monthly coverage figures.
Writing a good exception
A good exception explains why the standard cannot be met, what risk remains, how it is reduced and when the situation will change. For the two Linux servers needing an older library, the entry explains the vendor dependency, isolates the servers in their own network segment with only required connections, and sets an expiry linked to the vendor's next release.
Vague entries such as "business need" are sent back for detail.
Seun keeps two good examples in the register's guidance so that owners can see what a complete entry looks like.
Residual risk reporting
Each quarter, Seun summarises exceptions by group and risk score for the operations director: how many exist, how many are overdue and which carry the highest residual risk. This puts all accepted risk in one place, so the director can decide whether to fund faster fixes. Over six months the number of exceptions falls as hardware is replaced and vendors release updates. Exceptions are also reviewed whenever the standard changes, because a new version may resolve an exception, for example by relaxing a setting, or create new ones by adding a requirement some devices cannot yet meet.
Example entries
By month six the register includes the two Linux servers, three old warehouse PCs, one laptop running specialist mapping software that needs an older driver, and six servers awaiting vendor updates. Each has an owner, a compensating control and an expiry date within the next year.
Two earlier exceptions were closed when the vendor released fixes, showing that the register shrinks when actively managed.
The register is small enough to review in half an hour, which keeps the quarterly review realistic for busy owners.
Worked example
Twelve exceptions at month six, all in date.
Synthetic case. Figures are synthetic.
Errors and limits
Exceptions without expiry become permanent.
Exercises
- EX041 — Fields. List six register fields. Rubric: 3 = six;; 2 = five;; 1 = fewer;; 0 = none.
- EX042 — Approver. Who approves exceptions? Rubric: 3 = business owner;; 2 = manager;; 1 = IT;; 0 = none.
- EX043 — Review outcomes. Name three review outcomes. Rubric: 3 = renew, close, escalate;; 2 = two;; 1 = one;; 0 = none.
- EX044 — Expiry. Why must exceptions expire? Rubric: 3 = prevent permanence;; 2 = review;; 1 = vague;; 0 = none.
- EX045 — Month six. How many exceptions at month six? Rubric: 3 = twelve in date;; 2 = twelve;; 1 = vague;; 0 = none.
Synthesis
A governed register makes residual risk visible.
Continue studying — chapter 09 of 12
← Chapter 08 (draft) · Course chapter index · Chapter 10 (draft) →