Safeguard 11.4 Isolated copy of recovery data: evidence

What Safeguard 11.4 isolated recovery data requires in practice

Safeguard 11.4 asks the enterprise to establish and maintain an isolated instance of recovery data, meaning a copy of backups that sits outside the reach of the systems and identities it protects. If a CISO or compliance lead is answering a CIS Controls assessment or a customer question about backup resilience, the test is not whether backups run. The test is whether a ransomware operator or a compromised administrator who controls the production environment can also delete, encrypt or alter the backup copy. CIS gives version-controlled backup destinations held in offline, cloud or off-site systems or services as example implementations, and the Coverage metric in the Assessment Specification measures the share of in-scope assets configured to send backups to such an isolated instance. The risk is concentrated in identity. A backup repository that accepts the same domain administrator credentials, the same backup server service account or the same management plane as production gives an attacker a route to the copy along with the original data. Many ransomware incidents follow this pattern: the attacker gains privileged access, finds the backup console, and removes or encrypts restore points before deploying the payload. An isolated copy is only isolated if the write path, the delete path and the administrative path are separated from production identities, with immutability, object locking or a separate administrative domain where the platform supports them. Confirm what each option in your environment actually enforces before you describe it as isolated.

Three decisions usually make 11.4 difficult. The first is credential separation: the team that operates backups needs its own accounts, MFA and logging, and the backup system must not depend on production directories for authentication. The second is retention: an isolated copy must hold enough restore points to predate an attack that may have been dormant for weeks, and the retention period, storage cost and off-site transfer volume all grow with it. The third is restore dependencies: a copy that cannot be restored without the production key management service, the same DNS, or an intact configuration database offers less protection than it appears to. Open-source engines such as Bareos, whose Director keeps a SQL catalog and schedules restore jobs, and restic, whose check --read-data command reads pack files back to confirm stored data is unmodified, can support these decisions, but the isolation design itself is yours to define and to document in the data recovery process under Safeguard 11.1.

Which backup destinations and teams fall under 11.4

Safeguard 11.4 applies wherever in-scope recovery data is kept, so the scope question starts with the backup sets themselves. The cards below cover the asset classes and function the Safeguard sits in, how IG1 applies to every tier, and the decisions that determine which copies need isolation and who owns each control.

Data asset class and Recover function

In v8.1, Safeguard 11.4 is assigned to the Data asset class and the Recover security function. That placement means the isolated copy is judged as data protection for recovery, not as a device or network control. Start your scope with the data sets that Control 11 covers: production databases, file shares, configuration stores and anything your recovery process names as a restore priority. Confirm that each of these has an owner who can say where its recovery copies live.

IG1 applies to every tier

Safeguard 11.4 sits in Implementation Group 1, so it applies to IG1, IG2 and IG3 enterprises alike. A small organization cannot treat an isolated copy as an advanced option reserved for mature programs. Confirm the enterprise's Implementation Group in writing, then check that the isolated copy is in the baseline and not deferred to a later phase.

Which backup sets need an isolated copy

Not every backup needs the same isolation, but the ones that restore critical systems must have one. Identify the backup sets tied to ransomware-exposed systems, domain controllers, identity stores and backup servers themselves. Record the decision for each set, including the reason a set is excluded. The Coverage metric in the assessment specification counts the share of assets configured to send backups to an isolated instance, so every excluded set reduces the score and should be justified.

Cloud accounts and SaaS backup

Recovery data often sits in cloud accounts and SaaS platforms that the backup team does not operate directly. Object storage buckets, managed database snapshots and SaaS mail or document backups each need a versioned, isolated destination. Check whether the provider's default retention can be deleted by the same credentials that run production, and whether a separate account or tenant can hold the isolated copy. Ask the provider to confirm each of these in writing before you rely on them.

Third-party backup providers

When a backup provider stores or restores your recovery data, that provider holds an isolated instance on your behalf. Include the provider in scope, obtain its description of where copies are kept, how immutability or versioning is enforced, and who can delete them. Its contract should state these responsibilities. Keep the provider's evidence alongside your own so an assessor can trace each copy to a named destination.

Who owns the isolation controls

Isolation spans three teams. The backup team configures destinations, schedules and retention. The identity team controls the accounts and keys that can write to, change or delete the isolated copy. The security team sets the requirement, reviews exceptions and tests whether a compromised production credential can reach the copy. Write these responsibilities into the recovery process so that no isolation control is owned by nobody.

