Last updated: 2026-11-06
This page applies to both frameworks: to financial entities under the full framework of Articles 5 to 15 DORA and to entities under the simplified framework of Article 16, including, from 1 January 2027, the institutions under Section 1a(2a) of the German Banking Act (KWG) (here: KWG group) such as factoring and leasing firms. It is aimed at firms that already run an information security management system (ISMS) under ISO/IEC 27001:2022, certified or not. How to implement an ISMS and have it certified is described by Blackfort Technology on its company page on ISO 27001 consulting. For entities under NIS2, the counterpart is NIS2 and ISO 27001.
How do ISO 27001 and DORA relate to each other?
DORA is law, ISO/IEC 27001 a voluntary standard. DORA does not refer to the standard but leaves the door open: under the full framework, the security policies take into account leading practices and, where applicable, standards (Delegated Regulation (EU) 2024/1774 Article 2(2)(h), “RTS” below), and for documentation financial entities may use any documents they already have (RTS recital 2). An ISMS is therefore a good starting point. The differences lie less in the protective measures than in scope and binding force:
| Topic | ISMS under ISO/IEC 27001 | DORA |
|---|---|---|
| Scope | set by the organisation itself, for example one site or one platform | in our assessment the ICT risk of the entire financial entity |
| Measures | Annex A as a reference list, selection and exclusions justified in the statement of applicability | binding requirements, under the full framework partly with set intervals such as weekly scans (RTS Article 10(2)) |
| Risk | risk criteria and acceptance set by the organisation | risk tolerance level for ICT risk, under the full framework set by the management body (Article 5(2)(d), Article 6(8)(b)) |
| External effect | certificate from a certification body, if desired | incident reports, register and review reports to BaFin, supervision by BaFin |
A certificate does not replace any DORA obligation. There is no certification for DORA itself. How DORA is audited is shown on our page DORA audit.
Mapping of clauses 4 to 10
The clauses describe the management system. They cover the cycle of planning, implementation, review and improvement that DORA also requires for the ICT risk management framework. The labels are our own short versions, the coverage is our assessment.
| Clause | DORA full framework | Article 16 framework | Coverage | What DORA additionally requires |
|---|---|---|---|---|
| 4 Context and scope | Article 6(1), Article 8 | Article 16(1)(a), RTS Article 30 | partly | in our assessment a framework for the entire firm, starting from critical or important functions and their dependencies |
| 5 Leadership | Article 5(2) and (4) | RTS Article 28(1) and (2) | partly | ultimate responsibility, approval of strategy, policies, plans and budget, training of the members of the management body (full framework), approval of classification, BIA and business continuity plans (Article 16) |
| 6 Planning | Article 6(8), RTS Article 3 | RTS Article 31 | largely | tolerance level, under the full framework the DOR strategy and an inventory of residual risks (RTS Article 3(d)) |
| 7 Support | Article 5(2)(g), Article 13(6), Article 14 | Article 16(1)(h), RTS Article 28(2)(e) | largely | training for senior management too, under the full framework communication plans for incidents |
| 8 Operation | Articles 9 to 12, RTS Title II | RTS Articles 32 to 39 | largely | specific individual requirements from the RTS, see Annex A below |
| 9 Performance evaluation | Article 6(5) to (7), RTS Article 27 | Article 16(2), RTS Article 28(5) and (6), Article 41 | partly | internal audit with ICT expertise, follow-up of critical findings, review report with prescribed content |
| 10 Improvement | Article 13 | Article 16(1)(h) and (2) | largely | post-incident reviews of major incidents, under the full framework an annual report to the management body (Article 13(5)) |
Mapping of Annex A
Annex A of the 2022 edition has 93 controls in four themes: organisational (5.1 to 5.37), people (6.1 to 6.8), physical (7.1 to 7.14) and technological (8.1 to 8.34). The table groups them by topic. “Largely” means a control that is implemented effectively provides most of the evidence. “Partly” means DORA requires considerably more. “Low” means the standard touches on the topic, but the DORA obligation is a different one.
| Annex A | Topic | DORA full framework | Article 16 framework | Coverage | What DORA additionally requires |
|---|---|---|---|---|---|
| 5.1, 5.4 | policies, management responsibilities | Article 9(4)(a), RTS Article 2 | RTS Article 29 | largely | date of approval by the management body, alignment with the DOR strategy, register of documentation (RTS Article 2(2)(a), (b), (f)) |
| 5.2, 5.3 | roles, segregation of duties | Article 5(2)(c), Article 6(4), RTS Article 2(2)(g) | RTS Article 28(2)(b) and (4) | partly | ICT risk control function with an appropriate level of independence (full framework), segregation of control functions and internal audit (both) |
| 5.5, 5.6 | contact with authorities and special interest groups | Article 19, Article 45 | Article 19, Article 45 | low | reporting of major incidents in three stages with deadlines, notification of participation in information-sharing arrangements (Article 45(3)) |
| 5.7 | threat intelligence | Article 13(1) | RTS Article 31(3), Article 34(h) | largely | link to critical or important functions |
| 5.9 to 5.13 | inventory, classification | Article 8, RTS Articles 4, 5 | RTS Article 30 | partly | classification along critical or important functions with dependencies, including at service providers |
| 5.15 to 5.18, 8.2, 8.3, 8.5 | access, identities, privileged rights, authentication | Article 9(4)(c), (d), RTS Articles 20, 21 | RTS Article 33 | largely | need-to-use, privileged access only when needed and logged, strong authentication, under the full framework recertification at least every six months for systems supporting critical or important functions (RTS Article 21(e)(iv)) |
| 5.19 to 5.23 | suppliers, supply chain, cloud | Articles 28 to 30 | Articles 28 to 30 without Article 28(2), not for microenterprises of the KWG group | partly | register of information, minimum contractual content under Article 30, concentration risk (Article 29), exit strategies (Article 28(8)), under the full framework a strategy on ICT third-party risk (Article 28(2)) |
| 5.24 to 5.28, 6.8 | incident management | Articles 17 to 19, RTS Articles 22, 23 | Articles 17 to 19, RTS Article 31(4), Article 34(g) | partly | classification under Delegated Regulation (EU) 2024/1772 and reporting to BaFin |
| 5.29, 5.30, 8.14 | security during disruption, ICT readiness, redundancy | Article 11, Article 12(4), RTS Articles 24 to 26 | RTS Articles 39, 40 | partly | business impact analysis, recovery objectives per function, scenarios, yearly tests, under the full framework a crisis management function |
| 8.13 | backup | Article 12(1) to (3), (7) | RTS Article 39(2)(g) | largely | minimum frequency based on criticality, under the full framework restoration on segregated systems and data reconciliation |
| 5.31, 5.35, 5.36 | legal requirements, independent review, compliance | Article 6(5) to (7), RTS Article 27 | Article 16(2), RTS Article 28(5), (6), Article 41 | partly | internal audit following an audit plan, review report in a searchable electronic format |
| 6.1 to 6.6 | people before, during and after employment | RTS Article 19 | no explicit requirement | largely | requirements also for staff of ICT third-party service providers who use the entity’s assets (RTS Article 19(b)) |
| 6.3 | awareness and training | Article 5(4), Article 13(6) | Article 16(1)(h) | partly | training for staff and senior management, under the full framework regular training of the members of the management body |
| 6.7, 8.1 | remote working, endpoint devices | RTS Article 11(2)(f), (j) | RTS Article 35(b), (g) | largely | remote wiping of company data on mobile devices (full framework) |
| 7.1 to 7.14 | physical security | RTS Article 18 | RTS Article 32 | largely | alignment with the classification of assets |
| 8.6, 8.9, 8.19 | capacity, configuration, software installation | Article 7, RTS Articles 9, 11 | RTS Article 34(c), Article 35(b) | largely | secure configuration baseline with regular review (full framework) |
| 8.7, 8.8 | malware, vulnerabilities | RTS Article 10, Article 11(2)(d) | RTS Article 34(d), (i) | partly | automated vulnerability scanning, under the full framework at least weekly for assets supporting critical or important functions, deadlines and escalation for patches, vulnerability notifications from service providers |
| 8.10 to 8.12 | deletion, masking, data leakage prevention | RTS Article 11(2)(g) to (i), Article 16(5) | RTS Article 34(i), Article 35(e), (f) | largely | under the full framework anonymised, pseudonymised or randomised test data |
| 8.15 to 8.17 | logging, monitoring, clock synchronisation | Article 10, RTS Articles 12, 23 | RTS Article 33, Article 34(f), (g) | largely | set retention periods, alert thresholds for responding to incidents |
| 8.20 to 8.23, 5.14 | networks, information transfer | RTS Articles 13, 14 | RTS Article 35(c), (d) | largely | - |
| 8.24 | cryptography | Article 9(4)(d), RTS Articles 6, 7 | RTS Article 35(a) | partly | protection of data in use as well, under the full framework key management over the whole lifecycle and a register of all certificates for assets supporting critical or important functions (RTS Article 7(4)) |
| 8.25 to 8.31, 8.33 | secure development, security testing, test data | RTS Article 16 | RTS Article 37 | partly | under the full framework source code review with static and dynamic testing, also for code from third parties and open source projects (RTS Article 16(3) and (8)) |
| 8.32, 5.8 | changes, projects | RTS Articles 15, 17 | RTS Article 38 | largely | changes are recorded, tested, assessed, approved, implemented and verified (RTS Article 38(2), in more detail under the full framework RTS Article 17) |
What an ISMS does not deliver
Some DORA obligations have no counterpart in the standard. They are added to the ISMS:
| Obligation | Reference | Framework | More detail |
|---|---|---|---|
| Register of information on all contractual arrangements for ICT services | Article 28(3), Implementing Regulation (EU) 2024/2956 | both, not for microenterprises of the KWG group | Register of information |
| Classification and reporting of major ICT-related incidents to BaFin | Articles 18, 19 | both | DORA incident reporting |
| Minimum contractual content, exit strategies, concentration risk | Article 28(8), Articles 29, 30 | both, not for microenterprises of the KWG group | Managing ICT third-party service providers |
| Testing programme, and TLPT for certain entities | Articles 24 to 27 | full framework, testing programme under the Article 16 framework in our reading (see DORA Article 16) | DORA resilience testing |
| Obligations and training of the management body | Article 5(2) and (4), RTS Article 28(2) | both, Article 5(4) only under the full framework | ICT risk management |
| DOR strategy and ICT risk control function | Article 6(4) and (8) | full framework | ICT risk management |
| Business impact analysis and recovery objectives per function | Article 11(5), Article 12(6), RTS Article 39(2)(d) | both | ICT business continuity |
Example: ISMS comparison for a payment institution
Fictitious example, not a client. Muster-Zahlungsdienste GmbH is the payment institution from the example on our page ZAIT and DORA (ZAIT: BaFin’s supervisory requirements for IT in payment and e-money institutions): 14 employees, card payments for online retailers, full framework. Its ISMS has been certified under ISO/IEC 27001 for years, with a scope covering development and operation of the merchant portal and the connection to the payment platform, which a processor provides as a cloud service. Customer service, accounting and regulatory reporting are outside the scope. The comparison against DORA found:
| Area | Finding | DORA reference | Measure |
|---|---|---|---|
| Scope | Regulatory reporting is a critical or important function but lies outside the ISMS. | Article 6(1), Article 8 | extend the framework to the whole institution, review the scope of the certificate at the next recertification |
| Statement of applicability | Control 8.11 (masking) excluded, tests run with production data. | RTS Article 16(5) | anonymise test data or govern exceptions with an approval |
| Suppliers | Contracts with the processor and the fraud detection provider follow the firm’s own ISMS template, without audit rights for the supervisor and without exit support. | Article 30(2) and (3), Article 28(8) | contract annex under Article 30, exit plans for both providers |
| Vulnerabilities | Monthly scans. | RTS Article 10(2) | weekly scans for assets supporting critical or important functions |
| Management body | Management review once a year by the information security officer, which the managing directors take note of. | Article 5(2) and (4) | approval of the policies and the ICT business continuity policy by the managing directors, training plan for them |
Most findings concerned scope, contracts, intervals and responsibility, less the protective measures themselves.
Three typical gaps
| Gap | Cause | Effect | Remedy |
|---|---|---|---|
| Certificate scope too narrow | The ISMS was certified to meet a customer requirement, for example only for the platform or the data centre. | Functions outside the scope, often regulatory reporting or business units, are missing from risk assessment, tests and evidence. | Lay the critical or important functions over the scope and extend the framework to the entire firm. The certificate may remain narrower. |
| Statement of applicability excludes what DORA requires | Controls were excluded to save effort, for example masking, secure coding or security testing in development. | There is no evidence at all for the excluded topics, although the RTS expressly requires them under the full framework. | Check each exclusion against DORA and the RTS and add a column with the DORA reference to the statement of applicability. |
| Management review treated as the review report | The annual ISMS report is offered to the supervisor as the review of the framework. | Content and format under RTS Article 27 or Article 41 are missing, such as date of approval, trigger, period, responsible function or person and remediation measures with dates. | Build the report following the structure of the RTS and use the management review as a source. |
How we help
The DORA gap analysis sets your ISMS against DORA and the RTS, using your statement of applicability as the starting point, and for institutions under the simplified framework as an Article 16 gap analysis. Institutions of the KWG group moving from BAIT (BaFin’s supervisory requirements for IT in banks) on 1 January 2027 transfer existing ISMS documents into the structure of the RTS in the transition from BAIT to Article 16.
Frequently asked questions
Does DORA require ISO 27001 certification?+
No. DORA requires an ICT risk management framework with defined content, but no certificate under a standard. The security policies are to take into account leading practices and, where applicable, standards (RTS (EU) 2024/1774 Article 2(2)(h)). Whether you use ISO/IEC 27001 for this and have it certified is your decision.
May we reuse existing ISMS documents for DORA?+
Yes. Under recital 2 of RTS (EU) 2024/1774, financial entities may use any documentation they already have to meet the documentation requirements. What matters is that every requirement of the RTS can be found in the documents, for example through a mapping list like the table above, and that the documents show approval by the management body where DORA requires it.
Is our IT service provider’s ISO certificate enough?+
It is a good indication but does not replace your own obligations. You may only use providers that comply with appropriate information security standards, and for critical or important functions you take into account the most up-to-date and highest quality standards (Article 28(5) DORA). Check the scope and date of the certificate. The contractual content under Article 30 and your responsibility under Article 28(1)(a) remain regardless.
Does the mapping also work for IT-Grundschutz?+
The method does: map modules or requirements to the references in DORA and the RTS, assess coverage, add what is missing. This page contains no mapping of the IT-Grundschutz modules (the BSI’s baseline protection methodology) to DORA. How a security concept under IT-Grundschutz is created is shown on the page Security concept under IT-Grundschutz (in German).
Read more
- DORA requirements: obligations matrix for the full framework and Article 16
- ICT risk management under DORA: framework and DOR strategy
- DORA Article 16: the simplified ICT risk management framework
- DORA register of information: structure, mandatory fields, submission
- DORA incident reporting: classifying and reporting ICT-related incidents
- DORA resilience testing: testing programme, pentests and TLPT
Sources
- Regulation (EU) 2022/2554 (DORA), Articles 5, 6, 8 to 14, 16 to 19, 24 to 30, 45, German version (retrieved 2026-11-06)
- Delegated Regulation (EU) 2024/1774 (RTS on ICT risk management), recitals 2 and 6, Titles II and III, German version (retrieved 2026-11-06)
- BSI: mapping of ISO/IEC 27001:2022 Annex A to GS++ (control numbers of Annex A), Stand-der-Technik-Bibliothek (retrieved 2026-11-06)
This content provides general technical and organisational information and does not constitute legal advice (no legal services within the meaning of the German RDG).