Information backup

“Information backup” in ISO/IEC 27017 is a requirement-level control aimed at one outcome: you can restore cloud-hosted data and services within business-acceptable time and integrity limits. The clause is short, but auditors and customers interpret it broadly because it explicitly covers information, software, and system images, and it adds a second obligation that teams often skip: regular testing.

For a CCO or GRC lead, the fastest path to compliance is to treat backups as a governed service with clear accountability. That means you need an approved backup policy that covers cloud workloads, maps to your data and service criticality, and reflects the shared-responsibility split between cloud service provider (CSP) and customer. In practice, you will coordinate IT operations, security, application owners, and third parties that host or process your data.

This page translates the clause into an operator-ready checklist: what to decide, what to configure, what to test, what to keep as evidence, and where audits commonly fail teams. Source requirement: ISO/IEC 27017:2015 Clause 12.3.1 (ISO/IEC 27017:2015 Information technology — Security techniques — Code of practice for information security controls based on ISO/IEC 27002 for cloud services).

Regulatory text

Clause requirement (verbatim): “Backup copies of information, software and system images shall be taken and tested regularly in accordance with an agreed backup policy for cloud-hosted data and services.” (ISO/IEC 27017:2015 Information technology — Security techniques — Code of practice for information security controls based on ISO/IEC 27002 for cloud services)

Operator interpretation: you must (1) take backups for defined cloud assets, (2) test those backups on a repeatable schedule, and (3) do both under a policy that is agreed by the relevant parties (customer and cloud provider, or internal service owner and platform team). The policy must be specific enough that an auditor can trace: system → backup method → schedule → retention → restore test → evidence.

Plain-English interpretation (what the requirement means)

You need a documented, approved backup policy for cloud-hosted systems and data that answers four questions:

1. What is backed up? Data, configurations, software components, and system images where relevant.
2. How is it backed up? Native cloud backup, snapshots, replication, immutable backups, or third-party tooling.
3. How long is it kept and where? Retention periods, storage locations, and any segregation requirements.
4. Can you restore it? You must prove restorability through regular testing, not just successful backup jobs.

Auditors generally accept different backup patterns for different workloads, but they will not accept “we rely on the cloud provider” unless the agreement and technical implementation clearly show what the provider covers versus what you cover.

Who it applies to (entity and operational context)

Applies to:

• Cloud Service Providers (CSPs): If you provide cloud services to customers, you must have a backup policy for the services you operate and be able to demonstrate backup and restore testing. (ISO/IEC 27017:2015 Information technology — Security techniques — Code of practice for information security controls based on ISO/IEC 27002 for cloud services)
• Cloud Service Customers: If you run workloads in a cloud environment, you must ensure backups and tests occur according to an agreed policy, including where you depend on the CSP or a managed service provider. (ISO/IEC 27017:2015 Information technology — Security techniques — Code of practice for information security controls based on ISO/IEC 27002 for cloud services)

Operational contexts where this becomes urgent:

• Regulated production systems (customer data, financial reporting, health data).
• SaaS apps where the provider’s built-in backup is limited, optional, or excludes certain objects.
• Containerized and infrastructure-as-code environments where “system images” translates to golden images, registries, and configuration states.
• Third-party hosted platforms where you need contract language to make “agreed backup policy” real.

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

1) Define backup scope and ownership (shared responsibility)

Create a service inventory for cloud-hosted assets and decide ownership:

• Data sets (databases, object storage, file shares)
• Software (application binaries, packages, container images, critical dependencies)
• System images/configuration states (VM images, AMIs, templates, IaC repos, critical configs)

Document for each asset:

• System owner (business)
• Technical owner (platform/app team)
• Backup operator (internal team or third party)
• Restore approver (who authorizes and validates restores)

2) Write the “agreed backup policy” with decision-grade detail

At minimum, your backup policy should include:

• Scope (what environments and data classes are in/out)
• Backup methods per asset type (snapshot, full, incremental, replication)
• Retention rules and disposal process
• Backup storage controls (access control, separation, integrity protections)
• Restore testing approach (what is tested, how often, success criteria)
• Roles and escalation path during restore events
• Exceptions process (with risk acceptance and compensating controls)

