Article 57: Exercise of the delegation

Article 57 (exercise of the delegation) is not an operational ICT-control requirement for financial entities; it governs how the European Commission may adopt delegated acts under DORA. Your job is to operationalize it by running a controlled “regulatory change intake” process: monitor delegated acts, assess applicability, update your DORA control mapping, and retain evidence that changes were implemented and governed. (Regulation (EU) 2022/2554, Article 57)

Key takeaways:

• Treat Article 57 as a trigger for regulatory-change management, not a stand-alone security control. (Regulation (EU) 2022/2554, Article 57)
• Build a repeatable workflow: identify delegated acts, assess impact, approve changes, implement, and evidence closure. (Regulation (EU) 2022/2554)
• Keep traceability: requirement-to-control mapping, decisions, approvals, implementation records, and readiness checks.

“Article 57: exercise of the delegation requirement” sits in DORA’s legal mechanics. It states that the European Commission has the power to adopt delegated acts, subject to conditions in that Article. (Regulation (EU) 2022/2554, Article 57) For a Compliance Officer, CCO, or GRC lead, that translates into one practical obligation: you must be ready to absorb and implement downstream, binding details that may be introduced via delegated acts.

In practice, teams fail this requirement indirectly. They build a DORA program that maps to today’s text but cannot demonstrate a controlled way to (1) detect updates, (2) decide applicability, (3) implement changes across ICT risk, security operations, and third-party management, and (4) prove it happened with auditable evidence. Supervisors rarely accept “we didn’t notice” or “we thought it didn’t apply” without a documented decision trail.

This page gives you requirement-level implementation guidance: who owns what, the workflow to stand up, the evidence set to retain, and the audit questions you should pre-answer. It’s written so you can operationalize quickly, then keep it running with minimal friction.

Regulatory text

Excerpt (provided): “The power to adopt delegated acts is conferred on the Commission subject to the conditions laid down in this Article.” (Regulation (EU) 2022/2554, Article 57)

Plain-English interpretation

• What the law says: The Commission can issue delegated acts under DORA, but only under the boundaries and conditions set in Article 57. (Regulation (EU) 2022/2554, Article 57)
• What an operator must do: Maintain an operating model that reliably identifies delegated acts connected to DORA and converts them into internal requirements, control updates, and implemented changes with documented governance. This is a compliance change-management expectation rooted in DORA’s structure as a framework that is supplemented over time. (Regulation (EU) 2022/2554)

Operator framing: Article 57 is a “future obligations will arrive” clause. You operationalize it by proving your DORA program can adapt without chaos and without gaps in ownership or evidence.

Who it applies to (entity and operational context)

In scope entities

• Financial entities implementing DORA controls (the “regulated entities” population referenced in your program scope) that must remain compliant as DORA is updated and supplemented. (Regulation (EU) 2022/2554)

In scope operational contexts

• Regulatory change management for ICT risk management, ICT incident handling, digital operational resilience testing, third-party risk management, and governance artifacts that may need updates when delegated acts change details. (Regulation (EU) 2022/2554)
• Cross-functional ownership: Legal/Compliance (interpretation), GRC (control mapping and evidence), CISO/ICT risk (technical implementation), Procurement/TPRM (third-party contract and oversight impacts).

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

Below is a practical workflow you can implement as a controlled process. Keep it simple, but make it provable.

Step 1: Establish a “DORA delegated acts” intake channel

Goal: No delegated act relevant to DORA should be missed.

Actions

1. Assign an owner in Compliance or Regulatory Affairs for DORA change monitoring.
2. Define monitored sources (at minimum, your legal update service and EUR-Lex watchlist tied to DORA). Anchor the scope to the DORA regulation reference to avoid drifting into unrelated ICT topics. (Regulation (EU) 2022/2554)
3. Create a standard intake record template: title, publication date, effective/applicable date (if stated in the act), summary, impacted DORA topics, and initial applicability view.

Practical tip: Make this intake channel the single entry point. When updates arrive via email threads, you lose traceability.

