CIS 11.1 Data recovery process: requirements and evidence

What the CIS Safeguard 11.1 data recovery process requires

Safeguard 11.1 asks for a documented data recovery process that sets the scope of recovery activities, the order in which systems and data are restored, and how backup data itself is secured. It is the governing document for CIS Control 11. The technical safeguards that follow it, automated backups, protection of recovery data, isolated copies and recovery testing, all depend on this process to define what must be recovered, how quickly, and under whose authority. If an audit, a customer questionnaire or an internal plan asks for proof of recovery readiness, this is the first document the reader will expect to see. The risk it addresses is recovery being improvised during an incident. Without an agreed process, teams argue about which systems matter most while ransomware or a failed change is still spreading, backups are restored from the wrong point in time, and nobody knows whether the backup repository was itself compromised. The safeguard is hard in practice because ownership is split. IT operates the backup platform, business owners decide which data and applications are critical, and a managed service provider or cloud vendor may hold part of the recovery chain. The document also goes stale quickly when systems move, are retired or change owners.

Safeguard 11.1 is classed under the Documentation asset class and the Govern security function, and it sits in Implementation Group 1, so it applies to every enterprise regardless of size or maturity. Under the CIS Controls Assessment Specification, it is scored on completeness, meaning the share of required elements the process actually includes, and an enterprise with no data recovery process fails outright. Before drafting, confirm the current wording and measures in the CIS Controls Assessment Specification for Safeguard 11.1, since the specification is the document an assessor will test against. The practical first step is to name an accountable owner, list the in-scope enterprise assets and data sets, and agree recovery priorities with the business owners who will have to sign off on them. CIS asks for this document to be reviewed at least annually and sooner after significant enterprise changes, such as a cloud migration, an acquisition or a new backup provider. Confirm with your own environment how those review triggers will be recorded, and keep the approved version and review history in a system that tracks who changed what and when, so the document itself can be evidence.

Which systems, data, teams and providers the recovery process must cover

The scope statement in the Safeguard 11.1 document is the first thing an assessor compares against your asset inventory from Control 1 and your data inventory from Control 3. Four decisions shape that statement: which assets and data classes are in, which priority tiers the business agrees, who owns each recovery step, and which providers the process depends on.

In-scope assets and data classes

Start by listing the enterprise assets and data classes that the recovery process covers, drawn directly from the Control 1 asset inventory and the Control 3 data inventory. Check that every system holding sensitive data appears, and that nothing in the scope statement refers to an asset that no longer exists. Ask whether SaaS platforms, endpoints and cloud storage buckets are in or out, and record the reason for each exclusion so the assessor can follow the decision.

Recovery priority tiers

Recovery priorities decide which systems return first after an incident. Business owners, not only IT, must agree the tiers, because they set the order of restoration and the acceptable loss of data. Document each tier with the systems it contains and the owner who signed off. An assessor will look for priorities that match the business impact, not a list that IT wrote alone.

Teams that own recovery steps

Name a responsible team for each recovery step, including declaring an incident, selecting a backup, restoring data, validating integrity and approving return to service. Include backup administrators, application owners and the people who can authorize restores outside business hours. Confirm that the named roles and their deputies are current, because a process that lists people who have left the organization will not stand up to review.

Third-party backup and cloud providers

Where a backup service, managed hosting provider or cloud platform holds recovery data, the process must state how recovery works through that provider. Record the restore request path, the expected recovery terms in the contract and who can escalate a failed restore. Review these terms with procurement and legal, and confirm them against the provider's written service documentation rather than assumptions.

Security of backup data

The process must address the security of backup data, so define who may access backup copies, where they are stored and how restore credentials are controlled. Treat backup repositories as sensitive stores that carry the same classification as the source data. Confirm that the scope includes the backup servers, catalogs and key material, since an attacker who reaches those can compromise recovery.

How an assessor tests the CIS Safeguard 11.1 data recovery process

This table sets out how an assessor checks Safeguard 11.1 step by step, the evidence each step asks for, and the findings that most often cause a failing score. Read it as a pre-assessment checklist: each row is a test the documented process must pass before the enterprise can show the Safeguard is implemented.

