Exception Risk Scoring & Expiry Model
Converts a subjective 'how risky is this exception' conversation into a repeatable score that sets both the approval level and the maximum duration.
Available soon
- Format
- Word
- Size
- 62 KB
- Length
- 18 pages
- Version
- 1.1
- Updated
What's inside
- Purpose
- Principles
- Inputs
- Scales and criteria
- Calculation
- Worked examples
- How to defend the method to an auditor
- Limitations
- Calibration and review
- Related documents
- Adapting this template
- Framework references
- Definitions
Preview
The document from section 1, as you will receive it. Highlighted [[text]] is for you to replace; shaded guidance boxes are for you to delete before approval. The cover and document control pages are in the file.
Purpose
This model turns "how risky is this exception?" into a score that two people will reach independently. The score decides three things that would otherwise be argued case by case: who may approve the exception, how long it may run before it ends or is renewed, and how quickly the approver must decide.
It applies the rules of the Security Exception & Waiver Standard: the risk assessment by information security (EX-04), approval authority by band (EX-05), maximum duration by band (EX-06), compensating controls (EX-07) and renewals (EX-08). The Standard says what must happen; this model is the method that produces the numbers those rules depend on.
It is applied to every request made on the Security Exception Request & Approval Form, and the result is recorded against the exception in the Security Exception Register.
Guidance — delete before approval
Keep this model and the Security Exception & Waiver Standard in step. If the bands, approvers or durations change, change them in the Standard and this model in the same approval. Where the two appear to disagree, the Standard wins and this model is corrected.
The model scores exceptions: a known, time-limited gap between what a policy or standard requires and what is actually in place. It is not a replacement for your organisation's wider risk assessment method, and it should use the same idea of impact. See 'Adapting this template'.
Principles
The model rests on six principles. Most questions about why an exception received the score it did are answered by one of them.
- Score the gap, not the system. The question is what could go wrong because this rule is not being met, for as long as it is not met — not how important the system is in general.
- The person who wants the exception does not score it. The requester describes the gap and proposes controls; information security assesses the score (EX-04). This keeps the score independent of the deadline pressure behind most requests.
- The score decides; nobody negotiates it. Once scored, the approver, the longest duration and the decision time follow from one table. An approver may set a shorter duration or refuse, but may not approve outside the band.
- Controls count once, and only when tested. A compensating control that has been shown to work lowers likelihood by one step. It never lowers impact, and several controls together still count as one step (EX-07).
- Every exception ends. Each band has a longest duration and a limit on renewals. What cannot be fixed within them goes up a level, where someone more senior decides whether the organisation keeps living with it (EX-06, EX-08).
- When unsure, round up. A missing fact or a borderline rating always gives the higher level, so gaps in information cost the people who can close them.
Inputs
The inputs come from the request form (Security Exception Request & Approval Form, Part A), checked by information security before scoring. A request missing any of them is returned, not scored.
Input | Question it answers | Where it comes from | If it is not known |
|---|---|---|---|
The rule not met | Which policy or standard clause is not being followed, and what exactly is not done? | Request form; the policy or standard itself | Return the request: an exception needs a named rule |
Scope | Which systems, data and users does the gap affect? | Request form; [[asset inventory]]; [[information classification]] | Use the most important system or most sensitive data that could be affected |
Reachability | Who or what can reach the weakness — the internet, partners, all staff, a few administrators? | Request form; network diagrams; firewall and cloud rules | Treat as internet-facing |
Threat evidence | Is this kind of weakness being used in attacks now? | Information security: vendor advisories, [[threat intelligence source]], the organisation's own incidents | Treat as 'techniques public' (likelihood at least 3 if reachable by many) |
Compensating controls | What reduces the risk while the gap is open, and has it been shown to work? | Request form, with test evidence | No control counts until tested |
Duration | How long is the exception needed, and what is the plan to end it? | Request form: requested end date and remediation plan | Return the request: an exception with no end is not an exception |
Guidance — delete before approval
The 'If it is not known' column is deliberate. A missing input makes the score higher, never lower, so a request with thin information goes to a more senior approver for a shorter time. Requesters quickly learn to supply the facts.
Scales and criteria
Impact and likelihood each have four levels. The anchors below decide the level; where a gap sits between two levels, the higher one is used.
Impact
Impact is the worst credible outcome if the gap were used against the organisation while the exception is open. It is rated for the whole scope of the exception, at its most important system or most sensitive data.
Level | Anchor — use this level when the gap | Examples — replace with your own |
|---|---|---|
1 — Minor | Affects one system of Standard criticality or non-sensitive data; no customer or regulatory effect. | [[e.g. screen lock disabled on a reception visitor kiosk; an old TLS version on an internal test server]] |
2 — Moderate | Affects a High criticality system or internal confidential data; limited, recoverable disruption. | [[e.g. local administrator rights for a developer team; a file server holding internal reports without encryption at rest]] |
3 — Major | Affects a Critical system, personal or customer data, or a regulated service; notifiable if it went wrong. | [[e.g. no multi-factor sign-in on a system holding customer records; an unsupported operating system on a production-line controller]] |
4 — Severe | Could stop a core business service, expose sensitive data at scale, or breach a legal obligation. | [[e.g. a shared administrator account for the email and file-sharing service; backups not isolated from the production network]] |
'Standard', 'High' and 'Critical' criticality are the ratings in [[your asset inventory]]. If your organisation has no such ratings, use: Critical — needed for a core business service or holding regulated data; High — important to a department; Standard — everything else.
Compensating controls never change impact. A measure that genuinely reduces what could be lost — removing the sensitive data from the system, for example — changes the scope of the exception. Re-describe the scope and score it again.
Likelihood
Likelihood is how probable it is that the gap is used against the organisation while the exception is open, given who can reach it and whether the weakness is being exploited elsewhere.
Level | Anchor — use this level when | Examples |
|---|---|---|
1 — Unlikely | Not reachable from the internet or by ordinary users; no known exploitation; strong compensating control in place. | An isolated system reachable only from one administrator workstation, after a tested network restriction. |
2 — Possible | Reachable internally; exploitation needs skill or insider access. | A weakness on an internal server that only staff on the office network can reach. |
3 — Likely | Reachable by many users or from partner networks; exploitation techniques are public. | A weakness in a system every employee signs in to, or one reachable over a partner connection, where attack methods are published. |
4 — Almost certain | Internet-facing or known to be actively exploited, with no effective compensating control. | An internet-facing sign-in page without multi-factor sign-in; a weakness listed as actively exploited. |
Rate likelihood as if the proposed compensating control were not there — with the organisation's ordinary protections, but not the control put forward for this exception. The control is then applied once, in step 4 of the calculation.
Guidance — delete before approval
The anchors for levels 1 and 4 mention compensating controls because they describe where a gap usually ends up: a gap reaches 'Unlikely' only with a strong, tested control, and 'Almost certain' means there is no effective one. Do not count the same control twice — once in the anchor and again under EX-07. Rate before the control; let step 4 apply it.
Compensating controls
A compensating control is a measure that reduces the risk of the gap while it remains open. Under EX-07 it lowers likelihood by one step if, and only if, it is effective — it addresses the way the gap would be used — and tested — there is dated evidence that it works now, not that it was configured.
Counts — effective and tested | Does not count — or not yet |
|---|---|
Access to the system is restricted to named hosts by a firewall rule, and a scan from the general network shows it no longer answers. | A firewall rule has been requested, or 'should' block the traffic. |
Sign-in to a service is limited to the office and VPN addresses, and a sign-in attempt from outside was refused. | Staff have been reminded to use strong passwords. |
Alerts on every use of a shared account go to a named manager, and a test sign-in produced an alert that was received and logged. | The account is 'monitored', with no named recipient and no test. |
A second person reviews every change made with the account, shown by [[the last month's signed review]]. | A review is planned but has not yet happened. |
Controls in the right-hand column may still reduce risk, and belong on the request form. They do not lower the score until tested. Test evidence should be dated after the control was put in place and no more than [[30 days]] before the assessment.
Calculation
The steps
- Confirm an exception is needed and allowed. The request concerns a rule within scope of the Security Exception & Waiver Standard (EX-01) and is not one of the items that may never be excepted (EX-02). If it is, stop: the request is refused, not scored.
- Rate impact from 1 to 4, for the whole scope, using the Impact anchors.
- Rate likelihood from 1 to 4, without the proposed compensating control, using the Likelihood anchors.
- Apply compensating controls (EX-07). If at least one control is effective and tested, lower likelihood by one step. One step at most, and never below 1.
- Score = impact × likelihood after step 4. Read the band from the matrix.
- Read what the band sets: the approver (EX-05), the longest duration (EX-06), the decision time and the number of renewals allowed.
- Set the expiry date. The requested end date or the approval date plus the band's longest duration, whichever is earlier. The owner is reminded 30 days before expiry (EX-09).
The matrix
Steps 2 to 5 give the result below. Impact runs down the side, likelihood (after compensating controls) across the top. Only nine scores are possible: 1, 2, 3, 4, 6, 8, 9, 12 and 16.
Impact ↓ / Likelihood → | 1 Unlikely | 2 Possible | 3 Likely | 4 Almost certain |
|---|---|---|---|---|
4 Severe | 4 Medium | 8 High | 12 Critical | 16 Critical |
3 Major | 3 Low | 6 Medium | 9 High | 12 Critical |
2 Moderate | 2 Low | 4 Medium | 6 Medium | 8 High |
1 Minor | 1 Low | 2 Low | 3 Low | 4 Medium |
What each band sets
Band | Score | Who approves (EX-05) | Longest it may run (EX-06) | Decision within (working days from a complete request) | Renewals within the band |
|---|---|---|---|---|---|
Low | 1–3 | Control owner | 365 days | 5 | 2 |
Medium | 4–6 | Head of Information Security | 180 days | 10 | 2 |
High | 8–9 | Head of Information Security and the accountable executive (risk owner) | 90 days | 10 | 1 |
Critical | 12–16 | 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, such as in an owner-managed company, executive management | 30 days | 5 | 1 |
Longest it may run counts calendar days from the date of approval. The approver may set a shorter period, never a longer one. Decision within counts working days from a complete request: the clock starts when the request has everything the form asks for, so an incomplete request does not use the approver's time. The target is: at least 90% of requests decided within the band's decision time.
Guidance — delete before approval
The Critical band decides faster than the High band on purpose. A Critical gap is one the organisation should not live with for long; it needs a quick decision to fix, contain or accept it — not a queue.
Where the approver for a band is also the requester, the approval goes to the next level up. In a small organisation this happens often: see 'Adapting this template'.
Expiry, renewal and escalation
An exception ends on its expiry date. Before then, the owner either closes it — the gap is fixed — or asks for a renewal. A renewal is a new request on the same form: the gap is scored again with current facts, and the renewal runs for no longer than the band's longest duration, counted from the date the renewal is approved.
Band | Renewals by the band's approver | A further renewal goes to (EX-08) |
|---|---|---|
Low | 2 renewals | Head of Information Security |
Medium | 2 renewals | Head of Information Security and the accountable executive (risk owner) |
High | 1 renewal | 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, such as in an owner-managed company, executive management |
Critical | 1 renewal | [[the full board, or its equivalent]] |
- Reminder — the owner is reminded 30 days before expiry (EX-09).
- Expired — an exception past its expiry date, neither closed nor renewed, must be remediated, renewed or escalated within 10 working days (EX-10). It is reported as expired until then.
- Chronic — an exception renewed more times than its band allows (EX-08) is reported by name to management (EX-12). A renewal beyond the band's limit goes to the next approval level up (EX-08).
- Band change — if the new score at renewal falls in a different band, the new band's approver, duration and renewal limit apply. Renewals already used still count.
Rules for applying the model
SM-01 The score is assessed by information security from the request and its evidence (EX-04). The requester may propose ratings; information security sets them and records the reason for each.
SM-02 Impact and likelihood are rated for the whole scope of the exception, at its most important system, most sensitive data and most exposed point. Where an exception covers several systems with different exposure, the worst one is scored. Splitting one exception into several lower-scoring ones to reach a more junior approver is a breach of the Standard.
SM-03 Where a fact is not known, the default in the Inputs section applies. Where a rating falls between two levels, the higher level applies.
SM-04 Likelihood is rated without the proposed compensating control. EX-07 then applies once: one step lower for effective, tested controls, whatever their number, and never below 1. Compensating controls never lower impact.
SM-05 A control counts as tested only with dated evidence that it works, taken after it was put in place. Evidence older than [[30 days]] at assessment, or at renewal, is refreshed before the control counts.
SM-06 The approver may refuse, shorten the duration or add conditions, but may not approve an exception outside the band's authority or for longer than the band allows.
SM-07 If a compensating control relied on under EX-07 is removed or stops working, the exception is scored again at once without it. If the new band allows a shorter duration, the expiry date is brought forward to the approval date plus the new band's longest duration; if that date has passed, the exception is expired (EX-10). The new band's approver decides within the new band's decision time.
SM-08 The exception is scored again at every renewal, and whenever its facts change — its scope grows, the weakness is reported as exploited, or a control changes. A higher score takes effect at once; a lower score takes effect at the next renewal.
SM-09 Renewals are counted over the whole life of the exception. Scoring it again, changing band or changing owner does not reset the count.
Guidance — delete before approval
SM-07 matters most. Exceptions are often approved on the strength of a control that is quietly removed months later — a firewall rule reverted during a change, an alert rule disabled because it was noisy. The monthly register review (EX-11) should ask, for each exception relying on a control, when it was last shown to work.
Worked examples
The organisations, systems and dates are illustrative. Each score below is calculated by the same rules as the matrix.
Example 1 — unsupported operating system on an isolated production-line computer
Step | Request: keep a production-line control PC on an operating system its vendor no longer supports, until the line is replaced |
|---|---|
Rule not met | [[Patch and vulnerability management standard]]: operating systems must be vendor-supported. The PC runs software certified only for that operating system. |
2. Impact | The line is a Critical system for the business: if the PC were compromised, production stops. → 3 — Major. |
3. Likelihood | Before isolation, the PC sits on the plant network used by [[80]] staff and contractors, and attacks on this operating system are widely published. → 3 — Likely. |
4. Controls | The PC was moved to its own network segment, reachable only from one engineering workstation, with no internet access. Evidence: the firewall rule export and a scan from the plant network, dated the week before the assessment, showing no response. Effective and tested → likelihood lowered one step. |
5–6. Result | Score 3 × 2 = 6 → Medium. Approver: Head of Information Security. Longest it may run: 180 days; 2 renewals within the band. |
7. Dates | Complete request received and scored on 21 October 2026; decision due by 4 November 2026. Approved on 2 November 2026 → expires no later than 1 May 2027; reminder on 1 April 2027. |
Without the control | Had the isolation not been tested, the score would be 9 — High: two approvers and at most 90 days. The test moved the decision down one level. |
Example 2 — a shared administrator account at a small firm
Step | Request: two IT staff and the outsourced IT provider share one administrator account for the email and file-sharing service |
|---|---|
Rule not met | [[Access Control Policy]]: every administrator uses a named, personal account. The firm's licence covers one administrator account until the renewal of its subscription. |
2. Impact | The account controls every mailbox and file of a [[20]]-person firm holding clients' personal and financial data. Misuse could expose it all, and breach the firm's legal duties. → 4 — Severe. |
3. Likelihood | The administration portal is reachable from the internet. The account has multi-factor sign-in, but the second factor is shared by three people and credential theft is common. → 3 — Likely. |
4. Controls | Every sign-in and every administrator change on the account sends an alert to the managing director, who is not an administrator. A test sign-in on [[date]] produced the alert within five minutes. Effective and tested → one step lower. |
5–6. Result | Score 4 × 2 = 8 → High. Approver: Head of Information Security and the accountable executive (risk owner). Longest it may run: 90 days; 1 renewal within the band. |
Who signs | The firm's IT manager holds the Head of Information Security role, but is one of the three users of the account — so is not independent. The firm's Security Exception & Waiver Standard names [[the finance director]] to sign in that role when the IT manager is the requester; the managing director signs as the accountable executive. |
Renewal | One renewal is allowed within the High band. If named accounts are not in place after that, the next renewal goes to 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, such as in an owner-managed company, executive management (EX-08) — in practice, the partners' meeting. |
Example 3 — multi-factor sign-in not enforced on a software service, with and without a tested control
Step | Request: the sales team's customer relationship service cannot enforce multi-factor sign-in on the current subscription |
|---|---|
Rule not met | [[Access Control Standard]]: multi-factor sign-in on every internet-facing service holding personal data. |
2. Impact | The service holds [[12,000]] customer contact records and sales notes. → 3 — Major. |
3. Likelihood | The sign-in page is on the internet, and password-guessing attacks against such services are constant. → 4 — Almost certain. |
4a. First request | The requester offered "a strong password policy and staff reminders". Neither changes how the gap would be used, and neither was tested. No step lower → Score 3 × 4 = 12 → Critical. Approver: 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, such as in an owner-managed company, executive management. Longest it may run: 30 days; 1 renewal within the band. |
4b. Resubmitted | The service's own setting was used to accept sign-ins only from the office and VPN addresses. A sign-in attempt from a mobile network on [[date]] was refused. Effective and tested → one step lower. |
5–6. Result | Score 3 × 3 = 9 → High. Approver: Head of Information Security and the accountable executive (risk owner). Longest it may run: 90 days; 1 renewal within the band. |
What changed | Testing one real control moved the request from Critical to High: from 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, such as in an owner-managed company, executive management and 30 days to two named approvers and up to 90 days. The remediation plan — upgrading to a subscription with single sign-on by [[date]] — fits within that. This example is completed in full at the end of the Security Exception Request & Approval Form. |
Example 4 — a small gap that stays small
Step | Request: disable the screen lock on the reception visitor kiosk, which shows only the visitor sign-in page |
|---|---|
Rule not met | [[End-User Device Standard]]: screens lock after [[5]] minutes of inactivity. |
2. Impact | A kiosk account with no access to internal systems or personal data beyond the day's visitor list. → 1 — Minor. |
3. Likelihood | Reachable by anyone in reception, but only to the sign-in page. → 2 — Possible. No compensating control proposed; none needed for the band. |
5–6. Result | Score 1 × 2 = 2 → Low. Approver: Control owner. Longest it may run: 365 days; 2 renewals within the band. |
Point | Not every exception needs senior time. A Low exception is decided by the control owner in days, and the register still shows it, with its expiry. |
How to defend the method to an auditor
An auditor examining how exceptions are handled will usually test two things. First, that the organisation's risk criteria produce consistent, valid and comparable results when applied again (ISO/IEC 27001 clause 6.1.2) and that the chosen treatment was approved by the right person (clause 6.1.3). Second, that departures from the organisation's own policies are known, approved and reviewed (Annex A 5.36). This model is designed to show both.
Evidence to have ready
- The approved Security Exception & Waiver Standard and this model, with matching bands, approvers and durations.
- The Security Exception Register, showing for each exception its impact, likelihood before and after controls, score, band, approver, approval date and expiry date.
- For each exception relying on a compensating control: the test evidence and its date (SM-05).
- The calibration record (see 'Calibration and review'), including the results of the test cases.
- The quarterly management report (EX-12) with the four headline numbers: open exceptions by band; expired exceptions; chronic exceptions; unmitigated SoD conflicts.
The re-derivation test
Invite the auditor to pick [[10]] exceptions from the register. For each, take the recorded impact, likelihood and control test, and read the band from the matrix. Every result should match the recorded band and approver, and every expiry date should fall within the band's longest duration from its approval date. Run this test yourself each quarter, so the first time is not in front of the auditor.
Questions auditors commonly ask
Question | Answer the model gives |
|---|---|
Who decides the score, and are they independent? | Information security, not the requester (EX-04, SM-01). The reason for each rating is recorded, so a reviewer can disagree with a specific judgement rather than with the result. |
Why can't a strong control reduce the score further? | Because controls fail, and approvals outlive them. One step (EX-07) recognises a real control without letting a stack of partial controls make a serious gap disappear. SM-07 re-scores the exception if the control stops working. |
How do you stop exceptions becoming permanent? | Every band has a longest duration and a renewal limit. Beyond the limit the decision moves up a level (EX-08), and chronic exceptions are reported by name to management (EX-12). |
What about risks you have simply accepted? | An exception is a time-limited acceptance of a specific gap. A risk the organisation chooses to accept permanently belongs in the risk register, with the risk treatment approval that clause 6.1.3 expects — not in an exception renewed for ever. |
Is the 4 × 4 scale fine enough? | It is deliberately coarse. It is used to decide authority and duration, where consistency matters more than precision. The calibration section shows that different assessors reach the same band. |
Limitations
No scoring model is complete. These are the known weaknesses of this one, and how they are managed.
Limitation | Effect | How it is managed |
|---|---|---|
Ratings are judgements. | Two assessors can disagree by a level, which can change the band. | Anchors and examples; 'round up' (SM-03); reasons recorded (SM-01); quarterly re-derivation and two-assessor calibration. |
Multiplying ordinal numbers is a convention, not arithmetic. | A 2 × 4 and a 4 × 2 both score 8, although a severe, unlikely gap and a moderate, almost certain one are different risks. | Both land in the High band, with the same approver and duration — which is the only use the score is put to. The ratings themselves are recorded, not just the product. |
Exceptions are scored one at a time. | Several Medium exceptions on the same system can together give an attacker a path that none shows alone. | The monthly register review (EX-11) looks for clusters on one system or owner. A cluster found there is scored as one exception, at its worst system (SM-02). |
Test evidence ages. | A control shown to work in March may not work in June. | Evidence is refreshed at renewal (SM-05); a failed control triggers a new score (SM-07). |
The model does not weigh cost. | An expensive fix and a cheap one receive the same duration. | The remediation plan on the form states the cost and the date; the approver may shorten the duration where the fix is cheap. |
Impact anchors are general. | They may not fit a sector with its own harm criteria — patient safety, market integrity. | Replace the anchors with your organisation's own risk criteria, keeping four levels (see 'Adapting this template'). |
Calibration and review
Before approval
- Score every exception you already know about — including those living in email — with this model.
- Count them by band. If more than a quarter land in High or Critical, check the impact anchors against your organisation's own risk criteria before approval, not afterwards.
- Have two people score the same [[10]] requests independently. Every difference of a band shows an anchor that needs clearer wording or a better example.
- Check that the approvers named for each band have agreed to the volume and decision times this will give them.
Every quarter
Information security reviews the following alongside the quarterly management report (EX-12), and records the result. The signals are prompts to investigate, not targets.
Check | Signal that the model needs attention |
|---|---|
Open exceptions by band | A rise in High or Critical without a known reason (target: trend down; no unexplained rise in High or Critical). |
Decisions within the band's decision time | Below the Standard's target (at least 90% of requests decided within the band's decision time). |
Controls relied on under EX-07 | Controls found not working at the monthly review, or test evidence older than the limit in SM-05. |
Disputed scores | More than [[1 in 10]] requests where the requester or approver challenged the score, or the same challenge recurring. |
Incidents | Any incident that used a gap covered by an exception, and the score that exception had. |
Re-derivation test | Any exception whose recorded band cannot be reproduced from its ratings. |
Calibration test cases
Use these cases to train assessors and to check any spreadsheet or tool that applies the model, including the register. Each must give the expected band.
Case | Impact | Likelihood before controls | Tested control | Score | Expected band | What it tests |
|---|---|---|---|---|---|---|
1 | 1 | 1 | No | 1 × 1 = 1 | Low | The lowest score |
2 | 1 | 3 | No | 1 × 3 = 3 | Low | Minor impact, likely: still Low |
3 | 1 | 4 | No | 1 × 4 = 4 | Medium | Minor impact, almost certain: Medium |
4 | 2 | 2 | No | 2 × 2 = 4 | Medium | Two moderate ratings: Medium |
5 | 3 | 2 | Yes | 3 × 1 = 3 | Low | A tested control lowers likelihood from 2 to 1 |
6 | 4 | 1 | Yes | 4 × 1 = 4 | Medium | A control cannot take likelihood below 1 |
7 | 2 | 4 | Yes | 2 × 3 = 6 | Medium | One step only, however many controls |
8 | 3 | 3 | No | 3 × 3 = 9 | High | Major and likely: High |
9 | 4 | 3 | No | 4 × 3 = 12 | Critical | Severe and likely, no tested control: Critical |
10 | 4 | 4 | Yes | 4 × 3 = 12 | Critical | Severe, almost certain, tested control: still Critical |
Review
This model is reviewed with the Security Exception & Waiver Standard, at least every 12 months, and also when: the organisation's own risk criteria change; an incident exploits a gap under an exception; the quarterly checks show a signal twice running; or the approvers named in the Standard change.
Calibration record
Date | Reviewed by | Exceptions sampled | Mismatches found | Change proposed | Approved by |
|---|---|---|---|---|---|
[[YYYY-MM-DD]] | [[Name]] | [[n]] | [[n]] | [[None / description]] | [[Name]] |
Related documents
Document | Relationship |
|---|---|
Security Exception & Waiver Standard | Sets the rules this model applies: EX-04 to EX-10, and the approvers for each band |
Exception Lifecycle Operating Procedure | The steps in which a request is scored, decided, reminded, renewed and closed |
Security Exception Request & Approval Form | Collects the inputs (Part A) and records the score (Part B) and the decision (Part C) |
Security Exception Register | Records each exception's ratings, score, band, approver and expiry |
SoD Conflict Review & Compensating Control Procedure | Uses this model to score segregation-of-duties conflicts that cannot be separated |
Exception Ageing & Expiry Dashboard | Reports exceptions by band, and those expired or renewed too often |
[[Risk Management Methodology]] | The organisation's wider risk criteria, which this model should match |
Adapting this template
Guidance — delete before approval
Small organisation: keep the matrix, the one-step rule (EX-07) and the durations unchanged — they are what an auditor tests. Name real people for each band: in a firm of [[20]], the control owner may be the IT manager, the Head of Information Security role may be held by the IT manager or an external adviser, and executive management may be the owners or partners. Where the approver is also the requester or a user of the gap, name who signs instead (see Example 2). Run the calibration checks every six months rather than quarterly.
Regulated entity (NIS2, DORA): approve this model within your ICT risk management framework, so the exception scores form part of your documented risk criteria. DORA's technical standards expect ICT security policies to record exceptions and to keep resilience assured while they exist: the register built from this model is that record. Consider rating any gap affecting a system that supports a critical or important function, or an essential or important service under NIS2, at impact 3 or above, and taking Critical exceptions to the management body itself.
IT run by a service provider: the provider raises its exceptions on your form and supplies test evidence for its controls, but information security in your organisation sets the score. Put the bands and durations in the service agreement, so the provider knows in advance how long a gap in its service may be tolerated.
If your organisation already has a risk matrix, replace the anchors here with its criteria, keeping four levels of each so the bands still work. Do not keep two different matrices in use.
Delete this section before approval.
Framework references
These references show where this document supports an external framework. They indicate relevance only and do not reproduce the text of any standard. Editions referenced: ISO/IEC 27001:2022 incl. Amd 1:2024; NIST CSF 2.0; Directive (EU) 2022/2555 (NIS2); Regulation (EU) 2022/2554 (DORA); Delegated Regulation (EU) 2024/1774.
Framework | Reference | Supported by |
|---|---|---|
ISO/IEC 27001:2022 | Clause 6.1.2 — Information security risk assessment | Scales and criteria; calibration and review; how to defend the method |
ISO/IEC 27001:2022 | Clause 6.1.3 — Information security risk treatment | What each band sets: approval of the chosen treatment |
ISO/IEC 27001:2022 | Annex A 5.36 — Compliance with policies, rules and standards for information security | Whole model: departures from policy approved and reviewed |
NIST CSF 2.0 | GV.RM-06 — “A standardized method for calculating, documenting, categorizing, and prioritizing cybersecurity risks is established and communicated” | Whole model: a standard way to calculate and categorise exception risk |
NIST CSF 2.0 | ID.RA-06 — “Risk responses are chosen, prioritized, planned, tracked, and communicated” | Calculation; expiry, renewal and escalation |
Definitions
Term | Meaning in this model |
|---|---|
Band | One of the four ranges of score — Low (1–3), Medium (4–6), High (8–9), Critical (12–16) — each with its own approver, longest duration, decision time and renewal limit. |
Chronic exception | An exception renewed more times than its band allows (EX-08). |
Compensating control | A measure that reduces the risk of a gap while it remains open. Under EX-07, an effective and tested one lowers likelihood by one step. |
Exception | An approved, time-limited decision that a rule in a policy or standard need not be met in a stated scope, with a named owner, compensating controls and an expiry date. Also called a waiver in the Security Exception & Waiver Standard. |
Expired exception | An exception past its expiry date that has been neither closed nor renewed. |
Impact | The worst credible outcome if the gap were used while the exception is open, rated 1 to 4. |
Likelihood | How probable it is that the gap is used while the exception is open, rated 1 to 4, before and after compensating controls. |
Renewal | A new decision to extend an exception past its expiry date, made on a new request and a new score. |
Score | Impact multiplied by likelihood after compensating controls: one of 1, 2, 3, 4, 6, 8, 9, 12 or 16. |
Tested | Shown to work by dated evidence taken after the control was put in place (SM-05). |