DORA Mapping: From Requirements to Audit-Ready Evidence

Not an explicit obligation, but decisive once an audit starts: here is how DORA mapping ties the regulation to the processes, contracts and evidence your organisation already has.

Contents

1. What is DORA mapping?
2. Why you need it
3. Is DORA mapping mandatory?
4. Processes, controls and responsibilities
5. Third-party risk management
6. DORA mapping: ISO 27001 and NIS2

Key takeaways: DORA mapping

• DORA mapping links the requirements of Regulation (EU) 2022/2554 to the processes, controls and contracts a financial entity in the EU already has in place
• Nowhere in the regulation is a mapping explicitly required, yet registers, contracts and audits make it hard to work without one
• Third-party risk management rests on two things: one central register of information and a CIF classification for every ICT provider
• ISO 27001 and NIS2 cover a good part of the ground, with gaps around reporting deadlines, mandatory contract terms and penetration testing
• SoSafe’s Human Risk Management Dashboard supplies the role-based awareness evidence that Article 13(6) calls for

Thinking beyond DORA: metrics and compliance in view

From a maturity assessment to audit preparation, these topics help IT and security teams place the mapping in a wider compliance picture and plan what comes next.

Read more

Glossary

DORA Compliance: Requirements, Checklist, and Human Risk

Read more

Glossary

DORA

What is DORA mapping?

DORA mapping is the structured allocation of the requirements set out in the Digital Operational Resilience Act (Regulation (EU) 2022/2554) to the processes, controls, contracts and responsibilities that actually exist inside a financial entity. Rather than working through the articles one at a time, a good mapping connects each requirement to the place where the organisation already lives up to it, or where it does not.

Three layers come together here: which of the five DORA pillars an area falls under (ICT risk management, incident reporting, resilience testing, ICT third-party risk, information sharing); which existing process or control already covers the requirement; and what would demonstrate that in an audit, whether a document, a log or a contract clause. It is that final layer that distinguishes a mapping from a checklist. A checklist confirms that an action is being carried out. A mapping shows what you can produce to prove it.

DORA has applied directly in every EU member state since 17 January 2025. For most affected institutions, mapping is therefore not a one-off project but a standing task. New providers, changed processes and updated regulatory technical standards (RTS) from the European Supervisory Authorities all shift the picture again.

Why you need DORA mapping in practice

Without a mapping, DORA compliance appears as a loose set of separate measures. Each measure makes sense on its own, but once an audit begins, the thread connecting them is often missing. A structured mapping pays off in concrete ways.

Auditors rarely ask whether you meet DORA in general. What you will face are specific questions: how do you evidence requirement X in process Y through control Z? A mapping hands over that chain from requirement to evidence, instead of leaving you to improvise it in the room.

Gaps can also be identified more reliably. Only by placing the requirement next to the actual process does it become clear when something is missing, whether that is a contract clause required by Article 30 that is absent from an existing provider agreement, or an escalation chain that still fails to reflect the tighter deadlines set by the regulation.

Most regulated organisations are already meeting large parts of DORA through frameworks such as ISO 27001 or NIS2, without that overlap being written down anywhere. Mapping puts it on paper and spares you doing the same work twice.

For security teams with limited capacity, that is where the practical value sits. Meeting the requirement costs what it always did. Evidencing it in an audit costs considerably less once the chain exists on paper.

The legal position: is DORA mapping mandatory?

No, not explicitly. Nowhere does DORA require you to produce a “mapping”. What the regulation does make binding:

• a continuously updated register of information covering all contracts with ICT third-party providers (Art. 28(3)), which supervisory authorities can request when needed,
• prior due diligence before a contract is signed, covering substitutability, insolvency risk, data protection and subcontracting chains among other things (Art. 28(4)),
• minimum contractual provisions under Article 30 for contracts supporting “critical or important functions”,
• ongoing monitoring of provider relationships (Art. 28(6)).

