Article 12: Backup policies and procedures, restoration and recovery procedures and methods

Article 12 requires you to document and operate backup, restoration, and recovery procedures that can restore ICT systems and data with minimal downtime, disruption, and loss, as part of your ICT risk management framework (Regulation (EU) 2022/2554, Article 12). Operationalize it by defining backup scope and methods, setting recovery objectives, testing restores, and retaining evidence that proves recoverability.

Key takeaways:

• You need documented backup and recovery procedures that are demonstrably executable, not just policy statements (Regulation (EU) 2022/2554, Article 12).
• Testing is the control: backups without periodic restoration validation fail supervisory scrutiny in practice.
• Evidence must show coverage, success/failure, remediation, and accountable ownership across production and critical third-party services.

“Backups” under DORA are not a storage activity. Article 12 is a resilience requirement: you must be able to restore systems and data with minimum downtime, limited disruption, and limited loss, and you must be able to prove it with documentation and operational records (Regulation (EU) 2022/2554, Article 12). For a CCO, GRC lead, or Compliance Officer, the fastest path is to treat this as a recoverability control with three deliverables: (1) documented procedures, (2) tested restoration results, and (3) governance and evidence that ties those results to business impact and risk acceptance.

This page focuses on requirement-level implementation. It assumes you already have some backup tooling; the gap is usually in scope clarity, restoration runbooks, testing discipline, and evidence packaging. You will leave with a step-by-step implementation sequence, an audit-ready evidence list, and a practical execution plan that you can assign to IT operations, security, application owners, and third-party managers without rewriting the entire ICT risk program.

Target keyword: article 12: backup policies and procedures, restoration and recovery procedures and methods requirement

Regulatory text

DORA Article 12 excerpt (provided): “For the purpose of ensuring the restoration of ICT systems and data with minimum downtime, limited disruption and loss, as part of their ICT risk management framework, financial entities shall develop and document:” (Regulation (EU) 2022/2554, Article 12)

What the operator must do from this text

• Develop and document backup policies/procedures and restoration/recovery procedures/methods that support restoration with minimal downtime, disruption, and loss (Regulation (EU) 2022/2554, Article 12).
• Embed it in the ICT risk management framework. This is not a standalone IT document; it must connect to risk ownership, criticality, and control operation (Regulation (EU) 2022/2554, Article 12).

Because the provided excerpt is partial, treat Article 12 as a minimum baseline: you must be able to (a) restore, (b) do it fast enough for your business, and (c) demonstrate it through documented methods and records (Regulation (EU) 2022/2554, Article 12).

Plain-English interpretation (what supervisors expect to see)

• You can clearly answer: “If system X fails or data is corrupted, how do we restore it, how long will it take, how much data could we lose, and who executes the steps?”
• Your backup approach matches risk: critical services have tighter recovery expectations and more rigorous testing than non-critical services.
• You have repeatable procedures (runbooks), not heroic recovery.
• You can prove “minimum downtime” is engineered through defined recovery targets, architecture choices (replication, immutable backups, offline copies where appropriate), and practiced execution (Regulation (EU) 2022/2554, Article 12).

Who it applies to (entity and operational context)

Applies to: financial entities in scope of DORA that operate ICT systems and data needing restoration capability (Regulation (EU) 2022/2554, Article 12).

Operational contexts in scope

• Core production systems supporting critical or important functions (payments, trading, policy admin, customer onboarding, risk systems).
• Data stores: databases, object storage, file shares, SaaS data, logs needed for security/operations, configuration repositories.
• End-user productivity and identity dependencies if required to restore operations (IdP, directory services, privileged access tooling).
• Third-party provided services where recovery depends on the third party (cloud platforms, SaaS, managed service providers). You still need procedures and evidence: shared responsibility is not shared accountability.

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

Use this as an implementation sequence you can assign tomorrow.

1) Set scope and ownership (control design)

1. Create a recoverability inventory: list ICT services/systems, data sets, and dependencies that must be recoverable.
2. Assign accountable owners:
   • Business owner (impact and acceptable downtime/data loss)
   • Technical owner (backup and restore execution)
   • Control owner (GRC/IRM who ensures policy, testing, and evidence)
3. Tier the inventory by business criticality to decide testing rigor and restoration priority.

Artifact: Recoverability scope register (system, data, tier, owners, dependencies).