Step 2: Run a structured applicability and impact assessment

Goal: Produce a defensible decision, even when the answer is “no change required.”

Actions

1. Convene a small triage group: Compliance (chair), ICT risk, security operations, TPRM, and business owner(s) for affected services.
2. Document:
   • Whether the delegated act applies to your entity type and services in scope.
   • What policies/standards/procedures would change.
   • What controls and evidence artifacts must be added or modified.
3. Record the decision with sign-off (Compliance + accountable ICT owner).

Output: A signed applicability memo or ticket with attached analysis.

Step 3: Update your DORA requirement-to-control mapping

Goal: Maintain traceability from DORA obligations to operating controls and evidence.

Actions

1. Maintain a DORA control register that maps:
   • Requirement text reference (e.g., “DORA delegated act X” and its relation to DORA),
   • Control owner,
   • Control statement,
   • Evidence artifacts,
   • Testing/assurance method,
   • Dependencies (systems, third parties).
2. When the delegated act changes expectations, update the mapping and record the change reason.

Daydream fit (earned mention): Daydream is useful here because teams often struggle to keep a single, current register that ties requirements to controls, owners, and evidence across ICT and third-party domains. Use it as the system of record so updates are tracked, assigned, and evidenced without spreadsheet drift.

Step 4: Push changes through governed implementation (policy-to-production)

Goal: Convert analysis into implemented change.

Actions

1. Create implementation tasks for each impacted area:
   • Policy/standard updates (GRC/Compliance),
   • Procedure/runbook updates (Security Ops/IT),
   • Tooling/config changes (IT/SecEng),
   • Third-party contract updates and oversight actions (TPRM/Procurement).
2. Use your change governance forum (risk committee, ICT steering committee, or equivalent) to approve the plan and timelines.
3. Track remediation to closure with acceptance criteria: “what does ‘done’ mean” plus required evidence.

Step 5: Validate and retain evidence (prove it works)

Goal: Show operation, not intent.

Actions

1. Perform a readiness check after implementation:
   • Walkthrough of updated process,
   • Sampling of executed tickets/incidents/tests (as applicable),
   • Confirmation that evidence is produced and stored.
2. Record gaps as corrective actions with owners and due dates.
3. Close with validation evidence (e.g., retest record, revised artifact, manager attestation).

Required evidence and artifacts to retain

Build an “Article 57 evidence packet” that demonstrates your change-management capability under DORA’s delegated-acts mechanism. Suggested artifacts:

Governance and monitoring

• Regulatory change monitoring procedure (DORA-specific scope). (Regulation (EU) 2022/2554)
• Subscription/watchlist evidence or monitoring logs (what you monitor and when alerts were received).
• Intake log of delegated acts with unique identifiers and status (triage, in analysis, in implementation, closed).

Applicability and decisioning

• Applicability assessment memo/ticket with:
  • Summary,
  • Impacted domains,
  • Decision and rationale,
  • Approvals (Compliance and accountable ICT owner).

Control traceability

• DORA control mapping/register showing requirement-to-control-to-evidence links.
• Change history for control updates (what changed, why, who approved).

Implementation and validation

• Updated policies/standards/procedures with version control.
• Change tickets and implementation records (tool config changes, runbook updates).
• Post-change validation results (testing evidence, walkthrough notes, corrective actions closed).

Common exam/audit questions and hangups

Auditors and supervisors tend to probe for “control of change” and “evidence of operation.” Expect questions like:

• “How do you identify new DORA delegated acts and determine applicability?” (Regulation (EU) 2022/2554, Article 57)
• “Show me the last regulatory update you processed end-to-end. Where is the decision record and approval?”
• “Where is the mapping from the update to specific control changes and owners?”
• “If a delegated act required changes affecting third parties, how did you update contracts, oversight, and evidence?”
• “How do you prevent ‘orphan obligations’ when responsibilities span ICT risk, security, and procurement?”

Hangup to pre-empt: Teams present a generic regulatory change policy but cannot show DORA-specific execution records. Keep DORA-tagged artifacts.