The word “agreed” matters in cloud. If a third party performs backups, your policy should reference the agreement (MSA/SOW/SLA) that commits them to scope, retention, and restore support. (ISO/IEC 27017:2015 Information technology — Security techniques — Code of practice for information security controls based on ISO/IEC 27002 for cloud services)

3) Configure backups with traceability to the policy

Make the policy enforceable:

• Tag cloud resources and align backup jobs to tags (so new assets get coverage).
• Standardize backup job naming (system, environment, data class).
• Ensure backup failures generate tickets/alerts with owner routing.
• Control administrative access to backup configuration and deletion actions.

If you operate multiple accounts/subscriptions, make sure backup administration is not scattered without governance. Auditors look for central visibility, or documented federation.

4) Build and run restore tests that prove recoverability

Testing is not “checking the dashboard.” It is a restore attempt with validation. Define test types:

• File/object restore test (retrieve specific objects and verify readability).
• Database restore test (restore to isolated environment and run integrity checks).
• System image restore test (launch from image/snapshot and confirm boot + app health).
• Application-level restore test (restore data plus app dependencies to a working state).

Document success criteria that your operators can execute consistently: what constitutes “pass,” what logs/screenshots to collect, and who signs off.

5) Close the loop: exceptions, drift, and change management

Common drift patterns:

• New cloud services deployed without backup tagging.
• Backup retention changed during cost optimization without risk review.
• Migrations that invalidate prior restore procedures.

Operationalize controls:

• Require backup coverage checks in change management for production systems.
• Run periodic backup coverage reviews against asset inventory.
• Track exceptions with expiry dates and compensating controls.

6) Third-party alignment (CSPs and managed providers)

For any third party hosting data/services:

• Confirm whether backups are included, optional, or customer-managed.
• Confirm restore support model (self-service, ticket-based, RTO commitments if any).
• Ensure your policy and the third party contract do not conflict on retention, deletion, or legal hold.

If you use Daydream to manage third-party risk and due diligence workflows, map backup obligations into your third-party questionnaires and contract checklists so “agreed backup policy” is evidenced by both operational configuration and supplier commitments.

Required evidence and artifacts to retain

Keep evidence that links policy → implementation → testing:

Policy and governance

• Approved backup policy (versioned, dated, owner assigned)
• Backup standards/procedures/runbooks (restore steps included)
• Exception register with approvals and expiration

Technical evidence

• Backup configuration exports ¹
• Backup job schedules and retention settings
• Backup success/failure logs and alert tickets
• Access control evidence for backup administration (roles, groups)

Testing evidence

• Restore test plans and test cases
• Restore test execution records (date, scope, results, artifacts)
• Validation evidence (hash checks, application checks, data integrity checks)
• Remediation records for failed tests

Third-party evidence (where relevant)

• Contract/SLA clauses or SOW sections covering backup scope, retention, and restore support
• Third-party attestation or service description aligning to your backup policy

Common exam/audit questions and hangups

Auditors and customers tend to ask:

• “Show me your backup policy, and show me how it applies to this specific system.” (ISO/IEC 27017:2015 Information technology — Security techniques — Code of practice for information security controls based on ISO/IEC 27002 for cloud services)
• “Which systems are excluded, and who accepted the risk?”
• “Prove you test restores regularly. Show the last test and the evidence.”
• “Are you backing up system images or only data?”
• “Who can delete backups, and how do you prevent accidental or malicious deletion?”
• “If a third party runs the platform, what does your agreement say about backups and restores?”

Hangups that cause findings:

• Tests are informal and not repeatable.
• Evidence exists in tools, but no one can produce it quickly for a sampled system.
• “We assumed the CSP backs it up” with no policy alignment and no contract clarity.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Treating snapshots as a complete backup strategy.
   Fix: Document where snapshots are sufficient and where you also need application-consistent backups and restore validation.

2. Mistake: No restore testing for “lower environments.”
   Fix: Test in an isolated environment, but test production-relevant data paths and system images. The clause requires testing; it does not limit testing to production only. (ISO/IEC 27017:2015 Information technology — Security techniques — Code of practice for information security controls based on ISO/IEC 27002 for cloud services)

