Article 46: Competent authorities

Article 46: competent authorities requirement means you must know which regulator(s) supervise your DORA compliance, then build an operational supervisory-response capability that produces consistent, review-ready evidence across ICT risk, incident handling, resilience testing, and third-party oversight. Treat it as a governance and readiness requirement, not a one-time mapping exercise. (Regulation (EU) 2022/2554, Article 46)

Key takeaways:

• Identify your DORA competent authority(ies) and document the supervisory perimeter by legal entity, branch, and regulated activity. (Regulation (EU) 2022/2554, Article 46)
• Stand up a regulator-request workflow with clear owners, escalation paths, and evidence packaging standards. (Regulation (EU) 2022/2554, Article 46)
• Maintain traceability from DORA obligations to controls and “show-me” artifacts so you can respond fast and consistently. (Regulation (EU) 2022/2554)

If you are a CCO or GRC lead, Article 46 matters because it determines who can ask you questions, what powers they can use, and how quickly you need to respond with credible proof that DORA is operating in practice. The text is short, but the operational burden is real: competent authorities supervise DORA compliance, and you need a repeatable way to manage supervisory interactions across multiple internal teams and, often, multiple EU entities. (Regulation (EU) 2022/2554, Article 46)

Most DORA programs stumble here for two reasons. First, ownership is diffuse: ICT risk sits with security and IT, incident reporting sits with ops and legal, third-party controls sit with procurement, and audit evidence sits with GRC. Second, evidence is scattered across ticketing systems, testing platforms, and shared drives. Under supervisory pressure, gaps appear as inconsistencies, missed deadlines, and unverifiable claims.

This page translates the article 46: competent authorities requirement into a practical implementation pattern: a documented authority map, a supervisory-response workflow, and an evidence register that ties DORA obligations to artifacts you can produce on request. (Regulation (EU) 2022/2554, Article 46)

Regulatory text

Regulatory excerpt (verbatim): “Without prejudice to the provisions on the Oversight Framework for critical ICT third-party service providers referred to in Chapter V, Section II, of this Regulation, compliance with this Regulation shall be ensured by the following competent authorities in accordance with the powers granted by the respective legal acts:” (Regulation (EU) 2022/2554, Article 46)

Plain-English operator meaning

• DORA compliance is supervised by “competent authorities.” Your organization must be prepared to be examined, asked for information, and directed to remediate by the relevant authority(ies) for your regulated entity. (Regulation (EU) 2022/2554, Article 46)
• Article 46 also signals a boundary: the oversight framework for critical ICT third-party service providers is addressed elsewhere, so your internal compliance program must distinguish (a) your obligations as a regulated financial entity from (b) oversight activities aimed at critical ICT third-party service providers. Your controls still need to support both, because your services depend on third parties. (Regulation (EU) 2022/2554, Article 46)

Plain-English interpretation of the requirement

Treat Article 46 as a readiness requirement with three concrete outcomes:

1. Supervisory ownership is unambiguous. You can name the competent authority for each in-scope legal entity and explain why. (Regulation (EU) 2022/2554, Article 46)
2. Regulatory response is operationalized. You have a documented process to intake, triage, fulfill, approve, and track supervisory requests and remediation actions. (Regulation (EU) 2022/2554, Article 46)
3. Evidence is continuously producible. For each major DORA obligation area, you can produce consistent artifacts that show control design and operation. (Regulation (EU) 2022/2554)

This is where many programs quietly fail: they have policies, but cannot reliably assemble “show me” packages across incidents, testing, and third-party risk without heroics.

Who it applies to

Entity scope

• Regulated financial entities within DORA scope that must demonstrate compliance to their competent authority(ies). (Regulation (EU) 2022/2554, Article 46)

Operational context that triggers the work

• Multiple EU legal entities or branches with different supervisory touchpoints.
• Material reliance on ICT services and third parties where evidence sits outside the compliance function.
• Any environment where supervisory requests, onsite inspections, or thematic reviews are plausible outcomes of being regulated.

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

Step 1: Build your “Competent Authority Map”

Create a single register (spreadsheet is acceptable if controlled) that includes:

• Legal entity name, LEI (if you track it internally), country, regulated activity.
• Primary competent authority, secondary authority(ies) if applicable (group vs local).
• Primary points of contact and internal owner for the relationship.
• DORA supervisory perimeter statement: what systems, services, and lines of business are in-scope for that entity’s DORA evidence pack. (Regulation (EU) 2022/2554, Article 46)

