CSSF Incident Handling Guidance: NIS2 Rulebooks and the DORA Clock

On 28 September 2026 the CSSF published press release 26/19 announcing operational guidance for incident handling: nine rulebooks written jointly by cybersecurity experts from the High Commission for National Protection (HCPN, acting as ANSSI and as GOVCERT.LU), CIRCL, the CSSF and the ILR. The practical question for Luxembourg DORA entities is whether the CSSF incident handling guidance moves their reporting. On the text of the release and the rulebooks, the filing stays where it was. The rulebooks were written in the context of Article 14(5) of the Luxembourg NIS2 Act, and their disclaimer says they do not address legal obligations such as notifying incidents to the CSSF, the ILR or the CNPD.

What the rulebooks do change is the first hour. Rulebook 0 tells a responding team to “tick mandatory regulatory reporting clocks immediately (NIS2, DORA, sectoral rules as applicable)”, which puts the DORA classification decision inside a playbook written by the national authorities. For DORA financial entities in scope of Circular CSSF 25/893, the reporting duty itself still sits in Article 19 of Regulation (EU) 2022/2554 (DORA), in Commission Delegated Regulation (EU) 2025/301 and in the CSSF eDesk procedure.

The gap worth managing is between the two scopes. The rulebooks cover malicious cyber-attacks only, while DORA’s incident definition also captures unplanned failures. The NIS2 clocks run 24 and 72 hours from awareness. DORA’s initial notification is due as early as possible and within four hours from classification as major and no later than 24 hours from awareness; however, where classification as major occurs later than 24 hours after awareness, the notification is due within four hours from classification.

Related reading: DORA ICT Incident Reporting: How to Classify, Escalate, and Report Major Incidents

The dates that frame the 28 September release

The rulebooks land on top of a Luxembourg incident framework that was reworked in May 2025 and again in May 2026. These are the operative dates:

• 27 May 2025: Circular CSSF 25/893 is dated (the CSSF published it on 28 May 2025). It sets the practical modalities for DORA major ICT-related incident notifications and makes Circular CSSF 24/847 no longer applicable to the firms in its scope, with a six-month transition for POST Luxembourg.
• 25 July 2025: the CSSF reminds supervised entities that an incident being publicly known or reported in the press does not exempt them from reporting it.
• 5 May 2026: the Law on measures to ensure a high level of cybersecurity (the NIS2 Act) is adopted. It is published in Memorial A No 225 on 6 May 2026.
• 10 May 2026: the NIS2 Act enters into force, according to the ILR.
• 27 August 2026: Circular CSSF 26/915 amends Circular 25/893 so that it also covers third-country branches in Luxembourg.
• 28 September 2026: CSSF press release 26/19. The rulebooks are published as version 1.0 (stable), classified TLP:CLEAR.

The rulebooks carry no application date and no transition period, because they impose nothing. Their GitHub README says regular reviews every six months set the release cycle, with urgent updates possible outside that cycle. Any internal procedure that cites a rulebook therefore needs to record which version it cites.

Inside the CSSF incident handling guidance: nine rulebooks

The document lists six authors: ANSSI, the CSSF, CIRCL, GOVCERT, the HCPN and the ILR. It is hosted on GitHub under the Creative Commons Attribution 4.0 licence, and outside contributions arrive as pull requests or issues that the maintainers review against published criteria including relevance to NIS2 incident handling, usefulness, technical accuracy, clarity, vendor independence, compatibility with existing guidance and maintainability. The CSSF files the publication on its website as “CSSF guidance”, with a 160 KB PDF. It has none of the apparatus of a circular: no addressee list, no numbered points, no application chapter.

The set contains:

• Rulebook 0: Triage and Routing
• Rulebook 1: Denial of Service (DoS) and Distributed Denial of Service (DDoS)
• Rulebook 2: Malware
• Rulebook 3: Exploitation of communication channels to gain access
• Rulebook 4: Credential theft and account compromise
• Rulebook 5: Vulnerability exploitation
• Rulebook 6: Insider threat
• Rulebook 7: Data exfiltration
• Rulebook 8: Package compromission and supply chain attack

Rulebooks 1 to 8 share one chronological structure: typical initial detection, immediate response (containment), investigation steps, remediation, evidence keeping, post-incident activity, communication and key watchpoints. Rulebook 0 is the entry point. It assigns roles, opens a case log with chain of custody, and routes the incident through a table of indicators of compromise to one or more of the other eight.

