Article 58: Review clause

Article 58 doesn’t impose a new control like incident reporting or penetration testing. It sets an expectation that the DORA regime will be reviewed by the Commission and may be updated, which creates an operational requirement for regulated entities: keep your DORA program maintainable, provable, and adaptable under supervisory scrutiny. (Regulation (EU) 2022/2554, Article 58)

For a Compliance Officer, CCO, or GRC lead, the practical question is: “How do I prevent a future regulatory change from turning into a scramble, missed deadlines, or inconsistent evidence?” The answer is governance and traceability. You need clear accountability across ICT risk, security operations, third-party risk management, and Legal/Compliance, plus a repeatable workflow to absorb supervisory requests and implement corrective actions without losing control of documentation.

This page translates the article 58: review clause requirement into an operator’s playbook: who owns it, how to build a “review-ready” compliance posture, what artifacts to keep, and what examiners usually probe (even when the legal text is short). Where helpful, it also points to widely used control structures (e.g., ISO/IEC 27001, NIST CSF) to make implementation concrete, without treating those frameworks as substitutes for DORA.

Regulatory text

Excerpt (operative concept): By 17 January 2028, the European Commission must review DORA, consult the ESAs and the ESRB as appropriate, and submit a report to the European Parliament and Council, potentially with a legislative proposal. (Regulation (EU) 2022/2554, Article 58)

What the operator must do with this text:
Article 58 is addressed to the Commission, but regulated entities should treat it as a governance and change-readiness requirement. You should be able to:

1. demonstrate that your DORA controls are mapped, owned, and evidenced, and
2. update that mapping efficiently if the review results in amendments, new RTS/ITS, or changed supervisory expectations. (Regulation (EU) 2022/2554, Article 58)

Plain-English interpretation (what it means in practice)

Article 58 signals that DORA is not “set and forget.” A formal review date exists, and amendments may follow. Practically, supervisors will expect regulated entities to run a living program: controls that are maintainable, evidence that is findable, and governance that can take new requirements from “published” to “implemented” with minimal confusion. (Regulation (EU) 2022/2554, Article 58)

Treat this requirement like you would treat:

• a standing regulatory change management obligation,
• a documentation and evidence discipline obligation, and
• a cross-functional accountability obligation.

This is where many programs fail: they implement controls but cannot prove them end-to-end, or they spread evidence across teams and tools with no single “source of truth.”

Who it applies to (entity and operational context)

Applies to: DORA in-scope financial entities and relevant internal functions that operate ICT risk and resilience controls, including:

• Compliance / Legal (regulatory interpretation, change management, supervisory response),
• ICT risk management (control design, risk acceptance),
• Information security / SOC (monitoring, incident workflows, testing),
• Third-party risk management / outsourcing (contracting, performance oversight),
• Internal audit (independent assurance and issue follow-up). (Regulation (EU) 2022/2554)

Operational contexts where Article 58 becomes “real”:

• You receive supervisory questions about your DORA readiness and need consistent evidence fast.
• A DORA-related delegated act, RTS/ITS, or interpretive expectation changes, and you must re-map controls without breaking your audit trail.
• M&A, major outsourcing, cloud migrations, or core banking platform changes alter your ICT risk profile and you must update your DORA mapping and evidence approach.

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

1) Build a DORA requirements-to-controls traceability register

Create a single register that maps each DORA obligation you track (article-level at minimum) to:

• control objective,
• control owner (named role, not a team),
• process and system scope,
• evidence artifacts (exact report, ticket type, log source, test record),
• review cadence and attestation method,
• open issues and remediation links. (Regulation (EU) 2022/2554)

Operator tip: If your GRC tool can’t represent “evidence pointers” cleanly, keep a lightweight register in a controlled repository and link out to the system of record (ticketing, SIEM, TPRM platform, document control).

2) Assign accountable owners across the full lifecycle (design, operation, evidence)

Article 58 risk is ownership ambiguity. For each mapped obligation, set:

• Accountable (A): one role who signs off control operation,
• Responsible (R): the role running the control day-to-day,
• Consulted (C): Legal/Compliance, ICT risk, third-party owner as needed,
• Informed (I): internal audit and senior management committees. (Regulation (EU) 2022/2554)

Keep this simple. A control with three “Accountables” has none.

