Article 2: Scope

Article 2: Scope requirement means you must determine whether your organization is in DORA’s in-scope population and document that determination so every DORA control, policy, and evidence set is built for the right legal entities, services, and jurisdictions. Operationalize it by producing a signed scope memo plus a living “DORA applicability register” that drives governance, third-party coverage, and audit-ready evidence. (Regulation (EU) 2022/2554, Article 2)

Key takeaways:

• Treat “scope” as a control: decide, document, approve, and keep it current as your business changes. (Regulation (EU) 2022/2554, Article 2)
• Your biggest risk is partial scoping: missing a regulated entity, branch, or ICT-supported business service that should be inside the DORA perimeter. (Regulation (EU) 2022/2554)
• Build traceability from Article 2 applicability to owners, controls, and supervisory artifacts in one register that you can hand to auditors. (Regulation (EU) 2022/2554)

Article 2 looks short, but it is the hinge for your entire DORA program. If you scope incorrectly, every downstream deliverable (ICT risk management, incident reporting, resilience testing, third-party oversight) can be misaligned, incomplete, or built for the wrong entities. Article 2 establishes which entities DORA applies to, and it does so by listing the categories of in-scope entities, while also signaling that other paragraphs (within Article 2) may further refine or adjust scope. (Regulation (EU) 2022/2554, Article 2)

For a Compliance Officer, CCO, or GRC lead, “operationalizing Article 2” is not a legal essay. It is an internal decision record that: (1) identifies the in-scope legal entities and relevant operations, (2) defines the DORA compliance perimeter for ICT and third-party relationships, and (3) sets accountability so the program can execute and produce evidence on demand. Your output should be simple to explain to a supervisor: who is in scope, why, what is covered, what is out, and how you keep the boundary current. (Regulation (EU) 2022/2554)

Regulatory text

Excerpt (provided): “Without prejudice to paragraphs 3 and 4, this Regulation applies to the following entities:” (Regulation (EU) 2022/2554, Article 2)

What an operator must do with this text

1. Make an applicability determination: confirm whether you are one of the entity types captured by Article 2, and which legal entities within your group fall inside that definition. (Regulation (EU) 2022/2554, Article 2)
2. Translate “applies to the following entities” into a compliance perimeter: define the organizational and operational boundary that your DORA program will govern (entities, branches, functions, ICT-supported services, and related third parties). (Regulation (EU) 2022/2554)
3. Document and govern change: because scope changes with acquisitions, new licenses, cross-border operations, and outsourcing, you need a controlled mechanism to keep the scope decision accurate over time. (Regulation (EU) 2022/2554)

Plain-English interpretation (article 2: scope requirement)

Article 2 is the “who is covered” rule. If you are a financial entity or otherwise listed in the scope provisions of DORA, DORA applies to you. Your practical job is to identify the exact legal entities and operations in your organization that must follow DORA, then use that decision to drive which ICT risks, systems, services, and third parties must be governed under your DORA framework. (Regulation (EU) 2022/2554, Article 2)

A workable interpretation for operators:

• Article 2 is a classification exercise (what regulated entity types you are).
• Article 2 is also a boundary exercise (which parts of the business and ICT estate your DORA controls must cover).
• Article 2 becomes an evidence exercise (can you prove to supervisors and auditors that you scoped deliberately and kept it current). (Regulation (EU) 2022/2554)

Who it applies to (entity and operational context)

DORA applies to the entity types identified in Article 2’s scope provisions. Your implementation should assume you may have more than one in-scope perimeter because many groups operate multiple legal entities across jurisdictions and business lines. (Regulation (EU) 2022/2554, Article 2)

Operationally, Article 2 touches:

• Corporate structure: parent, subsidiaries, branches, and regulated entities within a group structure. (Regulation (EU) 2022/2554)
• ICT governance: which ICT risk management policies and controls are mandatory for which entities. (Regulation (EU) 2022/2554)
• Third-party risk management: which third-party relationships must be controlled and evidenced as part of the DORA perimeter, including ICT-related third parties. (Regulation (EU) 2022/2554)

If you are a third party (for example, an ICT provider), Article 2 still matters because your customers will flow down DORA-driven requirements through contracting, oversight, incident communications, and testing expectations. Your “scope” work then becomes: identify which customers are DORA-regulated and which services you provide that support their regulated activities. (Regulation (EU) 2022/2554)

What you actually need to do (step-by-step)

Step 1: Build a DORA scope inventory (inputs first)

Collect the minimum inputs you need to decide scope and defend it:

• Legal entity list (including branches) and regulator/authorization status per entity.
• EU operating footprint and cross-border service delivery model.
• List of ICT-dependent critical or important business services (your internal terminology may differ, but keep the mapping consistent).
• Material ICT outsourcing and key ICT providers supporting those services. (Regulation (EU) 2022/2554)

Deliverable: Scope input pack stored in your GRC repository with version control.

Step 2: Make a written applicability determination

Create a short Article 2 applicability memo that answers:

• Which legal entities are in scope under Article 2 categories.
• Which are out of scope, and the reason (for example, non-regulated entity, non-EU operations, or other factual basis you can defend).
• Known scope assumptions and open questions for counsel or local regulatory specialists. (Regulation (EU) 2022/2554, Article 2)

Governance requirement (practical): route the memo for sign-off by Legal/Compliance and the accountable executive for ICT risk governance.

Step 3: Convert “who is in scope” into a DORA compliance perimeter

Define the perimeter in operational terms:

• In-scope entities and the ICT environments they rely on (shared services, group IT, cloud tenancy models).
• In-scope business services and key systems supporting them.
• Third parties supporting in-scope services, including subcontracting chains where known. (Regulation (EU) 2022/2554)

This step prevents a classic failure: scoping only legal entities while missing shared ICT services operated by a parent or affiliate that materially support the regulated entity.

Step 4: Create a DORA applicability register (the living control)

Build a single register that ties Article 2 scope to execution. Minimum columns:

• Legal entity
• Country/competent authority (if applicable)
• In-scope status (yes/no/partial) with rationale
• In-scope services and core systems
• Primary control owners (ICT risk, security operations, third-party risk, compliance)
• Evidence artifacts (policy links, testing records, incident runbooks, remediation logs)
• Last review date, next review trigger (acquisition, new product, new outsourcing, re-org) (Regulation (EU) 2022/2554, Article 2)

This is where tools like Daydream fit naturally: you use a single requirement-to-control-to-evidence register to keep scope decisions, ownership, and supervisory artifacts connected, rather than split across spreadsheets and ticketing systems.

Step 5: Stand up a regulatory-response workflow tied to scope

Supervisors and internal audit will test whether scope is real by asking for evidence quickly. Put in place:

• Intake channel for regulatory or auditor requests
• Triage criteria (what is in scope, what is out)
• Assignment and escalation
• Legal/compliance review before submission
• Post-response remediation tracking for any gaps found (Regulation (EU) 2022/2554)

Step 6: Prove it works with readiness drills and corrective actions

Run periodic “scope-to-evidence” drills:

• Pick an in-scope entity and a key ICT-supported service.
• Pull the end-to-end evidence set you claim exists.
• Log gaps and track them to closure with validation evidence. (Regulation (EU) 2022/2554)

Required evidence and artifacts to retain

Maintain artifacts that show the scope decision is deliberate, approved, and operationalized:

• Article 2 applicability memo with approvals. (Regulation (EU) 2022/2554, Article 2)
• DORA applicability register (current version plus change history). (Regulation (EU) 2022/2554)
• Entity and service mapping (legal entities to business services to key systems).
• Third-party inventory slice for in-scope services (contracts, due diligence status, oversight cadence).
• Regulatory-response runbook and sample completed request packages.
• Readiness drill reports and corrective action plans with closure evidence. (Regulation (EU) 2022/2554)

Common exam/audit questions and hangups

Expect questions in these patterns:

• “Show me how you determined whether DORA applies to each legal entity in your group.” (Regulation (EU) 2022/2554, Article 2)
• “Which business services and ICT systems fall under your DORA perimeter for the in-scope entity?” (Regulation (EU) 2022/2554)
• “How do you ensure shared IT services operated by another group company are covered?” (Regulation (EU) 2022/2554)
• “How do you keep the scope current after org changes or new outsourcing?” (Regulation (EU) 2022/2554)
• “Who is accountable for the scope register and evidence quality?” (Regulation (EU) 2022/2554)

Hangups that slow teams down:

• Disagreement between Legal Entity scope and Operational service scope.
• Incomplete third-party mapping for ICT-supported services.
• Evidence fragmentation: controls exist, but proof is scattered across teams. (Regulation (EU) 2022/2554)

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails in practice	Fix
Scoping by “brand” or business line instead of legal entities	DORA applicability is evaluated against regulated entities, not marketing structure	Anchor scope to legal entity identifiers; map business lines second. (Regulation (EU) 2022/2554, Article 2)
Declaring “group-wide compliance” without mapping shared services	Shared ICT services can sit outside the regulated entity but still support it	Document shared services and assign control owners across entities. (Regulation (EU) 2022/2554)
Treating scope as a one-time project	M&A, new products, outsourcing changes the perimeter	Add scope change triggers and periodic review in governance calendar. (Regulation (EU) 2022/2554)
No traceability from Article 2 to evidence	You cannot answer supervisory questions quickly	Maintain one register connecting requirement, owner, and artifact; keep it current. (Regulation (EU) 2022/2554)

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so you should manage risk based on supervisory expectations embedded in DORA: demonstrable governance, clear ownership, and evidence that the program operates as described. (Regulation (EU) 2022/2554)

Risk implications of weak Article 2 operationalization:

• Regulatory exposure: if your DORA perimeter is wrong, downstream obligations may be missed or inconsistently applied. (Regulation (EU) 2022/2554)
• Operational resilience exposure: out-of-scope assumptions can leave key ICT dependencies unmanaged, especially third parties supporting critical services. (Regulation (EU) 2022/2554)
• Audit friction: teams waste time debating scope during audits because they never locked it with approvals and a living register. (Regulation (EU) 2022/2554)

Practical 30/60/90-day execution plan

Time-based plans can become false precision across different institutions. Use these phases as a sequencing guide and size them to your change calendar and regulatory deadlines. (Regulation (EU) 2022/2554)

First 30 days (establish the decision and governance)

• Name an executive owner for DORA scope and a day-to-day operator in GRC.
• Collect scope inputs: legal entities, operating footprint, key ICT-supported services, key third parties. (Regulation (EU) 2022/2554)
• Draft and approve the Article 2 applicability memo. (Regulation (EU) 2022/2554, Article 2)
• Create the first version of the DORA applicability register with ownership and evidence placeholders. (Regulation (EU) 2022/2554)

Day 31–60 (turn scope into operational coverage)

• Map in-scope entities to business services and enabling systems.
• Identify third parties supporting those services and align them to your third-party due diligence workflows.
• Stand up the regulatory-response workflow (intake, triage, escalation, sign-off, retention). (Regulation (EU) 2022/2554)
• Run one readiness drill: pick a service, pull evidence end-to-end, log gaps. (Regulation (EU) 2022/2554)

Day 61–90 (stabilize and evidence the operating model)

• Close priority gaps from the drill with tracked corrective actions and validation evidence.
• Add scope change triggers into governance: procurement intake, M&A integration, new product approval, and major ICT changes.
• Implement a recurring review of the DORA applicability register and evidence completeness.
• If you are scaling, migrate the register into a system like Daydream so requirement-to-control-to-evidence stays auditable across teams. (Regulation (EU) 2022/2554)

Frequently Asked Questions

What does “without prejudice to paragraphs 3 and 4” mean operationally for Article 2 scope?

Treat it as a flag that other parts of Article 2 may modify or clarify scope. Your memo should explicitly note that scope is based on Article 2 and will be updated if additional scope conditions apply in the full text. (Regulation (EU) 2022/2554, Article 2)

We are a group with shared IT. Do we scope DORA at the parent level or regulated subsidiary level?

Anchor the applicability decision to the regulated legal entities, then extend operational coverage to shared ICT services that support them. Document cross-entity control ownership so shared IT does not fall into a governance gap. (Regulation (EU) 2022/2554)

Does Article 2 require a formal document, or is a spreadsheet enough?

DORA does not prescribe a template in the provided excerpt, but you need a defensible record. In practice, keep a signed memo for the decision and a register for ongoing operation and evidence tracking. (Regulation (EU) 2022/2554, Article 2)

How do we treat third parties that support both in-scope and out-of-scope services?

Scope the relationship to the in-scope services and require due diligence, contractual controls, and monitoring for that service line. Record the segmentation logic so audit can see why certain controls apply to part of the relationship. (Regulation (EU) 2022/2554)

What is the minimum “audit-ready” evidence for the article 2: scope requirement?

Keep the applicability memo with approvals, the current scope register with change history, and the mapping from in-scope entities to services/systems/third parties. Auditors mainly test clarity, ownership, and maintenance. (Regulation (EU) 2022/2554, Article 2)

How often should we revalidate DORA scope?

Revalidate on change triggers (acquisitions, new licenses, new outsourcing, major ICT architecture changes) and on a recurring governance cadence you can sustain. Document each review in the register change log. (Regulation (EU) 2022/2554)