Safeguard 11.2 Automated backups: requirements and evidence

What Safeguard 11.2 automated backups requires and why it is hard to prove

An auditor or customer questionnaire asks whether backups run automatically and whether they are current. Safeguard 11.2 asks for exactly that: automated backups of in-scope enterprise assets, run on a schedule that matches how sensitive the data is. CIS sets weekly as the minimum frequency, and sensitive data calls for more frequent runs. The Safeguard sits in Implementation Group 1, so it applies to IG1, IG2 and IG3 enterprises alike. It addresses a plain risk: data lost to hardware failure, human error or ransomware that encrypts or deletes the primary copy. Without a current backup, recovery is guesswork.

The hard part is coverage and proof. Backups must exist for every in-scope asset, including the servers, endpoints, cloud workloads and SaaS-adjacent data stores that someone forgot to add to the job list, not only the systems people remember. That makes the asset inventory and software inventory under Controls 1 and 2 prerequisites in practice, and the secure configuration process under Control 4 is what keeps new assets from quietly running outside the backup policy. The assessment specification measures two things: coverage, meaning the share of in-scope assets with properly configured, authorized backup software, and compliance, meaning the share of assets backed up within the weekly timeframe. Both are ratios, so you need a current denominator. Confirm with your assessor how they will define in-scope assets before you build the report.

Proof must be a record, not a claim. Keep job logs, schedules exported from the backup server, a list of assets with their last successful backup time and alerts for missed or failed jobs. CIS publishes the Controls for free use but does not certify anyone against them, and CIS Controls Accreditation applies to service organizations, not to your environment. An independent assessor or certification body issues any report or attestation. DeployOpen can prepare the backup configuration, schedules and reporting so that this evidence can be produced on request, but the organization owns the backup policy and the assessor determines whether the evidence is sufficient.

Which assets, data and teams fall under automated backups

Safeguard 11.2 is only as complete as the scope behind it. The decisions below determine which systems must be backed up, how often, who runs the backups and who answers for them. Settle them in writing before choosing tooling, because an assessor measures coverage against the inventory you can show.

In-scope enterprise assets

Start from the asset inventory maintained under Safeguard 1.1 and list every server, endpoint, database host and cloud workload that holds enterprise data. Mark which assets are in scope for backup and record the reason for any exclusion, such as a host that holds only reproducible configuration. An assessor measuring Coverage needs a defined denominator, so a server missing from the list is a gap that the scope document does not explain. Check that virtual machines, containers with persistent volumes and endpoints used by staff are each classed deliberately.

SaaS and cloud data responsibilities

For SaaS platforms and managed cloud services, the provider often protects the platform but not your data. Confirm in the contract and service documentation which data you must export or back up yourself, such as mailboxes, repositories, configuration exports or object storage buckets. Record each one as in scope with its own owner and schedule. Where the provider offers native backup features, check whether they are enabled, which retention they apply and whether you can restore independently of the provider.

Data sensitivity classes

Sensitivity classes set the backup schedule. Safeguard 11.2 requires weekly backups at minimum, and more frequent runs for more sensitive data. Map each asset to the classification scheme used under Control 3, then assign a frequency to each class. A reviewer will test whether the schedule matches the classification, so an asset holding regulated personal data on a weekly-only cycle needs a documented reason. Ask data owners to confirm the acceptable data loss window for each class.

Third parties that hold or run backups

Backup work often sits with managed service providers, cloud backup services or a self-hosted platform run by an implementation partner. Each party that stores, copies or can restore backup data is a service provider under Control 15 and must be listed with its responsibilities. Confirm where copies are held, who holds the encryption keys and how the provider's access is logged and removed. Contracts should state the recovery time and data handling duties you need to demonstrate.

Prerequisite inventories

Coverage cannot be measured without knowing what the assets are, so Safeguard 11.2 depends on Safeguard 1.1 (detailed enterprise asset inventory), Safeguard 2.1 (software inventory) and Safeguard 4.1 (secure configuration process). The asset list shows which hosts exist, the software inventory shows which backup agents and applications must be present, and the configuration process defines how backup clients are deployed and kept correct. Verify that all three sources agree before counting coverage, because mismatches are the first thing an assessor finds.

Teams and their responsibilities