2) Define recovery objectives and minimum acceptable outcomes

Translate “minimum downtime, limited disruption and loss” into internal targets:

• Recovery time objective (RTO) per system/service tier.
• Recovery point objective (RPO) per data set/tier.
• Minimum service level during recovery (degraded mode expectations, manual workarounds).

Operator tip: If you can’t set RTO/RPO because the business won’t commit, treat that as a governance issue and record risk acceptance with an expiry date and escalation path.

Artifacts: RTO/RPO matrix; documented approvals; exceptions register.

3) Document backup policies and procedures (the “what” and the “how”)

Write procedures that an on-call team can execute under pressure:

• Backup coverage rules: what is backed up (systems, data types, configs, keys where applicable), what is excluded, and why.
• Backup methods: full/incremental, snapshots, replication, immutability, offline/air-gapped approach where applicable.
• Security controls: encryption, access controls, separation of duties, privileged access, logging.
• Retention rules: operational retention vs legal hold vs forensic needs.
• Monitoring and alerting: backup job failures, storage capacity thresholds, restore readiness signals.

Artifacts: Backup policy; backup runbooks; architecture diagrams for backup flows.

4) Document restoration and recovery procedures (runbooks you can execute)

For each critical tier and common platform pattern (database, VM, Kubernetes, SaaS):

• Trigger criteria: corruption, ransomware suspicion, availability outage, accidental deletion.
• Decision tree: restore point selection, failover vs restore, data integrity validation.
• Step-by-step runbook: commands/console steps, required access, prerequisites, dependencies.
• Validation steps: application checks, data reconciliation, security checks, customer-impact signoff.
• Communication plan hooks: incident management integration, stakeholder updates.

Artifacts: Restoration runbooks; decision trees; dependency maps.

5) Test restores and capture results (control operation)

A backup that has not been restored is an assumption. Build a test program:

• Planned restoration tests for representative systems in each tier.
• Scenario tests: partial data restore, point-in-time recovery, full environment rebuild, restore after suspected malware.
• Evidence capture: test plan, execution logs, timings, success criteria, issues found, remediation tickets, retest proof.

What auditors look for: proof that restoration is feasible and repeatable, and that failures drive corrective action.

Artifacts: Test calendar; test reports; tickets; post-test signoffs.

6) Third-party alignment (where recovery depends on someone else)

For each critical third party:

• Confirm who performs backups, what data is covered, and how restores are requested/executed.
• Obtain evidence: service descriptions, backup/restore commitments, incident and DR support processes, and relevant assurance reports where available.
• Document your internal runbook for invoking third-party recovery, including escalation and approvals.

Artifacts: Third-party recovery procedure; contract/SLA excerpts; assurance documents; escalation contacts list.

7) Package supervisory evidence in a single register (make exams survivable)

Create a mapping that links:

• Article 12 requirement language → internal controls → systems in scope → test evidence → open issues and remediation.

Daydream (or any GRC system) becomes useful here because the pain is traceability: you need one place that shows ownership, evidence, and remediation closure without chasing screenshots across teams.

Artifacts: Control-to-evidence mapping register; regulatory request response workflow.

Required evidence and artifacts to retain (audit-ready checklist)

Keep these in a controlled repository with versioning and access logs:

• Approved backup policy and restoration/recovery policy (with effective date, scope, owners).
• System/data recoverability inventory with tiering and dependencies.
• RTO/RPO matrix, approvals, and exception/risk acceptance records.
• Platform/application backup configurations (exported settings), job schedules, encryption settings.
• Backup job logs and monitoring alerts (success/fail history) and capacity reports.
• Restoration test plans and reports, including validation evidence and signoffs.
• Remediation records: tickets, root cause, compensating controls, retest results.
• Third-party evidence supporting recoverability where outsourced, plus internal invocation runbooks.
• Board/management reporting excerpts showing oversight where your governance model requires it.

Common exam/audit questions and hangups

Use these as your pre-audit readiness script.

Examiner question	What they’re probing	What to show
“Which systems and data are covered by backups?”	Scope completeness	Recoverability inventory + exclusions with rationale
“How do you know you can restore?”	Operational effectiveness	Restore test reports + logs + remediation closure
“Who is accountable for recovery outcomes?”	Governance	RACI, on-call ownership, approvals, escalation paths
“How do third parties fit into recovery?”	Shared responsibility gaps	Contract/SLA excerpts + third-party invocation runbooks
“What happens if backups are compromised?”	Ransomware resilience	Immutability/offline approach + access controls + monitoring

