What must a CIS data recovery policy say before an assessor will accept it?
If a customer, contract or regulator asks for a data recovery policy aligned to the CIS Controls, the starting point is the free IG1 Data Recovery policy template that CIS publishes, which supports Safeguards 11.1 to 11.4. CIS adds Safeguard 11.5 at IG2. The organization owns the policy and the controls it describes. An implementation partner can prepare the systems, backup configurations and evidence, but only an independent auditor or assessor issues any report or opinion on whether the policy is met. The detail that changes the answer is the scope: which in-scope enterprise assets are covered, how sensitive their data is, and which systems the recovery process must bring back first. Those decisions drive the backup frequency, the protection applied to recovery data and the isolation design, so they should be settled before any template language is adopted.
Safeguard 11.1 asks for a documented data recovery process that addresses the scope of recovery activities, recovery prioritization and the security of backup data. In practice, the policy must name the asset classes in scope, state the order in which systems return to service, and say who may restore data and under what approval. Safeguard 11.2 asks for automated backups of in-scope assets, run weekly or more often depending on how sensitive the data is. The policy should therefore record a frequency for each sensitivity tier rather than a single figure, and the assessor will look for the tiers in the configuration, not only in the document. Safeguard 11.3 expects recovery data to receive protection equivalent to the original data, through encryption or data separation as the requirements dictate. Safeguard 11.4 expects an isolated instance of recovery data to be established and maintained, so the policy should name the isolation method and who checks it.
Before engaging outside help, confirm three things with your own environment: which backup tool produces the evidence, whether that tool can verify backup integrity, and whether the isolated copy is actually separated from production credentials. For example, restic's check command verifies the structural consistency of snapshots and pack files, and with --read-data or --read-data-subset it reads pack files back to confirm stored data is unmodified. Recovery testing is the IG2 addition in Safeguard 11.5, so an IG1 policy can defer it, but a policy submitted to a regulator should already name the test owner, schedule and record format. Review the CIS Controls Policy Templates page and the Control 11 assessment specification side by side before drafting.
Which elements the data recovery policy must set
CIS Control 11 asks for four IG1 Safeguards that work together: a documented recovery process, automated backups, protection of recovery data and an isolated copy. The cards below take them in order, paraphrase what each one asks for, and name the checks an assessor is likely to make against the written policy and the systems behind it.
Recovery process scope and priority
Safeguard 11.1 asks the enterprise to document a data recovery process that defines what recovery covers and the order in which systems and data are restored. The policy should name the in-scope enterprise assets, the owner of the process and the recovery priority for each system category, so that a restore after an incident does not depend on who happens to be on call. Check that the priorities match the business impact agreed with system owners, and that the process also addresses how backup data itself is secured.
Automated backups on a set schedule
Safeguard 11.2 asks for automated backups of in-scope enterprise assets, run weekly or more often depending on how sensitive the data is. The policy should map each data class to a backup frequency and state that the schedule is automated rather than left to individual staff. Confirm that the schedule covers the assets listed in the scope, and that more sensitive data is backed up at a higher frequency than the weekly baseline.
Recovery data protected like the original
Safeguard 11.3 asks that recovery data receive protections equivalent to those on the original data, with encryption or separation applied as the requirements call for. A backup copy of regulated records that sits with weaker access controls than production is a common gap. The policy should require the same access restrictions, encryption expectations and logging for backup repositories and keys, and should name who can read, restore or delete backup data.
Isolated instance of recovery data
Safeguard 11.4 asks for an isolated instance of recovery data to be established and maintained, so that a copy survives an attack that reaches the production network or the primary backup system. The policy should state where the isolated copy lives, how access to it is restricted, and how it is refreshed. Confirm that the isolation is tested in practice by attempting restores from it, not only described in the document.
How the policy changes by environment
On-premises estates keep the workloads, storage and backup targets in facilities the organization controls, so the policy can name physical locations, hosts and storage arrays directly. The scope statement should list every in-scope enterprise asset class and where each one sits, because Safeguard 11.1 asks for the recovery process to address its scope. Backup jobs usually run from a central server against local disks or tape, which makes the policy's frequency and retention rules easy to tie to specific jobs.
- Named scope: list the hosts, databases and file shares that fall under the policy, and link each one to an owner.
- Local backup targets: state where backup repositories live and who can administer them.
- Frequency by sensitivity: set the weekly or more frequent schedule per data class, since 11.2 depends on how sensitive the data is.
- Isolation choice: decide whether the isolated instance under 11.4 is a separate site, an offline tape set or a logically separated repository.
- Restore tests: record which hosts are restored, how often and who signs off.
Confirm with your own platform team that every on-premises asset is in the inventory the policy cites, since unlisted hosts are the usual gap an assessor finds.
In cloud estates, much of the recovery capability is provided by the platform, so the policy has to say which backup features the organization relies on and who configures them. Scope is often defined by accounts, subscriptions or projects rather than by hardware, and resources can be created quickly, so the policy should require that new in-scope resources are added to backup coverage. Isolation usually means a separate account, region or vault with restricted access, but the policy should not assume that a provider feature meets the requirement without checking its configuration.
- Account-based scope: define in-scope accounts, subscriptions or projects and the tagging rule that brings new resources under backup.
- Provider features: name the backup service, retention settings and access roles the policy depends on.
- Separate recovery boundary: place recovery copies in a different account, region or vault with separate administrators.
- Encryption and keys: require recovery data to carry controls equivalent to the source data, including key handling for 11.3.
- Shared responsibility records: document which recovery tasks belong to the provider and which belong to the organization.
Confirm the exact backup features, regional options and retention limits with your cloud provider's current documentation, since these change between services.
Hybrid estates run some workloads on-premises and others in the cloud, so a single backup routine rarely covers both. The policy should define one scope that spans both sides, then state separately how each side is backed up and how recovery data moves between them. The main risk is a recovery path that depends on the environment that failed, such as a cloud copy that can only be restored through an on-premises identity service. Sensitivity-driven frequency should apply the same way on both sides, so a sensitive dataset does not get a weaker schedule because it lives in a different place.
- Unified scope statement: cover both sides in one list of in-scope assets with an environment field.
- Cross-environment copies: state whether recovery data is copied between sites and how transfers are protected.
- Independent recovery path: confirm that restoring the cloud copy does not require the failed on-premises directory.
- Consistent frequency: apply the same sensitivity classes to both environments.
- Dual testing: test restores on each side, not only the side that is easier to reach.
Check that each isolated instance remains reachable during an incident that takes down the primary environment.
Air-gapped networks have no routine connection to outside networks, so the policy must describe how recovery data crosses the gap and how its integrity is confirmed before it is trusted. Isolation is a property the environment already provides, but the policy still has to set who can introduce media or transfer files, how those transfers are logged and how often the isolated copy is refreshed. Frequency may be limited by how often approved transfers happen, so the policy should tie the schedule to the sensitivity of the data and document any gap between the two. Recovery testing matters more here because a failed restore cannot be fixed by pulling a copy from elsewhere.
- Transfer procedure: define the approved path for moving backup data across the boundary and who authorizes it.
- Media handling: record how removable media is labeled, stored, wiped and retired.
- Integrity checks: verify backups after transfer, for example with restic
check --read-datawhere the tool is used. - Refresh schedule: set how often the isolated copy is updated and document any gap against the sensitivity rule.
- Offline restore drills: test restores using only the materials held inside the network.
Confirm with your accreditation or security authority which transfer methods the environment permits before the policy is finalized.
How an assessor tests the policy and the backups
The assessment specification for Control 11 moves from the written process to the backup jobs, the protection of recovery data and the isolated copy, so each step leaves a document, log or configuration export that a reviewer can trace back to the Safeguard it supports.
Review the documented data recovery process
The assessor starts with the written data recovery process required by Safeguard 11.1. They check that it states the scope of recovery activities, how assets and data sets are prioritized for recovery, and how backup data is secured. The organization's owner of the process walks the assessor through it and confirms it matches current practice. The step is complete when the assessor has the approved document, its version history and a list of the in-scope enterprise assets it refers to. Gaps here usually show up as backups that exist but are not tied to any stated priority.
Confirm the in-scope asset list matches backup coverage
Next, the assessor compares the in-scope enterprise assets named in the process with the systems the backup tooling actually covers. The organization exports the backup job target lists and the asset inventory, and the assessor checks that each in-scope system appears in a job. Systems that sit outside every job are recorded as exceptions for the organization to resolve. The output is a reconciliation sheet showing covered and uncovered assets, which becomes the starting point for the rest of the test.
Examine automated backup job schedules and logs
For Safeguard 11.2, the assessor looks for automated backups of in-scope assets running weekly or more often, with the frequency set according to how sensitive the data is. The organization provides scheduler configuration exports and job run logs covering a period the assessor selects. The assessor checks that jobs ran on their scheduled cadence, that failures were recorded and followed up, and that the frequency matches the sensitivity rating in the process. The step closes when the logs show consistent runs for each covered asset.
Verify backup integrity with restore checks
Running jobs do not prove that recoverable data exists, so the assessor asks for evidence that backups can be read back. The organization runs integrity checks on its repositories and records the output. For restic-based repositories, the check command verifies the structure of snapshots, trees and pack files, and with the read-data option it reads pack files back to confirm the stored data is unmodified. The output is the check log with its date, repository name and result, which the assessor can compare against the job schedule.
Inspect protection and encryption of recovery data
For Safeguard 11.3, the assessor checks that recovery data receives controls equivalent to those on the original data. This means reviewing encryption settings on backup repositories, key custody, access control lists on backup storage and whether backup administrators are separated from production administrators where the requirements call for it. The organization provides configuration exports and access review records. The step is complete when each repository's encryption and access settings are documented and matched against the controls applied to its source data.
Confirm an isolated copy exists and is maintained
Safeguard 11.4 asks for an isolated instance of recovery data. The assessor looks for a copy that is separated from the production environment and its usual administrative access, such as an offline medium, a separate account or an immutable storage location. The organization shows where the copy sits, how it is refreshed and who can reach it. The assessor then samples the isolated copy's last update against the backup schedule. The output is a diagram or configuration export of the isolation boundary plus the refresh log.
Record findings against each Safeguard
The assessor closes the test by mapping every artifact to Safeguards 11.1 to 11.4 and recording any gap, such as an uncovered asset, a missed job or an isolated copy that was not refreshed. Where Control 11 is assessed at IG2, the additional Safeguard 11.5 is tested in the same way. The organization receives a findings list and decides on remediation owners. Only the independent assessor or certification body issues the formal result; the implementation partner's role is to have the documents, logs and exports ready and accurate before the assessor arrives.
How open-source backup tooling produces the evidence
Backup tools produce records as a side effect of running, and those records can serve as evidence for Safeguards 11.2 and 11.3. The cards below cover the tool checks, the logs and the restore test records an assessor is likely to ask for. Confirm each feature against the tool your team actually chooses.
Repository consistency checks
The restic check command verifies the structural consistency of snapshots, trees and pack files in a repository. Scheduling it and keeping the output gives you a dated record that the repository's index and metadata were consistent at each run. This shows the backup store itself was intact, which supports the security of backup data named in Safeguard 11.1. Ask your team to confirm the check schedule and where the output is stored.
Data read-back verification
Running restic check with --read-data or --read-data-subset reads pack files back and confirms the stored backup data is unmodified. A full read-back is thorough but takes longer, so many teams rotate a subset on each run and cover the whole repository over time. Record which option ran and what subset was read, because the assessor will want to see that the stored data itself was verified, not only its structure.
Automated backup job logs
Scheduler and backup job logs show that automated backups of in-scope assets ran at the frequency your policy sets, which Safeguard 11.2 ties to data sensitivity. Keep logs that record the start time, the asset or path, the result and any error, and retain them long enough to cover the assessment window. Gaps in the log sequence are the first thing an assessor will question, so alert on missed runs.
Encryption and separation settings
For Safeguard 11.3, the evidence is configuration: how the repository is encrypted, where its keys are held and whether the recovery copy is separated from the production systems it protects. restic encrypts repository data by default, so the settings to document are the key custody model and access to the repository. Export the relevant configuration and access lists on a schedule, and confirm the encryption behavior against the version you deploy.
Isolated copy and access records
Safeguard 11.4 asks for an isolated instance of recovery data. Evidence here includes the network and account boundary around the backup target, the credentials that can write to or delete from it, and the access logs for those credentials. A recovery copy that the production administrator can delete with the same login is hard to defend, so record who holds delete rights and how that changes.
Restore test records
A restore test record names the snapshot, the target, the person who ran the restore, the time taken and whether the restored data matched expectations. These records connect backup logs to proof of recovery, which is the question an assessor asks after reading the policy. Schedule restores from different systems and keep the results in your change or ticket system so they can be traced to the policy requirement.
What recovery testing at IG2 adds to the policy
Safeguard 11.5 is the IG2 addition to Control 11, and it is the part of the data recovery policy that the IG1 template does not cover. CIS publishes its policy templates only for IG1 Safeguards, so the recovery testing requirement has to be written into the organization's own policy. The Safeguard asks for recovery processes to be tested, so the policy should name who schedules the tests, which systems and data sets are in the test scope, how often a test runs, and who signs off the result. Treat the test as a control in its own right, not a side task for the backup administrator.
A tested restore record should show enough for an assessor to reconstruct what happened without asking the team to explain it. At minimum, record the date, the backup set or snapshot identifier, the systems or data restored, the target environment, the person who ran the restore, the elapsed time against the recovery priority the policy assigned, and whether the restored data matched the expected state. Failed restores belong in the record too, with the cause and the corrective action. For file-level backups, a verification step such as restic's check command with --read-data or --read-data-subset can show that stored pack files read back intact, which is a different question from whether the business application works after restore. Confirm both with the vendor documentation and your own environment before you rely on either.
IG2 and IG3 Safeguards are not covered by CIS policy templates, so the organization must do the policy work itself for these requirements. Ask whether your backup platform, your recovery runbooks and your test calendar can produce the restore records described above without manual reconstruction. An implementation partner can prepare the test plan, the restore runbooks and the evidence format, but the organization owns the policy, approves the scope and decides how much recovery risk it accepts.
Who is paid for what when building this policy
This table shows who is paid for each cost of writing and running a CIS-aligned data recovery policy, whether each cost is one-time or recurring, and what pushes it up or down. Use it to scope a quote, because most of the cost sits in backup tooling, isolation and recurring restore testing rather than in the document itself. No fixed prices or durations are given, so ask each party for a written estimate tied to your environment.
| Cost component | Who is paid | One-time or recurring | What drives it |
|---|---|---|---|
| Internal policy owner time | Your own staff (no external payee) | One-time to write, recurring to review | Number of in-scope asset classes, and how many teams must sign off on recovery priorities |
| Implementation partner for backup and isolation setup | External implementation partner, under a written fixed scope | One-time | Number of backup sources, and whether an isolated recovery instance must be built for Safeguard 11.4 |
| Backup tooling and storage | Software vendors or open-source projects (licence or none), your cloud or data center provider for storage | Mostly recurring (storage, compute, support) | Data volume, snapshot retention, backup frequency set by data sensitivity, and encryption or separation requirements under Safeguard 11.3 |
| Independent assessor, if an assessment is required | Independent auditor or assessor, not DeployOpen | One-time per assessment cycle | Which framework your customers or regulators require, and how many Safeguards and evidence samples the assessor tests |
| Ongoing restore testing | Your own operations staff, or a retainer with an implementation partner | Recurring | Size of the recovery scope, how often you test restores, and whether tests cover the isolated instance as well as production |
Where data recovery policy projects stall
Data recovery policies usually fail in the gap between what is written and what runs. The four cards below cover the points where CIS Control 11 projects most often stall, from untested backups to frequency claims the jobs do not meet. Each card names a prevention step to check before the policy is signed.
Backups that run but never restore
A backup job reporting success proves only that data was written somewhere. Safeguard 11.1 expects a documented recovery process, and recovery is only proven when a restore completes. Teams often run jobs for years without restoring a file, a database or a full system. Prevention: schedule restore tests against sample data from each in-scope system, record the time taken and the result, and treat a failed restore as an incident under the policy. The restore test log is the evidence an assessor will ask to see.
Isolated copy sharing production credentials
Safeguard 11.4 asks for an isolated instance of recovery data. A copy that uses the same administrator accounts, service credentials or backup encryption keys as production can be altered or deleted by an attacker who has compromised production. Prevention: give the recovery store its own identity store, separate administrator accounts, and key material held outside the production trust boundary. Check that a production administrator cannot delete or overwrite recovery snapshots without a second approval path.
Undefined recovery priorities
Safeguard 11.1 requires the recovery process to address prioritization. When priorities are missing, teams restore whichever system is loudest, and directory services, identity providers and key management often wait behind less critical applications. Prevention: rank in-scope systems in writing, tie each rank to a recovery order and an owner, and confirm that the order matches the dependencies in the environment. Review the ranking whenever a major system is added or retired.
Frequency claims the jobs do not meet
Safeguard 11.2 asks for automated backups run weekly or more often, depending on how sensitive the data is. A policy that promises daily backups for data held in a job scheduled monthly creates a gap that surfaces only during an incident. Prevention: write the frequency for each data class in the policy, then compare it against the scheduler configuration and the backup job history. Any mismatch should be fixed in the job or in the policy, whichever reflects the agreed risk.
Data recovery policy questions buyers ask
Is the free CIS data recovery policy template enough to meet Control 11?
A template is a starting point, not a finished control. CIS publishes its policy templates free, aligned to CIS Controls v8 and v8.1, and they cater exclusively to IG1 Safeguards. The Data Recovery template maps to Control 11, which has four IG1 Safeguards (11.1 to 11.4). Adopting the text does not satisfy the Safeguards on its own. Your organization must still fill in its own scope, recovery priorities, backup schedule, isolation method and restore test records, then run the process and keep evidence that it works. The assessment specification checks the documented process and its operation, so a template left unedited will not show that.
- Replace generic wording with your in-scope asset classes and named owners.
- Record how sensitivity sets backup frequency and who approved it.
- Keep dated evidence of backups, isolation and restore tests.
What does the data recovery policy ask of internal staff?
Internal staff must own the decisions and the routine work that the policy describes. The policy assigns accountability for the recovery process, the list of in-scope assets and their recovery priority, the backup configuration, and the protection of backup data. Operations staff run and monitor automated backups, keep records of restore tests, and act when a backup fails. Security or compliance staff review whether backup data is protected to the same standard as the original data and whether an isolated copy exists. Leadership signs off on the process and on any exceptions. An outside partner can prepare the systems and documentation, but these roles need named people inside your organization.
Is meeting IG1 enough for data recovery, or do we need IG2?
IG1 covers the essential baseline, and for Control 11 it is four Safeguards. CIS defines IG1 as essential cyber hygiene and a minimum standard for every enterprise. IG2 adds Safeguard 11.5 for enterprises with more operational complexity that often hold sensitive information. The 11.5 Safeguard is recovery testing, so an organization handling sensitive data or running complex operations should plan for it. Which Implementation Group applies depends on your size, the sensitivity of your data and your regulatory obligations. Confirm the IG with your risk owner and any regulator or contract that names it, rather than assuming the lowest group is sufficient.
Who can assess whether our data recovery controls meet CIS Control 11?
Assessment is done by an independent assessor chosen by the organization or by the party requiring the evidence, such as a customer, auditor or regulator. CIS itself does not issue certificates of compliance for the Controls. CIS Controls Accreditation, run with CREST, accredits CIS SecureSuite member organizations that provide implementation, auditing or assessment services, and CIS lists an application fee of $1,500 for CREST members and $2,500 for non-members. Ask any assessor whether it holds that accreditation, how it measures Safeguard 11.1 through 11.5 against the assessment specification, and which evidence it will request. Confirm whether your own internal audit or a regulator will accept the results.
Can a partner write the data recovery policy for us?
A partner can draft the policy, but the organization must own and approve it. DeployOpen plans, implements, hardens, backs up, documents and supports self-hosted open-source platforms inside the client's own infrastructure, and it prepares systems, controls and evidence for compliance assessments. DeployOpen does not issue audit reports, attestations or certifications. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. A useful written scope would list the policy sections to draft, the backup and isolation configuration to build, the restore tests to run and the evidence to hand over. Ask for the written scope before committing, and confirm who signs the final policy.
How should we decide how often backups run?
Backup frequency is set by how sensitive the data is, and Safeguard 11.2 asks for automated backups of in-scope enterprise assets at a weekly or more frequent interval. The policy should define the sensitivity tiers, the frequency for each tier and who approves the decision. Consider the data's classification, how much data loss the business can tolerate, regulatory expectations for that data, and how quickly systems must return to a trusted state. A tier with high sensitivity will usually need more frequent backups than a tier with low sensitivity. Write the decision down, review it when classifications change, and keep logs that show the schedule ran. Confirm the required interval with your regulator or contract when one applies.
Can an open-source tool like restic produce the backup evidence we need?
restic can produce useful backup evidence, but the tool does not decide policy or prove compliance on its own. Its 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 the stored backup data is unmodified. Those check runs, together with backup logs and restore test records, can support Safeguards 11.2 and 11.3. Confirm how your restore tests and isolated copy are configured, since restic does not establish isolation by itself. The restic repository documentation explains how to work with repositories and is the right next read for the commands your team will run.
How DeployOpen prepares backup and isolation evidence
DeployOpen plans, implements, backs up, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For CIS Control 11, we help the organization prepare the recovery process, the backup configuration and the isolated recovery copy, while the organization keeps ownership of its policy and controls.
How we scope
- Agree in writing which in-scope enterprise assets and data sets the recovery process covers for Safeguard 11.1.
- Record recovery priorities for each system so the policy reflects how the organization ranks its critical data.
- Confirm backup frequency per data sensitivity, since Safeguard 11.2 asks for weekly or more often depending on sensitivity.
How we build
- Configure automated backups of in-scope assets in the client's cloud accounts, data centers or air-gapped networks.
- Apply encryption or data separation to recovery data so protection matches the original data, as Safeguard 11.3 expects.
- Establish an isolated recovery copy under Safeguard 11.4 and test restores against it using tools such as restic.
How we hand over
- Document the recovery process, backup schedules, isolation design and restore test records as evidence for the assessor.
- Map each deliverable to the Safeguard it supports so the organization can show the assessment specification's checks.
- Walk the client's owners through the handover so they can run backup verification and restore tests without us.
How we support
- Offer ongoing support, upgrades and recovery testing as a retainer after the fixed-scope engagement ends.
- Review backup logs and restore test results at agreed intervals and update documentation when systems change.
- Note that independent auditors, not DeployOpen, assess the controls and issue any report or certificate.