Name one owner for backup scope, typically the IT operations or platform engineering lead, and separate duties for the data owners who set recovery needs and the security team who reviews protection of backup data. Application owners confirm which systems are business critical and which data they cannot lose. Document these roles in the data recovery process under Safeguard 11.1, so each team knows what evidence it supplies and who signs off on changes to scope.

How assessors test Safeguard 11.2 automated backups

This table shows how the CIS Controls Assessment Specification measures Safeguard 11.2 through its Coverage and Compliance metrics, what evidence an assessor asks for, and where backup programs usually fall short. Read it as a checklist of what to prepare before an assessment, keeping in mind that CIS defines what to measure while the assessor decides whether the result meets the Safeguard.

Assessment element	What the assessor checks	Evidence to prepare	Where programs usually fail
Coverage metric	Share of in-scope assets with properly configured, authorized backup software	Asset inventory matched to backup client registrations, with the authorized backup software named for each asset	Assets missing from the backup server's client list, or backup agents that are installed but misconfigured
Compliance metric	Share of in-scope assets backed up within the weekly timeframe	Job completion records showing the last successful backup date for each in-scope asset	Jobs reported as scheduled but with no successful run in the review window
Prerequisite inventories	Whether the asset inventory (1.1), software inventory (2.1) and secure configuration process (4.1) support the backup scope	Current asset and software inventories, and the configuration baseline used to build backup clients	Backup scope built from an outdated spreadsheet that omits cloud workloads or new endpoints
Schedule definitions	Whether backup frequency is set for each data class, with weekly as the minimum	Written schedule per data sensitivity tier, plus the job definitions that implement it	One schedule applied to every system regardless of sensitivity, or sensitive data set to run less often than the policy requires
Backup configurations	Whether backup software settings reflect the documented scope and retention	Exported job and client configurations, with change history for recent modifications	Exclusion rules that silently skip directories, or configurations edited without a recorded approval
Job logs and failures	Whether failed or partial jobs were detected and resolved	Job logs for the review period, failure alerts and tickets showing the follow-up and re-run	Failed jobs that appear in logs but have no ticket, owner or re-run record
Reconciliation	Whether the inventory, backup client list and job results agree	A dated reconciliation showing each in-scope asset mapped to its backup job and last success	Unbacked assets found only when a restore is requested, such as new cloud instances or retired servers still in the inventory
Judgment and conclusion	Whether the assessor finds the Safeguard implemented, based on the metrics and supporting evidence	A short narrative linking the metrics to the data sensitivity decisions behind the schedule	Organizations expecting the CIS Controls to produce a pass result on their own; the assessor, not CIS, reaches the conclusion

Implementing automated backups under Safeguard 11.2 in order

This sequence takes an organization from an unclear picture of its assets to backups that are scheduled by data sensitivity, covered in full, and reviewed on a fixed cadence. Each step ends with a record an assessor can read and trace back to the Safeguard.