Test area	Evidence requested	Common findings
Document exists and is approved	The written data recovery process, version history, and the named approver or owner who signed off on it	No written process exists, so the Safeguard scores as a failure; or a draft is circulated but never approved
Scope of recovery activities	A scope statement listing which in-scope enterprise assets, data stores and systems the process covers	Scope is implied rather than written, or excludes SaaS, cloud workloads or endpoints that hold sensitive data
Recovery prioritization	A priority order for systems and data restoration, with the reasoning tied to business impact or data sensitivity	Priorities are missing, or every system is marked equally critical, which gives no restoration order
Security of backup data	Statements on how backup data is protected, such as access restriction, encryption and separation from the primary environment	Backup data is described only as copied, with no statement on who can access or alter it
Review date and currency	The last review date, the review record, and any change log showing updates after significant enterprise changes	Last review is older than one year with no later change record; or a major migration or acquisition passed without an update
Completeness of elements	A checklist of required elements compared against the document, showing which are present and which are absent	Completeness is judged by eye rather than by counting elements, so partial documents pass informally and fail on review
Prerequisites and dependencies	Confirmation that no prerequisite safeguards are required before measuring 11.1, and the assessor's notes on that check	Teams assume other safeguards must be finished first and delay the assessment, although 11.1 has no listed prerequisites

How to build and approve the recovery process step by step

This sequence turns Safeguard 11.1 into a written, owned and reviewed data recovery process that defines what is recovered, in what order, how backup data is protected, and who is accountable for keeping it current.

Define recovery scope from inventories
Start from the asset inventory and the data inventory that Controls 1 and 3 call for, and list which in-scope enterprise assets and data sets the recovery process covers. Name the systems in and out of scope and record the reason for each exclusion. Output: a scope statement that a reviewer can match against the inventories line by line. Confirm the scope with the system owners before moving on, because the Completeness measure in the assessment specification checks whether the elements of the process are included.
Agree recovery priorities with business owners
Meet with the owners of each in-scope system and data set to agree the order in which they must return after an incident, and why. Record the business function each system supports, the dependencies between systems and the owner who signs off each priority. Output: a ranked recovery priority list with named owners. This ranking is what Safeguard 11.2 uses to set backup frequency by data sensitivity and what Safeguard 11.5 tests against.
Document how backup data is protected
Write the rules that cover the security of backup data: how recovery data is encrypted or separated from production (Safeguard 11.3), where an isolated copy is kept (Safeguard 11.4), and which accounts may read, restore or delete recovery data. Describe these as requirements of the process and reference the technical safeguards as the places where they are implemented. Output: a protection section that names each control and the system that enforces it, so an assessor can trace the requirement to a configuration.
Assign roles and escalation paths
Name who initiates a recovery, who approves restoring data to production, who communicates with the business during an event, and who escalates when a recovery exceeds its priority target. Confirm that each role has a named person and a deputy, and that the people holding these roles know them. Output: a roles table and an escalation path that link to the incident response process. Keep the names in a controlled location and record the date they were last confirmed.
Approve and publish the document with an owner
Route the draft to the executive or risk owner who accepts the residual risk of the recovery approach, then record the approval with a version number, date and approver. Publish the approved version in the location where staff and auditors can find it, and retain prior versions. Output: an approved, versioned document with a single accountable owner. Version history matters because the assessor will ask which version was in force when a given recovery test ran. Use a system that keeps change history, such as a version-controlled wiki, if you already run one.
Set the annual review and change-triggered review
Schedule the annual review that CIS asks for and add a rule that the document is also reviewed sooner when a significant change could affect it, such as a new cloud platform, a merger, a new critical application or a change of backup tooling. Assign the review owner and record each review outcome, even when no edits are made. Output: a review calendar and a change log showing the trigger for each review. Confirm with your assessor how they expect a review to be evidenced in your environment.

Evidence that passes CIS Safeguard 11.1 and how to keep it current

Safeguard 11.1 is a documentation safeguard, so the assessor's view is built from artifacts: the process itself, the scope and priorities behind it, and the records showing it is reviewed and approved. The cards below cover what to keep and how to keep it accurate between assessments.

Approved process document with version history

The data recovery process is the primary artifact for Safeguard 11.1. Keep a single controlled copy with a named owner, an approval date, and a version history that shows what changed in each revision. An assessor will check that the document covers recovery scope, recovery prioritization and the security of backup data, and that the version in force matches what staff actually follow. Confirm that superseded versions are retained so you can show what applied on any past date.

Scope statement tied to the asset inventory

The scope statement names which enterprise assets, systems and data sets the recovery process covers. It should reference your asset inventory from Control 1 and software inventory from Control 2 rather than a free-text list, so that a newly added system either falls inside scope or is explicitly excluded. Check that every system in the inventory with recovery needs maps to a scope entry, and that exclusions carry a stated reason and an owner.

Recovery priority register

