Safeguard 3.11: Encrypt Sensitive Data at Rest

To meet the safeguard 3.11: encrypt sensitive data at rest requirement, you must identify where sensitive data is stored and ensure it is encrypted on every storage layer (endpoints, servers, databases, backups, and removable media), with keys protected and rotation/auditability in place. Then you must retain clear evidence that encryption is consistently enabled and monitored per CIS Controls v8. ¹

Key takeaways:

• Encrypting “at rest” means covering disks, volumes, databases, object storage, backups, and exported snapshots, not just production databases.
• Evidence wins assessments: you need configuration proof, key-management proof, and recurring verification, mapped to Safeguard 3.11. ¹
• Most failures are scope and operational drift: unknown data stores, “temporary” exports, unmanaged endpoints, and backups without encryption.

Encrypting sensitive data at rest is a requirement-level control because it reduces impact when storage is lost, stolen, misconfigured, or accessed without authorization. Safeguard 3.11 expects you to make encryption the default state for sensitive data wherever it persists, not a one-off project that “should be enabled.”

For a CCO or GRC lead, the operational goal is straightforward: define what “sensitive data” means for your organization, map where it lives, enforce encryption using standard platform controls, and prove it with durable evidence. The fastest path is to treat encryption-at-rest as a baseline configuration requirement tied to data classification and asset inventory. Then wrap it with key management, change control, and recurring verification so the control keeps working after migrations, new services, and third-party integrations.

This page focuses on execution: scope decisions, implementation steps, audit-ready artifacts, and the questions assessors ask when they test whether encryption is real, consistent, and measurable. The underlying requirement is Safeguard 3.11 in CIS Controls v8. ¹

Regulatory text

Requirement: “CIS Controls v8 safeguard 3.11 implementation expectation (Encrypt Sensitive Data at Rest).” ¹

Operator interpretation: You must ensure sensitive data is encrypted when stored on any persistent medium you control (or that a third party controls on your behalf), and you must be able to demonstrate it through documentation and recurring evidence capture mapped to Safeguard 3.11. ¹

What this means in practice:

• “At rest” covers disks/volumes, database storage, filesystems, object storage, backups, snapshots, and removable media.
• “Sensitive data” must be defined by your classification scheme, then applied consistently to systems and datasets in scope.
• “Encrypt” implies you select and enforce an encryption mechanism appropriate to the storage layer and manage keys so encryption cannot be trivially bypassed (for example, keys stored alongside the data).

Plain-English requirement interpretation (what the control is really testing)

Assessors are trying to answer three questions:

1. Do you know where sensitive data lives? If you can’t enumerate storage locations, you can’t credibly claim encryption coverage.
2. Is encryption actually enabled everywhere it should be? They will test endpoints, servers, cloud storage, databases, and backups. They will also look for “shadow” copies: exports, analytics extracts, log sinks, and data shared with third parties.
3. Can you prove it stays enabled over time? A point-in-time screenshot is weak. Recurring checks, configuration management, and exception handling are strong.

CIS Safeguard 3.11 also has an evidence expectation: map the safeguard to documented control operation and recurring evidence capture. ¹

Who it applies to

Entity scope: Enterprises and technology organizations adopting CIS Controls v8, especially those storing regulated, confidential, or business-critical data. ¹

Operational scope (systems and data):

• Endpoints: laptops/desktops used by workforce members who access or store sensitive files.
• Servers and VMs: any system with sensitive data on attached volumes.
• Databases: managed or self-hosted relational/non-relational stores.
• Cloud storage: object stores, file shares, block storage, and managed disks.
• Backups and archives: backup repositories, long-term archives, cold storage, snapshots.
• Removable media: USB drives, external disks, media used for transfers.
• Third parties: SaaS platforms, managed service providers, and processors storing sensitive data on your behalf (you still own the risk; contract terms and due diligence become part of “doing the control”).

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

Use this as a build sheet you can hand to Security/IT with clear acceptance criteria.

1) Define “sensitive data” for encryption-at-rest scope

• Adopt or reuse a classification scheme (examples: Restricted/Confidential/Internal/Public).
• Write a one-page scope statement: which classes require encryption at rest and where exceptions may exist.
• Set decision rules (example: “customer PII is always encrypted at rest in any storage layer, including backups and exports”).