Confirm the asset inventory and classify data sensitivity
The security or IT operations lead confirms which enterprise assets are in scope by checking the detailed asset inventory under Safeguard 1.1 and the software inventory under Safeguard 2.1. Data owners then classify the data on each in-scope asset by sensitivity, because that classification sets how often each asset must be backed up. The output is a scoped asset register with a sensitivity class on every row, signed off by the data owners. This step is done when no in-scope asset lacks a class.
Set backup schedules per sensitivity class
The backup owner turns each sensitivity class into a schedule. Safeguard 11.2 sets weekly as the minimum frequency, so the most sensitive classes run more often than weekly and lower classes may not run less often than weekly. The schedule table records the class, the frequency, the assets it covers and the approver. Ask the data owners to confirm the frequencies in writing, since the Safeguard does not set a single fixed interval for every data type. This step is done when every class has an approved schedule that meets or exceeds the weekly floor.
Deploy authorized backup software to every in-scope asset
The platform team installs the backup agent or client on each in-scope asset using the approved configuration baseline from Safeguard 4.1, so that agents are configured the same way everywhere. Only authorized backup software appears on the software inventory, which keeps unauthorized tools out of the backup path. Open-source options such as Bareos, whose Director schedules and supervises backup, restore, verify and archive jobs, or restic, can be evaluated against the environment before selection. The output is a deployment record listing each asset, the agent version and the install date. Confirm each product's current capabilities with its documentation before committing.
Configure jobs, retention and failure alerting
The backup engineer creates a backup job for each asset and schedule, sets retention periods approved by the data owners, and turns on failure alerts that reach a monitored queue, not a single mailbox. Jobs are tested against a non-production asset first, and the catalog or repository is checked to confirm that backed-up data is recorded. The output is a job configuration export, a retention register and an alert routing record. This step is done when a deliberately failed job produces an alert that a named person acknowledges.
Reconcile backup coverage against the inventory
The security team runs a first full reconciliation that compares every in-scope asset in the inventory with the assets that have a working, authorized backup job and a successful recent run. Each gap is either fixed or recorded as an exception with an owner and a reason. The coverage figure produced here is the same kind of measure the CIS assessment specification uses for Safeguard 11.2, so it should be calculated in the same way. The output is a signed reconciliation report with its exception list. This step is done when every in-scope asset is either covered or on an approved exception list.
Establish a recurring review of job results and exceptions
The backup owner and a second reviewer examine job results, failed runs, missed schedules and open exceptions on a fixed cadence that the organization sets and documents. Repeated failures trigger a ticket, and assets that move in or out of scope update the inventory and schedule table. Compliance is measured as the share of in-scope assets backed up within the scheduled timeframe, so the review also tracks that figure over time. The output is a review log with dates, reviewers, findings and closed actions. This recurring record is the evidence that the safeguard operates, not only that it was set up once.

Evidence that shows automated backups are running and covered

An assessor testing Safeguard 11.2 looks for one thing: a line of proof from the in-scope asset list, through the backup schedule, to job records that show the backups actually ran. The cards below cover the artifacts that link those points, how to keep each one current between audits, and what gets rejected.

In-scope asset list reconciled to backup clients

Start with the asset inventory that Safeguards 1.1 and 2.1 require, filtered to in-scope enterprise assets that hold data. Reconcile that list against the backup clients registered with the backup server. Every in-scope asset should appear on one side and be accounted for on the other, with exceptions documented and approved. Assets present in the inventory but absent from backup are the first finding an assessor will raise.

Backup schedule with sensitivity rationale

Export the job definitions that set frequency, retention and target for each data class. Each schedule should cite the sensitivity classification that justifies it, since Safeguard 11.2 requires weekly backups at minimum and more often for more sensitive data. Keep the schedule under version control so changes carry a date, an author and an approval. A schedule that claims daily backups for data that is backed up weekly will fail the review.

Job logs and catalog records for a sample period

Pull job run history for a sample period and match each scheduled job to a completed run. Bareos keeps a SQL catalog of backed-up files and job records, and restic snapshots list the time and host of each backup. The assessor will check that a job run exists for every schedule entry in the period, so gaps in the sample need an explanation tied to a maintenance window or a documented failure.

Failed-job alerts and resolution records

Keep the alert history for failed, partial and skipped jobs, and a ticket for each one showing the cause, the fix and the date the backup succeeded again. Assessors read these records to judge whether failures are caught quickly. Confirm that alerts reach a monitored queue and not one person's inbox, and that repeated failures on the same asset are escalated rather than closed each time.

Coverage and compliance reports

Produce a dated report that shows the two measures CIS uses for this Safeguard: coverage, the share of in-scope assets with properly configured authorized backup software, and compliance, the share backed up within a week. Generate it from the backup server or the asset list, not typed by hand. The figures must match the job logs for the same period, since a report that no job log supports will not hold up in testing.

Scheduled exports and named report owners

Set the reports to export on a fixed cadence, store them in a restricted evidence location with timestamps, and assign one named owner per report who signs off on accuracy. Record who changed the schedule, the asset list or the alert rules and when. Assessors reject undated screenshots and evidence that cannot be regenerated, so the owner should be able to reproduce any report for any past period on request.

Open-source backup tools that produce this evidence