A recovery priority register ranks systems and data by business impact, so recovery effort goes first to the services that matter most. Record the ranking criteria, the assigned priority for each asset, and the business owner who agreed to it. Assessors look for prioritization that is documented and reflects current operations, so the register should be reviewed alongside the process rather than created once and left alone.

Annual and change-triggered review records

CIS asks that the Safeguard 11.1 documentation be reviewed annually, and sooner when significant enterprise changes could affect it. Keep dated review records that show who reviewed the document, what they checked, and what changed as a result. Also keep a list of significant changes, such as a cloud migration, a new backup platform or a merger, with the review that followed each one. A review with no recorded outcome is weak evidence.

Role assignments and responsibilities

The process should name who declares a recovery event, who authorizes restoration, who owns backup data security and who maintains the document. Record these as role assignments with named individuals or positions, plus a deputy for each. Check that the people named still hold those roles, because stale assignments are a common finding. Pair the roles with their access rights so the assignments match what the systems actually permit.

Approval records and change tickets

Keep signed or system-recorded approvals for each process version, along with the scope and priority register it relies on. Between audits, link change tickets to the process: when a change affects recovery scope, the ticket should reference the affected process section and record whether the document was updated. This shows the process is maintained as part of change management, not only at review time.

What it costs to meet the Safeguard 11.1 data recovery process

This table compares each cost component of maintaining the Safeguard 11.1 data recovery process, showing who is paid, whether the cost is one-time or recurring, and what drives it up or down. The document itself carries almost no license cost, so most spend comes from people time, legal review and assessor effort. Read the rows as a checklist for requesting a quote.

Cost component	One-time or recurring	What drives it and how to keep it down
Internal engineering and business owner time to draft and agree recovery priorities	One-time, then recurring on review	Number of in-scope systems and how many business owners must agree priorities. Keep it down by starting from an existing asset inventory and recovery tiers already agreed for other purposes.
Legal or records review if retention rules apply	One-time, with occasional recurrence	Count of regulated data sets and jurisdictions with retention obligations. Keep it down by limiting legal review to the specific retention rules that change recovery scope, and confirm the scope with counsel in writing.
Annual review effort for the Safeguard 11.1 document	Recurring, at least annually	CIS asks for review at least annually and sooner after significant enterprise changes, so large or fast-changing estates review more often. Keep it down by tying reviews to change management events and a fixed calendar slot.
External consultant drafting, if used	One-time, plus fees for later revisions	Scope of the drafting work and how much internal input is ready. Keep it down by agreeing a fixed scope and deliverables in writing before work starts, and by preparing inventory and priority inputs internally.
Auditor sampling and walkthrough time	Recurring, once per assessment cycle	Number of assessment samples, how many documents and versions the auditor reviews, and whether review history is easy to show. Keep it down by keeping version history and approval records in one place.
Tooling to store, version and approve the document	Mostly one-time setup, low recurring upkeep	Whether an existing wiki or document system already keeps version history and role-based approvals. Keep it down by reusing a self-hosted tool your organization already runs, and confirm version history and permissions in your own environment before relying on them.
CIS Controls license for the document	None for most organizations	CIS states the Controls are free for any organization to use to improve its own cybersecurity under its Creative Commons license. Commercial use needs CIS's prior approval, so confirm with CIS if you plan to resell the material.

Open-source tools that support the evidence for Safeguard 11.1

Safeguard 11.1 is met by a written data recovery process that your organization owns and approves, so none of the tools below replace it. Each one produces records an assessor can ask to see when testing recovery scope, backup security and document history. Confirm each tool's current behavior in your own environment before you cite its output as evidence.

Bareos job and catalog records

Bareos is an AGPL-3.0-only backup system. Its Director schedules, supervises and logs backup, restore, verify and archive jobs, and its SQL catalog of backed-up files shows what was protected and when. For Safeguard 11.1, the catalog gives dated evidence of the assets in scope for recovery. Check that the catalog covers every asset your process names, and that restore tests draw on these records. Confirm which features your Bareos version includes before you rely on them.

restic integrity checks

restic is a BSD-2-Clause backup tool. Its check command verifies the structural consistency of snapshots, trees and pack files. With --read-data or --read-data-subset, it reads pack files back to confirm that stored backup data is unmodified. That output supports evidence that backup data is protected from silent corruption, a concern your recovery process should address. Record the commands, schedule and results, and confirm which options your version supports and how long a full read takes on your repository.

XWiki page version history

