Article 3: Definitions

Article 3 is short, but it is operationally expensive to get wrong. DORA’s control obligations, reporting triggers, and third-party expectations depend on defined terms. If your organization interprets “ICT services,” “ICT-related incident,” “critical or important function,” or “ICT third-party service provider” differently across Security, Technology, Procurement, and Compliance, you will mis-scope your program and produce evidence that does not line up under supervisory review.

Treat the article 3: definitions requirement as an implementation prerequisite: you are not “complying with definitions” by publishing a glossary. You comply by making DORA’s definitions the single source of truth for how your controls are scoped, who owns them, what gets inventoried, and what gets reported. The practical outcome is consistent classification across systems, faster regulatory responses, and cleaner audit trails.

This page gives requirement-level guidance you can execute quickly: who needs to care, what to build, what artifacts to retain, and the exam questions that tend to expose definition gaps. Primary source: DORA Article 3. (Regulation (EU) 2022/2554, Article 3)

Regulatory text

Excerpt: “For the purposes of this Regulation, the following definitions shall apply:” (Regulation (EU) 2022/2554, Article 3)

Operator interpretation (plain English)

Article 3 tells you that DORA’s defined terms control how the rest of the regulation is read and applied. Practically: you must adopt the DORA definitions as binding, align internal terminology to them, and document how you apply them to your business and third parties so your DORA program is scoped consistently. (Regulation (EU) 2022/2554, Article 3)

What the operator must do

You need a controlled, reviewable method to:

1. Identify where DORA-defined terms drive scope or thresholds (for example, what counts as an ICT service, who qualifies as an ICT third-party provider, what is a function in scope).
2. Implement those terms as data fields and decision rules in your inventories, workflows, and reporting.
3. Retain evidence that your teams apply the definitions consistently over time and can explain exceptions. (Regulation (EU) 2022/2554, Article 3)

Plain-English requirement statement (what “good” looks like)

You can demonstrate the article 3: definitions requirement is operationalized when:

• Your DORA control mapping uses DORA terms consistently (no “local synonyms” that change scope).
• Your ICT asset/service inventory and third-party inventory can be filtered using DORA-relevant classifications.
• Your incident management workflow uses DORA-aligned categories and escalation paths, with documented decisioning.
• Your policies and procedures reference DORA definitions or link to your Definitions Register as the authoritative source. (Regulation (EU) 2022/2554, Article 3)

Who it applies to (entity and operational context)

DORA applies to financial entities in scope and includes oversight expectations that touch core ICT operations and third-party dependency management. At the operational level, Article 3 impacts any function that sets scope, classifies services, or triggers reporting, including:

• Compliance / GRC (control mapping, regulatory interpretations, exam response)
• Information Security (incident taxonomy, monitoring, response thresholds)
• Technology / ITSM (service catalog, change and problem management)
• Third-party risk management and Procurement (third-party classification, contracting)
• Business owners of key processes (function criticality, impact assessments) (Regulation (EU) 2022/2554)

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

Step 1: Build a controlled “DORA Definitions Register”

Create a single register that includes:

• Defined term (as in DORA)
• Internal term(s) used today (synonyms, legacy labels)
• Operational decision rule (how your org applies it)
• Systems of record where the term must be implemented (GRC tool, CMDB/service catalog, third-party system, IR platform)
• Control and process owners accountable for correct use
• Evidence artifact(s) that prove operational use (tickets, reports, screenshots, workflow configs)
• Change control (who approves updates; versioning; effective date)

Keep this register under document control with Legal/Compliance sign-off for interpretive notes. (Regulation (EU) 2022/2554, Article 3)

Step 2: Map definitions to concrete control scope decisions

For each definition that changes scope, force a decision and record it. Examples of high-impact decision points:

• Whether a given outsourced activity is an ICT service for DORA purposes.
• Whether a provider is treated as an ICT third-party service provider in your inventory and due diligence workflow.
• Which business processes are treated as critical or important for resilience scoping.
• What qualifies as an ICT-related incident category in your incident workflow and reporting triggers.