Bareos and restic can produce much of the technical record behind Safeguard 11.2, but they cover backup execution and records only. The organization still owns the decisions that the tools cannot make for it: which assets are in scope, how often each data class is backed up according to its sensitivity, and whether the coverage and compliance figures match the asset inventory. Treat the tools as the source of evidence, not as the control itself. Bareos is a network backup system whose Director schedules and supervises backup, restore, verify and archive jobs. It keeps a SQL catalog of the files it has backed up and can restore files selected from the current backup or from one taken before a given date and time. For an assessor testing the weekly minimum and the sensitivity-based frequency, the useful outputs are the job schedule, the job history with completion status, and catalog entries that tie each backed-up client and file set to a backup run. Compare those records against the in-scope asset list to support the Coverage and Compliance measures in the CIS Controls Assessment Specification.

restic is a command-line backup tool that stores snapshots in a repository. Its restic check command verifies the structural consistency of snapshots, trees and pack files. Adding --read-data or --read-data-subset makes it read pack files back to confirm the stored data is unmodified, which supports integrity evidence beyond the job log. Schedule these checks at a frequency the organization documents, and keep the output with the backup records. Note that a passing check shows the repository is intact, not that every asset was backed up on time. Before relying on either tool, have counsel review licensing. Bareos is licensed under AGPL-3.0-only and restic under BSD-2-Clause, and the obligations differ, particularly if the organization modifies the software or offers it to others over a network. Confirm these obligations with counsel for your own deployment. Also confirm with the Safeguard 11.2 measure owner that exported Bareos and restic records can be retained and produced at assessment time.

What meeting Safeguard 11.2 costs in money and effort

This table breaks down the money and effort behind running automated backups under Safeguard 11.2, showing who is paid for each component, whether it is one-time or recurring, and what pushes it up or down. Use it to structure a written scope and to check that a quote covers each line before you sign.

Cost component	Who is paid, one-time or recurring	What drives it up or down
Backup software	No license fee for self-hosted open source such as Bareos or restic. One-time effort to select and integrate, plus recurring upgrade and patch work.	Up: custom integrations and plugins needed for databases or SaaS sources. Down: standard clients and one backup tool across the estate.
Storage and compute	Cloud or data center providers are paid for backup storage and job runtime. Recurring, usually billed by volume.	Up: asset count, total data volume, retention length, cloud egress on restores. Down: deduplication, incremental jobs, lifecycle rules.
Asset inventory and sensitivity classification	Internal staff or a consultant. One-time to set up, recurring when new systems appear.	Up: many sensitivity classes and no current inventory. Down: a clean inventory under Safeguards 1.1 and 2.1 and a small set of backup tiers.
Schedule design and configuration	Engineers or a fixed-scope implementation partner. One-time for the initial schedules, recurring for changes.	Up: many schedules, exceptions and bespoke scripts. Down: a documented secure configuration process under Safeguard 4.1 and templated job definitions.
Job monitoring and failure handling	Internal operations or a retained managed service. Recurring, often daily review of job results and alerts.	Up: high job count and noisy alerts. Down: alert routing into existing monitoring and tuned failure thresholds.
Evidence upkeep	Internal compliance or security staff. Recurring, typically in regular reporting cycles.	Up: manual exports of job logs and coverage reports. Down: scheduled reports from the backup catalog and retained configuration files.
External review or restore testing	Independent testers or a consultant for review. Periodic, one-time per engagement.	Up: broad asset scope and undocumented schedules. Down: a narrow written scope agreed before testing starts.
Auditor sampling time	Auditor or certification body, which an organization pays directly. Recurring per assessment cycle.	Up: missing job records or inconsistent schedules that force extra sampling. Down: complete catalog history and a documented schedule for each asset.

Who owns backups, who can prepare the evidence and who assesses it

Your organization owns Safeguard 11.2. The Safeguard is a commitment about your data and your recovery risk, so the decisions behind it cannot be delegated to a vendor or a partner. Your team sets the schedule, classifies data by sensitivity, decides who is accountable when a restore fails, and reviews the coverage reports that show whether in-scope assets are being backed up.

Schedule decisions: Set backup frequency for each sensitivity class, with weekly as the minimum Safeguard 11.2 expects and more frequent runs for sensitive data.
Data sensitivity classes: Define the classes, usually tied to your data classification work under Control 3, and assign assets to them.
Recovery accountability: Name the owners who approve restore priorities and who act when a backup job fails.
Coverage reports: Review the share of in-scope assets with authorized backup software and the share backed up within the required timeframe, and decide what to do about gaps.
Approval records: Keep signed or versioned records of schedule and classification decisions so an auditor can trace them.