How an assessor tests 11.4 under the CIS Assessment Specification

This table walks through how an assessor works through Safeguard 11.4, from the prerequisites and the Coverage metric to the evidence requested and the findings that most often appear. Read it as a checklist of what to have ready before an assessment, since the assessor reaches the conclusion, not the organization or its implementation partner.

Assessment step	What the assessor checks	Evidence to have ready	Common finding
Prerequisite 1.1	Whether the enterprise asset inventory is complete enough to define which assets are in scope for isolated recovery copies	Current asset inventory export with owners and asset classes, and the process that keeps it current	Backup-scoped servers or virtual machines missing from the inventory, so they never receive an isolated copy
Prerequisite 4.1	Whether a documented secure configuration process governs how backup agents, jobs and destinations are built and changed	Configuration standard for backup systems, change records for job and destination settings	Backup destinations configured by hand with no baseline, so settings drift between environments
Coverage metric	The share of in-scope assets configured to send backups to an isolated instance of recovery data	Asset-to-destination mapping showing each in-scope asset, its backup job and the isolated target it writes to	Mapping covers only the primary data center, while cloud workloads or branch assets write to the production-reachable target only
Backup job configuration	That scheduled jobs actually write to the isolated destination, not just to a staging copy on the production network	Exported job definitions, schedules and destination identifiers, plus recent job logs showing successful writes	Job definitions point to an isolated target, but recent logs show failed or skipped copies that nobody reviewed
Destination settings	That the isolated instance is offline, cloud or off-site in the way the organization describes, with version history retained	Destination configuration such as object lock or immutability settings, retention rules and version history samples	Cloud bucket with versioning enabled but no retention lock, so versions can be deleted with the same credentials
Access separation	Whether the isolated copy can be altered or deleted by the credentials that administer production systems	Identity and access records for the backup destination, showing which accounts and roles hold write and delete rights	Isolated copies reachable with the production administrator credentials, which defeats the purpose of the copy during a compromise
Recovery reference	Whether the isolated copy is restorable and whether its integrity is verified, which supports the claim that it is usable	Verification job results or integrity check output, and links to the recovery test records held under Safeguard 11.5	Verification runs only against the primary backup set, so the isolated copy has never been checked for consistency

Steps to establish an isolated copy of recovery data

This sequence moves from knowing which assets exist and how they are configured to a documented, measured set of backup jobs that send recovery data to a destination an attacker with access to the primary environment cannot easily reach. Each step produces an artifact that an assessor can trace back to Safeguard 11.4.