Rulebook 0 is candid about its limits. It sets out the four-phase incident management cycle (preparation; detection and analysis; containment, eradication and recovery; post-incident activity) and says the set covers only parts of that cycle. Preparation, the phase where a firm’s DORA incident management process is designed, is largely left to the entity. The glossary at the end is labelled as generated with artificial intelligence tools, a disclosure worth knowing before anyone quotes a definition from it in a policy.

Some content goes beyond pure technique. Rulebook 2 states that entities should not pay a ransom because payment does not guarantee recovery and may breach sanctions law. Rulebook 3 recommends monitoring affected accounts for at least 72 hours after a phishing compromise, a figure that has nothing to do with the NIS2 72-hour notification despite the matching number.

Article 14(5) of the NIS2 Act and the 24-hour response

The legal hook is narrow. Article 14 of the NIS2 Act requires essential and important entities to notify significant incidents to their competent authority. Article 14(3) sets the NIS2 Act’s general test for a significant incident. For entity types covered by Commission Implementing Regulation (EU) 2024/2690, including cloud computing, data-centre, managed-service and managed-security-service providers, that test must also be read with the directly applicable EU criteria that further specify when an incident is significant. Article 14(4) then sets the sequence:

• an early warning without undue delay and within 24 hours of becoming aware of the significant incident, indicating where relevant whether unlawful or malicious acts are suspected or cross-border impact is possible;
• an incident notification within 72 hours of becoming aware, updating the early warning and giving an initial assessment of severity and impact, with indicators of compromise where available;
• an intermediate report at the request of a CSIRT or the competent authority;
• a final report no later than one month after the incident notification, or a progress report at that point if the incident is still ongoing, followed by a final report within one month of handling the incident.

Article 14(5) is where the rulebooks come from. The competent authority must answer the notifying entity without undue delay and, where possible, within 24 hours of receiving the early warning, with initial feedback and, at the entity’s request, guidance or operational advice on possible mitigation measures. That guidance is issued by the competent authority in cooperation with the CSIRT concerned, and the CSIRT gives additional technical support if the entity asks. Where criminal activity is suspected, the CSIRT or the authority also gives guidance on reporting to law enforcement.

The press release describes the rulebooks as the translation of that Article 14(5) guidance into ready-to-use material. Which CSIRT stands behind it depends on the entity. Under Article 7(1), GOVCERT.LU is the CSIRT for state administrations and services, public establishments and critical entities designated under the separate Law of 5 May 2026 on the resilience of critical entities. CIRCL is the CSIRT for all other cases, which covers private financial firms unless they are designated critical entities.

Opening Rulebook 0, or asking the CSSF for Article 14(5) guidance, sits outside the Article 14(4) deadline sequence: the request for guidance follows the early warning under Article 14(5), and the rulebooks’ own disclaimer excludes the legal notification duties from their scope.

Which CSSF-supervised firms meet the NIS2 Act directly

Article 3 of the NIS2 Act makes the ILR the default competent authority. By derogation, the CSSF is the competent authority for the banking sector and the financial market infrastructure sector, points 3 and 4 of Annex I. It is also competent for the digital infrastructure and ICT service management sectors, points 8 and 9 of Annex I, for activities that fall under CSSF supervision.

The Annex I rows are tight. Banking means credit institutions within the meaning of Article 4(1), point (1), of Regulation (EU) No 575/2013. Financial market infrastructure means operators of trading venues and central counterparties. Annex II, the “other critical sectors” list, contains no financial sector row at all. Size also filters: Article 1(1) applies the law to entities that are at least medium-sized under Commission Recommendation 2003/361/EC, with size-independent exceptions in Article 1(2).

A payment institution, an e-money institution or a UCITS management company does not appear as such in the banking or financial market infrastructure rows. Investment firms likewise do not appear as a standalone category, but an investment firm that operates an MTF or OTF may fall within the financial market infrastructure row as an operator of a trading venue. Subject also to any other NIS2 sectoral activity carried on by the entity, firms outside those Annex I categories rely on the applicable DORA and Circular 25/893 incident-reporting framework. Treating the 28 September release as a new NIS2 reporting layer for them would be a scoping error. For fund managers, our DORA compliance checklist for Luxembourg fund administrators sets out the DORA incident obligations that do apply.

