What is the difference between DORA and data security controls that only protect data at rest?

Why This Matters for Security Teams

DORA changes the question from "is the data encrypted on disk?" to "can the financial service keep operating safely when systems, providers, or processes fail?" That matters because resilience obligations sit across governance, incident handling, testing, and ICT third-party risk, not just storage protection. A control set focused only on data at rest can still leave organisations exposed during live processing, backup restore, API exchange, privileged access abuse, or a provider outage. The relevant regulatory lens is closer to DORA — Digital Operational Resilience Act than to a narrow encryption checklist.

Security teams often get misled by control language that sounds comprehensive while covering only one state of data. Encryption at rest is important, but it does not address availability, integrity under active use, or the operational impact of outsourced services. Under DORA, the failure mode is not simply data exposure; it is the inability to deliver critical functions within tolerable disruption. In practice, many security teams encounter DORA shortcomings only after a third-party incident or restore failure has already disrupted business operations, rather than through intentional resilience testing.

How It Works in Practice

DORA is built around operational resilience, so the practical implementation model needs to span people, processes, technology, and suppliers. A useful way to think about it is to map each critical business service to the systems, identities, interfaces, and dependencies that keep it running. That includes encryption, but also backup integrity, recovery objectives, authentication paths, logging, monitoring, failover, and exit planning for ICT providers. The NIST Cybersecurity Framework 2.0 is helpful here because it frames outcomes across governance, protect, detect, respond, and recover.

Controls that only protect data at rest usually stop at one layer of the stack. DORA-aligned control design has to ask where data is exposed in transit and in use, who can access it, how incidents are detected, and whether a service can be restored without compromising integrity. A practical programme usually includes:

• Classification of critical or important functions and the systems that support them
• Encryption for data at rest, in transit, and where justified for sensitive data in use
• Access control, privileged access reviews, and strong identity governance for operators and vendors
• Logging, alerting, and incident escalation tied to regulatory reporting timelines
• Recovery testing, backup validation, and resilience exercises that include third parties
• Contractual oversight of ICT providers, including audit rights and exit provisions

For control depth, practitioners often cross-map to NIST SP 800-53 Rev 5 Security and Privacy Controls or the CSA Cloud Controls Matrix when cloud outsourcing is part of the operating model. These references help translate resilience obligations into implementable controls without reducing the problem to storage encryption alone. These controls tend to break down when critical services depend on opaque outsourcing chains because the organisation cannot evidence recovery, oversight, or effective incident response end to end.

Common Variations and Edge Cases

Tighter data protection often increases operational overhead, requiring organisations to balance confidentiality goals against recovery speed, service continuity, and third-party complexity. That tradeoff becomes visible when teams add stronger encryption, tokenisation, or segmentation without also adjusting monitoring, restore testing, and runbook quality.

There is no universal standard that says encrypted data at rest is enough for resilience, and current guidance suggests the opposite for regulated financial services. A payment platform may have strong disk encryption but still fail DORA expectations if key services rely on a managed provider that cannot support timely recovery or if privileged administrator access is not controlled during incident response. In cloud-native environments, the distinction between data at rest and data in use becomes even more important because customer data may pass through APIs, managed services, and ephemeral compute that leave little room for static-only controls.

Another edge case is where a programme treats DORA as a compliance documentation exercise. That approach tends to produce policies that look complete but do not improve operational survivability. The better question is whether the control set can prove continuity during a real outage, cyber incident, or supplier failure. If it cannot, then the organisation has data protection, but not resilience.

Related resources from NHI Mgmt Group

• What is the difference between summarising security data and prioritising security risk?
• What is the difference between model security and agent identity controls?
• What is the difference between IAM controls and session security?
• What is the difference between API security and traditional IAM controls?