3) Implement a regulatory-response workflow (supervisory readiness)

Stand up a workflow that handles:

• inbound supervisory requests (intake, triage, deadlines, owner assignment),
• evidence collection (standardized request lists, export formats),
• Legal/Compliance review and sign-off,
• final submission packaging (version control, approvals),
• post-response actions (gaps logged, corrective actions created). (Regulation (EU) 2022/2554)

Minimum viable workflow components:

• a single intake channel (mailbox + ticket),
• a request tracker with statuses,
• an evidence library structure aligned to your traceability register,
• a sign-off checkpoint before anything leaves the firm.

4) Run periodic readiness drills (tabletop for evidence, not just incidents)

Schedule drills focused on:

• “Provide proof” exercises (produce evidence for a sample of key obligations),
• response-time measurement (qualitative targets are fine; focus on repeatability),
• quality checks (is evidence complete, dated, scoped, and approved?). (Regulation (EU) 2022/2554)

A drill is successful only if it produces corrective actions with owners and closure dates tracked to completion.

5) Close gaps with tracked corrective action plans (CAPs) and validation

For every drill finding, audit issue, or control failure:

• open a CAP with root cause,
• assign an owner and approver,
• define remediation steps and acceptance criteria,
• collect validation evidence (test results, screenshots, change records),
• record closure approval and residual risk acceptance if applicable. (Regulation (EU) 2022/2554)

6) Monitor for change and update the mapping (regulatory change management)

Operationalize “review clause readiness” by monitoring:

• Commission/ESA publications relevant to DORA,
• internal impact assessments (what changes in scope, controls, evidence),
• communication and training updates,
• revisions to your traceability register and policy set. (Regulation (EU) 2022/2554, Article 58)

Where Daydream fits naturally: If you need to keep a living DORA obligation-to-evidence map without manual chasing, Daydream’s control register approach can centralize owners, evidence pointers, and remediation tracking so you can answer supervisory questions without rebuilding context each time.

Required evidence and artifacts to retain

Keep artifacts that prove three things: (1) you mapped and owned the obligation, (2) controls operate, and (3) you can respond and remediate.

Core artifacts (recommended):

• DORA traceability register (article → control → owner → evidence pointer). (Regulation (EU) 2022/2554)
• RACI or equivalent ownership matrix for ICT resilience controls. (Regulation (EU) 2022/2554)
• Supervisory/regulatory request log (intake, assignment, deadlines, responses, approvals). (Regulation (EU) 2022/2554)
• Evidence library index (what evidence exists, where it lives, retention owner). (Regulation (EU) 2022/2554)
• Readiness drill records: scenario, participants, evidence produced, gaps, CAPs opened. (Regulation (EU) 2022/2554)
• CAP tracker with validation evidence and closure approvals. (Regulation (EU) 2022/2554)

Evidence quality checklist (use on every artifact):

• dated, versioned, and approved,
• scoped to the correct legal entity and service perimeter,
• repeatable (another person can reproduce the report),
• stored in a controlled repository with access logs.

Common exam/audit questions and hangups

Expect questions that test whether you can prove “program control,” not just “control existence”:

• “Show me where DORA obligations are mapped to specific internal controls and owners.” (Regulation (EU) 2022/2554)
• “If DORA guidance changes, how do you update policies, procedures, and evidence expectations?” (Regulation (EU) 2022/2554, Article 58)
• “Produce evidence for a sample of controls, end-to-end, including approvals and remediation history.” (Regulation (EU) 2022/2554)
• “How do you ensure ICT risk, security, and third-party owners stay aligned on one interpretation?” (Regulation (EU) 2022/2554)

Hangups that stall teams:

• evidence exists but is spread across tools with inconsistent naming,
• ownership is a committee instead of a person,
• remediation closes in tickets without validation artifacts.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Treating Article 58 as “not applicable” because it’s addressed to the Commission.
   Avoidance: Keep it on your compliance obligations list as a trigger for regulatory change management and audit-readiness governance. (Regulation (EU) 2022/2554, Article 58)

2. Mistake: Mapping obligations to policies only (no operating control and no evidence pointer).
   Avoidance: For every mapped item, list the operational control activity and the exact evidence output (report name, ticket type, system log). (Regulation (EU) 2022/2554)

