Unified Control Framework Mapping Workbook

Lists one set of controls beside the ISO 27001, NIST CSF 2.0, NIS2 and DORA requirements in their own words, with the CISO Times documents that cite each, so you record which control you rely on for which requirement.

Available soon

Format: Excel
Size: 80 KB
Length: 13 sheets
Version: 1.6
Updated: 2 Oct 2026

Follow this documentFree account. We can email you when it changes.

What changed

1.610 Oct 2026
Names the P27 documents.
1.59 Oct 2026
Names the P26 documents.
1.49 Oct 2026
Names the P25 documents.

Earlier versions (4)

1.39 Oct 2026
Names the P24 documents.
1.23 Oct 2026
The restore-testing note names P23's Restore Testing Methodology.
1.12 Oct 2026
The restore-testing note names P22's RR-14.
1.02 Oct 2026
Published.

Changes across this pack

Preview

The workbook's sheets as you will receive them, with its example rows and the values its formulas calculate. Highlighted [[text]] is for you to replace; rows marked EXAMPLE are for you to delete. Wide sheets scroll sideways. The cover, document control and changelog sheets are in the file.

Instructions

How to use this workbook

Step	What to do
1	What this workbook is. The Your Controls sheet lists the 30 recurring controls the published CISO Times packs set, CT-01 to CT-30. Each row gives what the control does, how often it runs, the record it leaves, and the pack, rule and document it comes from. Four sheets list requirement sets you may rely on your controls for, each in its publisher's own words and numbering: NIS2 Article 21(2) (10 points), ISO 27001 Annex A (93 controls, number and title only), NIST CSF 2.0 (all 106 subcategories) and DORA Chapter II (Articles 5 to 16, heading only). The Entry Check counts what you have entered.
2	What it does not do. This workbook does not say which control meets which requirement. It lists your controls, and beside them the requirement sets you may rely on them for, each in its own words. The column "Requirements you rely on it for" is yours to fill. Where a CISO Times document's own framework references cite a requirement, the workbook names that document; this says the document helps with the work, not that using it meets the requirement.
3	Why the title differs from what the workbook does. "Unified Control Framework Mapping Workbook" is this workbook's name in the CISO Times catalogue. The pairing is yours to make. The workbook gives you the controls and the requirement lists, and leaves every pairing blank. What you enter is your own judgement: check it against the standard or the law, and with your auditor or counsel where you rely on it.
4	Test once, rely on it many times. Test once, rely on it many times: one test supports every requirement the organisation relies on the control for, as long as the attributes tested include what each of those requirements needs. Which requirement a control is relied on for is the organisation's own record in the workbook; P20 does not say it. (CA-17) So when you enter a requirement against a control, check that the attributes the Control Test Workpaper Template tests include what that requirement asks for. If they do not, add the attribute to the test, or rely on another control.
5	On the Your Controls sheet, fill the six yellow columns for each control: the requirements you rely on it for, one requirement set per column. Write the IDs as each set numbers them, separated by commas: Annex A numbers such as A.5.15, CSF subcategories such as PR.AA-05, NIS2 points such as (i), DORA articles such as Article 9. Leave a cell blank where you rely on the control for nothing in that set.
6	Use "Contracts and customer reviews" for a contract clause, a customer's supplier security review or a certification body's scope that relies on the control: name the contract or the review. Use "Other requirements" for anything else you answer for, such as a national law, a sector code or your own policy.
7	On each requirement sheet (NIS2 Article 21(2), ISO 27001 Annex A, NIST CSF 2.0, DORA Chapter II), write in "Your controls (your own entry)" the control IDs you rely on for that requirement, such as CT-16, CT-18. This is the same reliance read from the requirement's side. The workbook does not check that the two sides agree: compare them when you review it.
8	The column "NIS2 Article 21(2) points the source document cites" repeats a citation. Each control's source document names, in its own framework references, the NIS2 points it helps with; P12's measure library derives the list from those references. It says the document helps with that point's work. It says nothing about whether the control is enough for that point. Use it as a prompt for your own entry. CT-09 and CT-10 come from P12, whose documents are about NIS2 as a whole, so they show no single point.
9	Add your own controls in the yellow rows below CT-30, numbered CT-31 onwards, each written as who does what, how often and the record it leaves (CA-01), and add them to the Control Inventory & Ownership Register. Restore testing is one to consider: the set has no such control, and the Cyber Resilience & Recovery pack's RR-14 gives the rule to quote (each critical service's recovery tested at least every 12 months), and the Backup & Restore Assurance pack's Restore Testing Methodology sets the other restore checks. Quote the rule you rely on.
10	Read the Entry Check. For each requirement set it counts the requirements with no control entered, and the controls with nothing entered for that set. It also counts the controls relied on for nothing at all. They are counts, never a percentage or a score (CA-19). A requirement with no control entered is a question for you: rely on a control you already test, add a control, or record why the requirement does not apply to you.
11	Not every set applies to you. DORA binds financial entities only. NIS2 applies to the entities in its scope, and its Implementing Regulation only to the digital providers its Article 1 names. ISO/IEC 27001 and NIST CSF apply where you use them or a customer asks for them. Leave the sheets of the sets that do not apply blank, and ignore their rows on the Entry Check.
12	Review the workbook when the control inventory changes, when a requirement set you rely on changes, and at least every 12 months. Before an audit, a supervisory review or a customer review relies on your tests, use the workbook to list the controls it relies on: their tests must be final at least [[6]] weeks before it starts (CA-16).

Legend

Yellow cells are inputs. Everything else is calculated or fixed — do not overwrite formulas.

EXAMPLE

Rows marked EXAMPLE in the first column show how a completed row looks. Delete them before approval.

Limitations: This document helps you test whether your security controls work. It is not legal advice, and a test result is not a statement that you comply with NIS2, DORA, the GDPR or any standard. Where a law, a certification or a contract asks for an audit or an independent review, confirm with counsel, your certification body or the other party what it must include.

Control testing is not an internal audit, a certification audit, a P19 maturity assessment or a statement of compliance, and is never presented as one. Its results can feed each of them. (CA-18)

NIS2's Implementing Regulation (EU) 2024/2690 adds detailed requirements to each Article 21(2) measure in its Annex. It applies only to the providers its Article 1 names: DNS service providers, top-level domain name registries, cloud computing, data centre and content delivery network providers, and the other digital providers listed there.

