Article 64: Entry into force and application

Article 64 looks simple, but it frequently creates avoidable supervisory friction because it is the anchor for timing, accountability, and evidence. If your DORA program plan, board updates, internal audit coverage, and third-party remediation timelines do not map cleanly to DORA’s legal effective date, you end up arguing about calendars instead of demonstrating control operation.

For a CCO, Compliance Officer, or GRC lead, the practical goal is to make the “when does DORA apply?” question boring and repeatable. You do that by recording the entry-into-force date, linking it to your internal obligations register, and ensuring every DORA workstream (ICT risk, security operations, incident management, resilience testing, and third-party risk management) uses the same authoritative date reference and governance artifacts.

This page gives you requirement-level implementation guidance for the article 64: entry into force and application requirement, including who it applies to, what to do step-by-step, which evidence to retain, and what auditors tend to challenge. The regulatory basis is short and explicit. (Regulation (EU) 2022/2554, Article 64)

Regulatory text

Excerpt (verbatim): “This Regulation shall enter into force on the twentieth day following that of its publication in the Official Journal of the European Union.” (Regulation (EU) 2022/2554, Article 64)

Operator meaning: You must treat “20 days after publication” as the authoritative legal trigger for when DORA becomes effective as EU law. Your job is not to reinterpret the date. Your job is to (a) capture the date, (b) align internal governance and program milestones to it, and (c) retain evidence that your organization managed the compliance timeline intentionally. (Regulation (EU) 2022/2554, Article 64)

Plain-English interpretation

• DORA becomes legally effective shortly after publication, based on a fixed rule. (Regulation (EU) 2022/2554, Article 64)
• Article 64 itself does not list controls; it tells you when the Regulation takes legal effect. Your operational control is governance: consistent internal dating, clear ownership, and traceable execution against the compliance timeline.

Who it applies to (entity and operational context)

Applies to: Regulated entities in scope of DORA and the functions that run DORA workstreams (Compliance, Legal, ICT risk management, information security, operational resilience, procurement/third-party risk, internal audit). DORA is an EU Regulation, so once effective it applies directly in Member States without needing national transposition. (Regulation (EU) 2022/2554)

Operational contexts where Article 64 matters most:

• Program governance: defining “effective date,” “readiness checkpoints,” and escalation triggers.
• Policy lifecycle: when policies, standards, and procedures must be approved, trained, and operational.
• Third-party lifecycle: aligning contract remediation and onboarding gates to DORA-driven requirements (for example, updated ICT clauses, audit rights, and incident cooperation).
• Assurance: scoping internal audit reviews and management testing windows against the effective date.

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

Step 1: Establish the authoritative date record (single source of truth)

1. Create a DORA “Date & Applicability Memo” owned by Compliance with Legal sign-off.
2. Record:
   • publication source reference (Official Journal publication event),
   • the computed “entry into force” date rule (20 days after publication),
   • the internal “effective date” you will use consistently in program artifacts. (Regulation (EU) 2022/2554, Article 64)
3. Link the memo in your GRC tool / obligations register as the timing authority for DORA.

Practical tip: auditors dislike “tribal knowledge” dates embedded in slide decks. Put the date logic in a controlled document with version history and approvals.

Step 2: Tie Article 64 to an obligations register and control map

Build a register entry for the article 64: entry into force and application requirement that includes:

• requirement statement (verbatim excerpt),
• accountable owner (Compliance or Legal),
• impacted domains (all DORA workstreams),
• evidence list (see below),
• link to your DORA control framework mapping. (Regulation (EU) 2022/2554, Article 64)

If you use Daydream, this becomes a clean mapping node: requirement → owners → controls → evidence artifacts, so you can answer “how did you operationalize the start date?” without assembling proof ad hoc.

Step 3: Convert the date into a governance cadence and program gates

Create a simple set of gates tied to your internal effective date reference:

• Gate A: Scope confirmation (entities, branches, key services, critical functions, third parties).
• Gate B: Policy/standard approvals (ICT risk management, incident response, resilience testing, third-party oversight).
• Gate C: Evidence readiness (runbooks, reports, meeting minutes, testing results, remediation closure).
• Gate D: Assurance readiness (internal audit plan, management testing, issue tracking).

These gates are not in Article 64. They are how you operationalize it: you demonstrate that the organization governed the transition into an effective Regulation. (Regulation (EU) 2022/2554, Article 64)

Step 4: Stand up a regulatory-response workflow

Operationalize “supervisory readiness” even if you are not under active examination:

1. Define an intake channel for regulatory questions and requests (email alias or ticket queue).
2. Define escalation paths (Compliance → Legal → CIO/CISO → executive sponsor).
3. Define response SLAs (your own targets) and required approvals.
4. Maintain a log: request, owner, due date, response package, closure note.

This aligns with the practical reality that supervisors test execution through follow-up questions and document requests. Your workflow becomes evidence of control, not just process intent.

Step 5: Run readiness drills and track corrective actions

Conduct periodic “evidence assembly drills” where you simulate an examiner request:

• “Show me your DORA effective-date governance and how it drove your program plan.”
• “Show me how third-party remediation milestones align to your DORA plan.”
• “Show me your issue log and closure evidence.”

Log gaps as corrective actions with owners, due dates, and validation evidence. Keep closure proof (screenshots, approvals, test results) in a controlled repository.

Required evidence and artifacts to retain