Confirm the asset inventory and configuration process
Before any backup destination is chosen, confirm that the enterprise asset inventory under Safeguard 1.1 and the secure configuration process under Safeguard 4.1 are current. The CIS Controls Assessment Specification treats both as prerequisites for measuring Safeguard 11.4, because the Coverage metric is a share of assets, and that share is meaningless if the asset list is incomplete. Owned by the IT or platform team, this step ends when you can export a list of in-scope assets with an owner, a data class and a configuration baseline for each one. Missing assets found here should be added to the backup scope before the rest of the work proceeds.
Define the isolation requirement for each data class
Work with data owners to decide which recovery data must be isolated, how far, and how quickly it must be restorable after an incident. Classify systems by data sensitivity and criticality, then record for each class whether an offline copy, an off-site copy or a versioned cloud copy is required, and which accounts are allowed to reach it. The output is a short standard that names the isolation requirement per class and is approved by the owner of the documented data recovery process under Safeguard 11.1. Ask the policy owner to confirm how the recovery process treats each class before engineers build anything.
Choose the isolated destination type
Select the destination for each data class from the options CIS gives as examples: version-controlled backup destinations held in offline, cloud or off-site systems or services. Offline media suit the strictest separation but need a handling procedure, cloud versioned storage needs immutability or object lock controls that you must confirm with the provider, and off-site systems need a network path that the primary environment cannot freely write through. Record the chosen destination, its version retention, and the reason for the choice. Ask the provider in writing which isolation features its service actually supports before you rely on them.
Separate credentials, network paths and retention
Create the isolation itself. Give the backup destination its own administrative identities, separate from production administrators, and restrict who can delete or shorten retention on recovery copies. Limit the network paths so that compromised production hosts cannot reach or modify the isolated instance except through the backup service. Document retention settings so that a copy cannot be overwritten within the retention window by a user or process on the primary side. This step is complete when a test account on a production host cannot delete, alter or expire an isolated copy, and that test result is written down.
Configure backup jobs to the isolated instance
Point the automated backup jobs for each in-scope asset at the isolated destination. Open-source options include Bareos, whose Director schedules and supervises backup, restore, verify and archive jobs and keeps a SQL catalog of backed-up files, and restic, which stores snapshots in a repository that can be checked with restic check. Confirm that the job definitions, schedules and destination identifiers live in version control under the secure configuration process. The output is a job list in which every in-scope asset points to an isolated destination, with a verification run recorded for each job.
Verify integrity of isolated recovery data
Confirm that the isolated copies are intact and readable. With restic, run restic check, and add --read-data or --read-data-subset to read pack files back and confirm the stored data is unmodified. With Bareos, use its verify job type against the isolated storage. Keep the verification logs, the date of each run and the identifier of the snapshot checked. This step shows that the isolated instance is usable, which an assessor will look for alongside the coverage figure. Confirm with your own environment how often these checks run, and align that frequency with the testing approach in Safeguard 11.5.
Measure coverage and document the result
Calculate the Coverage metric defined in the CIS Controls Assessment Specification: the share of in-scope assets configured to send backups to an isolated instance. Compare the result with the asset inventory from the first step and list every exception with an owner and a reason. Write up the isolation standard, destination choices, credential separation, job configuration, verification results and coverage figure in one record, and link it to the data recovery process. This record is the evidence an assessor, or your own control owner, will use to show Safeguard 11.4 is implemented and maintained. Review it whenever assets, destinations or providers change.

Choosing an isolation pattern for recovery data

Offline media keeps a copy physically disconnected from the network, usually on tape, removable disk or cartridges that are rotated off-site or into a locked store. Because no live path connects the copy to the production environment, ransomware and an attacker with administrator rights on the primary systems cannot reach it without a physical step. The trade-off is operational: someone must load, label, rotate and carry media on a schedule, and restores from tape are typically slower than restores from disk.

Protection: Strong against network-borne ransomware and credential theft, since the copy is not reachable from the production domain.
Operational demand: Named custodians, a rotation calendar, chain-of-custody records and periodic checks that media still reads.
Recurring effort: Media purchase, courier or vault fees and handling time, all of which repeat with each backup cycle.
Evidence produced: Rotation logs, custody sign-offs, vault access records and restore test results from media.
Open-source fit: Bareos can write to tape and manage its catalog, but confirm the tape library and drive support in your environment.

Confirm with your backup vendor and vault provider how media is verified, how long it can be stored and how quickly a restore can be run from it.

A separate-account or off-site copy writes backups to a second administrative domain, such as another cloud account, another data center or a remote site. The key design choice is that the credentials able to write or delete backups are not usable from the production environment, so compromising production does not grant control of the recovery copy. This pattern is common in self-hosted estates because it can run on infrastructure you already operate, but it depends heavily on how the trust boundary is drawn.

Protection: Guards against an attacker who gains administrator access in the primary environment, provided the second account shares no identities, keys or trust relationships with it.
Operational demand: Separate identity controls, write-only or append-only service credentials, MFA for administrators and a documented list of who can reach the second domain.
Recurring effort: Duplicate infrastructure or storage capacity, cross-site bandwidth and periodic access reviews.
Evidence produced: Account and role inventories, credential rotation records, access logs from the recovery domain and restore tests run from it.
Open-source fit: restic can write encrypted snapshots to a remote repository, and its check command with --read-data or --read-data-subset reads pack files back to confirm stored data is unmodified.

Confirm that the recovery account shares no administrators, service accounts or key material with production, and check how deletion of old backups is restricted.

Evidence that shows an isolated copy exists and works

An assessor testing Safeguard 11.4 wants to see which assets send backups to an isolated destination, how that destination is locked down, and whether copies are actually written there. The six artifacts below answer those questions, and each one goes stale unless someone refreshes it on a schedule between audits.

Asset-to-destination coverage report

