Safeguard 11.3 Protect recovery data: requirements and evidence

What Safeguard 11.3 requires for recovery data

Safeguard 11.3 asks that recovery data receive protection equivalent to the original data it copies, using controls such as encryption or separation, according to the sensitivity of that data. If your backup platform holds copies of production systems, this Safeguard is the one that tests whether those copies are as hard to read, alter or delete as the systems they came from. CIS publishes it as an IG1 Safeguard, so every enterprise is expected to meet it, and it sits in the Data asset class under the Protect security function.

The risk is practical. Attackers who reach production often look for backups first, because a readable, writable or deletable backup set lets them steal the data inside it, encrypt the only remaining copies, or erase the recovery path entirely. An unencrypted backup repository on a file share, a backup server with standing administrator access, or a copy sent to a cloud bucket with broad read permissions can each expose the same records that production controls protect. The protection has to follow the data into every copy, not stop at the primary system.

Three things usually make this hard. The first is unknown backup destinations: a backup job someone configured years ago, a laptop agent, or a SaaS export may write data to places that never appear in the asset inventory, which is why Safeguards 1.1 and 2.1 are prerequisites for measuring 11.3. The second is shadow copies, such as snapshots, replicas, developer exports or synced archives that inherit none of the production access rules. The third is key handling. Encryption that stores its keys beside the backups protects little, so confirm who holds the keys, how they rotate and whether a restore can be performed without the person who set the system up. Start by listing every destination that receives recovery data, then check each one against the production controls it must match.

Which backups and teams fall under 11.3

Safeguard 11.3 applies to recovery data wherever it lives, so the scope starts with an honest list of what gets backed up and where the copies sit. The cards below cover the asset types, destinations and owners that a scoping exercise must reconcile, plus the judgment calls that change how much work the safeguard becomes.

Servers and virtual machines

Physical servers and hypervisor-hosted virtual machines are the most common backup targets and the first place to check coverage. Compare the asset inventory from Safeguard 1.1 against the backup job list, because a server built outside the normal process often has no job at all. For each backup set, confirm the encryption setting in the backup software and record which assets are excluded and why. The assets missing from the backup job list are where coverage gaps usually hide.

Endpoints and user devices

Laptops and desktops hold local files that users assume are recoverable. Whether they are in scope depends on whether a client agent or sync tool copies their data to a managed backup store. Devices that only sync to a consumer cloud account sit outside the organization's backup configuration, so Safeguard 11.3 does not reach them unless the copies are managed. Confirm the device population from the asset inventory and decide per device class whether backups are encrypted and where the keys live.

Cloud workloads and snapshots

Cloud instances, managed disks and their snapshots are recovery data in their own right. A snapshot is a copy of the original data, so it needs the same protection as the disk it came from, including encryption and access restrictions. Teams often assume the cloud provider handles this, but the organization still owns the configuration that decides whether snapshots are encrypted and who can copy or share them. Ask the cloud team to list every snapshot policy and the key used for each.

Databases and application exports

Database backups, transaction log archives and scheduled application exports often run from scripts owned by a database or application team rather than the backup team. They carry some of the most sensitive records in the enterprise, so they need the same encryption and separation as the source database. Check whether dump files written to shared folders or object storage are encrypted at rest and whether the people who can read them match the people who can read the live database.

SaaS exports and third-party backup services

Exports from SaaS platforms and backups held by a third-party backup provider are recovery data even though the organization does not run the storage. Under Control 15 the provider must be assessed, but Safeguard 11.3 still applies to the copies, so the contract should state the encryption and key arrangements. Confirm whether the provider holds the keys, whether the organization can hold its own, and whether the provider's staff can read restored content.

Replicas, tape and offsite copies

Replicas and high-availability copies are a scoping decision, not a formality. A replica that mirrors production in near real time copies any corruption or encryption event along with the data, so it may not count as a recovery copy, but it still holds the original data and needs the same protection. Tape cartridges and offsite media leave the data center, so their encryption, transport and storage custody must be documented. Write down how each copy type is classified so the audit trail stays consistent.

How an assessor tests Safeguard 11.3

