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

Restoration of Availability

Also known as: Availability Restoration, Restoration of Access to Data
Simply put

Restoration of availability refers to the ability to bring systems and data back into a usable, accessible state after a failure, outage, or disaster. It is a reactive capability, meaning it is concerned with recovering normal operations as quickly as possible once something has gone wrong, rather than preventing the disruption in the first place. In practice it typically relies on measures such as backups, failover processes, and documented disaster recovery procedures.

Formal definition

Restoration of availability is the capacity to recover access to systems, services, and data and return them to normal operating conditions following an incident such as an outage, hardware failure, or disaster. It is generally distinguished from high availability, which is preventive and aims to avoid downtime, whereas restoration is a reactive disaster recovery function that seeks to restore operations within defined durability and service objectives; in cloud contexts this may be handled through platform-level failover and repair processes, sometimes managed by the provider without customer action. In data protection practice, the concept aligns with the security principle that appropriate technical and organisational measures should enable the timely restoration of availability of and access to personal data in the event of a physical or technical incident; readers should verify the precise wording and any relevant article references against the current official GDPR text, as the sources in this evidence packet address the concept from an IT resilience and business continuity perspective rather than the Regulation itself.

Why it matters

When systems or data become unavailable due to an outage, hardware failure, or disaster, the consequences can extend well beyond inconvenience. In a data protection context, availability is a recognised dimension of information security alongside confidentiality and integrity, and the ability to restore access to personal data in a timely manner after a physical or technical incident is generally treated as part of the appropriate technical and organisational measures expected under the GDPR's security principle. Readers should verify the precise wording and any relevant article references against the current official GDPR text, as the underlying sources here approach the concept from an IT resilience and business continuity perspective rather than from the Regulation itself.

Restoration of availability matters because it is fundamentally reactive: it is what an organisation relies on once prevention has failed. Business continuity is generally described as the state in which a business can continue operations during failures, outages, or disasters, and disaster recovery is typically the reactive process intended to restore normal operations as quickly as possible. Without documented recovery procedures, tested backups, and clear objectives for how quickly and how completely data must be recovered, an organisation may struggle to demonstrate that it has taken adequate account of the risk of accidental or unlawful loss of personal data.

The practical stakes vary by context and should be assessed case by case. In some cloud arrangements, restoration may be handled at the platform level by the provider without customer action, while in others the customer retains significant responsibility for backups and recovery. Understanding where that boundary falls is important both for operational resilience and for allocating responsibilities between parties, though the specific division depends on the service model and contractual terms in place.

Who it's relevant to

Data Protection Officers and Compliance Leads
Restoration of availability is relevant to demonstrating that appropriate technical and organisational measures address the availability of personal data, not only its confidentiality. DPOs and compliance leads should be able to point to recovery capabilities and documented procedures as part of an overall security and accountability posture, while verifying the applicable GDPR wording and article references against the current official text.
IT Resilience and Business Continuity Teams
Teams responsible for business continuity and disaster recovery own the practical mechanics of restoration, including backups, failover, and documented recovery procedures. They typically distinguish reactive disaster recovery from preventive high availability and set recovery objectives that describe how quickly and how completely systems and data should be restored after an incident.
Engineers and Cloud Architects
Engineers designing systems, particularly in cloud environments, need to understand which restoration functions are handled at the platform level by a provider and which remain the customer's responsibility. This boundary depends on the service model and contractual terms, and clarifying it is important for both operational resilience and correct allocation of responsibilities.
Legal and Contracting Teams
Those negotiating service arrangements should understand how restoration responsibilities and recovery commitments are allocated between parties, since some providers manage restoration without customer action while other configurations leave recovery with the customer. Accurately capturing these responsibilities supports both resilience and clear accountability, subject to the specific terms in place.

Inside Restoration of Availability

Timely Restoration Obligation
Article 32(1)(c) of the GDPR requires controllers and processors to have the ability to restore the availability of and access to personal data in a timely manner in the event of a physical or technical incident. The Regulation does not fix a specific recovery time; timeliness is assessed by reference to the risk to the rights and freedoms of data subjects and the nature of the processing.
Availability as a Security Property
Availability is one of the security objectives referenced in Article 32, alongside confidentiality, integrity and resilience. In this context it concerns ensuring that authorised access to personal data can be re-established after disruption, rather than preventing unauthorised access.
Physical or Technical Incident
The trigger for restoration is a physical or technical incident, which may include events such as hardware failure, system outages, or accidental loss of access. The Regulation uses broad wording and does not enumerate an exhaustive list of qualifying incidents; assessment is context dependent.
Relationship to Resilience
Restoration of availability is closely linked to, but distinct from, the resilience of processing systems and services also named in Article 32. Resilience concerns the systems' ability to withstand and continue operating through adverse conditions, whereas restoration concerns re-establishing access once availability has been lost.
Risk-Based Calibration
Article 32 frames appropriate measures by reference to the state of the art, costs of implementation, and the nature, scope, context and purposes of processing, as well as the risk to individuals. What counts as adequate restoration capability therefore varies with the sensitivity and volume of the personal data and the potential impact of unavailability.
Controller and Processor Responsibility
Both controllers and processors are addressed by Article 32. Where a processor handles restoration on a controller's behalf, the allocation of responsibilities is generally reflected in the Article 28 processing arrangement, though the specific terms depend on the contract and the parties' roles.