This report lists every in-scope asset next to the isolated destination its backups are sent to, with a status for each. It is the artifact that supports the Coverage measure in the CIS Controls Assessment Specification, which asks for the share of assets configured to send backups to an isolated instance. Start from the asset inventory required by Safeguard 1.1, so that a missing asset shows up as a gap rather than disappearing. Regenerate it monthly and reconcile it against the inventory each time new systems are onboarded.

Backup job configuration exports

Export the Bareos Director job and fileset definitions, or the restic repository and schedule settings, to version-controlled files. These exports prove which destination each job writes to and that the setting has not drifted. Store them in a configuration repository with change approval, so an assessor can see who altered a destination and when. Compare the exports against live configuration after each change window, because an out-of-band edit can silently redirect a backup away from the isolated copy.

Destination access control lists and credential records

Document who and what can write to, read from, or delete the isolated destination, and where the credentials for it are held. The separation matters: the backup client should hold credentials that can add data but not erase or rewrite prior versions, and the administrative credentials should sit apart from production identities. Keep a register that names each credential, its owner, its scope and its last rotation date. Review the register on the same cadence as the access reviews required by Control 6, and confirm that no production administrator also controls the destination.

Retention and version settings

Retention settings show how many versions the isolated destination keeps and for how long, which is the evidence that a clean copy from before an incident survives. Record the retention policy, the immutability or object lock settings if the platform provides them, and the pruning schedule that applies to the isolated copy. Confirm with the platform documentation whether a given retention or lock feature is available in your deployment before you claim it. Check settings after every platform upgrade, since pruning defaults can change.

Job logs showing isolated copies are written

Logs from successful jobs are the proof that copies actually reach the isolated destination, not just that the configuration points there. Retain the Bareos job reports or restic command output, and keep the timestamps, the destination identifier and the result for each run. Sample logs from several dates, including one from a period that had no incidents, and compare them with the coverage report. Failed and skipped jobs need the same retention, because they show when the isolated copy fell behind.

Documented exceptions

Some assets cannot send backups to an isolated instance, such as a legacy system with an unsupported client or a device with limited storage. Record each exception with the asset, the reason, the compensating control, the named risk owner, and an expiry date for the exception. An assessor will test whether exceptions are approved and reviewed, so an undocumented gap is worse than an open exception. Review the exception register at each coverage report cycle and close entries as assets are migrated.

What an isolated copy costs to meet and what drives it up

This table breaks down who is paid for each part of meeting Safeguard 11.4, whether the cost is one-time or recurring, and what pushes it higher. Use it to frame a quote request, since no price list applies and every figure depends on the written scope and your environment.

Cost component	Who is paid	One-time or recurring	What drives it up
Storage for the isolated copy	Cloud provider, data center operator or hardware vendor, plus internal teams for capacity planning	Recurring, scaling with each backup cycle	Total data volume, retention periods, number of versioned generations kept, and copies held in more than one isolated location
Backup software (Bareos, restic)	No license spend for Bareos (AGPL-3.0-only) or restic (BSD-2-Clause); costs fall to the hosts, storage and staff that run them	One-time setup, then recurring operations effort	Number of in-scope assets, job schedules, catalog size, and whether separate backup hosts are needed for isolation
Isolation design and credential separation	Internal architects or an implementation partner preparing the design, network paths and separate administrative identities	One-time design, with revisions when the environment changes	Number of backup destinations, complexity of network segmentation, and how many separate identity systems must be built
Asset coverage mapping	Internal asset owners and the team maintaining the inventory that Safeguards 1.1 and 4.1 require	Initial mapping, then recurring updates as assets change	Number of in-scope assets, how often assets are added or retired, and how current the configuration process is
Evidence upkeep	Internal compliance or security staff, sometimes with a partner preparing the records	Recurring, usually tied to each review cycle	Frequency of coverage reports, how many systems produce separate logs, and whether evidence is collected by hand
Recovery testing of the isolated copy	Internal operations staff, with time spent on restores from the isolated instance	Recurring	Size of the restore sample, the number of isolated destinations to prove, and the effort needed to rebuild a clean recovery environment
External review	An independent assessor or consultant, if you choose to buy one	Usually one-time per review, sometimes recurring	Scope of the review, number of environments examined, and whether the reviewer must rebuild the setup to test it
Auditor sampling	Your external auditor, when a framework or contract requires an audit	Recurring per audit cycle	Number of backup destinations and assets sampled, and how many isolated copies must be produced with dated evidence