The CSSF-supervised population most directly exposed to Article 14 is a different one: firms that are not DORA financial entities but provide managed ICT services, managed security services, cloud computing or data centre services. Support PFS do not appear in the Circular 25/893 scope list. A Luxembourg support PFS that qualifies as a managed service provider or managed security service provider and falls within the NIS2 Act’s scope may therefore be subject directly to the NIS2 incident-reporting framework, with the CSSF as competent authority where the relevant activity falls under CSSF supervision. For such providers, the Article 14 notification sequence must be read together with Commission Implementing Regulation (EU) 2024/2690, which further specifies when an incident is significant for managed service providers and managed security service providers.

One further boundary sits in Article 1(5): the NIS2 Act does not apply to entities that a Member State has excluded from DORA’s scope under Article 2(4) of Regulation (EU) 2022/2554.

Lex specialis: how Article 1(8) keeps DORA in the reporting seat

For credit institutions, trading venue operators and central counterparties, two regimes could in principle apply. Article 1(8) of the NIS2 Act resolves the overlap. Where a sector-specific Union act requires essential or important entities to adopt cybersecurity risk-management measures or to notify significant incidents, and those requirements are at least equivalent in effect to the NIS2 Act, the relevant provisions of the NIS2 Act, including supervision and enforcement under Chapter 6, do not apply to those entities.

The incident limb of the equivalence test has two parts: the sectoral act must give the CSIRTs, competent authorities or single points of contact under the NIS2 Act immediate access (automatic and direct, where appropriate) to the incident notifications, and its notification requirements must be at least equivalent to Article 14(1) to (6).

DORA is built to pass both parts. Article 19(6)(c) of DORA requires the competent authority, on receipt of each DORA notification and report, to pass details of the major ICT-related incident in a timely manner to the competent authorities, single points of contact or CSIRTs under Directive (EU) 2022/2555. Recital 1 of Delegated Regulation (EU) 2025/301 says the DORA reporting time limits should, to the greatest extent possible, follow a consistent approach with, and at least be equivalent in effect to, the NIS2 Directive requirements. My reading is that a Luxembourg credit institution reports a major ICT-related incident under DORA to the CSSF, and Article 14 of the NIS2 Act does not add a second filing for the same event. That is an interpretation of Article 1(8), and it is consistent with recital 16 of DORA, which states that the Regulation constitutes lex specialis with regard to Directive (EU) 2022/2555; neither the press release nor Circular 25/893 states the no-second-filing conclusion in those words.

Two carve-outs keep the reading honest. Article 1(8) disapplies only the “relevant provisions”, leaving credit institutions subject to the rest of the NIS2 Act. And its second sentence keeps the NIS2 Act in force for any entities of a sector that the sectoral act does not cover.

DORA itself leaves Member States an option. The last subparagraph of Article 19(1) lets them require some or all financial entities to send the initial notification and each report also to the NIS2 competent authorities or CSIRTs. Circular 25/893 names only two channels, the eDesk procedure and the CSSF API interface, plus an e-mail fallback for technical impossibility. It contains no instruction to copy CIRCL.

The DORA filing the rulebooks leave untouched

Circular 25/893, as amended by Circular 26/915, applies to three groups: the DORA financial entities the CSSF supervises, POST Luxembourg as a payment service provider outside DORA, and third-country branches whose head office would qualify under Article 2(1) of DORA. Luxembourg branches of entities headquartered elsewhere in the EU are excluded: point 4 sends their DORA reports to the home Member State authority. For the branch angle, see our note on CSSF Circular 26/915 and third-country branches.

The mechanics are fixed in Chapter 3 of the circular:

• Notifications go through the eDesk procedure “DORA Major ICT-related Incident Notification” or through the CSSF API interface (S3).
• If a technical impossibility blocks that channel, the entity informs the CSSF at ictrisksupervision@cssf.lu without undue delay, within the applicable time limit, and explains why it used the alternative channel.
• One form carries all three stages: initial notification, intermediate report and final report, with the data fields of Annexes II and IV of Commission Implementing Regulation (EU) 2025/302.
• The CSSF permits no aggregated reporting of major ICT-related incidents under Article 7 of that Implementing Regulation.
• A firm that outsources its reporting must tell the CSSF before the first notification, giving the third party’s name, contact details and identification code and the persons who will hold the notification role.

