Patch Deferral Request Form
Captures justification, compensating controls and expiry for a patch that cannot be applied on time; feeds the P02 exception register.
Available soon
- Format
- Word
- Size
- 65 KB
- Length
- 21 pages
- Version
- 1.0
- Updated
What's inside
What changed
- 1.0
Published.
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.
How to use this form
Use this form to ask for a patch to be installed after its deadline. One form covers one patch on the systems it names. It is designed so that the approver can decide from the form alone, without a meeting, and so that the decision can be copied straight into the organisation's exception register.
A deferral is an exception under the Security Exception & Waiver Standard (P02). The rules are PM-14 to PM-16 of the Patch Management Standard; the deadline is the Vulnerability & Exposure Management Standard's. Installing a patch after its P01 deadline, approved in advance as a P02 exception (PM-14). Moving a patch to a later window that is still inside its deadline is not a deferral.
Part | Who completes it | When |
|---|---|---|
A Request | The system owner, with the patch owner | As soon as the patch will miss its deadline, and always before the deadline passes |
B Assessment | Head of Information Security [[e.g. Head of Information Security or CISO]] | On receipt of a complete request |
C Decision | The approver B3 names | Within the band's decision time |
D Closure | The patch owner; confirmed by the Head of Information Security | When the patch is installed and verified |
Steps
- The system owner completes Part A with the patch owner, attaches the evidence for the reason and for each compensating control, and sends the form to the information security team.
- The Head of Information Security checks the request is complete, made before the deadline and for an accepted reason (B1). An incomplete request is returned at once, saying what is missing; a request for a reason that is never accepted is refused.
- The Head of Information Security scores it with the P02 model (B2), works out the approver and the latest expiry (B3), and sends it to the approver.
- The approver decides within the band's decision time and signs Part C. A second signature is added where DA-2 or DA-4 applies.
- The Head of Information Security enters the deferral in the exception register (C3) and sends a copy to the requester. The patch owner books the window in A6.
- When the patch is installed and the rescan is clean, the patch owner completes Part D and the register entry is closed. If the date in A6 cannot be met, a new request is made before expiry: a renewal is a new decision on a new score.
Guidance — delete before approval
Keep this form's fields in step with the columns of the Security Exception Register: the table under "Copying the decision into the exception register" shows where each answer goes. If you run requests through a service desk or workflow tool, rebuild these fields there and keep the four parts.
When a deferral is needed
Ask in order and stop at the first answer that settles it.
Question | Yes | No |
|---|---|---|
Will the patch be installed and verified on every system by its P01 deadline? | No form. Moving a patch to a later window inside its deadline is not a deferral. | Next question. |
Has the deadline already passed? | Too late for a deferral (P01 VM-16). It is reported as overdue and escalated as the Vulnerability & Exposure Management Standard sets (VM-19). Install it as soon as possible. | Next question. |
Is the reason on the accepted list below? | Next question. | No deferral. Install it by the deadline, or report it overdue: it is escalated as the Vulnerability & Exposure Management Standard sets (VM-19). |
Is it Priority 1? | Put the 72-hour mitigation in place first (DA-1), then request. | Request now, with a tested compensating control. |
Accepted reasons
A deferral is approved only for a reason on the accepted list, with a compensating control that has been tested and a date the patch will be installed. Workload, the lack of a test system and a missed window are never reasons (PM-15).
Code | Reason |
|---|---|
DR-1 | The patch failed in the pilot or a test with a confirmed fault, or the vendor withdrew it or published a known issue that affects us. |
DR-2 | The system's supplier has not yet certified the patch, and installing it uncertified would end the supplier's support. |
DR-3 | The system cannot be restarted inside the deadline without stopping a critical service, and none of the other options in PM-16 works in time. |
DR-4 | No patch exists: the vendor has not released one, or the system is past support (PM-17). |
DR-5 | The system is being retired before the next window, on an approved date. |
Never reasons:
- The team was busy, or short of staff.
- There is no test system.
- The window was missed.
- The system is internal only: exposure is already in the P01 priority.
- It has always been done this way.
For a system that cannot be restarted, the options must be worked through first, in order (PM-16). RO-1 use the redundancy; RO-2 agree a window inside the deadline; RO-3 live patching; RO-4 mitigate and defer; RO-5 fix the cause. A deferral is the fourth option, not the first.
Who approves, and for how long
A patch that will not be installed by its P01 deadline must be deferred as a P02 exception, requested before the deadline passes (P01 VM-16), scored with the P02 model and approved by the approver its band sets (P02 EX-05). It expires no later than the band's maximum or [[90]] days (P01 VM-17), whichever is shorter. A Priority 1 deferral needs the 72-hour mitigation in place first and the approver P01 VM-18 names. Moving a patch to a later window inside its deadline is not a deferral (PM-14).
Band | Score | Approver | Decision within (working days from a complete request) | Longest deferral |
|---|---|---|---|---|
Low | 1–3 | Control owner | 5 | 90 days |
Medium | 4–6 | Head of Information Security | 10 | 90 days |
High | 8–9 | Head of Information Security and the accountable executive (risk owner) | 10 | 90 days |
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 | 30 days |
These always apply on top of the band:
When | What applies | |
|---|---|---|
DA-1 | Priority 1 | Only once the 72-hour mitigation is in place (P01 VM-09), and approved by the approver of the vulnerability standard (P01 VM-18), or by the band's approver where that approver is more senior. |
DA-2 | The risk left is outside appetite, or scored Critical | The P05 approver for that position signs as well: the stricter of the two always applies (P05). |
DA-3 | The approver requested the deferral, or runs the patching | The approval passes to the next level up (P02 EX-05). |
DA-4 | A Critical band deferral | Approved by 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; a renewal beyond its limit goes to [[the full board, or its equivalent]] (P02 EX-08). |
The longest deferral is the band's maximum under the exception standard or P01's 90 days, whichever is shorter; for the Critical band it is 30 days. A broken rule is a P02 exception, not a risk acceptance. Where the exception leaves a risk outside appetite, or scored Critical, the approver this pack requires for that position also signs the exception: the stricter of the two always applies.
Guidance — delete before approval
Most patch deferrals score Low or Medium once a tested control is in place, and the band's approver is then often the person who runs the patching. DA-3 moves the decision up a level, so nobody approves a deferral of their own work. Name in this form who signs in that case, before you adopt it.
Before you submit
- Every system is named as it is in the inventory (A1).
- The deadline is the P01 deadline from first detection, as a date (A2).
- The reason is one code from the accepted list, with its evidence attached (A3).
- Each option in A4 has a line, in order.
- Each compensating control has a test date and a result (A5). A control that is planned, or not tested, is listed, but it will not lower the score.
- There is a date the patch will go in, and a lasting fix with an owner (A6).
- You are sending it before the deadline passes.
Field guidance
Field | What a good answer looks like | Common weak answer, and what follows |
|---|---|---|
A1 Systems affected | Every system by its inventory name, so the deferral covers exactly those and no others: 'WMS-APP-01 and WMS-DB-01'. | 'The warehouse servers'. The request is returned: a deferral without names cannot be checked or closed. |
A2 Deadline | The P01 deadline of each system, from its first detection, as a date. Where systems have different priorities, the earliest. | The release date plus a month. The request is returned: the deadline is P01's, from first detection (PM-02). |
A3 Reason | One code from the accepted list, with the evidence: the supplier's message, the failed test record, the vendor's known issue. | 'Busy this month', 'no test system', 'missed the window'. These are never reasons (PM-15): the request is refused. |
A4 Options tried | Each option in order, with why it does or does not work for this system in this month. | 'Server can't be rebooted'. The request is returned: the options must be worked through first (PM-16). |
A5 Compensating controls | What makes the flaw harder to reach while the patch waits, who checked it, how and when, with the result. | 'Firewall in place' with no test. Scored as not tested: it does not lower the likelihood (P02 EX-07). |
A6 Install date | A date and a window, after which the deferral ends because the patch is in. | 'When the supplier certifies'. The request is returned: the expiry needs a date. |
B2 Score | Impact and likelihood as the P02 model defines them, with one line on each. | — |
Where each answer the standard requires is asked:
Required answer | Where on the form | Rule |
|---|---|---|
Patch and vendor reference | A2 | PM-03 |
Systems affected, by name | A1 | PM-14 |
P01 priority, first detection and deadline | A2 | PM-02 |
Reason, from the accepted list | A3 | PM-15 |
Options tried for a system that cannot be restarted | A4 | PM-16 |
Compensating controls, and the date each was tested | A5 | PM-15 |
Date the patch will be installed | A6 | PM-15 |
Score: impact, likelihood before and after controls, band (P02) | B2 | PM-14 |
Approver, decision date and expiry | C1, C2 | PM-14 |
P02 exception register reference | C3 | PM-14 |
Closure: date installed and verified, with the scan | D1 | PM-10 |
The form
Guidance — delete before approval
Replace the placeholders with blank space when you adopt the form, or leave them as prompts. Keep the band table identical to the Security Exception & Waiver Standard, and A3's codes identical to the Patch Management Standard.
Part A: Request
Completed by the system owner, with the patch owner, before the deadline passes. Send it to the Head of Information Security with the evidence for A3 and A5 attached.
A1 Requester and systems | |||
Requester name and role; usually the system owner | [[Name, role]] | Date requested | [[YYYY-MM-DD]] |
System owner owns the risk while the patch waits | [[Name, role]] | Patch owner who deploys the patch | [[Name, role]] |
Systems affected by inventory name | [[System names]] | Asset class AC-1 to AC-5 | [[AC-n]] |
A2 The patch and its deadline | |||
Patch and vendor reference | [[Vendor, product, update and reference]] | Released | [[YYYY-MM-DD]] |
P01 priority the earliest, if systems differ | [[Priority 1 / 2 / 3 / 4]] | First detected | [[YYYY-MM-DD]] |
Deadline first detection plus the priority's days (P01 VM-08) | [[YYYY-MM-DD]] | Route and the date it was planned | [[RT-C / RT-X / RT-E, planned for YYYY-MM-DD]] |
A3 Reason | one code from the accepted list (PM-15): DR-1, DR-2, DR-3, DR-4, DR-5 | |||
Reason code | [[DR-n]] | ||
Why, with the evidence the supplier's message, the failed test, the vendor's notice | [[What happened, and the reference of the evidence attached]] | ||
A4 Options tried | in this order (PM-16); say why each does or does not work | |||
RO-1 Use the redundancy | [[Tried? Result, or why it does not apply]] | ||
RO-2 Agree a window inside the deadline | [[Tried? Result, or why it does not apply]] | ||
RO-3 Live patching | [[Tried? Result, or why it does not apply]] | ||
RO-4 Mitigate and defer | [[Tried? Result, or why it does not apply]] | ||
System past support EO-1, EO-2, EO-3 | [[Still needed? Upgrade or replace? Extended support? Or not applicable]] | ||
A5 Compensating controls | what makes the flaw harder to reach while the patch waits, and the proof it works (P02 EX-07) | |||
Control 1 | [[What it is, on which systems]] | Tested on | [[YYYY-MM-DD]] |
How tested, and result | [[Test performed, by whom, and the result; evidence attached]] | ||
Control 2 optional | [[What it is]] | Tested on | [[YYYY-MM-DD]] |
How tested, and result | [[Test performed and result]] | ||
A6 When the patch will be installed | |||
Date the deferral ends when it is in | [[YYYY-MM-DD]] | Window | [[Window, and who must attend]] |
Lasting fix RO-5: so this does not recur | [[A second node, a standing window, a supplier who certifies in time]] | ||
Owner | [[Name, role]] | Due | [[YYYY-MM-DD]] |
A7 Declaration | |||
System owner the above is complete and accurate | [[Signature, date]] | Patch owner the date in A6 can be met | [[Signature, date]] |
Part B: Assessment
Completed by the Head of Information Security, with the P02 scoring model (P02 EX-04). The requester does not complete this part.
B1 Checks before scoring | |||
Requested before the deadline? P01 VM-16; if not, report it overdue | [[Yes / No]] | Reason accepted? PM-15; if not, refuse | [[Yes: DR-n / No]] |
Priority 1: mitigation in place within 72 hours? DA-1 | [[Yes, since YYYY-MM-DD HH:MM / Not applicable]] | Tested control? P02 EX-07 | [[Yes: which, when / No]] |
B2 Score | P02's model: impact × likelihood after controls | |||
Impact 1 Minor · 2 Moderate · 3 Major · 4 Severe | [[1–4]] | Reason | [[Why this level]] |
Likelihood before controls 1 Unlikely · 2 Possible · 3 Likely · 4 Almost certain | [[1–4]] | Reason | [[Why this level]] |
Likelihood after one step lower with a tested control, never below 1 | [[1–4]] | Score | [[1–16]] |
Band Low 1–3 · Medium 4–6 · High 8–9 · Critical 12–16 | [[Low / Medium / High / Critical]] | ||
B3 Who approves, and for how long | |||
Band's approver from the table below | [[Approver]] | Conflicted? DA-3: requested it, or runs the patching | [[No / Yes: why]] |
Approver after DA-1 and DA-3 | [[Approver]] | Position against appetite DA-2 (P05) | [[Within appetite / outside appetite: P05 approver signs too]] |
Longest deferral days: Low 90 · Medium 90 · High 90 · Critical 30 | [[n days]] | Latest expiry approval date plus that | [[YYYY-MM-DD]] |
Decision due by working days from a complete request | [[YYYY-MM-DD]] | ||
Assessed by | [[Name, role]] | Date | [[YYYY-MM-DD]] |
Part C: Decision
The approver in B3 decides within the band's decision time. The approver may shorten the deferral or add conditions, never extend it past the latest expiry.
C1 Decision | |||
Decision | [[Approved / Approved with conditions / Refused]] | ||
Conditions | [[Conditions, or none]] | ||
Approved on | [[YYYY-MM-DD]] | Expires on no later than B3's latest expiry | [[YYYY-MM-DD]] |
Reason if refused and what happens instead | [[Reason; install by the deadline or report it overdue]] | ||
C2 Signatures | |||
Approver from B3 | [[Name, role]] | Signature and date | [[Signature, date]] |
Risk approver only where DA-2 applies (P05) | [[Name, role / not required]] | Signature and date | [[Signature, date]] |
Critical band decision of the board or its equivalent (DA-4) | [[Body and meeting / not required]] | Minute or decision reference | [[Reference]] |
C3 Exception register | Security Exception Register | |||
Register reference | [[Reference]] | Recorded by, and date | [[Name, date]] |
Part D: Closure
Completed when the patch is in. The deferral closes on the rescan, not on the install (PM-10). The Head of Information Security confirms the evidence before the register entry is closed.
D1 Closure | |||
Installed on | [[YYYY-MM-DD]] | Verified with the scan | [[YYYY-MM-DD: scan reference]] |
What was done | [[Installed in which window, by whom; anything left over]] | ||
Register entry closed | [[YYYY-MM-DD]] | Closed before expiry? | [[Yes / No: days expired]] |
Compensating controls kept or removed | [[Kept / removed on YYYY-MM-DD]] | Lasting fix status | [[Done / on track / late]] |
Verified by | [[Name, role, date]] | ||
Worked example: a supplier that had not certified the update
EXAMPLE. The organisation is the one used throughout the pack: a wholesale distributor with about 900 staff, three warehouses and an online ordering service that takes 60% of its orders. DEF-2026-01: the warehouse management system, WMS-APP-01 (warehouse management system application server); WMS-DB-01 (warehouse management system database server), could not take September's operating system update in its window because its supplier had not certified it. Planned for 20 Sep. The supplier certified the update on 24 Sep, after the window and a day after the deadline, so it was deferred to the 27 Sep window.
Guidance — delete before approval
Note what made this approvable: it was asked for 2 days before the deadline, for an accepted reason with evidence, after the options were worked through, with a tested control and a date. The band's approver, the control owner, runs the patching, so the decision went up to the Head of Information Security (DA-3). The score left the risk within appetite, so no second signature was needed (DA-2).
Delete this worked example from your adopted form.
Part A: Request
Completed by the system owner, with the patch owner, before the deadline passes. Send it to the Head of Information Security with the evidence for A3 and A5 attached.
A1 Requester and systems — EXAMPLE | |||
Requester name and role; usually the system owner | Head of Logistics, system owner (P14 PS-06) | Date requested | 21 Sep 2026 |
System owner owns the risk while the patch waits | Head of Logistics | Patch owner who deploys the patch | IT Operations Manager |
Systems affected by inventory name | WMS-APP-01 (warehouse management system application server); WMS-DB-01 (warehouse management system database server) | Asset class AC-1 to AC-5 | AC-2 Servers |
A2 The patch and its deadline — EXAMPLE | |||
Patch and vendor reference | REL-01: monthly operating system and office software updates, with the month's browser and document reader updates. [[Operating system and office software vendor]] | Released | 8 Sep 2026 |
P01 priority the earliest, if systems differ | Priority 2 | First detected | 9 Sep 2026 |
Deadline first detection plus the priority's days (P01 VM-08) | 23 Sep 2026 | Route and the date it was planned | RT-C: planned for 20 Sep 2026 |
A3 Reason | one code from the accepted list (PM-15): DR-1, DR-2, DR-3, DR-4, DR-5 — EXAMPLE | |||
Reason code | DR-2 | ||
Why, with the evidence the supplier's message, the failed test, the vendor's notice | The system's supplier has not yet certified the patch, and installing it uncertified would end the supplier's support. The supplier (P06 SUP-010, warehouse management system provider) had not certified September's update before the 20 Sep 2026 window; the next Sunday window falls after the deadline. | ||
A4 Options tried | in this order (PM-16); say why each does or does not work — EXAMPLE | |||
RO-1 Use the redundancy | No second database node | ||
RO-2 Agree a window inside the deadline | Dispatch runs round the clock; the Sunday window is the only one, and the 20 Sep window came before certification | ||
RO-3 Live patching | Live patching is not supported for this update | ||
RO-4 Mitigate and defer | Chosen | ||
System past support EO-1, EO-2, EO-3 | Not applicable: the system is supported | ||
A5 Compensating controls | what makes the flaw harder to reach while the patch waits, and the proof it works (P02 EX-07) — EXAMPLE | |||
Control 1 | The host firewall on WMS-DB-01 accepts connections only from WMS-APP-01 and the backup service, so the vulnerable service cannot be reached from anywhere else | Tested on | 21 Sep 2026 |
How tested, and result | Tested on the day of the request, before it was sent; the test record is attached | ||
Control 2 optional | The warehouse networks are separated from the office network (P05 TA-04, done 11 Sep 2026) | Tested on | 11 Sep 2026 |
How tested, and result | Tested when the separation was completed (P05 TA-04) | ||
A6 When the patch will be installed — EXAMPLE | |||
Date the deferral ends when it is in | 27 Sep 2026 | Window | Sunday change window, with the supplier's engineer |
Lasting fix RO-5: so this does not recur | Agree with the supplier that it certifies each month's operating system update within [[5]] working days of the release day, before Window B | ||
Owner | Head of Logistics | Due | 20 Oct 2026 |
A7 Declaration — EXAMPLE | |||
System owner the above is complete and accurate | Head of Logistics, 21 Sep 2026 | Patch owner the date in A6 can be met | IT Operations Manager, 21 Sep 2026 |
Part B: Assessment
Completed by the Head of Information Security, with the P02 scoring model (P02 EX-04). The requester does not complete this part.
B1 Checks before scoring — EXAMPLE | |||
Requested before the deadline? P01 VM-16; if not, report it overdue | Yes: 2 days before | Reason accepted? PM-15; if not, refuse | Yes: DR-2 |
Priority 1: mitigation in place within 72 hours? DA-1 | Not applicable: Priority 2 | Tested control? P02 EX-07 | Yes: control 1, 21 Sep 2026 |
B2 Score | P02's model: impact × likelihood after controls — EXAMPLE | |||
Impact 1 Minor · 2 Moderate · 3 Major · 4 Severe | 3 Major | Reason | Affects a Critical system, personal or customer data, or a regulated service; notifiable if it went wrong. |
Likelihood before controls 1 Unlikely · 2 Possible · 3 Likely · 4 Almost certain | 2 Possible | Reason | Reachable internally; exploitation needs skill or insider access. |
Likelihood after one step lower with a tested control, never below 1 | 1 Unlikely | Score | 3 × 1 = 3 |
Band Low 1–3 · Medium 4–6 · High 8–9 · Critical 12–16 | Low | ||
B3 Who approves, and for how long — EXAMPLE | |||
Band's approver from the table below | Control owner | Conflicted? DA-3: requested it, or runs the patching | Yes. The band's approver is the control owner, the IT Operations Manager, who runs the patching; the approval passes to the next level up (P02 EX-05). |
Approver after DA-1 and DA-3 | Head of Information Security | Position against appetite DA-2 (P05) | Within appetite (Service availability): no second signature |
Longest deferral days: Low 90 · Medium 90 · High 90 · Critical 30 | 90 days | Latest expiry approval date plus that | 21 Dec 2026 |
Decision due by working days from a complete request | 28 Sep 2026 | ||
Assessed by | Head of Information Security | Date | 22 Sep 2026 |
Part C: Decision
The approver in B3 decides within the band's decision time. The approver may shorten the deferral or add conditions, never extend it past the latest expiry.
C1 Decision — EXAMPLE | |||
Decision | Approved with conditions | ||
Conditions | Install in the 27 Sep 2026 window. The host firewall rule stays in place until the rescan is clean (PM-10). | ||
Approved on | 22 Sep 2026 | Expires on no later than B3's latest expiry | 29 Sep 2026 |
Reason if refused and what happens instead | — | ||
C2 Signatures — EXAMPLE | |||
Approver from B3 | Head of Information Security | Signature and date | Head of Information Security, 22 Sep 2026 |
Risk approver only where DA-2 applies (P05) | Not required: within appetite (DA-2) | Signature and date | — |
Critical band decision of the board or its equivalent (DA-4) | Not required: Low band | Minute or decision reference | — |
C3 Exception register | Security Exception Register — EXAMPLE | |||
Register reference | EX-2026-025 | Recorded by, and date | Head of Information Security, 22 Sep 2026 |
Part D: Closure
Completed when the patch is in. The deferral closes on the rescan, not on the install (PM-10). The Head of Information Security confirms the evidence before the register entry is closed.
D1 Closure — EXAMPLE | |||
Installed on | 27 Sep 2026 | Verified with the scan | 28 Sep 2026: targeted rescan clean |
What was done | Installed in the 27 Sep window with the supplier's engineer; verified by rescan on 28 Sep (PM-10). | ||
Register entry closed | 28 Sep 2026 | Closed before expiry? | Yes |
Compensating controls kept or removed | Kept: both stay as standing controls: the database server needs no other connections, and the network separation is P05 TA-04's lasting fix | Lasting fix status | Taken into the supplier's first assessment, booked for 20 Oct 2026 (P06 SUP-010) |
Verified by | Head of Information Security, 28 Sep 2026 | ||
A second example: a system past vendor support
EXAMPLE. DEF-2026-02 shows the same form used for reason DR-4, where no patch exists. It runs until the system is retired, not until a window.
Field | Answer |
|---|---|
A1 Systems affected | NAS-W3: document storage appliance at Warehouse 3 goods-in: scanned delivery notes, which carry customer names and addresses |
A2 Patch and deadline | No patch: the vendor's support ended on 30 Jun 2024. None offered by the vendor. |
A3 Reason | DR-4: No patch exists: the vendor has not released one, or the system is past support (PM-17). |
A4 Options tried | EO-1: still needed until the scans move. EO-2: replacement on 30 Nov 2026. EO-3: the vendor offers no extended support. EO-4 and EO-5 applied. |
A5 Compensating controls | 1. EO-4: Moved to its own network segment, reachable only from the three goods-in PCs at Warehouse 3, with no internet access and its administration interface turned off. Tested 14 Sep 2026 2. EO-5: One administrator account left, and the appliance's access log sent to the security monitoring provider (P06 SUP-006), which alerts on any sign-in or connection from anywhere but the goods-in PCs. Tested 15 Sep 2026 |
A6 Date | Retirement on 30 Nov 2026: move the scans to a share on FS-02 and retire the appliance |
B2 Score | Impact 3, likelihood 3 before and 2 after the tested controls: 6, Medium |
B3 Approver and limit | Head of Information Security; within appetite, so no second signature; latest expiry 15 Dec 2026 |
C1 Decision | Approved on 16 Sep 2026, expiring on 30 Nov 2026, the retirement date. Status at 30 Sep 2026: Open |
C3 Register reference | EX-2026-024 |
The appliance is also in the End-of-Life Software & Unsupported System Register, which reviews it at least quarterly (P01 VM-15) until it is retired. EXAMPLE
Copying the decision into the exception register
Every approved deferral is one row in the Security Exception Register. The register calculates the score, band, approver and latest expiry itself; enter the answers, and check the register's results match B2 and B3.
Register column | From this form |
|---|---|
Exception ID | C3 Register reference |
Exception type | Always 'Policy or standard requirement' |
Title | 'Patch deferral:' and the patch from A2 |
Policy or standard clause not met | The Patch Management Standard, PM-02 (the P01 deadline) |
System or asset | A1 Systems affected |
Requester | A1 Requester |
Risk owner | A1 System owner |
Control owner | A1 Patch owner |
Impact (1–4) | B2 Impact |
Likelihood without compensating control (1–4) | B2 Likelihood before controls |
Compensating control | A5 Control 1 (and 2) |
Compensating control last tested | A5 Tested on |
Compensating control effective | B1 Tested control? |
Request complete date | A1 Date requested, or the date the returned request came back complete |
Decision | C1 Decision |
Decided by | C2 Approver |
Decision date | C1 Approved on |
First start date | C1 Approved on |
Expiry date | C1 Expires on |
Closed date | D1 Register entry closed |
Closure evidence | D1 Verified, with the scan |
Related documents
Document | Relationship |
|---|---|
Patch Management Standard | The rules this form applies: PM-14, PM-15 and PM-16 |
Vulnerability & Exposure Management Standard | The deadline (VM-08), the request before it passes (VM-16), the 90-day limit (VM-17), the Priority 1 approver (VM-18) and overdue escalation (VM-19) |
Security Exception & Waiver Standard | The scoring model, bands, approvers, decision times and renewals |
Security Exception Register | Where every approved deferral is recorded, tracked and closed |
Risk Acceptance Form & Approval Record | The risk approver's signature where a deferral leaves a risk outside appetite (DA-2) |
Monthly Patch Cycle Operating Procedure | Starts a request at CY-01, CY-07 or CY-09 |
Emergency Out-of-Band Patching Procedure | A Priority 1 patch that cannot go in within the deadline |
End-of-Life Software & Unsupported System Register | Systems past vendor support, each with its deferral |
Adapting this template
Guidance — delete before approval
Small organisation: keep Parts A to C; Part D may be the register's closure columns. Where the Head of Information Security is also the person who runs the patching, name who signs instead (DA-3), so nobody approves their own deferral.
Regulated entity (NIS2, DORA): the NIS2 Implementing Regulation lets the entities it covers decide not to apply a patch only with the reasons documented and substantiated, and asks for additional measures and accepted residual risk where a patch is not applied; DORA's technical standards ask for escalation where patch deadlines cannot be met. This form and the register are written to record both. Add a field in A1 for whether the system supports a critical or important function, and keep completed forms for the period your regulator expects.
IT run by a service provider: the provider completes Part A for systems it patches, with its own test evidence for A5. Part B stays with your Head of Information Security, and Part C with your own approvers.
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) and Implementing Regulation (EU) 2024/2690; Regulation (EU) 2022/2554 (DORA) and Delegated Regulation (EU) 2024/1774.
Framework | Reference | Supported by |
|---|---|---|
ISO/IEC 27001:2022 | Annex A 8.8 — Management of technical vulnerabilities | The whole form: a patch not applied on time, with its measures and decision |
ISO/IEC 27001:2022 | Annex A 5.36 — Compliance with policies, rules and standards for information security | The whole form: a departure from the standard requested, approved and recorded |
NIST CSF 2.0 | ID.RA-07 — “Changes and exceptions are managed, assessed for risk impact, recorded, and tracked” | The whole form: each deferral assessed for risk (Part B), recorded and tracked (Parts C and D) |
NIST CSF 2.0 | ID.RA-06 — “Risk responses are chosen, prioritized, planned, tracked, and communicated” | Parts C and D: the decision, its tracking and closure |
NIS2 — Implementing Regulation (EU) 2024/2690 | Article 1 — lays down the technical and methodological requirements of the Article 21(2) measures, and further specifies when an incident is significant, for DNS service providers, TLD name registries, cloud computing, data centre and content delivery network providers, managed service and managed security service providers, providers of online marketplaces, online search engines and social networking services platforms, and trust service providers | Who the Implementing Regulation binds; for other entities it shows what is expected |
NIS2 — Implementing Regulation (EU) 2024/2690 | Annex, point 6.6.1 — “The relevant entities shall specify and apply procedures, coherent with the change management procedures referred to in point 6.4.1 as well as with vulnerability management, risk management and other relevant management procedures, for ensuring that: (a) security patches are applied within a reasonable time after they become available; (b) security patches are tested before being applied in production systems; (c) security patches come from trusted sources and are checked for integrity; (d) additional measures are implemented and residual risks are accepted in cases where a patch is not available or not applied pursuant to point 6.6.2.” | A5 and Part B: additional measures, and the residual risk accepted where a patch is not applied |
NIS2 — Implementing Regulation (EU) 2024/2690 | Annex, point 6.6.2 — “By way of derogation from point 6.6.1(a), the relevant entities may choose not to apply security patches when the disadvantages of applying the security patches outweigh the cybersecurity benefits. The relevant entities shall duly document and substantiate the reasons for any such decision.” | A3 and A4: the reasons for not applying the patch documented and substantiated |
DORA — Regulation (EU) 2022/2554 | Article 9(4)(f) — “have appropriate and comprehensive documented policies for patches and updates” | The whole form, as part of the organisation's patch policies |
DORA — Delegated Regulation (EU) 2024/1774 | Article 10(4) — the patch management procedures shall “(a) to the extent possible identify and evaluate available software and hardware patches and updates using automated tools; (b) identify emergency procedures for the patching and updating of ICT assets; (c) test and deploy the software and hardware patches and the updates referred to in Article 8(2), points (b)(v), (vi) and (vii); (d) set deadlines for the installation of software and hardware patches and updates and escalation procedures in case those deadlines cannot be met.” | Point (d): escalation where a patch deadline cannot be met |
ISO/IEC 27001 references name the clause or control this document relates to. They do not say that meeting it meets any other framework's requirement.
Definitions
Term | Meaning in this form |
|---|---|
Band | The range the P02 score falls in (Low 1–3 · Medium 4–6 · High 8–9 · Critical 12–16), which sets the approver, the decision time and the longest deferral. |
Compensating control | A measure that makes a vulnerability harder to exploit while the patch is not installed: blocking the vulnerable service, restricting who can reach the system, disabling the affected feature or isolating the system. It counts only once it has been tested (P02 EX-07). |
Deadline | The P01 deadline of the finding the patch fixes: first detection plus the days its priority allows. |
Deferral | Installing a patch after its P01 deadline, approved in advance as a P02 exception (PM-14). Moving a patch to a later window that is still inside its deadline is not a deferral. |
Expiry | The date the deferral ends unless renewed: no later than the approval date plus the longest deferral for its band. |
Patch owner | The person who makes sure a system is patched: deploys the patch, or makes sure the team or provider who does it has done so. |
Renewal | A new decision, on a new score, to extend a deferral past its expiry. |
Score | Impact multiplied by likelihood after compensating controls, each 1 to 4, as the P02 model sets out. |
System owner | Agrees the system's maintenance window, checks the service after patching and requests any deferral for it (P01 VM-16). |
Verified | Installed, the service checked by its owner, and a scan no longer finds the vulnerability (P01 VM-13). |