Deliverable: Data classification + encryption-at-rest scope standard, approved by the control owner.

2) Create a storage inventory for sensitive datasets

• Start from known systems: primary applications, data warehouse, CRM/ERP, file shares.
• Add “copy pathways”: ETL jobs, S3/object buckets, BI extracts, ticket attachments, email gateways, log aggregation.
• Include third-party repositories where your sensitive data is stored.

Deliverable: “Sensitive Data Store Register” (system, dataset type, owner, storage layer, encryption method, key owner, monitoring, exception status).

3) Select encryption mechanisms per storage layer (standardize)

You want consistency, not bespoke crypto.

• Endpoints: full-disk encryption with centralized enforcement and recovery key handling.
• Servers/VMs: volume/disk encryption for attached storage; ensure base images/blueprints inherit encryption settings.
• Databases: prefer platform-native at-rest encryption; decide whether you also need column/field-level encryption for specific high-risk fields.
• Object/file storage: server-side encryption and policies that deny unencrypted writes.
• Backups/snapshots: encryption enabled at creation and for replication targets; confirm restores preserve encryption requirements.
• Removable media: default deny, or require hardware-encrypted media with documented issuance.

Deliverable: Encryption standard by storage type, with “must/should/may” statements and owner.

4) Implement key management controls that make encryption meaningful

Encryption at rest fails in audits when key handling is sloppy.

Minimum operator expectations:

• Centralize key management ownership (KMS/HSM or equivalent).
• Restrict who can access keys and who can disable encryption.
• Document key rotation approach and incident procedures for key compromise.

Deliverable: Key management procedure + access control list for key admins and break-glass roles.

5) Enforce via policy-as-code / configuration guardrails where possible

Manual enablement creates drift.

Common guardrails:

• Cloud policies that block creation of unencrypted storage.
• Infrastructure-as-code modules that default encryption on.
• Endpoint management policies that enforce disk encryption and report compliance.

Deliverable: Guardrail evidence (policy definitions, configuration baselines, and a sample of enforcement logs).

6) Define and run recurring verification (the “prove it” step)

CIS evidence expectations point directly at recurring evidence capture. ¹

Build a repeatable check:

• A scheduled report or query for each platform showing encryption status by asset/dataset.
• An exception list with expiry dates and compensating controls.
• A remediation workflow for noncompliant assets.

Deliverable: Monthly/quarterly encryption-at-rest compliance report + ticket artifacts showing remediation or exception approval.

7) Map Safeguard 3.11 to control operation and evidence capture

This is the recommended control action in your source pack: map 3.11 to documented control operation and recurring evidence capture. ¹

What “mapped” looks like:

• Control statement: objective, scope, roles, frequency, tools, and evidence.
• Test procedure: how an internal auditor would sample and verify.
• Evidence index: where artifacts live, who produces them, and how long you retain them.

How Daydream fits: Use Daydream to document the control once, attach recurring evidence on a schedule, track exceptions with expiry, and generate an assessor-ready evidence packet tied directly to Safeguard 3.11. ¹

Required evidence and artifacts to retain

Keep evidence that answers “scope, enforcement, and ongoing proof.”

Core artifacts (recommended minimum set):

• Policy/standard: encryption-at-rest standard tied to data classification.
• Sensitive Data Store Register: inventory of in-scope systems and storage locations.
• Configuration proof: screenshots/exports from endpoint management, cloud configurations, database settings, backup settings.
• Key management proof: KMS/HSM configuration overview, key admin access list, rotation procedure.
• Monitoring/verification outputs: recurring reports showing encryption status and exception tracking.
• Exceptions: formal risk acceptance with compensating controls, approval, owner, and expiry.
• Change records: tickets/PRs showing encryption enabled during provisioning or migration.

Common exam/audit questions and hangups

Expect these lines of questioning:

• “Show me all places customer data is stored, including backups and analytics extracts.”
• “How do you prevent an engineer from creating an unencrypted bucket/volume?”
• “Who can disable encryption or access keys? Show me the access reviews.”
• “How do you verify encryption remains enabled after changes?”
• “Do third parties store your sensitive data, and how do you confirm encryption at rest there?”

Hangups that slow assessments:

• Encryption is “enabled” but keys are unmanaged or broadly accessible.
• Coverage gaps: endpoints, snapshots, dev/test copies, or exports.
• Evidence is ad hoc: one screenshot with no recurrence or sampling logic.

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails	How to avoid
Treating “database encryption” as complete coverage	Files, caches, exports, and backups still hold sensitive data	Maintain a storage inventory; validate each storage layer
Relying on manual enablement	Drift after migrations and new projects	Default encryption in templates/IaC; enforce with policy guardrails
No exception process	Teams create silent workarounds	Publish exception workflow with expiry and compensating controls
Keys stored next to data or shared too widely	Encryption becomes a paper control	Centralize key management; restrict key admin roles
Weak evidence	You can’t prove ongoing control operation	Produce recurring reports and retain them in a control evidence binder

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite specific actions.

Risk implications to communicate internally:

• Breach impact: If an attacker exfiltrates storage media or snapshots, encryption at rest can reduce data exposure.
• Operational resilience: Proper key management and backup encryption reduce “unknown copies” risk but require tested recovery procedures so encryption does not block restoration in an incident.
• Third-party risk: Sensitive data stored by third parties should be contractually protected; request attestations and configuration evidence where feasible.

Practical 30/60/90-day execution plan

No source-backed timelines were provided, so treat these as execution phases you can adjust to your change cadence.

Days 0–30: Establish scope, ownership, and visibility

• Assign control owner and key stakeholders (Security, IT, Data, App owners).
• Publish encryption-at-rest standard tied to data classification.
• Build the Sensitive Data Store Register for top systems and third-party platforms.
• Identify quick wins: enforce endpoint full-disk encryption reporting; enable encryption defaults in major cloud accounts.

Exit criteria: clear scope statement; initial inventory; at least one recurring report draft for a major platform.

Days 31–60: Enforce defaults and close high-risk gaps

• Implement guardrails to block unencrypted storage creation where supported.
• Standardize database and object storage encryption configurations.
• Lock down key admin roles; document rotation and incident procedures.
• Implement backup encryption consistently and validate restore paths.

Exit criteria: encryption enabled for core data stores and backups; key management documented; exception process active.

Days 61–90: Operationalize evidence and audit readiness

• Schedule recurring evidence capture (reports, samples, exceptions, remediation tickets).
• Run an internal control test: sample assets and prove encryption end-to-end (including backups and a third-party system).
• Build an assessor packet mapped to Safeguard 3.11, including control narrative and evidence index. ¹

Exit criteria: repeatable verification, exception governance, and a clean evidence trail.

Frequently Asked Questions

Does “encrypt at rest” include backups and snapshots?

Yes for practical assurance. If a backup, snapshot, or replica contains sensitive data, treat it as in scope and encrypt it, then retain proof through recurring checks.

Is full-disk encryption on laptops enough for Safeguard 3.11?

It covers endpoint storage, but Safeguard 3.11 also applies to servers, databases, cloud storage, and backups that store sensitive data. Your evidence should show coverage by storage layer. ¹

Can we meet the requirement with application-level (field) encryption only?

Field encryption can help for specific high-risk elements, but it does not replace storage-layer encryption for files, backups, indexes, and exports. Most programs implement storage-layer encryption as the baseline, then add field encryption where needed.

What evidence do auditors accept for encryption-at-rest?

Auditors typically accept a combination of configuration exports/screenshots, a system inventory showing what’s in scope, and recurring compliance reports with remediation tickets. The evidence should be explicitly mapped to Safeguard 3.11. ¹

How should we handle third parties that store our sensitive data?

Put encryption-at-rest expectations into contracts and security requirements, then collect due diligence evidence (attestations, architecture statements, or config-level proof where available). Track the third party system in your Sensitive Data Store Register.

What should an exception look like?

An exception should name the system/dataset, the reason encryption cannot be enabled, compensating controls, an approving authority, and an expiry date with a remediation plan. Store it alongside the Safeguard 3.11 evidence set.

Footnotes

1. CIS Controls v8; CIS Controls Navigator v8