EXAMPLE: the distributor in the P03 to P19 examples, an important entity under NIS2 in its Member State; not a financial entity, so DORA's reporting duties do not apply. Its largest customer reviews its supplier security each year, next on 14 Jun 2027, and relies on CT-13, CT-16, CT-19, CT-22, CT-24. The distributor names that review in "Contracts and customer reviews" for those five controls, and plans their tests to be final 6 weeks before it (CA-16). The workbook ships with every yellow column blank, as you receive it: no pairing is filled in for you.

Tailoring — small organisation: start with the one requirement set you are asked about most, often a customer's review or NIS2. Fill the others when someone relies on them.

Tailoring — financial entity: DORA Chapter II applies. Article 16 sets a simplified framework for the entities it names, to which Articles 5 to 15 do not apply. Confirm with counsel which applies to you before you fill the DORA sheet.

Tailoring — IT run by a service provider: where a provider performs a control, the control stays in your inventory and the reliance stays yours. Name the provider's report you rely on in "Other requirements" or in your test.

This workbook is your own record. Keep it with the control inventory and the test plan.

Your Controls

The 30 controls the published packs set, and yellow rows for your own. Grey columns describe the control; yellow columns are yours. Nothing is paired for you.

This workbook does not say which control meets which requirement. It lists your controls, and beside them the requirement sets you may rely on them for, each in its own words. The column "Requirements you rely on it for" is yours to fill. Where a CISO Times document's own framework references cite a requirement, the workbook names that document; this says the document helps with the work, not that using it meets the requirement.

Control	Control name	What the control does	How often it runs	The record it leaves	Source pack and rule	Source document	NIS2 Article 21(2) points the source document cites (the document's citation)	Relied on for (calc)
CT-01	Board report from checked figures	Each quarter, every figure in the board security report comes from one data collection workbook, checked and signed off before the deck is built.	Quarterly	The signed-off data collection workbook and the board deck built from it	P03 BR-08	P03-A05 Board Reporting Data Collection Workbook	None	Nothing entered
CT-02	Policy reviews on time	Every policy and standard is reviewed within its tier's interval (12 months for policies and standards, 24 for procedures and guidelines), and sooner on a trigger; a review that changes nothing is still recorded.	As it falls due	The policy register's review dates and each review's record	P04 PF-06	P04-A02 Policy Framework Standard	(a)	Nothing entered
CT-03	Joiners acknowledge policies	Each joiner acknowledges the policies that apply to them within 10 working days of starting.	As it happens	The acknowledgement record for each joiner	P04 PF-09	P04-A02 Policy Framework Standard	(a)	Nothing entered
CT-04	Quarterly risk review	Each risk owner reviews each of their risks every quarter, and the whole register is reassessed once a year and on any trigger.	Quarterly	Each risk's review date and decision in the register	P05 RM-09	P05-A02 Risk Assessment Methodology & Scoring Model	(a)	Nothing entered
CT-05	Exceptions approved and renewed in time	Every exception is approved by the approver its band sets, runs no longer than its band allows (Low 365 days, Medium 180 days, High 90 days, Critical 30 days), and on expiry is remediated, renewed or escalated within 10 working days.	As it happens	The exception register and each exception's request, approval and renewal	P02 EX-05, EX-06, EX-10	P02-A02 Security Exception & Waiver Standard	(a), (i)	Nothing entered
CT-06	Monthly exception register review	Information security reviews the whole exception register monthly, chasing exceptions near expiry and expired.	Monthly	The monthly review record of the exception register	P02 EX-11	P02-A02 Security Exception & Waiver Standard	(a), (i)	Nothing entered
CT-07	Tier 1 suppliers reassessed in time	Each Tier 1 supplier is reassessed at least every 12 months, and on any material change, incident or breach at the supplier.	As it falls due	Each supplier's assessment and decision	P06 TP-09	P06-A02 Third-Party Security Policy	(d)	Nothing entered
CT-08	Metric inputs checked before reporting	Before any figure is reported, its inputs pass the completeness, freshness and plausibility checks, made by someone other than the person who supplied them.	Monthly	The data quality log for each reporting cycle	P11 MR-05, MR-06	P11-A02 Security Metric Definition & Measurement Method	(f)	Nothing entered
CT-09	NIS2 readiness self-assessed	Readiness for NIS2 is self-assessed at least every 6 months, and after a significant incident or a change in scope, with every item given a readiness level and its evidence.	Every six months	The readiness self-assessment with each item's level and evidence	P12 NR-08	P12-A04 NIS2 Readiness Self-Assessment	None: P12's documents are about NIS2 as a whole, so P12 lists them under no single point	Nothing entered
CT-10	Board members trained	Every member of the management body follows cybersecurity training at least every 12 months, and a new member within 3 months of appointment, with attendance and content recorded.	As it falls due	The board training record	P12 NR-05	P12-A06 Management Body Cybersecurity Training Plan	None: P12's documents are about NIS2 as a whole, so P12 lists them under no single point	Nothing entered
CT-11	Information register reviewed	Information owners review each register entry at least every 12 months, and review an entry's level within 15 working days of a change to its purpose, users, law, supplier or risk.	As it happens	The information register's review dates and change reviews	P15 CL-03, CL-12	P15-A02 Information Classification & Handling Policy	(i)	Nothing entered
CT-12	Disposal certificates collected	A certificate is kept for every Confidential item a provider sanitises or destroys, received within 10 working days of collection.	As it happens	The disposal record and the provider's certificate	P15 CL-11	P15-A02 Information Classification & Handling Policy	(i)	Nothing entered
CT-13	Urgent vulnerabilities fixed in time	Priority 1 vulnerabilities are fixed within 7 days of first detection, and Priority 2 within 14 days, counted in calendar days.	As it happens	The remediation tracker and the scanner's detection and closure dates	P01 VM-08	P01-A02 Vulnerability & Exposure Management Standard	(e)	Nothing entered
CT-14	Vendor releases reviewed	Every vendor release that applies to an in-scope system is reviewed within 1 working day of its release, rated with the P01 model and routed to the monthly, expedited or emergency route.	As it happens	The release review log	P17 PM-03	P17-A02 Patch Management Standard	(e)	Nothing entered
CT-15	Missed patch deadlines deferred	A patch that will not be installed by its P01 deadline is deferred as a P02 exception, requested before the deadline passes and approved by the approver its band sets.	As it happens	The deferral request and its approval	P17 PM-14	P17-A02 Patch Management Standard	(e)	Nothing entered
CT-16	Leavers' access removed	A leaver's access is removed from every system, including local accounts, by the end of their last working day; for an urgent leaver within 60 minutes of the decision.	As it happens	The provisioning log and each system's account history	P13 JML-09	P13-A02 Access Control Policy	(i)	Nothing entered
CT-17	Movers' old access removed	A mover's old role access is removed on the move date or, with a handover the old manager records, within 5 working days of it.	As it happens	The provisioning log	P13 JML-08	P13-A02 Access Control Policy	(i)	Nothing entered
CT-18	Monthly account reconciliation	Within 3 working days of each month end, every in-scope system's accounts are reconciled with the HR record and the sponsor register, and an orphaned account is disabled within 1 working day of being found.	Monthly	The reconciliation report and the actions on each difference	P13 JML-15	P13-A02 Access Control Policy	(i)	Nothing entered
CT-19	User access reviews	Access is reviewed at least as often as its scope requires (3 months for privileged access, 6 for systems supporting a critical service, 12 for the rest), and every removal is made within its window (1 working day privileged, 5 standard) and confirmed against a fresh extract.	Every six months	The campaign's evidence file	P07 AR-02, AR-07	P07-A02 Access Review Methodology	(i)	Nothing entered
CT-20	Privileged access reviewed	Privileged access is reviewed every 3 months by the system owner and information security.	Quarterly	The privileged access review record	P14 PA-16	P14-A02 Privileged Access Standard	(i), (j)	Nothing entered
CT-21	Break-glass accounts tested and every use reviewed	Break-glass accounts are tested every 3 months, alert on every sign-in, and every use is declared and reviewed.	Quarterly	The break-glass test and use records	P14 PA-12	P14-A02 Privileged Access Standard	(i), (j)	Nothing entered
CT-22	Security induction completed	Each joiner completes the security induction within 10 working days of their start date.	As it happens	The learning system's completion record	P16 AW-05	P16-A02 Annual Security Awareness Plan	(g)	Nothing entered
CT-23	Annual security course completed	Everyone with an account completes the baseline course at least every 12 months.	As it falls due	The learning system's completion record	P16 AW-04	P16-A02 Annual Security Awareness Plan	(g)	Nothing entered
CT-24	Post-incident review held	Every Severity 1 and 2 incident has a post-incident review within 10 working days of closure, with owners and due dates for its actions.	As it happens	The post-incident review and its actions	P09 IM-11	P09-A02 Security Incident Management Policy	(b)	Nothing entered
CT-25	Incident response exercised	Each audience is exercised at least as often as the audience table sets: every 24 months for board or its equivalent; every 12 months for executive management and the crisis team; every 6 months for incident response team; every 6 months for technical responders; every 12 months for critical suppliers with a part in the plan.	As it falls due	The exercise programme and each exercise's report	P10 EX-02	P10-A02 Tabletop Exercise Design Methodology	(f)	Nothing entered
CT-26	After-action report approved	The after-action report is approved by the sponsor within 10 working days of the exercise, with every objective rated.	As it happens	The approved after-action report	P10 EX-09	P10-A12 Exercise After-Action Report Template	(f)	Nothing entered
CT-27	Notification readiness checked	The notification readiness checklist is completed at least every 6 months and on any change of authority, channel, signatory or profile, and each signatory's access to each channel is tested at least every 12 months.	Every six months	The readiness checklist and the channel access tests	P18 RN-17	P18-A08 Notification Readiness Checklist	None	Nothing entered
CT-28	Maturity assessed each year	A full maturity assessment runs at least every 12 months.	Annual	The assessment report	P19 MA-17	P19-A03 Internal Security Assessment Procedure	(f)	Nothing entered
CT-29	Supplier High findings escalated	Every supplier finding has an owner and a deadline set by its severity, and a High finding past its deadline is escalated to the business owner.	As it happens	The supplier finding log	P06 TP-08	P06-A02 Third-Party Security Policy	(d)	Nothing entered
CT-30	Triggered risk reassessment	A trigger, such as an incident, a major change or a control failure, forces reassessment of the risks it touches within 10 working days.	As it happens	The reassessment record	P05 RM-10	P05-A02 Risk Assessment Methodology & Scoring Model	(a)	Nothing entered

NIS2 Article 21(2)

The ten measures of NIS2 Article 21(2), points (a) to (j), in the Directive's words, with the published CISO Times documents whose own framework references cite each. This pack's documents cite point (f).

Point	Measure	Article 21(2) text	CISO Times documents whose own references cite it
(a)	Risk analysis and security policies	“policies on risk analysis and information system security”	P02-A02 Security Exception & Waiver Standard P02-A03 Exception Lifecycle Operating Procedure P04-A02 Policy Framework Standard P04-A03 Policy Lifecycle Operating Procedure P04-A05 Security Policy Hierarchy & Document Map P04-A08 Policy Coverage Gap Assessment P05-A02 Risk Assessment Methodology & Scoring Model P27-A02 First 90 Days Security Leader Checklist P27-A03 Inherited Security Programme Discovery Workbook
(b)	Incident handling	“incident handling”	P09-A02 Security Incident Management Policy P09-A03 Incident Response Plan P09-A12 Incident Response Readiness Checklist P10-A03 Exercise Planning & Facilitation Procedure P10-A04 Tabletop Scenario — Ransomware Encryption of Core Systems P10-A06 Tabletop Scenario — Insider Data Exfiltration P10-A07 Tabletop Scenario — Cloud Tenant Account Takeover P10-A08 Tabletop Scenario — Executive Payment Fraud P27-A02 First 90 Days Security Leader Checklist P27-A03 Inherited Security Programme Discovery Workbook P27-A05 Security Function Handover Document
(c)	Business continuity and crisis management	“business continuity, such as backup management and disaster recovery, and crisis management”	P09-A03 Incident Response Plan P09-A12 Incident Response Readiness Checklist P10-A04 Tabletop Scenario — Ransomware Encryption of Core Systems P10-A05 Tabletop Scenario — Critical Supplier Outage P22-A02 Business Continuity & ICT Resilience Policy P22-A03 Cyber Recovery Operating Procedure P22-A04 Critical Service Recovery Objectives Matrix (RTO, RPO, MTD) P22-A05 Cyber Recovery Plan Template P22-A06 Clean-Room Recovery & Rebuild Checklist P22-A07 Resilience Dependency Register P22-A08 Crisis & Recovery Responsibility Matrix P22-A09 Resilience Readiness Dashboard P23-A02 Restore Testing Methodology P23-A03 Backup Operations & Restore Test Procedure P23-A04 Backup Coverage & Retention Matrix P23-A05 Restore Test Workbook P23-A06 Immutable & Offline Backup Protection Checklist P23-A07 Backup Failure & Restore Findings Tracker P23-A08 Restore Test Evidence Report Template P23-A09 Backup Assurance Dashboard
(d)	Supply chain security	“supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers”	P06-A02 Third-Party Security Policy P06-A04 Supplier Criticality & Tiering Model P06-A07 Supplier Contract Security Clause Library P06-A10 Third-Party Risk Dashboard P24-A03 AI Use Case Intake & Approval Procedure P24-A07 AI Tool Approval & Data Permission Matrix P25-A06 AI Vendor & Model Provider Security Questionnaire P26-A02 Questionnaire Response Governance Method P26-A03 Questionnaire Intake, Drafting & Approval Procedure P26-A07 Questionnaire Request Tracker P27-A02 First 90 Days Security Leader Checklist P27-A03 Inherited Security Programme Discovery Workbook P27-A05 Security Function Handover Document
(e)	Security in acquisition, development and maintenance	“security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure”	P01-A02 Vulnerability & Exposure Management Standard P01-A03 Vulnerability Triage & Remediation Operating Procedure P01-A04 Vulnerability Risk Rating & SLA Model P01-A05 Scan Coverage & Asset Scope Register P01-A06 Vulnerability Remediation Tracker P17-A02 Patch Management Standard P17-A03 Monthly Patch Cycle Operating Procedure P17-A05 Emergency Out-of-Band Patching Procedure P17-A08 Patch Compliance Dashboard P25-A02 Generative AI Security Standard P25-A03 LLM Application Security Review Procedure P25-A07 AI Red Team Test Plan Template
(f)	Assessing effectiveness	“policies and procedures to assess the effectiveness of cybersecurity risk-management measures”	P01-A08 Vulnerability Management Metrics Workbook P01-A09 Vulnerability Programme Maturity Self-Assessment P04-A05 Security Policy Hierarchy & Document Map P04-A08 Policy Coverage Gap Assessment P04-A10 Policy Health & Attestation Reporting Workbook P10-A02 Tabletop Exercise Design Methodology P10-A11 Exercise Observations & Improvement Tracker P10-A12 Exercise After-Action Report Template P11-A02 Security Metric Definition & Measurement Method P11-A03 Security KPI & KRI Catalogue P11-A05 Metrics Data Collection & Quality Workbook P11-A06 Operational Security Metrics Dashboard P11-A10 Metrics Programme Maturity Self-Check P19-A02 Security Maturity Model & Scoring Method P19-A03 Internal Security Assessment Procedure P19-A04 Security Programme Maturity Assessment P19-A05 Assessment Evidence Request Checklist P19-A07 Maturity Assessment Report Template P19-A09 Maturity Results Executive Summary Deck P20-A02 Control Testing Methodology P20-A03 Control Inventory & Ownership Register P20-A04 Unified Control Framework Mapping Workbook P20-A05 Control Test Execution Procedure P20-A06 Control Test Workpaper Template P20-A07 Control Evidence Standards Checklist P20-A09 Annual Control Testing Plan P20-A10 Control Assurance Dashboard P27-A02 First 90 Days Security Leader Checklist P27-A03 Inherited Security Programme Discovery Workbook P27-A07 100-Day Security Plan P27-A08 First-Year Security Operating Calendar P27-A10 Security Posture Baseline Scorecard
(g)	Cyber hygiene and training	“basic cyber hygiene practices and cybersecurity training”	P04-A05 Security Policy Hierarchy & Document Map P04-A07 Policy Attestation & Acknowledgement Tracker P16-A02 Annual Security Awareness Plan P16-A03 Role-Based Security Training Matrix P16-A04 Awareness Campaign Communications Kit P16-A05 Phishing Simulation Programme Method P16-A06 New Joiner Security Induction Deck P16-A07 Training Completion & Evidence Register P16-A09 Human Risk Metrics Dashboard P24-A09 AI Literacy & Staff Training Plan P27-A02 First 90 Days Security Leader Checklist P27-A03 Inherited Security Programme Discovery Workbook P27-A08 First-Year Security Operating Calendar
(h)	Cryptography and encryption	“policies and procedures regarding the use of cryptography and, where appropriate, encryption”	No published CISO Times document cites this point yet.
(i)	People, access and assets	“human resources security, access control policies and asset management”	P02-A02 Security Exception & Waiver Standard P02-A07 Segregation of Duties Conflict Matrix P02-A08 SoD Conflict Review & Compensating Control Procedure P07-A02 Access Review Methodology P07-A05 Reviewer Instruction Pack & Campaign Communications P07-A09 Access Review Outcome Report Template P13-A02 Access Control Policy P13-A03 Joiner-Mover-Leaver Operating Procedure P13-A04 Role-Based Access Profile Matrix P13-A06 Leaver Access Removal Checklist P13-A08 Identity Lifecycle Responsibility Matrix P13-A09 Leaver Timeliness & Orphaned Account Report P14-A02 Privileged Access Standard P14-A03 Privileged Access Request, Elevation & Revocation Procedure P14-A04 Privileged & Service Account Inventory P14-A06 Privileged Access Control Review Workbook P14-A07 Privileged Session Review Record P14-A09 Privileged Access Metrics Dashboard P15-A02 Information Classification & Handling Policy P15-A03 Classification Level Handling Rules Matrix P15-A04 Classification & Labelling Procedure P15-A05 Information Asset Register P15-A06 Information Asset Classification Workbook P15-A07 Secure Information Disposal Checklist P15-A08 Classification Quick-Reference Card & Staff Briefing P15-A09 Information Ownership Responsibility Matrix P24-A02 AI Acceptable Use & Security Policy P24-A05 AI System & Use Case Inventory P25-A02 Generative AI Security Standard P25-A05 Generative AI Deployment Configuration Checklist P27-A02 First 90 Days Security Leader Checklist P27-A03 Inherited Security Programme Discovery Workbook P27-A05 Security Function Handover Document
(j)	Multi-factor authentication and secured communications	“the use of multi-factor authentication or continuous authentication solutions, secured voice, video and text communications and secured emergency communication systems within the entity, where appropriate”	P14-A02 Privileged Access Standard P14-A05 Break-Glass Account Control Checklist

ISO 27001 Annex A

The 93 controls of ISO/IEC 27001:2022 Annex A: number and title only. The control text is in the standard and is not reproduced.

Annex A control	Title (ISO/IEC 27001:2022)	Your controls (your own entry)
A.5.1	Policies for information security
A.5.2	Information security roles and responsibilities
A.5.3	Segregation of duties
A.5.4	Management responsibilities
A.5.5	Contact with authorities
A.5.6	Contact with special interest groups
A.5.7	Threat intelligence
A.5.8	Information security in project management
A.5.9	Inventory of information and other associated assets
A.5.10	Acceptable use of information and other associated assets
A.5.11	Return of assets
A.5.12	Classification of information
A.5.13	Labelling of information
A.5.14	Information transfer
A.5.15	Access control
A.5.16	Identity management
A.5.17	Authentication information
A.5.18	Access rights
A.5.19	Information security in supplier relationships
A.5.20	Addressing information security within supplier agreements
A.5.21	Managing information security in the ICT supply chain
A.5.22	Monitoring, review and change management of supplier services
A.5.23	Information security for use of cloud services
A.5.24	Information security incident management planning and preparation
A.5.25	Assessment and decision on information security events
A.5.26	Response to information security incidents
A.5.27	Learning from information security incidents
A.5.28	Collection of evidence
A.5.29	Information security during disruption
A.5.30	ICT readiness for business continuity
A.5.31	Legal, statutory, regulatory and contractual requirements
A.5.32	Intellectual property rights
A.5.33	Protection of records
A.5.34	Privacy and protection of PII
A.5.35	Independent review of information security
A.5.36	Compliance with policies, rules and standards for information security
A.5.37	Documented operating procedures
A.6.1	Screening
A.6.2	Terms and conditions of employment
A.6.3	Information security awareness, education and training
A.6.4	Disciplinary process
A.6.5	Responsibilities after termination or change of employment
A.6.6	Confidentiality or non-disclosure agreements
A.6.7	Remote working
A.6.8	Information security event reporting
A.7.1	Physical security perimeters
A.7.2	Physical entry
A.7.3	Securing offices, rooms and facilities
A.7.4	Physical security monitoring
A.7.5	Protecting against physical and environmental threats
A.7.6	Working in secure areas
A.7.7	Clear desk and clear screen
A.7.8	Equipment siting and protection
A.7.9	Security of assets off-premises
A.7.10	Storage media
A.7.11	Supporting utilities
A.7.12	Cabling security
A.7.13	Equipment maintenance
A.7.14	Secure disposal or re-use of equipment
A.8.1	User endpoint devices
A.8.2	Privileged access rights
A.8.3	Information access restriction
A.8.4	Access to source code
A.8.5	Secure authentication
A.8.6	Capacity management
A.8.7	Protection against malware
A.8.8	Management of technical vulnerabilities
A.8.9	Configuration management
A.8.10	Information deletion
A.8.11	Data masking
A.8.12	Data leakage prevention
A.8.13	Information backup
A.8.14	Redundancy of information processing facilities
A.8.15	Logging
A.8.16	Monitoring activities
A.8.17	Clock synchronization
A.8.18	Use of privileged utility programs
A.8.19	Installation of software on operational systems
A.8.20	Networks security
A.8.21	Security of network services
A.8.22	Segregation of networks
A.8.23	Web filtering
A.8.24	Use of cryptography
A.8.25	Secure development life cycle
A.8.26	Application security requirements
A.8.27	Secure system architecture and engineering principles
A.8.28	Secure coding
A.8.29	Security testing in development and acceptance
A.8.30	Outsourced development
A.8.31	Separation of development, test and production environments
A.8.32	Change management
A.8.33	Test information
A.8.34	Protection of information systems during audit testing

NIST CSF 2.0

All 106 subcategories of NIST CSF 2.0, in NIST's words, as NIST's own export of the Core gives them.

Subcategory	Function	Category	Outcome (NIST CSF 2.0)
GV.OC-01	Govern	GV.OC Organizational Context	The organizational mission is understood and informs cybersecurity risk management
GV.OC-02	Govern	GV.OC Organizational Context	Internal and external stakeholders are understood, and their needs and expectations regarding cybersecurity risk management are understood and considered
GV.OC-03	Govern	GV.OC Organizational Context	Legal, regulatory, and contractual requirements regarding cybersecurity - including privacy and civil liberties obligations - are understood and managed
GV.OC-04	Govern	GV.OC Organizational Context	Critical objectives, capabilities, and services that external stakeholders depend on or expect from the organization are understood and communicated
GV.OC-05	Govern	GV.OC Organizational Context	Outcomes, capabilities, and services that the organization depends on are understood and communicated
GV.RM-01	Govern	GV.RM Risk Management Strategy	Risk management objectives are established and agreed to by organizational stakeholders
GV.RM-02	Govern	GV.RM Risk Management Strategy	Risk appetite and risk tolerance statements are established, communicated, and maintained
GV.RM-03	Govern	GV.RM Risk Management Strategy	Cybersecurity risk management activities and outcomes are included in enterprise risk management processes
GV.RM-04	Govern	GV.RM Risk Management Strategy	Strategic direction that describes appropriate risk response options is established and communicated
GV.RM-05	Govern	GV.RM Risk Management Strategy	Lines of communication across the organization are established for cybersecurity risks, including risks from suppliers and other third parties
GV.RM-06	Govern	GV.RM Risk Management Strategy	A standardized method for calculating, documenting, categorizing, and prioritizing cybersecurity risks is established and communicated
GV.RM-07	Govern	GV.RM Risk Management Strategy	Strategic opportunities (i.e., positive risks) are characterized and are included in organizational cybersecurity risk discussions
GV.RR-01	Govern	GV.RR Roles, Responsibilities, and Authorities	Organizational leadership is responsible and accountable for cybersecurity risk and fosters a culture that is risk-aware, ethical, and continually improving
GV.RR-02	Govern	GV.RR Roles, Responsibilities, and Authorities	Roles, responsibilities, and authorities related to cybersecurity risk management are established, communicated, understood, and enforced
GV.RR-03	Govern	GV.RR Roles, Responsibilities, and Authorities	Adequate resources are allocated commensurate with the cybersecurity risk strategy, roles, responsibilities, and policies
GV.RR-04	Govern	GV.RR Roles, Responsibilities, and Authorities	Cybersecurity is included in human resources practices
GV.PO-01	Govern	GV.PO Policy	Policy for managing cybersecurity risks is established based on organizational context, cybersecurity strategy, and priorities and is communicated and enforced
GV.PO-02	Govern	GV.PO Policy	Policy for managing cybersecurity risks is reviewed, updated, communicated, and enforced to reflect changes in requirements, threats, technology, and organizational mission
GV.OV-01	Govern	GV.OV Oversight	Cybersecurity risk management strategy outcomes are reviewed to inform and adjust strategy and direction
GV.OV-02	Govern	GV.OV Oversight	The cybersecurity risk management strategy is reviewed and adjusted to ensure coverage of organizational requirements and risks
GV.OV-03	Govern	GV.OV Oversight	Organizational cybersecurity risk management performance is evaluated and reviewed for adjustments needed
GV.SC-01	Govern	GV.SC Cybersecurity Supply Chain Risk Management	A cybersecurity supply chain risk management program, strategy, objectives, policies, and processes are established and agreed to by organizational stakeholders
GV.SC-02	Govern	GV.SC Cybersecurity Supply Chain Risk Management	Cybersecurity roles and responsibilities for suppliers, customers, and partners are established, communicated, and coordinated internally and externally
GV.SC-03	Govern	GV.SC Cybersecurity Supply Chain Risk Management	Cybersecurity supply chain risk management is integrated into cybersecurity and enterprise risk management, risk assessment, and improvement processes
GV.SC-04	Govern	GV.SC Cybersecurity Supply Chain Risk Management	Suppliers are known and prioritized by criticality
GV.SC-05	Govern	GV.SC Cybersecurity Supply Chain Risk Management	Requirements to address cybersecurity risks in supply chains are established, prioritized, and integrated into contracts and other types of agreements with suppliers and other relevant third parties
GV.SC-06	Govern	GV.SC Cybersecurity Supply Chain Risk Management	Planning and due diligence are performed to reduce risks before entering into formal supplier or other third-party relationships
GV.SC-07	Govern	GV.SC Cybersecurity Supply Chain Risk Management	The risks posed by a supplier, their products and services, and other third parties are understood, recorded, prioritized, assessed, responded to, and monitored over the course of the relationship
GV.SC-08	Govern	GV.SC Cybersecurity Supply Chain Risk Management	Relevant suppliers and other third parties are included in incident planning, response, and recovery activities
GV.SC-09	Govern	GV.SC Cybersecurity Supply Chain Risk Management	Supply chain security practices are integrated into cybersecurity and enterprise risk management programs, and their performance is monitored throughout the technology product and service life cycle
GV.SC-10	Govern	GV.SC Cybersecurity Supply Chain Risk Management	Cybersecurity supply chain risk management plans include provisions for activities that occur after the conclusion of a partnership or service agreement
ID.AM-01	Identify	ID.AM Asset Management	Inventories of hardware managed by the organization are maintained
ID.AM-02	Identify	ID.AM Asset Management	Inventories of software, services, and systems managed by the organization are maintained
ID.AM-03	Identify	ID.AM Asset Management	Representations of the organization's authorized network communication and internal and external network data flows are maintained
ID.AM-04	Identify	ID.AM Asset Management	Inventories of services provided by suppliers are maintained
ID.AM-05	Identify	ID.AM Asset Management	Assets are prioritized based on classification, criticality, resources, and impact on the mission
ID.AM-07	Identify	ID.AM Asset Management	Inventories of data and corresponding metadata for designated data types are maintained
ID.AM-08	Identify	ID.AM Asset Management	Systems, hardware, software, services, and data are managed throughout their life cycles
ID.RA-01	Identify	ID.RA Risk Assessment	Vulnerabilities in assets are identified, validated, and recorded
ID.RA-02	Identify	ID.RA Risk Assessment	Cyber threat intelligence is received from information sharing forums and sources
ID.RA-03	Identify	ID.RA Risk Assessment	Internal and external threats to the organization are identified and recorded
ID.RA-04	Identify	ID.RA Risk Assessment	Potential impacts and likelihoods of threats exploiting vulnerabilities are identified and recorded
ID.RA-05	Identify	ID.RA Risk Assessment	Threats, vulnerabilities, likelihoods, and impacts are used to understand inherent risk and inform risk response prioritization
ID.RA-06	Identify	ID.RA Risk Assessment	Risk responses are chosen, prioritized, planned, tracked, and communicated
ID.RA-07	Identify	ID.RA Risk Assessment	Changes and exceptions are managed, assessed for risk impact, recorded, and tracked
ID.RA-08	Identify	ID.RA Risk Assessment	Processes for receiving, analyzing, and responding to vulnerability disclosures are established
ID.RA-09	Identify	ID.RA Risk Assessment	The authenticity and integrity of hardware and software are assessed prior to acquisition and use
ID.RA-10	Identify	ID.RA Risk Assessment	Critical suppliers are assessed prior to acquisition
ID.IM-01	Identify	ID.IM Improvement	Improvements are identified from evaluations
ID.IM-02	Identify	ID.IM Improvement	Improvements are identified from security tests and exercises, including those done in coordination with suppliers and relevant third parties
ID.IM-03	Identify	ID.IM Improvement	Improvements are identified from execution of operational processes, procedures, and activities
ID.IM-04	Identify	ID.IM Improvement	Incident response plans and other cybersecurity plans that affect operations are established, communicated, maintained, and improved
PR.AA-01	Protect	PR.AA Identity Management, Authentication, and Access Control	Identities and credentials for authorized users, services, and hardware are managed by the organization
PR.AA-02	Protect	PR.AA Identity Management, Authentication, and Access Control	Identities are proofed and bound to credentials based on the context of interactions
PR.AA-03	Protect	PR.AA Identity Management, Authentication, and Access Control	Users, services, and hardware are authenticated
PR.AA-04	Protect	PR.AA Identity Management, Authentication, and Access Control	Identity assertions are protected, conveyed, and verified
PR.AA-05	Protect	PR.AA Identity Management, Authentication, and Access Control	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
PR.AA-06	Protect	PR.AA Identity Management, Authentication, and Access Control	Physical access to assets is managed, monitored, and enforced commensurate with risk
PR.AT-01	Protect	PR.AT Awareness and Training	Personnel are provided with awareness and training so that they possess the knowledge and skills to perform general tasks with cybersecurity risks in mind
PR.AT-02	Protect	PR.AT Awareness and Training	Individuals in specialized roles are provided with awareness and training so that they possess the knowledge and skills to perform relevant tasks with cybersecurity risks in mind
PR.DS-01	Protect	PR.DS Data Security	The confidentiality, integrity, and availability of data-at-rest are protected
PR.DS-02	Protect	PR.DS Data Security	The confidentiality, integrity, and availability of data-in-transit are protected
PR.DS-10	Protect	PR.DS Data Security	The confidentiality, integrity, and availability of data-in-use are protected
PR.DS-11	Protect	PR.DS Data Security	Backups of data are created, protected, maintained, and tested
PR.PS-01	Protect	PR.PS Platform Security	Configuration management practices are established and applied
PR.PS-02	Protect	PR.PS Platform Security	Software is maintained, replaced, and removed commensurate with risk
PR.PS-03	Protect	PR.PS Platform Security	Hardware is maintained, replaced, and removed commensurate with risk
PR.PS-04	Protect	PR.PS Platform Security	Log records are generated and made available for continuous monitoring
PR.PS-05	Protect	PR.PS Platform Security	Installation and execution of unauthorized software are prevented
PR.PS-06	Protect	PR.PS Platform Security	Secure software development practices are integrated, and their performance is monitored throughout the software development life cycle
PR.IR-01	Protect	PR.IR Technology Infrastructure Resilience	Networks and environments are protected from unauthorized logical access and usage
PR.IR-02	Protect	PR.IR Technology Infrastructure Resilience	The organization's technology assets are protected from environmental threats
PR.IR-03	Protect	PR.IR Technology Infrastructure Resilience	Mechanisms are implemented to achieve resilience requirements in normal and adverse situations
PR.IR-04	Protect	PR.IR Technology Infrastructure Resilience	Adequate resource capacity to ensure availability is maintained
DE.CM-01	Detect	DE.CM Continuous Monitoring	Networks and network services are monitored to find potentially adverse events
DE.CM-02	Detect	DE.CM Continuous Monitoring	The physical environment is monitored to find potentially adverse events
DE.CM-03	Detect	DE.CM Continuous Monitoring	Personnel activity and technology usage are monitored to find potentially adverse events
DE.CM-06	Detect	DE.CM Continuous Monitoring	External service provider activities and services are monitored to find potentially adverse events
DE.CM-09	Detect	DE.CM Continuous Monitoring	Computing hardware and software, runtime environments, and their data are monitored to find potentially adverse events
DE.AE-02	Detect	DE.AE Adverse Event Analysis	Potentially adverse events are analyzed to better understand associated activities
DE.AE-03	Detect	DE.AE Adverse Event Analysis	Information is correlated from multiple sources
DE.AE-04	Detect	DE.AE Adverse Event Analysis	The estimated impact and scope of adverse events are understood
DE.AE-06	Detect	DE.AE Adverse Event Analysis	Information on adverse events is provided to authorized staff and tools
DE.AE-07	Detect	DE.AE Adverse Event Analysis	Cyber threat intelligence and other contextual information are integrated into the analysis
DE.AE-08	Detect	DE.AE Adverse Event Analysis	Incidents are declared when adverse events meet the defined incident criteria
RS.MA-01	Respond	RS.MA Incident Management	The incident response plan is executed in coordination with relevant third parties once an incident is declared
RS.MA-02	Respond	RS.MA Incident Management	Incident reports are triaged and validated
RS.MA-03	Respond	RS.MA Incident Management	Incidents are categorized and prioritized
RS.MA-04	Respond	RS.MA Incident Management	Incidents are escalated or elevated as needed
RS.MA-05	Respond	RS.MA Incident Management	The criteria for initiating incident recovery are applied
RS.AN-03	Respond	RS.AN Incident Analysis	Analysis is performed to establish what has taken place during an incident and the root cause of the incident
RS.AN-06	Respond	RS.AN Incident Analysis	Actions performed during an investigation are recorded, and the records' integrity and provenance are preserved
RS.AN-07	Respond	RS.AN Incident Analysis	Incident data and metadata are collected, and their integrity and provenance are preserved
RS.AN-08	Respond	RS.AN Incident Analysis	An incident's magnitude is estimated and validated
RS.CO-02	Respond	RS.CO Incident Response Reporting and Communication	Internal and external stakeholders are notified of incidents
RS.CO-03	Respond	RS.CO Incident Response Reporting and Communication	Information is shared with designated internal and external stakeholders
RS.MI-01	Respond	RS.MI Incident Mitigation	Incidents are contained
RS.MI-02	Respond	RS.MI Incident Mitigation	Incidents are eradicated
RC.RP-01	Recover	RC.RP Incident Recovery Plan Execution	The recovery portion of the incident response plan is executed once initiated from the incident response process
RC.RP-02	Recover	RC.RP Incident Recovery Plan Execution	Recovery actions are selected, scoped, prioritized, and performed
RC.RP-03	Recover	RC.RP Incident Recovery Plan Execution	The integrity of backups and other restoration assets is verified before using them for restoration
RC.RP-04	Recover	RC.RP Incident Recovery Plan Execution	Critical mission functions and cybersecurity risk management are considered to establish post-incident operational norms
RC.RP-05	Recover	RC.RP Incident Recovery Plan Execution	The integrity of restored assets is verified, systems and services are restored, and normal operating status is confirmed
RC.RP-06	Recover	RC.RP Incident Recovery Plan Execution	The end of incident recovery is declared based on criteria, and incident-related documentation is completed
RC.CO-03	Recover	RC.CO Incident Recovery Communication	Recovery activities and progress in restoring operational capabilities are communicated to designated internal and external stakeholders
RC.CO-04	Recover	RC.CO Incident Recovery Communication	Public updates on incident recovery are shared using approved methods and messaging

DORA Chapter II

DORA Chapter II, Articles 5 to 16: the headings as the Regulation gives them. DORA binds financial entities only; the EXAMPLE distributor is not a financial entity.

Article	Heading (Regulation (EU) 2022/2554)	Your controls (your own entry)
Article 5	Governance and organisation
Article 6	ICT risk management framework
Article 7	ICT systems, protocols and tools
Article 8	Identification
Article 9	Protection and prevention
Article 10	Detection
Article 11	Response and recovery
Article 12	Backup policies and procedures, restoration and recovery procedures and methods
Article 13	Learning and evolving
Article 14	Communication
Article 15	Further harmonisation of ICT risk management tools, methods, processes and policies
Article 16	Simplified ICT risk management framework

Article 16 sets a simplified ICT risk management framework for the entities it names. Articles 5 to 15 do not apply to them. Fill only the articles that apply to you, and confirm which with counsel.

Entry Check

Entry check

Counted from the Your Controls sheet and the four requirement sheets. The counts say which cells you have filled in. They judge no requirement and do not say whether a control works: the Control Test Workpaper Template tests that.

By requirement set

Requirement set	Requirements listed	Requirements with no control entered	Your controls with nothing entered for this set	Where
ISO/IEC 27001:2022 Annex A	93	93 of 93	30 of 30	ISO 27001 Annex A sheet, and Your Controls
NIST CSF 2.0	106	106 of 106	30 of 30	NIST CSF 2.0 sheet, and Your Controls
NIS2 Article 21(2)	10	10 of 10	30 of 30	NIS2 Article 21(2) sheet, and Your Controls
DORA Chapter II	12	12 of 12	30 of 30	DORA Chapter II sheet, and Your Controls
Contracts and customer reviews	Your own list	Not counted	30 of 30	Your Controls only: list your own
Other requirements	Your own list	Not counted	30 of 30	Your Controls only: list your own

All requirement sets

Measure	Count	What it means
Controls listed	30	Rows on Your Controls with a control ID: the 30 the packs set and any you add.
Controls relied on for nothing	30 of 30	Controls with every yellow column blank. Keep a control for its risk even if no requirement relies on it; test it on its own cycle (CA-15).

Every figure is a count, never a percentage or a score (CA-19). A requirement with no control entered may be one you do not rely on, one you rely on another way, or a gap: decide which, and record why.

Lists

Frequency	RequirementSet
As it happens	ISO/IEC 27001:2022 Annex A
As it falls due	NIST CSF 2.0
Monthly	NIS2 Article 21(2)
Quarterly	DORA Chapter II
Every six months	Contracts and customer reviews
Annual	Other requirements

Definitions

Definitions

Term	Meaning in this workbook
Control	Something done routinely to keep a risk in check, written as who does what, how often, and the record it leaves (CA-01).
Key control	A control whose failure, on its own, would let a risk on the register happen or go unnoticed, or that the organisation names as its evidence for an obligation. Key controls are never rated Lower risk.
Control owner	The manager accountable for a control running and leaving its record. Agrees test dates, provides access to records and fixes deficiencies.
Design test	A check that the control, as written and as set up, would prevent or detect the risk if it ran: a walkthrough of one occurrence from start to record (CA-02).
Operating test	A check, on a sample chosen by the tester, that the control ran as designed throughout the testing period (CA-04 to CA-07).
Attribute	One thing the tester checks on every sampled occurrence, such as "removed by the end of the last working day" or "approved before the change". Each control's attributes are listed with it.
Requirement set	A list of requirements from one law, standard or framework, numbered as its publisher numbers them: the points of NIS2 Article 21(2), the controls of ISO/IEC 27001:2022 Annex A, the subcategories of NIST CSF 2.0, the articles of DORA Chapter II.
Your own entry	A yellow column. You record there which requirements you rely on a control for, or which controls you rely on for a requirement. The workbook leaves every such column blank (D-51).
Relied on for	A requirement you answer for using this control's test result, with the attributes the requirement needs included in the test (CA-17).
Points the source document cites	The NIS2 Article 21(2) points that the control's source document names in its own framework references, as P12's measure library lists them. A citation by the document, not a statement about the control.
Source pack and rule	The published CISO Times pack and rule that set the control and its values, such as P13 JML-09. P20 tests the control; it restates none of its values differently.
Annex A control	One of the 93 controls listed in Annex A of ISO/IEC 27001:2022, in four themes. Numbers and titles are ISO's; the control text is in the standard.
CSF subcategory	An outcome in NIST CSF 2.0, such as GV.OC-03, within a category and one of six functions: Govern, Identify, Protect, Detect, Respond and Recover.
Article 21(2) point	One of the ten cybersecurity risk-management measures NIS2 Article 21(2) lists, (a) to (j).
DORA Chapter II	Articles 5 to 16 of Regulation (EU) 2022/2554, on ICT risk management by financial entities.
Entry check	The sheet that counts the cells you have filled in. It judges no requirement and no control.
CT-nn	The controls of the Control Inventory & Ownership Register, CT-01 to CT-30. Your own controls continue from CT-31.
CA-nn	The rules of the Control Testing Methodology, CA-01 to CA-20.
(calc)	A column the workbook calculates. Do not type or paste over it.

Framework References

Framework references

These references indicate relevance only and do not reproduce the text of any standard.

Framework	Reference	Supported by
ISO/IEC 27001:2022	Annex A 5.31 — Legal, statutory, regulatory and contractual requirements	NIS2 Article 21(2), ISO 27001 Annex A, NIST CSF 2.0 and DORA Chapter II sheets, and the contracts column: the requirement sets you answer for, identified and recorded
ISO/IEC 27001:2022	Annex A 5.36 — Compliance with policies, rules and standards for information security	Your Controls sheet: the controls whose tests check that your policies, rules and standards are followed
NIST CSF 2.0	GV.OC-03 — “Legal, regulatory, and contractual requirements regarding cybersecurity - including privacy and civil liberties obligations - are understood and managed”	The whole workbook: the requirements you answer for understood, and each recorded against the controls you rely on
NIS2 — Directive (EU) 2022/2555	Article 21(1) — appropriate and proportionate technical, operational and organisational measures to manage the risks posed to the security of network and information systems	NIS2 Article 21(2) sheet: the measures you rely on your controls for, sized to your own risks
NIS2 — Directive (EU) 2022/2555	Article 21(2)(f) — “policies and procedures to assess the effectiveness of cybersecurity risk-management measures”	Your Controls sheet: each control tested once and its result used for every requirement recorded against it (CA-17), so the effectiveness of the measures can be assessed
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	Instructions: the Implementing Regulation applies only to the providers its Article 1 names. For them, the Annex point below
NIS2 — Implementing Regulation (EU) 2024/2690	Annex, point 2.2.1 — regularly review compliance with the network and information system security policies, topic-specific policies, rules and standards; “The management bodies shall be informed of the status of network and information security on the basis of the compliance reviews by means of regular reporting.”	Your Controls sheet: the policies, rules and standards whose controls are reviewed by testing, and which requirement each review serves
DORA — Regulation (EU) 2022/2554	Article 6(5) — the ICT risk management framework is documented and reviewed at least once a year (periodically for microenterprises), upon major ICT-related incidents, and following supervisory instructions or conclusions from digital operational resilience testing or audit processes; “It shall be continuously improved on the basis of lessons derived from implementation and monitoring.” A report on the review is submitted to the competent authority on request	DORA Chapter II sheet, for financial entities: the framework's controls listed against its articles, reviewed with the framework at least once a year
DORA — Regulation (EU) 2022/2554	Article 16(1)(g) — the entities under the simplified ICT risk management framework, to which Articles 5 to 15 do not apply, “test, on a regular basis, the plans and measures referred to in point (f), as well as the effectiveness of the controls implemented in accordance with points (a) and (c)”	DORA Chapter II sheet, Article 16: entities under the simplified framework test the effectiveness of their controls regularly; this workbook records what each test is relied on for
GDPR — Regulation (EU) 2016/679	Article 24(1) — the controller implements appropriate technical and organisational measures to ensure, and to be able to demonstrate, that processing is performed in accordance with the Regulation; “Those measures shall be reviewed and updated where necessary.”	"Other requirements" column: the measures a controller relies on to demonstrate that processing follows the Regulation, recorded against the controls whose tests show it

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; Regulation (EU) 2016/679 (GDPR)

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.

These references show where this document supports an external framework. They indicate relevance only and do not reproduce the text of any standard.