3. Mistake: Backups exist, but ownership is unclear during an incident.
   Fix: Put the restore decision tree in the runbook: who declares a restore event, who executes, who validates.

4. Mistake: Retention is set by default and never reviewed.
   Fix: Tie retention to business requirements and data classification. Review changes through risk and change management.

5. Mistake: Third-party backup promises are not contractually enforceable.
   Fix: Add explicit backup/restore obligations to MSAs/SOWs and keep them aligned with your internal policy’s scope and testing expectations. (ISO/IEC 27017:2015 Information technology — Security techniques — Code of practice for information security controls based on ISO/IEC 27002 for cloud services)

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this specific ISO/IEC 27017 clause, so this page does not cite enforcement actions. Practically, weak backups show up as control deficiencies during ISO audits, customer security reviews, and post-incident investigations. The business risk is straightforward: inability to restore can turn an availability incident into a data-loss event and can also undermine legal or contractual commitments on service continuity.

Practical execution plan (30/60/90)

Because the requirement does not prescribe a specific cadence, focus on reaching provable operational maturity in phases.

First 30 days (Immediate)

• Publish an interim backup policy for cloud-hosted data and services with defined scope, roles, and exception process. (ISO/IEC 27017:2015 Information technology — Security techniques — Code of practice for information security controls based on ISO/IEC 27002 for cloud services)
• Identify crown-jewel systems and confirm they have backups configured plus a documented restore procedure.
• Run at least one restore test for a critical system and store the evidence in your audit repository.

By 60 days (Near-term)

• Complete backup coverage mapping for in-scope cloud assets (inventory → backup job association).
• Implement alerting/ticketing for failed backups with owner routing.
• Formalize restore test cases by asset type (data, software, system images) and schedule recurring execution with assigned owners.

By 90 days (Ongoing operationalization)

• Integrate backup checks into change management and new system onboarding (tags, policies, approvals).
• Expand restore testing to representative systems across major platforms and environments.
• Close contract gaps with third parties so backup scope, retention, and restore support are “agreed” and auditable. (ISO/IEC 27017:2015 Information technology — Security techniques — Code of practice for information security controls based on ISO/IEC 27002 for cloud services)

Frequently Asked Questions

Does ISO/IEC 27017 require backups for both data and infrastructure?

Yes. The text explicitly includes “information, software and system images,” so your policy and evidence must cover more than just database dumps. (ISO/IEC 27017:2015 Information technology — Security techniques — Code of practice for information security controls based on ISO/IEC 27002 for cloud services)

What counts as “tested regularly”?

The clause does not define an exact frequency; you must define it in the agreed backup policy and execute to it. Auditors look for a repeatable schedule, documented test cases, and evidence of recent successful restores. (ISO/IEC 27017:2015 Information technology — Security techniques — Code of practice for information security controls based on ISO/IEC 27002 for cloud services)

If our cloud provider says they handle backups, are we done?

Only if your backup policy documents that responsibility split and you can produce evidence of scope, retention, and restore testing support through the provider’s commitments and your own verification. “Agreed backup policy” pushes you to make this explicit. (ISO/IEC 27017:2015 Information technology — Security techniques — Code of practice for information security controls based on ISO/IEC 27002 for cloud services)

Do we need to back up SaaS application data separately?

If the SaaS provider’s native backup/restore capabilities do not meet your policy requirements for retention and recoverability, you need compensating backups (exports, third-party backup tools) and restore tests. Your policy should state how SaaS is handled and who owns restores. (ISO/IEC 27017:2015 Information technology — Security techniques — Code of practice for information security controls based on ISO/IEC 27002 for cloud services)

What evidence is most persuasive in an audit?

A dated, approved policy; a system-to-backup mapping; and a restore test record that shows steps performed and validation results for a sampled production system. Backup “success” dashboards help, but they do not replace restore proof. (ISO/IEC 27017:2015 Information technology — Security techniques — Code of practice for information security controls based on ISO/IEC 27002 for cloud services)

How do we handle backup exceptions for legacy systems or cost constraints?

Use a time-bound exception with documented rationale, compensating controls, and risk acceptance by an accountable owner. Track expiry and require a remediation plan so exceptions do not become permanent policy gaps.

Footnotes

1. cloud account/subscription