Exception Lifecycle Operating Procedure
Describes the end-to-end path of a single exception from request through approval, monitoring, renewal and closure.
Available soon
- Format
- Word
- Size
- 60 KB
- Length
- 16 pages
- Version
- 1.1
- Updated
What's inside
- Purpose
- Scope
- Roles
- Triggers and inputs
- Procedure steps
- Decision points
- Outputs and records produced
- Timing targets
- Escalation
- Evidence retained
- 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 procedure sets out how a single security exception moves through [[Organisation Name]], from the moment someone finds they cannot meet a security requirement to the moment the exception is closed with evidence. It is the working routine behind the Security Exception & Waiver Standard: the Standard says what the rules are; this procedure says who does what, in which order, by when, and what record each step leaves.
It answers three questions for every exception: who decides it and on what score, who keeps it under control while it is open, and what evidence allows it to be closed.
Scope
This procedure applies to:
- every exception request under the Security Exception & Waiver Standard, whatever its source — a remediation deadline that will be missed, a control that cannot be implemented, a supplier that cannot meet a security clause, or a segregation of duties conflict that cannot be separated (SD-04);
- everyone with a role in the table below, including service providers who request exceptions for systems they operate for us.
It does not cover how conflicts in the Segregation of Duties Conflict Matrix are found and reviewed (the SoD Conflict Review & Compensating Control Procedure), how the risk score is worked out in detail (the Exception Risk Scoring & Expiry Model), or obligations that cannot be excepted at all (EX-02), which leave this procedure at step 5.
Guidance — delete before approval
Keep the scope identical to the Standard's. If another standard has its own exception clause — for example, the vulnerability management standard — it should route requests into this procedure rather than run a parallel one.
Roles
Role | What they do in this procedure |
|---|---|
Requester [[e.g. system owner, project lead]] | Raises the request, runs the compensating controls, delivers the remediation plan, answers reminders, requests renewal or closure, and provides closure evidence. |
Risk owner [[the accountable business executive for the affected service]] | Confirms on the request that they accept the residual risk. Co-approves High exceptions and presents Critical ones. Receives reminders and expiry notices. |
Control owner [[e.g. IT Operations Manager]] | Confirms the requirement and the compensating control. Approves Low exceptions, unless they are also the requester. |
Information security [[e.g. Security Analyst, acting for the Head of Information Security]] | Keeps the register. Checks completeness, scores the request, routes it to the approver, sends reminders and expiry notices, runs the monthly review and verifies closure evidence. |
Head of Information security [[e.g. Head of Information Security]] | Approves Medium exceptions and co-approves High ones. Decides disputed scores. Receives escalations. |
Executive management [[e.g. Executive Committee or its risk committee]] | Approves Critical exceptions where the organisation has no board; otherwise takes them to the board or its equivalent, as the approval bands set out. Approves renewals escalated beyond their band (EX-08). |
Guidance — delete before approval
In a small organisation the information security role and the Head of Information Security may be one person. That is acceptable, but that person must not approve an exception they requested, or one to a control they operate themselves (EX-05); the approval goes up a level.
Triggers and inputs
When this procedure runs
Trigger | What starts | Steps |
|---|---|---|
Someone foresees, or discovers, that a security requirement will not or is not being met (EX-01) | A new request | 1 to 15 |
The monthly register review (EX-11) | Checks on every open exception | 16 to 19 |
30 days before an exception expires (EX-09) | Reminder, and a decision: close, renew or let lapse | 20 to 21 |
The requester asks to extend an exception | Renewal | 22 to 26 |
An exception passes its expiry date without being closed or renewed (EX-10) | Expiry handling | 27 to 30 |
The requirement is met, the system is retired or the requirement changes | Closure | 31 to 34 |
Inputs
Input | Where it comes from | Used for |
|---|---|---|
The completed request | Security Exception Request & Approval Form or [[exception workflow]] | Everything that follows |
The requirement not met | [[Policy, standard or contract, with rule or clause number]] | Checking the request is a valid exception (EX-02) |
Asset and data information | [[Asset inventory]] | Impact score; the risk owner |
Evidence that the compensating control works | Requester; [[test results, configuration exports, logs]] | Likelihood score (EX-07) |
The register | Security Exception Register | History, renewal count, duplicates, expiry dates |
The scoring model | Exception Risk Scoring & Expiry Model | Impact, likelihood, band |
Procedure steps
The bands this procedure works to
These are the bands in the Security Exception & Waiver Standard, repeated for convenience; the Standard governs if the two ever differ. Decision time counts in working days from a complete request; maximum duration counts in calendar days from approval.
Band | Score | Approver | Decision time | Maximum duration | Renewals |
|---|---|---|---|---|---|
Low | 1–3 | Control owner | 5 working days | 365 days | Up to 2 |
Medium | 4–6 | Head of Information Security | 10 working days | 180 days | Up to 2 |
High | 8–9 | Head of Information Security and the accountable executive (risk owner) | 10 working days | 90 days | Up to 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 | 5 working days | 30 days | Up to 1 |
Stage 1 — Request
Step | What happens | Who | Output |
|---|---|---|---|
1 | Identify that a security requirement will not be met, or is not being met. Request the exception before the breach where it can be foreseen, and within [[5 working days]] of discovery where it cannot (EX-01). | Requester | Decision to request |
2 | Complete the Security Exception Request & Approval Form with every field in EX-03: requirement and rule number, systems affected, reason, compensating controls and how they will be checked, remediation plan with dates, duration requested. Attach evidence that each existing compensating control works. | Requester | Draft request |
3 | Obtain the risk owner's confirmation that they accept the residual risk, and the control owner's confirmation of the requirement and the compensating control. | Requester; risk owner; control owner | Request with confirmations |
4 | Submit the request to information security through [[the exception mailbox or workflow]]. | Requester | Request submitted |
Stage 2 — Triage and completeness
Done by information security within [[2 working days]] of submission. The band's decision time does not start until the request is complete.
Step | What happens | Who | Output |
|---|---|---|---|
5 | Check the request is a valid exception. Reject it, with the reason, if it asks to except anything EX-02 forbids: a legal, regulatory or contractual obligation; the Standard itself; an open-ended duration; backdated approval; or unnamed systems. Route a legal or regulatory issue to [[the compliance or legal escalation process]]. | Information security | Rejected request, or accepted for triage |
6 | Give the request a reference in the form EX-YYYY-nnn (for example EX-2026-004) and enter it in the Security Exception Register with status Requested, so refused requests are also recorded (EX-11). Check the register for an existing exception on the same requirement and systems: a repeat is a renewal (stage 8), and several requests that together cover one weakness are assessed as one. | Information security | Register entry; reference |
7 | Check every EX-03 field is present. Return an incomplete request to the requester, stating what is missing. Record the date the request became complete: the decision clock starts then. | Information security | Complete request, date recorded |
Stage 3 — Risk assessment
Step | What happens | Who | Output |
|---|---|---|---|
8 | Score impact and likelihood, each 1 to 4, using the Exception Risk Scoring & Expiry Model. Score the worst affected system. Discuss the proposed score with the requester and risk owner; they may comment but not set it (EX-04). | Information security | Impact and likelihood |
9 | Check the compensating control. It lowers likelihood by one step only if it is in place and has been tested; a planned control does not count; it never lowers impact (EX-07). | Information security | Likelihood after control; test evidence referenced |
10 | Record the score, the band, the approver, the maximum duration and the decision due date. If the approver would be the requester, or the operator of the control, route it to the next level up (EX-05). | Information security | Assessment in the register |
Stage 4 — Approval by band
Step | What happens | Who | Output |
|---|---|---|---|
11 | Send the request and assessment to the band's approver: Low to the control owner; Medium to the Head of Information security; High to both the Head of Information security and the risk owner as accountable executive; Critical to [[the management body or its risk committee]], presented by the risk owner. | Information security | Approval request with due date |
12 | Decide in writing: approve, approve with a shorter duration or conditions, or refuse. Set the expiry date, no later than the band's maximum from the approval date (EX-06), and preferably the remediation plan's date. | Approver | Written decision with expiry date |
13 | If no decision has been made by the due date, escalate to the next approval level up. Silence is never approval (EX-05). | Information security | Escalation |
Guidance — delete before approval
A Critical exception has a 5 working days decision time. If your Critical approver meets only monthly, agree now how it decides between meetings — by written procedure, or by delegating Critical decisions to a named committee.
Stage 5 — Registration
Step | What happens | Who | Output |
|---|---|---|---|
14 | Update the register: status Approved (or Refused), approver, approval date, expiry date, reminder date, renewal count 0, conditions, compensating controls and the remediation plan's milestones. For a segregation of duties conflict, reference the conflict in the Segregation of Duties Conflict Matrix. | Information security | Register entry complete |
15 | Tell the requester, risk owner and control owner the decision, the expiry date, the reminder date and any conditions. For a refused request, the requirement applies in full, and a breach is reported as a breach. | Information security | Decision notice |
Stage 6 — Monitoring and compensating control checks
Done at the monthly register review (EX-11), for every open exception.
Step | What happens | Who | Output |
|---|---|---|---|
16 | Check each compensating control is still in place and working: ask for current evidence for every High and Critical exception, and for a [[sample]] of the others. | Information security; requester provides evidence | Control check recorded |
17 | Check the remediation plan against its milestones. A missed milestone is recorded, and discussed with the requester and risk owner. | Information security | Progress recorded |
18 | Re-score any exception whose facts have changed — a control removed, new exposure, active exploitation. If the band rises, send it to the new band's approver within the new band's decision time, and bring the expiry date forward if the new band's maximum from the original approval date is shorter. | Information security; approver for the new band | Updated score; re-approval if needed |
19 | Prepare the figures for the quarterly report (EX-12) with the Exception Ageing & Expiry Dashboard: open exceptions by band, expired exceptions, chronic exceptions and unmitigated conflicts. | Information security | Review record; report figures |
Stage 7 — Reminders
Step | What happens | Who | Output |
|---|---|---|---|
20 | Send the reminder 30 days before expiry to the requester and risk owner (EX-09), or on approval for an exception approved for 30 days or less. Ask which it will be: closed, renewed, or allowed to lapse with the requirement met. | Information security | Reminder sent |
21 | If there is no reply within [[10 working days]], remind again and copy the approver. | Information security | Second reminder |
Stage 8 — Renewal
Step | What happens | Who | Output |
|---|---|---|---|
22 | Request renewal before expiry with an updated request: current state of the compensating controls with fresh evidence, progress against the remediation plan, the reason it is late, and the new date. | Requester; risk owner confirms | Renewal request |
23 | Re-assess the score (steps 8 to 10). A renewal is scored as a new request. | Information security | Updated assessment |
24 | Check the renewal count against the band's limit. Within the limit, route to the band's approver. Beyond it, route to the next level up (EX-08) — the Medium approver for a Low exception, and so on; for a Critical exception, [[the full board, or its equivalent]]. | Information security | Approval request, right level |
25 | Decide as in step 12. The new expiry date counts from the renewal approval date and is no later than the band's maximum. | Approver | Renewal decision |
26 | Update the register: new expiry and reminder dates, renewal count increased by one, updated score. Mark it chronic if it is now renewed more times than its band allows (EX-08). | Information security | Register updated |
How many renewals each band allows before a renewal must go up a level:
Band | Renewals by the same approver | Beyond that, decided by |
|---|---|---|
Low | 2 | Head of Information Security |
Medium | 2 | Head of Information Security and the accountable executive (risk owner) |
High | 1 | 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 | [[The full board, or its equivalent]] |
Stage 9 — Expiry handling
An exception that passes its expiry date without being closed or renewed is expired: the requirement applies again in full (EX-10). It must be remediated, renewed or escalated within 10 working days.
Step | What happens | Who | Output |
|---|---|---|---|
27 | On the first working day after expiry, set the status to Expired, and notify the requester, risk owner and control owner. For a High or Critical exception, notify its approver the same day. | Information security | Expiry notice |
28 | Report the deviation as non-compliance in the next monthly review. It is no longer covered by an exception. | Information security | Non-compliance recorded |
29 | Remediate and provide closure evidence (stage 10), or submit a renewal (stage 8), within the grace period. | Requester; risk owner | Closure or renewal request |
30 | If neither has happened by working day 10, escalate to the next approval level up, and name the exception in the quarterly report until it is resolved. | Information security | Escalation |
Stage 10 — Closure with evidence
Step | What happens | Who | Output |
|---|---|---|---|
31 | Tell information security the requirement is now met, the system retired, or the requirement changed, and attach the evidence. | Requester | Closure request with evidence |
32 | Check the evidence (see below). If it does not show the requirement is met, the exception stays open and the requester is told what is missing (EX-13). | Information security | Evidence accepted or returned |
33 | Close the exception in the register with the closure date and the evidence reference. Compensating controls may be removed only after closure, and only if they are not needed for another reason. | Information security | Closed register entry |
34 | Tell the requester, risk owner, control owner and approver it is closed. | Information security | Closure notice |
What evidence closes an exception
Situation | Evidence that closes it | Not enough on its own |
|---|---|---|
Requirement now met | A scan, configuration export, test result or screenshot of the setting, dated after the change, for every system the exception named | A ticket marked done; the remediation plan marked complete |
System retired | The retirement or change record and the updated asset inventory | The system simply no longer appearing in a report |
Requirement changed | The approved revision of the policy or standard, with its effective date | An agreement that the requirement "should not apply" |
Segregation of duties conflict separated | The access change record and a current access listing showing the combination has gone | A manager's statement |
Decision points
Decision | Who decides | Rule | Recorded in |
|---|---|---|---|
Is it a valid exception? | Information security | Nothing in EX-02 may be excepted | Register (rejected) |
Is the request complete? | Information security | Every EX-03 field; the decision clock starts when complete | Register |
What is the score and band? | Information security; Head of Information security for disputes | Scored with the Exception Risk Scoring & Expiry Model; compensating control one step at most (EX-04, EX-07) | Register; request |
Approve, shorten, add conditions or refuse? | Band approver | Within the decision time; never by silence; not by the requester (EX-05) | Decision; register |
How long? | Band approver | No later than the band's maximum (EX-06) | Register |
Renew, and at which level? | Band approver, or the next level up | Renewal count against the band's limit (EX-08) | Register |
Is it closed? | Information security | Only on evidence (EX-13) | Register, with evidence reference |
Worked example — one exception's life
An illustration, not part of the procedure. The dates are worked out from the Standard's rules.
Date | What happened | Step |
|---|---|---|
Mon, 5 Oct 2026 | The finance team finds that the accounting system's administrator console cannot enforce multi-factor authentication, required by [[Access Control Standard, rule AC-07]], until the vendor's next major release, due in March. The finance systems manager submits request EX-2026-004 for 180 days, with the risk owner's (the Finance Director's) confirmation. | 1 to 4 |
Wed, 7 Oct 2026 | Returned once for missing test evidence of the proposed compensating control, then complete. Decision clock starts; decision due by Wed, 21 Oct 2026 (10 working days). | 5 to 7 |
Thu, 8 Oct 2026 | Scored: impact 3 (customer and personal data), likelihood 3 without controls — score 9, High. The console has been restricted to a jump host that enforces multi-factor authentication, and a test shows direct access is blocked, so likelihood falls one step to 2: score 6, Medium. Approver: Head of Information Security. | 8 to 10 |
Fri, 16 Oct 2026 | Approved for 180 days, the band's maximum, to allow for the release slipping. Expiry Wed, 14 Apr 2027; reminder due Mon, 15 Mar 2027. | 11 to 15 |
Monthly | Jump host rule and its logs checked at each register review; remediation milestones on track until February, when the vendor delays the release. | 16 to 19 |
Mon, 15 Mar 2027 | Reminder sent. The requester asks for 60 more days, with the vendor's new date and fresh evidence that the jump host restriction still works. | 20, 22 |
Mon, 29 Mar 2027 | Re-scored: still Medium. First renewal, within the band's limit of 2, so the Head of Information security decides. Renewed for 60 days: new expiry Fri, 28 May 2027. | 23 to 26 |
Mon, 10 May 2027 | Upgrade installed. Closure evidence: a screenshot of the enforced setting and a failed login test without a second factor. Information security checks it and closes the exception; the jump host stays as good practice. | 31 to 34 |
Had the finance team not replied to the reminder, the exception would have expired on Wed, 14 Apr 2027: the requirement would have applied again in full, the team would have had until Wed, 28 Apr 2027 (10 working days) to fix, renew or be escalated, and — because it is Medium, not High or Critical — the approver would have been told in the monthly review rather than on the next working day. Had the jump host not been tested before approval, the score would have stayed 9: High, approved by the Head of Information Security and the accountable executive (risk owner), for at most 90 days.
Outputs and records produced
Output | Produced at step | Held in | Maintained by |
|---|---|---|---|
Exception request with confirmations and evidence | 2 to 4 | Security Exception Request & Approval Form / [[workflow]] | Requester |
Register entry: status, score, band, approver, dates, renewal count | 6, 10, 14, 26, 33 | Security Exception Register | Information security |
Rejection or return notice | 5, 7 | [[Email or workflow]] | Information security |
Written approval decision | 12, 25 | Security Exception Request & Approval Form / [[workflow]] | Approver |
Monthly review record and control checks | 16 to 19 | [[Location]] | Information security |
Reminders, expiry notices and escalations | 13, 20, 21, 27, 30 | [[Email or workflow]] | Information security |
Closure evidence and closure notice | 31 to 34 | Security Exception Register | Information security |
These records feed the quarterly report required by the Security Exception & Waiver Standard (EX-12), produced with the Exception Ageing & Expiry Dashboard.
Timing targets
Activity | Target | Basis |
|---|---|---|
Request made | Before the breach where foreseeable; within [[5 working days]] of discovery otherwise | Standard EX-01 |
Completeness check | Within [[2 working days]] of submission | This procedure |
Decision — Low | Within 5 working days of a complete request | Standard EX-05 |
Decision — Medium | Within 10 working days of a complete request | Standard EX-05 |
Decision — High | Within 10 working days of a complete request | Standard EX-05 |
Decision — Critical | Within 5 working days of a complete request | Standard EX-05 |
Decisions made on time | At least 90% of requests decided within the band's decision time | Standard |
Register updated and decision notified | Within [[1 working day]] of the decision | This procedure |
Register review | Monthly | Standard EX-11 |
Expiry reminder | 30 days before expiry; on approval if shorter | Standard EX-09 |
Expired exception resolved | Within 10 working days of expiry | Standard EX-10 |
Expired exceptions | Zero expired High or Critical exceptions; below 5% of all open exceptions expired | Standard |
Management report | Quarterly | Standard EX-12 |
Guidance — delete before approval
Targets marked "This procedure" are not in the Standard. You may change them, but check the result still leaves the approver enough of the band's decision time.
Escalation
When | Escalated to | By | Basis |
|---|---|---|---|
No decision by the band's decision time | Next approval level up | Information security | Standard EX-05 |
Renewal beyond the band's limit | Next approval level up | Information security | Standard EX-08 |
High or Critical exception expired | Its approver, first working day after expiry | Information security | Standard EX-10 |
Any expired exception unresolved after 10 working days | Next approval level up; named in the quarterly report | Information security | Standard EX-10 |
Compensating control found not working | Risk owner and approver; re-score (step 18) | Information security | This procedure |
Score disputed | Head of Information security decides within [[2 working days]] | Information security | This procedure |
Service provider misses a milestone | [[Supplier or contract manager]] | Information security | Service agreement |
An escalation states the exception reference, the requirement, the band, the dates, and the decision needed — fix, renew, or accept at a higher level. It asks for a decision, not just attention.
Evidence retained
Keep the following so a reviewer can follow any exception from request to closure. Retention periods follow the Records to keep section of the Security Exception & Waiver Standard.
Evidence | Shows | Minimum retention |
|---|---|---|
Requests, including refused and returned ones | Every departure was requested and recorded (EX-03, EX-11) | [[3 years after closure]] |
Risk assessments with compensating control test evidence | The band was set on a tested control (EX-04, EX-07) | [[3 years after closure]] |
Approval and renewal decisions | The right approver decided in time (EX-05, EX-08) | [[3 years after closure]] |
Monthly review records | The register was reviewed and controls checked (EX-11) | [[3 years]] |
Reminders, expiry notices, escalations | Expiry was managed (EX-09, EX-10) | [[3 years]] |
Closure evidence | The requirement was met before closure (EX-13) | [[3 years after closure]] |
Guidance — delete before approval
An auditor typically picks a few exceptions and asks for the request, the score, the approver's decision, the expiry date and the closure evidence. Test this yourself each quarter on three exceptions, including one that was renewed.
Related documents
Document | Relationship |
|---|---|
Security Exception & Waiver Standard | The rules this procedure runs (EX-01 to EX-13) |
Security Exception Request & Approval Form | The request and approval record (stages 1 and 4) |
Exception Risk Scoring & Expiry Model | How the score and band are set (stage 3) |
Security Exception Register | Where every exception is recorded (stages 2, 5, 8 to 10) |
Segregation of Duties Conflict Matrix | Conflicts that become exceptions under SD-04 |
SoD Conflict Review & Compensating Control Procedure | How accepted conflicts are reviewed (SD-05) |
Exception & SoD Responsibility Matrix | Who does what across the pack |
Exception Ageing & Expiry Dashboard | The monthly and quarterly figures (step 19) |
Adapting this template
Guidance — delete before approval
Small organisation: a shared mailbox and the register can replace a workflow tool. Stages 2 and 3 can be one sitting. Keep step 10's check that nobody approves their own exception, and the monthly review; they are what an auditor tests.
Regulated entity (NIS2 or DORA): record that this procedure is part of your ICT risk management framework. For DORA financial entities, the register and monthly review show that exceptions from ICT security policies are recorded and that resilience is kept while they exist; keep the records for the period your regulator expects (typically at least five years).
IT run by a service provider: the provider may prepare requests and provide evidence, but the risk owner and approver are always your own people, and information security verifies closure evidence itself (step 32). Put the provider's obligations in the service agreement.
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 | Annex A 5.36 — Compliance with policies, rules and standards for information security | Whole procedure |
ISO/IEC 27001:2022 | Clause 6.1.3 — Information security risk treatment | Stages 3, 4 and 8: exceptions as risk treatment decisions |
NIST CSF 2.0 | ID.RA-06 — “Risk responses are chosen, prioritized, planned, tracked, and communicated” | Stages 3, 4 and 8: choosing and approving the risk response |
NIST CSF 2.0 | ID.RA-07 — “Changes and exceptions are managed, assessed for risk impact, recorded, and tracked” | Whole procedure: each exception requested, assessed, recorded and tracked to closure |
NIST CSF 2.0 | GV.RM-06 — “A standardized method for calculating, documenting, categorizing, and prioritizing cybersecurity risks is established and communicated” | Stage 3: a standard way of scoring every exception |
NIS2 — Directive (EU) 2022/2555 | Article 21(2)(a) — “policies on risk analysis and information system security” | Whole procedure |
DORA — Delegated Regulation (EU) 2024/1774 | Article 2(2)(c)(ii) and (iii) — ICT security policies record exceptions from their implementation and keep resilience assured while exceptions exist | Stages 2, 5 and 6: recording exceptions and checking compensating controls |
Definitions
Term | Meaning in this procedure |
|---|---|
Band | The level of risk — Low, Medium, High, Critical — set by the score, which decides the approver and the maximum duration. |
Chronic exception | An exception renewed more times than its band allows (EX-08). |
Compensating control | A measure that reduces the risk while a requirement is not met. It counts in the score only once tested. |
Complete request | A request with every field EX-03 requires. The decision time starts from the date it is complete. |
Decision time | The longest an approver may take to decide, in working days from a complete request. |
Exception | An approved, time-limited decision that a security requirement need not be met for named systems, accounts or suppliers. |
Expired exception | An exception past its expiry date that has been neither closed nor renewed. The requirement applies again in full. |
Grace period | The 10 working days after expiry in which an expired exception must be remediated, renewed or escalated. The exception is not valid during it. |
Renewal | Extending an exception by a new, re-scored decision before it expires. |
Risk owner | The accountable business executive for the affected service, who accepts the residual risk. |