Information backup

The ISO/IEC 27018 information backup requirement means you must take backups of information, software, and system images, test those backups regularly, and run the entire backup program under an agreed backup policy. For any backups containing PII, you must apply the same security protections as the original data, including access controls and encryption. (ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors)

Key takeaways:

• Backups are mandatory, and restore testing is part of the requirement, not a nice-to-have. (ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors)
• Your backup policy must be explicit: scope, frequency, retention, testing, roles, and failure handling. (ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors)
• PII backups must match production protections, or you have created an ungoverned copy of regulated data. (ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors)

Most backup failures in audits are not “we forgot to back up.” They are: no written backup policy, unclear scope (what systems count), weak restore testing evidence, and a separate backup environment that is less protected than production. ISO/IEC 27018 makes all four issues exam-grade by tying backups to policy, testing, and “same level of protection” for PII.

This requirement is especially operational for cloud service providers acting as PII processors. You often have multiple backup mechanisms (snapshots, object replication, database point-in-time recovery, SaaS-native backup) spread across teams. Auditors will expect you to show a single coherent program: a policy that governs all backup types; an inventory mapping systems to backup methods; testing records that prove recoverability; and controls showing PII backups are encrypted and access-restricted like production.

If you want to operationalize this quickly, focus on three deliverables: (1) a backup policy that names standards you actually follow, (2) a restore testing cadence with tickets and results, and (3) a controls matrix proving PII backup protections align with production. (ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors)

Regulatory text

ISO/IEC 27018:2019 Clause 12.3.1 requires: “Backup copies of information, software and system images shall be taken and tested regularly in accordance with an agreed backup policy. Backup procedures for PII shall ensure the same level of protection as the original data.” (ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors)

What an operator must do

• Take backup copies that cover: (a) information (data), (b) software, and (c) system images (or equivalent rebuild artifacts). (ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors)
• Test backups regularly to prove integrity and recoverability, not just completion. (ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors)
• Operate under an agreed backup policy that defines how your organization does the above. (ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors)
• Apply equivalent protections to PII backups as you apply to the original PII, including encryption and access controls (explicitly called out in the requirement summary). (ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors)

Plain-English interpretation

You need a backup program you can defend under scrutiny. That means: every in-scope production system has a defined backup method; the method is documented in policy; backups are protected like production (especially if they contain PII); and you periodically restore from backup to prove you can recover.

A common trap: treating “backup success” dashboards as testing. ISO/IEC 27018 expects you to test recoverability, which in practice means performing restores and validating outcomes.

Who it applies to

Entity scope

• Cloud service providers acting as PII processors (the primary applicability stated for this requirement set). (ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors)

Operational context (what auditors will include)

• Production services that store or process customer PII.
• Supporting systems that enable recovery: configuration management, image repositories, deployment artifacts, encryption key management dependencies, and identity systems that gate backup access.
• Third parties that run any part of backup or restore operations (managed backup providers, SaaS backup tools, offsite storage).

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

1) Define “what must be backed up”

Create (or update) a simple register that maps:

• System / service name
• Data classification (identify where PII exists)
• Backup method (snapshot, database backup, object replication, SaaS-native export)
• Backup storage location(s)
• Owner (engineering) and control owner (security/GRC)

Outcome: you can show complete coverage and identify PII-bearing backups that need equivalent security.

2) Write an “agreed backup policy” that matches reality

At minimum, your backup policy should state:

• Scope: systems, environments, and data types (explicitly include PII)
• Roles: who runs backups, who approves exceptions, who reviews failures
• Protection requirements: encryption, access control, logging for backup systems; explicit statement that PII backups receive the same protections as production PII (encryption and access controls). (ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors)
• Testing expectations: restore test types, success criteria, and documentation requirements (tie to tickets and evidence)
• Exception process: how you document deviations and compensating controls

Practical note: “Agreed” should mean approved by accountable leadership, not a draft in a wiki.

3) Implement protections for PII backups equal to production

For backup repositories and pipelines that handle PII, validate:

• Encryption at rest and in transit is enabled and enforced.
• Access is restricted via least privilege, with admin roles controlled and reviewed.
• Backup access is logged, and logs are protected from tampering.
• Keys and secrets needed for restores are managed with the same rigor as production dependencies.

Your goal is simple to explain to an auditor: “A backup copy of PII is still PII, and we protect it the same way.” (ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors)

4) Establish “regular” testing and document it

Define a restore testing program that includes:

• Integrity checks (backup not corrupted)
• Recoverability tests (actual restore into a controlled environment)
• Validation (application starts, data is readable, access controls work)

Document each test with: what was restored, who executed it, what issues occurred, and remediation actions.

5) Operationalize failure handling and continuous improvement

Backups fail. Auditors care whether you:

• Detect failures (alerting)
• Triage and resolve within a defined operational process
• Track recurring failure causes to remediation

Treat backup failures and failed restore tests like reliability incidents: ticket them, root-cause them, fix them, and keep evidence.

