Safeguard 11.2: Perform Automated Backups

Safeguard 11.2: perform automated backups requirement means you must implement scheduled, tool-driven backups for in-scope systems and data, then prove those backups run reliably without manual intervention. Operationalize it by defining backup scope and frequency, automating backup jobs, monitoring success/failure, and retaining evidence (logs, configs, restore results) tied to asset inventory. ¹

Key takeaways:

• Automate backups for systems and data that matter to operations, security, and recovery objectives. ¹
• Treat “automated” as both scheduling and verification: jobs run, alerts fire, and failures get fixed. ²
• Evidence is part of the control: retain job configurations, backup logs, and restore/validation records mapped to assets. ¹

CIS Control 11 focuses on Data Recovery, and Safeguard 11.2 sits at the point where policy turns into repeatable operations: backups must happen automatically, not “when someone remembers.” For a Compliance Officer, CCO, or GRC lead, the hard part is rarely buying backup tooling; it is scoping what must be backed up, proving the automation is real, and showing sustained operation during an audit.

This requirement page is written to help you implement safeguard 11.2: perform automated backups requirement with minimal interpretation risk. You will translate the safeguard into: (1) a clear backup scope tied to your asset inventory and data classification, (2) an automated schedule with ownership and monitoring, (3) exception handling for edge cases (SaaS, endpoints, legacy systems), and (4) evidence that stands on its own.

CIS Controls are a framework, not a law, but they are commonly adopted as an internal control baseline and referenced in customer security reviews. Your main exposure is operational: if backups are ad hoc, you lose recoverability during incidents and you cannot defend control operation in assessments. ¹

Regulatory text

Excerpt (provided): “CIS Controls v8 safeguard 11.2 implementation expectation (Perform Automated Backups).” ¹

Operator interpretation: You must configure backups to run on a schedule through centralized or managed automation, rather than relying on manual steps. “Perform” also implies you confirm the backups actually happen. To be assessment-ready, you need (a) defined scope, (b) automated execution, (c) monitoring and failure handling, and (d) retained evidence that shows the control operates over time. ¹

What an operator must do (minimum bar):

• Identify systems and datasets that require backups for recovery. ¹
• Implement scheduled, automated backups for that scope. ²
• Monitor backup completion and address failures through tickets or documented remediation. ¹
• Keep recurring evidence that backs up your claim that automation is in place and working. ¹

Plain-English interpretation of the requirement

If losing it would hurt, back it up automatically. That includes production workloads, configuration states that are hard to rebuild, and core business data. Manual backups do not scale, do not survive staff changes, and tend to fail silently. Automated backups reduce operational risk, reduce incident impact, and give you defensible audit artifacts. ¹

Who it applies to (entity and operational context)

Applies to: Enterprises and technology organizations adopting CIS Controls v8 as a security baseline. ¹

Operational contexts where auditors will expect 11.2 coverage:

• Infrastructure and platform: virtual machines, databases, object storage, container platforms, directory services, and key configuration stores.
• Endpoints (where applicable): critical user devices, admin workstations, and specialized devices holding unique business data.
• SaaS: email, collaboration, CRM, ticketing, source control, and HR systems where business records live. SaaS often requires a separate backup/export approach because the SaaS provider’s availability does not equal your recoverability.

Third-party angle: If a third party hosts or processes your critical data, you still own the recovery outcome. You may satisfy the control through the third party’s backup capabilities, but you must document the dependency and retain evidence (contract terms, SOC reports, or attestations) as part of your control file. ¹

What you actually need to do (step-by-step)

1) Define backup scope and ownership

• Build a backup scope register from your asset inventory: list systems, data repositories, and SaaS platforms that are in scope for backup.
• Assign an owner per scope item (platform owner, application owner, or IT operations owner).
• Declare “source of truth” locations (for example: primary database, object store bucket, Git repositories, directory services configuration).

Deliverable: a scoped inventory table that maps assets to backup method and owner.

2) Choose automation mechanisms per platform type

Use a simple decision matrix:

Platform type	Preferred automation approach	Evidence you should expect
Cloud IaaS VM / volumes	Native snapshot policies or backup service policies	Policy config export, job history, alert config
Databases	Managed DB backups or scheduled dumps to protected storage	Backup schedules, success logs, retention config
Kubernetes / containers	Back up persistent volumes plus cluster state where required	Scheduled jobs, repo logs, restore notes
SaaS	Native export + third-party backup tooling where needed	Export schedules, admin audit logs, backup tool reports
Endpoints	Endpoint backup agent for scoped devices	Agent policy, device coverage list, job status

Keep the emphasis on “automated”: scheduled jobs or policies, not runbooks that rely on a person clicking “start.” ¹

3) Configure schedules and retention in a way you can defend

CIS 11.2 does not prescribe exact frequencies in the provided excerpt, so define them based on operational need and document the rationale. Record:

• Backup frequency (how often backups run)
• Retention (how long backups are kept)
• Coverage (what is included/excluded)

Auditors usually probe consistency: if production databases are automated but critical file shares are “manual on request,” you have a gap.

4) Implement monitoring, alerting, and failure handling

Automation without monitoring becomes “unknown status.” Put in place:

• Failure alerts to a monitored channel (ticketing system, on-call queue, or security operations mailbox).
• A response workflow: create a ticket, triage root cause (capacity, credentials, permissions, misconfiguration), re-run job, document closure.
• Exception handling: document why an asset is excluded and what compensating step exists (for example, immutable source-of-record elsewhere).

This is where teams most often fail audits: they can show a schedule, but cannot show they notice and fix failures. ¹

5) Validate backups by proving restore feasibility