Typical hangup: teams provide backup job success reports but cannot produce a recent, successful restore for a critical system. Fix this by making restoration testing a scheduled control with tracked outcomes.

Frequent implementation mistakes and how to avoid them

1. Mistake: treating backups as a storage KPI.
   Avoid it: make “restored to a validated state” the success criterion, not “backup job succeeded.”

2. Mistake: RTO/RPO exist on paper but are not engineered.
   Avoid it: tie each tier’s RTO/RPO to specific methods (replication, snapshots, rebuild automation) and test against them.

3. Mistake: no clean ownership for SaaS recovery.
   Avoid it: document who initiates restores, expected timelines, and escalation routes with the third party.

4. Mistake: evidence scattered across tools.
   Avoid it: maintain a single evidence map for Article 12 with links to logs, tests, and tickets. Daydream-style control registers reduce scramble time during supervisory requests.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite specific actions. Practically, Article 12 failures show up as:

• Extended outages because restoration steps are unclear or untested.
• Data loss beyond what the business expected because RPO assumptions were wrong.
• Ransomware impacts worsening because backups are reachable, encrypted by attackers, or restores are too slow to meet service needs.

For compliance, the core risk is defensibility: you must demonstrate that backup and recovery are designed, operated, tested, and governed as part of ICT risk management (Regulation (EU) 2022/2554, Article 12).

A practical 30/60/90-day execution plan

Numeric timelines below are planning phases, not performance claims.

First 30 days (stabilize and map)

• Stand up the recoverability inventory and assign owners.
• Document current-state backup coverage and identify obvious gaps (missing systems, unknown SaaS backup status).
• Draft or update the backup policy and restoration runbook template.
• Create the Article 12 control-to-evidence register (even if it starts as a spreadsheet).

Next 60 days (operationalize and test)

• Finalize RTO/RPO targets per tier with business signoff; record exceptions.
• Publish runbooks for top-tier systems and one representative system per platform.
• Execute initial restoration tests for critical tiers; open remediation tickets for failures.
• Validate third-party recovery paths for critical outsourced services; document invocation procedures.

By 90 days (prove and institutionalize)

• Complete a test cycle that covers critical tiers and demonstrates restore validation.
• Close high-risk remediation items or document compensating controls with risk acceptance.
• Implement recurring reporting: restore test outcomes, backup failure trends, exception aging.
• Run an internal “supervisory evidence drill”: produce the full Article 12 evidence pack on request, with consistent naming and version control.

Frequently Asked Questions

Do we need separate documents for backup policy and restoration procedures?

Article 12 requires that you “develop and document” what you do to restore systems and data (Regulation (EU) 2022/2554, Article 12). You can combine documents, but keep backup rules distinct from step-by-step restoration runbooks so operators can execute quickly.

Are backups enough if we have high availability and replication?

Replication helps availability, but it can replicate corruption or malicious changes. Keep documented recovery methods that allow point-in-time restoration and validate them through restore testing (Regulation (EU) 2022/2554, Article 12).

How do we handle SaaS where the provider controls backups?

Document your procedure to invoke provider restore options, including roles, approvals, and escalation contacts, and retain the provider’s service commitments and assurance materials. Your obligation is to ensure restorability outcomes within your ICT risk management framework (Regulation (EU) 2022/2554, Article 12).

What evidence is most persuasive in an exam?

Recent restoration test reports with clear scope, timings, validation steps, and remediation closure are usually stronger than policy text alone. Pair them with your recoverability inventory and an evidence map that links artifacts to Article 12 (Regulation (EU) 2022/2554, Article 12).

Can we rely on daily backup success emails as proof?

They help, but they only show backup job execution. Add restore validation evidence, plus issue tracking and retest results for failures, to demonstrate that restoration works under real conditions (Regulation (EU) 2022/2554, Article 12).

How do we operationalize this across many systems without boiling the ocean?

Tier systems by criticality, standardize runbook templates by platform, and test representative systems first. Use a single control register (Daydream or equivalent) to track scope, evidence, and remediation without losing traceability.