Which open-source backup tools produce 11.4 evidence

Two open-source tools can produce the records an assessor asks for under Safeguard 11.4: a scheduler and catalog, and a verifiable repository. Neither makes a copy isolated on its own, so the destination and credential design the organization sets up decide whether the evidence holds.

Bareos director as job record

The Bareos Director schedules backup, restore, verify and archive jobs and supervises them, and it keeps a SQL catalog of backed-up files. For Safeguard 11.4, the job schedule and catalog show which assets send backups to a designated destination, which is the basis for the Coverage measure. Check that every in-scope asset has a client and job definition that points at the isolated storage pool, and export the job configuration and catalog reports as dated evidence. Bareos is licensed under AGPL-3.0-only, so confirm with counsel whether that license works for how your organization will distribute or host it.

Bareos restore from prior states

Bareos can restore files selected from the current backup or from one taken before a given date and time. An assessor looking at an isolated copy will want to see that a clean, pre-incident version still exists and can be selected after the primary environment is compromised. Run a restore drill from the isolated pool, not the primary storage, and record which backup version was restored. This ties the isolated copy to the recovery testing in Safeguard 11.5.

Restic repository checks

restic is licensed under BSD-2-Clause, a permissive license that most organizations can review quickly. Its check command verifies the structural consistency of snapshots, trees and pack files. Adding --read-data or --read-data-subset reads pack files back to confirm the stored backup data is unmodified. Schedule these checks against the isolated repository and keep the output, since a passing run on an immutable, separately credentialed repository is direct evidence that the isolated copy is intact.

Read-data checks on sample sets

A full read of every pack file can be slow and costly in egress fees for cloud destinations. The --read-data-subset option lets you verify a defined portion of the repository on each run, which is useful for showing regular integrity checks without reading everything each time. Document the subset rule, how it rotates across runs, and how often a full read is performed, so the assessor can see the method rather than a single run.

Isolation depends on your design

Neither tool makes a copy isolated by itself. Isolation comes from where the copy sits and who can change it: a separate account or tenant, immutable or write-once storage, offline or off-site media, and credentials that the production environment cannot use to delete or overwrite backups. Record the destination type, the credential boundary and the retention lock settings as design evidence. Ask your implementation partner and your cloud or storage vendor to confirm which of these controls your chosen destination supports.

Evidence to retain for assessors

Keep a short evidence set for each isolated repository: the job or repository configuration, the destination and credential design, the coverage list of assets, recent check and restore logs, and any change records for the retention settings. Store these outside the primary environment so an attacker who compromises production cannot alter them. An assessor will test the records against the Coverage metric, so match asset names across inventory, job definitions and logs.

Who owns the isolation controls, who helps, and who certifies

Your organization owns Safeguard 11.4. The CIS Controls are a self-assessment baseline, and no one else can decide which assets need an isolated recovery copy, how long copies are kept, or who may approve a restore. Those decisions belong in the data recovery process described under Safeguard 11.1, and they should be signed off by people accountable for the business services that depend on the data.

Scope and recovery priorities: Decide which in-scope assets must have an isolated copy and document the reasoning, using the asset inventory that Safeguards 1.1 and 4.1 call for.
Credentials and key custody: Hold the keys, passphrases and administrator accounts for the isolated destination separately from the production directory, and review who can delete or overwrite recovery data.
Destination choice: Select the offline, cloud or off-site target and accept the residual risk of the chosen model, including who operates it.
Recovery decisions: Name the people who authorize a restore after an incident and the order in which systems come back.
Ongoing operation: Own the Coverage measure, meaning the share of assets configured to send backups to an isolated instance, and review it on a schedule.

Before engaging anyone, check that you can name each owner in writing and show the Coverage figure for your own environment.

An implementation partner such as DeployOpen can plan, configure and document the isolated copy inside your own cloud accounts, data centers or air-gapped networks. The partner prepares systems and evidence. It does not decide scope, hold your recovery authority, or certify that the control works. Work is normally fixed in a written scope with defined deliverables and timelines agreed before work starts.

Architecture and configuration: Set up the isolated destination, such as a versioned repository or an immutable object store, and connect it to your backup jobs.
Open-source tooling: Deploy platforms such as Bareos, whose Director schedules backup, restore, verify and archive jobs and keeps a SQL catalog, or restic, whose check command can read pack files back with --read-data or --read-data-subset.
Evidence preparation: Produce configuration exports, job logs, catalog reports and restore test records that show the isolated copy exists and is current.
Documentation: Write the runbooks and change records that your auditor will ask to see.
Limits: The partner cannot issue an audit report, attestation or certificate, and it should not be asked to rate its own work as compliant.