Common questions

Answers to the questions practitioners most commonly ask about Restoration of Availability.

Is restoration of availability the same as having good backups?
Not exactly. Backups are one component that supports restoration of availability, but the concept under GDPR (referenced in Article 32(1)(c)) concerns the broader ability to restore access to personal data in a timely manner following a physical or technical incident. Restoration typically depends not only on the existence of backups but also on tested recovery procedures, defined recovery objectives, and operational readiness. Backups that are never tested, incomplete, or unrecoverable may not, by themselves, satisfy the ability to restore availability. The two concepts are related but should not be treated as interchangeable.
Does restoring availability quickly mean an organisation avoids its breach notification obligations?
Generally, no. Rapid restoration of availability does not automatically remove notification duties. A loss of availability can itself constitute a personal data breach under the GDPR's definition, and whether notification to a supervisory authority or affected individuals is required depends on a separate risk assessment. Restoring access swiftly may reduce the risk to individuals and can be a relevant factor in that assessment, but it does not, in most cases, function as a blanket exemption. Organisations should assess each incident on its facts and against current regulatory guidance, which can vary between authorities.
How should recovery time and recovery point objectives be set for personal data?
Recovery objectives are typically set through a risk-based assessment that considers the sensitivity of the personal data, the potential impact on individuals if the data is unavailable, and the operational role of the affected systems. There is no single figure mandated by the GDPR; the standard is generally one of appropriateness to the risk under Article 32. Objectives for systems processing special category data or supporting essential services are often more stringent. Organisations should document the rationale for the objectives they set and revisit them as processing activities change.
How often should restoration capabilities be tested?
GDPR does not prescribe a specific testing frequency. Article 32(1)(d) refers to a process for regularly testing, assessing, and evaluating the effectiveness of security measures, which is generally understood to include restoration processes. In practice, testing frequency is typically calibrated to the risk profile of the processing, the rate of system change, and the criticality of the data. Testing may range from periodic full recovery exercises to more frequent partial or automated checks. Results should generally be documented to demonstrate accountability, and untested restoration procedures may not be considered reliable.
Who is responsible for restoration of availability when a processor hosts the data?
The controller remains accountable for ensuring appropriate measures are in place, but responsibility for the technical restoration is typically shared with the processor and should be defined in the data processing agreement under Article 28. That agreement generally specifies the processor's security obligations, including measures relevant to availability and recovery, and its duty to assist the controller. Where multiple processors or sub-processors are involved, the allocation of restoration responsibilities should be clearly documented across the chain. The precise division depends on the contractual terms and the nature of the service.
What documentation supports demonstrating restoration of availability?
Relevant documentation typically includes recovery procedures, defined recovery objectives, records of testing and their outcomes, incident and recovery logs, and any relevant provisions in processor agreements. Such records support the accountability principle and can help demonstrate that appropriate measures under Article 32 were considered and implemented. The specific documentation expected can vary with the organisation's size, the nature of its processing, and the expectations of the relevant supervisory authority, so organisations should align their records with current regulatory guidance.

Common misconceptions

The GDPR sets a specific maximum recovery time for restoring availability.
Article 32(1)(c) requires restoration in a timely manner but does not prescribe a numeric recovery time objective. Timeliness is assessed against the risk to data subjects and the circumstances of the processing; readers should verify any specific timing expectations against sector guidance and their own risk assessment.
Restoration of availability and resilience are the same requirement.
Although both appear in Article 32, resilience typically refers to systems continuing to function through adverse conditions, while restoration refers to re-establishing access to personal data after an incident has caused a loss of availability. They are complementary but distinct objectives.
Meeting the restoration requirement guarantees a data availability incident will not need to be handled as a breach.
Availability loss can itself constitute a personal data breach, and the existence of restoration capability does not, on its own, remove any applicable notification or documentation obligations. Whether a given incident triggers such obligations depends on a separate assessment; practitioners should not treat restoration measures as making an event out of scope for breach handling.

Best practices

Document backup and recovery arrangements as part of your Article 32 security measures, and record how they map to the timely restoration obligation.
Calibrate restoration capability to the risk profile of the processing, giving greater priority and shorter targeted recovery timeframes to higher-risk or special category data where justified by assessment.
Test restoration procedures periodically rather than assuming backups will restore successfully, and retain evidence of these tests to support your accountability position.
Clarify in the Article 28 processing arrangement which party is responsible for restoration activities where a processor is involved, and confirm the practical division of tasks.
Treat availability incidents through your breach assessment process, since loss of availability may itself amount to a personal data breach and should be evaluated for any resulting obligations.
Review restoration targets and measures against current regulatory guidance and the official Regulation text, as expectations on what is timely and appropriate can evolve.