XWiki is an LGPL-2.1-or-later wiki in which every page change is kept under version control. Each entry records what changed, when and by whom, and any two versions can be compared or rolled back. For Safeguard 11.1, this gives assessors a traceable history of the recovery process document, including review dates and edits. Confirm that each annual review, and each review triggered by significant change, appears as a recorded edit with a named approver, not only in a separate cover note.

BookStack role-based access

BookStack is an MIT-licensed documentation platform. User abilities come from assigned roles, and permissions can be set per role at the shelf, book, chapter or page level. You can limit who edits or approves the recovery process and show that document ownership sits with named roles. Check that only authorized roles can change the recovery document, then export the role and permission settings into your evidence file so the access model can be reviewed alongside the process itself.

Who owns the recovery process, who can help and what the auditor checks

Your organization owns the data recovery process. Only your people can decide what is in scope, how recovery priorities rank business systems, who approves the document and what the acceptable recovery trade-offs are for each data set. Those decisions reflect your business obligations, contracts and risk appetite, so they cannot be delegated to a vendor.

Scope decisions: Confirm which enterprise assets and data sets the process covers, and record any exclusions with a reason.
Recovery priorities: Rank systems by business impact with the application owners who will be asked to restore them first.
Backup data security: Decide how recovery data is protected, who may access it and where it is stored, in line with your data classification.
Approval and ownership: Name an accountable owner and an approver, and keep a dated record of approval.
Annual review: Review and update the document at least annually, and sooner after significant changes such as a merger, a new cloud region or a new critical platform.

Before accepting any draft, confirm that a named person on your side can explain every priority and exclusion in it.

Where organizations usually fall short on the recovery process

Safeguard 11.1 is a governing document, so most shortfalls are not missing backups but a process that is undocumented, unapproved, out of date or ignored. The cards below cover the gaps assessors most often find and the checks that close each one.

Process lives in one engineer's head

Recovery steps that exist only as tribal knowledge fail the moment the person who knows them is unavailable. Check whether a written process names the systems in scope, the order of recovery, and who decides to start a restore. Ask a second engineer to walk through a restore using only the document. If they cannot, the process is incomplete. Store the approved version in a controlled location with an owner and a revision history.

Runbook without approval

A runbook that an engineer wrote and posted is a draft, not a governed process. Assessors look for evidence that accountable leaders reviewed and approved the process, with the approver, date and version recorded. Confirm the approval step with your governance function and record it in the document itself. Unapproved runbooks are a common reason the process scores as incomplete even when restores work in practice.

Scope that ignores the asset inventory

The recovery process should name the enterprise assets it covers, and that list must match the asset inventory maintained under Control 1 and the data inventory under Control 3. Systems added through new projects, SaaS tools or shadow IT often sit outside the document. Reconcile the process scope against the current inventory each review cycle and record any gaps with an owner and a deadline.

Recovery priorities never agreed

Which systems come back first is a business decision, not an engineering default. If priorities were set only by the infrastructure team, the process will not reflect what the business needs restored first after an incident. Obtain written agreement from system owners on recovery order and the data each one cannot lose. Keep that agreement with the process so the Completeness of the document can be shown.

No review after major change

A process written for an on-premises data center can be wrong after a cloud migration, a new region or a move to a managed database service. The safeguard expects a review at least annually and sooner when significant changes could affect it. Build a trigger into change management so that migrations, acquisitions and new critical platforms prompt a documented review. Record the date and outcome of each review, even when no change is needed.

Backup security absent from the process

Engineers often describe encryption, access restrictions and separate credentials for backup data in design notes, but the recovery process itself says nothing about them. Because Safeguard 11.1 covers the security of backup data, the document must state how recovery data is protected, who may access it and how recovery credentials are controlled. Trace each protection in the technical notes to a sentence in the process so an assessor can follow the link.

Questions buyers ask about the CIS 11.1 recovery process

How much effort does a first draft of the data recovery process take?

The effort depends mostly on how many systems and data types the process must cover and how much recovery knowledge already exists in writing. A first draft is usually a documentation exercise: listing in-scope enterprise assets, agreeing recovery priorities, describing how backups are protected, and naming who decides and who acts. Organizations with current runbooks, a configuration management database and documented backup jobs can draft faster because the facts already exist. Organizations that have never written down what they back up will spend most of their effort discovering it. Ask any provider for a written list of the inputs they expect you to supply and the reviews they plan, since those two items drive the work more than the writing does.

Can our own team write the data recovery process without a consultant?

Yes. The CIS Controls are free for any organization to use to improve its own cybersecurity, and the Safeguard 11.1 requirement is a written process that your organization owns. Internal teams usually write it well when the people who run backups, the owners of critical systems and someone with authority over recovery priorities contribute. Outside help is a choice made for capacity, facilitation or a second pair of eyes, not a requirement of the Safeguard. Note that commercial use of the Controls content requires CIS's prior approval, so check the license terms before reusing CIS text in a product or service you sell.

How long does the work take, and what sets the timeline?

No duration is fixed by the Safeguard itself, so the timeline depends on your environment and approvals. The main drivers are the number of in-scope asset groups, whether recovery priorities already exist in a business continuity or disaster recovery plan, how many business owners must agree to them, and how many review cycles your governance process requires. Approval by executives or a risk committee often takes longer than drafting. For a fixed-scope engagement, the written scope should state the milestones, the owners of each input and the date by which each review must happen, so that the timeline is visible before work starts.

What does the process need from business owners?

Business owners decide what recovers first and how much data loss or downtime each service can tolerate. The data recovery process sets recovery priorities, so someone accountable for each critical service must say which systems matter most and in what order they return. They also confirm the data classes that need protection, approve who may request a restore, and sign off on the process before it is published. Technical staff can describe what is possible, but priorities are a business decision. Asking owners for these decisions early avoids a document that engineers cannot enforce.

Do we need a consultant to pass an assessment against Safeguard 11.1?

The CIS Controls do not require a consultant, and an assessment does not require one either. The assessment specification measures whether a documented data recovery process exists and how complete its elements are, so an internal reviewer can check it against the Safeguard's requirements. If your customers, insurers or regulators ask for an independent opinion, that comes from an independent auditor or assessor, which is a separate engagement. A consultant may prepare the evidence and gaps, but only an independent assessor issues a report or opinion. Ask any firm to state in writing whether it is preparing your material or performing an independent assessment.

How often must the data recovery process document be reviewed?

CIS asks that the Safeguard 11.1 documentation be reviewed and updated at least annually, and sooner when significant enterprise changes could affect the process. Typical triggers include a new cloud region or platform, a merger, a new critical application, a change to backup tooling, a major incident that exposed a gap, or a change in recovery priorities. Record each review with its date, the reviewer and the changes made, because the evidence of an annual review is often what an assessor asks to see first.

Does Safeguard 11.1 alone prove that our backups can be restored?

No. Safeguard 11.1 governs the process: its scope, recovery priorities and the security of backup data. It does not test whether a restore works. Proof that backups can be recovered comes from Safeguard 11.5, which asks for recovery testing on a sample of in-scope assets at least quarterly. The technical safeguards 11.2 to 11.4 cover automated backups, protection of recovery data and an isolated copy. A written process with no restore tests will still show a documented plan, not a working recovery capability, so the two safeguards should be evidenced together.

What does DeployOpen do and not do for this safeguard?

DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms in your own infrastructure, and it can prepare systems and documentation that support recovery and the evidence for compliance assessments. Where a client asks for it, the work can include drafting the recovery process and the supporting runbooks with the client's owners. DeployOpen does not own your controls, decide your recovery priorities for your business, or issue audit reports, attestations or certifications. Only an independent auditor or certification body does that. Scope, deliverables and timelines are agreed in writing before work starts, and a quote follows from that written scope.

How DeployOpen scopes and prepares the recovery process

DeployOpen helps organizations write and maintain the data recovery process that Safeguard 11.1 requires, and prepares the evidence an assessor will ask for. The organization owns the process and its decisions, while DeployOpen documents the scope, priorities and backup data protections that the process describes.

How we scope

Agree in writing which in-scope enterprise assets and data sets the recovery process covers before work starts.
Confirm recovery priorities with system owners so restoration order reflects business criticality, not only technical convenience.
Record how the security of backup data is handled, including who may access recovery data and under what conditions.

How we build

Draft the recovery process document so it names scope, priorities and backup data security in plain, reviewable language.
Map each recovery step to the platform, such as Bareos or restic, that actually performs it in the client environment.
Test that the documented process matches the configured jobs, retention settings and access rules before sign-off.

How we hand over

Deliver the approved recovery process in the client's document system, such as XWiki or BookStack, with version history intact.
Provide an annual review schedule and a trigger list for earlier updates after significant enterprise changes.
Walk the internal owners through the document and record who is accountable for each section and each review.

How we support

Offer ongoing support and upgrades as a retainer, so the recovery process keeps pace with platform and infrastructure changes.
Update the document and related evidence when systems, backup destinations or recovery priorities change.
Ask your auditor or assessor early which evidence format they accept, since DeployOpen prepares evidence but does not issue reports.