What's changed
Packs are revised when a rule is corrected, a regulation is read again, or a new pack changes what an older document lists. Every change to a published document, newest first.
Security Exception, Waiver & Segregation of Duties
Privileged and emergency access is reviewed within 1 working day of use, not 2, the same deadline the privileged access standard sets for break-glass use (SD-06).
- Security Exception & Waiver Standard 1.2 → 1.3
Stage 4 sends a Critical exception to the board or its equivalent, named by how the organisation is governed as the Standard names it, instead of a placeholder for the management body or its risk committee.
- Exception Lifecycle Operating Procedure 1.2 → 1.3
Emergency and privileged access is reviewed within 1 working day of use, not 2, as the Standard now says (SD-06, E4).
Emergency and privileged access is reviewed within 1 working day of use, not 2, as the Standard now says (SD-06).
- Exception & SoD Responsibility Matrix 1.2 → 1.3
A chronic exception is no longer accepted at the next approval level up; management funds the fix or retires the system, or changes the rule first and accepts any remaining risk in the risk register, as the Standard says. The Instructions and the Metric Definitions say so.
- Exception Ageing & Expiry Dashboard 1.1 → 1.2
Security Policy Management
The regulated-entity tailoring sets every tier's review interval to 12 months, Standards and Procedures included, as the Policy Framework Standard and the procedure say, not only for documents that form part of the ICT risk management framework.
- Policy Register & Review Schedule 1.1 → 1.2
Third-Party Security Risk Management
Step 11 says a finding's deadline counts from the day the review report is issued to the supplier, the one start date every P06 document now uses.
- Supplier Security Assessment Procedure 1.1 → 1.2
Finding deadlines count from the day the review report is issued to the supplier, not from the assessment date, as the assessment procedure and the review report say; the Results sheet has a field for that date, and the proposed due dates stay blank until it is entered.
- Tiered Supplier Security Questionnaire 1.0 → 1.1
Finding deadlines count from the day the review report is issued to the supplier, not from the evidence review date, as the assessment procedure and the review report say; the Review Summary has a field for that date, and the proposed due dates stay blank until it is entered.
User Access Review
The Evidence table says who signs at the close, as the procedure has it: each system owner signs their system's results and the Head of Information Security signs the campaign closed; the campaign coordinator assembles the file and does not sign the results.
- Access Review Methodology 1.1 → 1.2
The Summary sheet records who signs at the close, as the procedure has it: each system owner signs their system's results and the Head of Information Security signs the campaign closed; the campaign coordinator confirms the file is complete. The Instructions and EF-13 say the same.
NIS2 Implementation & Readiness
The note on mappings says the CISO Times Library shows each mapping with how closely the two match and where they differ, and to confirm one against both texts before relying on it, instead of a verification state.
- Guide 1.0 → 1.1
The mappings note no longer says the CISO Times Library shows a verification state; it says what a mapping shows and to confirm it against both texts.
DORA ICT Risk & Resilience Readiness
The note on mappings says that where the CISO Times Library holds a mapping between a DORA requirement and a control, it shows how closely the two match and where they differ, and to confirm it against both texts before relying on it, instead of a verification state.
- Guide 1.0 → 1.1
The mappings note no longer says the CISO Times Library shows a verification state; it says what a mapping shows and to confirm it against both texts.
- DORA Proportionality & Scope Assessment 1.1 → 1.2
- DORA Article-to-Control Mapping Library 1.3 → 1.4
- DORA Readiness Self-Assessment 1.2 → 1.3
- ICT Risk Management Framework Document Template 1.1 → 1.2
- ICT Third-Party Arrangements Register — Working Copy 1.1 → 1.2
- Digital Operational Resilience Testing Programme 1.0 → 1.1
- DORA Documentation & Evidence Checklist 1.1 → 1.2
- DORA Gap & Remediation Tracker 1.1 → 1.2
- Management Body DORA Briefing Deck 1.1 → 1.2
Backup & Restore Assurance
When to escalate sends every failed job not put right in its class's time to the backup owner, as BR-11 says, not only a critical data set's; the critical class keeps the shortest time.
AI Security Governance & Acceptable Use
Internal data, like Confidential, goes into an AI tool only under a contract term that bars the supplier from training on it, as the information classification standard's CL-19 requires; a vendor setting verified off is an added technical control and no longer a substitute. A supplier's written statement no longer stands in for the term.
- AI Acceptable Use & Security Policy 1.0 → 1.1
Hold H-2 applies to Internal data as well as Confidential: either goes in only under a contract term that bars the supplier from training on it, and a setting verified off does not clear the hold. The worked cases and the example's warehouse forecasting module follow it.
- AI Use Case Intake & Approval Procedure 1.0 → 1.1
Check IV-10 asks for a contract term that bars training for Internal data as well as Confidential, as the information classification standard's CL-19 requires; a setting verified off is no longer enough on its own. The example's warehouse forecasting module now has that term.
- AI System & Use Case Inventory 1.0 → 1.1
Hold H-2 applies to Internal data as well as Confidential: either goes in only under a contract term that bars the supplier from training on it, and a setting verified off does not clear the hold.
- AI Use Case Risk & Impact Assessment 1.0 → 1.1
Internal data, like Confidential, needs a contract term that bars the supplier from training on it, as the information classification standard's CL-19 requires; a setting verified off is an added control and no longer enough on its own. The grid, the check and the example's warehouse forecasting module follow it.
Security Questionnaire & Due Diligence Response
The Customer-Facing Security Overview Document is described as built from library answers that may go out as they stand, naming only the evidence their sharing tiers allow, not from Public answers.
- Guide 1.0 → 1.1
Sharing evidence offers a recipient with no non-disclosure agreement a summary only where the summary's own sharing tier is Public, as EV-13 says, not any approved summary. The overview is described as built from library answers that may go out as they stand, naming only the evidence their sharing tiers allow, not from Public answers.
- Questionnaire Response Governance Method 1.0 → 1.1
Steps 3, 4 and 7 and the records no longer say only a Current answer goes out unchanged; a library answer in the state Current, Review due or Evidence expiring goes out as it stands, as QG-05 and the state table say.
How each section is filled says what the template does: a section takes the topic's answers that may go out as they stand, Current, Review due or Evidence expiring, as QG-05 says, not Current answers only.
CISO Transition, Handover & First 90 Days
PL-01 names an inherited exception among the sources a plan item may come from, as TR-14 and the workbook's instructions do.
- 100-Day Security Plan 1.0 → 1.1
Vulnerability & Exposure Management
The Priority 3 note no longer says 30 days meets the payment card standard; it says that standard's month runs from the patch's release, not from detection.
The payment card question, the Priority 3 note and the regulated-entity adaptation no longer say Priorities 1 to 3 meet that standard's one-month period; its month runs from the patch's release, not from detection, so a late-detected finding can miss it inside its own deadline.
- Vulnerability Risk Rating & SLA Model 1.2 → 1.3
NIS2 Implementation & Readiness
Test cases TC-21 to TC-23 answer SQ-03 with Annex I, as the Assessment sheet's check requires of every SQ-04 type; classifications unchanged.
DORA ICT Risk & Resilience Readiness
IM-01 and IM-02's "Operating when" no longer print an internal code name; they name the incident checks.
- DORA Readiness Self-Assessment 1.1 → 1.2
DORA ICT Risk & Resilience Readiness
The Supporting Documents sheet no longer repeats each document's pack name in a column of its own, which the document ID already gives.
- DORA Article-to-Control Mapping Library 1.2 → 1.3
Vulnerability & Exposure Management
Unknown exploitation evidence is treated as not known exploited and checked again at the next weekly triage, as the Inputs table says; the paragraph under the table and the inventory limitation no longer say every missing input makes a finding more urgent.
- Vulnerability Risk Rating & SLA Model 1.1 → 1.2
Board Cybersecurity Reporting
The management body training interval is this pack's default, not the Directive's.
- Board Question Bank & Preparation Brief 1.0 → 1.1
- Board & Executive Reporting Calendar 1.1 → 1.2
ISO 27001 Implementation & Certification Readiness
The training interval is this pack's default, not the Directive's, and the P27 documents are named.
- Annex A Control Implementation Library 1.11 → 1.12
NIS2 Implementation & Readiness
Names the P27 documents.
The training interval is this pack's default, not the Directive's.
Patch Management
Unknown exploitation evidence counts as not known exploited and is checked again at the next weekly triage, as the P01 model says; only exposure, severity and criticality default to the more urgent value.
- Monthly Patch Cycle Operating Procedure 1.0 → 1.1
Security Control Assurance
Names the P27 documents.
DORA ICT Risk & Resilience Readiness
A financial entity that sells ICT services is also a supplier, and any Priority 1 gap goes to the chair route.
- DORA Proportionality & Scope Assessment 1.0 → 1.1
- DORA Article-to-Control Mapping Library 1.1 → 1.2
- DORA Readiness Self-Assessment 1.0 → 1.1
- ICT Risk Management Framework Document Template 1.0 → 1.1
- ICT Third-Party Arrangements Register — Working Copy 1.0 → 1.1
- DORA Gap & Remediation Tracker 1.0 → 1.1
- Management Body DORA Briefing Deck 1.0 → 1.1
Lists the P26 documents among the supporting documents.
- DORA Article-to-Control Mapping Library 1.0 → 1.1
- DORA Documentation & Evidence Checklist 1.0 → 1.1
CISO Transition, Handover & First 90 Days
Published. The guide and nine documents, at 1.0.
ISO 27001 Implementation & Certification Readiness
Names the P24 documents.
- Annex A Control Implementation Library 1.9 → 1.10
- Mandatory ISMS Documentation Checklist 1.6 → 1.7
- Stage 1 and Stage 2 Audit Preparation Guide 1.6 → 1.7
Names the P26 documents.
- Annex A Control Implementation Library 1.10 → 1.11
NIS2 Implementation & Readiness
Names the P24 documents.
Names the P25 documents.
Names the P26 documents.
AI Security Governance & Acceptable Use
Published. The guide and eight documents, at 1.0.
Generative AI Security
Published. The guide and eight documents, at 1.0.
Security Questionnaire & Due Diligence Response
Published. The guide and eight documents, at 1.0.
ISO 27001 Implementation & Certification Readiness
Names the P21 documents.
- Annex A Control Implementation Library 1.8 → 1.9
- Mandatory ISMS Documentation Checklist 1.5 → 1.6
- Stage 1 and Stage 2 Audit Preparation Guide 1.5 → 1.6
DORA ICT Risk & Resilience Readiness
Published. The guide and nine documents, at 1.0.
ISO 27001 Implementation & Certification Readiness
Names the P23 documents.
- Annex A Control Implementation Library 1.7 → 1.8
- Mandatory ISMS Documentation Checklist 1.4 → 1.5
- Stage 1 and Stage 2 Audit Preparation Guide 1.4 → 1.5
NIS2 Implementation & Readiness
Adds the P23 documents under measure (c), business continuity and backup management.
Security Maturity & Internal Assessment
DM-14 names P23.
- Security Maturity Model & Scoring Method 1.1 → 1.2
- Security Programme Maturity Assessment 1.1 → 1.2
- Assessment Evidence Request Checklist 1.2 → 1.3
- Maturity Findings & Improvement Tracker 1.2 → 1.3
Security Control Assurance
The restore-testing note names P23's Restore Testing Methodology.
- Control Testing Methodology 1.1 → 1.2
- Control Inventory & Ownership Register 1.1 → 1.2
- Unified Control Framework Mapping Workbook 1.1 → 1.2
- Control Assurance Dashboard 1.1 → 1.2
Cyber Resilience & Recovery
RR-11 points to P23 for other restore checks.
RR-11 points to P23 for other restore checks and retention.
- Cyber Recovery Operating Procedure 1.0 → 1.1
Third-Party Security Risk Management
The note on CL-07 now says the customer's clocks start at the supplier's notice, as the GDPR guidance reads it, so the case for a short notice period is acting sooner, not running out of time.
ISO 27001 Implementation & Certification Readiness
The Catalogue support column now names the regulatory incident notification documents now published (P18).
- Annex A Control Implementation Library 1.3 → 1.4
The Catalogue support column now names the security maturity assessment documents now published (P19).
- Annex A Control Implementation Library 1.4 → 1.5
The Catalogue support column now names the security control assurance documents now published (P20).
- Annex A Control Implementation Library 1.5 → 1.6
Names the P22 documents.
- Annex A Control Implementation Library 1.6 → 1.7
- Mandatory ISMS Documentation Checklist 1.3 → 1.4
- Stage 1 and Stage 2 Audit Preparation Guide 1.3 → 1.4
Security Incident Management
RD-10 now states DORA's rule for an incident classified as major only after 24 hours: the initial notification is due within 4 hours of that classification (Delegated Regulation (EU) 2025/301, Article 5(2)).
- Security Incident Management Policy 1.1 → 1.2
- Incident Response Plan 1.1 → 1.2
- Incident Triage & First-Hour Assessment Procedure 1.1 → 1.2
- Ransomware Response Playbook 1.1 → 1.2
- Incident Communications Template Set 1.0 → 1.1
RD-10 now states DORA's rule for an incident classified as major only after 24 hours: the initial notification is due within 4 hours of that classification (Delegated Regulation (EU) 2025/301, Article 5(2)); the clock calculator applies it.
The example restore order follows the continuity plan: foundations, then the shortest recovery time first, with the targets from P22 (RR-08).
- Ransomware Response Playbook 1.2 → 1.3
Cyber Incident Exercises & Tabletop Scenario Library
DORA Article 11(6) quoted in full: the yearly test covers ICT systems supporting all functions.
- Tabletop Exercise Design Methodology 1.1 → 1.2
- Exercise Planning & Facilitation Procedure 1.0 → 1.1
- Tabletop Scenario — Ransomware Encryption of Core Systems 1.1 → 1.2
- Tabletop Scenario — Critical Supplier Outage 1.0 → 1.1
- Tabletop Scenario — Executive Payment Fraud 1.0 → 1.1
- Exercise Logistics & Participant Readiness Checklist 1.0 → 1.1
- Exercise Observations & Improvement Tracker 1.0 → 1.1
- Exercise After-Action Report Template 1.0 → 1.1
Cybersecurity Metrics & Reporting Programme
MC-35 shows the ordering platform's monthly restore check (P10 EA-04): 0 of 4.
NIS2 Implementation & Readiness
Lists the published security maturity assessment documents (P19) that support measure (f).
Lists the published security control assurance documents (P20) that support measure (f).
Names the P22 documents.
Counts the published security maturity assessment documents (P19) the measure library now lists.
- NIS2 Documentation & Evidence Checklist 1.1 → 1.2
Counts the published security control assurance documents (P20) the measure library now lists.
- NIS2 Documentation & Evidence Checklist 1.2 → 1.3
Regulatory Incident Notification & Reporting
Quotes P09's corrected RD-10 deadline.
Published. The guide and seven documents, at 1.0.
Security Maturity & Internal Assessment
DM-14 Recovery and continuity names P22.
- Security Maturity Model & Scoring Method 1.0 → 1.1
- Security Programme Maturity Assessment 1.0 → 1.1
- Assessment Evidence Request Checklist 1.1 → 1.2
- Maturity Findings & Improvement Tracker 1.1 → 1.2
- Maturity Assessment Report Template 1.1 → 1.2
- Target-State Maturity Roadmap 1.0 → 1.1
MP-24 names the monthly restore check of the ordering platform (P10 EA-04).
- Assessment Evidence Request Checklist 1.0 → 1.1
- Maturity Findings & Improvement Tracker 1.0 → 1.1
- Maturity Assessment Report Template 1.0 → 1.1
Published. The guide and eight documents, at 1.0.
Security Control Assurance
The restore-testing note names P22's RR-14.
- Control Testing Methodology 1.0 → 1.1
- Control Inventory & Ownership Register 1.0 → 1.1
- Unified Control Framework Mapping Workbook 1.0 → 1.1
- Control Assurance Dashboard 1.0 → 1.1
Published. The guide and nine documents, at 1.0.
Cyber Resilience & Recovery
Published. The guide and eight documents, at 1.0.
Backup & Restore Assurance
Published. The guide and eight documents, at 1.0.
ISO 27001 Implementation & Certification Readiness
The Catalogue support column now names the access, privileged access, classification, awareness and patch management documents now published (P13 to P17).
- Annex A Control Implementation Library 1.2 → 1.3
- Mandatory ISMS Documentation Checklist 1.2 → 1.3
The blocking-item support table now names the access, privileged access, classification, awareness and patch management documents now published (P13 to P17).
NIS2 Implementation & Readiness
Lists the published access, privileged access and classification documents that support each measure.
Counts the published access, privileged access and classification documents the measure library now lists against each measure.
- NIS2 Documentation & Evidence Checklist 1.0 → 1.1
Joiner-Mover-Leaver & Access Provisioning
Rewritten to the depth of the other CISO Times packs: the principles, the lifecycle events and who approves access now come before the rules; every rule names its evidence; the timings are gathered in one table with the shortcuts the policy rules out; each role lists what it answers for and does; the measures, exceptions and conflicts of duties are explained; and a worked example of the first quarter is added.
- Access Control Policy 1.0 → 2.0
Rewritten to the depth of the other CISO Times packs: each lifecycle event now has numbered steps with who does them, when and what they leave behind, and a worked example from the month; the conflict check on a mover's whole access, role profiles, resets, systems outside single sign-on and the monthly reconciliation are explained step by step; timing targets, escalation and the evidence kept are added.
- Joiner-Mover-Leaver Operating Procedure 1.0 → 2.0
Rewritten to the depth of the other CISO Times packs: the base and seven role profiles with their system owners' approvals and review dates, a matrix view, a conflict check of every profile and every mover's resulting access (JML-06), and the method for building profiles with the example's coverage.
- Role-Based Access Profile Matrix 1.0 → 2.0
Rewritten to the depth of the other CISO Times packs: the form now comes with when to use it, who approves, the route a request takes, guidance for each field and the decision in order; each part's fields carry hints; and two worked requests, one granted and one capped by a contractor's end date, and a request the conflict check stops, are added.
- Access Request & Approval Form 1.0 → 2.0
Rewritten to the depth of the other CISO Times packs: one row per leaver with the removal deadline JML-09 sets, one row per required removal with its confirmation in the system (JML-14), the full checklist by group, the month's JMM-01 with the results by system, the late removal and what went to the access review, and a signature block.
- Leaver Access Removal Checklist 1.0 → 2.0
Rewritten to the depth of the other CISO Times packs: every lifecycle event with its source record, approvers, maker, the deadline it sets and whether it was met, a record check for JML-04, JML-05, JML-07 and JML-14, the live non-standard rights with JMM-04, the lifecycle events, approvals and evidence, and a Summary by event with the example's three late entries.
- Access Provisioning Log 1.0 → 2.0
Rewritten to the depth of the other CISO Times packs: the sixteen activities with accountable and responsible roles named by formula, role holders with deputies and duty counts, who answers for each step of each lifecycle event, and a separation check that no role both approves access and makes the change (JML-05, P02 SOD-IT-01).
- Identity Lifecycle Responsibility Matrix 1.0 → 2.0
Rewritten to the depth of the other CISO Times packs: the four measures with three months, target, tolerance, status in P11's words and direction, the summary for the leadership team, what went to the access review and where the measures go, and the leavers, movers and orphaned accounts behind the figures, each checked against JML-08, JML-09 and JML-15.
Published. The guide and eight documents, at 1.0.
Privileged Access Management
Rewritten to the depth of the other CISO Times packs: principles come before the rules, and every rule now names its evidence and the control test that checks it; the tiers come with what an account may do on each, the account types with worked rotation dates, sign-in with the rollout as it stood, approval with the durations used, and emergency access with a worked use; service accounts, leavers, suppliers, the control review, the measures and exceptions are explained; and a worked example of the first two weeks is added.
- Privileged Access Standard 1.0 → 2.0
Rewritten to the depth of the other CISO Times packs: each step from request to removal now names who does it, when and what it leaves behind, with the approver's questions in order; the out-of-hours route, removal for leavers, movers and suppliers, privileged resets, unowned service accounts and tier breaches each have their steps and a worked example from the quarter; inputs, the elevation record, timing targets and records are added.
Rewritten to the depth of the other CISO Times packs: all 22 of the example's accounts with their rights, tiers, sign-in method, just-in-time status and credential; next change and rotation status from the rotation table; owner, tier and rights checks; a Discovery sheet with the claim and disable deadlines; the service account steps and removal times; and a Summary giving PAM-01, PAM-02 and PAM-04.
- Privileged & Service Account Inventory 1.0 → 2.0
Rewritten to the depth of the other CISO Times packs: each account's tests, next test due and count against PA-12; the ten checks for every account with evidence and follow-up; each use timed against PA-12's deadlines with the review delay in working days; the five after-use steps with the example's completion; and a Summary with readiness, PAM-06 and a signature block.
- Break-Glass Account Control Checklist 1.0 → 2.0
Rewritten to the depth of the other CISO Times packs: a scope of every system with its review interval and next review due; the thirteen tests for each system with evidence and a record check; a test guide with the evidence to keep and the route without a PAM platform; findings and actions with statuses against the as-at date; and a summary of results by system with a signature block.
Rewritten to the depth of the other CISO Times packs: the record now comes with its schedule, who may review, the log sources, the steps, what each of the seven questions looks for and field guidance; each part's fields carry hints; and two worked reviews are added, the first weekly Tier 0 review with its tier breach and the break-glass use reviewed late.
- Privileged Session Review Record 1.0 → 2.0
Rewritten to the depth of the other CISO Times packs: the three tiers side by side with their elevation limits, review cadence and approvers; every system and directory group with its tier; the separation matrix by formula; every enabled account's rights checked against it, flagging an account that reaches two tiers; the rules with their built-in enforcement; and a breach register with the steps, deadlines and completion.
Rewritten to the depth of the other CISO Times packs: the seven headline measures with three months, target, tolerance, status in P11's words and direction; definitions and settings on a Metrics sheet; monthly values with their sources; the findings behind the measures with the next action due; and the reporting levels and PA-18.
- Privileged Access Metrics Dashboard 1.0 → 2.0
Published. The guide and eight documents, at 1.0.
Information Classification & Handling
Rewritten with the rest of the pack to the depth of the other CISO Times packs: who the pack is for; the three levels with the impact ratings read from the risk scale and the markers that sit on top; a worked quarter at the distributor; the three documents to start with; a first-month plan; the four measures to report; adapting it for a small organisation, suppliers and access; and where it maps.
- Guide 1.0 → 2.0
Rewritten to the depth of the other CISO Times packs: the levels now come with their meaning, labels and examples; impact is read from the risk scale; the decision has its special cases and worked decisions; rules CL-13 to CL-20 are added; every statement names its evidence; roles, measures, exceptions and a worked example of the first quarter are added.
Rewritten to the depth of the other CISO Times packs: the 10 actions at each of the 3 levels, with the rules each applies and the other packs it relies on; the levels, the three markers and the rules on one sheet; labelling for 8 media; and a lookup that gives the rule, the label and the marker rules for any piece of information, checked for special category data and legal holds, with the distributor's worked example.
Rewritten to the depth of the other CISO Times packs: the decision in eight steps with owners, times and outputs; labels for every medium; the setup for a Confidential asset; reclassification triggers; the quarterly handling check; legal holds, disposal and the certificate check; reporting mishandling; and three worked examples from the distributor's quarter.
- Classification & Labelling Procedure 1.0 → 2.0
Rewritten to the depth of the other CISO Times packs: the 16 register fields in full, the three impacts on the risk scale with the level they give beside the owner's level, markers, access, retention and a calculated review date; a change log and legal holds; a Summary with the measures ICM-01 and ICM-02; a Field guide; and the distributor's 17 assets as the worked example.
- Information Asset Register 1.0 → 2.0
Rewritten to the depth of the other CISO Times packs: impact criteria for 5 areas on the risk scale's four impact levels, the three questions with examples, and the decision steps and special cases; an impact-by-area worksheet that rates an asset on its own and combined (CL-13); the assessment of every asset with ratings, markers, the level they give and the owner's decision; the reclassification record and its triggers; a summary; and the distributor's 17 assets and re-rated price export as the worked example.
Rewritten to the depth of the other CISO Times packs: a checklist of 21 items in 5 areas for each disposal batch, with critical items and a closed status; a disposal log that checks the method, the certificate window and the chase for each batch; a tag-by-tag reconciliation of manifest and certificate; the three methods for 10 media types at each level, the certificate's fields and the providers' tiers; a Summary with ICM-04 and a signature block; and the distributor's quarter of disposals, with a laptop missing from a certificate, as the worked example.
- Secure Information Disposal Checklist 1.0 → 2.0
Rewritten to the depth of the other CISO Times packs: a one-page card in staff words, everyday examples drawn from the register, a twenty-minute briefing script with what to say, show and ask, short and team versions, the questions staff ask, scenarios, a follow-up message and a briefing record.
Rewritten to the depth of the other CISO Times packs: the 14 activities RS-01 to RS-14, each with the rule it serves, against 6 roles including the privacy and records roles, checked for one accountable role; role holders and deputies with their counts; the owner and custodian of every asset in the register; an ownership check; and the distributor's owners as the worked example.
Published. The guide and eight documents, at 1.0.
Security Awareness Programme
Published. The guide and eight documents, at 1.0.
Patch Management
Published. The guide and eight documents, at 1.0.
Vulnerability & Exposure Management
The small-team note gives the deadlines behind the weekly meeting: a Priority 1 finding is mitigated within 72 hours and fixed within 7 days, and 14 days is the tightest deadline for other findings.
- Guide 1.0 → 1.1
The definition of internet-facing now also names third-party connections, and every P01 document uses it word for word. Section 4.3: fixes are proved by a targeted rescan, so closure never waits for the scanning schedule; internet-facing web applications are scanned at least monthly and internal ones quarterly. Section 7 defers to the organisation's exception standard, and the more senior approver and the shorter duration apply.
Internet-facing now includes partner links, guest Wi-Fi and third-party connections, as the Standard defines it. Priority 1 exceptions go to the approver the Standard's VM-18 names, which may be the more senior approver of the organisation's exception standard.
The definition of internet-facing now names partner links, guest Wi-Fi and third-party connections, word for word as the Standard has it. A Priority 1 exception goes to the approver the Standard's VM-18 names, which may be the more senior approver of the organisation's exception standard.
- Vulnerability Risk Rating & SLA Model 1.0 → 1.1
Internet-facing now includes partner links, guest Wi-Fi and third-party connections, as the Standard defines it. The As-at date ships as a fixed date instead of TODAY(), so the file does not change from day to day; set it to today's date or type =TODAY(). The frequencies note now covers end-user devices and internet-facing web applications.
- Scan Coverage & Asset Scope Register 1.0 → 1.1
Internet-facing now includes partner links, guest Wi-Fi and third-party connections, as the Standard defines it. A two-weekly review now carries the Standard's two conditions. The Suggested priority now applies the model's criticality uplift (RM-05). Priority 1 exceptions go to the approver VM-18 names. The As-at date ships as a fixed date instead of TODAY(), so the file does not change from day to day; set it to today's date or type =TODAY().
- Vulnerability Remediation Tracker 1.0 → 1.1
Internet-facing now includes partner links, guest Wi-Fi and third-party connections, as the Standard defines it. SF-06 checks internet-facing web applications at least monthly and internal ones at least quarterly, as the Standard now sets them. SF-04 and SF-05 say plainly that end-user devices are scanned continuously by an agent or at least monthly, and cloud infrastructure assessed continuously by a posture tool or at least weekly.
The definition of Priority now names all four inputs of the Vulnerability Risk Rating & SLA Model, asset criticality included. EXAMPLE finding VUL-0005 is on a High criticality system, so its suggested Priority 3 is what the model gives (a Critical system would be raised to Priority 2, RM-05).
PRI-01's Defined level and the Prioritisation action now include asset criticality, the fourth input of the Vulnerability Risk Rating & SLA Model. A two-weekly triage counts for OWN-02 only with the Standard's two conditions.
The exceptions slide's notes name the approver the Standard's VM-18 now names for Priority 1 exceptions.
Security Exception, Waiver & Segregation of Duties
The Critical band's approver is the board or its equivalent, by how the organisation is governed: the board or a board risk committee it has delegated to, the management board in a two-tier structure, or executive management where there is no board, instead of executive management.
- Guide 1.0 → 1.1
Renewal is due before expiry, and the grace period after expiry is for a late renewal, which is reported (EX-08, EX-10); a gap kept for good means changing the rule first, then accepting any remaining risk in the risk register.
- Security Exception & Waiver Standard 1.1 → 1.2
The grace period after expiry is for a late renewal, which is reported, since renewal is due before expiry; the worked example is returned for a missing remediation date, not for untested control evidence, which is scored with the model's default.
- Exception Lifecycle Operating Procedure 1.1 → 1.2
The Critical signature is the decision of the board or its equivalent, as the band table names it by structure; field guidance says which weak answers return a request and which are scored with the model's defaults.
An unknown input with a default is scored with that default, and a request missing any other input is returned; a gap kept for good means changing the rule first, then accepting any remaining risk in the risk register.
- Exception Risk Scoring & Expiry Model 1.1 → 1.2
The As-at date is a fixed date (the example rows' date) instead of TODAY(), so the example statuses do not change from day to day; adopters set today's date or type =TODAY(). The Critical example is decided by the board risk committee, the top body the Standard names for an organisation with a board.
- Security Exception Register 1.1 → 1.2
A conflicted approver's decision passes to the next level up, as the Standard requires (SOD-EM-02, EX-05); the As-at date is a fixed date (the example rows' date) instead of TODAY(), so the example statuses do not change from day to day.
- Segregation of Duties Conflict Matrix 1.0 → 1.1
Writing and deploying your own code is a High conflict, as the conflict matrix rates it (SOD-IT-05); a rating is lowered only with a recorded reason and a working review.
A chronic exception is fixed, or the rule is changed first and any remaining risk accepted in the risk register; a permanent exception is a rule that no longer reflects policy.
- Exception & SoD Responsibility Matrix 1.1 → 1.2
Board Cybersecurity Reporting
The worked example's BM-02 counts Priority 1 and Priority 2 weaknesses, each against its own deadline (7 and 14 days), as the Vulnerability & Exposure Management pack sets them; BM-06 counts the five critical services of the Third-Party Security Risk Management pack's example, so the example reads 2 of 5 (40%), not 2 of 4.
- Board Reporting Narrative Model 1.1 → 1.2
The worked example's BM-08 direction reads 'Not comparable' instead of 'Better': the staff training definition changed on 26 Jun 2026, so June's 88% counted something else and no trend is drawn across the break (as the Cybersecurity Metrics & Reporting pack records it, MR-09).
- Board Reporting Narrative Model 1.2 → 1.3
The EXAMPLE slide's BM-02 counts Priority 1 and Priority 2 weaknesses, each against its own deadline (7 and 14 days), as the Vulnerability & Exposure Management pack sets them; BM-06 counts the five critical services of the Third-Party Security Risk Management pack's example, so the example reads 2 of 5 (40%), not 2 of 4.
- Board Cybersecurity Report Deck Template 1.0 → 1.1
The EXAMPLE slide's BM-08 direction reads 'Not comparable' instead of 'Better': the staff training definition changed on 26 Jun 2026, so June's 88% counted something else and no trend is drawn across the break (as the Cybersecurity Metrics & Reporting pack records it, MR-09). The measures slide's notes say what to do when a definition changes; the EXAMPLE table is set a point smaller so the longer cell fits.
- Board Cybersecurity Report Deck Template 1.1 → 1.2
BM-02 counts Priority 1 and Priority 2 weaknesses, each against its own deadline (7 and 14 days), as the Vulnerability & Exposure Management pack sets them, in its definition and the EXAMPLE target; BM-06 counts the five critical services of the Third-Party Security Risk Management pack's example, so the example reads 2 of 5 (40%), not 2 of 4, with a 20% tolerance.
- Board Metric Selection Catalogue 1.0 → 1.1
The EXAMPLE figures follow the board measures: BM-02 counts Priority 1 and Priority 2 weaknesses, each against its own deadline (7 and 14 days), as the Vulnerability & Exposure Management pack sets them; BM-06 counts the five critical services of the Third-Party Security Risk Management pack's example, so the example reads 2 of 5 (40%), not 2 of 4.
- Board Reporting Data Collection Workbook 1.0 → 1.1
The EXAMPLE BM-08 row leaves last period blank and its direction reads 'Not comparable': the staff training definition changed on 26 Jun 2026, so June's 88% counted something else and no trend is drawn across the break (as the Cybersecurity Metrics & Reporting pack records it, MR-09). Direction reads 'Not comparable' where 'No previous value' was, and the instructions say to leave last period blank when a definition changes.
- Board Reporting Data Collection Workbook 1.1 → 1.2
The EXAMPLE one page: BM-02 counts Priority 1 and Priority 2 weaknesses, each against its own deadline (7 and 14 days), as the Vulnerability & Exposure Management pack sets them; BM-06 counts the five critical services of the Third-Party Security Risk Management pack's example, so the example reads 2 of 5 (40%), not 2 of 4.
- Cyber Risk One-Page Board Summary 1.0 → 1.1
The As-at date on the Year View ships as the EXAMPLE quarter end (2026-09-30) instead of TODAY(), so the EXAMPLE statuses and the preview read the same on any day; the instructions say to set it or type =TODAY().
- Board & Executive Reporting Calendar 1.0 → 1.1
DIR-01 and the definition of Direction accept 'Not comparable' where a measure's definition changed, as the reporting pack now says, instead of treating it as a missing trend.
- Board Reporting Effectiveness Self-Check 1.1 → 1.2
Security Policy Management
A procedure is approved by the Head of Information Security, with the process owner consulted, and the guide says who approves the top policy: the board or its equivalent, by how the organisation is governed, and in a NIS2 or DORA entity the management body itself, not a committee it has delegated to.
- Guide 1.0 → 1.1
The top policy is approved by the board or its equivalent, and in a NIS2 or DORA entity by the management body itself.
- Policy Framework Standard 1.0 → 1.1
- Policy Lifecycle Operating Procedure 1.0 → 1.1
A policy is approved by executive management, and the top policy by the board or its equivalent, and in a NIS2 or DORA entity by the management body itself.
- Security Policy Document Template 1.0 → 1.1
The top policy is approved by the board or its equivalent, and by the management body itself in a regulated entity; other policies by the Policy tier's approver, not by a delegate the management body names.
- Security Policy Hierarchy & Document Map 1.0 → 1.1
The Policy tier's approver reads Executive management; who approves the top policy is set in the Policy Framework Standard.
- Policy Register & Review Schedule 1.0 → 1.1
- Policy Health & Attestation Reporting Workbook 1.0 → 1.1
The Policy tier's approver reads executive management; who approves the top policy is set in the Policy Framework Standard.
- Policy Coverage Gap Assessment 1.0 → 1.1
The Policy approval row names the board or its equivalent, by structure, as the approver of the top policy.
Information Security Risk Management
Only the board or its equivalent may accept a risk above tolerance, and the guide says who that is by how the organisation is governed.
- Guide 1.0 → 1.1
A control that has failed, or is found not to work, is now a reassessment trigger (RM-10), as the Limitations section already said. Example 3 says the acceptance form is optional within appetite and no new decision is required.
A control that has failed, or is found not to work, is now a trigger in Stage 8 (RM-10), as the methodology says.
A failed control is a trigger; a small organisation starts with 10 to 15 risks, as the methodology says; for a Critical risk, Who may accept reads 'The band's approvers recommend; only the board or its equivalent may accept', and so does the outside-tolerance record check; a risk within appetite needs no new decision and the acceptance form is optional for it.
- Information Security Risk Register 1.1 → 1.2
A risk within appetite needs no new decision, only the owner's quarterly review, as the methodology says; a failed control is a reason for reassessment; Who may accept for a Critical risk uses the methodology's words; the top approver is 'the board or its equivalent'; the BM-02 target follows P03.
- Risk Assessment Workbook 1.1 → 1.2
Part C: for a Critical risk the band's approvers recommend and the board or its equivalent decides, so one body is no longer named as both; the board is named as 'the board or its equivalent' throughout Part C and the steps.
- Risk Acceptance Form & Approval Record 1.1 → 1.2
Quotes P03's corrected board-measure wording (Priority 1 and 2).
- Risk Reporting Dashboard 1.0 → 1.1
Third-Party Security Risk Management
A Minimal-tier supplier is re-screened at renewal as well as when the service changes.
- Guide 1.0 → 1.1
Rejecting or exiting a Tier 1 supplier is decided by the board or its equivalent; executive management decides it only where there is no board. The Policy-tier approver reads executive management, as the Policy Framework Standard sets it.
- Third-Party Security Policy 1.0 → 1.1
A Tier 4 supplier is re-screened at renewal as well as when the service changes; a supplier that moves down a tier at renewal keeps its evidence until its next scheduled reassessment, as the tiering model says; rejecting or exiting a Tier 1 supplier is decided by the board or its equivalent.
- Supplier Security Assessment Procedure 1.0 → 1.1
Tier 3 samples 3 answers against evidence, as the assessment procedure says; a Tier 4 supplier is re-screened at renewal as well as when the service changes.
CL-15 now lets the customer terminate for a material or repeated breach of the security clauses, vulnerability management (CL-08) included; a refused clause is always an exception, co-signed by the risk approver where it leaves the supplier outside appetite, as the policy says.
A Tier 4 supplier is re-screened at renewal as well as when the service changes, as the tiering model says.
- Supplier Security Risk Register 1.0 → 1.1
User Access Review
A Cannot decide decision needs a reason, as Modify and Revoke do.
- Access Review Methodology 1.0 → 1.1
Reviewers give a reason for Cannot decide, as for Modify and Revoke.
Last review is the campaign's extract date, not its close date, so the review frequency counts from when access was last examined, as the methodology says.
- Access Review Scope & System Inventory 1.0 → 1.1
A reviewer no longer keeps a dormant account: they choose Cannot decide with the reason, and only the system owner may keep it and records why.
ISO 27001 Implementation & Certification Readiness
Narrowing the scope to meet a date is allowed only where the scope still passes every scope test, or by leaving out a service not yet run for the operating period, added at surveillance; group IT that runs systems the scope depends on is included, not named as an interface.
The Catalogue support column now names the published P09 and P10 documents (and P06-A10, P07-A05) instead of 'more planned'.
- Annex A Control Implementation Library 1.0 → 1.1
The Catalogue support column now names the metrics and NIS2 documents now published (P11, P12) where it said 'more planned' or 'None yet'.
- Annex A Control Implementation Library 1.1 → 1.2
The Catalogue support column now names the published P09 and P10 documents instead of 'Coming'.
- Mandatory ISMS Documentation Checklist 1.0 → 1.1
The Catalogue support column now names the NIS2 documents now published (P12) where it said they were coming.
- Mandatory ISMS Documentation Checklist 1.1 → 1.2
The 30- and 90-day corrective action targets are labelled as internal audit targets, and a certification body's finding follows the period that body sets.
The blocking-item support table now names the published P09 and P10 documents instead of 'coming' packs.
The blocking-item support table now names the NIS2 documents now published (P12) where it said a pack was coming.
Security Incident Management
In a small organisation one person can hold several roles, but the incident manager and the executive incident lead are always two different people, each with a deputy.
- Guide 1.0 → 1.1
IM-08 now says the incident manager contains at once with the least disruptive action, and brings in the service owner and specialists before stopping a service people depend on for safety or essential operations. The Policy-tier approver reads executive management, as the Policy Framework Standard sets it.
- Security Incident Management Policy 1.0 → 1.1
Containment is least disruptive first, and the service owner and specialists come in before a service people depend on for safety or essential operations is stopped.
- Incident Response Plan 1.0 → 1.1
Step F4 contains with the least disruptive action and brings in the service owner and specialists before stopping a service people depend on for safety or essential operations.
Containment and site isolation step S3 are least disruptive first, with the service owner and specialists brought in before a service people depend on for safety or essential operations is stopped; the incident manager and executive incident lead are two people even in a small organisation.
- Ransomware Response Playbook 1.0 → 1.1
The first-hour containment step now says to use the least disruptive containment that stops the harm, as IM-08 does.
- Personal Data Breach Response Playbook 1.0 → 1.1
Part L counts every open action past its due date in IMM-03, as the policy defines the measure, not only those more than 30 days late.
- Post-Incident Review Template 1.0 → 1.1
Published. The guide and eleven documents, at 1.0.
Cyber Incident Exercises & Tabletop Scenario Library
The worked containment step now uses the least disruptive containment that stops the harm, and brings in the service owner and specialists before stopping a service people depend on for safety or essential operations, as P09's IM-08 now says.
- Tabletop Exercise Design Methodology 1.0 → 1.1
The facilitator notes quote P09's corrected IM-08: least disruptive containment first, with the service owner and specialists brought in before stopping a service people depend on for safety or essential operations.
Published. The guide and eleven documents, at 1.0.
Cybersecurity Metrics & Reporting Programme
Published. The guide and nine documents, at 1.0.
NIS2 Implementation & Readiness
Published. The guide and nine documents, at 1.0.
Security Exception, Waiver & Segregation of Duties
A Critical exception is decided by the board or its equivalent, named by how the organisation is governed: the board or a board risk committee it has delegated to, the management board in a two-tier structure, or executive management where there is no board. Executive management approves Critical exceptions itself only where there is no board, and a Critical renewal beyond its limit goes to the full board or its equivalent (EX-08).
- Security Exception & Waiver Standard 1.0 → 1.1
Executive management approves Critical exceptions only where there is no board, otherwise taking them to the board or its equivalent, named by how the organisation is governed; a Critical renewal beyond its limit goes to the full board or its equivalent (EX-08); and the note on deciding between meetings speaks of the Critical approver, not the management body.
- Exception Lifecycle Operating Procedure 1.0 → 1.1
The Critical band's approver is the board or its equivalent, named by how the organisation is governed (the board or a board risk committee it has delegated to, the management board in a two-tier structure, or executive management where there is no board), instead of executive management.
The Critical band's approver is the board or its equivalent, named by how the organisation is governed, instead of executive management, and the next level up for a Critical renewal is the full board or its equivalent; the worked example's approver and renewal route read the same way.
- Exception Risk Scoring & Expiry Model 1.0 → 1.1
The band list and the definitions of Approver required and Renewal limit name the Critical approver as the board or its equivalent, named by how the organisation is governed, instead of executive management, and the next level up as the full board or its equivalent.
- Security Exception Register 1.0 → 1.1
The decision on a Critical exception is for the board or its equivalent, named by how the organisation is governed; executive management approves Critical exceptions only where there is no board, and the next level up above Critical is the full board or its equivalent.
- Exception & SoD Responsibility Matrix 1.0 → 1.1
The Critical band's approver is the board or its equivalent, named by how the organisation is governed, instead of executive management.
- Exception Ageing & Expiry Dashboard 1.0 → 1.1
Published. The guide and nine documents, at 1.0.
Board Cybersecurity Reporting
The board's likelihood words are the four levels the exceptions and risk packs use, Unlikely, Possible, Likely and Almost certain, each with the chance the risk methodology scores with; Rare is no longer a scale word.
- Board Reporting Narrative Model 1.0 → 1.1
The likelihood words a top risk is given are the four levels the exceptions and risk packs use, Unlikely, Possible, Likely and Almost certain; Rare is no longer one.
- Board Reporting Effectiveness Self-Check 1.0 → 1.1
Published. The guide and eight documents, at 1.0.
Security Policy Management
Published. The guide and nine documents, at 1.0.
Information Security Risk Management
Outside tolerance, and for a Critical risk, only the board or its equivalent may accept, instead of the board or management body; the methodology says who that is by how the organisation is governed, and RM-08 reads the same way.
Step 17 and the Critical band's approver name the board or its equivalent, by how the organisation is governed, as the only one who may accept outside tolerance, instead of the board or management body.
Outside tolerance, only the board or its equivalent may accept (RM-08), instead of the board or management body.
- Cyber Risk Appetite Statement Template 1.0 → 1.1
Outside tolerance, and for a Critical risk, Who may accept names the board or its equivalent, by how the organisation is governed, instead of the board or management body (RM-08).
- Information Security Risk Register 1.0 → 1.1
Outside tolerance, and for a Critical risk, the workbook names the board or its equivalent, by how the organisation is governed, as the only one who may accept (RM-08), instead of the board or management body.
- Risk Assessment Workbook 1.0 → 1.1
Outside tolerance, only the board or its equivalent accepts a residual risk (RM-08), instead of the board or management body.
- Risk Treatment Plan 1.0 → 1.1
RM-08 and the approval table name the board or its equivalent, by how the organisation is governed, as the only one who may accept a risk outside tolerance or a Critical risk, instead of the board or management body.
- Risk Acceptance Form & Approval Record 1.0 → 1.1
Two scenario notes say Uncommon instead of Rare, which is no longer a likelihood word.
- Cyber Risk Scenario Library 1.0 → 1.1
Published. The guide and nine documents, at 1.0.
Third-Party Security Risk Management
Published. The guide and nine documents, at 1.0.
User Access Review
Published. The guide and eight documents, at 1.0.
ISO 27001 Implementation & Certification Readiness
Every cost figure is stated as an estimate, not a price: confirm each with your own figures and with quotes from accredited certification bodies.
- Guide 1.0 → 1.1
Every cost figure is stated as an estimate, not a price or a quote: the cost table's column reads Estimated range, each range is an estimate, and the limitation says the ranges are estimates.
Published. The guide and nine documents, at 1.0.
Vulnerability & Exposure Management
Published. The guide and nine documents, at 1.0.