6) Extend the control to third parties

If a third party provides backup tooling or managed backup services:

• Contractually require the same protection for PII backups as production PII.
• Request evidence that backups are encrypted and access-controlled.
• Confirm restore testing responsibilities (you, them, or shared).

Daydream can help here by standardizing third-party due diligence requests and tracking backup-control evidence alongside your broader third-party risk program, so “backup protection parity for PII” does not get lost across multiple providers.

Required evidence and artifacts to retain

Auditors typically accept a combination of governance artifacts plus technical proof. Maintain:

• Approved backup policy (with version history and approval record)
• System-to-backup mapping (inventory/register)
• Backup configuration evidence (screenshots or exported configs showing encryption, retention settings, access control)
• Access reviews for backup admin roles
• Restore testing records (tickets, runbooks executed, logs, results, follow-up remediation)
• Backup failure logs and incident/ticket trail
• Evidence of PII protection parity (control mapping showing same encryption/access model as production)
• Third-party attestations or contract clauses covering backup protection and testing responsibilities

Common exam/audit questions and hangups

• “Show me your backup policy and who approved it.”
• “Which systems are in scope, and how do you know you didn’t miss any?”
• “Prove you can restore. Show the last restore test record.”
• “Do backups include PII? If yes, show encryption and access controls for the backup repository.”
• “Who can delete backups or disable backup jobs? How is that restricted and monitored?”
• “What happens when a backup fails? Show the ticket and resolution.”

Hangup to expect: teams often can show backup job status, but not a repeatable restore test with documented outcomes.

Frequent implementation mistakes (and how to avoid them)

1. Backups exist, but no policy ties them together.
   Fix: publish a single policy that governs all backup types, including cloud-native snapshots and SaaS backups. (ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors)

2. PII backups are less protected than production.
   Fix: explicitly validate encryption/access parity for backup stores and service accounts; treat the backup environment as production-grade for PII. (ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors)

3. “Testing” means reading a dashboard.
   Fix: define restore tests as a required activity with recorded outputs and success criteria; schedule them as operational work, not ad hoc heroics. (ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors)

4. Keys/secrets for restore are overlooked.
   Fix: include restore dependencies in scope. If you cannot access keys, your backups are functionally useless.

5. Third parties run backups, but you cannot evidence protections.
   Fix: include backup controls in third-party due diligence and contract requirements; collect artifacts on a recurring basis.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so treat enforcement risk as indirect: weak backups increase breach impact and operational outages, and weak protection on PII backups increases the likelihood that an attacker finds an easier path through your backup environment than through production. ISO/IEC 27018 makes backup protection parity a clear expectation for cloud PII processors. (ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors)

Practical 30/60/90-day execution plan

First 30 days (stabilize and document)

• Identify all PII-bearing systems and their current backup methods; capture in a backup register.
• Draft or refresh the backup policy; get formal approval.
• Verify encryption and access controls on primary backup repositories for PII.

Days 31–60 (prove recoverability)

• Create restore test runbooks for critical systems.
• Execute restore tests and store evidence (tickets, logs, validation steps).
• Implement an exception process for systems that cannot meet the policy yet, with compensating controls.

Days 61–90 (operationalize and extend)

• Build a repeatable restore testing cadence tied to change management and incident response.
• Add continuous monitoring for backup job failures and privileged changes to backup configurations.
• Extend requirements to third parties through due diligence requests and contract updates; centralize evidence tracking in Daydream if you need consistent follow-through across providers.

Frequently Asked Questions

What counts as “regularly” tested backups under ISO/IEC 27018?

The standard does not define a fixed interval in the provided text. Define a restore testing cadence in your backup policy, align it to system criticality, and keep evidence that you followed it. (ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors)

Do we need to back up “software and system images” if we use infrastructure as code?

You still need a recovery path for software and system images, which can include golden images, immutable artifacts, and rebuild pipelines if they are controlled and recoverable. Document that approach in the backup policy and test restores or rebuilds as part of recoverability. (ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors)

If production PII is encrypted, do PII backups also have to be encrypted?

Yes. The requirement summary explicitly calls out maintaining the same level of protection for PII backups, including encryption and access controls. (ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors)

What evidence is strongest for backup testing?

Provide restore test tickets showing scope, executor, timestamps, restoration logs, validation steps, results, and remediation actions. Pair that with a runbook that defines success criteria and required sign-off.

How do we handle backups for SaaS systems where we can’t access the underlying infrastructure?

Treat SaaS-native export/backup features as your backup mechanism and document them in the backup register and policy. If a third party provides backup capabilities, collect evidence of encryption/access control and clarify restore testing responsibilities in the contract.

Who should own this control: IT, Security, or GRC?

Engineering or IT usually owns execution, Security defines protection requirements (especially for PII parity), and GRC owns the policy and evidence narrative for audits. Assign one accountable owner for the overall backup policy to avoid gaps. (ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors)