What does control A.3.24 require?
Backup copies of PII, and software and systems related to PII processing shall be maintained and regularly tested.
This control sits within the Shared security controls annex (A.3) and addresses the availability dimension of PII protection. While many privacy controls focus on preventing unauthorised access or disclosure, A.3.24 ensures that PII can be recovered and restored when systems fail. Without tested backups, a ransomware attack, hardware failure or natural disaster could result in permanent loss of personal data.
What does the Annex B implementation guidance say?
Annex B (section B.3.24) provides extensive guidance:
- Backup and erasure policy — The organisation should have a policy addressing backup, recovery and restoration of PII, including any contractual or legal requirements for the erasure of PII contained in backup data
- Customer communication — PII-specific backup responsibilities can depend on the customer. The organisation should ensure customers are informed of the limits of the service regarding backup
- Backup service transparency — Where backup and restore services are explicitly provided to customers, the organisation should provide clear information about its capabilities
- Jurisdictional requirements — Some jurisdictions impose specific requirements regarding backup frequency, review and test frequency, or recovery procedures for PII. Organisations operating in these jurisdictions must demonstrate compliance
- PII restoration integrity — When PII is restored from backup, processes must ensure the PII is restored to a state where integrity can be assured, or where inaccuracy or incompleteness is identified and resolved (which may involve the PII principal)
- Restoration logging — The organisation should maintain a procedure and log for PII restoration efforts, recording at minimum the name of the responsible person and a description of the restored PII
- Subcontractor backups — Use of subcontractors to store replicated or backup copies of PII is covered by supplier management controls (B.3.10, B.3.20)
- See also A.3.22: User Endpoint Devices for related requirements
- See also A.3.25: Logging for related requirements
A particularly important point is the tension between backup retention and PII deletion: organisations must balance the need to retain backups for recovery with obligations to delete PII when retention periods expire or when data subjects exercise their right to erasure.
How does this map to GDPR?
Control A.3.24 maps to the following GDPR articles:
- Article 5(1)(f) — The integrity and confidentiality principle, covering protection against accidental loss or destruction of personal data
- Article 32(1)(c) — The requirement to implement the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident
Article 32(1)(c) specifically calls out restoration capability, making tested backups a direct GDPR requirement rather than just good practice.
What changed from ISO 27701:2019?
For a step-by-step approach, see the Transition from 2019 to 2025.
In the 2019 edition, this requirement was covered by Clause 6.9.3.1 (information backup). The 2025 edition retains and expands the core requirements as A.3.24, with significantly more detailed implementation guidance in B.3.24 covering restoration logging, jurisdictional requirements and the backup-versus-erasure tension. See the Annex F correspondence table for the full mapping.
Get started easily with a personal product demo
One of our onboarding specialists will walk you through our platform to help you get started with confidence.
What evidence do auditors expect?
When assessing compliance with A.3.24, auditors will typically look for:
- Backup policy — A documented policy covering backup scope, frequency, retention periods, encryption, testing schedules and responsibilities for PII-containing systems
- Backup test records — Evidence of regular backup restoration tests, including test dates, scope, results and any issues identified and remediated
- Restoration logs — A log of any PII restoration events recording the responsible person, a description of the restored PII and any integrity issues identified
- Backup-erasure reconciliation — Evidence that the organisation has addressed PII erasure within backup data, whether through technical measures or documented justification for retention
- Customer communication — For processors, evidence that customers have been informed of backup capabilities and limitations
What are the related controls?
| Control | Relationship |
|---|---|
| A.1.4.8 Retention | Backup retention must align with PII retention schedules |
| A.1.4.6 De-identification and deletion | PII deletion requirements create tension with backup retention |
| A.3.20 Storage media | Backup media must be managed through its life cycle |
| A.3.26 Use of cryptography | Backup data should be encrypted both in transit and at rest |
| A.3.10 Supplier agreements | Third-party backup providers must be bound by appropriate contracts |
Who does this control apply to?
A.3.24 is a shared control that applies to both PII controllers and PII processors. Controllers must ensure their PII is backed up and recoverable. Processors have additional obligations to communicate backup capabilities and limitations to their customers, and to provide clear information about restoration capabilities where backup services are part of the service offering.
Free yourself from a mountain of spreadsheets
Embed, expand and scale your compliance, without the mess. IO gives you the resilience and confidence to grow securely.
Why choose ISMS.online for backup compliance management?
ISMS.online provides practical tools for managing PII backup compliance:
- Backup schedule management — Document and track backup schedules for all PII-processing systems, with automated reminders for upcoming tests and reviews
- Test result tracking — Log backup restoration test results with pass/fail status, issues identified and remediation actions, creating a complete audit trail
- Restoration log — Maintain the required log of PII restoration events with responsible person, description and integrity assessment fields
- Policy management — Publish backup policies with version control and staff acknowledgement tracking
- Retention management — Link backup retention periods to your data retention schedule, highlighting where backup retention may conflict with PII erasure obligations
FAQs
How do you handle erasure requests when PII exists in backups?
This is one of the most challenging aspects of PII backup management. Most organisations cannot selectively delete individual records from backup sets without restoring the entire backup. Common approaches include: maintaining a deletion register that is applied whenever a backup is restored, using backup retention periods that are short enough to ensure deleted PII naturally ages out, or implementing backup solutions that support granular deletion. The approach should be documented in the backup policy and communicated to data subjects when responding to erasure requests.
How often should backup restoration be tested?
The standard requires regular testing but does not specify a frequency. Industry best practice is to test critical PII system backups at least quarterly, with less critical systems tested at least annually. Some jurisdictions may impose specific testing frequencies. The testing should verify both the technical ability to restore data and the integrity of the restored PII. Test results should be documented and any failures should trigger immediate remediation.
What should the PII restoration log contain?
At minimum, the log must record the name of the person responsible for the restoration and a description of the restored PII. Best practice extends this to include the date and time of restoration, the reason for the restoration, the source backup used, any integrity issues identified during restoration and the actions taken to resolve them. Some jurisdictions prescribe additional log content, so organisations should check local requirements and document compliance.