Ask for the written scope, the list of deliverables and the named evidence artifacts before signing, and confirm whether the partner will also support the restore tests tied to Safeguard 11.5.

Where organizations fail 11.4 and how to close each gap

Safeguard 11.4 is easy to claim and hard to prove. The gaps below share one root cause: the isolated copy exists on paper but is not separated, complete, restorable or current when it is needed. Each card names a failure point and the check that closes it.

Isolated copy reachable with production admin credentials

An isolated copy that the production domain administrator can delete is not isolated. Ransomware that gains domain admin rights can reach the backup console, the storage account and the retention settings in one pass. Review who holds credentials for the backup server, the storage target and the cloud account that hosts the copy, and confirm that those identities are separate from production administrators. Test by attempting a delete of the latest recovery point using a production admin account. The attempt should fail.

Assets missing from backup coverage

Coverage is the metric the CIS assessment specification uses for 11.4, so every asset left out of the backup job is a gap in the score. Servers added after the last job configuration, virtual machines moved between hosts and laptops outside the backup schedule are common causes. Reconcile the asset inventory from Safeguard 1.1 against the list of hosts configured to send backups to the isolated destination. Any asset without a matching job should be assigned an owner or formally excluded with a documented reason.

Untested restore paths

An isolated copy that has never been restored from is an assumption, not a recovery capability. Restores from an off-site or cloud destination often fail on credentials, bandwidth, decryption keys or missing catalog entries that only appear under real conditions. Schedule restores from the isolated copy, not the local backup, and record the time taken and any manual steps. Tools such as Bareos keep a catalog of backed-up files, and restic can verify pack file integrity, so confirm both the restore and the integrity check run against the isolated destination.

Retention shorter than detection time

Ransomware and quiet compromises can sit inside an environment for a long time before anyone notices. If the isolated copy keeps only a short rolling window, every recovery point may already contain encrypted or tampered data by the time the incident is found. Compare the retention period of the isolated destination with the organization's realistic detection and dwell time estimates from incident reviews. Keep enough versions that a clean, pre-compromise point still exists, and confirm with the incident response team how far back they would need to restore.

Cloud and SaaS data outside the inventory

Mail, collaboration suites, code repositories and SaaS platforms often hold business records that never reach the on-premises backup job. The provider's built-in retention may be shorter than the organization's own recovery requirement, and the copy may sit in the same tenant as production. Add each cloud and SaaS data store to the inventory, record who owns its recovery, and decide whether an isolated copy is needed outside the provider account. Ask providers in writing what retention, deletion protection and tenant separation they offer for backup data.

Recovery data without a secure configuration baseline

The isolated destination is only as trustworthy as its configuration. Immutability settings, object lock, retention locks and access policies are often set once and then changed during routine storage maintenance. Include the isolated destination in the secure configuration process from Safeguard 4.1, record the approved settings, and check them on a schedule. Changes to deletion protection or retention should require a documented approval, so the isolation cannot be quietly removed.

Questions buyers ask about Safeguard 11.4

How much effort does it take to keep an isolated copy of recovery data?

Effort depends mainly on how many in-scope assets send backups to an isolated destination and how that destination is built. The work has four parts: choosing the isolated target (offline media, a separate cloud account or an off-site versioned repository), configuring each backup job to write there, setting retention so older versions survive, and keeping an inventory that shows which assets are covered. Setup is a one-time cost. Storage, bandwidth, monitoring of failed jobs and periodic access reviews recur every year. Ask any partner to split its quote into one-time build work and recurring operating work, and to name the assets in scope.

Can our own team implement Safeguard 11.4 without outside help?

Many teams can, provided they already run backups, own an asset inventory and can manage access to a second storage location. Safeguard 11.4 is measured through a Coverage metric, so the team must be able to show which assets send backups to the isolated instance. Internal staff often struggle with separating administrative credentials for the isolated copy from the production environment, and with proving that the copy is not reachable from the same identity that runs production. An implementation partner can prepare the configuration and evidence, but your organization still owns the control and its results.

