Skip to main content
Privacy Track
Category: Security & Breach Notification

Ability to Restore Availability and Access

Also known as: Ability to Restore the Availability and Access to Personal Data, Restoration of Availability and Access
Simply put

This is a security requirement that organisations be able to bring personal data back online and make it accessible again in a timely way after something goes wrong, such as a system failure, outage, or physical damage. In practice it typically means having recovery measures like backups and a plan to get systems working again. It is one of several security capabilities expected when handling personal data.

Formal definition

One of the technical and organisational measures identified in Article 32 GDPR (security of processing), requiring controllers and processors, as appropriate and subject to a risk-based assessment, to be able to restore the availability of and access to personal data in a timely manner following a physical or technical incident. This capability is generally supported by recovery-oriented controls such as backup regimes, resilience arrangements, and incident response and recovery processes, and per ICO guidance it forms part of demonstrating appropriate security. The Regulation does not prescribe specific technologies or fixed recovery timeframes; what is 'appropriate' and 'timely' depends on factors including the state of the art, costs of implementation, and the nature, scope, context, and purposes of processing, as well as the risks to individuals. The evidence here does not address the equivalent UK GDPR position in detail beyond ICO guidance, and readers should verify the current Article 32 text and applicable guidance.

Why it matters

The ability to restore the availability of and access to personal data is one of the security capabilities expressly identified in Article 32 GDPR, and it addresses a scenario that most organisations will face at some point: personal data becoming unavailable following a physical or technical incident such as a system failure, outage, or physical damage. Where individuals depend on an organisation to hold and process their data, an inability to recover that data in a timely way can itself constitute a security failing and, depending on the circumstances, may have consequences for the people whose data is affected.

This requirement reflects the GDPR's treatment of security as extending beyond confidentiality to include availability and resilience. A breach under the Regulation is not limited to unauthorised disclosure; it can also involve accidental loss of access to personal data. Demonstrating that recovery measures are in place is therefore part of showing appropriate security and, per ICO guidance, part of demonstrating accountability. What counts as 'timely' and 'appropriate' is not fixed by the Regulation and depends on a risk-based assessment, so organisations should document their reasoning rather than assume any single standard applies universally.

The boundary of this concept is important: Article 32 does not prescribe specific technologies or fixed recovery timeframes, and the evidence here does not detail equivalent positions beyond ICO guidance. Readers should verify the current Article 32 text and applicable regulatory guidance, and recognise that expectations may vary with the nature, scope, context, and purposes of the processing and the risks to individuals.

Who it's relevant to

Data controllers
Controllers are responsible under Article 32 for implementing appropriate technical and organisational measures, which include the ability to restore availability and access to personal data. They typically need to assess what recovery capability is appropriate to their processing and risks, and to be able to demonstrate that reasoning as part of accountability.
Data processors
Article 32 applies to processors as well as controllers. Where a processor holds or handles personal data on a controller's behalf, it is generally expected to maintain recovery-oriented controls appropriate to the risk, and these expectations are commonly reflected in the arrangements between the parties.
Compliance and data protection officers
DPOs and compliance leads are often involved in evaluating whether recovery measures are appropriate, ensuring the risk-based assessment is documented, and confirming that the organisation can evidence its security posture in line with ICO guidance on demonstrating appropriate security.
IT, security, and engineering teams
Technical teams typically design, operate, and test the backup, resilience, and incident response and recovery processes that support this capability. They are usually best placed to translate a 'timely' recovery objective into concrete measures, subject to the organisation's risk assessment, and to help verify that those measures function when needed.

Inside Ability to Restore Availability and Access

Restoration of Availability
The capability to bring personal data and the systems that process it back to an accessible state following a physical or technical incident. This is one of the security measures referenced in GDPR Article 32(1)(c), which requires the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident.
Timeliness Requirement
Article 32 frames restoration in terms of timeliness rather than a fixed deadline. What counts as timely is generally assessed against the nature, scope, context and purposes of processing and the risk to individuals, so the expected recovery window is context and risk dependent rather than a single prescribed period.
Backup and Recovery Processes
The operational mechanisms, such as data backups and recovery procedures, that make restoration possible. Article 32 does not prescribe a specific technical solution; it sets an outcome (the ability to restore) and leaves the choice of measures to be determined through assessment of appropriateness and risk.
Regular Testing and Evaluation
Article 32(1)(d) calls for a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures. Applied to restoration, this means the ability to restore should itself be tested rather than assumed to work.
Scope Boundary
This obligation concerns the security of processing of personal data. It does not, by itself, govern anonymous data, and its restoration duty sits within the broader security principle (integrity and confidentiality) under Article 5(1)(f). It is distinct from breach notification duties, which are addressed separately in the Regulation.

Common questions

Answers to the questions practitioners most commonly ask about Ability to Restore Availability and Access.

Does the ability to restore availability and access mean simply having data backups in place?
Not on its own. Restoring availability and access is a functional capability, not merely the existence of backups. Backups are a common component, but the requirement generally concerns the demonstrable ability to bring personal data and the systems that process it back into a usable state within an appropriate timeframe. Backups that cannot be reliably restored, or that are untested, would not typically satisfy this. The concept is broader than storage and encompasses recovery processes, procedures, and their effectiveness.
Is this the same thing as the personal data breach notification obligation?
No. These are distinct concepts, though they can be related in practice. The ability to restore availability and access is a security capability addressing resilience and recovery of systems and data. Breach notification concerns obligations that arise once a personal data breach has occurred. A loss of availability can itself constitute a breach in some circumstances, but the capability to restore is a preventive and remedial security measure rather than a notification duty. Readers should treat the two as separate requirements that may intersect.
How can an organisation demonstrate that this capability actually exists rather than exists only on paper?
Demonstration typically rests on evidence that recovery processes have been exercised, not merely documented. This can include records of restore tests, recovery time observations, documented recovery procedures, and logs showing successful recovery from defined scenarios. What is appropriate is generally assessed against the nature, scope, context, and risk of the processing, so expectations will vary. Organisations should verify their evidence approach against current regulator guidance, as expectations regarding testing and documentation can evolve.
How often should restore capabilities be tested?
There is no single prescribed frequency stated in the Regulation text. Testing cadence is generally determined on a risk basis, taking into account the sensitivity of the data, the criticality of the systems, and the potential impact of unavailability. In most cases, more frequent or more rigorous testing is expected for higher-risk processing. Because this is a matter of assessment rather than a fixed rule, organisations should document the rationale for their chosen frequency and revisit it as risks change.
How does responsibility for restoration split between a controller and a processor?
Both may have obligations, but their positions differ. A controller remains generally accountable for ensuring appropriate security measures across its processing, while a processor is typically bound by contractual terms addressing security and assistance. Where a processor operates systems that hold personal data, the allocation of restoration responsibilities should be set out in the processing arrangement between the parties. Organisations should confirm how recovery duties are apportioned in their specific contracts rather than assuming a default position.
Should recovery timeframes be defined in advance, and how strict do they need to be?
Defining target recovery timeframes in advance is generally advisable because it allows the capability to be measured and tested. However, appropriate timeframes are context-dependent and should reflect the risk to individuals from unavailability of their data. Stricter targets are typically warranted where prolonged unavailability could cause significant harm. Because appropriateness is assessed against risk rather than a universal standard, organisations should document their reasoning and avoid treating any single target as inherently compliant.

Common misconceptions

GDPR sets a specific maximum time within which personal data must be restored.
The Regulation uses the qualitative standard of restoring availability and access in a timely manner (Article 32(1)(c)) and does not, in its text, specify a fixed number of hours or days. The appropriate recovery time is determined by risk assessment and may vary; readers should verify the current official text rather than assume a numeric deadline.
Having backups is enough to satisfy this requirement.
The obligation is the ability to restore, not merely to store copies. Article 32(1)(d) also expects regular testing and evaluation of the effectiveness of measures, so untested backups may not, on their own, demonstrate that restoration can be achieved in a timely manner.
This is solely a technical, IT concern separate from data protection compliance.
Restoration of availability and access is expressly a security-of-processing measure under Article 32 and supports the integrity and confidentiality principle in Article 5(1)(f). It typically involves both technical and organisational measures and is generally treated as a shared responsibility across security, engineering, and compliance functions.

Best practices

Implement documented backup and recovery procedures for systems processing personal data, and define expected recovery objectives based on a risk assessment rather than assuming a single fixed target.
Regularly test restoration in line with Article 32(1)(d), verifying that data and access can actually be recovered rather than relying on the existence of backups alone.
Assess timeliness in context, considering the nature, scope, context and purposes of processing and the risk to individuals when determining what an acceptable recovery window looks like.
Record the technical and organisational measures adopted and the reasoning behind them, so the appropriateness of the chosen approach can be demonstrated on an accountability basis.
Treat restoration as a cross-functional responsibility, coordinating between engineering, security, and compliance teams rather than isolating it as a purely technical task.
Review and re-evaluate restoration measures periodically and after significant incidents or changes in processing, and verify obligations against the current official text where precise requirements matter.