The output is a “definition-to-scope map” that shows how you translate legal terms into operational boundaries. (Regulation (EU) 2022/2554, Article 3)

Step 3: Implement definitions in tooling (don’t stop at documents)

Update your systems so the definitions drive workflow:

• Third-party inventory: add fields/tags aligned to DORA scoping (for example, “ICT service provided: yes/no,” “supports critical/important function: yes/no,” “data sensitivity class” if used in your control design).
• Service catalog/CMDB: tag services that meet your DORA “ICT service” decision rule and link them to owners and dependent third parties.
• Incident management: incorporate DORA-aligned categories and escalation decision points; ensure decisioning is recorded in tickets.
• GRC mapping: map each DORA requirement to internal controls, owners, and evidence artifacts in one register so definitions and obligations stay linked.

This is where most programs fail: teams agree on definitions in workshops, but nothing changes in the data model. (Regulation (EU) 2022/2554, Article 3)

Step 4: Train reviewers and create a “definition escalation” path

Create a lightweight workflow for definition disputes:

• If Security and Procurement disagree on whether a SaaS tool is an ICT service, the issue must route to a named decision-maker (often Compliance + ICT Risk + Legal).
• Store the decision in the Definitions Register and link it to the affected third party or service record.
• Re-test impacted control mappings after the decision.

In Daydream (or any GRC system), treat this as a “regulatory interpretation ticket” with approval, evidence, and audit trail. (Regulation (EU) 2022/2554, Article 3)

Step 5: Run readiness drills focused on definition consistency

Run scenario-based checks that specifically target definition application:

• Pick a set of services and third parties and validate their DORA classification end-to-end across inventory, contracts, incident workflows, and control mappings.
• Open corrective actions for mismatches and require closure evidence.
• Keep the drill outputs as audit-ready artifacts.

This supports faster supervisory responses because you can show you test your own scoping logic and fix gaps. (Regulation (EU) 2022/2554)

Required evidence and artifacts to retain

Auditors and supervisors rarely want a glossary alone. Retain:

• DORA Definitions Register (version-controlled; approvals captured)
• Mapping register connecting DORA requirements to controls, owners, and evidence artifacts (single source of truth)
• Tool configuration evidence (screenshots/exported configs showing required fields and workflow steps in third-party inventory, ITSM, IR tooling)
• Decision logs for disputed classifications (who decided, rationale, date, impacted records)
• Training artifacts (slides, attendance, role-based job aids for classification)
• Readiness drill outputs (test scripts, sample selections, findings, corrective action plans, closure evidence) (Regulation (EU) 2022/2554, Article 3)

Common exam/audit questions and hangups

Expect questions like:

• “Show me where you define and operationalize DORA terms, and how you keep definitions consistent across teams.” (Regulation (EU) 2022/2554, Article 3)
• “Which system is the source of truth for whether a third party is an ICT third-party provider, and who approves changes?” (Regulation (EU) 2022/2554, Article 3)
• “Give examples where a definition changed the scope of controls or reporting, and show the evidence trail.” (Regulation (EU) 2022/2554, Article 3)
• “How do you prevent local terms (‘IT vendor’, ‘outsourcer’, ‘cloud supplier’) from bypassing your DORA scoping logic?” (Regulation (EU) 2022/2554, Article 3)

Hangups that trigger follow-ups:

• Definitions exist in policy, but inventories don’t reflect them.
• Multiple inventories disagree (Procurement list vs. Security SaaS discovery vs. AP spend list).
• No approval trail for interpretation decisions. (Regulation (EU) 2022/2554, Article 3)

Frequent implementation mistakes and how to avoid them

Mistake 1: Treating Article 3 as “legal-only”

Failure mode: Legal publishes definitions; operations ignore them.
Fix: Add required fields and workflow gates in tools so the definitions are applied at intake (new third party, new service, new incident). (Regulation (EU) 2022/2554, Article 3)

Mistake 2: No explicit decision rules

Failure mode: Teams interpret the same term differently in different contexts.
Fix: For each high-impact term, write a decision rule and include examples of inclusions/exclusions in the register. Keep it short and testable. (Regulation (EU) 2022/2554, Article 3)