Safeguard 11.2 is about performing automated backups, but operationalizing it for real risk reduction requires at least occasional restore validation. Even a limited restore test gives you stronger assurance and better evidence packaging. Record what you restored, where, who approved it, and the outcome.

6) Package evidence as a recurring control

The provided guidance emphasizes mapping 11.2 to documented control operation and recurring evidence capture. ¹ Treat this as a control with a cadence:

• Monthly (or other chosen cadence) evidence pull
• Quarterly review with system owners
• Ongoing ticket evidence for failures and fixes

Where Daydream fits naturally: Daydream is useful as the system of record for control mapping and recurring evidence capture for 11.2, so you can tie backup job outputs to the asset list and keep an audit-ready timeline without chasing screenshots across teams. ¹

Required evidence and artifacts to retain

Keep artifacts that answer three questions: What is backed up, is it automated, and did it run successfully?

Core evidence set (recommended):

• Backup scope register mapped to asset inventory (system, owner, method, schedule reference).
• Backup configuration exports (policy settings, schedules, retention, target storage).
• Job execution history (logs or reports showing automated runs and status).
• Alerting configuration (notification rules, recipients, on-call integration).
• Failure tickets (incident/ticket trail showing detection and remediation).
• Restore/validation records (restore request, steps, results, and sign-off).
• Exception register (explicit exclusions, business rationale, compensating controls, review/approval).

Store evidence in a controlled repository with access controls and a retention rule aligned to your audit needs.

Common exam/audit questions and hangups

Expect auditors and customer assessors to ask:

• “Show me which systems are in scope and how you decided.” Provide the scope register tied to asset inventory.
• “Where is the proof the backups are automated?” Show policy-based schedules and job histories, not a runbook.
• “What happens when backups fail?” Show alerts plus a sample of failure tickets closed with root cause notes.
• “Are SaaS datasets included?” Many teams miss SaaS because “the vendor backs it up.” Be ready with exports or third-party backup reports.
• “Who reviews backup coverage?” Point to a named owner, a review cadence, and the last review output. ¹

Frequent implementation mistakes and how to avoid them

1. Mistake: Automation exists, but only for part of the environment.
   Fix: Start from asset inventory, not from the backup tool. Your inventory should drive coverage.

2. Mistake: “Green dashboard” evidence with no underlying logs.
   Fix: Retain raw job histories or immutable reports that show dates, systems, and outcomes.

3. Mistake: No failure workflow.
   Fix: Require tickets for failures and keep samples. A control without corrective action looks unmanaged.

4. Mistake: SaaS is treated as out of scope by default.
   Fix: Decide per SaaS app whether you rely on native retention, scheduled exports, or a third-party backup tool. Document the rationale.

5. Mistake: Evidence is screenshot-only and inconsistent.
   Fix: Standardize evidence pulls. Use exports, reports, and a checklist so evidence looks the same each cycle. ¹

Enforcement context and risk implications

No public enforcement cases are provided in the supplied source catalog for this safeguard, so you should treat this requirement as a control baseline and an auditability expectation rather than a direct enforcement trigger. The practical risk is still high: poor backups increase downtime, impair incident recovery, and can turn a containable event into a material business interruption. ¹

A practical 30/60/90-day execution plan

Goal: Stand up an auditable, automated backup control with recurring evidence capture aligned to safeguard 11.2. ¹

First 30 days (Immediate)

• Confirm executive owner (IT Ops or Security) and define RACI for backup operations and evidence.
• Build the backup scope register from asset inventory; identify obvious gaps (SaaS, file shares, niche databases).
• Inventory existing backup tools and native platform capabilities; map each in-scope asset to a method.
• Define what evidence you will collect each cycle (configs, logs, alerts, tickets) and where it will be stored.

By 60 days (Near-term)

• Implement or standardize automated schedules for all high-priority in-scope systems.
• Turn on alerting for failures and route to a monitored queue.
• Establish the failure handling workflow and require ticket closure notes.
• Run an initial restore validation for a representative system and document results.

By 90 days (Operationalize and sustain)

• Close remaining coverage gaps, including SaaS exports/backup where needed.
• Formalize the control narrative: “What 11.2 means here,” scope, tools, responsibilities, and evidence list. ¹
• Start recurring evidence capture and management review, and track exceptions with approvals.
• If you use Daydream, configure the control record and evidence requests so the process runs without manual chasing. ¹

Frequently Asked Questions

Does “automated backups” mean every system must be backed up the same way?

No. You can mix native snapshots, backup software, database-native backups, and SaaS exports. The requirement is that backups are scheduled and not dependent on a person remembering to run them. ¹

Are SaaS systems in scope for safeguard 11.2?

If the SaaS holds critical business records, treat it as in scope and document your approach. That may be scheduled exports, a third-party SaaS backup tool, or documented reliance on provider features with retained evidence. ¹

What evidence is strongest for auditors: screenshots or exports?

Exports and system-generated job histories are stronger because they show repeatable operation and dates. Screenshots can supplement, but they should not be your only evidence. ¹

How do we handle systems that cannot be backed up automatically?

Put them on an exception register with an owner, rationale, compensating measure, and periodic review. Auditors typically accept exceptions when they are explicit, approved, and managed. ¹

Who should own safeguard 11.2, Security or IT?

IT operations usually owns execution, while Security/GRC owns control definition, testing, and evidence. Write it down in a RACI so failures do not sit in a gray area. ¹

How do we show the control operates “over time”?

Keep recurring evidence pulls (job history reports, config snapshots) and link them to your scope register. Pair that with a small sample of failure tickets and restore validations from different points in the period. ¹

Footnotes

1. CIS Controls v8

2. CIS Controls Navigator v8