Article 1: Subject matter

Article 1 of DORA is short, but it sets the operating perimeter for everything that follows. It states that the Regulation establishes uniform requirements for the security of network and information systems that support the business processes of financial entities (Regulation (EU) 2022/2554, Article 1). For a Compliance Officer, CCO, or GRC lead, the practical job is not to “comply with Article 1” in isolation. The job is to translate Article 1 into a defensible scope statement and an execution model you can prove with artifacts.

If you skip this step, downstream DORA work tends to fragment: security teams build controls around “critical systems,” procurement runs third-party diligence in a separate tool, resilience testing happens ad hoc, and compliance cannot quickly answer basic supervisory questions like “Which processes are in scope?” and “Show me the evidence that controls operate for systems that support those processes.”

This page gives requirement-level implementation guidance for operationalizing Article 1 quickly: what it means in plain English, who it applies to, what to do step-by-step, what evidence to retain, and what exam teams typically probe.

Requirement: Article 1 — Subject matter (what this really demands)

Plain-English interpretation: Article 1 tells you what DORA is “about” operationally: protecting the network and information systems that support the business processes of financial entities through uniform requirements (Regulation (EU) 2022/2554, Article 1). Your implementation deliverable is a scoped, owned, and evidence-backed program that covers those systems and the processes they enable.

Think of Article 1 as the scope spine for your DORA program:

• It forces a clear definition of business processes that matter to regulated activity.
• It forces a clear inventory of ICT assets and services that support those processes (including third parties).
• It forces a governance model that assigns accountability for meeting DORA requirements across ICT risk, security operations, compliance, and third-party owners.

Regulatory text

Excerpt: “In order to achieve a high common level of digital operational resilience, this Regulation lays down uniform requirements concerning the security of network and information systems supporting the business processes of financial entities…” (Regulation (EU) 2022/2554, Article 1)

Operator meaning: You must be able to demonstrate, on request, that:

1. You know which business processes are in scope,
2. You know which network and information systems support them, and
3. You implemented a coherent set of requirements across those systems, with proof the controls operate.

Article 1 does not list specific controls by itself. It compels you to set up the mapping and governance so the rest of DORA can be applied consistently.

Who it applies to (entity and operational context)

Article 1 sets the subject matter for DORA as a whole, so it is relevant wherever your organization is subject to DORA as a financial entity and wherever ICT supports the regulated business processes (Regulation (EU) 2022/2554, Article 1).

Operationally, this touches:

• Board/management governance: approval of scope, risk appetite for ICT risk, accountability.
• CISO / security operations: network and information systems security controls and monitoring.
• ICT risk management: risk identification and control assurance.
• Third-party risk management (TPRM): outsourced ICT services supporting in-scope processes.
• Business owners: process ownership, impact tolerance inputs, continuity expectations.
• Compliance/legal: regulatory interpretation, supervisory communications, evidence packaging.

If you are a group with multiple entities, treat applicability as an entity-by-entity and process-by-process scoping exercise. Article 1’s phrase “supporting the business processes of financial entities” is your cue to anchor scope to business processes, not org charts.

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

Below is a pragmatic build sequence that produces supervisory-ready outputs fast.

1) Create a DORA Article 1 scope statement (business-process anchored)

Deliverable: DORA Scope Memo (owned by Compliance; co-signed by ICT Risk/Security)

Include:

• List of in-scope business processes (use your enterprise process taxonomy if it exists; otherwise start with top customer/regulatory-facing processes).
• Criteria for what makes a process “in scope” (tie to regulated services and materiality).
• Mapping approach from business processes to ICT dependencies.

What examiners will test: that your scope is explicit, consistent, and maintained.

2) Map business processes to “supporting” network and information systems

Deliverable: Process-to-ICT Dependency Map

Minimum viable mapping fields:

• Business process name and owner
• Supporting applications/services (internal and third party)
• Infrastructure dependencies (identity, network, endpoints, hosting, key platforms)
• Data types handled (high-level)
• RTO/RPO or impact notes (high-level if your org has not finalized tolerances)