This table maps what the CIS Assessment Specification asks of an assessor for Safeguard 11.3, from prerequisites and the Coverage measure through sampling, evidence and common findings. Read it as a checklist of what to prepare before an assessor arrives, since each row names a point where a gap usually appears.

Assessment step	What the assessor checks	Evidence to prepare
Prerequisite inventories	Asset inventory (1.1), software inventory (2.1) and secure configuration process (4.1) exist and cover the systems that hold recovery data	Current asset and software inventories, documented configuration baseline, dated review records
Scope of in-scope assets	Which assets hold data that needs recovery, so the denominator of the Coverage measure is correct	Asset list tagged by backup need, with a note of any excluded assets and why
Coverage measure	Share of in-scope assets whose backup software is configured to encrypt backups	Per-asset report showing backup encryption setting, with the count of covered and total in-scope assets
Sampling of assets	Assessor selects a sample of in-scope assets and traces each to its backup job and configuration	Backup job list mapped to asset list, so any sampled asset can be traced quickly
Configuration export review	Encryption enabled on each sampled backup job, including the key or passphrase setting and where it is stored	Configuration exports from backup software, with timestamps and change history for encryption settings
Secondary and offsite copies	Whether copies sent to disk pools, tape, cloud or remote sites are encrypted as well as the primary backup	Storage destination list with encryption status for each copy, including copies made by replication
Verification of encryption	Evidence that encryption is actually applied to stored backup data, not only configured in a setting that was never applied	Test restore or verification output, or a documented check of encrypted backup files

How to implement 11.3 in sequence

The sequence starts with the inventories and configuration baseline that the assessment specification requires, then moves through encryption choices, key custody and coverage measurement, so the organization can show that every in-scope backup is protected to the standard of its source data.

Confirm the asset and software inventories
Before any backup is encrypted, the organization confirms the detailed enterprise asset inventory (Safeguard 1.1) and the software inventory (Safeguard 2.1). The assessment specification treats both as prerequisites for measuring 11.3, because the coverage metric depends on knowing which assets are in scope and which backup software runs against them. The internal owner of the asset register signs off the list of systems that hold recovery data. Done means every backup source and every backup platform appears in one of the two inventories, with an owner recorded for each.
Set the secure configuration baseline
The team documents a secure configuration process (Safeguard 4.1) that covers the backup servers, backup agents, catalogs, repositories and storage targets. The baseline states how encryption is enabled, which settings are locked, who may change them and how changes are approved. Platform engineering and the security team own the document, and the backup administrators follow it. Done means a versioned baseline exists for each backup product in use, and the current configuration of each system can be compared against it.
Classify backup tiers and choose protection per tier
The organization groups its recovery data into tiers based on the sensitivity of the source data, then selects encryption, data separation or both for each tier. Data owners and the security team make this decision together, since the requirement is that recovery data receive controls equivalent to those on the original data. Typical choices include encryption at rest in the backup software, separate repositories or keys for the most sensitive tier, and access restrictions on restore paths. Done means a written tier table lists each backup set, its source classification and its chosen protection method.
Configure encryption in the backup software and storage
Backup administrators enable encryption in the backup product and in the storage layer for each tier. Open-source options to evaluate include Bareos for scheduled backup, restore and catalog management, and restic, whose repositories are encrypted by design. Application-layer features such as Nextcloud server-side encryption protect file contents at rest, but it does not encrypt file names or folder structure, so teams must account for that gap. Done means a test backup for each tier can be inspected and shows encrypted content, and the configuration matches the baseline from the previous step.
Establish key custody and rotation
The team decides where encryption keys live, who can retrieve them and how they are rotated, and records that decision in the key management procedure. Keys stored beside the backups they protect weaken the control, so custody is separated from the storage administrators. OpenBao's transit secrets engine can hold keys, encrypt and decrypt application data, and support versioned keys with rotation, if it fits the architecture. Done means a named custodian, an access list, a rotation schedule and a tested restore using a rotated key are all documented.
Verify coverage and retain the evidence
The team measures coverage as the share of in-scope assets whose backup software is properly configured to encrypt backups, which is the metric the assessment specification uses for 11.3. It compares the backup inventory with the encryption settings, investigates every gap and records exceptions with an owner and a decision. Evidence includes the tier table, configuration exports, key custody records and the coverage report. Done means the coverage figure is recorded, every exception has an approved disposition, and the evidence pack is stored where an independent assessor can review it.