Mistake 3: Definition drift over time

Failure mode: As org structure changes, old classifications remain and scope decays.
Fix: Add periodic sampling checks in your readiness drill program and require remediation tickets with closure evidence. (Regulation (EU) 2022/2554)

Mistake 4: Poor traceability from definition to evidence

Failure mode: You can’t prove that an “ICT service” tag changes any control execution.
Fix: Link the classification to concrete control activities (due diligence depth, testing cadence, monitoring requirements) and retain system outputs that show the linkage. (Regulation (EU) 2022/2554, Article 3)

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so you should treat enforcement risk here as indirect: supervisors typically identify definition problems as root causes of broader failures (mis-scoped incident reporting, incomplete third-party oversight, missing resilience testing evidence). Your risk is rework under exam pressure, inconsistent supervisory responses, and gaps that persist because the program’s “who/what is in scope” logic is unstable. (Regulation (EU) 2022/2554)

Practical execution plan (30/60/90-day)

You asked for speed. This plan focuses on getting to a stable operational baseline quickly.

First 30 days: establish the source of truth

• Stand up the DORA Definitions Register with document control and named approvers (Compliance + ICT Risk + Legal).
• Identify “definition hotspots”: third-party inventory, service catalog/CMDB, incident workflow, control mapping.
• Pick a minimal set of high-impact terms and write decision rules for each.
• Create an escalation workflow for definition disputes and require that decisions are logged. (Regulation (EU) 2022/2554, Article 3)

Days 31–60: push definitions into systems and workflows

• Add/update required fields in third-party inventory and service catalog to reflect your decision rules.
• Update incident intake and triage workflows so DORA-aligned categories and decisioning are recorded.
• Update your DORA control mapping to reference the Definitions Register and specify evidence artifacts per control.
• Train control owners and reviewers on how to apply definitions in tickets and assessments. (Regulation (EU) 2022/2554, Article 3)

Days 61–90: test, fix, and make it audit-ready

• Run a readiness drill: sample services, third parties, and incidents; test definition consistency across systems.
• Open corrective actions for mismatches; require closure evidence (tool updates, retraining, reclassification).
• Prepare an “exam pack” folder: register versions, decision logs, workflow screenshots, drill results, and mapping outputs. (Regulation (EU) 2022/2554)

Frequently Asked Questions

Do we need to copy DORA’s definitions verbatim into our policies?

You can reference DORA’s definitions and point to a controlled Definitions Register as the authoritative source. The key is consistency and auditability of how your teams apply the terms. (Regulation (EU) 2022/2554, Article 3)

Who should own the definitions register: Legal or Compliance?

Compliance/GRC typically owns the operational register because it ties directly to control scope and evidence. Legal should approve interpretive notes and handle disputes that affect regulatory interpretation. (Regulation (EU) 2022/2554, Article 3)

What is the minimum evidence an auditor will accept for Article 3?

A version-controlled Definitions Register plus proof the definitions are implemented in systems (inventory fields, workflow steps) and used in real records (tickets, assessments). A glossary without workflow evidence is rarely persuasive. (Regulation (EU) 2022/2554, Article 3)

Our third-party inventory is incomplete. Can we still operationalize Article 3?

Yes. Start by making the inventory you have DORA-classifiable, then create a remediation plan to reconcile data sources (Procurement, AP, SSO/SaaS discovery). Document gaps and decisions as you go. (Regulation (EU) 2022/2554, Article 3)

How do we handle disagreements on whether a provider is an “ICT third-party service provider”?

Use a formal escalation path with a recorded decision, approver, and effective date. Link the decision to the provider record so future reviews do not reopen the same argument. (Regulation (EU) 2022/2554, Article 3)

Where does Daydream fit without turning this into a tooling project?

Use Daydream as the single register for requirement-to-control mapping, owners, and evidence artifacts, then attach definition decisions and workflow proof to the same record. That keeps your definitions, scoping, and supervisory evidence in one place. (Regulation (EU) 2022/2554, Article 3)