Control objective: anyone on your team can answer “who supervises this entity for DORA?” in one lookup, and route requests correctly. (Regulation (EU) 2022/2554, Article 46)

Step 2: Define a supervisory-request workflow (intake to closure)

Document a workflow that is enforceable in practice:

1. Intake channels: email alias, portal, registered mail handling, and a back-up route if the primary contact is unavailable.
2. Triage and classification: information request, finding, remediation demand, or follow-up.
3. Assignment: named accountable owner (RACI) plus contributing SMEs (security, IT, procurement, ops, internal audit).
4. Response drafting: standard templates, fact-check rules, and evidence requirements.
5. Approval gates: Legal + Compliance sign-off for final response; include a “claims substantiation” check so every statement has an artifact behind it.
6. Submission and tracking: log sent date, method, attachments, and regulator acknowledgements.
7. Remediation management: convert findings into corrective action plans with owners and validation evidence before closure. (Regulation (EU) 2022/2554, Article 46)

Practical note: Put the workflow in the same system you use for other regulated commitments (GRC tool, ticketing, or case management). Email-only handling breaks under staff changes.

Step 3: Create an “Evidence Register” tied to DORA obligations

Build traceability from obligation area → control → artifact. Minimum viable structure:

• Obligation theme (ICT risk governance, incident handling, resilience testing, third-party risk).
• Control statement (what happens, by whom, how often you expect it to happen).
• Evidence list (what you will show an examiner).
• Evidence location (system of record), retention owner, and last refresh date. (Regulation (EU) 2022/2554)

This is where Daydream fits naturally: teams use Daydream to maintain a requirement-to-evidence register and to package supervisory-ready evidence consistently across control owners, so responses do not depend on institutional memory.

Step 4: Run readiness drills

Run a tabletop-style exercise that tests:

• Can you retrieve the last set of key artifacts quickly from the system of record?
• Do artifacts match what your policies claim?
• Do different teams provide consistent narratives (for example, incident severity definitions and escalation timelines)?
• Can you demonstrate remediation closure with validation evidence, not just ticket closure?

Convert drill outputs into tracked corrective actions with due dates, owners, and validation steps. (Regulation (EU) 2022/2554, Article 46)

Step 5: Operationalize “regulatory change + perimeter drift” checks

Your competent authority map can become stale after reorganizations, new products, or new outsourcing arrangements. Add a lightweight checkpoint in:

• New product approval
• Legal entity restructuring
• Outsourcing intake
• Major system migrations

Update the authority map and evidence register when perimeter changes occur. (Regulation (EU) 2022/2554, Article 46)

Required evidence and artifacts to retain

Keep artifacts in a controlled repository with versioning and clear ownership. Typical examiner-ready artifacts include:

• Competent Authority Map (the register described above) and internal ownership assignments. (Regulation (EU) 2022/2554, Article 46)
• Regulatory response procedure (workflow, RACI, approval requirements, escalation path). (Regulation (EU) 2022/2554, Article 46)
• Regulatory interaction log: requests received, responses sent, meeting minutes, commitments made, and closure status. (Regulation (EU) 2022/2554, Article 46)
• Evidence register mapping obligations to artifacts and systems of record. (Regulation (EU) 2022/2554)
• Corrective action plans tied to supervisory feedback, including validation evidence and closure approvals. (Regulation (EU) 2022/2554, Article 46)
• Readiness drill records: scenarios, participants, gaps found, and remediation tracking. (Regulation (EU) 2022/2554, Article 46)

Common exam/audit questions and hangups

Expect these lines of questioning:

1. “Who is your competent authority for DORA, and why?”
   Hangup: inconsistent answers across compliance, legal, and local management. (Regulation (EU) 2022/2554, Article 46)

2. “Show me how you handle supervisory requests end-to-end.”
   Hangup: no auditable workflow, no approval gates, or missing logs. (Regulation (EU) 2022/2554, Article 46)

3. “Prove that controls operate, not that policies exist.”
   Hangup: evidence lives in personal drives; artifacts are not reproducible. (Regulation (EU) 2022/2554)