Before engaging anyone, confirm that these owners are named and that the classification and schedule decisions are written down.

Where organizations fall short on automated backups and how to close each gap

Most backup failures under Safeguard 11.2 start before any job runs: an incomplete asset list, a schedule that ignores sensitivity, or nobody reading the results. The cards below pair each gap with a closure step and the evidence that shows it is closed, so the Coverage and Compliance measures in the assessment specification can be reproduced from records.

Assets missing from backup scope

Backups only protect what someone put on the list. If the enterprise asset inventory under Safeguard 1.1 is incomplete, servers, laptops and cloud workloads outside the list never receive a job and never appear as failures. Reconcile the inventory against cloud account listings, hypervisor records and endpoint management exports, then mark each in-scope asset with its backup job. Evidence: the reconciled inventory with a backup job or documented exclusion for every row.

Schedules ignoring data sensitivity

Safeguard 11.2 asks for backup frequency that matches how sensitive the data is, with weekly as the minimum. Organizations often apply one nightly or weekly schedule to everything, or leave the schedule to the default set when the server was built. Classify the data first, then assign each class a documented frequency and check that the job schedule matches it. Evidence: a schedule register linking data classes to job definitions and their last run times.

Failed jobs that go unnoticed

A backup job that fails at 2 a.m. and reports nothing to anyone leaves the Compliance measure silently falling behind. Route job results to a monitored channel, alert on any failed or missed run, and assign a named person to clear each alert within a set window. Test the alert path by forcing a failure in a non-production job. Evidence: alert records, ticket history showing each failure resolved, and the job success log.

Backups never reconciled to assets

A job that runs successfully proves only that it ran, not that it covered the right systems. Compare the catalog of backed-up hosts and file sets against the asset inventory on a fixed cadence, so new systems, renamed hosts and retired servers are caught. Bareos keeps a SQL catalog of backed-up files that can be queried for this comparison. Evidence: a dated reconciliation report with each asset marked covered, excluded or retired.

Configurations drifting from the standard

Backup agents, retention settings and included paths change during upgrades, emergency fixes and staff turnover, so the running setup slowly departs from what was approved. Store backup job definitions as version-controlled configuration, review changes through the normal change process, and compare live settings against the approved baseline. Evidence: the baseline document, the configuration repository history and a drift check output showing no unapproved differences.

No owner for the coverage report

Coverage and compliance figures only matter when someone is accountable for producing and acting on them. Without a named owner, the report exists in a dashboard that nobody reviews, and gaps persist for months. Assign an owner in the data recovery process, set the reporting frequency and define who escalates shortfalls to the asset owner. Evidence: the signed role assignment, meeting or review minutes, and escalation records for each reported gap.

Questions buyers ask about Safeguard 11.2 automated backups

How much effort does it take to meet Safeguard 11.2 in-house?

The effort depends mostly on how many in-scope assets exist, how many backup destinations and data types you run, and how much of your asset inventory is already reliable. Meeting 11.2 means configuring authorized backup software on every in-scope asset, setting a schedule that matches each data sensitivity tier, and keeping evidence that the jobs ran. Organizations with a current asset inventory and a documented configuration process usually spend far less time than those discovering their estate while building backups. No duration figure is supplied for this work, so ask your team or a partner to estimate it from your own asset count and tooling, and request that estimate as a line item in any written scope.

Do we need an implementation partner to meet Safeguard 11.2?

No, the organization can meet the Safeguard with its own staff, because CIS Controls content is free for organizations to use to improve their own security. A partner becomes useful when the internal team lacks backup engineering time, has no experience with the chosen backup platform, or needs help producing consistent evidence across many systems. A partner prepares and configures systems and evidence, but the organization still owns its controls and its backup policy. Any partner engagement should begin with a written, fixed scope that names the assets, platforms and evidence it covers.

How long does automated backup work usually take, and what drives that time?