Practical tip: start with “systems of record” and “systems required to operate,” then expand to shared services (identity, logging, monitoring) that underpin many processes.

3) Stand up a single DORA obligation-to-control-and-evidence register

Deliverable: DORA Traceability Register (your “one register” for supervisors)

For Article 1, the register should show:

• Requirement: “Article 1: Subject matter”
• Program scope link: pointer to the Scope Memo and Dependency Map
• Control themes that implement DORA requirements across scoped systems (e.g., ICT risk governance, incident response workflow, resilience testing, third-party oversight)
• Named accountable owner(s) and backup
• Evidence artifacts and where they live
• Status and remediation items

This is where Daydream fits naturally: use it to maintain a living register that ties Article 1 scope to control owners and evidence pointers, so you can answer supervisory requests without assembling spreadsheets under pressure.

4) Assign accountability with an ICT-resilience RACI

Deliverable: RACI matrix spanning Compliance, ICT Risk, Security, IT Ops, TPRM, and key Business Owners

Minimum responsibilities to assign:

• Maintaining the scope statement
• Updating the dependency map as systems change
• Running control testing and tracking issues
• Owning third-party oversight for in-scope ICT services
• Managing supervisory requests, escalations, and sign-off

Risk to watch: “shared accountability” that becomes “no accountability.” Article 1’s uniformity goal implies consistent ownership and execution across the enterprise (Regulation (EU) 2022/2554, Article 1).

5) Implement a regulatory-response workflow (requests, escalations, remedial actions)

Deliverable: Supervisory Response Procedure + ticketing/workflow configuration

Operational requirements:

• Intake channel (mailbox or case system)
• Triage (what is urgent, who is informed)
• Legal/compliance review gates
• Evidence packaging standards (versioning, timestamps, source-of-truth links)
• CAPA workflow for remediation with closure criteria and validation evidence

This is one of the fastest ways to reduce “audit scramble” risk, because it turns ad hoc responses into a repeatable process.

6) Run readiness drills and remediate gaps with validation evidence

Deliverable: Readiness Drill Report + Corrective Action Plans (CAPAs)

A drill should test:

• Can you produce the scope statement and dependency map quickly?
• Can you show operated controls for a sampled set of scoped systems?
• Can you show open issues, risk acceptances, and closure evidence?

You do not need perfection on day one; you need a defensible plan, clear owners, and proof of iteration.

Required evidence and artifacts to retain

Use this as your Article 1 evidence checklist. Store it in a controlled repository and link it in your traceability register.

Artifact	Purpose	Owner
DORA Scope Memo (Article 1 scope)	Defines in-scope business processes and ICT scope	Compliance
Process-to-ICT Dependency Map	Proves you identified supporting systems	ICT Risk / Enterprise Architecture
DORA Traceability Register	Shows mapping from requirement to controls and evidence	GRC
RACI matrix	Demonstrates accountability	Compliance + CIO/CISO functions
Supervisory Response Procedure + sample completed case	Proves regulatory response capability	Compliance/Legal
Readiness drill outputs + CAPAs	Proves operational execution and remediation discipline	GRC + Control Owners
Change management linkage (how scope updates)	Shows scope stays current as systems change	IT Ops / GRC

Common exam/audit questions and hangups

Expect variants of:

• “Show me the list of business processes in scope and the ICT systems that support them.” (Regulation (EU) 2022/2554, Article 1)
• “How do you ensure DORA requirements are applied uniformly across those systems?”
• “Who owns this requirement operationally, and how do you prove controls operate?”
• “How do you manage ICT third parties that support in-scope processes?”
• “How do you respond to supervisory information requests and track remediation?”

Hangups that slow teams down:

• Disagreement on what counts as a “business process”
• Missing dependency mapping for shared services (IAM, logging, network)
• Evidence scattered across teams with no index or source-of-truth links

