Safeguard
Compliance•

DORA scoping: who is covered and what your boundary includes

Scope DORA before you build: confirm your entity type, apply proportionality, list critical functions and map every ICT third party into one register.

Safeguard Security Team
5 min read

DORA, the EU Digital Operational Resilience Act (Regulation 2022/2554), has applied since 17 January 2025 to many EU financial entities. Scoping means confirming your entity type, deciding how proportionality applies, identifying critical or important functions, and mapping every ICT service and third party that supports them.

Are you a financial entity under DORA?

Article 2 of the regulation lists the entity types in scope. Based on the recitals, they include credit institutions, payment institutions, account information service providers and electronic money institutions, along with other regulated financial firms. Some entities, such as certain insurers and small occupational pension schemes, sit outside it, and recitals describe a simplified framework for small and non interconnected investment firms and other named categories.

Read Article 2 itself against your licence, not a summary, and write down the result. If you are a technology company that sells to banks, you are probably not a financial entity, but you will be pulled in through contracts, which is a different boundary covered below.

How does proportionality change the work?

Microenterprises are exempt from several requirements, including advanced threat led testing, and the framework scales rules to size and complexity. Record your category, headcount and turnover basis, and have your regulator guidance on hand, because the supervisor's view of your category is what counts.

What is a critical or important function?

Most of DORA's heaviest rules hang on this idea. Article 8 asks you to identify, classify and document ICT supported business functions, the assets that support them and the dependencies, and to review this at least yearly. Build a function register with columns for business owner, supporting systems, supporting providers, and your reasoning for whether the function is critical or important. Make the reasoning concrete: what harm follows if it is down for a day, who is affected, and which regulatory duty it supports.

Which third parties are in the boundary?

Article 28(3) requires a register of information on all contractual arrangements for ICT services from third party providers, at entity and consolidated level, distinguishing those that support critical or important functions. Article 30 sets contract content, including service descriptions, data locations and termination rights, with extra terms for critical functions such as audit and access rights and exit strategies with a transition period.

List cloud, software as a service, managed services, data and market feeds, and intra group providers. Include subcontractors where your provider relies on them for a critical service. For each arrangement note the function it supports, the contract date, data location and exit plan.

What about groups and branches?

The register and the framework operate at entity and consolidated levels. If you sit in a group, agree with the parent who owns which part, how entity level registers roll up, and which entities are in scope. Document the decision in one page so a supervisor can follow it.

What evidence do you keep from scoping?

Keep the entity type analysis, proportionality note, function register, asset inventory, third party register, and board minutes approving scope. Article 5 puts ultimate responsibility for ICT risk on the management body, so minutes showing that body saw and approved the boundary matter more than a polished diagram.

What to do

  1. Read Article 2 and record whether and how each legal entity is covered.
  2. Note your proportionality category and the exemptions you claim, with reasons.
  3. Build a function register and mark critical or important functions.
  4. Inventory ICT assets and dependencies for those functions and set a yearly review.
  5. Start the third party register with every ICT arrangement, flagged by function.
  6. Check each contract against the Article 30 content list and log gaps.
  7. Agree group roles and consolidation with the parent entity.
  8. Take the scope to the management body for approval and keep the minutes.

Quick check

Does DORA apply to a software vendor that serves banks?

Not directly unless it is designated as a critical ICT third party provider, but its banking customers must put DORA terms into their contracts with it.

When did DORA start to apply?

Article 64 states that it applies from 17 January 2025.

How Safeguard helps automate this

Your register and inventory help while they match reality. Safeguard's compliance suite covers frameworks, controls, evidence, continuous monitoring, automated tests and questionnaires, so evidence is collected from connected systems and code instead of by screenshot, and monitoring runs between reviews so your team can work on other things. Technical evidence comes from your real code and dependencies through scans, SBOMs and reachability, which helps you see which open source components sit behind the functions you mapped. The agent can open tested fix pull requests, but it is off by default, every category starts on Manual, and you decide which categories run automatically. Safeguard helps prepare evidence; your supervisor and auditors make the judgments. Book a call.

Sources

Last reviewed: 18 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.