The clocks come from Article 5 of Delegated Regulation (EU) 2025/301. The initial notification is due as early as possible and within four hours of classifying the incident as major, and no later than 24 hours after the entity became aware of it. If classification as major happens only after those 24 hours, the four hours run from classification. The intermediate report is due within 72 hours of the initial notification, even where nothing has changed, with an updated intermediate report once regular activities are recovered. The final report is due within one month of the latest intermediate report.

Set against Article 14(4) of the NIS2 Act, the triggers differ at every stage. The NIS2 early warning and notification count from awareness. DORA’s initial notification counts from classification, with an awareness cap, and its intermediate report counts from the initial notification. A single “72 hours from detection” line in an incident runbook matches the NIS2 notification at best and misstates DORA’s intermediate report, which runs from the initial notification. Our guide to the ESAs’ filing instructions for DORA major incident reports covers the field-level rules.

Malicious attacks only: where the rulebooks and DORA classification diverge

Rulebook 0 limits the set to malicious cyber-attacks and states that human errors and system failures are out of scope. DORA’s reporting perimeter is wider. The definition of an ICT-related incident, as derived from DORA in point 5 of Circular 25/893, is a single event or a series of linked events unplanned by the financial entity that compromises the security of network and information systems and has an adverse impact on the availability, authenticity, integrity or confidentiality of data, or on the services the entity provides. A failed change or a hardware fault that takes down a critical service meets that definition without any attacker involved.

The routing table in Rulebook 0 also answers a different question from DORA classification. It decides which playbook to open. Whether the incident is major is decided under Commission Delegated Regulation (EU) 2024/1772 against the criteria in Article 18(1) of DORA, which the ESAs summarised at their public hearing as clients, financial counterparts and transactions affected (with reputational impact), data losses, duration and service downtime, criticality of the services affected, geographical spread and economic impact. A phishing campaign handled under Rulebook 3 may never reach the major threshold. An outage that no rulebook covers may reach it within hours.

Two more duties run alongside and outside the rulebooks. Rulebook 7 tells teams to coordinate with the data protection officer if personal data was exfiltrated, with a pointer to the GDPR; the notification to the CNPD is a separate obligation that the rulebooks’ disclaimer expressly leaves out. And the CSSF’s July 2025 reminder applies with full force: press coverage of an incident does not remove the duty to report it.

Feeding rulebook outputs into the DORA report fields

The most useful reading of the rulebooks for a DORA reporting team is as a data-capture discipline. Several of their steps produce exactly what Delegated Regulation (EU) 2025/301 asks for, if the case log is set up to keep it.

• Rulebook 0’s case log records who, what, when and how for every artefact, with a SHA-256 hash and read-only originals. That log is the natural source for the date and time of detection and classification and for how the incident was discovered, both required in the initial notification under Article 2 of the Delegated Regulation.
• Rulebook 0 suggests engaging the business continuity lead immediately when a crisis is declared. The initial notification asks whether a business continuity plan has been activated.
• The investigation and evidence-keeping steps in Rulebooks 1 to 8 generate indicators of compromise and descriptions of attacker techniques. The intermediate report asks, where applicable, for the threats and techniques used by the threat actor and for indicators of compromise, together with affected functional areas and infrastructure components.
• Post-incident activity feeds the final report, which asks for root causes, resolution details, direct and indirect costs and losses with any financial recoveries, and recurring incidents.

Rulebook 0 also asks for the communication and reporting function to be segregated from the teams resolving the incident. For a DORA entity, that is where the four-hour clock owner belongs: someone who is not in the war room restoring systems while the classification decision is being made.

One practical trap concerns channels. Rulebook 0 warns that the entity’s own infrastructure may be compromised and that out-of-band communication and storage may be necessary. Circular 25/893 accepts the e-mail fallback only where a technical impossibility prevents submission through the designated channel, and only with the reasons stated. A compromised mail domain is itself a reason to decide in advance which out-of-band route will carry that fallback message.

Legacy references worth cleaning out of incident procedures

The NIS2 Act also retired part of the old framework, and incident policies written before 2026 may still cite it.