Does Safeguard 11.4 require offline or air-gapped media?

No. CIS gives version-controlled backup destinations in offline, cloud or off-site systems or services as example implementations. What the Safeguard asks is that an isolated instance exists and is maintained, meaning a copy that a compromise of the primary environment cannot easily reach, alter or delete. Tape, a write-once or immutable object store in a separate account, and a versioned repository on separate credentials can each meet that intent if the isolation is real and documented. Confirm with your assessor how they will test isolation for the option you choose.

How does Safeguard 11.4 differ from 11.3 and 11.5?

Safeguard 11.3 asks that backup and recovery data receive the same protection as the original data, such as encryption or separation. Safeguard 11.4 asks for an isolated instance of that data, so a copy survives if the primary environment is compromised. Safeguard 11.5 asks you to test recovery from backups on a sample of in-scope assets at least quarterly, which shows that restores work. Each safeguard produces different evidence: 11.3 shows protection settings, 11.4 shows isolated destinations and coverage, and 11.5 shows restore test records.

Does an isolated copy alone prove that we can recover?

No. An isolated copy shows that data is stored somewhere a compromise is unlikely to reach. It does not show that the data can be read, that it is complete or that systems can be rebuilt from it. Restore testing under Safeguard 11.5 provides that proof. Tools such as restic can check repository structure and, with its read-data options, read pack files back to confirm stored data is unmodified. Bareos can run verify jobs and restore from a chosen point in time. Both support the evidence chain, but a restore exercise on real assets still has to be recorded.

What should we ask an implementation partner to include in a fixed-scope quote?

Ask for the written scope to list the in-scope assets, the isolated destinations and their technologies, the backup tools and versions to be configured, and the retention rules applied to the isolated copy. The quote should separate one-time design and build from recurring operation, name what evidence will be delivered (asset coverage records, configuration exports, access lists, job logs), and state what the organization must provide, such as access, asset inventory data and decision makers. Confirm whether the partner will also support the prerequisite work tied to Safeguards 1.1 and 4.1, and whether the engagement excludes any audit activity.

How long does this take to implement?

The duration depends on scope: the number of in-scope assets, how many backup jobs must be redirected, whether the isolated destination already exists, and how much access separation has to be designed. Your organization should ask a partner for a timeline tied to the written scope rather than relying on a general estimate. Confirm internally whether your asset inventory (Safeguard 1.1) and secure configuration process (Safeguard 4.1) are current, since both are prerequisites for measuring 11.4.

How 11.4 maps to NIST SP 800-53, ISO 27001 and PCI DSS

The CIS Controls Navigator links Safeguard 11.4 to three other frameworks: NIST SP 800-53 Rev. 5 controls CP-6, CP-6(1), CP-9(3) and CP-9(5), ISO/IEC 27001:2022 Annex A control 8.13, and PCI DSS v4.0 requirement 9.4.1. The mappings tell you where the same underlying need, an isolated copy of recovery data that survives a compromise of the primary environment, shows up in each framework's language. They do not tell you that passing 11.4 passes those controls. Treat each mapping as a starting point for finding the evidence you already need, and confirm the exact wording and scope of each target control against the framework itself before you cite it in a submission. The Navigator is maintained by CIS and is available at CIS Controls Navigator.

Each framework has its own assessor, and that assessor decides whether your evidence meets its requirement. A NIST SP 800-53 assessment looks at the contingency planning family, so the questions concern the alternate storage site, backup protection and whether recovery data is separated from the system it protects. An ISO/IEC 27001 certification body looks at Annex A 8.13 through your information backup policy, the frequency and scope of backups, and restoration tests. A PCI DSS assessor, working from requirement 9.4.1, will ask whether media holding cardholder data is physically secured and whether the backup copy sits under the same controls as the cardholder data environment. Ask each assessor early which evidence they will accept, because the same isolated copy may need different documentation for each.

Practically, build one evidence set and label it per framework: the backup architecture diagram showing the isolated destination, the configuration exports that prove the copy is written to it, access lists for that destination, and the most recent restore test. Confirm with your scoping or compliance lead whether the isolated copy falls inside your PCI DSS cardholder data environment, since that decision changes which controls apply. Where an implementation partner prepares the configuration and evidence, the mapping work is still yours to validate, and only the independent assessor or certification body can confirm that a framework's requirement is met.