DORA: what your RSSI did not tell you.

Most financial entities did not start DORA from zero. They had an ISMS, a business continuity plan, an outsourcing policy, and a third-party inventory that was mostly procurement contracts. DORA does not throw that away. It re-frames it, raises the bar on two pillars in particular, and moves the conversation from "do you have a control" to "can you prove your service keeps running when an ICT provider fails." This page is about that gap: how the five pillars actually land in operations, what a supervisor opens first, and where teams lose time.

The five pillars, and who gets audited on each

The regulation is built on five pillars. They are not equally weighted in practice. Pillar 1 is foundational but familiar to anyone who runs an ISMS. Pillars 3 and 4 are where the supervisory attention concentrates, because they produce evidence that is hard to fake and easy to test. The table below is the version we use to brief a board: what each pillar requires, and who inside the entity ends up most exposed when the regulator asks for proof.

What to do first

The mistake is to start with the policy refresh, because that is the comfortable work. Start instead with the two artefacts a supervisor can ask for in writing and that take the longest to build correctly: the ICT third-party register and the mapping of critical or important functions to the ICT assets and providers that support them. Everything else hangs off that mapping. You cannot scope resilience testing, you cannot classify incident severity, and you cannot reason about concentration risk until you know which functions are critical and what they depend on.

A workable first-90-days sequence:

1. Define your critical or important functions. This is a business decision, not a security one. It drives the scope of almost every other obligation.
2. Map each critical function to the ICT services, internal and outsourced, that it relies on. This is your dependency graph.
3. Build the third-party register from that graph, not from the procurement spreadsheet. The register must describe arrangements that support functions, including subcontractors in the chain.
4. Close the contractual gaps DORA requires (audit rights, exit strategies, subcontracting transparency, incident cooperation) on the arrangements that support critical functions first.
5. Only then formalise the ICT risk-management framework and the testing programme, because both now have a defined scope to work against.

The ICT third-party register (Pillar 4) in practice

The register is not a vendor list. It is a structured set of registers of information that the entity maintains and that competent authorities collect, in a defined template, to see ICT concentration across the whole financial sector. That changes how you build it. A field that is "close enough" for internal use becomes a data-quality problem when it is aggregated at national and EU level. Three things cause most of the pain.

First, the unit is the contractual arrangement, not the supplier. One provider can sit behind several arrangements, and one arrangement can support several functions. You are describing a many-to-many graph, and flattening it into one row per vendor will not survive review.

Second, you have to follow the chain. The register must capture subcontractors that effectively support a critical or important function, which means your provider visibility has to reach past your direct counterparty. If your contract does not give you the right to know who the fourth party is, that is a contractual gap to close, not a field to leave blank.

Third, the function-criticality flag on each arrangement is the field everything else keys off. Mark too much as critical and you drown your own testing and contractual remediation; mark too little and you understate concentration risk and mislead the supervisor. Get the criticality assessment right once, at the function level, and let it propagate.

Threat-led penetration testing (Pillar 3): what the room actually looks like

TLPT is the pillar that surprises people, because it is unlike a routine penetration test. It is intelligence-led, run against live production systems, scoped to the critical or important functions, and conducted under the TIBER-EU methodology with the national authority involved. Significant entities run it on at least a three-year cycle. It is closer to a supervised red-team exercise than to a vulnerability scan, and the deliverable that matters is not the list of findings; it is the evidence that detection and response worked, or the honest account of why they did not.

Three realities teams underestimate:

• Scope is driven by critical functions, not by what is convenient to test. If a function spans an outsourced provider, that provider may have to be in scope, which means provider cooperation has to be contractually secured in advance.
• The blue team is generally not told. The value is in testing real detection and response, so a TLPT that the defenders were warned about has lost most of its point. That has organisational consequences you plan for, not discover mid-exercise.
• Testers and threat-intelligence providers must meet competence and independence requirements, and the authority reviews the process. You cannot simply re-badge last year is annual pentest as TLPT.

If your entity is below the significance threshold, you are not running TLPT, but you still owe a risk-based testing programme: vulnerability assessments, scenario-based testing, and resilience testing of the recovery path. The Lead Operational Resilience Manager course is built around exactly this regulator-facing testing-and-evidence layer, and the DORA Lead Manager course covers how the full programme is governed end to end.

DORA as lex specialis over NIS 2 for banks

Banks, and most other financial entities, fall in scope of both NIS 2 and DORA. The two overlap heavily on ICT risk, incident reporting, and supply-chain security, which raises the obvious fear of doing everything twice. DORA resolves this: on the ICT matters it governs, DORA is lex specialis. The specific rule displaces the general one. Where DORA sets the ICT risk-management and incident-reporting obligation, a financial entity follows DORA, and competent authorities should not apply the equivalent NIS 2 requirement on top of it for the same ICT topic.

What this does not mean: it does not switch NIS 2 off entirely for a financial entity, and it does not change who your competent authority is for non-ICT matters. The practical decision for a bank is to map each obligation to its governing instrument: ICT operational resilience, incident reporting, and third-party ICT risk run under DORA; anything outside DORA is scope you assess separately. Document that mapping. It is the answer to the "are you double-counting or under-counting" question that examiners and auditors both ask.

Common mistakes and where to build the competence

The recurring failures are not exotic. The register is built per vendor instead of per arrangement and breaks the moment subcontracting matters. Critical-function criticality is assessed by IT instead of by the business, so the scope of everything downstream is wrong. Incident classification thresholds are written but never tested against a real incident, so the first major event becomes the first rehearsal of the reporting timeline. And business continuity is treated as a separate ISO 22301 project rather than the recovery muscle that DORA testing is meant to exercise.

That last point matters: DORA does not replace a business continuity management system, it assumes one. The recovery objectives and the tested recovery path that a BCMS gives you are what resilience testing validates. Build the BCMS properly with the ISO 22301 Lead Implementer course, and it becomes the substrate the operational-resilience obligations stand on rather than a parallel binder no one opens.

If you are starting from the regulation itself, the DORA Foundation course gives the whole team a shared, accurate reading of the five pillars and the scope before anyone touches the register or the testing programme. From there the DORA Lead Manager course is the implementation and governance layer for the people who will own the framework, and the Lead Operational Resilience Manager course is for the function that has to stand in front of the supervisor and show that resilience is real, not documented.