Timing is driven by the state of your asset inventory, the number of in-scope assets, the variety of platforms (physical servers, virtual machines, cloud workloads, endpoints) and the frequency your data classification requires. Safeguard 11.2 depends on the prerequisite Safeguards 1.1, 2.1 and 4.1, so an incomplete asset inventory, software inventory or secure configuration process usually adds time before backups can be measured. Ask for a schedule that separates inventory and configuration prerequisites from the backup deployment itself, and confirm how the plan accounts for testing of the backups.

What does the internal team need to provide for automated backups?

The internal team needs to supply decisions and access rather than only labor. Owners must classify data sensitivity so the backup schedule has a basis, and they must confirm which assets are in scope. Administrators need to grant access to hypervisors, cloud accounts, storage and endpoints, and they must approve the backup software, retention rules and where encryption keys are held. Someone must also own the monitoring of backup job results, because the Safeguard is measured by the share of in-scope assets backed up within the required timeframe.

Does meeting Safeguard 11.2 produce an audit report or certificate?

No. Meeting Safeguard 11.2 produces internal evidence such as backup job logs, coverage reports and schedule configurations, but it does not produce an audit report, attestation or certificate. Only an independent auditor, assessor or certification body can issue a report or certificate for a framework that uses the Safeguard, such as ISO/IEC 27001 or SOC 2. Your auditor will decide whether your evidence is sufficient for their scope, so confirm early which framework applies and what format of backup evidence they expect.

Does CIS certify that we comply with Safeguard 11.2?

No, CIS does not certify organizations against the CIS Controls. CIS publishes the Controls and the Assessment Specification, which describes what to measure, but it does not issue compliance certificates to enterprises. CIS Controls Accreditation applies to CIS SecureSuite member organizations that provide implementation, auditing or assessment services, not to the enterprises they serve. If a customer or regulator asks for proof, provide your own measured evidence and, where required, an independent assessor's report.

How does Safeguard 11.2 relate to the isolated copy and recovery testing in Control 11?

Safeguard 11.2 creates the backups, while Safeguard 11.4 requires an isolated copy that survives ransomware or compromise of the primary environment, and Safeguard 11.5 requires testing that backups can actually be restored. A backup that is never isolated or never restored tests cannot demonstrate recovery, so the three Safeguards work as a set. Your data recovery process under Safeguard 11.1 should define how these fit together. Confirm with your team how each backup job maps to an isolated destination and to a recovery test sample before treating 11.2 as complete.

Which open-source tools can run automated backups for this Safeguard?

Bareos is a backup system whose Director schedules and supervises backup, restore, verify and archive jobs and keeps a SQL catalog of backed-up files, which makes job history easier to evidence. For repository-based backups, restic offers a check command that verifies the structural consistency of snapshots, trees and pack files, and its --read-data option reads pack files back to confirm stored data is unmodified. Neither tool removes the need to define scope, schedule and retention yourself. Confirm each platform's support for your specific workloads and storage targets before selecting it.

How DeployOpen scopes, implements and prepares backup evidence

DeployOpen plans and implements self-hosted backup platforms for Safeguard 11.2 inside the client's own cloud accounts, data centers or air-gapped networks. The work produces the configuration, schedules and records an assessor would need to test coverage and timeliness, while the organization keeps ownership of its controls and the independent auditor decides what the evidence shows.

How we scope

Agree in writing which in-scope enterprise assets and data stores the backup platform will cover for Safeguard 11.2.
Record the backup frequency for each data sensitivity tier, with weekly as the floor set by the Safeguard.
Confirm the prerequisite inventories from Safeguards 1.1, 2.1 and 4.1 that the assessment specification relies on.

How we build

Deploy and configure authorized backup software, such as Bareos or restic, on the client's own infrastructure.
Set schedules, retention and job definitions per sensitivity tier, and document the configuration as code where practical.
Test that scheduled jobs run, complete and report failures, so coverage and timeliness can be measured from logs.

How we hand over

Deliver the backup configuration, job schedules, asset coverage list and job success reports for the assessor's review.
Document how the coverage and timeliness metrics in the assessment specification are calculated from the platform's records.
Provide runbooks for failed jobs and schedule changes, so the client's own staff can operate the platform after handover.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope work closes.
Confirm with your auditor which evidence formats and time periods they will accept before handover.
Ask for a written quote tied to the agreed scope, deliverables and timeline before any work begins.