Frequent implementation mistakes (and how to avoid them)

1. Scoping by system criticality alone.
   Fix: scope by business process first, then map to supporting ICT systems (Regulation (EU) 2022/2554, Article 1).

2. Treating Article 1 as “intro text” with no work product.
   Fix: produce the Scope Memo + Traceability Register entry for Article 1. Make it auditable.

3. No single owner for the scope boundary.
   Fix: assign Compliance as scope curator, with ICT Risk validating technical completeness.

4. Dependency maps that don’t include third parties.
   Fix: include external ICT services that support in-scope processes and link them to TPRM records.

5. Evidence that exists but can’t be produced quickly.
   Fix: evidence indexing. Use a register (Daydream or equivalent) with direct links, owners, and last-updated dates.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so you should not assume a specific enforcement pattern here.

Operational risk is still clear: weak Article 1 execution leads to inconsistent application of DORA controls, gaps in third-party coverage, and slow supervisory responses. Those failures tend to surface during exams as “inability to demonstrate” scope, ownership, and operated controls tied to the systems that support regulated business processes (Regulation (EU) 2022/2554, Article 1).

Practical 30/60/90-day execution plan

Use a phased plan so you can show progress early without inventing time-based compliance guarantees.

First 30 days (Immediate)

• Draft and approve the DORA Scope Memo for Article 1 (Regulation (EU) 2022/2554, Article 1).
• Build the first version of the Process-to-ICT Dependency Map for the most material business processes.
• Create the DORA Traceability Register structure (even if some rows are placeholders).
• Assign a RACI for scope, mapping upkeep, and evidence ownership.

Days 31–60 (Near-term)

• Expand dependency mapping to shared services (IAM, network, monitoring, logging).
• Implement the supervisory response workflow with legal/compliance sign-off gates.
• Populate the traceability register with control owners and evidence pointers for the scoped systems.
• Start a CAPA log for gaps discovered during mapping and ownership assignment.

Days 61–90 (Operationalize)

• Run a readiness drill: produce scope, mapping, evidence for a sample set of systems, and remediation tracking.
• Tighten change management hooks: define when new systems/processes trigger scope review.
• Establish a cadence to refresh evidence links and validate control operation through testing results and remediation closure.

Frequently Asked Questions

What is the fastest way to “comply” with Article 1 if I’m behind?

Produce two artifacts: a business-process-based scope memo and a process-to-ICT dependency map, then connect them to a DORA traceability register (Regulation (EU) 2022/2554, Article 1). That gives you a defensible perimeter and a way to prove progress.

Does Article 1 require specific security controls by itself?

Article 1 sets the subject matter and scope for uniform requirements, focused on security of network and information systems supporting business processes (Regulation (EU) 2022/2554, Article 1). The specific control obligations come from other DORA articles, but Article 1 forces you to scope and govern them coherently.

How should we treat third parties under Article 1?

If a third party’s ICT services support an in-scope business process, include that dependency in your mapping and ensure your third-party oversight is tied to the same scope boundary (Regulation (EU) 2022/2554, Article 1). The goal is uniform coverage across internal and outsourced ICT.

What evidence will a supervisor ask for that maps directly to Article 1?

Expect requests for your scope definition, the list of business processes in scope, the systems supporting them, and proof you can trace requirements to owned controls and artifacts (Regulation (EU) 2022/2554, Article 1). Keep these indexed and retrievable.

We have multiple EU entities. Do we need one scope or many?

Start with a group approach, but maintain entity-level clarity where business processes, systems, or third-party contracts differ. Your artifacts should make it obvious what is in scope for each financial entity’s business processes (Regulation (EU) 2022/2554, Article 1).

Where does Daydream help with Article 1 specifically?

Article 1 lives or dies on traceability. Daydream is a practical place to maintain the obligation-to-control-and-evidence register, assign owners, and keep links to scope and dependency artifacts current so supervisory responses are repeatable.