4. “How do you ensure remediation actions actually fix the issue?”
   Hangup: tickets closed without validation evidence or independent sign-off. (Regulation (EU) 2022/2554, Article 46)

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails	How to avoid it
Treating Article 46 as “informational only”	Supervision becomes chaotic during the first real request	Build the authority map and response workflow as formal controls. (Regulation (EU) 2022/2554, Article 46)
No single system of record for regulator interactions	You cannot prove what was sent, when, and by whom	Maintain a controlled interaction log with attachments and approvals. (Regulation (EU) 2022/2554, Article 46)
Evidence assembled ad hoc	Responses become slow and inconsistent	Create an evidence register with named owners and locations. (Regulation (EU) 2022/2554)
Over-reliance on one SME	Key-person risk during exams	Use role-based ownership, backups, and rehearsal drills. (Regulation (EU) 2022/2554, Article 46)
Remediation tracked, but not validated	Findings recur in later reviews	Require validation evidence and closure sign-off in the workflow. (Regulation (EU) 2022/2554, Article 46)

Enforcement context and risk implications

No public enforcement cases were provided in the supplied source catalog for this requirement, so you should treat “enforcement context” here as supervisory-risk mechanics rather than case law.

Operational risk if you ignore Article 46 patterns:

• Regulatory relationship risk: missed deadlines, inconsistent statements, and incomplete evidence packages damage credibility quickly.
• Program risk: DORA activities remain siloed, so gaps in third-party oversight or resilience testing surface during reviews instead of being managed continuously. (Regulation (EU) 2022/2554, Article 46)

Practical 30/60/90-day execution plan

First 30 days (Immediate)

• Assign an executive owner (CCO or delegated regulatory affairs lead) for DORA supervisory readiness. (Regulation (EU) 2022/2554, Article 46)
• Draft the Competent Authority Map and validate it with legal entity owners and compliance.
• Stand up the regulator-request intake alias and interaction log.
• Identify top evidence sources and owners across security, IT, procurement, and ops. (Regulation (EU) 2022/2554)

By 60 days (Near-term)

• Publish the supervisory-request workflow with approval gates and escalation paths. (Regulation (EU) 2022/2554, Article 46)
• Build the first version of the evidence register, starting with the artifacts you can reliably produce today.
• Run a readiness drill using a realistic information request. Capture gaps and create corrective actions. (Regulation (EU) 2022/2554, Article 46)

By 90 days (Operationalize)

• Close priority gaps found in the drill with validation evidence and sign-offs.
• Integrate authority-map upkeep into change processes (new outsourcing, major platform changes, entity changes). (Regulation (EU) 2022/2554, Article 46)
• Standardize response templates and “claims substantiation” checks so every response can be defended with artifacts.
• If you need faster traceability and packaging, configure Daydream to maintain the requirement-to-evidence register and regulator-ready response packs across control owners. (Regulation (EU) 2022/2554)

Frequently Asked Questions

Does Article 46 require us to notify a competent authority proactively?

Article 46, as provided, establishes that competent authorities ensure compliance; it does not itself describe specific notification timelines or triggers. Treat it as a supervision and readiness requirement that drives your authority mapping and response workflow. (Regulation (EU) 2022/2554, Article 46)

We operate in multiple EU countries. Do we need more than one competent authority map?

Keep one consolidated map with clear filtering by legal entity and country, plus a single accountable owner for maintaining it. Supervisory routing fails when teams keep separate, conflicting lists. (Regulation (EU) 2022/2554, Article 46)

How do we show “compliance is ensured by competent authorities” in an audit?

You prove readiness and traceability: your authority map, your regulatory response workflow, your interaction log, and evidence packs that demonstrate operating controls. Auditors look for reproducibility and governance, not just policy statements. (Regulation (EU) 2022/2554, Article 46)

Does the oversight framework for critical ICT third-party service providers change what we do under Article 46?

Article 46 flags that a separate oversight framework exists; operationally, you should separate “our entity’s DORA obligations” from “third-party oversight mechanics,” but keep evidence connected because third-party controls are part of your ICT risk posture. (Regulation (EU) 2022/2554, Article 46)

What’s the minimum evidence pack we should be able to produce on demand?

Start with the authority map, the regulatory request workflow, the interaction log, and an evidence register that points to system-of-record artifacts across ICT risk, incidents, testing, and third-party oversight. Expand depth as you mature, but keep the core pack consistent. (Regulation (EU) 2022/2554)

Our evidence is spread across Jira, SharePoint, and security tools. How do we make this exam-ready?

Don’t try to centralize all raw data immediately. Create an evidence register that lists the authoritative source for each artifact, the owner, and how it is exported into a regulator-ready format, then test retrieval through drills. (Regulation (EU) 2022/2554)