Maintain these artifacts so you can show a clean line from Article 64 to operational execution:

Artifact	Owner	What auditors look for
DORA Date & Applicability Memo (with Legal sign-off)	Compliance / Legal	One authoritative date source and consistent definitions (Regulation (EU) 2022/2554, Article 64)
Obligations register entry for Article 64	Compliance	Traceability: requirement → owner → evidence
DORA program plan with dated milestones	Program Mgmt / GRC	Alignment of workstreams to the effective date narrative
Governance minutes (steering committee, risk committee)	GRC / Secretariat	Decisions, escalations, resourcing tied to DORA timeline
Regulatory-response procedure + request log	Compliance	Repeatable intake, approval, and response package discipline
Corrective action log (CAPA) + validation evidence	GRC / Control owners	Closure proof and management verification

Common exam/audit questions and hangups

Expect variations of:

• “What date are you using for DORA effectiveness, and where is it documented?” (Regulation (EU) 2022/2554, Article 64)
• “How did this date drive your implementation plan and governance cadence?”
• “Where is Legal sign-off that your scope interpretation and timeline are correct?”
• “Show consistency: does the date match your board reporting, internal policies, and third-party remediation plan?”
• “How do you ensure teams do not work to conflicting ‘go-live’ dates?”

Hangups typically come from inconsistency: one date in a deck, another in a policy, and a third in a project plan.

Frequent implementation mistakes and how to avoid them

1. Mistake: Treating Article 64 as a legal footnote with no control owner.
   Avoid it: assign an owner and add it to your obligations register with evidence requirements. (Regulation (EU) 2022/2554, Article 64)

2. Mistake: Confusing “entry into force” with “full operational readiness.”
   Avoid it: maintain separate language: legal effective date vs. internal readiness gates and remediation timelines.

3. Mistake: No signed record of how the date was determined.
   Avoid it: create the Date & Applicability Memo, keep it version-controlled, and require Legal approval. (Regulation (EU) 2022/2554, Article 64)

4. Mistake: Program plans that do not translate into evidence.
   Avoid it: run evidence drills and maintain an evidence inventory per workstream.

5. Mistake: Third-party timelines ignored until contract renewal.
   Avoid it: treat DORA-related third-party clauses and oversight as a remediation project with tracked exceptions and documented risk acceptance where needed.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not summarize enforcement actions.

Practical risk still exists: if you cannot show a coherent “effective date → governance → execution → evidence” chain, supervisors and auditors often reframe it as a broader governance weakness. That increases the likelihood of follow-up requests, management actions, and expanded testing scope.

Practical 30/60/90-day execution plan

First 30 days (foundation and consistency)

• Publish the DORA Date & Applicability Memo with Legal sign-off. (Regulation (EU) 2022/2554, Article 64)
• Update your obligations register with the article 64: entry into force and application requirement, named owner, and evidence list.
• Standardize the date reference across program plans, steering decks, and policy drafting templates.
• Stand up the regulatory-response workflow and logging.

Days 31–60 (make it operational and provable)

• Build the DORA control-to-evidence mapping for major workstreams (ICT risk, security ops, incident management, resilience testing, third-party risk).
• Run a readiness drill focused on date governance: assemble the “Article 64 evidence pack” in a single folder and test retrieval time.
• Create a corrective action log for gaps found and assign owners.

Days 61–90 (assurance readiness)

• Schedule internal audit or second-line testing of the governance artifacts: memo, register entry, program plan alignment, and request workflow.
• Close high-priority corrective actions and capture validation evidence.
• Prepare a supervisor-ready narrative: one page explaining the date, governance gates, and where evidence is stored.

Daydream fit: use Daydream to keep the requirement mapping, ownership, and evidence inventory in one register so teams stop chasing dates across decks, emails, and disconnected trackers.

Frequently Asked Questions

What is the difference between “entry into force” and “application” for DORA?

Article 64 specifies when the Regulation enters into force: 20 days after publication in the Official Journal. (Regulation (EU) 2022/2554, Article 64) If you need the separate “application” date used in other DORA provisions, confirm it in the full Regulation text and document your interpretation in your Legal memo. (Regulation (EU) 2022/2554)

Do I need a control for Article 64 even though it’s just a date?

Yes. The control is governance: documenting the authoritative date, aligning milestones to it, and retaining evidence that the organization managed the transition intentionally. (Regulation (EU) 2022/2554, Article 64)

Who should own Article 64 in the obligations register?

Assign primary ownership to Compliance or Legal, with shared accountability across ICT risk, security, and third-party risk for execution artifacts. The key is a single accountable owner who can produce the evidence pack on demand.

What evidence is “enough” for auditors?

Keep a signed Date & Applicability Memo, the obligations register entry, and a program plan that clearly references the effective date. (Regulation (EU) 2022/2554, Article 64) Add governance minutes and a request log to prove the process operates under pressure.

We are mid-implementation and different teams cite different dates. How do we fix this fast?

Freeze a single authoritative date reference in the Legal/Compliance memo and publish it as the required citation for all DORA artifacts. Then update the program plan, steering templates, and policy headers to use that same reference.

Does Article 64 change our third-party contract approach?

Indirectly. Article 64 anchors when DORA is legally effective, so it drives when your DORA-aligned third-party remediation plan must be governed, tracked, and evidenced. (Regulation (EU) 2022/2554, Article 64)