NIS2 binds Member States and the companies inside them, but it does not reach the EU's own institutions, bodies, offices and agencies, so the Union wrote a separate law for itself: Regulation (EU, Euratom) 2023/2841. Adopted on 13 December 2023 and in force since 7 January 2024, it requires every Union entity to run a cybersecurity framework, assess its maturity, apply a defined set of measures, approve a cybersecurity plan and report significant incidents to CERT-EU on fixed clocks. It also turns CERT-EU into a permanent body with a legal mandate and creates the Interinstitutional Cybersecurity Board (IICB) to oversee compliance. This guide is for security teams inside Union entities and for the cloud, software and managed service suppliers who support them and will see the obligations flow into contracts. It goes deeper than the EU row in our Central Government Cybersecurity Programme Guide and the Global Cybersecurity Regulatory Map.
Key takeaways
- Every core deadline has now passed. The framework was due by 8 April 2025, the first maturity assessment by 8 July 2025, the Article 8 measures by 8 September 2025 and the cybersecurity plan by 8 January 2026, so 2026 is the first year of steady-state compliance.
- Top management is accountable. Article 6 makes the highest level of management of each Union entity responsible for the framework; it can delegate tasks but not the liability.
- Incident clocks mirror NIS2. Article 21 requires an early warning to CERT-EU within 24 hours of becoming aware of a significant incident, a notification within 72 hours and a final report no later than one month after the notification.
- Identity controls are written into law. Article 8(3) names multifactor authentication as the norm, steps towards zero trust, cryptography and software supply chain security among the specific measures each entity must take.
- Suppliers are pulled in through procurement. Article 8(3)(k) requires procurement rules that remove barriers to sharing incident information with CERT-EU.
Scope: who the Regulation covers
Article 2 applies the Regulation to all Union entities, to the IICB and to CERT-EU. Article 3(1) defines Union entities as the institutions, bodies, offices and agencies set up by or under the Treaty on European Union, the Treaty on the Functioning of the European Union or the Euratom Treaty. That reaches the large institutions (the Parliament, the Council, the Commission) and the decentralised agencies alike.
| Question | Answer from the Regulation | Article |
|---|---|---|
| Which systems are covered? | The entire unclassified ICT environment: on-premises systems, operational technology networks, outsourced assets and services in cloud or hosted by third parties, mobile devices, corporate and business networks and connected devices | 6(2) |
| What is excluded? | Network and information systems handling EU classified information (EUCI), except for CERT-EU assistance on explicit request | 2(3), 13(8) |
| Does it override institutional autonomy? | No: it applies without prejudice to the institutional autonomy each entity has under the Treaties | 2(2) |
| Which data protection law applies to incident data? | Regulation (EU) 2018/1725, the GDPR equivalent for Union institutions | 4 |
| Are private suppliers directly bound? | No. They are reached through contracts and procurement rules (Article 8(3)(k)) and, where they are essential or important entities, through national NIS2 law | 8(3)(k) |
The obligation timeline
The Regulation sets staged deadlines counted from entry into force. Each date below is taken from the operative articles on EUR-Lex.
| Date | Obligation | Who | Article |
|---|---|---|---|
| 7 January 2024 | Entry into force | All | 26 |
| 8 July 2024 | Guidelines on incident reporting | IICB | 21(9) |
| 8 September 2024 | Guidelines on implementing Articles 6 to 9 | IICB, after consulting ENISA | 5(1) |
| 8 January 2025 | First annual IICB report to Parliament and Council; guidelines on significant incident response | IICB | 10(14), 22, 25 |
| 8 April 2025 | Internal risk management, governance and control framework in place, after an initial review such as an audit | Each Union entity | 6(1) |
| 8 July 2025 | First cybersecurity maturity assessment, then at least every two years | Each Union entity | 7(1) |
| 8 September 2025 | Cybersecurity risk-management measures in place | Each Union entity | 8(1) |
| 8 January 2026 | Cybersecurity plan approved by top management, then revised every two years | Each Union entity | 9(1) |
| 8 January 2027 | First Commission report to Parliament and Council, then every two years | Commission | 25 |
| 8 January 2029 | Commission evaluation of the Regulation | Commission | 25 |
Article 12(5) lets the IICB extend the Article 6(1) and Article 8(1) deadlines in justified cases, so an individual entity's date can differ from the table.
What each Union entity must build
The framework (Article 6)
- Content: cybersecurity policies, objectives and priorities, roles and responsibilities, and mechanisms to measure effectiveness, using an all-hazards approach.
- Review: regularly and at least every four years.
- Budget: an adequate percentage of the ICT budget for cybersecurity. Recital 14 gives an indicative longer-term target of at least 10 percent; treat this as guidance, not an operative rule.
- Local cybersecurity officer: each entity appoints one as its single point of contact, reporting to top management. CERT-EU keeps the list.
- Training: senior officials and relevant staff receive regular training.
Maturity assessments and plans (Articles 7 and 9)
The maturity assessment covers the whole ICT environment and may be supported by a specialised third party. Similar entities may cooperate on it. The cybersecurity plan must contain at least the Article 8 measures and a cyber crisis management plan for major incidents, and it is submitted to the IICB.
The Article 8 measures
Article 8(2) lists sixteen domains that the measures must address, and Article 8(3) adds eleven specific measures. The table groups them for planning.
| Group | Article 8(2) domains | Article 8(3) specific measures |
|---|---|---|
| Governance | (a) cybersecurity policy; (b) risk analysis and information system security policies; (f) cybersecurity organisation and roles | (h) training for top management; (i) regular staff training |
| Assurance | (d) audits, including penetration testing by a trusted private provider; (e) implementing audit recommendations | (j) interconnectivity risk analyses where relevant |
| Identity and access | (h) human resources security and access control | (b) steps towards zero trust; (c) multifactor authentication as the norm |
| Assets and cloud | (c) cloud computing policy objectives; (g) asset management and ICT inventory | (a) teleworking arrangements |
| Operations and communications | (i) operations security; (j) communications security | (d) cryptography and encryption, including end-to-end encryption and secure digital signing; (e) secured voice, video and text communications where appropriate; (f) proactive malware and spyware detection and removal |
| Development and supply chain | (k) acquisition, development and maintenance, including vulnerability handling and disclosure; (l) source code transparency where possible; (m) supply chain security | (g) software supply chain security; (k) procurement rules supporting incident information sharing with CERT-EU |
| Detection and resilience | (n) incident handling and cooperation with CERT-EU, including monitoring and logging; (o) business continuity, backup, disaster recovery and crisis management; (p) education, awareness and training | None additional |
Incident reporting to CERT-EU
Article 21(1) defines a significant incident as one that has caused or can cause severe operational disruption or financial loss to the Union entity, or that has affected or can affect other persons through considerable material or non-material damage. Article 3(8) separately defines a major incident: one whose disruption exceeds the response capacity of the entity and CERT-EU, or that has a significant impact on at least two Union entities.
| Report | Deadline | Contents and notes | Article |
|---|---|---|---|
| Early warning | Within 24 hours of becoming aware | First alert of a significant incident | 21(2)(a) |
| Incident notification | Within 72 hours of becoming aware | Includes an initial assessment | 21(2)(b) |
| Intermediate report | On CERT-EU request | Relevant status updates | 21(2)(c) |
| Final report | No later than one month after the incident notification | For an ongoing incident, a progress report at that point and a final report within one month of handling the incident | 21(2)(d), (e) |
| Member State notice | Within 24 hours of becoming aware | Relevant Member State counterparts are informed of the significant incident | 21(3) |
CERT-EU sends summary reports to the IICB, ENISA, EU INTCEN and the CSIRTs network every three months (Article 21(8)). Voluntary reporting of threats, near misses and vulnerabilities is also possible under Article 20 and creates no extra obligations. Article 17 limits disclosure of an affected entity's identity to cases where it consents, has already made the incident public, or the Head of CERT-EU decides disclosure would help prevent or mitigate incidents elsewhere after written notice. For the national NIS2 clocks that may run in parallel at suppliers, see the Cyber Incident Reporting Requirements Map.
Governance: the IICB and CERT-EU
- IICB composition: one representative each from fifteen named bodies, including the Parliament, the Council, the Commission, ENISA, the EDPS and the ECCC, plus three designated by the EU Agencies Network for agencies that run their own ICT. It meets at least three times a year and decides by simple majority (Article 10).
- IICB tasks: adopt a multiannual strategy, approve CERT-EU's work programme, service catalogue and key performance indicators, adopt guidelines and supply chain recommendations, and run the cyber crisis management plan (Articles 11 and 23).
- CERT-EU mission: contribute to the security of the unclassified ICT environment of all Union entities. Core tasks include baseline CSIRT services, coordination of major incidents, acting as coordinator for coordinated vulnerability disclosure, and non-intrusive scanning of publicly accessible systems on request (Article 13).
- Calls for action: CERT-EU can issue calls for action with urgent measures and a set timeframe, and entities report back how they applied them (Article 14).
CERT-EU reported in May 2025 that the IICB had published mandatory guidelines covering incident reporting, the framework, risk management, maturity assessment, cybersecurity plans and incident response, set up a Local Cybersecurity Officers network, and adopted a multiannual strategy to 2029.
Compliance escalation
Article 12 gives the IICB a graded set of tools: a reasoned opinion, compliance guidelines with a deadline, a warning, a reasoned notification if the warning is not addressed, a recommended or requested audit, informing the Court of Auditors, and a recommendation to temporarily suspend data flows to the entity. Article 12(4) covers requests for disciplinary action where persistent infringements stem from staff conduct. There are no fines: the pressure is reputational, operational and personal.
What suppliers to Union entities should expect
A cloud provider, software house or managed service provider does not fall under the Regulation, but Article 8(3)(k) and the supply chain domains mean its customer must contract for certain behaviours. Our reading of the measures (an NHI Mgmt Group view, not text from the Regulation) is that tenders and renewals will increasingly ask for:
- Incident reporting duties in the contract: notice to the Union entity fast enough that it can meet the 24 hour early warning, and no contractual barriers to sharing incident details with CERT-EU.
- Penetration testing and audit cooperation: Article 8(2)(d) names penetration testing by a trusted private provider, so expect test windows and access to findings.
- Vulnerability handling and disclosure: a published disclosure process that fits CERT-EU's coordinator role.
- Software supply chain evidence: component inventories and secure development practice, which overlap with the EU Cyber Resilience Act Guide for products with digital elements.
- Strong authentication for support access: MFA for supplier staff and controlled machine credentials for integrations, matching Article 8(3)(c).
Suppliers that are also essential or important entities under national NIS2 law will report to their own national authority as well; see the NIS2 Supply Chain Security Guide.
Where identity fits
Three of the Article 8(3) measures are identity controls: multifactor authentication as the norm, steps towards zero trust, and secure digital signing. Article 6(2) brings outsourced cloud services, mobile devices and connected devices into scope, which means service accounts, API keys, cloud workload identities and the integration accounts that suppliers use must sit inside the ICT inventory required by Article 8(2)(g). Human MFA does not cover these: machine credentials need their own ownership, rotation and monitoring. See the Zero Trust Identity Guide and the NHI Discovery Guide.
Implementation approach for a Union entity
- Confirm your dates: check with your local cybersecurity officer whether the IICB granted any Article 12(5) extension, and whether the cybersecurity plan was approved and submitted.
- Map the IICB guidelines to your controls: the guidelines are mandatory for implementation; build one control register that cites the Article 8 point and the guideline paragraph for each control.
- Close identity gaps first: MFA coverage for all human access, then inventory and ownership of non-human identities, because both are named measures and both feed incident scope.
- Rehearse the 24 hour clock: run a tabletop that starts from detection and ends with the early warning to CERT-EU and the Member State notice, then measure the elapsed time.
- Fix procurement: add incident reporting and CERT-EU information sharing clauses to standard contract templates and to renewals.
- Plan the next maturity cycle: the second assessment falls no later than two years after the first, and the plan revision follows the same two-year rhythm.
Measuring progress
- Article 8 coverage: percentage of the 27 Article 8(2) and 8(3) points with an owner, a control and evidence.
- MFA coverage: share of interactive accounts, including supplier accounts, enforced to MFA.
- Non-human identity ownership: share of service accounts and keys in the ICT inventory with a named owner.
- Reporting speed: median time from awareness to early warning in exercises and real incidents, against the 24 hour target.
- Call for action closure: percentage of CERT-EU calls for action closed within the set timeframe.
- Audit follow-through: open audit and penetration test findings past their due date, since Article 8(2)(e) requires implementing recommendations.
Common failure patterns
- Treating the plan as a document exercise: a plan approved by 8 January 2026 that does not trace to the maturity assessment will not survive IICB review.
- Leaving outsourced services out of scope: Article 6(2) explicitly includes cloud and third-party hosted assets.
- Contracts that block reporting: confidentiality clauses that stop the entity sharing supplier incident details with CERT-EU run against Article 8(3)(k).
- MFA for staff only: supplier support accounts and machine credentials left on passwords or long-lived keys.
- Confusing significant and major incidents: the reporting duty is triggered by significant incidents; major incidents add crisis coordination on top.
Framework mapping
| Regulation duty | NIST CSF 2.0 | Notes |
|---|---|---|
| Framework and legal requirements (Article 6) | GV.OC-03 | Legal and regulatory requirements understood and managed |
| Supply chain and procurement clauses (Article 8(2)(m), 8(3)(k)) | GV.SC-05 | Requirements integrated into supplier contracts |
| ICT inventory (Article 8(2)(g)) | ID.AM-01 | Extend to software, services and identities |
| MFA and access control (Article 8(3)(c), 8(2)(h)) | PR.AA-03 | Users, services and hardware authenticated |
| Incident reporting (Article 21) | RS.CO-02 | Internal and external stakeholders notified |
Practitioner checklist
- Confirm the framework, maturity assessment, measures and plan dates for your entity, including any IICB extension.
- Keep a control register citing each Article 8(2) and 8(3) point and the matching IICB guideline.
- Name the local cybersecurity officer and confirm the reporting line to top management.
- Test the 24 hour early warning, 72 hour notification and one month final report path to CERT-EU.
- Include the Member State counterpart notice in the incident runbook.
- Enforce MFA for all interactive accounts, including supplier support access.
- Inventory service accounts, keys and cloud workload identities with owners.
- Add incident reporting and CERT-EU sharing clauses to procurement templates.
- Track CERT-EU calls for action to closure.
- Schedule the next maturity assessment and plan revision on the two-year cycle.
Standards and references
- EUR-Lex: Regulation (EU, Euratom) 2023/2841 (full text)
- EUR-Lex: Regulation (EU, Euratom) 2023/2841 (document information)
- CERT-EU: First year in the bag, many more to come
- European Parliament Legislative Observatory: procedure 2022/0085(COD) summary
- NIST: Cybersecurity Framework 2.0
This guide summarises Regulation (EU, Euratom) 2023/2841 and is not legal advice. Related NHI Mgmt Group resources: Central Government Cybersecurity Programme Guide · NIS2 Directive Guide · Cyber Incident Reporting Requirements Map · Global Cybersecurity Regulatory Map