These duties are difficult to meet in practice without some structured allocation of requirement to process, control and evidence, not least because supervisory reviews tend to follow exactly that chain, from how current the register is to whether the mandatory Article 30 clauses appear in the contracts. DORA mapping is therefore hard to avoid in practice, even though it is never named as a duty in its own right. Relying on “we meet the individual requirements” without documenting and allocating them makes proving it considerably harder.

Processes, controls and responsibilities

The internal translation of a DORA requirement into a concrete process that already exists or still needs to be created, with clear ownership, is the most effective part of any mapping. If you skip that step, the mapping remains a spreadsheet without operational value.

In practice, four columns are enough: requirement, function, control and evidence. The incident management process shows what those lines look like.

Each of the five DORA areas can be built out the same way. No row should be without a named owner, whether that is a person or a role. Leave it out and the boundary between IT, compliance and risk management blurs, which is where audit findings on governance tend to come from.

One element is repeatedly underestimated in mapping: the human factor. Article 13(6) puts role-based, documented awareness and training on the mandatory side for staff and management alike. It is not a voluntary extra, and it earns a line of its own in the mapping, with evidence attached like any other. Putting that in front of an auditor takes more than an attendance rate. It takes role-specific content and proof that the knowledge holds. SoSafe’s Human Risk Management Dashboard closes exactly that gap, with role-based learning content and audit-ready records, so the row can be filled with reliable data rather than a statement of intent.

Third-party risk management in DORA mapping

DORA leaves little room for interpretation here: you can outsource the service, but not the resilience or the risk that comes with it. Where a critical function depends on an external ICT provider, accountability stays with the entity that falls under DORA. A provider’s own compliance documentation, however thorough, is not a substitute for yours.

Three things follow from that in practice:

1. Keep one central register: The register does not distinguish between a global cloud platform and a niche SaaS tool. Both go into the same single, current register of information under Art. 28(3), with provider identity, the service delivered, contract data and the subcontracting chain behind it.
2. Classify by criticality: Whether a provider supports a critical or important function (CIF) governs almost everything that follows. Article 30 applies its full set of mandatory clauses, from audit rights to exit strategies and data portability, only to that group.
3. Check contracts for mandatory clauses: Existing agreements have to be read against what Article 30 prescribes. With older framework contracts, that reading often turns into a renegotiation of its own.

A number of larger ICT providers now publish their own DORA documentation, among them GoTo, GitLab and SAP. Worth keeping in mind what that material is: input from the provider, not your own mapping. Documents like these help with contract review and with due diligence towards that one supplier. They replace neither your cross-provider register of information nor the internal criticality classification, which only the financial entity itself can carry out, is replaced by them.

DORA mapping: ISO 27001 and NIS2

Few organisations begin their DORA mapping entirely from scratch. Anyone already certified to ISO 27001, or who has implemented NIS2 requirements, covers a substantial share of DORA already. Making those overlaps visible saves duplicated work, and it is often exactly what auditors ask to see.

A simplified view of where the DORA areas touch ISO 27001 and NIS2:

DORA and ISO 27001

ICT risk management is where mapping DORA to ISO 27001 pays off most, since the Annex A controls already cover much of Articles 5 to 15. Where it stops is with the parts of DORA that ISO 27001 never had reason to address: the tight, staggered deadlines that follow an incident, and threat-led penetration testing (TLPT) at significant institutions. An existing certification is therefore a strong starting point, but it does not replace DORA-specific evidence.

DORA and NIS2

With DORA and NIS2, supply chain security and risk management measures again show the greatest overlap. The challenge differs from the ISO 27001 case: NIS2 is a directive, transposed differently from one country to the next, while DORA applies directly and uniformly as a regulation. For financial entities that also fall within the scope of NIS2, one further rule applies: as the sector-specific regulation, DORA takes precedence in case of doubt. Documenting that explicitly in the mapping avoids duplicated effort and contradictory processes.

This guide is intended as an initial orientation and does not constitute legal advice. Legal sources: Regulation (EU) 2022/2554 (DORA), ISO/IEC 27001:2022, Directive (EU) 2022/2555 (NIS2). Last updated: September 2026