Evidence that passes an 11.3 review

An assessor testing Safeguard 11.3 wants to see that every in-scope backup is encrypted or separated to the same standard as the source data, and that the configuration stays that way. The cards below cover the artifacts that show this, along with the routine that keeps each one current between audits.

Backup job encryption configuration

Export the backup job definitions and the software settings that enable encryption for each job, including the key reference used. Assessors compare these settings against the Safeguard's requirement that recovery data carry controls equivalent to the original data. Confirm that no job is set to a plaintext destination or a fallback mode. Re-export after every change to a job, and store the export with the change ticket so the history is traceable.

Per-asset coverage report

The CIS assessment specification scores this Safeguard with a Coverage metric: the share of in-scope assets whose backup software is properly configured to encrypt backups. Produce a report that lists each in-scope asset from the asset inventory, the backup job covering it, and whether encryption is confirmed. Reconcile the report against the inventory each month, because an asset added without a backup job is a gap the metric will show as uncovered.

Key management policy and access logs

Keep a written policy that says who creates, stores, rotates and revokes the keys protecting recovery data, and where they are held. Pair it with access logs showing who read or used those keys over the audit period. Review the policy when the key platform changes, and check that logs from the key service reach the central log store. Assessors often test whether backup administrators can reach keys without a documented approval.

Encryption verification output

Keep the output of checks that prove stored backup data is encrypted and unmodified. For restic, this means the results of checks run with read-data options that read pack files back. For other tools, record the verification job logs and any failed-verification alerts. Run these checks on a schedule, and keep a dated record of each run, including failures and how they were resolved.

Storage-level encryption settings

Capture the encryption settings on the storage that holds recovery data, such as the server-side encryption option on a backup volume, object store or file server. Note which layer applies the encryption, who holds the keys, and whether file names and folder structure are protected. Some application-level options protect file contents but not metadata, so the record should state exactly what is covered. Re-capture the settings after storage changes.

Configuration drift change records

Keep change records for every modification to backup encryption, key settings and storage configuration, with the approver and the reason. Compare the current configuration against the approved baseline on a regular schedule and log any difference. Assessors use these records to check that a disabled encryption setting is caught and reversed, not left in place until the next audit.

Open-source options for encrypting recovery data

Bareos is a backup suite whose Director schedules and supervises backup, restore, verify and archive jobs and keeps a SQL catalog of the files it has backed up. For Safeguard 11.3, the question is whether the backup jobs and the stored volumes are configured so that backup data is encrypted to the same standard the original data receives. The configuration is the primary evidence: the job definitions, storage daemon settings and the catalog show which clients and jobs are in scope and how their backups are handled. The assessment specification measures coverage, meaning the share of in-scope assets whose backup software is properly configured to encrypt backups, so the inventory from Safeguards 1.1 and 2.1 must be complete before the coverage figure means anything.

Job-level coverage: Export the job and client definitions and compare them against the asset inventory to find in-scope hosts with no encrypted backup job.
Restore evidence: Restore a sample to confirm that encrypted volumes can be read with the keys held under your key process.
Catalog records: Use the catalog to show which backups exist for each asset and when they were taken.
Key location: Confirm where the encryption keys are stored and who can access them, since a backup that is encrypted with a key kept on the same host offers limited protection.
Version control: Keep the configuration in version control so changes to encryption settings are traceable.

Confirm with your own deployment which encryption options your Bareos version supports and how they are enabled, because the supplied facts describe the Director's scheduling and catalog functions rather than the encryption settings themselves.

What meeting 11.3 costs in money and effort

This table breaks down the cost components of meeting Safeguard 11.3 by who is paid, whether each cost is one-time or recurring, and what drives it up or down. No figures are given because none were supplied, so use it to structure quotes and internal budgets. The main takeaway is that key management and the number of backup destinations usually shape the cost more than the tools.