• Article 30 of the NIS2 Act repeals the Law of 28 May 2019 that transposed the first NIS Directive. CSSF Regulation No 24-01 of 5 January 2024 relates to incident notification under that 2019 law, so any procedure relying on it needs to be checked against the CSSF’s current position.
• Point 13 of Circular 25/893 makes Circular CSSF 24/847 and Circular CSSF 21/787 no longer applicable to entities listed under points 1(a) to (j) and (l). For the PSPs listed under point 1(k), point 14 provides a six-month transition during which both earlier circulars remain applicable; point 15 provides for the formal repeal of Circular CSSF 21/787 six months after publication. The CSSF’s July 2025 reminder still refers to Circular 24/847 “and/or” Circular 25/893, which is consistent with 24/847 staying relevant for supervised entities outside the 25/893 scope; the CSSF page for Circular 24/847 lists support PFS and specialised PFS among the entities it is relevant for.
• “Law of 5 May 2026” is ambiguous in Luxembourg. The NIS2 Act appears in Memorial A No 225. The law of the same date transposing CRD VI appears in Memorial A No 227. A third law of that date covers the resilience of critical entities. Article 32 of the NIS2 Act fixes its citation form, which names the law as the one on measures to ensure a high level of cybersecurity.

Frequently Asked Questions

We are the Luxembourg branch of a bank headquartered in another EU Member State. Does anything here change our reporting?

Point 4 of Circular 25/893 excludes EU branches, which report major ICT-related incidents and significant cyber threats under DORA to their home Member State authority. The rulebooks remain usable as operational material for the branch’s incident team, but the filing follows the head office’s authority and channel.

Can our incident response policy simply adopt the rulebooks as our procedure?

The disclaimer says the rulebooks must not be used as a substitute for any policies or procedures in force at the entity. DORA requires financial entities to establish and implement their own ICT-related incident management process to detect, manage and notify incidents. The rulebooks can inform that process, without serving as a replacement for it.

An incident happens on a Saturday. Can we wait until Monday to file the initial notification?

Article 5(4) of Delegated Regulation (EU) 2025/301 allows submission by noon of the next working day when a deadline falls on a weekend or bank holiday. Article 5(5) removes that relief for initial notifications and intermediate reports by credit institutions, central counterparties, trading venue operators and other financial entities identified as essential or important entities under NIS2. Article 5(6) lets the competent authority extend the exclusion to other significant or systemic entities by a decision notified to them individually; Circular 25/893 announces no such general decision. On 15 January 2025 the CSSF said it had identified the financial entities concerned by Article 5(5) and would notify them; on 28 February 2025 it postponed that notification until the NIS2 Directive was transposed at national level, and the NIS2 Act transposing it entered into force on 10 May 2026.

We know we will miss the four-hour deadline. What does the regulation require?

Article 5(3) of Delegated Regulation (EU) 2025/301 requires the entity to inform the competent authority without undue delay, and no later than the time limit itself, and to explain the reasons for the delay. That is a separate step from the technical-impossibility fallback in point 9 of Circular 25/893, which covers a blocked channel rather than a late report.

An external incident response firm is running our investigation. Can it file the DORA notification for us?

Article 19(5) of DORA allows the reporting obligation to be outsourced, with the financial entity remaining fully responsible. Circular 25/893 point 12 requires the CSSF to be told before the first notification, with the third party’s identification details and the named persons who will hold the notification role in the CSSF system. Arranging that during a live incident is late.

Does the CSSF give DORA reporters anything comparable to Article 14(5) guidance?

DORA has its own feedback provision. Under Article 22(1), the competent authority acknowledges receipt of each notification and report and may provide proportionate feedback or high-level guidance, including anonymised intelligence on similar threats. The ESAs’ 2025 feasibility report stresses that this does not shift responsibility: financial entities remain fully responsible for handling ICT-related incidents and their consequences.

Related Articles

• DORA ICT Incident Reporting: How to Classify, Escalate, and Report Major Incidents: the classification framework and the three-stage reporting sequence for major ICT-related incidents.
• DORA Major Incident Reporting: The ESAs’ Filing Instructions: field-by-field guidance on completing the DORA incident templates.
• CSSF Circular 26/915: DORA Circulars Re-Mapped for Third-Country Branches: how the August 2026 circular brought third-country branches under the CSSF’s DORA circulars.
• DORA ICT Incident Reporting: What the ESAs First Annual Report Reveals: what the first year of EU-wide major incident data shows.
• DORA Compliance Checklist for Luxembourg Fund Administrators: a Luxembourg-specific checklist covering incident reporting alongside ICT risk, testing and third-party oversight.

Key Takeaways