3. Mistake: “Evidence by screenshot” without a reproducible source.
   Avoidance: Prefer system-generated exports, immutable logs, ticket histories, and signed test reports. Use screenshots only as supplemental context. (Regulation (EU) 2022/2554)

4. Mistake: CAP closure without independent validation.
   Avoidance: Require a closure checklist with validation evidence and approver sign-off. Internal audit should be able to reperform the verification. (Regulation (EU) 2022/2554)

5. Mistake: Third-party evidence is requested ad hoc each time.
   Avoidance: Predefine third-party evidence expectations (SOC reports, resilience testing, incident coordination artifacts) and link them to the traceability register. (Regulation (EU) 2022/2554)

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for Article 58. Practically, the risk shows up as supervisory friction: slow or inconsistent responses, missing evidence, unclear ownership, and repeated audit findings. Those failures tend to expand exam scope, trigger formal remediation programs, and increase management attention requirements. (Regulation (EU) 2022/2554)

A practical 30/60/90-day execution plan

First 30 days (stabilize governance and traceability)

• Stand up a DORA traceability register at article level, starting with “high scrutiny” operational areas (incident handling, testing, third-party services). (Regulation (EU) 2022/2554)
• Assign a single accountable owner per mapped obligation and document RACI. (Regulation (EU) 2022/2554)
• Create a standard evidence library structure and naming convention aligned to the register. (Regulation (EU) 2022/2554)
• Draft the supervisory request workflow (intake, tracking, approvals, packaging). (Regulation (EU) 2022/2554)

Next 60 days (prove operation and fix obvious gaps)

• Run an evidence production drill: select a sample of mapped obligations and produce end-to-end evidence packages with sign-off. (Regulation (EU) 2022/2554)
• Open CAPs for every gap, assign owners, and define validation criteria. (Regulation (EU) 2022/2554)
• Add third-party evidence expectations to your mapping for critical services, and confirm contract hooks or practical alternatives where contracts are silent. (Regulation (EU) 2022/2554)

By 90 days (institutionalize repeatability)

• Operationalize a steady-state cadence: recurring mapping review, readiness drills, and CAP reporting to the right governance forum. (Regulation (EU) 2022/2554)
• Implement metrics that matter operationally (counts are fine): open CAPs by severity, overdue evidence items, response workflow cycle times. (Regulation (EU) 2022/2554)
• Do a “single point of truth” check: confirm every mapped obligation has an owner and a current evidence pointer that a backup person can retrieve. (Regulation (EU) 2022/2554)

Frequently Asked Questions

Does Article 58 create a direct compliance obligation for my firm?

The text directs the Commission to perform a review by 17 January 2028. Operationally, you should treat it as a requirement to maintain change readiness and governance so your DORA program can adapt and remain provable. (Regulation (EU) 2022/2554, Article 58)

What will an examiner actually expect me to show for the article 58: review clause requirement?

They will typically test that you have traceability from DORA obligations to controls, owners, and evidence, plus a repeatable regulatory-response and remediation workflow. Article 58 supports the expectation that your program stays current as the regime evolves. (Regulation (EU) 2022/2554, Article 58)

What is the minimum viable artifact set to be “review-ready”?

Keep a DORA mapping register with owners and evidence pointers, a supervisory request tracker with approvals, and a CAP log with validation evidence. Those three pieces usually expose whether the program is controlled or improvised. (Regulation (EU) 2022/2554)

How do I align this with ISO 27001 or NIST CSF without creating duplicate work?

Use ISO 27001/NIST CSF as your control taxonomy, then map DORA obligations to the specific controls already operating under those frameworks. The deliverable that matters is the DORA-to-control-to-evidence traceability, not a second set of controls. (Regulation (EU) 2022/2554)

How should third-party risk management tie into Article 58 readiness?

Your mapping should include evidence that critical third parties meet resilience expectations, and your supervisory-response workflow should define how you collect third-party artifacts quickly. Avoid one-off chases by predefining evidence requirements and storage locations. (Regulation (EU) 2022/2554)

What’s the fastest way to find out whether we’re actually ready?

Run an evidence drill where a non-subject-matter-expert follows your register to assemble an evidence pack for a sample of obligations. If they get blocked by unclear ownership or missing artifacts, you have an operational readiness gap. (Regulation (EU) 2022/2554)