Cost component	Who is paid or who carries it	One-time or recurring	What drives the cost
Tooling and licenses	Software vendors if commercial add-ons are used, or no license fee for open-source tools	Recurring if support contracts apply, otherwise minimal	Named tools such as Bareos, restic, Nextcloud and OpenBao are open source, but confirm each license's terms (AGPL, BSD, MPL) with counsel before distribution
Engineering time for encryption configuration	Internal platform or backup engineers, or an implementation partner under a fixed-scope agreement	One-time	Number of backup jobs, asset classes and storage types that need encryption enabled and verified
Key management design and setup	Internal security engineers or the implementation partner	One-time, with periodic rework	Number of key hierarchies, whether keys are held in a central secrets store, and how key custody is split between teams
Key rotation and lifecycle operations	Internal operations staff	Recurring	Rotation frequency set by the organization, number of keys, and how well rotation is automated
Evidence upkeep	Internal compliance or operations staff	Recurring	Frequency of configuration exports, coverage reports and change records needed to show encryption on every in-scope backup
External review or testing	Independent testers or assessors engaged by the organization	Recurring, usually tied to audit or testing cycles	Scope of backup destinations, depth of testing of encrypted restores, and whether reviewers must access key material
Auditor sampling and assessment	The organization pays its independent auditor or assessor	Recurring per assessment cycle	Number of backup systems and assets sampled, and how easily the organization can produce coverage evidence on request
Asset count and destination growth	Internal teams absorb the work, and any partner charges follow the written scope	Recurring as the environment changes	Each new in-scope asset, backup destination or cloud region adds configuration and evidence work

Where organizations fall short on 11.3

Safeguard 11.3 is usually missed in the copies, not the primary backup. The gaps below cluster around where recovery data is stored, who can read it, and whether anyone has shown that protection is actually in place. Each card names the gap and the check that closes it.

Encrypting only the primary backup

Teams often enable encryption on the main backup server, then forget that offsite copies, tape exports, replicated repositories and cloud tiers were created through other jobs with different settings. Safeguard 11.3 asks for recovery data to receive protection equivalent to the original data, so every copy is in scope. Close the gap by listing every backup destination and job, then confirming each one has encryption enabled in its configuration. Check the destinations, not only the default job template. Bareos is one open-source option whose Director supervises all backup jobs from a single place, which makes this review easier to run.

Encryption keys stored beside the data

When the encryption key sits on the same host, in the same backup configuration file or in the same storage bucket as the encrypted data, anyone who steals the backup can read it. This defeats the purpose of encryption for recovery data. Store keys in a separate system with its own access controls and audit trail, and limit who can export or read them. OpenBao's transit secrets engine can encrypt data without storing it and supports versioned keys with rotation, which keeps key material out of the backup set. Confirm that a restore is still possible if the key service is unavailable, through documented break-glass procedures.

No coverage metric for backup encryption

Many organizations cannot say what share of their in-scope assets have encrypted backups. Without that number, gaps appear only during an incident. The CIS Controls Assessment Specification scores Safeguard 11.3 with a coverage metric: the share of in-scope assets with backup software properly configured to encrypt backups. Build this from the asset inventory (Safeguard 1.1) and software inventory (Safeguard 2.1), then compare each asset against its backup job configuration. Report the result as a recurring figure with a named owner, and treat any asset missing from the backup scope as a finding.

Unmanaged configuration drift

Encryption settings change when someone edits a job, upgrades backup software or rebuilds a server, and the change is often not recorded. A backup that was encrypted last quarter may not be encrypted today. Safeguard 4.1, the secure configuration process, is a prerequisite for measuring 11.3, so the encryption setting should be part of a baseline that is version controlled and checked on a schedule. Compare the live backup configuration with the approved baseline and alert on any difference. Ask your backup vendor or integrator to show how a changed encryption flag would be detected.

Recovery data outside the inventory

Cloud snapshots, object storage buckets, SaaS export tools and developer laptops can hold copies of production data that nobody lists as recovery data. These copies are usually the least protected, because they were created by a service rather than by the backup team. Start by searching cloud accounts for snapshots, replication targets and lifecycle rules that copy data, then add each one to the asset inventory with its encryption status. For a self-hosted platform such as Nextcloud, confirm whether server-side encryption is enabled, and note that it does not encrypt file names or folder structure, so those need separate handling.