• Log which rulebook version your procedures cite: version 1.0 is dated 28 September 2026 and the maintainers review the set every six months.
• Decide, per legal entity, whether the NIS2 Act reaches you at all: in the financial sector only credit institutions, trading venue operators and central counterparties sit in Annex I, while CSSF-supervised managed ICT and cloud providers may enter through points 8 and 9.
• Keep one DORA clock owner outside the resolution team, with authority to escalate the classification decision promptly and to file through eDesk or the S3 interface within the applicable Article 5 reporting deadline.
• Add a classification checkpoint for non-malicious outages, which Rulebook 0 routes nowhere but DORA can treat as major.
• File the outsourcing notice with ictrisksupervision@cssf.lu before any third party submits a DORA notification on your behalf.
• Replace references to the Law of 28 May 2019 and, for entities in the 25/893 scope, to Circulars 24/847 and 21/787 in incident policies.

Sources and References

• CSSF, press release 26/19, Operational guidance for incident handling (28 September 2026): cssf.lu
• ANSSI, CSSF, CIRCL, GOVCERT, HCPN, ILR, Operational Guidance For Incident Handling, version 1.0 (28 September 2026): PDF
• NIS2 rulebooks repository and README: github.com/nis2-rulebooks
• Law of 5 May 2026 on measures to ensure a high level of cybersecurity, Memorial A No 225 of 6 May 2026: Legilux
• ILR, entry into force of the Law of 5 May 2026 (NIS2): ilr.lu
• Directive (EU) 2022/2555 (NIS2 Directive): EUR-Lex
• Regulation (EU) 2022/2554 (DORA): EUR-Lex
• Commission Delegated Regulation (EU) 2025/301 on the content and time limits of major ICT-related incident reports: EUR-Lex
• Commission Implementing Regulation (EU) 2025/302 on standard forms, templates and procedures for incident reporting: EUR-Lex
• Commission Delegated Regulation (EU) 2024/1772 on the classification of ICT-related incidents and cyber threats: EUR-Lex
• Commission Implementing Regulation (EU) 2024/2690 of 17 October 2024 laying down rules for the application of Directive (EU) 2022/2555 as regards technical and methodological requirements of cybersecurity risk-management measures and further specification of the cases in which an incident is considered to be significant with regard to DNS service providers, TLD name registries, cloud computing service providers, data centre service providers, content delivery network providers, managed service providers, managed security service providers, providers of online market places, of online search engines and of social networking services platforms, and trust service providers: EUR-Lex
• Directive 2014/65/EU (MiFID II), Article 4(1), points (22) to (24): definitions of multilateral trading facility, organised trading facility and trading venue, and Article 18 on investment firms and market operators operating an MTF or OTF: EUR-Lex
• Circular CSSF 25/893 as amended by Circular CSSF 26/915: cssf.lu and PDF
• Circular CSSF 26/915 (27 August 2026): cssf.lu
• Circular CSSF 24/847 on the ICT-related incident reporting framework and related documents: cssf.lu
• CSSF, Reminder regarding ICT-related incident reporting requirements (25 July 2025): cssf.lu
• CSSF, Entry into application of DORA regulation on 17 January 2025 (15 January 2025): cssf.lu
• CSSF, DORA: postponement of notification to financial entities of their obligation to report a major incident on weekends or bank holidays (28 February 2025): cssf.lu
• CSSF, Publication of the Law of 5 May 2026 transposing CRD VI and Directive (EU) 2024/2994: cssf.lu
• ESAs, JC 2024 108, Report on the feasibility of further centralisation of reporting of major ICT-related incidents (January 2025): PDF
• ESAs, DORA public hearing slides (23 January 2024): PDF

Putting the rulebooks beside Circular 25/893

For a Luxembourg DORA entity the 28 September release adds material and leaves the reporting line where it was. The major ICT-related incident still goes to the CSSF through eDesk or the S3 interface, on the four-hour, 72-hour and one-month clocks of Delegated Regulation (EU) 2025/301. The rulebooks earn a place in the runbook as the containment and evidence layer that sits under those clocks.

The artefact to produce now is a one-page crosswalk: each rulebook stage mapped to the DORA report field it feeds, a separate route for non-malicious outages, and a decision recorded per legal entity on whether Annex I point 8 or 9 of the NIS2 Act brings any group company under Article 14 with the CSSF as its competent authority.

Disclaimer: The information on RegReportingDesk.com is for educational and informational purposes only. It does not constitute legal, regulatory, tax, or compliance advice. Always consult your compliance officer, legal counsel, or the relevant supervisory authority for guidance specific to your institution.