Trust Center
DMS
Compliance built on a machine-readable decomposition of the EU AI Act, NIS2, DORA, GDPR and the Cyber Resilience Act — not a folder of screenshots. Every obligation below cites the regulation, article and exact source line it comes from.
Publish your own trust center →Regulatory frameworks we cover
Sourced directly from the official texts on EUR-Lex — never from secondary commentary or a competitor's summary.
Regulation
Regulation (EU) 2024/1689 — artificial intelligence
- CELEX
- 32024R1689
- Obligations tracked
- 5
Regulation
Regulation (EU) 2024/2847 — Cyber Resilience Act
- CELEX
- 32024R2847
- Obligations tracked
- 2
Regulation
Regulation (EU) 2022/2554 — digital operational resilience
- CELEX
- 32022R2554
- Obligations tracked
- 11
Delegated Regulation
Commission Delegated Regulation (EU) 2025/301 — DORA incident reporting RTS
- CELEX
- 32025R0301
- Obligations tracked
- 0
Regulation
Regulation (EU) 2016/679 — data protection
- CELEX
- 32016R0679
- Obligations tracked
- 3
Directive
Directive (EU) 2022/2555 — cybersecurity
Directive — takes legal effect through national transposition, which may be stricter than the base EU text.
- CELEX
- 32022L2555
- Obligations tracked
- 8
Implementing Regulation
Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements
- CELEX
- 32024R2690
- Obligations tracked
- 48
Obligation library
Each regulation is decomposed into individual, testable obligations. Click any one to see its exact legal citation and how it gets verified.
77
obligations
- artificial intelligence5
- Cyber Resilience Act2
- digital operational resilience11
- data protection3
- cybersecurity8
- NIS2 Art 21(2) technical requirements48
AI-ACT-004 · Regulation (EU) 2024/1689 — artificial intelligence, Article 4
AI literacy
Take measures to ensure staff and other people operating or using AI systems on the organisation's behalf have a sufficient level of AI literacy, proportionate to their role, technical knowledge and the AI systems in use.
Applicable now
AI-ACT-004 · Regulation (EU) 2024/1689 — artificial intelligence, Article 4
AI literacy
Take measures to ensure staff and other people operating or using AI systems on the organisation's behalf have a sufficient level of AI literacy, proportionate to their role, technical knowledge and the AI systems in use.
- Applies to
- All in-scope organisations
- Severity if failed
- Medium
- Applies from
- 2 Feb 2025
- Source
- AI-ACT.txt:1186
How this is verified
Training records exist for all staff who operate or use AI systems, refreshed on a defined cycle, mapped to the AI Register
The AI Register and shadow-AI discovery (§1) are what identify who needs this training in the first place — pending that feature, evidence collection here is manual declaration only.
Last verified against primary law 23 Jul 2026
AI-ACT-005 · Regulation (EU) 2024/1689 — artificial intelligence, Article 5
Prohibited AI practices
Do not place on the market, put into service, or use AI systems that deploy prohibited practices — including manipulative/subliminal techniques, exploitation of vulnerabilities, and social scoring that causes significant harm.
Applicable now
AI-ACT-005 · Regulation (EU) 2024/1689 — artificial intelligence, Article 5
Prohibited AI practices
Do not place on the market, put into service, or use AI systems that deploy prohibited practices — including manipulative/subliminal techniques, exploitation of vulnerabilities, and social scoring that causes significant harm.
- Applies to
- All in-scope organisations
- Severity if failed
- Critical
- Applies from
- 2 Feb 2025
- Source
- AI-ACT.txt:1196
How this is verified
The AI Register shows no in-use AI system flagged against any Article 5(1) prohibited-practice category
Determining whether a given system falls into a prohibited category is a legal judgment call — pending compliance-expert review, not something to automate from a keyword match.
Last verified against primary law 23 Jul 2026
AI-ACT-050 · Regulation (EU) 2024/1689 — artificial intelligence, Article 50
Transparency obligations for certain AI systems
Ensure people are informed when interacting with an AI system, label AI-generated or manipulated audio/image/video/text content as such, and disclose deepfakes and AI-generated public-interest text.
Not yet applicable
AI-ACT-050 · Regulation (EU) 2024/1689 — artificial intelligence, Article 50
Transparency obligations for certain AI systems
Ensure people are informed when interacting with an AI system, label AI-generated or manipulated audio/image/video/text content as such, and disclose deepfakes and AI-generated public-interest text.
- Applies to
- All in-scope organisations
- Severity if failed
- Medium
- Applies from
- 2 Aug 2026
- Source
- AI-ACT.txt:2574
How this is verified
AI-generated/manipulated content is machine-readably marked, and chatbot/emotion-recognition/deepfake disclosures are in place before first interaction
Not yet applicable — evidence collection for this obligation shouldn't start until closer to 2 Aug 2026.
Last verified against primary law 23 Jul 2026
AI-ACT-053 · Regulation (EU) 2024/1689 — artificial intelligence, Article 53
General-purpose AI model provider obligations
Maintain up-to-date technical documentation of the model, provide integration documentation to downstream AI-system providers, maintain a copyright-compliance policy, and publish a training-content summary.
Applicable now
AI-ACT-053 · Regulation (EU) 2024/1689 — artificial intelligence, Article 53
General-purpose AI model provider obligations
Maintain up-to-date technical documentation of the model, provide integration documentation to downstream AI-system providers, maintain a copyright-compliance policy, and publish a training-content summary.
- Applies to
- All in-scope organisations
- Severity if failed
- High
- Applies from
- 2 Aug 2025
- Source
- AI-ACT.txt:2642
How this is verified
Technical documentation, downstream integration documentation, a copyright policy, and a public training-content summary all exist and are current
The free/open-source exemption (Art 53(2)) doesn't apply to models with systemic risk — scoping which of DMS's models this covers is expert/legal review, not automatable yet.
Last verified against primary law 23 Jul 2026
AI-ACT-055 · Regulation (EU) 2024/1689 — artificial intelligence, Article 55
Systemic-risk GPAI provider obligations
For general-purpose AI models with systemic risk: perform standardised model evaluation and adversarial testing, assess and mitigate systemic risk, report serious incidents to the AI Office, and secure the model and its infrastructure.
Applicable now
AI-ACT-055 · Regulation (EU) 2024/1689 — artificial intelligence, Article 55
Systemic-risk GPAI provider obligations
For general-purpose AI models with systemic risk: perform standardised model evaluation and adversarial testing, assess and mitigate systemic risk, report serious incidents to the AI Office, and secure the model and its infrastructure.
- Applies to
- All in-scope organisations
- Severity if failed
- Critical
- Applies from
- 2 Aug 2025
- Source
- AI-ACT.txt:2720
How this is verified
Adversarial testing, systemic-risk assessment, and serious-incident reporting to the AI Office are current, on top of the Article 53 obligations
Only applies if DMS is designated as providing a GPAI model with systemic risk — that designation itself isn't modelled yet.
Last verified against primary law 23 Jul 2026
CRA-013-1 · Regulation (EU) 2024/2847 — Cyber Resilience Act, Article 13(1)-(5) / Annex I Part I
Essential cybersecurity requirements — product design and properties
When placing a product with digital elements on the market, ensure it is designed, developed and produced to provide an appropriate level of cybersecurity based on risk. Based on the Article 13(2) cybersecurity risk assessment and where applicable: ship without known exploitable vulnerabilities; ship with a secure-by-default configuration (with reset capability); ensure vulnerabilities can be addressed via security updates (including automatic updates with opt-out, enabled by default where applicable, with update notifications and postponement options); protect against unauthorised access (authentication/identity/access-management controls, with reporting on possible unauthorised access); protect the confidentiality of stored/transmitted/processed data (e.g. encryption at rest/in transit); protect the integrity of data, commands, programs and configuration against unauthorised manipulation (with corruption reporting); minimise processed data to what's necessary (data minimisation); protect the availability of essential/basic functions including resilience against denial-of-service; minimise negative impact on other devices'/networks' availability; limit attack surfaces including external interfaces; reduce incident impact via exploitation-mitigation techniques; provide security-related information via internal activity recording/monitoring (with user opt-out); and let users securely and easily permanently remove all data/settings, with secure transfer where applicable.
Not yet applicable
CRA-013-1 · Regulation (EU) 2024/2847 — Cyber Resilience Act, Article 13(1)-(5) / Annex I Part I
Essential cybersecurity requirements — product design and properties
When placing a product with digital elements on the market, ensure it is designed, developed and produced to provide an appropriate level of cybersecurity based on risk. Based on the Article 13(2) cybersecurity risk assessment and where applicable: ship without known exploitable vulnerabilities; ship with a secure-by-default configuration (with reset capability); ensure vulnerabilities can be addressed via security updates (including automatic updates with opt-out, enabled by default where applicable, with update notifications and postponement options); protect against unauthorised access (authentication/identity/access-management controls, with reporting on possible unauthorised access); protect the confidentiality of stored/transmitted/processed data (e.g. encryption at rest/in transit); protect the integrity of data, commands, programs and configuration against unauthorised manipulation (with corruption reporting); minimise processed data to what's necessary (data minimisation); protect the availability of essential/basic functions including resilience against denial-of-service; minimise negative impact on other devices'/networks' availability; limit attack surfaces including external interfaces; reduce incident impact via exploitation-mitigation techniques; provide security-related information via internal activity recording/monitoring (with user opt-out); and let users securely and easily permanently remove all data/settings, with secure transfer where applicable.
- Applies to
- All in-scope organisations
- Severity if failed
- Critical
- Applies from
- 11 Dec 2027
- Source
- CRA.txt:2379-2444
How this is verified
The product's documented cybersecurity risk assessment (Article 13(2)) addresses each applicable Annex I Part I (2)(a)-(m) property, with implementation evidence for each addressed requirement and a documented justification for any requirement treated as inapplicable
Not yet applicable — this obligation's main application date (11 Dec 2027) is well over a year away as of this corpus's last-verified date; evidence collection shouldn't start until closer to that date. Which Annex I(2) items are 'applicable' to a given product is a risk-assessment-driven, product-specific determination pending compliance-expert review.
Last verified against primary law 23 Jul 2026
CRA-013-2 · Regulation (EU) 2024/2847 — Cyber Resilience Act, Article 13(6)/(8) / Annex I Part II
Vulnerability handling requirements for products with digital elements
Manufacturers shall: identify and document vulnerabilities and components, including a machine-readable software bill of materials covering at least top-level dependencies; address and remediate vulnerabilities without delay, providing security updates (separated from functionality updates where technically feasible); apply effective, regular security tests and reviews; once a fix is available, share and publicly disclose vulnerability information (description, affected-product identification, impact, severity, remediation guidance) — with a duly justified delay option where publication risk outweighs benefit until users can patch; put in place and enforce a coordinated vulnerability disclosure policy; facilitate information-sharing about potential vulnerabilities including in third-party components, with a reporting contact address; provide secure update-distribution mechanisms ensuring timely, and where applicable automatic, fixes; and disseminate available security updates without delay and — unless otherwise agreed for a tailor-made product — free of charge, with advisory guidance for users.
Not yet applicable
CRA-013-2 · Regulation (EU) 2024/2847 — Cyber Resilience Act, Article 13(6)/(8) / Annex I Part II
Vulnerability handling requirements for products with digital elements
Manufacturers shall: identify and document vulnerabilities and components, including a machine-readable software bill of materials covering at least top-level dependencies; address and remediate vulnerabilities without delay, providing security updates (separated from functionality updates where technically feasible); apply effective, regular security tests and reviews; once a fix is available, share and publicly disclose vulnerability information (description, affected-product identification, impact, severity, remediation guidance) — with a duly justified delay option where publication risk outweighs benefit until users can patch; put in place and enforce a coordinated vulnerability disclosure policy; facilitate information-sharing about potential vulnerabilities including in third-party components, with a reporting contact address; provide secure update-distribution mechanisms ensuring timely, and where applicable automatic, fixes; and disseminate available security updates without delay and — unless otherwise agreed for a tailor-made product — free of charge, with advisory guidance for users.
- Applies to
- All in-scope organisations
- Severity if failed
- Critical
- Applies from
- 11 Dec 2027
- Source
- CRA.txt:2445-2480
How this is verified
A machine-readable SBOM exists covering top-level dependencies, vulnerabilities are remediated without delay via separated security updates, regular security testing occurs, fixed vulnerabilities are disclosed with remediation guidance (or delay is justified), a coordinated vulnerability disclosure policy is enforced with a reporting contact, and security updates are distributed securely and, where applicable, free of charge without delay
Not yet applicable — this obligation's main application date (11 Dec 2027) is well over a year away as of this corpus's last-verified date, though the closely related Article 14 reporting clock applies far sooner (11 Sep 2026).
Last verified against primary law 23 Jul 2026
DORA-005 · Regulation (EU) 2022/2554 — digital operational resilience, Article 5
Governance and organisation of ICT risk management
Maintain an internal governance and control framework ensuring effective, prudent ICT risk management for a high level of digital operational resilience. The management body defines, approves, oversees and is responsible for the ICT risk management framework — bearing ultimate responsibility for ICT risk; setting data availability/authenticity/integrity/confidentiality policies; setting clear ICT-function roles/responsibilities and coordination governance; approving the digital operational resilience strategy and ICT risk tolerance; approving and periodically reviewing the ICT business continuity policy and response/recovery plans; approving ICT internal audit plans and material changes; allocating and reviewing budget for digital operational resilience needs including awareness/training; approving and reviewing the ICT third-party service provider policy; and establishing reporting channels on third-party arrangements, planned material changes, and major ICT-related incidents. Entities other than microenterprises establish a dedicated role or senior-management responsibility for overseeing ICT third-party risk exposure, and management body members keep their ICT risk knowledge/skills current via regular training.
Applicable now
DORA-005 · Regulation (EU) 2022/2554 — digital operational resilience, Article 5
Governance and organisation of ICT risk management
Maintain an internal governance and control framework ensuring effective, prudent ICT risk management for a high level of digital operational resilience. The management body defines, approves, oversees and is responsible for the ICT risk management framework — bearing ultimate responsibility for ICT risk; setting data availability/authenticity/integrity/confidentiality policies; setting clear ICT-function roles/responsibilities and coordination governance; approving the digital operational resilience strategy and ICT risk tolerance; approving and periodically reviewing the ICT business continuity policy and response/recovery plans; approving ICT internal audit plans and material changes; allocating and reviewing budget for digital operational resilience needs including awareness/training; approving and reviewing the ICT third-party service provider policy; and establishing reporting channels on third-party arrangements, planned material changes, and major ICT-related incidents. Entities other than microenterprises establish a dedicated role or senior-management responsibility for overseeing ICT third-party risk exposure, and management body members keep their ICT risk knowledge/skills current via regular training.
- Applies to
- Financial entities in scope of DORA
- Severity if failed
- High
- Applies from
- 17 Jan 2025
- Source
- DORA.txt:921-981
How this is verified
The management body has defined, approved and overseen the ICT risk management framework per Article 5(2)(a)-(i), a dedicated role or senior-management owner monitors ICT third-party arrangements (non-microenterprises), and management body members receive regular ICT risk training
Board-level governance evidence (meeting minutes, approval records) is qualitative and typically requires document review rather than automated verification — draft placeholder pending compliance-expert input on what counts as sufficient evidence.
Last verified against primary law 23 Jul 2026
DORA-006 · Regulation (EU) 2022/2554 — digital operational resilience, Article 6
ICT risk management framework
Maintain a sound, comprehensive, well-documented ICT risk management framework as part of the overall risk management system, including strategies, policies, procedures, ICT protocols and tools protecting all information/ICT assets and physical components/infrastructure from damage and unauthorised access. Minimise ICT risk impact via the framework's deployed measures, and provide complete/updated ICT risk information to competent authorities on request. Entities other than microenterprises assign ICT risk management/oversight to an independent control function with appropriate segregation from ICT risk management and internal audit functions (three-lines-of-defence or equivalent model). The framework is documented and reviewed at least annually (or periodically for microenterprises), and after major ICT-related incidents or supervisory/testing/audit findings, continuously improved from implementation lessons, with a review report available to the competent authority on request. The framework is subject to regular internal audit by appropriately independent, ICT-risk-competent auditors (non-microenterprises), with a formal follow-up process for critical audit findings. The framework includes a documented digital operational resilience strategy covering Article 6(8)(a)-(h): business-strategy alignment, risk tolerance, information security objectives/KPIs, ICT reference architecture, incident detection/prevention mechanisms, resilience-situation evidence, resilience testing per Chapter IV, and an incident communication strategy.
Applicable now
DORA-006 · Regulation (EU) 2022/2554 — digital operational resilience, Article 6
ICT risk management framework
Maintain a sound, comprehensive, well-documented ICT risk management framework as part of the overall risk management system, including strategies, policies, procedures, ICT protocols and tools protecting all information/ICT assets and physical components/infrastructure from damage and unauthorised access. Minimise ICT risk impact via the framework's deployed measures, and provide complete/updated ICT risk information to competent authorities on request. Entities other than microenterprises assign ICT risk management/oversight to an independent control function with appropriate segregation from ICT risk management and internal audit functions (three-lines-of-defence or equivalent model). The framework is documented and reviewed at least annually (or periodically for microenterprises), and after major ICT-related incidents or supervisory/testing/audit findings, continuously improved from implementation lessons, with a review report available to the competent authority on request. The framework is subject to regular internal audit by appropriately independent, ICT-risk-competent auditors (non-microenterprises), with a formal follow-up process for critical audit findings. The framework includes a documented digital operational resilience strategy covering Article 6(8)(a)-(h): business-strategy alignment, risk tolerance, information security objectives/KPIs, ICT reference architecture, incident detection/prevention mechanisms, resilience-situation evidence, resilience testing per Chapter IV, and an incident communication strategy.
- Applies to
- Financial entities in scope of DORA
- Severity if failed
- High
- Applies from
- 17 Jan 2025
- Source
- DORA.txt:985-1039
How this is verified
A documented ICT risk management framework exists with an independent control function (non-microenterprises), is reviewed at least annually or after major incidents, is subject to regular internal audit with a critical-finding follow-up process, and includes a digital operational resilience strategy covering Article 6(8)(a)-(h)
Audit frequency and what counts as a 'major' ICT-related incident triggering an off-cycle review are entity-specific — draft placeholders pending compliance-expert definition.
Last verified against primary law 23 Jul 2026
DORA-007 · Regulation (EU) 2022/2554 — digital operational resilience, Article 7
ICT systems, protocols and tools
Use and maintain updated ICT systems, protocols and tools that are appropriate to the scale of operations (per the Article 4 proportionality principle), reliable, equipped with sufficient capacity to accurately process data and handle peak volumes including when new technology is introduced, and technologically resilient enough to handle additional processing needs under stressed market conditions or other adverse situations.
Applicable now
DORA-007 · Regulation (EU) 2022/2554 — digital operational resilience, Article 7
ICT systems, protocols and tools
Use and maintain updated ICT systems, protocols and tools that are appropriate to the scale of operations (per the Article 4 proportionality principle), reliable, equipped with sufficient capacity to accurately process data and handle peak volumes including when new technology is introduced, and technologically resilient enough to handle additional processing needs under stressed market conditions or other adverse situations.
- Applies to
- Financial entities in scope of DORA
- Severity if failed
- High
- Applies from
- 17 Jan 2025
- Source
- DORA.txt:1043-1061
How this is verified
ICT systems, protocols and tools in use are documented as appropriate to operational scale, reliable, sufficiently capacious for peak loads, and resilient under stressed conditions
Capacity/resilience thresholds are entity-specific and scale-dependent — draft placeholder pending compliance-expert definition.
Last verified against primary law 23 Jul 2026
DORA-008 · Regulation (EU) 2022/2554 — digital operational resilience, Article 8
Identification of ICT-supported functions, assets and risk sources
As part of the ICT risk management framework, identify, classify and document all ICT-supported business functions, roles, responsibilities, and the information/ICT assets supporting them, reviewing this classification at least yearly. Continuously identify all sources of ICT risk (including exposure to/from other financial entities) and assess relevant cyber threats/vulnerabilities, reviewing risk scenarios at least yearly. Non-microenterprises perform a risk assessment upon each major change to network/information system infrastructure or ICT-supported processes/procedures. Identify all information/ICT assets (including remote sites, network resources, hardware), map critical ones and their configurations/interdependencies. Identify and document all processes dependent on ICT third-party service providers and interconnections supporting critical/important functions. Maintain and periodically update relevant inventories. Non-microenterprises conduct a specific ICT risk assessment on all legacy ICT systems at least yearly and before/after connecting new technologies, applications or systems.
Applicable now
DORA-008 · Regulation (EU) 2022/2554 — digital operational resilience, Article 8
Identification of ICT-supported functions, assets and risk sources
As part of the ICT risk management framework, identify, classify and document all ICT-supported business functions, roles, responsibilities, and the information/ICT assets supporting them, reviewing this classification at least yearly. Continuously identify all sources of ICT risk (including exposure to/from other financial entities) and assess relevant cyber threats/vulnerabilities, reviewing risk scenarios at least yearly. Non-microenterprises perform a risk assessment upon each major change to network/information system infrastructure or ICT-supported processes/procedures. Identify all information/ICT assets (including remote sites, network resources, hardware), map critical ones and their configurations/interdependencies. Identify and document all processes dependent on ICT third-party service providers and interconnections supporting critical/important functions. Maintain and periodically update relevant inventories. Non-microenterprises conduct a specific ICT risk assessment on all legacy ICT systems at least yearly and before/after connecting new technologies, applications or systems.
- Applies to
- Financial entities in scope of DORA
- Severity if failed
- High
- Applies from
- 17 Jan 2025
- Source
- DORA.txt:1063-1079
How this is verified
ICT-supported business functions, assets, risk sources and third-party dependencies are identified, classified, mapped and documented per Article 8(1)-(7), with inventories maintained and reviewed at least yearly or after major changes
The specific mapping granularity and 'major change' threshold are entity-specific — draft placeholders pending compliance-expert definition.
Last verified against primary law 23 Jul 2026
DORA-009 · Regulation (EU) 2022/2554 — digital operational resilience, Article 9
Protection and prevention
Continuously monitor and control ICT system security/functioning, minimising ICT risk impact via appropriate security tools, policies and procedures. Design, procure and implement ICT security policies/procedures/protocols/tools ensuring resilience, continuity and availability of ICT systems (especially those supporting critical/important functions) and high standards of data availability/authenticity/integrity/confidentiality at rest, in use and in transit — via solutions that secure data transfer, minimise corruption/loss/unauthorised-access risk, prevent availability/integrity/confidentiality breaches, and protect against data-management risks including human error. As part of the framework: develop and document an information security policy; establish a risk-based network/infrastructure management structure (potentially including automated isolation of affected assets during cyber-attacks, with network connections designed to be instantly severable/segmentable); implement access-limiting policies restricting physical/logical access to what's required for legitimate functions, with sound access-rights administration; implement strong-authentication and cryptographic-key-protection policies based on data classification/risk assessment; implement documented, risk-based ICT change management policies ensuring changes are recorded, tested, assessed, approved, implemented and verified in a controlled manner (approved by appropriate management lines with specific protocols); and maintain comprehensive documented patch/update policies.
Applicable now
DORA-009 · Regulation (EU) 2022/2554 — digital operational resilience, Article 9
Protection and prevention
Continuously monitor and control ICT system security/functioning, minimising ICT risk impact via appropriate security tools, policies and procedures. Design, procure and implement ICT security policies/procedures/protocols/tools ensuring resilience, continuity and availability of ICT systems (especially those supporting critical/important functions) and high standards of data availability/authenticity/integrity/confidentiality at rest, in use and in transit — via solutions that secure data transfer, minimise corruption/loss/unauthorised-access risk, prevent availability/integrity/confidentiality breaches, and protect against data-management risks including human error. As part of the framework: develop and document an information security policy; establish a risk-based network/infrastructure management structure (potentially including automated isolation of affected assets during cyber-attacks, with network connections designed to be instantly severable/segmentable); implement access-limiting policies restricting physical/logical access to what's required for legitimate functions, with sound access-rights administration; implement strong-authentication and cryptographic-key-protection policies based on data classification/risk assessment; implement documented, risk-based ICT change management policies ensuring changes are recorded, tested, assessed, approved, implemented and verified in a controlled manner (approved by appropriate management lines with specific protocols); and maintain comprehensive documented patch/update policies.
- Applies to
- Financial entities in scope of DORA
- Severity if failed
- High
- Applies from
- 17 Jan 2025
- Source
- DORA.txt:1081-1135
How this is verified
ICT security policies/procedures/tools per Article 9(4)(a)-(f) are documented and implemented — information security policy, risk-based network management with segmentation capability, least-privilege access controls, strong authentication/key protection, controlled change management, and patch/update policies
Specific technical thresholds (e.g. authentication strength, segmentation triggers) are entity/risk-specific — draft placeholders pending compliance-expert definition.
Last verified against primary law 23 Jul 2026
DORA-010 · Regulation (EU) 2022/2554 — digital operational resilience, Article 10
Detection
Maintain mechanisms to promptly detect anomalous activities — including ICT network performance issues, ICT-related incidents, and potential material single points of failure — regularly tested per Article 25. Detection mechanisms enable multiple layers of control, define alert thresholds/criteria triggering incident response processes, and include automatic alerts for relevant incident-response staff. Devote sufficient resources/capabilities to monitor user activity and ICT anomalies/incidents, particularly cyber-attacks. Data reporting service providers additionally maintain systems to check trade reports for completeness, identify omissions/errors, and request re-transmission.
Applicable now
DORA-010 · Regulation (EU) 2022/2554 — digital operational resilience, Article 10
Detection
Maintain mechanisms to promptly detect anomalous activities — including ICT network performance issues, ICT-related incidents, and potential material single points of failure — regularly tested per Article 25. Detection mechanisms enable multiple layers of control, define alert thresholds/criteria triggering incident response processes, and include automatic alerts for relevant incident-response staff. Devote sufficient resources/capabilities to monitor user activity and ICT anomalies/incidents, particularly cyber-attacks. Data reporting service providers additionally maintain systems to check trade reports for completeness, identify omissions/errors, and request re-transmission.
- Applies to
- Financial entities in scope of DORA
- Severity if failed
- High
- Applies from
- 17 Jan 2025
- Source
- DORA.txt:1137-1149
How this is verified
Detection mechanisms exist covering anomalous activity, network performance and single-point-of-failure identification, with defined alert thresholds/criteria and automatic staff alerting, regularly tested per Article 25
Alert thresholds and monitoring resourcing levels are entity-specific — draft placeholder pending compliance-expert definition.
Last verified against primary law 23 Jul 2026
DORA-011 · Regulation (EU) 2022/2554 — digital operational resilience, Article 11
Response and recovery
As part of the ICT risk management framework and based on Article 8 identification, maintain a comprehensive ICT business continuity policy implemented via documented arrangements/plans/procedures/mechanisms that ensure continuity of critical/important functions; enable quick, effective incident response limiting damage and prioritising resumption/recovery; activate containment measures without delay per incident type; estimate preliminary impacts/damages/losses; and set out communication/crisis-management actions per Article 14 with competent-authority reporting per Article 19. Implement associated ICT response and recovery plans (independently internally audited for non-microenterprises). Maintain and periodically test ICT business continuity plans, especially for outsourced critical/important functions. Conduct a business impact analysis (BIA) of exposure to severe business disruptions using quantitative/qualitative criteria, considering business-function/process/third-party/asset criticality and interdependencies, ensuring ICT assets/services align with BIA findings including critical-component redundancy. Test business continuity and response/recovery plans (including crisis communication plans) at least yearly and after substantive ICT-system changes, with non-microenterprises including cyber-attack scenarios and primary/redundant-infrastructure switchover testing. Regularly review the policy/plans based on test results and audit/supervisory recommendations. Non-microenterprises maintain a crisis management function for plan activation. Keep readily accessible records of disruption-event activities.
Applicable now
DORA-011 · Regulation (EU) 2022/2554 — digital operational resilience, Article 11
Response and recovery
As part of the ICT risk management framework and based on Article 8 identification, maintain a comprehensive ICT business continuity policy implemented via documented arrangements/plans/procedures/mechanisms that ensure continuity of critical/important functions; enable quick, effective incident response limiting damage and prioritising resumption/recovery; activate containment measures without delay per incident type; estimate preliminary impacts/damages/losses; and set out communication/crisis-management actions per Article 14 with competent-authority reporting per Article 19. Implement associated ICT response and recovery plans (independently internally audited for non-microenterprises). Maintain and periodically test ICT business continuity plans, especially for outsourced critical/important functions. Conduct a business impact analysis (BIA) of exposure to severe business disruptions using quantitative/qualitative criteria, considering business-function/process/third-party/asset criticality and interdependencies, ensuring ICT assets/services align with BIA findings including critical-component redundancy. Test business continuity and response/recovery plans (including crisis communication plans) at least yearly and after substantive ICT-system changes, with non-microenterprises including cyber-attack scenarios and primary/redundant-infrastructure switchover testing. Regularly review the policy/plans based on test results and audit/supervisory recommendations. Non-microenterprises maintain a crisis management function for plan activation. Keep readily accessible records of disruption-event activities.
- Applies to
- Financial entities in scope of DORA
- Severity if failed
- Critical
- Applies from
- 17 Jan 2025
- Source
- DORA.txt:1151-1207
How this is verified
A documented ICT business continuity policy and response/recovery plans exist covering Article 11(2)(a)-(e), a business impact analysis informs asset/service design, plans are tested at least yearly (including cyber-attack scenarios for non-microenterprises) and reviewed based on results, and disruption-event records are kept accessible
BIA methodology and test scenario coverage are entity-specific — draft placeholders pending compliance-expert definition.
Last verified against primary law 23 Jul 2026
DORA-012 · Regulation (EU) 2022/2554 — digital operational resilience, Article 12
Backup policies, restoration and recovery procedures
To restore ICT systems and data with minimum downtime/disruption/loss, develop and document backup policies/procedures (specifying backup scope and minimum frequency based on data criticality/confidentiality) and restoration/recovery procedures/methods. Set up backup systems activatable per those policies without jeopardising network/system security or data availability/authenticity/integrity/confidentiality, with periodic testing of backup and restoration/recovery procedures. When restoring from backup using own systems, use ICT systems physically and logically segregated from the source system, securely protected from unauthorised access/corruption, allowing timely service restoration. Non-microenterprises maintain redundant ICT capacities adequate for business needs (microenterprises assess the need based on risk profile). Determine recovery time/point objectives per function considering criticality and market-efficiency impact, ensuring agreed service levels are met in extreme scenarios. When recovering from an incident, perform necessary checks (including multiple checks/reconciliations) to maintain the highest data integrity, including when reconstructing data from external stakeholders.
Applicable now
DORA-012 · Regulation (EU) 2022/2554 — digital operational resilience, Article 12
Backup policies, restoration and recovery procedures
To restore ICT systems and data with minimum downtime/disruption/loss, develop and document backup policies/procedures (specifying backup scope and minimum frequency based on data criticality/confidentiality) and restoration/recovery procedures/methods. Set up backup systems activatable per those policies without jeopardising network/system security or data availability/authenticity/integrity/confidentiality, with periodic testing of backup and restoration/recovery procedures. When restoring from backup using own systems, use ICT systems physically and logically segregated from the source system, securely protected from unauthorised access/corruption, allowing timely service restoration. Non-microenterprises maintain redundant ICT capacities adequate for business needs (microenterprises assess the need based on risk profile). Determine recovery time/point objectives per function considering criticality and market-efficiency impact, ensuring agreed service levels are met in extreme scenarios. When recovering from an incident, perform necessary checks (including multiple checks/reconciliations) to maintain the highest data integrity, including when reconstructing data from external stakeholders.
- Applies to
- Financial entities in scope of DORA
- Severity if failed
- Critical
- Applies from
- 17 Jan 2025
- Source
- DORA.txt:1209-1251
How this is verified
Documented backup policies (scope, frequency by criticality) and restoration/recovery procedures exist, backup systems are periodically tested and logically/physically segregated from source systems, redundant ICT capacity is maintained (non-microenterprises) or assessed (microenterprises), and recovery time/point objectives are defined per function
Backup frequency and recovery time/point objective thresholds are entity/criticality-specific — draft placeholders pending compliance-expert definition.
Last verified against primary law 23 Jul 2026
DORA-013 · Regulation (EU) 2022/2554 — digital operational resilience, Article 13
Learning and evolving
Maintain capabilities and staff to gather and analyse information on vulnerabilities, cyber threats and ICT-related incidents and their likely digital-operational-resilience impact. Conduct post-incident reviews after major ICT-related incidents disrupt core activities, analysing disruption causes and required improvements to ICT operations or the business continuity policy — assessing response promptness, forensic-analysis quality/speed, incident-escalation effectiveness, and internal/external communication effectiveness (non-microenterprises report implemented changes to competent authorities on request). Continuously incorporate lessons from resilience testing (Articles 26-27), real incidents, business-continuity-plan activation challenges, and supervisory-review findings into the ICT risk assessment process and framework reviews. Monitor digital operational resilience strategy implementation effectiveness, mapping ICT risk evolution and incident patterns to understand exposure and enhance cyber maturity. Senior ICT staff report findings to the management body at least yearly with recommendations. Develop compulsory ICT security awareness/resilience training for all staff and senior management (including, where appropriate, ICT third-party providers). Non-microenterprises continuously monitor relevant technological developments and keep ICT risk management processes current against evolving cyber-attack forms.
Applicable now
DORA-013 · Regulation (EU) 2022/2554 — digital operational resilience, Article 13
Learning and evolving
Maintain capabilities and staff to gather and analyse information on vulnerabilities, cyber threats and ICT-related incidents and their likely digital-operational-resilience impact. Conduct post-incident reviews after major ICT-related incidents disrupt core activities, analysing disruption causes and required improvements to ICT operations or the business continuity policy — assessing response promptness, forensic-analysis quality/speed, incident-escalation effectiveness, and internal/external communication effectiveness (non-microenterprises report implemented changes to competent authorities on request). Continuously incorporate lessons from resilience testing (Articles 26-27), real incidents, business-continuity-plan activation challenges, and supervisory-review findings into the ICT risk assessment process and framework reviews. Monitor digital operational resilience strategy implementation effectiveness, mapping ICT risk evolution and incident patterns to understand exposure and enhance cyber maturity. Senior ICT staff report findings to the management body at least yearly with recommendations. Develop compulsory ICT security awareness/resilience training for all staff and senior management (including, where appropriate, ICT third-party providers). Non-microenterprises continuously monitor relevant technological developments and keep ICT risk management processes current against evolving cyber-attack forms.
- Applies to
- Financial entities in scope of DORA
- Severity if failed
- Medium
- Applies from
- 17 Jan 2025
- Source
- DORA.txt:1253-1289
How this is verified
Post-incident reviews are conducted after major incidents assessing Article 13(2)(a)-(d), lessons from testing/incidents/reviews are incorporated into the risk assessment process, senior ICT staff report to the management body at least yearly, and mandatory ICT security awareness/resilience training exists for all staff
Training complexity/frequency and technological-monitoring cadence are entity-specific — draft placeholders pending compliance-expert definition.
Last verified against primary law 23 Jul 2026
DORA-014 · Regulation (EU) 2022/2554 — digital operational resilience, Article 14
Communication
As part of the ICT risk management framework, maintain crisis communication plans enabling responsible disclosure of at least major ICT-related incidents or vulnerabilities to clients, counterparts and, as appropriate, the public. Implement communication policies for internal staff and external stakeholders, differentiating between staff involved in ICT risk management/response-recovery and staff who need to be informed. Designate at least one person responsible for implementing the ICT-incident communication strategy and fulfilling the public/media function.
Applicable now
DORA-014 · Regulation (EU) 2022/2554 — digital operational resilience, Article 14
Communication
As part of the ICT risk management framework, maintain crisis communication plans enabling responsible disclosure of at least major ICT-related incidents or vulnerabilities to clients, counterparts and, as appropriate, the public. Implement communication policies for internal staff and external stakeholders, differentiating between staff involved in ICT risk management/response-recovery and staff who need to be informed. Designate at least one person responsible for implementing the ICT-incident communication strategy and fulfilling the public/media function.
- Applies to
- Financial entities in scope of DORA
- Severity if failed
- Medium
- Applies from
- 17 Jan 2025
- Source
- DORA.txt:1293-1299
How this is verified
Crisis communication plans exist covering client/counterpart/public disclosure of major incidents/vulnerabilities, internal/external communication policies differentiate staff roles, and a designated person owns the incident communication/media function
None beyond the primary text's own explicit requirements — this is one of the more concretely specified obligations.
Last verified against primary law 23 Jul 2026
DORA-019 · Regulation (EU) 2022/2554 — digital operational resilience, Article 19
Major ICT-related incident reporting
Report major ICT-related incidents to the relevant competent authority using the required templates and timelines.
Applicable now
DORA-019 · Regulation (EU) 2022/2554 — digital operational resilience, Article 19
Major ICT-related incident reporting
Report major ICT-related incidents to the relevant competent authority using the required templates and timelines.
- Applies to
- Financial entities in scope of DORA
- Severity if failed
- Critical
- Applies from
- 17 Jan 2025
- Source
- DORA.txt:1501
How this is verified
Initial notification within 4h of major-incident classification (and ≤24h from awareness), intermediate report within 72h, final report within 1 month
Mirrors the Incident Notification Commitments table above — the 4-hour clock is defined in Delegated Regulation (EU) 2025/301, not Article 19 itself. Major-incident classification thresholds are set elsewhere in DORA and aren't decomposed here yet.
Last verified against primary law 23 Jul 2026
GDPR-028 · Regulation (EU) 2016/679 — data protection, Article 28
Processor obligations and contracts
Use only processors that provide sufficient guarantees of appropriate technical and organisational measures, governed by a binding contract covering the required terms.
Applicable now
GDPR-028 · Regulation (EU) 2016/679 — data protection, Article 28
Processor obligations and contracts
Use only processors that provide sufficient guarantees of appropriate technical and organisational measures, governed by a binding contract covering the required terms.
- Applies to
- Controllers and processors of personal data
- Severity if failed
- High
- Applies from
- 25 May 2018
- Source
- GDPR.txt:1675
How this is verified
A data processing agreement is on file for every processor and subprocessor, covering the Art 28(3) required terms, with subprocessor changes notified in advance
DPA completeness against all of Art 28(3)(a)-(h) is a checklist a compliance expert should validate, not something inferred from the contract's existence alone.
Last verified against primary law 23 Jul 2026
GDPR-033 · Regulation (EU) 2016/679 — data protection, Article 33
Personal data breach notification to the supervisory authority
Notify the competent supervisory authority of a personal data breach without undue delay and, where feasible, within 72 hours of becoming aware of it — unless the breach is unlikely to result in a risk to individuals' rights and freedoms.
Applicable now
GDPR-033 · Regulation (EU) 2016/679 — data protection, Article 33
Personal data breach notification to the supervisory authority
Notify the competent supervisory authority of a personal data breach without undue delay and, where feasible, within 72 hours of becoming aware of it — unless the breach is unlikely to result in a risk to individuals' rights and freedoms.
- Applies to
- Controllers processing personal data (processors must notify controllers without undue delay, Art 33(2))
- Severity if failed
- Critical
- Applies from
- 25 May 2018
- Source
- GDPR.txt:1835
How this is verified
Breach assessed and notified to the supervisory authority within 72 hours of becoming aware, or a documented reason for delay
Requires a timestamped incident register capturing time of awareness — not yet built (§3.15 Incident Management is Phase 3 scope).
Last verified against primary law 23 Jul 2026
GDPR-034 · Regulation (EU) 2016/679 — data protection, Article 34
Personal data breach communication to the data subject
When a personal data breach is likely to result in a high risk to individuals' rights and freedoms, communicate the breach to the affected data subjects without undue delay.
Applicable now
GDPR-034 · Regulation (EU) 2016/679 — data protection, Article 34
Personal data breach communication to the data subject
When a personal data breach is likely to result in a high risk to individuals' rights and freedoms, communicate the breach to the affected data subjects without undue delay.
- Applies to
- Controllers processing personal data
- Severity if failed
- Critical
- Applies from
- 25 May 2018
- Source
- GDPR.txt:1865
How this is verified
Affected data subjects are notified without undue delay whenever the breach risk assessment concludes 'high risk'
Art 34(3) lists exemptions (e.g. the data was already encrypted, or a public communication is used instead) — not modelled as separate conditions yet; the risk assessment itself is a manual judgment call pending expert input.
Last verified against primary law 23 Jul 2026
NIS2-021-2a · Directive (EU) 2022/2555 — cybersecurity, Article 21(2)(a)
Risk analysis and information security policy
Maintain documented policies on risk analysis and information system security.
Applicable now
NIS2-021-2a · Directive (EU) 2022/2555 — cybersecurity, Article 21(2)(a)
Risk analysis and information security policy
Maintain documented policies on risk analysis and information system security.
- Applies to
- Essential & important entities
- Severity if failed
- High
- Applies from
- 18 Oct 2024
- Source
- NIS2.txt:1709
How this is verified
A management-approved risk analysis and information-security policy exists and has been reviewed within a defined interval
Article 21(2)(a) states the duty but not a review cadence or threshold — the specific interval here is a draft placeholder pending compliance-expert definition, not something the primary text specifies.
Last verified against primary law 23 Jul 2026
NIS2-021-2b · Directive (EU) 2022/2555 — cybersecurity, Article 21(2)(b)
Incident handling
Maintain a documented incident-handling capability covering detection, response and post-incident review.
Applicable now
NIS2-021-2b · Directive (EU) 2022/2555 — cybersecurity, Article 21(2)(b)
Incident handling
Maintain a documented incident-handling capability covering detection, response and post-incident review.
- Applies to
- Essential & important entities
- Severity if failed
- Critical
- Applies from
- 18 Oct 2024
- Source
- NIS2.txt:1713
How this is verified
Incidents are logged with detection/assessment/response timestamps, and NIS2 Art 23 reporting deadlines are met for qualifying incidents
Art 23's clock (24h early warning / 72h notification / 1 month final report) is the concrete, quotable threshold here — see the Incident Notification Commitments section. The incident register itself is §3.15, Phase 3 scope.
Last verified against primary law 23 Jul 2026
NIS2-021-2c · Directive (EU) 2022/2555 — cybersecurity, Article 21(2)(c)
Business continuity, backup and disaster recovery
Maintain business continuity arrangements, including backup management, disaster recovery, and crisis management procedures.
Applicable now
NIS2-021-2c · Directive (EU) 2022/2555 — cybersecurity, Article 21(2)(c)
Business continuity, backup and disaster recovery
Maintain business continuity arrangements, including backup management, disaster recovery, and crisis management procedures.
- Applies to
- Essential & important entities
- Severity if failed
- Critical
- Applies from
- 18 Oct 2024
- Source
- NIS2.txt:1717
How this is verified
A documented business continuity and disaster recovery plan exists, backups run on a defined schedule, and restores have been tested
Restore-test cadence and RTO/RPO thresholds aren't specified in the primary text — draft placeholder pending compliance-expert input. Backup APIs can automate the schedule/completion evidence; the restore test itself stays a human process (§3.1).
Last verified against primary law 23 Jul 2026
NIS2-021-2d · Directive (EU) 2022/2555 — cybersecurity, Article 21(2)(d)
Supply chain security
Address security-related aspects of relationships with direct suppliers and service providers, including their vulnerabilities and security practices.
Applicable now
NIS2-021-2d · Directive (EU) 2022/2555 — cybersecurity, Article 21(2)(d)
Supply chain security
Address security-related aspects of relationships with direct suppliers and service providers, including their vulnerabilities and security practices.
- Applies to
- Essential & important entities
- Severity if failed
- High
- Applies from
- 18 Oct 2024
- Source
- NIS2.txt:1721
How this is verified
A current supplier/vendor register exists with a security assessment on file for each direct supplier and service provider
Art 21(3) also requires considering the coordinated supply-chain risk assessments under Article 22(1) — not yet modelled; the Vendor module (§3.14, Phase 3) is where this becomes automatable.
Last verified against primary law 23 Jul 2026
NIS2-021-2e · Directive (EU) 2022/2555 — cybersecurity, Article 21(2)(e)
Secure development and vulnerability handling
Apply security in the acquisition, development and maintenance of network and information systems, including vulnerability handling and disclosure.
Applicable now
NIS2-021-2e · Directive (EU) 2022/2555 — cybersecurity, Article 21(2)(e)
Secure development and vulnerability handling
Apply security in the acquisition, development and maintenance of network and information systems, including vulnerability handling and disclosure.
- Applies to
- Essential & important entities
- Severity if failed
- High
- Applies from
- 18 Oct 2024
- Source
- NIS2.txt:1725
How this is verified
A vulnerability handling and disclosure process exists, with vulnerabilities tracked from discovery to remediation
Scanner/patch-state automation (README: scanner APIs, GitHub/GitLab, patch state) is the intended evidence source — specific remediation SLAs are a draft placeholder pending expert input.
Last verified against primary law 23 Jul 2026
NIS2-021-2h · Directive (EU) 2022/2555 — cybersecurity, Article 21(2)(h)
Cryptography and encryption policy
Maintain policies and procedures on the use of cryptography and, where appropriate, encryption.
Applicable now
NIS2-021-2h · Directive (EU) 2022/2555 — cybersecurity, Article 21(2)(h)
Cryptography and encryption policy
Maintain policies and procedures on the use of cryptography and, where appropriate, encryption.
- Applies to
- Essential & important entities
- Severity if failed
- High
- Applies from
- 18 Oct 2024
- Source
- NIS2.txt:1737
How this is verified
A documented cryptography/encryption policy exists and encryption is enforced for data classified as requiring it
Which data classes require encryption depends on the entity's own asset classification (the Asset model is Phase 3 scope) — draft placeholder pending that and expert input.
Last verified against primary law 23 Jul 2026
NIS2-021-2i · Directive (EU) 2022/2555 — cybersecurity, Article 21(2)(i)
HR security, access control policy and asset management
Maintain human resources security measures, access control policies, and asset management practices.
Applicable now
NIS2-021-2i · Directive (EU) 2022/2555 — cybersecurity, Article 21(2)(i)
HR security, access control policy and asset management
Maintain human resources security measures, access control policies, and asset management practices.
- Applies to
- Essential & important entities
- Severity if failed
- High
- Applies from
- 18 Oct 2024
- Source
- NIS2.txt:1741
How this is verified
An access control policy exists, staff access is provisioned/deprovisioned against HR records, and an asset inventory is maintained
Deprovisioning-latency threshold and inventory completeness criteria are draft placeholders pending expert input.
Last verified against primary law 23 Jul 2026
NIS2-021-2j · Directive (EU) 2022/2555 — cybersecurity, Article 21(2)(j)
Access control & multi-factor authentication
Staff access must be controlled; MFA for privileged/remote access
Applicable now
NIS2-021-2j · Directive (EU) 2022/2555 — cybersecurity, Article 21(2)(j)
Access control & multi-factor authentication
Staff access must be controlled; MFA for privileged/remote access
- Applies to
- Essential & important entities
- Severity if failed
- High
- Applies from
- 18 Oct 2024
- Source
- NIS2.txt:1745
Pending legislative change: COM(2026) 13 (52026PC0013, proposal only) may add a certification-based compliance pathway — not adopted, does not change this obligation's requirements yet.
How this is verified
>= 95% of active users MFA-enabled AND 0 unprotected admin accounts
Single band only — NIS2 Art 21(1) proportionality (micro/small/medium bands) not yet split out, pending compliance expert input. Also see Implementing Reg §11.7.2: authentication strength should scale with asset classification, which this threshold alone doesn't express (Asset model is Phase 3).
Last verified against primary law 23 Jul 2026
NIS2-IMPL-1.1 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §1.1
Network and information system security policy — required content and review
Maintain a single approved network-and-information-system security policy that sets out the entity's security approach, aligns with business strategy, states security objectives, commits to continual improvement and adequate resourcing, is communicated to staff and relevant external parties, lays down roles per §1.2, lists retained documentation and topic-specific policies, sets monitoring indicators, and is dated with management-body approval — reviewed at least annually or after a significant incident or change.
Applicable now
NIS2-IMPL-1.1 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §1.1
Network and information system security policy — required content and review
Maintain a single approved network-and-information-system security policy that sets out the entity's security approach, aligns with business strategy, states security objectives, commits to continual improvement and adequate resourcing, is communicated to staff and relevant external parties, lays down roles per §1.2, lists retained documentation and topic-specific policies, sets monitoring indicators, and is dated with management-body approval — reviewed at least annually or after a significant incident or change.
- Applies to
- Digital infrastructure/service entities in Art 3 scope (DNS providers, TLD registries, cloud/data-centre/CDN providers, MSPs/MSSPs, online marketplaces, search engines, social platforms, trust services)
- Severity if failed
- High
- Applies from
- 6 Nov 2024
- Source
- NIS2-implementing-2024-2690.txt:2272-2517
How this is verified
A single management-approved N&IS security policy exists covering all eleven §1.1.1(a)-(k) elements, and has been reviewed at least annually or after a significant incident/change
The annual-review cadence is the primary text's own stated threshold, not a draft placeholder.
Last verified against primary law 23 Jul 2026
NIS2-IMPL-1.2 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §1.2
Roles, responsibilities and authorities for network and information system security
Assign and communicate network-and-information-system security responsibilities and authorities; require personnel and third parties to follow the security policy; ensure at least one person reports directly to the management body on security matters; size-appropriate dedicated or combined roles; segregate conflicting duties where applicable; review roles at planned intervals or after significant change.
Applicable now
NIS2-IMPL-1.2 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §1.2
Roles, responsibilities and authorities for network and information system security
Assign and communicate network-and-information-system security responsibilities and authorities; require personnel and third parties to follow the security policy; ensure at least one person reports directly to the management body on security matters; size-appropriate dedicated or combined roles; segregate conflicting duties where applicable; review roles at planned intervals or after significant change.
- Applies to
- Digital infrastructure/service entities in Art 3 scope (DNS providers, TLD registries, cloud/data-centre/CDN providers, MSPs/MSSPs, online marketplaces, search engines, social platforms, trust services)
- Severity if failed
- High
- Applies from
- 6 Nov 2024
- Source
- NIS2-implementing-2024-2690.txt:2524-2640
How this is verified
Security roles/authorities are assigned, communicated and reviewed at planned intervals, at least one person reports directly to the management body on N&IS security, and conflicting duties are segregated where applicable
The 'planned intervals' cadence and what counts as 'applicable' segregation are draft placeholders pending compliance-expert definition.
Last verified against primary law 23 Jul 2026
NIS2-IMPL-10.1 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §10.1
Human resources security responsibilities
Ensure employees and, where applicable per §5.1.4, direct suppliers and service providers understand and commit to their security responsibilities, appropriate to their role and service and in line with the N&IS security policy — via mechanisms ensuring standard cyber hygiene practices (§8.1) are understood and followed, administrative/privileged users act per their roles/responsibilities/authorities, management body members understand and act on their N&IS security role, and qualified personnel are hired for security-relevant roles (e.g. reference checks, vetting, certification validation, written tests). Personnel role assignments (per §1.2) and resourcing are reviewed at planned intervals and at least annually, updated where necessary.
Applicable now
NIS2-IMPL-10.1 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §10.1
Human resources security responsibilities
Ensure employees and, where applicable per §5.1.4, direct suppliers and service providers understand and commit to their security responsibilities, appropriate to their role and service and in line with the N&IS security policy — via mechanisms ensuring standard cyber hygiene practices (§8.1) are understood and followed, administrative/privileged users act per their roles/responsibilities/authorities, management body members understand and act on their N&IS security role, and qualified personnel are hired for security-relevant roles (e.g. reference checks, vetting, certification validation, written tests). Personnel role assignments (per §1.2) and resourcing are reviewed at planned intervals and at least annually, updated where necessary.
- Applies to
- Digital infrastructure/service entities in Art 3 scope (DNS providers, TLD registries, cloud/data-centre/CDN providers, MSPs/MSSPs, online marketplaces, search engines, social platforms, trust services)
- Severity if failed
- Medium
- Applies from
- 6 Nov 2024
- Source
- NIS2-implementing-2024-2690.txt:7567-7705
How this is verified
Mechanisms exist ensuring employees/suppliers understand security responsibilities per §10.1.2(a)-(d), and role assignments are reviewed at planned intervals and at least annually
The specific hiring-verification mechanisms used are entity-defined — draft placeholder pending compliance-expert input.
Last verified against primary law 23 Jul 2026
NIS2-IMPL-10.2 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §10.2
Background verification
To the extent feasible, verify the background of employees and, where applicable per §5.1.4, direct suppliers and service providers, where necessary for their role, responsibilities and authorisations — by setting criteria for which roles require verified backgrounds, and performing that verification before the person starts exercising the role, taking into account applicable laws, regulations and ethics, proportionate to business requirements, the §12.1 asset classification, the systems to be accessed, and perceived risk. The policy is reviewed and, where appropriate, updated at planned intervals.
Applicable now
NIS2-IMPL-10.2 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §10.2
Background verification
To the extent feasible, verify the background of employees and, where applicable per §5.1.4, direct suppliers and service providers, where necessary for their role, responsibilities and authorisations — by setting criteria for which roles require verified backgrounds, and performing that verification before the person starts exercising the role, taking into account applicable laws, regulations and ethics, proportionate to business requirements, the §12.1 asset classification, the systems to be accessed, and perceived risk. The policy is reviewed and, where appropriate, updated at planned intervals.
- Applies to
- Digital infrastructure/service entities in Art 3 scope (DNS providers, TLD registries, cloud/data-centre/CDN providers, MSPs/MSSPs, online marketplaces, search engines, social platforms, trust services)
- Severity if failed
- Medium
- Applies from
- 6 Nov 2024
- Source
- NIS2-implementing-2024-2690.txt:7706-7806
How this is verified
Criteria exist identifying which roles require background verification, verification is performed before role commencement proportionate to risk/asset classification, and the policy is reviewed at planned intervals
The specific verification depth/method is jurisdiction- and role-dependent — draft placeholder pending compliance-expert definition.
Last verified against primary law 23 Jul 2026
NIS2-IMPL-10.3 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §10.3
Termination or change of employment procedures
Ensure network and information system security responsibilities and duties that remain valid after termination or change of an employee's employment are contractually defined and enforced — including confidentiality clauses and similar terms written into the individual's employment terms, contract or agreement.
Applicable now
NIS2-IMPL-10.3 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §10.3
Termination or change of employment procedures
Ensure network and information system security responsibilities and duties that remain valid after termination or change of an employee's employment are contractually defined and enforced — including confidentiality clauses and similar terms written into the individual's employment terms, contract or agreement.
- Applies to
- Digital infrastructure/service entities in Art 3 scope (DNS providers, TLD registries, cloud/data-centre/CDN providers, MSPs/MSSPs, online marketplaces, search engines, social platforms, trust services)
- Severity if failed
- Medium
- Applies from
- 6 Nov 2024
- Source
- NIS2-implementing-2024-2690.txt:7807-7849
How this is verified
Post-employment N&IS security responsibilities (e.g. confidentiality) are contractually defined and enforced in employment terms/contracts
Specific contract clause language is left to the entity's legal function — draft placeholder pending compliance-expert input.
Last verified against primary law 23 Jul 2026
NIS2-IMPL-10.4 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §10.4
Disciplinary process for security policy violations
Establish, communicate and maintain a disciplinary process for handling violations of network and information system security policies, taking into account relevant legal, statutory, contractual and business requirements. The process is reviewed and, where appropriate, updated at planned intervals and when necessary due to legal changes or significant operational/risk changes.
Applicable now
NIS2-IMPL-10.4 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §10.4
Disciplinary process for security policy violations
Establish, communicate and maintain a disciplinary process for handling violations of network and information system security policies, taking into account relevant legal, statutory, contractual and business requirements. The process is reviewed and, where appropriate, updated at planned intervals and when necessary due to legal changes or significant operational/risk changes.
- Applies to
- Digital infrastructure/service entities in Art 3 scope (DNS providers, TLD registries, cloud/data-centre/CDN providers, MSPs/MSSPs, online marketplaces, search engines, social platforms, trust services)
- Severity if failed
- Medium
- Applies from
- 6 Nov 2024
- Source
- NIS2-implementing-2024-2690.txt:7850-7892
How this is verified
A documented, communicated disciplinary process exists for N&IS security policy violations, accounting for legal/contractual/business requirements, and is reviewed at planned intervals or after legal/operational/risk changes
Review cadence is entity-defined — draft placeholder pending compliance-expert input.
Last verified against primary law 23 Jul 2026
NIS2-IMPL-11.1 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §11.1
Access control policy
Establish, document and implement logical and physical access control policies for network and information systems, based on business and N&IS security requirements — addressing access by persons (staff, visitors, external entities such as suppliers/service providers) and by network and information systems themselves, and ensuring access is only granted to adequately authenticated users. Policies are reviewed and, where appropriate, updated at planned intervals and after significant incidents or significant operational/risk changes.
Applicable now
NIS2-IMPL-11.1 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §11.1
Access control policy
Establish, document and implement logical and physical access control policies for network and information systems, based on business and N&IS security requirements — addressing access by persons (staff, visitors, external entities such as suppliers/service providers) and by network and information systems themselves, and ensuring access is only granted to adequately authenticated users. Policies are reviewed and, where appropriate, updated at planned intervals and after significant incidents or significant operational/risk changes.
- Applies to
- Digital infrastructure/service entities in Art 3 scope (DNS providers, TLD registries, cloud/data-centre/CDN providers, MSPs/MSSPs, online marketplaces, search engines, social platforms, trust services)
- Severity if failed
- High
- Applies from
- 6 Nov 2024
- Source
- NIS2-implementing-2024-2690.txt:7896-8015
How this is verified
Documented logical/physical access control policies exist covering person, system and authenticated-access requirements per §11.1.2(a)-(c), and are reviewed at planned intervals or after significant incidents/changes
Review cadence is entity-defined — draft placeholder pending compliance-expert input.
Last verified against primary law 23 Jul 2026
NIS2-IMPL-11.2 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §11.2
Management of access rights
Provide, modify, remove and document access rights to network and information systems in accordance with the §11.1 access control policy — assigning and revoking rights based on need-to-know, least privilege and separation of duties; modifying access upon termination or change of employment; ensuring access is authorised by the relevant persons; appropriately addressing third-party access (visitors, suppliers, service providers) by limiting scope and duration; maintaining a register of granted access rights; and applying logging to access-rights management. Access rights are reviewed at planned intervals, modified based on organisational changes, with review results and necessary changes documented.
Applicable now
NIS2-IMPL-11.2 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §11.2
Management of access rights
Provide, modify, remove and document access rights to network and information systems in accordance with the §11.1 access control policy — assigning and revoking rights based on need-to-know, least privilege and separation of duties; modifying access upon termination or change of employment; ensuring access is authorised by the relevant persons; appropriately addressing third-party access (visitors, suppliers, service providers) by limiting scope and duration; maintaining a register of granted access rights; and applying logging to access-rights management. Access rights are reviewed at planned intervals, modified based on organisational changes, with review results and necessary changes documented.
- Applies to
- Digital infrastructure/service entities in Art 3 scope (DNS providers, TLD registries, cloud/data-centre/CDN providers, MSPs/MSSPs, online marketplaces, search engines, social platforms, trust services)
- Severity if failed
- High
- Applies from
- 6 Nov 2024
- Source
- NIS2-implementing-2024-2690.txt:8016-8192
How this is verified
Access rights are assigned/modified/removed per §11.2.2(a)-(f) (need-to-know, least privilege, separation of duties, termination handling, authorisation, third-party limits, a maintained register, and logging), and reviewed at planned intervals with documented results
Review cadence is entity-defined — draft placeholder pending compliance-expert input.
Last verified against primary law 23 Jul 2026
NIS2-IMPL-11.3 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §11.3
Privileged accounts and system administration accounts
Maintain policies for managing privileged accounts and system administration accounts as part of the §11.1 access control policy — establishing strong identification/authentication (e.g. multi-factor) and authorisation procedures for such accounts; setting up dedicated accounts used exclusively for system administration operations (installation, configuration, management, maintenance); individualising and restricting administration privileges to the highest extent possible; and ensuring administration accounts are only used to connect to system administration systems. Access rights of privileged/administration accounts are reviewed at planned intervals, modified based on organisational changes, with review results documented.
Applicable now
NIS2-IMPL-11.3 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §11.3
Privileged accounts and system administration accounts
Maintain policies for managing privileged accounts and system administration accounts as part of the §11.1 access control policy — establishing strong identification/authentication (e.g. multi-factor) and authorisation procedures for such accounts; setting up dedicated accounts used exclusively for system administration operations (installation, configuration, management, maintenance); individualising and restricting administration privileges to the highest extent possible; and ensuring administration accounts are only used to connect to system administration systems. Access rights of privileged/administration accounts are reviewed at planned intervals, modified based on organisational changes, with review results documented.
- Applies to
- Digital infrastructure/service entities in Art 3 scope (DNS providers, TLD registries, cloud/data-centre/CDN providers, MSPs/MSSPs, online marketplaces, search engines, social platforms, trust services)
- Severity if failed
- High
- Applies from
- 6 Nov 2024
- Source
- NIS2-implementing-2024-2690.txt:8193-8331
How this is verified
Privileged/administration-account policies exist covering §11.3.2(a)-(d) (strong auth, dedicated accounts, individualised/restricted privileges, exclusive use for administration systems), and access rights are reviewed at planned intervals with documented results
Review cadence is entity-defined — draft placeholder pending compliance-expert input.
Last verified against primary law 23 Jul 2026
NIS2-IMPL-11.4 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §11.4
Restriction and control of system administration systems
Restrict and control the use of system administration systems in accordance with the §11.1 access control policy — using them only for system administration purposes and no other operations, logically separating them from application software not used for administration, and protecting access to them through authentication and encryption.
Applicable now
NIS2-IMPL-11.4 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §11.4
Restriction and control of system administration systems
Restrict and control the use of system administration systems in accordance with the §11.1 access control policy — using them only for system administration purposes and no other operations, logically separating them from application software not used for administration, and protecting access to them through authentication and encryption.
- Applies to
- Digital infrastructure/service entities in Art 3 scope (DNS providers, TLD registries, cloud/data-centre/CDN providers, MSPs/MSSPs, online marketplaces, search engines, social platforms, trust services)
- Severity if failed
- High
- Applies from
- 6 Nov 2024
- Source
- NIS2-implementing-2024-2690.txt:8332-8431
How this is verified
System administration systems are used exclusively for administration purposes, logically separated from other application software, and access-protected via authentication and encryption
The specific separation/encryption mechanism is entity-defined — draft placeholder pending compliance-expert input.
Last verified against primary law 23 Jul 2026
NIS2-IMPL-11.5 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §11.5
Identity lifecycle management
Manage the full life cycle of identities for network and information systems and their users — setting up unique identities for systems and users, linking each user identity to a single person, ensuring oversight of system identities, and applying logging to identity management. Identities assigned to multiple persons (e.g. shared identities) are only permitted where necessary for business or operational reasons, subject to explicit approval, documentation, and inclusion in the §2.1 risk management framework. Identities are regularly reviewed and deactivated without delay once no longer needed.
Applicable now
NIS2-IMPL-11.5 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §11.5
Identity lifecycle management
Manage the full life cycle of identities for network and information systems and their users — setting up unique identities for systems and users, linking each user identity to a single person, ensuring oversight of system identities, and applying logging to identity management. Identities assigned to multiple persons (e.g. shared identities) are only permitted where necessary for business or operational reasons, subject to explicit approval, documentation, and inclusion in the §2.1 risk management framework. Identities are regularly reviewed and deactivated without delay once no longer needed.
- Applies to
- Digital infrastructure/service entities in Art 3 scope (DNS providers, TLD registries, cloud/data-centre/CDN providers, MSPs/MSSPs, online marketplaces, search engines, social platforms, trust services)
- Severity if failed
- High
- Applies from
- 6 Nov 2024
- Source
- NIS2-implementing-2024-2690.txt:8432-8590
How this is verified
Unique identities exist for systems/users with each user identity linked to a single person, identity management is logged, shared identities (if any) are explicitly approved/documented/risk-assessed, and identities are regularly reviewed with no-longer-needed identities deactivated without delay
Review cadence ('regularly') is entity-defined — draft placeholder pending compliance-expert input.
Last verified against primary law 23 Jul 2026
NIS2-IMPL-11.6 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §11.6
Authentication procedures and technologies
Implement secure authentication procedures and technologies based on access restrictions and the access control policy — ensuring authentication strength matches the classification of the asset accessed; controlling allocation/management of secret authentication information to preserve confidentiality (including personnel guidance on handling it); requiring credential changes initially, at predefined intervals, and upon suspected compromise; resetting credentials and blocking users after a predefined number of failed login attempts; terminating inactive sessions after a predefined inactivity period; and requiring separate credentials for privileged/administrative access. To the extent feasible, state-of-the-art authentication methods and unique authentication information are used, matched to assessed risk and asset classification. Procedures and technologies are reviewed at planned intervals.
Applicable now
NIS2-IMPL-11.6 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §11.6
Authentication procedures and technologies
Implement secure authentication procedures and technologies based on access restrictions and the access control policy — ensuring authentication strength matches the classification of the asset accessed; controlling allocation/management of secret authentication information to preserve confidentiality (including personnel guidance on handling it); requiring credential changes initially, at predefined intervals, and upon suspected compromise; resetting credentials and blocking users after a predefined number of failed login attempts; terminating inactive sessions after a predefined inactivity period; and requiring separate credentials for privileged/administrative access. To the extent feasible, state-of-the-art authentication methods and unique authentication information are used, matched to assessed risk and asset classification. Procedures and technologies are reviewed at planned intervals.
- Applies to
- Digital infrastructure/service entities in Art 3 scope (DNS providers, TLD registries, cloud/data-centre/CDN providers, MSPs/MSSPs, online marketplaces, search engines, social platforms, trust services)
- Severity if failed
- High
- Applies from
- 6 Nov 2024
- Source
- NIS2-implementing-2024-2690.txt:8591-8787
How this is verified
Authentication procedures cover §11.6.2(a)-(f) (risk-matched strength, protected credential handling, credential rotation/reset-on-lockout, session timeout, separate privileged credentials), use state-of-the-art methods where feasible, and are reviewed at planned intervals
The specific 'predefined' thresholds (rotation interval, lockout count, inactivity timeout) are entity-defined — draft placeholders pending compliance-expert definition.
Last verified against primary law 23 Jul 2026
NIS2-IMPL-12.1 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §12.1
Asset classification
Lay down classification levels for all assets (including information) in scope of network and information systems, indicating the level of protection required — establishing a classification-level system, associating every asset with a level based on confidentiality/integrity/authenticity/availability requirements reflecting sensitivity, criticality, risk and business value, and aligning asset availability requirements with the delivery/recovery objectives set in the §4.1 business continuity/disaster recovery plans. Classification levels are periodically reviewed and updated where appropriate.
Applicable now
NIS2-IMPL-12.1 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §12.1
Asset classification
Lay down classification levels for all assets (including information) in scope of network and information systems, indicating the level of protection required — establishing a classification-level system, associating every asset with a level based on confidentiality/integrity/authenticity/availability requirements reflecting sensitivity, criticality, risk and business value, and aligning asset availability requirements with the delivery/recovery objectives set in the §4.1 business continuity/disaster recovery plans. Classification levels are periodically reviewed and updated where appropriate.
- Applies to
- Digital infrastructure/service entities in Art 3 scope (DNS providers, TLD registries, cloud/data-centre/CDN providers, MSPs/MSSPs, online marketplaces, search engines, social platforms, trust services)
- Severity if failed
- High
- Applies from
- 6 Nov 2024
- Source
- NIS2-implementing-2024-2690.txt:8834-8953
How this is verified
A classification-level system exists, every in-scope asset is associated with a level per §12.1.2(b), availability requirements align with BC/DR objectives, and classification levels are periodically reviewed
Review cadence ('periodic') is entity-defined — draft placeholder pending compliance-expert input.
Last verified against primary law 23 Jul 2026
NIS2-IMPL-12.2 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §12.2
Handling of assets
Establish, implement and apply a policy for the proper handling of assets (including information), in line with the N&IS security policy, communicated to anyone who uses or handles assets — covering the entire asset life cycle (acquisition, use, storage, transportation, disposal), providing rules for safe use/storage/transport and irretrievable deletion/destruction, and ensuring secure transfer appropriate to the asset type. Reviewed and, where appropriate, updated at planned intervals and after significant incidents or significant operational/risk changes.
Applicable now
NIS2-IMPL-12.2 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §12.2
Handling of assets
Establish, implement and apply a policy for the proper handling of assets (including information), in line with the N&IS security policy, communicated to anyone who uses or handles assets — covering the entire asset life cycle (acquisition, use, storage, transportation, disposal), providing rules for safe use/storage/transport and irretrievable deletion/destruction, and ensuring secure transfer appropriate to the asset type. Reviewed and, where appropriate, updated at planned intervals and after significant incidents or significant operational/risk changes.
- Applies to
- Digital infrastructure/service entities in Art 3 scope (DNS providers, TLD registries, cloud/data-centre/CDN providers, MSPs/MSSPs, online marketplaces, search engines, social platforms, trust services)
- Severity if failed
- Medium
- Applies from
- 6 Nov 2024
- Source
- NIS2-implementing-2024-2690.txt:8954-9073
How this is verified
A documented, communicated asset-handling policy exists covering the full asset life cycle per §12.2.2(a)-(c), and is reviewed at planned intervals or after significant incidents/changes
Review cadence is entity-defined — draft placeholder pending compliance-expert input.
Last verified against primary law 23 Jul 2026
NIS2-IMPL-12.3 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §12.3
Removable media policy
Establish, implement and apply a policy on managing removable storage media, communicated to employees and third parties who handle such media at the entity's premises or wherever it connects to the entity's network and information systems — technically prohibiting removable-media connection absent an organisational reason, disabling self-execution and scanning media for malicious code before use, controlling/protecting portable storage devices in transit and storage, and, where appropriate, using cryptographic techniques to protect data on removable media. Reviewed and, where appropriate, updated at planned intervals and after significant incidents or significant operational/risk changes.
Applicable now
NIS2-IMPL-12.3 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §12.3
Removable media policy
Establish, implement and apply a policy on managing removable storage media, communicated to employees and third parties who handle such media at the entity's premises or wherever it connects to the entity's network and information systems — technically prohibiting removable-media connection absent an organisational reason, disabling self-execution and scanning media for malicious code before use, controlling/protecting portable storage devices in transit and storage, and, where appropriate, using cryptographic techniques to protect data on removable media. Reviewed and, where appropriate, updated at planned intervals and after significant incidents or significant operational/risk changes.
- Applies to
- Digital infrastructure/service entities in Art 3 scope (DNS providers, TLD registries, cloud/data-centre/CDN providers, MSPs/MSSPs, online marketplaces, search engines, social platforms, trust services)
- Severity if failed
- Medium
- Applies from
- 6 Nov 2024
- Source
- NIS2-implementing-2024-2690.txt:9074-9212
How this is verified
A documented, communicated removable-media policy exists covering §12.3.2(a)-(d) (technical restriction, malware scanning/no self-execution, transit/storage protection, cryptographic protection where appropriate), and is reviewed at planned intervals or after significant incidents/changes
Review cadence is entity-defined — draft placeholder pending compliance-expert input.
Last verified against primary law 23 Jul 2026
NIS2-IMPL-12.4 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §12.4
Asset inventory
Develop and maintain a complete, accurate, up-to-date and consistent inventory of assets, with changes to inventory entries recorded traceably. Inventory granularity is appropriate to the entity's needs and includes the list of operations/services and their description, and the list of network and information systems and other associated assets supporting those operations/services. The inventory and its assets are regularly reviewed and updated, with a documented history of changes.
Applicable now
NIS2-IMPL-12.4 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §12.4
Asset inventory
Develop and maintain a complete, accurate, up-to-date and consistent inventory of assets, with changes to inventory entries recorded traceably. Inventory granularity is appropriate to the entity's needs and includes the list of operations/services and their description, and the list of network and information systems and other associated assets supporting those operations/services. The inventory and its assets are regularly reviewed and updated, with a documented history of changes.
- Applies to
- Digital infrastructure/service entities in Art 3 scope (DNS providers, TLD registries, cloud/data-centre/CDN providers, MSPs/MSSPs, online marketplaces, search engines, social platforms, trust services)
- Severity if failed
- High
- Applies from
- 6 Nov 2024
- Source
- NIS2-implementing-2024-2690.txt:9213-9313
How this is verified
A complete, accurate, up-to-date asset inventory exists covering §12.4.2(a)-(b) (operations/services and their supporting systems/assets), with traceably recorded changes and a regular review/update cadence
Review cadence ('regularly') is entity-defined — draft placeholder pending compliance-expert input.
Last verified against primary law 23 Jul 2026
NIS2-IMPL-12.5 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §12.5
Deposit, return or deletion of assets upon termination of employment
Establish, implement and apply procedures ensuring assets under personnel custody are deposited, returned or deleted upon termination of employment, with the deposit/return/deletion documented. Where deposit, return or deletion isn't possible, ensure those assets can no longer access the entity's network and information systems, per §12.2.2.
Applicable now
NIS2-IMPL-12.5 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §12.5
Deposit, return or deletion of assets upon termination of employment
Establish, implement and apply procedures ensuring assets under personnel custody are deposited, returned or deleted upon termination of employment, with the deposit/return/deletion documented. Where deposit, return or deletion isn't possible, ensure those assets can no longer access the entity's network and information systems, per §12.2.2.
- Applies to
- Digital infrastructure/service entities in Art 3 scope (DNS providers, TLD registries, cloud/data-centre/CDN providers, MSPs/MSSPs, online marketplaces, search engines, social platforms, trust services)
- Severity if failed
- Medium
- Applies from
- 6 Nov 2024
- Source
- NIS2-implementing-2024-2690.txt:9314-9318
How this is verified
Documented procedures ensure custodied assets are deposited/returned/deleted at termination with the action documented, or — where not possible — the asset's system access is revoked per §12.2.2
None beyond the primary text's own explicit fallback requirement.
Last verified against primary law 23 Jul 2026
NIS2-IMPL-13.1 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §13.1
Protection of supporting utilities
Prevent loss, damage or compromise of network and information systems, or interruption to operations, from failure or disruption of supporting utilities — where appropriate, protecting facilities from power failures and other utility disruptions (electricity, telecommunications, water, gas, sewage, ventilation, air conditioning); considering utility-service redundancy; protecting electricity/telecommunications utility services carrying data or supplying systems against interception and damage; monitoring those services and reporting threshold-breaching events to competent personnel; concluding emergency-supply contracts (e.g. fuel for emergency power); and ensuring continuous effectiveness through monitoring, maintenance and testing of the supply (electricity, temperature/humidity control, telecommunications, Internet connection). Protection measures are tested, reviewed and, where appropriate, updated regularly or after significant incidents or significant operational/risk changes.
Applicable now
NIS2-IMPL-13.1 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §13.1
Protection of supporting utilities
Prevent loss, damage or compromise of network and information systems, or interruption to operations, from failure or disruption of supporting utilities — where appropriate, protecting facilities from power failures and other utility disruptions (electricity, telecommunications, water, gas, sewage, ventilation, air conditioning); considering utility-service redundancy; protecting electricity/telecommunications utility services carrying data or supplying systems against interception and damage; monitoring those services and reporting threshold-breaching events to competent personnel; concluding emergency-supply contracts (e.g. fuel for emergency power); and ensuring continuous effectiveness through monitoring, maintenance and testing of the supply (electricity, temperature/humidity control, telecommunications, Internet connection). Protection measures are tested, reviewed and, where appropriate, updated regularly or after significant incidents or significant operational/risk changes.
- Applies to
- Digital infrastructure/service entities in Art 3 scope (DNS providers, TLD registries, cloud/data-centre/CDN providers, MSPs/MSSPs, online marketplaces, search engines, social platforms, trust services)
- Severity if failed
- High
- Applies from
- 6 Nov 2024
- Source
- NIS2-implementing-2024-2690.txt:9322-9498
How this is verified
Supporting-utility protection measures exist covering the applicable §13.1.2(a)-(f) elements, and are tested/reviewed regularly or after significant incidents/changes
Which measures are 'appropriate' and the test/review cadence are entity-specific — draft placeholders pending compliance-expert definition.
Last verified against primary law 23 Jul 2026
NIS2-IMPL-13.2 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §13.2
Protection against physical and environmental threats
Prevent or reduce the consequences of events from physical and environmental threats (natural disasters and other intentional or unintentional threats), based on the §2.1 risk assessment — where appropriate, designing and implementing protection measures, determining minimum/maximum control thresholds for physical/environmental threats, and monitoring environmental parameters with reporting to competent personnel on threshold breaches. Protection measures are tested, reviewed and, where appropriate, updated regularly or after significant incidents or significant operational/risk changes.
Applicable now
NIS2-IMPL-13.2 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §13.2
Protection against physical and environmental threats
Prevent or reduce the consequences of events from physical and environmental threats (natural disasters and other intentional or unintentional threats), based on the §2.1 risk assessment — where appropriate, designing and implementing protection measures, determining minimum/maximum control thresholds for physical/environmental threats, and monitoring environmental parameters with reporting to competent personnel on threshold breaches. Protection measures are tested, reviewed and, where appropriate, updated regularly or after significant incidents or significant operational/risk changes.
- Applies to
- Digital infrastructure/service entities in Art 3 scope (DNS providers, TLD registries, cloud/data-centre/CDN providers, MSPs/MSSPs, online marketplaces, search engines, social platforms, trust services)
- Severity if failed
- High
- Applies from
- 6 Nov 2024
- Source
- NIS2-implementing-2024-2690.txt:9499-9618
How this is verified
Risk-assessment-based physical/environmental threat protection measures exist per §13.2.2(a)-(c) (design/implementation, control thresholds, monitoring with breach reporting), and are tested/reviewed regularly or after significant incidents/changes
Threshold values and test/review cadence are entity-specific — draft placeholders pending compliance-expert definition.
Last verified against primary law 23 Jul 2026
NIS2-IMPL-13.3 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §13.3
Perimeter and physical access control
Prevent and monitor unauthorised physical access, damage and interference to network and information systems — laying down and using risk-assessment-based security perimeters to protect areas housing systems and associated assets; protecting those areas with appropriate entry controls and access points; designing and implementing physical security for offices, rooms and facilities; and continuously monitoring premises for unauthorised physical access. Physical access control measures are tested, reviewed and, where appropriate, updated regularly or after significant incidents or significant operational/risk changes.
Applicable now
NIS2-IMPL-13.3 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §13.3
Perimeter and physical access control
Prevent and monitor unauthorised physical access, damage and interference to network and information systems — laying down and using risk-assessment-based security perimeters to protect areas housing systems and associated assets; protecting those areas with appropriate entry controls and access points; designing and implementing physical security for offices, rooms and facilities; and continuously monitoring premises for unauthorised physical access. Physical access control measures are tested, reviewed and, where appropriate, updated regularly or after significant incidents or significant operational/risk changes.
- Applies to
- Digital infrastructure/service entities in Art 3 scope (DNS providers, TLD registries, cloud/data-centre/CDN providers, MSPs/MSSPs, online marketplaces, search engines, social platforms, trust services)
- Severity if failed
- High
- Applies from
- 6 Nov 2024
- Source
- NIS2-implementing-2024-2690.txt:9619-9762
How this is verified
Risk-assessment-based security perimeters, entry controls and continuous physical-access monitoring exist per §13.3.2(a)-(d), and physical access control measures are tested/reviewed regularly or after significant incidents/changes
Perimeter definitions and test/review cadence are entity-specific — draft placeholders pending compliance-expert definition.
Last verified against primary law 23 Jul 2026
NIS2-IMPL-2.1 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §2.1
Risk management framework and cybersecurity risk management process
Establish and maintain a risk management framework and a documented cybersecurity risk management process — following a defined methodology, risk tolerance and risk criteria, identifying risks with an all-hazards approach (including third-party and single-point-of-failure risk), analysing and evaluating them, prioritising and monitoring treatment, and documenting the risk treatment plan with justified residual-risk acceptance — reviewed at least annually or after significant change.
Applicable now
NIS2-IMPL-2.1 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §2.1
Risk management framework and cybersecurity risk management process
Establish and maintain a risk management framework and a documented cybersecurity risk management process — following a defined methodology, risk tolerance and risk criteria, identifying risks with an all-hazards approach (including third-party and single-point-of-failure risk), analysing and evaluating them, prioritising and monitoring treatment, and documenting the risk treatment plan with justified residual-risk acceptance — reviewed at least annually or after significant change.
- Applies to
- Digital infrastructure/service entities in Art 3 scope (DNS providers, TLD registries, cloud/data-centre/CDN providers, MSPs/MSSPs, online marketplaces, search engines, social platforms, trust services)
- Severity if failed
- High
- Applies from
- 6 Nov 2024
- Source
- NIS2-implementing-2024-2690.txt:2650-2916
How this is verified
A documented risk management framework and cybersecurity risk management process exist, risk assessments and a risk treatment plan are current, and both have been reviewed at least annually
The annual-review cadence is explicit in §2.1.4; the specific risk-criteria/tolerance thresholds an entity sets for itself are pending compliance-expert input.
Last verified against primary law 23 Jul 2026
NIS2-IMPL-2.2 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §2.2
Compliance monitoring
Regularly review compliance with the security policy, topic-specific policies, rules and standards, and inform the management body of the current security status through regular reporting via an effective compliance reporting system, at planned intervals or after significant incidents/changes.
Applicable now
NIS2-IMPL-2.2 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §2.2
Compliance monitoring
Regularly review compliance with the security policy, topic-specific policies, rules and standards, and inform the management body of the current security status through regular reporting via an effective compliance reporting system, at planned intervals or after significant incidents/changes.
- Applies to
- Digital infrastructure/service entities in Art 3 scope (DNS providers, TLD registries, cloud/data-centre/CDN providers, MSPs/MSSPs, online marketplaces, search engines, social platforms, trust services)
- Severity if failed
- Medium
- Applies from
- 6 Nov 2024
- Source
- NIS2-implementing-2024-2690.txt:2923-2979
How this is verified
Compliance reviews are performed at planned intervals with results reported to the management body via a functioning compliance reporting system
The review cadence ('planned intervals') is left to the entity to define — draft placeholder pending compliance-expert input on a concrete default.
Last verified against primary law 23 Jul 2026
NIS2-IMPL-2.3 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §2.3
Independent review of network and information system security
Independently review the approach to managing network-and-information-system security (people, processes, technology), carried out by reviewers with appropriate audit competence who are impartial and outside the line of authority of the area reviewed (or via alternative safeguards where the entity is too small for that separation), at planned intervals or after significant incidents/changes, with results — including compliance-monitoring and measurement output — reported to the management body.
Applicable now
NIS2-IMPL-2.3 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §2.3
Independent review of network and information system security
Independently review the approach to managing network-and-information-system security (people, processes, technology), carried out by reviewers with appropriate audit competence who are impartial and outside the line of authority of the area reviewed (or via alternative safeguards where the entity is too small for that separation), at planned intervals or after significant incidents/changes, with results — including compliance-monitoring and measurement output — reported to the management body.
- Applies to
- Digital infrastructure/service entities in Art 3 scope (DNS providers, TLD registries, cloud/data-centre/CDN providers, MSPs/MSSPs, online marketplaces, search engines, social platforms, trust services)
- Severity if failed
- Medium
- Applies from
- 6 Nov 2024
- Source
- NIS2-implementing-2024-2690.txt:2986-3062
How this is verified
Independent, impartial reviews of N&IS security (people, processes, technology) are conducted at planned intervals by competent reviewers, with results reported to the management body and corrective actions tracked
Review cadence and 'appropriate audit competence' criteria are draft placeholders pending compliance-expert definition.
Last verified against primary law 23 Jul 2026
NIS2-IMPL-3.1 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §3.1
Incident handling policy — roles, responsibilities and procedures
Establish and implement an incident handling policy that lays down roles, responsibilities and procedures for detecting, analysing, containing, responding to, recovering from, documenting and reporting incidents in a timely manner. The policy must be coherent with the business continuity and disaster recovery plan (§4.1), and include an incident categorisation system consistent with event assessment (§3.4.1), effective communication/escalation/reporting plans, role assignments to competent employees, and supporting documents (response manuals, escalation charts, contact lists, templates) — tested, reviewed and, where appropriate, updated at planned intervals and after significant incidents or changes.
Applicable now
NIS2-IMPL-3.1 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §3.1
Incident handling policy — roles, responsibilities and procedures
Establish and implement an incident handling policy that lays down roles, responsibilities and procedures for detecting, analysing, containing, responding to, recovering from, documenting and reporting incidents in a timely manner. The policy must be coherent with the business continuity and disaster recovery plan (§4.1), and include an incident categorisation system consistent with event assessment (§3.4.1), effective communication/escalation/reporting plans, role assignments to competent employees, and supporting documents (response manuals, escalation charts, contact lists, templates) — tested, reviewed and, where appropriate, updated at planned intervals and after significant incidents or changes.
- Applies to
- Digital infrastructure/service entities in Art 3 scope (DNS providers, TLD registries, cloud/data-centre/CDN providers, MSPs/MSSPs, online marketplaces, search engines, social platforms, trust services)
- Severity if failed
- High
- Applies from
- 6 Nov 2024
- Source
- NIS2-implementing-2024-2690.txt:3072-3210
How this is verified
A single incident handling policy exists covering detection, analysis, containment, response, recovery, documentation and reporting roles/procedures, is coherent with the business continuity plan, and has been tested/reviewed at planned intervals or after a significant incident/change
The 'planned intervals' testing/review cadence is left to the entity to define — draft placeholder pending compliance-expert input on a concrete default.
Last verified against primary law 23 Jul 2026
NIS2-IMPL-3.2 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §3.2
Monitoring and logging of network and information systems
Lay down procedures and use tools to monitor and log activity on network and information systems to detect events that could be incidents, minimising false positives/negatives and automating monitoring where feasible. Maintain, document and review logs covering — where appropriate, per the entity's own risk-based asset list — network traffic, user/permission changes, system and application access, authentication events, privileged/admin activity, configuration and backup changes, security-tool logs, resource usage, physical access, network-equipment access, log activation/pausing, and environmental events; reviewed regularly for unusual trends, with alarm thresholds triggering a timely qualified response. Logs must be backed up, protected from unauthorised access/change, time-synchronised across systems, and monitoring/logging systems kept redundant with availability monitored independently.
Applicable now
NIS2-IMPL-3.2 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §3.2
Monitoring and logging of network and information systems
Lay down procedures and use tools to monitor and log activity on network and information systems to detect events that could be incidents, minimising false positives/negatives and automating monitoring where feasible. Maintain, document and review logs covering — where appropriate, per the entity's own risk-based asset list — network traffic, user/permission changes, system and application access, authentication events, privileged/admin activity, configuration and backup changes, security-tool logs, resource usage, physical access, network-equipment access, log activation/pausing, and environmental events; reviewed regularly for unusual trends, with alarm thresholds triggering a timely qualified response. Logs must be backed up, protected from unauthorised access/change, time-synchronised across systems, and monitoring/logging systems kept redundant with availability monitored independently.
- Applies to
- Digital infrastructure/service entities in Art 3 scope (DNS providers, TLD registries, cloud/data-centre/CDN providers, MSPs/MSSPs, online marketplaces, search engines, social platforms, trust services)
- Severity if failed
- High
- Applies from
- 6 Nov 2024
- Source
- NIS2-implementing-2024-2690.txt:3211-3581
How this is verified
Monitoring and logging procedures and tools are in place covering the applicable §3.2.3(a)-(l) log categories per the entity's own risk-based asset list, logs are reviewed regularly with alarm thresholds configured, and logs are backed up, access-protected and time-synchronised
Which of the twelve §3.2.3 log categories are 'appropriate' depends on the entity's own risk assessment (§2.1) — the applicable subset and retention period are draft placeholders pending compliance-expert definition.
Last verified against primary law 23 Jul 2026
NIS2-IMPL-3.3 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §3.3
Event reporting mechanism for employees, suppliers and customers
Put in place a simple mechanism allowing employees, suppliers and customers to report suspicious events, communicate that mechanism to suppliers and customers where appropriate, and regularly train employees on how to use it.
Applicable now
NIS2-IMPL-3.3 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §3.3
Event reporting mechanism for employees, suppliers and customers
Put in place a simple mechanism allowing employees, suppliers and customers to report suspicious events, communicate that mechanism to suppliers and customers where appropriate, and regularly train employees on how to use it.
- Applies to
- Digital infrastructure/service entities in Art 3 scope (DNS providers, TLD registries, cloud/data-centre/CDN providers, MSPs/MSSPs, online marketplaces, search engines, social platforms, trust services)
- Severity if failed
- Medium
- Applies from
- 6 Nov 2024
- Source
- NIS2-implementing-2024-2690.txt:3582-3624
How this is verified
A simple suspicious-event reporting mechanism exists, is communicated to suppliers/customers where appropriate, and employees receive regular training on its use
Training frequency ('regularly') is left to the entity to define — draft placeholder pending compliance-expert input.
Last verified against primary law 23 Jul 2026
NIS2-IMPL-3.4 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §3.4
Event assessment and classification
Assess suspicious events against predefined criteria to determine whether they constitute incidents and, if so, their nature and severity — using triage to prioritise containment/eradication, reviewing relevant logs, correlating and analysing them, assessing recurring incidents on a quarterly basis, and reassessing/reclassifying events as new information becomes available.
Applicable now
NIS2-IMPL-3.4 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §3.4
Event assessment and classification
Assess suspicious events against predefined criteria to determine whether they constitute incidents and, if so, their nature and severity — using triage to prioritise containment/eradication, reviewing relevant logs, correlating and analysing them, assessing recurring incidents on a quarterly basis, and reassessing/reclassifying events as new information becomes available.
- Applies to
- Digital infrastructure/service entities in Art 3 scope (DNS providers, TLD registries, cloud/data-centre/CDN providers, MSPs/MSSPs, online marketplaces, search engines, social platforms, trust services)
- Severity if failed
- High
- Applies from
- 6 Nov 2024
- Source
- NIS2-implementing-2024-2690.txt:3625-3762
How this is verified
Suspicious events are assessed against predefined criteria with documented triage, relevant logs are reviewed and correlated, recurring incidents are assessed quarterly, and events are reassessed as new information emerges
The predefined assessment criteria and severity thresholds are entity-specific — draft placeholder pending compliance-expert definition.
Last verified against primary law 23 Jul 2026
NIS2-IMPL-3.5 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §3.5
Incident response — containment, eradication and recovery
Respond to incidents in a timely manner per documented procedures covering containment (preventing spread), eradication (preventing recurrence) and recovery. Establish communication plans and procedures with CSIRTs/competent authorities for incident notification and for internal/external stakeholder communication during an incident. Log incident response activities and record evidence, and test incident response procedures at planned intervals.
Applicable now
NIS2-IMPL-3.5 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §3.5
Incident response — containment, eradication and recovery
Respond to incidents in a timely manner per documented procedures covering containment (preventing spread), eradication (preventing recurrence) and recovery. Establish communication plans and procedures with CSIRTs/competent authorities for incident notification and for internal/external stakeholder communication during an incident. Log incident response activities and record evidence, and test incident response procedures at planned intervals.
- Applies to
- Digital infrastructure/service entities in Art 3 scope (DNS providers, TLD registries, cloud/data-centre/CDN providers, MSPs/MSSPs, online marketplaces, search engines, social platforms, trust services)
- Severity if failed
- Critical
- Applies from
- 6 Nov 2024
- Source
- NIS2-implementing-2024-2690.txt:3763-3960
How this is verified
Documented incident response procedures covering containment, eradication and recovery exist and are followed in a timely manner, CSIRT/competent-authority and internal/external communication plans exist, response activities are logged with evidence retained, and procedures are tested at planned intervals
The test cadence ('planned intervals') and 'timely manner' threshold are entity-defined — draft placeholders pending compliance-expert input.
Last verified against primary law 23 Jul 2026
NIS2-IMPL-3.6 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §3.6
Post-incident reviews and lessons learned
Where appropriate, carry out post-incident reviews after recovery to identify the root cause and produce documented lessons learned that reduce the occurrence and consequences of future incidents, feeding improvements back into network/information security, risk treatment, and incident handling/detection/response procedures — reviewing at planned intervals whether incidents led to post-incident reviews.
Applicable now
NIS2-IMPL-3.6 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §3.6
Post-incident reviews and lessons learned
Where appropriate, carry out post-incident reviews after recovery to identify the root cause and produce documented lessons learned that reduce the occurrence and consequences of future incidents, feeding improvements back into network/information security, risk treatment, and incident handling/detection/response procedures — reviewing at planned intervals whether incidents led to post-incident reviews.
- Applies to
- Digital infrastructure/service entities in Art 3 scope (DNS providers, TLD registries, cloud/data-centre/CDN providers, MSPs/MSSPs, online marketplaces, search engines, social platforms, trust services)
- Severity if failed
- Medium
- Applies from
- 6 Nov 2024
- Source
- NIS2-implementing-2024-2690.txt:3961-4023
How this is verified
Post-incident reviews are carried out where appropriate after recovery, identify root cause with documented lessons learned, and feed back into security/risk-treatment/incident-handling procedures
The entity itself determines when a review is 'appropriate' — draft placeholder pending compliance-expert definition of a concrete trigger threshold (e.g. severity tier).
Last verified against primary law 23 Jul 2026
NIS2-IMPL-4.1 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §4.1
Business continuity and disaster recovery plan
Lay down and maintain a business continuity and disaster recovery plan for incidents, based on the §2.1 risk assessment, covering purpose/scope/audience, roles and responsibilities, key contacts and communication channels, activation/deactivation conditions, recovery order, per-operation recovery plans with objectives, required resources (backups and redundancies), and restoring/resuming activities from temporary measures. A business impact analysis shall assess the potential impact of severe disruptions and establish continuity requirements for network and information systems. The plan is tested, reviewed and, where appropriate, updated at planned intervals and after significant incidents or changes, incorporating lessons learnt.
Applicable now
NIS2-IMPL-4.1 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §4.1
Business continuity and disaster recovery plan
Lay down and maintain a business continuity and disaster recovery plan for incidents, based on the §2.1 risk assessment, covering purpose/scope/audience, roles and responsibilities, key contacts and communication channels, activation/deactivation conditions, recovery order, per-operation recovery plans with objectives, required resources (backups and redundancies), and restoring/resuming activities from temporary measures. A business impact analysis shall assess the potential impact of severe disruptions and establish continuity requirements for network and information systems. The plan is tested, reviewed and, where appropriate, updated at planned intervals and after significant incidents or changes, incorporating lessons learnt.
- Applies to
- Digital infrastructure/service entities in Art 3 scope (DNS providers, TLD registries, cloud/data-centre/CDN providers, MSPs/MSSPs, online marketplaces, search engines, social platforms, trust services)
- Severity if failed
- Critical
- Applies from
- 6 Nov 2024
- Source
- NIS2-implementing-2024-2690.txt:4027-4261
How this is verified
A risk-assessment-based business continuity/disaster recovery plan exists covering the §4.1.2(a)-(h) elements, a business impact analysis has established continuity requirements, and the plan has been tested/reviewed at planned intervals or after a significant incident/change, incorporating lessons learnt
The 'planned intervals' test/review cadence is left to the entity to define — draft placeholder pending compliance-expert input.
Last verified against primary law 23 Jul 2026
NIS2-IMPL-4.2 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §4.2
Backup and redundancy management
Maintain data backup copies and sufficient redundant resources (facilities, network and information systems, staff). Lay down backup plans covering recovery times, backup completeness/accuracy (including data held in cloud environments), safe offline/online storage at a location distant enough to escape a disaster at the main site, physical/logical access controls matched to asset classification, restoration procedures, and retention periods based on business and regulatory requirements. Perform regular backup integrity checks; ensure at least partial redundancy of systems, assets, personnel and communication channels based on the risk assessment and continuity plan; keep resource monitoring and adjustment informed by backup/redundancy requirements; and regularly test recovery of backups and redundancies, documenting results and taking corrective action where needed.
Applicable now
NIS2-IMPL-4.2 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §4.2
Backup and redundancy management
Maintain data backup copies and sufficient redundant resources (facilities, network and information systems, staff). Lay down backup plans covering recovery times, backup completeness/accuracy (including data held in cloud environments), safe offline/online storage at a location distant enough to escape a disaster at the main site, physical/logical access controls matched to asset classification, restoration procedures, and retention periods based on business and regulatory requirements. Perform regular backup integrity checks; ensure at least partial redundancy of systems, assets, personnel and communication channels based on the risk assessment and continuity plan; keep resource monitoring and adjustment informed by backup/redundancy requirements; and regularly test recovery of backups and redundancies, documenting results and taking corrective action where needed.
- Applies to
- Digital infrastructure/service entities in Art 3 scope (DNS providers, TLD registries, cloud/data-centre/CDN providers, MSPs/MSSPs, online marketplaces, search engines, social platforms, trust services)
- Severity if failed
- Critical
- Applies from
- 6 Nov 2024
- Source
- NIS2-implementing-2024-2690.txt:4262-4574
How this is verified
Backup plans exist covering recovery times, completeness/accuracy, safe offsite storage, classification-based access controls and retention periods; backup integrity is checked regularly; systems/assets/personnel/communications have at least partial redundancy; and recovery of backups and redundancies is tested regularly with results documented
The 'appropriate level of redundancy' and integrity-check/recovery-test cadence are left to the entity's own risk assessment — draft placeholders pending compliance-expert definition.
Last verified against primary law 23 Jul 2026
NIS2-IMPL-4.3 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §4.3
Crisis management process
Put in place a crisis management process addressing personnel and, where appropriate, supplier/service-provider role allocation with specific steps to follow in crisis situations; appropriate communication channels with relevant competent authorities, covering both obligatory communications (e.g. incident reports and related timelines) and non-obligatory communications; and measures to maintain network and information system security during crises. Implement a process for managing and using information received from CSIRTs or competent authorities about incidents, vulnerabilities, threats or possible mitigation measures. Test, review and, where appropriate, update the crisis management plan on a regular basis or following significant incidents or significant changes to operations or risks.
Applicable now
NIS2-IMPL-4.3 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §4.3
Crisis management process
Put in place a crisis management process addressing personnel and, where appropriate, supplier/service-provider role allocation with specific steps to follow in crisis situations; appropriate communication channels with relevant competent authorities, covering both obligatory communications (e.g. incident reports and related timelines) and non-obligatory communications; and measures to maintain network and information system security during crises. Implement a process for managing and using information received from CSIRTs or competent authorities about incidents, vulnerabilities, threats or possible mitigation measures. Test, review and, where appropriate, update the crisis management plan on a regular basis or following significant incidents or significant changes to operations or risks.
- Applies to
- Digital infrastructure/service entities in Art 3 scope (DNS providers, TLD registries, cloud/data-centre/CDN providers, MSPs/MSSPs, online marketplaces, search engines, social platforms, trust services)
- Severity if failed
- High
- Applies from
- 6 Nov 2024
- Source
- NIS2-implementing-2024-2690.txt:4575-4716
How this is verified
A crisis management process exists covering role allocation, competent-authority communication channels (obligatory and non-obligatory), and security-maintenance measures during crises; a process exists for using CSIRT/competent-authority threat information; and the plan is tested/reviewed regularly or after a significant incident/change
The test/review cadence ('regular basis') is left to the entity to define — draft placeholder pending compliance-expert input.
Last verified against primary law 23 Jul 2026
NIS2-IMPL-5.1 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §5.1
Supply chain security policy — supplier selection, contracts and review
Establish, implement and apply a supply chain security policy governing direct suppliers and service providers to mitigate identified network-and-information-system security risks; identify the entity's own role in the supply chain and communicate it to those suppliers. The policy sets supplier/service-provider selection and contracting criteria — cybersecurity practices (including secure development), ability to meet the entity's cybersecurity specifications, ICT product/service quality, resilience and risk classification, and supply diversification/anti-lock-in where applicable — taking into account any Article 22(1) coordinated supply-chain risk assessments where applicable. Based on the policy and the §2.1 risk assessment, contracts/SLAs specify, where appropriate: cybersecurity requirements (including §6.1 acquisition requirements), supplier-staff awareness/training/certification requirements, background-verification requirements, prompt incident-notification obligations, audit or audit-report rights, vulnerability-handling obligations, subcontracting requirements, and contract-termination obligations (e.g. data retrieval/disposal). These elements feed both new-supplier selection and the §6.1 procurement process; the policy and supplier practice are reviewed, monitored and acted on at planned intervals and after significant operational/risk changes or supplier-related incidents — including regular SLA-report monitoring, incident review, unscheduled-review assessment, and timely risk mitigation for ICT product/service changes.
Applicable now
NIS2-IMPL-5.1 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §5.1
Supply chain security policy — supplier selection, contracts and review
Establish, implement and apply a supply chain security policy governing direct suppliers and service providers to mitigate identified network-and-information-system security risks; identify the entity's own role in the supply chain and communicate it to those suppliers. The policy sets supplier/service-provider selection and contracting criteria — cybersecurity practices (including secure development), ability to meet the entity's cybersecurity specifications, ICT product/service quality, resilience and risk classification, and supply diversification/anti-lock-in where applicable — taking into account any Article 22(1) coordinated supply-chain risk assessments where applicable. Based on the policy and the §2.1 risk assessment, contracts/SLAs specify, where appropriate: cybersecurity requirements (including §6.1 acquisition requirements), supplier-staff awareness/training/certification requirements, background-verification requirements, prompt incident-notification obligations, audit or audit-report rights, vulnerability-handling obligations, subcontracting requirements, and contract-termination obligations (e.g. data retrieval/disposal). These elements feed both new-supplier selection and the §6.1 procurement process; the policy and supplier practice are reviewed, monitored and acted on at planned intervals and after significant operational/risk changes or supplier-related incidents — including regular SLA-report monitoring, incident review, unscheduled-review assessment, and timely risk mitigation for ICT product/service changes.
- Applies to
- Digital infrastructure/service entities in Art 3 scope (DNS providers, TLD registries, cloud/data-centre/CDN providers, MSPs/MSSPs, online marketplaces, search engines, social platforms, trust services)
- Severity if failed
- High
- Applies from
- 6 Nov 2024
- Source
- NIS2-implementing-2024-2690.txt:4720-5166
How this is verified
A supply chain security policy exists identifying the entity's role and communicating it to direct suppliers, sets selection/contracting criteria covering §5.1.2(a)-(d), and results in contracts/SLAs specifying the applicable §5.1.4(a)-(h) terms; the policy and supplier practice are reviewed at planned intervals and after significant changes/incidents per §5.1.6-5.1.7
Which §5.1.4 contract terms are 'appropriate' for a given supplier, and the policy/practice review cadence, are entity-specific — draft placeholders pending compliance-expert definition.
Last verified against primary law 23 Jul 2026
NIS2-IMPL-5.2 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §5.2
Directory of suppliers and service providers
Maintain and keep up to date a registry of direct suppliers and service providers, including a contact point for each and a list of the ICT products, ICT services and ICT processes each one provides to the entity.
Applicable now
NIS2-IMPL-5.2 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §5.2
Directory of suppliers and service providers
Maintain and keep up to date a registry of direct suppliers and service providers, including a contact point for each and a list of the ICT products, ICT services and ICT processes each one provides to the entity.
- Applies to
- Digital infrastructure/service entities in Art 3 scope (DNS providers, TLD registries, cloud/data-centre/CDN providers, MSPs/MSSPs, online marketplaces, search engines, social platforms, trust services)
- Severity if failed
- Medium
- Applies from
- 6 Nov 2024
- Source
- NIS2-implementing-2024-2690.txt:5167-5209
How this is verified
An up-to-date registry of direct suppliers/service providers exists, listing a contact point and the ICT products/services/processes each one provides
The refresh cadence implied by 'kept up to date' is left to the entity to define — draft placeholder pending compliance-expert definition.
Last verified against primary law 23 Jul 2026
NIS2-IMPL-6.1 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §6.1
Security in acquisition of ICT services and products
Set and implement processes to manage risks stemming from acquiring ICT services or products for components critical to the entity's network and information system security, based on the §2.1 risk assessment, throughout the supplier or service-provider relationship's life cycle. Processes cover: security requirements to apply to acquired ICT services/products; requirements for security updates throughout their lifetime or replacement after end of support; documentation of the hardware/software components used; documentation of implemented cybersecurity functions and the configuration required for secure operation; assurance that the ICT services/products comply with the stated security requirements; and validation methods confirming delivered ICT services/products meet those requirements, with the validation results documented. Reviewed and, where appropriate, updated at planned intervals and when significant incidents occur.
Applicable now
NIS2-IMPL-6.1 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §6.1
Security in acquisition of ICT services and products
Set and implement processes to manage risks stemming from acquiring ICT services or products for components critical to the entity's network and information system security, based on the §2.1 risk assessment, throughout the supplier or service-provider relationship's life cycle. Processes cover: security requirements to apply to acquired ICT services/products; requirements for security updates throughout their lifetime or replacement after end of support; documentation of the hardware/software components used; documentation of implemented cybersecurity functions and the configuration required for secure operation; assurance that the ICT services/products comply with the stated security requirements; and validation methods confirming delivered ICT services/products meet those requirements, with the validation results documented. Reviewed and, where appropriate, updated at planned intervals and when significant incidents occur.
- Applies to
- Digital infrastructure/service entities in Art 3 scope (DNS providers, TLD registries, cloud/data-centre/CDN providers, MSPs/MSSPs, online marketplaces, search engines, social platforms, trust services)
- Severity if failed
- High
- Applies from
- 6 Nov 2024
- Source
- NIS2-implementing-2024-2690.txt:5213-5389
How this is verified
Documented acquisition-risk-management processes exist covering the §6.1.2(a)-(f) elements for ICT services/products critical to N&IS security, and are reviewed at planned intervals or after significant incidents
Which components are 'critical' and the review cadence are entity-specific — draft placeholders pending compliance-expert definition.
Last verified against primary law 23 Jul 2026
NIS2-IMPL-6.10 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §6.10
Vulnerability handling and disclosure
Obtain information about technical vulnerabilities in network and information systems, evaluate exposure, and take appropriate management measures: monitor vulnerability information through appropriate channels (CSIRTs, competent authorities, supplier/service-provider information); perform vulnerability scans where appropriate with recorded evidence at planned intervals; address vulnerabilities identified as critical to operations without undue delay; ensure vulnerability handling is compatible with change management, security patch management, risk management and incident management procedures; and lay down a vulnerability-disclosure procedure consistent with the applicable national coordinated vulnerability disclosure policy. Where justified by potential impact, create and implement a mitigation plan; otherwise document and substantiate why remediation isn't required. Monitoring channels are reviewed and, where appropriate, updated at planned intervals.
Applicable now
NIS2-IMPL-6.10 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §6.10
Vulnerability handling and disclosure
Obtain information about technical vulnerabilities in network and information systems, evaluate exposure, and take appropriate management measures: monitor vulnerability information through appropriate channels (CSIRTs, competent authorities, supplier/service-provider information); perform vulnerability scans where appropriate with recorded evidence at planned intervals; address vulnerabilities identified as critical to operations without undue delay; ensure vulnerability handling is compatible with change management, security patch management, risk management and incident management procedures; and lay down a vulnerability-disclosure procedure consistent with the applicable national coordinated vulnerability disclosure policy. Where justified by potential impact, create and implement a mitigation plan; otherwise document and substantiate why remediation isn't required. Monitoring channels are reviewed and, where appropriate, updated at planned intervals.
- Applies to
- Digital infrastructure/service entities in Art 3 scope (DNS providers, TLD registries, cloud/data-centre/CDN providers, MSPs/MSSPs, online marketplaces, search engines, social platforms, trust services)
- Severity if failed
- High
- Applies from
- 6 Nov 2024
- Source
- NIS2-implementing-2024-2690.txt:6578-6755
How this is verified
Vulnerability information is actively monitored through appropriate channels, exposure is evaluated with scans where appropriate, critical vulnerabilities are addressed without undue delay, handling is integrated with related management procedures, and a coordinated-disclosure procedure exists; each vulnerability either has a documented mitigation plan or a documented no-remediation justification
The scan cadence and 'critical to operations' threshold are entity-specific — draft placeholders pending compliance-expert definition.
Last verified against primary law 23 Jul 2026
NIS2-IMPL-6.2 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §6.2
Secure development life cycle
Before developing a network and information system (including software), lay down and apply secure-development rules covering all development phases — specification, design, development, implementation and testing — for both in-house and outsourced development. This includes: security-requirements analysis at the specification/design phases of any development or acquisition project; secure-engineering and secure-coding principles such as cybersecurity-by-design and zero-trust architectures; security requirements for development environments; security testing processes within the development life cycle; appropriate selection, protection and management of security test data; and sanitisation/anonymisation of test data per the §2.1 risk assessment. Outsourced development additionally applies the §5 supply-chain and §6.1 acquisition policies/procedures. Rules are reviewed and, where necessary, updated at planned intervals.
Applicable now
NIS2-IMPL-6.2 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §6.2
Secure development life cycle
Before developing a network and information system (including software), lay down and apply secure-development rules covering all development phases — specification, design, development, implementation and testing — for both in-house and outsourced development. This includes: security-requirements analysis at the specification/design phases of any development or acquisition project; secure-engineering and secure-coding principles such as cybersecurity-by-design and zero-trust architectures; security requirements for development environments; security testing processes within the development life cycle; appropriate selection, protection and management of security test data; and sanitisation/anonymisation of test data per the §2.1 risk assessment. Outsourced development additionally applies the §5 supply-chain and §6.1 acquisition policies/procedures. Rules are reviewed and, where necessary, updated at planned intervals.
- Applies to
- Digital infrastructure/service entities in Art 3 scope (DNS providers, TLD registries, cloud/data-centre/CDN providers, MSPs/MSSPs, online marketplaces, search engines, social platforms, trust services)
- Severity if failed
- High
- Applies from
- 6 Nov 2024
- Source
- NIS2-implementing-2024-2690.txt:5390-5586
How this is verified
Documented secure-development rules exist covering all development phases and the §6.2.2(a)-(f) elements, apply to both in-house and outsourced development (with §5/§6.1 additionally applied for outsourcing), and are reviewed at planned intervals
The review cadence ('planned intervals') is left to the entity to define — draft placeholder pending compliance-expert input.
Last verified against primary law 23 Jul 2026
NIS2-IMPL-6.3 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §6.3
Configuration management
Take appropriate measures to establish, document, implement and monitor configurations — including security configurations — of hardware, software, services and networks: laying down and ensuring secure configurations, and laying down and implementing processes/tools to enforce those configurations for newly installed systems and for systems in operation over their lifetime. Configurations are reviewed and, where appropriate, updated at planned intervals or when significant incidents or significant operational/risk changes occur.
Applicable now
NIS2-IMPL-6.3 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §6.3
Configuration management
Take appropriate measures to establish, document, implement and monitor configurations — including security configurations — of hardware, software, services and networks: laying down and ensuring secure configurations, and laying down and implementing processes/tools to enforce those configurations for newly installed systems and for systems in operation over their lifetime. Configurations are reviewed and, where appropriate, updated at planned intervals or when significant incidents or significant operational/risk changes occur.
- Applies to
- Digital infrastructure/service entities in Art 3 scope (DNS providers, TLD registries, cloud/data-centre/CDN providers, MSPs/MSSPs, online marketplaces, search engines, social platforms, trust services)
- Severity if failed
- High
- Applies from
- 6 Nov 2024
- Source
- NIS2-implementing-2024-2690.txt:5587-5687
How this is verified
Documented, monitored security configurations exist for hardware/software/services/networks, enforced via defined processes/tools for both newly installed and in-operation systems, and reviewed at planned intervals or after significant incidents/changes
The review cadence is entity-defined — draft placeholder pending compliance-expert input.
Last verified against primary law 23 Jul 2026
NIS2-IMPL-6.4 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §6.4
Change management, repairs and maintenance
Apply change management procedures — consistent with the entity's general change-management policies where applicable — to control changes to network and information systems, covering releases, modifications and emergency changes to software/hardware in operation and configuration changes; changes must be documented and, based on the §2.1 risk assessment, tested and impact-assessed before implementation. Where an emergency prevents following the regular procedure, the entity documents the change's result and the reason the procedure could not be followed. Procedures are reviewed and, where appropriate, updated at planned intervals and when significant incidents or significant operational/risk changes occur.
Applicable now
NIS2-IMPL-6.4 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §6.4
Change management, repairs and maintenance
Apply change management procedures — consistent with the entity's general change-management policies where applicable — to control changes to network and information systems, covering releases, modifications and emergency changes to software/hardware in operation and configuration changes; changes must be documented and, based on the §2.1 risk assessment, tested and impact-assessed before implementation. Where an emergency prevents following the regular procedure, the entity documents the change's result and the reason the procedure could not be followed. Procedures are reviewed and, where appropriate, updated at planned intervals and when significant incidents or significant operational/risk changes occur.
- Applies to
- Digital infrastructure/service entities in Art 3 scope (DNS providers, TLD registries, cloud/data-centre/CDN providers, MSPs/MSSPs, online marketplaces, search engines, social platforms, trust services)
- Severity if failed
- High
- Applies from
- 6 Nov 2024
- Source
- NIS2-implementing-2024-2690.txt:5688-5770
How this is verified
Documented change management procedures exist covering releases/modifications/emergency changes with pre-implementation testing and impact assessment, emergency deviations are documented with justification, and procedures are reviewed at planned intervals or after significant incidents/changes
Review cadence is entity-defined — draft placeholder pending compliance-expert input.
Last verified against primary law 23 Jul 2026
NIS2-IMPL-6.5 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §6.5
Security testing
Establish, implement and apply a security testing policy and procedures: determine the need, scope, frequency and type of security tests based on the §2.1 risk assessment; carry out tests per a documented methodology covering components identified as relevant to secure operation; document the type, scope, time and results of tests including a criticality assessment and mitigating actions per finding; and apply mitigating actions for critical findings. The policy is reviewed and, where appropriate, updated at planned intervals.
Applicable now
NIS2-IMPL-6.5 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §6.5
Security testing
Establish, implement and apply a security testing policy and procedures: determine the need, scope, frequency and type of security tests based on the §2.1 risk assessment; carry out tests per a documented methodology covering components identified as relevant to secure operation; document the type, scope, time and results of tests including a criticality assessment and mitigating actions per finding; and apply mitigating actions for critical findings. The policy is reviewed and, where appropriate, updated at planned intervals.
- Applies to
- Digital infrastructure/service entities in Art 3 scope (DNS providers, TLD registries, cloud/data-centre/CDN providers, MSPs/MSSPs, online marketplaces, search engines, social platforms, trust services)
- Severity if failed
- High
- Applies from
- 6 Nov 2024
- Source
- NIS2-implementing-2024-2690.txt:5771-5909
How this is verified
A documented security testing policy and methodology exist, tests are scoped/scheduled per the risk assessment, results and mitigating actions are documented, and critical findings receive mitigating action
Test frequency/type thresholds and the review cadence are entity-specific — draft placeholders pending compliance-expert definition.
Last verified against primary law 23 Jul 2026
NIS2-IMPL-6.6 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §6.6
Security patch management
Specify and apply patch-management procedures, coherent with change management, vulnerability management, risk management and other relevant procedures, ensuring: security patches are applied within a reasonable time after becoming available; patches are tested before production deployment; patches come from trusted sources and are integrity-checked; and additional measures with residual-risk acceptance apply where a patch is unavailable or not applied. By derogation, an entity may choose not to apply a patch when the disadvantages outweigh the cybersecurity benefits — such a decision must be documented and substantiated.
Applicable now
NIS2-IMPL-6.6 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §6.6
Security patch management
Specify and apply patch-management procedures, coherent with change management, vulnerability management, risk management and other relevant procedures, ensuring: security patches are applied within a reasonable time after becoming available; patches are tested before production deployment; patches come from trusted sources and are integrity-checked; and additional measures with residual-risk acceptance apply where a patch is unavailable or not applied. By derogation, an entity may choose not to apply a patch when the disadvantages outweigh the cybersecurity benefits — such a decision must be documented and substantiated.
- Applies to
- Digital infrastructure/service entities in Art 3 scope (DNS providers, TLD registries, cloud/data-centre/CDN providers, MSPs/MSSPs, online marketplaces, search engines, social platforms, trust services)
- Severity if failed
- High
- Applies from
- 6 Nov 2024
- Source
- NIS2-implementing-2024-2690.txt:5910-6028
How this is verified
Patch-management procedures exist ensuring timely, tested, integrity-checked patch application coherent with change/vulnerability/risk management, with any non-application decision documented and substantiated
What counts as a 'reasonable time' to apply a patch is entity/risk-specific — draft placeholder pending compliance-expert definition of a concrete SLA.
Last verified against primary law 23 Jul 2026
NIS2-IMPL-6.7 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §6.7
Network security
Take appropriate measures to protect network and information systems from cyber threats: document the network architecture in a comprehensible, up-to-date manner; determine and apply controls protecting internal network domains from unauthorised access; configure controls preventing unnecessary access/communication; determine and apply remote-access controls, including for service providers; keep security-policy administration systems separate from other uses; forbid or deactivate unneeded connections and services; where appropriate, restrict network access to authorised devices; allow service-provider connections only via time-boxed authorisation requests; use trusted, isolated channels (logical, cryptographic or physical separation with assured endpoint identification and protection from modification/disclosure) between distinct systems; adopt and accelerate an implementation plan for transitioning to latest-generation network-layer protocols; adopt and accelerate an implementation plan for modern, interoperable secure e-mail communication standards; and apply DNS security and Internet routing security/hygiene best practices. Measures are reviewed and, where appropriate, updated at planned intervals and after significant incidents or changes.
Applicable now
NIS2-IMPL-6.7 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §6.7
Network security
Take appropriate measures to protect network and information systems from cyber threats: document the network architecture in a comprehensible, up-to-date manner; determine and apply controls protecting internal network domains from unauthorised access; configure controls preventing unnecessary access/communication; determine and apply remote-access controls, including for service providers; keep security-policy administration systems separate from other uses; forbid or deactivate unneeded connections and services; where appropriate, restrict network access to authorised devices; allow service-provider connections only via time-boxed authorisation requests; use trusted, isolated channels (logical, cryptographic or physical separation with assured endpoint identification and protection from modification/disclosure) between distinct systems; adopt and accelerate an implementation plan for transitioning to latest-generation network-layer protocols; adopt and accelerate an implementation plan for modern, interoperable secure e-mail communication standards; and apply DNS security and Internet routing security/hygiene best practices. Measures are reviewed and, where appropriate, updated at planned intervals and after significant incidents or changes.
- Applies to
- Digital infrastructure/service entities in Art 3 scope (DNS providers, TLD registries, cloud/data-centre/CDN providers, MSPs/MSSPs, online marketplaces, search engines, social platforms, trust services)
- Severity if failed
- High
- Applies from
- 6 Nov 2024
- Source
- NIS2-implementing-2024-2690.txt:6029-6319
How this is verified
Network architecture is documented and current, access/communication controls per §6.7.2(a)-(l) are implemented, and measures are reviewed at planned intervals or after significant incidents/changes
The transition-plan timelines for network-layer protocols and e-mail security standards (§6.7.2(j)-(k)) are entity-specific — draft placeholders pending compliance-expert definition of concrete milestones.
Last verified against primary law 23 Jul 2026
NIS2-IMPL-6.8 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §6.8
Network segmentation
Segment systems into networks or zones per the §2.1 risk assessment, and segment the entity's own systems/networks from third parties' systems/networks — considering the functional, logical and physical relationship (including location) between trustworthy systems/services; granting zone access based on an assessment of security requirements; keeping operation- or safety-critical systems in secured zones; deploying a demilitarised zone for communications originating from or destined to the entity's networks; restricting inter/intra-zone access and communication to what's necessary for operation or safety; separating the network-administration network from the operational network; segregating network-administration channels from other traffic; and separating production systems (including backups) from development/testing systems. Segmentation is reviewed and, where appropriate, updated at planned intervals and after significant incidents or changes.
Applicable now
NIS2-IMPL-6.8 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §6.8
Network segmentation
Segment systems into networks or zones per the §2.1 risk assessment, and segment the entity's own systems/networks from third parties' systems/networks — considering the functional, logical and physical relationship (including location) between trustworthy systems/services; granting zone access based on an assessment of security requirements; keeping operation- or safety-critical systems in secured zones; deploying a demilitarised zone for communications originating from or destined to the entity's networks; restricting inter/intra-zone access and communication to what's necessary for operation or safety; separating the network-administration network from the operational network; segregating network-administration channels from other traffic; and separating production systems (including backups) from development/testing systems. Segmentation is reviewed and, where appropriate, updated at planned intervals and after significant incidents or changes.
- Applies to
- Digital infrastructure/service entities in Art 3 scope (DNS providers, TLD registries, cloud/data-centre/CDN providers, MSPs/MSSPs, online marketplaces, search engines, social platforms, trust services)
- Severity if failed
- High
- Applies from
- 6 Nov 2024
- Source
- NIS2-implementing-2024-2690.txt:6320-6534
How this is verified
Risk-assessment-based network segmentation exists implementing the §6.8.2(a)-(h) elements (including production/dev-test separation and admin-network isolation), and is reviewed at planned intervals or after significant incidents/changes
Zone boundaries and 'critical to operation or safety' classification are entity-specific — draft placeholders pending compliance-expert definition.
Last verified against primary law 23 Jul 2026
NIS2-IMPL-6.9 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §6.9
Protection against malicious and unauthorised software
Protect network and information systems against malicious and unauthorised software, in particular by implementing measures that detect or prevent its use — where appropriate, equipping systems with detection-and-response software that is regularly updated per the §2.1 risk assessment and the contractual agreements with providers.
Applicable now
NIS2-IMPL-6.9 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §6.9
Protection against malicious and unauthorised software
Protect network and information systems against malicious and unauthorised software, in particular by implementing measures that detect or prevent its use — where appropriate, equipping systems with detection-and-response software that is regularly updated per the §2.1 risk assessment and the contractual agreements with providers.
- Applies to
- Digital infrastructure/service entities in Art 3 scope (DNS providers, TLD registries, cloud/data-centre/CDN providers, MSPs/MSSPs, online marketplaces, search engines, social platforms, trust services)
- Severity if failed
- High
- Applies from
- 6 Nov 2024
- Source
- NIS2-implementing-2024-2690.txt:6535-6577
How this is verified
Detection/prevention measures for malicious and unauthorised software are implemented, with detection-and-response software equipped where appropriate and kept regularly updated
Update frequency and which systems require detection-and-response software 'where appropriate' are entity-specific — draft placeholders pending compliance-expert definition.
Last verified against primary law 23 Jul 2026
NIS2-IMPL-7 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §7
Effectiveness assessment of cybersecurity risk-management measures
Establish, implement and apply a policy and procedures to assess whether the entity's cybersecurity risk-management measures are effectively implemented and maintained — taking into account the §2.1 risk assessment results and past significant incidents. The policy and procedures determine which measures (including processes and controls) are monitored and measured, the methods for monitoring, measurement, analysis and evaluation to ensure valid results, when monitoring/measuring is performed, who is responsible for it, when results are analysed and evaluated, and who does that analysis. Reviewed and, where appropriate, updated at planned intervals and when significant incidents or significant operational/risk changes occur.
Applicable now
NIS2-IMPL-7 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §7
Effectiveness assessment of cybersecurity risk-management measures
Establish, implement and apply a policy and procedures to assess whether the entity's cybersecurity risk-management measures are effectively implemented and maintained — taking into account the §2.1 risk assessment results and past significant incidents. The policy and procedures determine which measures (including processes and controls) are monitored and measured, the methods for monitoring, measurement, analysis and evaluation to ensure valid results, when monitoring/measuring is performed, who is responsible for it, when results are analysed and evaluated, and who does that analysis. Reviewed and, where appropriate, updated at planned intervals and when significant incidents or significant operational/risk changes occur.
- Applies to
- Digital infrastructure/service entities in Art 3 scope (DNS providers, TLD registries, cloud/data-centre/CDN providers, MSPs/MSSPs, online marketplaces, search engines, social platforms, trust services)
- Severity if failed
- Medium
- Applies from
- 6 Nov 2024
- Source
- NIS2-implementing-2024-2690.txt:6756-6932
How this is verified
A documented policy and procedures exist to assess the effectiveness of cybersecurity risk-management measures, informed by the risk assessment and past incidents, specifying what is monitored/measured, the methods, timing, and responsible/evaluating parties per §7.2(a)-(f); reviewed at planned intervals or after significant incidents/changes
The monitoring/measurement cadence and specific methods are entity-defined — draft placeholders pending compliance-expert input.
Last verified against primary law 23 Jul 2026
NIS2-IMPL-8.1 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §8.1
Awareness raising and basic cyber hygiene practices
Ensure employees (including members of management bodies) and, where appropriate per §5.1.4, direct suppliers and service providers are aware of risks, informed of the importance of cybersecurity, and apply cyber hygiene practices — via an awareness-raising programme that is scheduled over time to repeat and reach new employees, established in line with the network-and-information-system security policy, topic-specific policies and procedures, and covers relevant cyber threats, the cybersecurity risk-management measures in place, contact points and resources for further advice, and cyber hygiene practices for users. Where appropriate, the programme's effectiveness is tested; it is updated and offered at planned intervals accounting for changes in cyber hygiene practices, the threat landscape and entity-specific risk.
Applicable now
NIS2-IMPL-8.1 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §8.1
Awareness raising and basic cyber hygiene practices
Ensure employees (including members of management bodies) and, where appropriate per §5.1.4, direct suppliers and service providers are aware of risks, informed of the importance of cybersecurity, and apply cyber hygiene practices — via an awareness-raising programme that is scheduled over time to repeat and reach new employees, established in line with the network-and-information-system security policy, topic-specific policies and procedures, and covers relevant cyber threats, the cybersecurity risk-management measures in place, contact points and resources for further advice, and cyber hygiene practices for users. Where appropriate, the programme's effectiveness is tested; it is updated and offered at planned intervals accounting for changes in cyber hygiene practices, the threat landscape and entity-specific risk.
- Applies to
- Digital infrastructure/service entities in Art 3 scope (DNS providers, TLD registries, cloud/data-centre/CDN providers, MSPs/MSSPs, online marketplaces, search engines, social platforms, trust services)
- Severity if failed
- Medium
- Applies from
- 6 Nov 2024
- Source
- NIS2-implementing-2024-2690.txt:6936-7055
How this is verified
An awareness-raising programme exists covering employees/management and suppliers where appropriate, is scheduled to repeat and reach new employees, aligns with the entity's N&IS policies, and covers the §8.1.2(a)-(c) content; effectiveness is tested where appropriate and the programme is updated at planned intervals
Programme cadence and 'where appropriate' effectiveness-testing triggers are entity-specific — draft placeholders pending compliance-expert definition.
Last verified against primary law 23 Jul 2026
NIS2-IMPL-8.2 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §8.2
Security training for security-relevant roles
Identify employees whose roles require security-relevant skills and expertise, and ensure they receive regular network-and-information-system security training, via a training programme established in line with the N&IS security policy, topic-specific policies and procedures that lays down role-based training needs by criteria. Training must be relevant to the employee's job function, have its effectiveness assessed, account for security measures in place, and cover secure configuration/operation instructions (including mobile devices), known cyber threat briefings, and behaviour during security-relevant events. Training is applied when staff transfer into security-relevant roles, and the programme is updated and run periodically accounting for applicable policies/rules, assigned roles and responsibilities, known threats and technological developments.
Applicable now
NIS2-IMPL-8.2 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §8.2
Security training for security-relevant roles
Identify employees whose roles require security-relevant skills and expertise, and ensure they receive regular network-and-information-system security training, via a training programme established in line with the N&IS security policy, topic-specific policies and procedures that lays down role-based training needs by criteria. Training must be relevant to the employee's job function, have its effectiveness assessed, account for security measures in place, and cover secure configuration/operation instructions (including mobile devices), known cyber threat briefings, and behaviour during security-relevant events. Training is applied when staff transfer into security-relevant roles, and the programme is updated and run periodically accounting for applicable policies/rules, assigned roles and responsibilities, known threats and technological developments.
- Applies to
- Digital infrastructure/service entities in Art 3 scope (DNS providers, TLD registries, cloud/data-centre/CDN providers, MSPs/MSSPs, online marketplaces, search engines, social platforms, trust services)
- Severity if failed
- Medium
- Applies from
- 6 Nov 2024
- Source
- NIS2-implementing-2024-2690.txt:7056-7215
How this is verified
Security-relevant roles are identified with a role-based training programme aligned to N&IS policy, training covers the §8.2.3(a)-(c) content with assessed effectiveness, role-transfer training is applied, and the programme is updated periodically
Training frequency ('regular'/'periodically') and role-identification criteria are entity-specific — draft placeholders pending compliance-expert definition.
Last verified against primary law 23 Jul 2026
NIS2-IMPL-9 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §9
Cryptography policy and key management
Establish, implement and apply a policy and procedures on cryptography to ensure adequate and effective use of cryptography protecting the confidentiality, authenticity and integrity of data, in line with asset classification and the §2.1 risk assessment. The policy and procedures establish, per asset classification: the type, strength and quality of cryptographic measures required for data at rest and in transit; the protocols/algorithms, cipher strength, cryptographic solutions and usage practices to approve and require, following a cryptographic agility approach where appropriate; and the entity's key-management approach, covering (where appropriate) key generation, certificate issuance/obtaining, key distribution/activation, key storage/access, key change/update, compromised-key handling, key revocation, lost/corrupted key recovery, key backup/archiving, key destruction, logging/auditing of key-management activity, and key activation/deactivation date-setting. Reviewed and, where appropriate, updated at planned intervals accounting for the state of the art in cryptography.
Applicable now
NIS2-IMPL-9 · Commission Implementing Regulation (EU) 2024/2690 — NIS2 Art 21(2) technical requirements, Annex §9
Cryptography policy and key management
Establish, implement and apply a policy and procedures on cryptography to ensure adequate and effective use of cryptography protecting the confidentiality, authenticity and integrity of data, in line with asset classification and the §2.1 risk assessment. The policy and procedures establish, per asset classification: the type, strength and quality of cryptographic measures required for data at rest and in transit; the protocols/algorithms, cipher strength, cryptographic solutions and usage practices to approve and require, following a cryptographic agility approach where appropriate; and the entity's key-management approach, covering (where appropriate) key generation, certificate issuance/obtaining, key distribution/activation, key storage/access, key change/update, compromised-key handling, key revocation, lost/corrupted key recovery, key backup/archiving, key destruction, logging/auditing of key-management activity, and key activation/deactivation date-setting. Reviewed and, where appropriate, updated at planned intervals accounting for the state of the art in cryptography.
- Applies to
- Digital infrastructure/service entities in Art 3 scope (DNS providers, TLD registries, cloud/data-centre/CDN providers, MSPs/MSSPs, online marketplaces, search engines, social platforms, trust services)
- Severity if failed
- High
- Applies from
- 6 Nov 2024
- Source
- NIS2-implementing-2024-2690.txt:7216-7563
How this is verified
A cryptography policy and procedures exist specifying required cryptographic strength/protocols by asset classification and a key-management approach covering the applicable §9.2(c)(i)-(xii) lifecycle stages, and are reviewed at planned intervals accounting for the state of the art
Which specific algorithms/key-lifecycle methods are 'appropriate' is entity/risk-specific — draft placeholder pending compliance-expert definition.
Last verified against primary law 23 Jul 2026
Obligations marked “Draft” are illustrative decompositions awaiting review by a compliance expert — shown as drafts, not presented as a finished, audited library.
Incident notification commitments
The reporting clocks below are tracked from the moment of detection for every applicable regime.
4h
Fastest clock — DORA major-incident classification
24h
Early warning — NIS2 & CRA
72h
Standard notification — all four regimes
| Regime | Deadline | Window |
|---|---|---|
NIS2 | Early warning Article 23 | 24h from awareness |
| Notification Article 23 | 72h, updates on request | |
| Final report Article 23 | 1 month after notification | |
DORA | Initial notification Article 19 + Delegated Reg. (EU) 2025/301 | 4h from classification as major, ≤24h from awarenessThe tightest clock in EU law — defined in the delegated regulation, not DORA itself. |
| Intermediate report Article 19 + Delegated Reg. (EU) 2025/301 | 72h after initial notification | |
| Final report Article 19 + Delegated Reg. (EU) 2025/301 | 1 month after intermediate report | |
CRA | Early warning Article 14 (applicable from 11 Sep 2026) | 24h |
| Notification Article 14 (applicable from 11 Sep 2026) | 72h | |
| Vulnerability report Article 14 (applicable from 11 Sep 2026) | 14 days after a fix is available | |
| Severe incident report Article 14 (applicable from 11 Sep 2026) | 1 monthRelevant once DMS manufactures products with digital elements — Art 14 applies from 11 Sep 2026, ahead of the rest of the CRA. | |
GDPR | Processor → controller Article 33(2) | Without undue delay |
| Controller → supervisory authority Article 33(1) | 72h | |
| Data subjects Article 34 | Without undue delayOnly where the breach is likely to result in a high risk to individuals' rights and freedoms. |
This page is a customer-facing notice channel. It does not replace the statutory reporting duty to the competent authority, CSIRT or supervisory authority under NIS2, DORA, CRA or GDPR.
Onboarding in progress. DMS has not yet connected a live evidence source. Once a connector (Microsoft 365, Google Workspace, Okta, etc.) is live, this page will show real, timestamped control status here — not before.
Security overview
Data residency
Customer data is intended to be hosted within the EU, addressing the CLOUD Act concerns EU buyers raise about US-hosted platforms.
Access control
Access control, asset management and HR security (NIS2 Art 21(2)(i)) plus MFA for privileged and remote access (Art 21(2)(j)) — see the obligation library above for the exact text.
Incident response
Cyber and AI incidents are tracked from detection through notification and remediation, against the statutory clocks above.
Subprocessors
A current subprocessor list with change notification (satisfying GDPR Article 28) is planned for this section — not yet published.
Certifications & audit reports
No third-party certifications on file yet. This section only ever shows a certificate once one is uploaded and its expiry/scope parsed — never a placeholder claim.
Frequently asked questions
Where does this content come from?
Directly from the official EU legal texts (EUR-Lex) — the AI Act, NIS2, DORA, GDPR and the Cyber Resilience Act. Every obligation cites its regulation, article and source line.
Why does NIS2 matter to us as your supplier?
NIS2 Article 21(2)(d) requires essential and important entities to assess the security of their direct suppliers. If your organisation is in scope for NIS2, this page is how we help satisfy that duty — pointing to a specific control and its citation, instead of a security questionnaire filled in from memory.
Is the EU AI Act still relevant if high-risk rules were delayed?
Yes. The Digital Omnibus moved stand-alone high-risk obligations to 2 December 2027, but Article 4 (AI literacy) has applied since 2 February 2025 and general-purpose AI obligations since 2 August 2025 — neither was delayed.
What's the difference between a Directive and a Regulation here?
NIS2 is a Directive — it takes legal effect through each EU member state's national transposition, which can be stricter than the base text. GDPR, DORA, the AI Act and the CRA are Regulations, which apply directly and identically across the EU.
How is evidence confidence scored?
Evidence is ranked on a 7-step reliability ladder by source, from API (99%), Direct database read (95%), System log evidence (90%), Digitally signed document / certificate (98%), AI-extracted from unstructured source (85%), Extracted from uploaded PDF (55%), Manual declaration (40%). Every evidence record carries its own confidence score rather than a single blanket rating.
What happens when a regulation changes?
Amendments almost always move dates, not duties. We update the applies-from date, legal status and pending-change note on the affected obligation, rather than rewriting the library — so you can always see what's binding now versus what's still pending adoption.
What does 'Draft — pending expert review' mean?
It means the obligation was decomposed from the primary legal text but hasn't yet been validated by a compliance expert for pass-rule thresholds and edge cases. We show that status rather than hide it.
Who can see the restricted and NDA-gated sections?
Restricted content requires a verified business email. NDA-gated content requires a signed NDA. Both are separate tiers below.
Does this replace statutory incident reporting?
No. This page is a customer-facing notice channel, not the statutory channel (competent authority / CSIRT / supervisory authority) required under NIS2, DORA, CRA or GDPR.