Encrypted copies that are never verified

A backup can be encrypted and still be unreadable or silently corrupted, and the gap only appears during a restore. Safeguard 11.3 asks that protection be effective, so encryption should be checked as part of backup integrity. restic's check command verifies the structural consistency of snapshots, trees and pack files, and with --read-data or --read-data-subset it reads pack files back to confirm stored data is unmodified. Schedule these checks, record the results and confirm the decryption key is available to the team that would perform a restore.

Who does what for 11.3

Your organization owns Safeguard 11.3. That means deciding which recovery data must receive the same protection as the source data, which encryption and separation methods apply, who holds the keys, and how those decisions are written into policy. No partner or auditor can make these choices for you, and the CIS Controls assessment expects the protection to be your documented, operating control.

Protection standard: Define that recovery data carries controls equivalent to the original data, and record how that equivalence is judged for each data class.
Key ownership: Decide who creates, rotates, escrows and revokes backup encryption keys, and where those keys are held.
Scope decisions: Confirm which in-scope enterprise assets and backup jobs fall under the standard, consistent with your recovery process under Safeguard 11.1.
Operating records: Keep the configuration baseline, access approvals for restore and key material, and exception records signed by an accountable owner.
Review cadence: Assign someone to recheck encryption coverage after new systems or backup targets are added.

Before engaging anyone, confirm that your internal owner can explain the protection standard and the key custody model without referring to a vendor document.

Common questions about Safeguard 11.3

How much effort does Safeguard 11.3 take to implement?

Effort depends mainly on how many backup jobs and in-scope assets you run, how many backup platforms are in use, and how much of the encryption configuration is already standardized. The Safeguard asks that recovery data receive protections equivalent to the original data, so the work centers on confirming encryption settings on every backup job, documenting key handling, and checking the result against the assessment measure for coverage of in-scope assets. Organizations with a single backup platform and a consistent configuration usually have far less to do than those with several tools built up over years. Ask any partner to size the work from a written inventory of backup jobs, storage targets and key management systems.

Can an in-house team implement Safeguard 11.3 without an outside partner?

Yes, many in-house teams can implement it, provided they already own the backup platform and the key management process. The main skills are backup administration, basic cryptographic key handling, and the ability to read configuration output and show it to an assessor. Teams often need outside help when backup software is spread across several systems, when keys are managed inconsistently, or when no one has time to build repeatable evidence. The organization remains responsible for its controls in every case. A partner can prepare configurations and evidence, but only an independent auditor or assessor reports on whether the Safeguard is met.

How long does implementing Safeguard 11.3 usually take?

Timelines vary with the number of backup environments, how much encryption is already enabled, and whether keys must move to a managed key service. Teams with consistent backup configuration and existing key management typically need a short, focused effort. Environments with unencrypted legacy backups, multiple storage locations or no key ownership model need longer, because the work includes deciding who holds keys and verifying each job. Prerequisite work from Safeguards 1.1, 2.1 and 4.1 can also extend the schedule when asset and software inventories are incomplete. Agree on a written scope and milestones before work begins so the timeline follows from what is actually in place.

Does encryption alone satisfy Safeguard 11.3?

Encryption is the most common way to meet the Safeguard, but the requirement is broader: recovery data must be protected with controls equivalent to those on the original data, and encryption or data separation is cited as the means according to requirements. A backup that is encrypted with keys stored beside it, or that is readable by anyone who can reach the backup server, may not give equivalent protection. Access control, separation of duties for restore operations, and secure key storage all affect whether the protection is equivalent. The assessment measure looks at coverage, meaning the share of in-scope assets whose backup software is properly configured to encrypt backups, so the configuration and key arrangement both need to be documented and checked.

How does Safeguard 11.3 differ from Safeguard 11.4 on isolated copies?

