Security Exception & Waiver Standard
Sets the rules for when a control deviation may be granted, who may approve it at each risk level, and the maximum lifetime it may carry.
Available soon
- Format
- Word
- Size
- 57 KB
- Length
- 14 pages
- Version
- 1.1
- Updated
What's inside
- Purpose
- Scope
- Parent policy and authority
- Roles and responsibilities
- When an exception is needed
- Requesting an exception
- Risk assessment and scoring
- Approval authority and maximum duration
- Renewal
- Monitoring, reminders and expiry
- Register, review and reporting
- Closure
- Segregation of duties
- Exceptions to this standard
- Records to keep
- Compliance
- Review
- Related documents
- Adapting this template
- Framework references
- Appendix A — 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 standard sets the rules for when [[Organisation Name]] may allow a system, service, team or supplier not to meet an information security requirement for a limited time, who may approve that at each level of risk, and how long it may last before it must be fixed, renewed or escalated. It also sets the rules for segregation of duties: which combinations of tasks one person must not hold, and what happens where a small team cannot separate them.
Its aim is simple: every departure from a security rule is known, decided by the right person, time-limited, protected by a compensating control where one is possible, and closed with evidence. An exception is a managed risk decision, not a way of making a requirement go away.
Guidance — delete before approval
Many organisations already grant exceptions informally — an email from a manager, a note in a ticket. This standard does not forbid those decisions; it makes them visible and time-limited. Before approval, collect the informal exceptions you know of and plan to bring them into the register within the first three months (see Transition in Adapting this template).
Scope
This standard applies to:
- every requirement in [[Organisation Name]]'s information security policies, topic-specific policies and standards, and in the security clauses of its procedures and baselines (together, security requirements);
- every system, service, location, team and supplier covered by those requirements, including systems operated for us by service providers;
- all access rights and business roles in the systems listed in the Segregation of Duties Conflict Matrix, for the segregation of duties rules.
It does not cover: accepting a risk that no security requirement addresses (that is a risk treatment decision under the [[Risk Management Methodology]]); legal, regulatory or contractual obligations, which an internal exception cannot waive (EX-02); or an emergency action taken during an incident under the [[Incident Management Procedure]], which is recorded there and, if it has to continue after the incident is closed, becomes an exception request under this standard.
Guidance — delete before approval
Exception or waiver? Some organisations use "waiver" for a permanent release from a requirement and "exception" for a temporary one. This standard does not allow permanent releases (EX-02). If a requirement should never apply to something, change the requirement or its scope through the normal policy review. The words "exception" and "waiver" are used as one thing here.
Parent policy and authority
This standard is issued under the [[Information Security Policy]], which gives [[the Head of Information Security]] authority to set standards and [[the executive committee]] authority to approve them. The approval authorities in this standard are delegated by [[the executive committee / management body]]; nobody may approve an exception above the authority this standard gives their role.
Where another policy or standard contains its own exception clause — for example, a remediation standard that requires an exception when a deadline cannot be met — that clause routes the request here. The rules of this standard apply unless the other document sets a shorter duration or a higher approver, in which case the stricter rule applies.
Roles and responsibilities
Role | Responsibilities under this standard |
|---|---|
Requester [[e.g. system owner, project lead]] | Raises the exception request before the requirement is breached where possible (EX-03). Proposes and runs the compensating controls. Delivers the remediation plan. Requests renewal or closure in time. |
Risk owner [[the accountable business executive for the affected service]] | Accepts the residual risk of the exception on behalf of the business, is named on every request, and answers for it until closure. Co-approves High exceptions and presents Critical ones. |
Control owner [[e.g. IT Operations Manager]] | Owns the requirement that is not being met. Confirms the compensating control works. Approves Low exceptions. |
Information security [[e.g. Head of Information Security]] | Maintains this standard, the register and the Segregation of Duties Conflict Matrix. Checks requests for completeness and assesses their risk (EX-04). Approves Medium exceptions and co-approves High ones. Runs the monthly review and quarterly report (EX-11, EX-12). |
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 escalated renewals (EX-08). Receives the quarterly report and decides on chronic exceptions. |
Independent reviewer [[e.g. internal audit, or an external reviewer for small organisations]] | Periodically checks that exceptions and segregation of duties conflicts are decided and recorded as this standard requires, and reviews privileged and emergency access (SD-06). |
Guidance — delete before approval
In a small organisation one person may hold several roles, but a requester must never approve their own exception (EX-05), and the person who holds a conflicting combination of duties must never be the one who reviews it (SD-04).
When an exception is needed
EX-01 An exception is required whenever a security requirement is not, or will not be, met by the date it applies — including a remediation deadline that will be missed, a control that cannot be implemented on a system, a supplier that cannot meet a contractual security clause, and a combination of duties that cannot be separated (SD-04). The exception must be requested before the requirement is breached where the breach can be foreseen, and within [[5 working days]] of discovery where it cannot.
EX-02 The following may never be excepted, and a request for any of them is rejected at triage:
- a legal or regulatory obligation, or a contractual obligation to a customer or regulator. An internal exception cannot waive the law. Where such an obligation cannot be met, it is a compliance issue handled under [[the compliance or legal escalation process]], which may include notifying a regulator. If the law itself permits a documented, risk-based deviation, that deviation may be recorded in the register, but it is decided under the law's own terms;
- this standard itself: its bands, approval authorities, maximum durations, renewal limits and the rules in this section. They change only by revising and re-approving the standard;
- indefinite or open-ended exceptions: every exception has a fixed expiry date no later than its band allows (EX-06);
- backdated approval: an exception takes effect from the date it is approved, never earlier. A breach before that date is reported as a breach;
- blanket exceptions that do not name the specific systems, accounts or suppliers affected;
- [[any further requirements your organisation treats as non-negotiable, e.g. multi-factor authentication for remote administrator access, or backups of Critical systems]].
Guidance — delete before approval
Keep the non-negotiable list short. A long list pushes people into unrecorded workarounds. Two or three controls whose failure you could not defend to a regulator or a customer are usually enough.
A regulator-facing obligation that cannot be met is not an exception: it needs legal advice and, often, a notification. The register can still hold a line for it, marked "Not an exception — compliance issue", so it is not lost.
Requesting an exception
EX-03 Every request is made on the Security Exception Request & Approval Form, or in [[the exception workflow in your ticketing system]] with the same fields, and states at least:
- the requester, the risk owner and the control owner;
- the requirement not met, by document and rule or clause number, and the systems, accounts, data or suppliers affected;
- why the requirement cannot be met now, and what meeting it would cost or disrupt;
- the compensating controls in place or proposed, and how their effect will be checked;
- the remediation plan: what will be done to meet the requirement, by whom, and by when;
- the duration requested, which may not exceed the band's maximum (EX-06).
A request that lacks any of these is returned to the requester and the decision time does not start until it is complete.
Risk assessment and scoring
EX-04 Information security assesses every complete request using the Exception Risk Scoring & Expiry Model. The score is impact × likelihood while the exception is open, each on a scale of 1 to 4, taking compensating controls into account. The score sets the band, and the band sets the approver and the maximum duration. The requester and the risk owner may comment on the score but may not set it.
EX-07 A compensating control lowers the likelihood by one step, never more, and never below 1. It counts only if it is in place and has been tested before approval — a planned control does not lower the score. A compensating control never lowers the impact.
Impact
Level | Impact | Meaning |
|---|---|---|
1 | Minor | Affects one system of Standard criticality or non-sensitive data; no customer or regulatory effect. |
2 | Moderate | Affects a High criticality system or internal confidential data; limited, recoverable disruption. |
3 | Major | Affects a Critical system, personal or customer data, or a regulated service; notifiable if it went wrong. |
4 | Severe | Could stop a core business service, expose sensitive data at scale, or breach a legal obligation. |
Likelihood
Level | Likelihood | Meaning |
|---|---|---|
1 | Unlikely | Not reachable from the internet or by ordinary users; no known exploitation; strong compensating control in place. |
2 | Possible | Reachable internally; exploitation needs skill or insider access. |
3 | Likely | Reachable by many users or from partner networks; exploitation techniques are public. |
4 | Almost certain | Internet-facing or known to be actively exploited, with no effective compensating control. |
Score and band
Each cell shows the score and the band it falls in. Impact × likelihood can only produce the scores shown; there are no scores of 5, 7, 10, 11 or 13 to 15.
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 |
Guidance — delete before approval
The Exception Risk Scoring & Expiry Model gives worked examples and the full reasoning behind these scales. Use it for every request: consistent scoring is what makes the band, and so the approver, defensible to an auditor.
If a request covers several systems with different exposure, score the worst one. Splitting one exception into several low-scoring ones to reach a more junior approver is itself a breach of this standard.
Approval authority and maximum duration
EX-05 An exception is approved only by the approver for its band, in writing, within the band's decision time counted in working days from a complete request. Nobody may approve an exception they requested, or one to a control they operate themselves; the approval then passes to the next level up. An approver may always refuse, shorten the duration or add conditions.
EX-06 Every exception has a fixed expiry date, set at approval, no later than the band's maximum duration counted in calendar days from the approval date. A shorter duration should be set wherever the remediation plan allows.
Band | Score | Approver | Decision time | Maximum duration | Renewals by the same approver |
|---|---|---|---|---|---|
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 |
The decision-time target is at least 90% of requests decided within the band's decision time. A request that is not decided in time is escalated to the next approval level up; it is never treated as approved by silence.
Guidance — delete before approval
Replace the example approvers with named roles before approval. A High exception needs both the Head of Information Security and the accountable executive; a Critical exception goes to the body your structure gives (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); name it, and note that it can usually be reached at its next scheduled meeting or by written procedure — check that it can decide within 5 working days.
The durations are ceilings, not defaults. An exception that covers a 90-day project should not be approved for longer because the band allows it.
Renewal
EX-08 An exception may be renewed only by a new request with an updated risk assessment and a progress report on the remediation plan, made before it expires. The band's approver may renew it up to the number of times in the table above. A renewal beyond the band's limit goes to the next approval level up. For a Critical exception, the next level up is [[the full board, or its equivalent]]. A renewal never restarts the renewal count, and a change of band re-sets the approver and maximum duration but not the count.
The longest an exception can run with the renewals its band allows, before it must go up a level:
Band | Maximum duration | Renewals by the same approver | Longest total before escalation | Beyond that, approved by |
|---|---|---|---|---|
Low | 365 days | 2 | 1095 days | Head of Information Security |
Medium | 180 days | 2 | 540 days | Head of Information Security and the accountable executive (risk owner) |
High | 90 days | 1 | 180 days | 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 | 30 days | 1 | 60 days | [[The full board, or its equivalent]] |
An exception renewed more times than its band allows (EX-08) is a chronic exception. It is reported by name in every quarterly report (EX-12) until it is closed.
Guidance — delete before approval
Renewal is where exception processes usually fail: the expiry date passes, someone extends it by email, and the exception becomes permanent. The escalation in EX-08 is deliberately uncomfortable, so that a chronic exception becomes a management decision to fund the fix or formally carry the risk.
Monitoring, reminders and expiry
EX-09 The requester and the risk owner are reminded 30 days before an exception expires, and asked to close, renew or confirm it will lapse. For an exception approved for 30 days or less, the reminder is sent on approval.
EX-10 An exception that passes its expiry date without being closed or renewed is expired: the requirement applies again in full, and the deviation is reported as non-compliance. Within 10 working days of expiry it must be remediated, renewed under EX-08 or escalated to the next approval level up. An expired High or Critical exception is reported to its approver on the first working day after expiry.
The target is: zero expired High or Critical exceptions; below 5% of all open exceptions expired.
Register, review and reporting
EX-11 Every exception, from request to closure, is recorded in the Security Exception Register, including refused requests. Information security reviews the whole register monthly: expiry dates, overdue remediation plans, whether compensating controls are still in place and working, and whether any score should change.
EX-12 Information security reports to [[e.g. Executive Committee or its risk committee]] quarterly, using the Exception Ageing & Expiry Dashboard. The report gives at least the four headline measures below, lists every High and Critical exception and every chronic exception by name, and states any decisions management needs to take.
The four headline measures:
Measure | Definition | Target |
|---|---|---|
Open exceptions by band | Live approved exceptions at month end, by Low, Medium, High and Critical. | Trend down; no unexplained rise in High or Critical |
Expired exceptions | Exceptions past their expiry date that are neither closed nor renewed, as a share of all open exceptions. | Zero High or Critical; below 5% overall |
Chronic exceptions | Exceptions renewed more than their band allows (EX-08), so the gap has outlived every renewal the Standard permits. | Zero; each one reported by name |
Unmitigated SoD conflicts | Known High conflicts with no compensating control recorded and reviewed in the last quarter. | Zero |
Closure
EX-13 An exception is closed only with evidence that it is no longer needed: the requirement is now met (for example, a scan, configuration export or test result), the system has been retired, or the requirement has been changed by a formal revision. Information security checks the evidence and records the closure date and reference in the register. A remediation plan marked complete is not evidence on its own.
Segregation of duties
SD-01 No one person may hold a combination of duties that would let them make, approve and conceal an unauthorised change, payment or access grant. This applies to business roles and to access rights in [[the finance, payroll, procurement, identity and production systems listed in the Segregation of Duties Conflict Matrix]], to IT administration, and to the security function itself: the people who operate a control do not audit it.
SD-02 Information security maintains the Segregation of Duties Conflict Matrix with the owners of the systems it covers. It lists the conflicting combinations and rates each High, Medium or Low. The matrix is reviewed annually, and after any restructure or new core system.
Rating | Meaning |
|---|---|
High | One person could make and hide an unauthorised change, payment or access grant with no second person seeing it. |
Medium | One person could make an unauthorised change that another control would probably, but not certainly, detect later. |
Low | The combination is undesirable but the damage is small or detected quickly by routine checks. |
SD-03 Before any role or access right is granted or changed in a system covered by the matrix, the person granting it checks the matrix. A grant that would create a conflict is not made unless it has been accepted under SD-04. Existing assignments are checked against the matrix at each review in SD-05.
SD-04 Where a conflict cannot be separated — usually because the team is too small — it is recorded in the Security Exception Register as an exception, scored and approved under EX-03 to EX-06 like any other, and protected by at least one compensating control carried out by someone without the conflict: for example, independent review of the person's activity, a second approval for transactions above [[threshold]], or a reconciliation performed by another person. The SoD Conflict Review & Compensating Control Procedure sets out how.
SD-05 Every accepted conflict, and the evidence that its compensating control was performed, is reviewed by someone without the conflict: quarterly for a High conflict, every six months for a Medium conflict, and at the annual review of the matrix for a Low conflict. A High conflict with no compensating control recorded and reviewed in the last quarter is reported as unmitigated.
SD-06 Privileged and emergency ("break-glass") access is granted for a stated purpose and a limited time, logged, and reviewed after use by someone other than the user, within [[2 working days]]. Administrators do not review the logs of their own activity. Standing privileged access that combines conflicting duties is a conflict under SD-04.
SD-07 Records of conflict checks, accepted conflicts, compensating control evidence, reviews and emergency access use are kept as set out in Records to keep, so that an independent reviewer can follow any conflict from detection to its latest review.
Guidance — delete before approval
Small teams: perfect separation is often impossible with two or three people in IT or finance. That is what SD-04 is for. An auditor accepts a documented conflict with a real, evidenced compensating review far more readily than a matrix that claims no conflicts.
The Exception & SoD Responsibility Matrix shows who does what across exceptions and segregation of duties; check it for your own conflicts before approving this standard.
Exceptions to this standard
There are no exceptions to this standard (EX-02). If a rule in it cannot be followed, [[the Head of Information Security]] proposes a revision to [[the approver]], and the rule stays in force until the revision is approved.
Records to keep
Record | Where held | Minimum retention |
|---|---|---|
Exception requests, risk assessments and approval decisions, including refusals | Security Exception Register / [[Location]] | [[3 years after closure]] |
Compensating control evidence and renewal decisions | Security Exception Register / [[Location]] | [[3 years after closure]] |
Reminders, expiry notices and escalations | [[Email or workflow system]] | [[3 years]] |
Closure evidence | Security Exception Register / [[Location]] | [[3 years after closure]] |
Monthly register reviews and quarterly reports | [[Location]] | [[3 years]] |
The Segregation of Duties Conflict Matrix, each approved version | [[Document management system]] | [[3 years after superseded]] |
Conflict checks, accepted conflicts and their reviews | [[Identity management system / Location]] | [[3 years]] |
Privileged and emergency access logs and their reviews | [[Log platform]] | [[12 months online; 3 years archived]] |
Approved versions of this standard | [[Document management system]] | [[Life of the ISMS + 3 years]] |
Guidance — delete before approval
Align retention with your records retention schedule. Regulated financial entities typically keep ICT risk records for at least five years; confirm your own obligations.
Compliance
Compliance with this standard is monitored through the monthly register review (EX-11) and the quarterly report (EX-12), and checked through [[internal audit / independent review]]. A security requirement not met without an approved exception is a breach, and is reported and escalated as such. Repeated breaches may be treated under [[the disciplinary procedure / supplier performance terms]].
Review
This standard is reviewed at least every 12 months, and also after an incident in which an excepted weakness played a part, a significant restructure, or a change in applicable regulation.
Related documents
Document | Relationship |
|---|---|
[[Information Security Policy]] | Parent policy |
Exception Lifecycle Operating Procedure | How a single exception moves from request to closure |
Security Exception Request & Approval Form | The request and approval record required by EX-03 and EX-05 |
Exception Risk Scoring & Expiry Model | The scoring method in EX-04 and EX-07, with worked examples |
Security Exception Register | The register required by EX-11, including accepted conflicts (SD-04) |
Segregation of Duties Conflict Matrix | The conflict matrix required by SD-02 |
SoD Conflict Review & Compensating Control Procedure | How conflicts are reviewed and compensated (SD-04, SD-05) |
Exception & SoD Responsibility Matrix | Who does what across the pack |
Exception Ageing & Expiry Dashboard | The quarterly report required by EX-12 |
[[Risk Management Methodology]] | Risks not tied to a security requirement |
Adapting this template
Guidance — delete before approval
Small organisation: the Head of Information Security may be the IT manager, and executive management the managing director. Keep the band table and EX-05 unchanged — the rule that nobody approves their own exception is what gives the process its value. An external reviewer (for example, your auditor or a trusted adviser) can act as the independent reviewer once a year.
Regulated entity (NIS2 or DORA): name the management body as the Critical approver, and record this standard in your ICT risk management framework. For DORA financial entities, the register (EX-11) is how you show that exceptions from ICT security policies are recorded and that resilience is kept while they exist; make sure the control function reviewing exceptions is independent of the teams requesting them.
IT run by a service provider: the provider may request exceptions, but the risk owner and approver are always your own people. Put EX-03 and EX-13 into the service agreement so the provider must supply the request details and closure evidence, and add the provider's administrator accounts to the conflict matrix.
Transition: in the first three months, enter every known informal exception in the register, score it, and have it approved or ended. Approve them for no longer than their band allows, starting from the approval date, not the date they began.
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 standard; EX-11, EX-12 |
ISO/IEC 27001:2022 | Clause 6.1.3 — Information security risk treatment | EX-04 to EX-08: exceptions as risk treatment decisions |
ISO/IEC 27001:2022 | Annex A 5.3 — Segregation of duties | SD-01 to SD-07 |
ISO/IEC 27001:2022 | Annex A 5.1 — Policies for information security | Parent policy and authority; review |
NIST CSF 2.0 | GV.PO-01 — “Policy for managing cybersecurity risks is established based on organizational context, cybersecurity strategy, and priorities and is communicated and enforced” | Whole standard: how policy is enforced where it cannot be met |
NIST CSF 2.0 | ID.RA-06 — “Risk responses are chosen, prioritized, planned, tracked, and communicated” | EX-04 to EX-08: 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” | EX-01 to EX-13: exceptions requested, assessed for risk, recorded and tracked |
NIST CSF 2.0 | PR.AA-05 — “Access permissions, entitlements, and authorizations are defined in a policy, managed, enforced, and reviewed, and incorporate the principles of least privilege and separation of duties” | SD-01 to SD-06 |
NIS2 — Directive (EU) 2022/2555 | Article 21(2)(a) — “policies on risk analysis and information system security” | Whole standard |
NIS2 — Directive (EU) 2022/2555 | Article 21(2)(i) — “human resources security, access control policies and asset management” | SD-03, SD-06 |
DORA — Regulation (EU) 2022/2554 | Article 6(4) — a control function for ICT risk, independent enough to avoid conflicts of interest, and segregation of ICT risk management, control and internal audit functions | Roles; SD-01 |
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 | EX-03, EX-07, EX-11 |
DORA — Delegated Regulation (EU) 2024/1774 | Article 2(2)(g) — ICT security policies specify segregation-of-duties arrangements to avoid conflicts of interest | SD-01, SD-02, SD-04 |
DORA — Delegated Regulation (EU) 2024/1774 | Article 21(b) — an access control policy with segregation of duties that prevents combinations of access rights able to circumvent controls | SD-02, SD-03 |
Appendix A — Definitions
Term | Meaning in this standard |
|---|---|
Band | The level of risk an exception carries — Low, Medium, High, Critical — set by its score. The band decides the approver and the maximum duration. |
Break-glass access | Emergency access to a system, usually a highly privileged account kept for use when normal access fails, granted for a short time and reviewed after use. |
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, such as restricting network access, adding monitoring, or an independent review of a person's activity. |
Conflict (segregation of duties) | A combination of duties or access rights held by one person that would let them make and conceal an unauthorised action. |
Exception (waiver) | An approved, time-limited decision that a security requirement need not be met for a named system, account or supplier, with a risk owner, a compensating control where possible, and a remediation plan. |
Expired exception | An exception past its expiry date that has been neither closed nor renewed. The requirement applies again in full. |
Risk owner | The accountable business executive for the affected service, who accepts the residual risk of the exception. |
Score | Impact × likelihood while the exception is open, each from 1 to 4, after compensating controls. |
Security requirement | Any requirement in an information security policy, standard, procedure or baseline of the organisation. |
Segregation of duties | Dividing tasks so that no one person can carry out and conceal an unauthorised action alone. |