DORA vs NIST CSF

DORA applies by law to 20 types of financial entity listed in Article 2(1), points (a) to (t), running from credit institutions and payment institutions to insurers, crypto-asset service providers and securitisation repositories. Point (u) extends the Regulation to ICT third-party service providers. Compliance is supervised by the national competent authority for each entity type under Article 46, and the ECB supervises credit institutions classified as significant. Critical ICT third-party providers fall under direct oversight by the ESAs as Lead Overseers. Before you map anything, confirm your exact entity type in Article 2(1) and your supervisor with your national competent authority, because the answer determines which obligations and deadlines you carry.

The NIST CSF applies by choice. NIST is not a regulator, and most organizations adopt the CSF voluntarily, sometimes because a customer or supplier requires it. The one mandatory case is the 2017 executive order that made it binding for U.S. federal agencies. A European bank or insurer using the CSF therefore holds no CSF obligation to a supervisor. Its CSF program still counts for DORA only if the evidence shows the DORA requirements are met, so the question for your compliance lead is which regulatory obligations the CSF work actually covers, not whether the CSF is "compliant."

DORA also links to NIS2. Article 1(2) makes DORA a sector-specific Union act for the purposes of Article 4 of the NIS2 Directive, for financial entities identified as essential or important entities under NIS2. Check with your competent authority whether your entity is in that group, since it affects which rules apply on top of DORA. Regulation (EU) 2022/2554 on EUR-Lex is the primary text to confirm entity scope against.

A mature CSF program does not, by itself, satisfy DORA. Three obligations must be built regardless of how far the Govern, Identify, Protect, Detect, Respond and Recover functions have matured, because they are legal duties with supervisory enforcement rather than outcomes you choose to pursue. The first is major ICT-related incident reporting. Under Article 5 of Delegated Regulation (EU) 2025/301, the initial notification is due within 4 hours of classifying the incident as major and no later than 24 hours after you became aware of it. The intermediate report follows within 72 hours of the initial notification, and the final report is due no later than one month after the latest intermediate report. CSF Respond and Recover subcategories describe good incident handling, but they set no clocks, recipients or report contents. Confirm that your incident classification criteria can be applied inside the 4-hour window, since that window opens at classification, not at detection.

The second addition is the register of information under Article 28(3). It must cover all contractual arrangements for ICT services at entity, sub-consolidated and consolidated levels, be reported yearly for new arrangements, be provided to the authority on request, and be notified to the authority in advance for planned arrangements supporting critical or important functions. CSF Govern and Identify categories on supply chain risk help you know your suppliers, but they do not produce a structured register that a supervisor can read. Ask whether your procurement and contract records can produce that dataset on request, and who owns each field.

The third is threat-led penetration testing under Chapter IV, which the CSF does not require or define. Where your entity is identified for TLPT, the test must be run against live production functions by qualified testers, and the authority may issue an attestation under Article 26(7) that the test met the requirements. This attestation is the only authority-issued attestation DORA provides for, and it is not a certificate. Treat CSF Detect and Protect testing outcomes as inputs, not as a substitute. Check with your competent authority whether your entity is in scope and what evidence it expects before scheduling any exercise.

Start by sorting existing CSF work into what carries over and what has to be rebuilt. Asset inventories, risk assessments, Govern policies, supplier tiering and recovery plans usually carry over with changes in scope and wording, because DORA's ICT risk management and third-party chapters ask for the same underlying facts. Ask each owner to tag every artifact with the DORA article it could support, and to record what is missing. The rebuilt items are the ones CSF never defined in regulatory terms: the incident classification and clocks that DORA's incident rules set out, the fields the register of information must hold for each contractual arrangement, and the scope of any threat-led penetration test. Treat those as new deliverables with their own owners, not as relabeled CSF Subcategories.

The CSF 2.0 Reference Tool export lists 363 Implementation Examples and informative references, including mappings to SP 800-53 Rev. 5.2.0, ISO/IEC 27001:2022, CIS Controls v8.1 and PCI DSS. These mappings are useful for finding candidate evidence, but NIST does not check the correctness of non-NIST mappings, and listing a mapping does not imply endorsement. Before a reviewer relies on any row that points toward DORA, they should open the cited DORA article, confirm the requirement actually says what the mapping claims, and record that check in the file. Where a mapping is wrong or thin, the gap belongs on the remediation list. The CRI Profile can help as a second cross-reference, but its own DORA mappings still need the same reviewer check. Confirm with your supervisor which evidence format and version of each mapping they will accept.