Frequent implementation mistakes and how to avoid them

1. Mistake: Treating Article 57 as “not applicable, ignore.”
   Avoidance: Mark it as applicable to your governance model and tie it to regulatory-change controls, not to technical controls. (Regulation (EU) 2022/2554, Article 57)

2. Mistake: Monitoring exists, but there’s no documented decision trail.
   Avoidance: Require an applicability memo/ticket for every relevant update, even if no changes are needed.

3. Mistake: Updates are implemented, but control mapping isn’t updated.
   Avoidance: Make control register updates a mandatory closure criterion for every regulatory-change ticket.

4. Mistake: Third-party impacts are missed.
   Avoidance: Include TPRM/Procurement in triage by default; add a checklist item: “third-party contract/oversight impact assessed.”

5. Mistake: Evidence is scattered across email, chat, and personal drives.
   Avoidance: Centralize in a GRC repository with naming conventions and retention rules.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this page, so you should treat enforcement learnings as indirect: weak regulatory change management increases the risk of drifting out of compliance when delegated acts add specificity. (Regulation (EU) 2022/2554, Article 57) Operationally, this turns into:

• Delayed implementation of new requirements,
• Inconsistent controls across business lines,
• Unclear accountability between ICT and Compliance,
• Incomplete evidence during supervisory review.

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

You asked for speed. Use phases rather than promises of completion dates.

First 30 days (Immediate foundation)

• Name a DORA regulatory-change owner and backups.
• Stand up the intake log and applicability memo template.
• Create or refresh the DORA control register with named owners and evidence fields.
• Run one tabletop: simulate a delegated act arriving and walk it through triage, mapping, and implementation planning.

Days 31–60 (Operationalize and test)

• Integrate the workflow into existing governance: committee cadence, change ticketing, and document control.
• Tag DORA artifacts in your repository and define minimum evidence for closure.
• Pilot the process on one real regulatory update (or a controlled internal “mock update”) and capture lessons learned.

Days 61–90 (Harden and make it auditable)

• Add readiness drills: periodic spot-checks that evidence is produced and stored.
• Close gaps via corrective action plans with validation records.
• Prepare an “exam-ready packet” that can be exported quickly: monitoring proof, last update processed, control mapping deltas, and closure evidence.

Frequently Asked Questions

Does Article 57 require me to implement a specific ICT security control?

No. Article 57 addresses the Commission’s authority to adopt delegated acts under DORA. You operationalize it by maintaining a controlled process to detect those acts and convert them into implemented compliance changes with evidence. (Regulation (EU) 2022/2554, Article 57)

What is the minimum I need to show an auditor for the article 57: exercise of the delegation requirement?

Show monitoring plus execution: an intake log, an applicability assessment with sign-off, updated control mapping where needed, and implementation/validation evidence. The goal is traceable change management tied to DORA updates. (Regulation (EU) 2022/2554)

Who should own this requirement internally?

Compliance or Regulatory Affairs should own monitoring and interpretation, with ICT risk/security and TPRM owning implementation actions in their domains. Document RACI so delegated-act changes cannot fall between teams. (Regulation (EU) 2022/2554)

How do I handle a delegated act that I believe does not apply to my entity?

Record a formal non-applicability decision with rationale and approvals, then store it in the same evidence repository as “applicable” changes. Treat “no change” as an auditable outcome, not an informal judgment. (Regulation (EU) 2022/2554)

How does this connect to third-party risk management under DORA?

Delegated acts can introduce details that affect oversight, contractual clauses, or evidence expectations for ICT third parties. Include TPRM in triage and require an explicit “third-party impact assessed” step in every applicability review. (Regulation (EU) 2022/2554)

We already have an enterprise regulatory change policy. What do we add for DORA?

Add DORA-specific scoping, tagging, and evidence expectations: a DORA intake log, a control mapping register that ties changes to owners and artifacts, and a readiness check that confirms the updated process produces evidence. (Regulation (EU) 2022/2554)