Safeguard 11.3 is about protecting recovery data wherever it lives, so that copies receive controls equivalent to the originals, through encryption or separation. Safeguard 11.4 is about keeping an isolated instance of recovery data, such as an offline, cloud or off-site versioned destination, so that backups survive ransomware or compromise of the primary environment. The two often share the same backup platform, which is why teams mix them up. A backup can be encrypted under 11.3 and still sit in the same network as production, which does not satisfy 11.4. Plan and evidence them separately, even when one tool produces both configurations.

What must our team provide to a partner before work starts?

Provide a current list of in-scope assets, the backup software and version in use, the storage locations where recovery data is kept, and the key management arrangement, including who can create, rotate and revoke keys. Share existing backup job definitions, encryption settings and any written backup or key policies, along with the named owner for each system. Identify any legacy or unencrypted backups and the business reason they exist. Confirm which Safeguards 1.1, 2.1 and 4.1 artifacts already exist, because the assessment specification treats them as prerequisites. A fixed-scope agreement is easier to price and deliver when this material is ready at kickoff.

How 11.3 relates to 11.1, 11.2, 11.4 and 11.5

Safeguard 11.3 protects the copies that the other recovery safeguards create, so it only has something to act on once automated backups exist. The backup data produced under 11.2 must carry protections equivalent to the original data, such as encryption at rest or separation from general-purpose storage, and the 11.2 backup jobs are the first place to confirm that this is configured. The 11.1 data recovery process is the governing document that sets which assets are in scope, what their recovery priorities are, and how the security of backup data is decided and reviewed. If 11.1 does not name who owns backup encryption keys and how they are rotated, 11.3 has no owner and no standard to test against.

Safeguard 11.3 is distinct from 11.4. Safeguard 11.3 asks whether the backup copies are protected in place. Safeguard 11.4 asks whether an isolated instance survives a compromise of the primary environment, such as an offline, cloud or off-site versioned destination. An encrypted backup that sits on the same domain as production can still be deleted or encrypted by an attacker who holds the same credentials, so the two safeguards answer different questions and need separate evidence. Confirm with your team which backup destinations are isolated and which are only encrypted, and record the answer against both safeguards.

Safeguard 11.5 is the proof point. The CIS assessment specification scores 11.3 with a Coverage metric, the share of in-scope assets whose backup software is properly configured to encrypt backups, and a configuration setting alone does not show that encrypted data can be read back. Restore tests under 11.5 confirm that encrypted backups decrypt with the keys held by the organization. For cross-framework work, the CIS Controls Navigator maps 11.3 to NIST CSF 2.0 PR.DS-11, NIST SP 800-53 Rev. 5 CP-9, CP-9(8) and SC-28, ISO/IEC 27001:2022 Annex A controls 8.12 and 8.13, and AICPA SOC 2 criteria A1.2, CC6.4 and CC6.7. Confirm the exact mapping text against the current CIS Controls Navigator before citing it to an assessor, because the mappings are CIS's own and the wording of each framework belongs to its publisher.

How DeployOpen prepares 11.3 evidence

DeployOpen plans and implements self-hosted open-source backup and key management inside your own infrastructure so that recovery data carries the same protections as the original data. We prepare the systems and evidence an assessor will examine for Safeguard 11.3, while your organization owns the controls and an independent auditor or assessor issues any report.

How we scope

The written scope names the in-scope enterprise assets whose backups must be encrypted or separated under Safeguard 11.3.
We record which backup platforms, storage targets and key stores are covered and which are excluded.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.

How we build

We configure backup software such as Bareos or restic so that backups are encrypted before they leave the source.
Encryption keys are held in a managed key store such as OpenBao, with versioning and rotation documented.
We test that encrypted backups are created and restored correctly, and we record the configuration as evidence of coverage.

How we hand over

You receive configuration records, key management procedures and the coverage evidence for in-scope backup jobs.
Documentation maps each control to Safeguard 11.3 and to the prerequisite inventories from Safeguards 1.1, 2.1 and 4.1.
Your internal team or an independent assessor reviews the handover, and any formal assessment decision remains with them.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainers can cover key rotation reviews, backup software upgrades and periodic checks that encryption still covers new assets.
Confirm with DeployOpen during scoping which support terms and response expectations apply to your environment.