Safeguard 3.11 encrypt sensitive data at rest: evidence

What Safeguard 3.11 asks for when sensitive data sits at rest

Safeguard 3.11 asks you to encrypt sensitive data wherever it is stored: on servers, inside applications and in databases. If you have been told this Safeguard applies to you, the first question is which systems hold sensitive data at rest, and the second is whether each of them encrypts it. The minimum is storage-layer encryption, meaning the server or storage platform encrypts data on write and decrypts it on read for authorized access. The stronger option is application-layer encryption, where the application encrypts data before it reaches storage, so someone with access to the disks, backups or database files cannot read plaintext without also reaching the keys. The Safeguard does not require one approach over the other, but the choice determines who can read the data when storage is compromised.

The risk sits in copies. Sensitive data rarely lives in one place: it appears in database replicas, file shares, search indexes, log files, analytics exports, developer workstations and backup sets. Each unencrypted copy is a path around the controls protecting the primary system. This is why the hard part of Safeguard 3.11 is usually discovery, not configuration. Before you change any setting, ask your data owners and platform teams for a list of every store that holds sensitive data, and cross-check it against your asset and software inventories (Safeguards 1.1 and 2.1), which the CIS Controls Assessment Specification treats as prerequisites for measuring this Safeguard. Stores that nobody has listed are the ones most likely to be unencrypted.

In CIS Controls v8.1, Safeguard 3.11 sits in the Data asset class and the Protect security function. It applies to Implementation Groups 2 and 3, not to IG1, so an organization that has only adopted IG1 is not measured against it. If you are in IG2 or IG3, confirm your own Implementation Group with your assessor or governance lead before you scope the work, because it determines what evidence you must produce. Keep the encryption decision for each store in your data inventory, with the method used, the key location and the owner responsible, so the evidence follows the data rather than a single system.

Which stores fall under Safeguard 3.11 and how scope changes the work

The number of stores an assessor measures for Safeguard 3.11 depends on a handful of decisions made before any encryption work starts. Each decision below changes the population, so settle them in writing and tie them to the data inventory and classification.

Servers, databases and application stores

Start with the data inventory and classification labels. Every server volume, database and application store that holds sensitive data belongs in the population, including file shares, document stores and message queues that persist records. Stores that only hold public or low-sensitivity data drop out, but only if the classification scheme says so explicitly. Ask the team to list each store, its owner and the sensitivity label applied, then confirm that the list matches what the inventory shows as running.

Backups and replicas

Backups, snapshots and read replicas copy the same sensitive records, so an assessor may treat each copy as its own store. Decide whether copies inherit the encryption status of their source or must be checked on their own. Backup targets are a common gap because they sit outside the production runbook. Confirm that every backup repository and replica is listed, and that its encryption is verified rather than assumed from the source.

Cloud-managed versus self-managed storage

Managed database and object storage services often encrypt at rest by default, while self-managed servers and databases need explicit configuration and key handling. Both count in the population. The difference lies in evidence: for managed services, record the provider setting and key source; for self-managed stores, record the configuration file, the key location and the verification command. Confirm which keys the provider manages and whether the organization can see and rotate them.

Third-party hosted stores

Sensitive data held by a service provider still reflects on the organization's own data flows and inventory. Where a provider hosts a store on the organization's behalf, the organization must know the store exists, what it holds and how it is encrypted. Ask providers for their encryption attestations and key management terms, and record gaps in the service provider file. Stores the provider runs entirely for itself are a separate question and should be documented as such.

IG2 versus IG3 scope

Safeguard 3.11 applies from Implementation Group 2, and IG3 adds the same Safeguard with the same encryption expectation, so the store population does not shrink at IG2. What changes is the surrounding context: IG3 organizations usually hold more regulated and sensitive assets, which tends to enlarge the population and the depth of key management review. Confirm which Implementation Group the organization claims before scoping, because the claim determines which Safeguards the assessment covers.

Scope drift from new stores

The population changes whenever a new store appears, such as a new analytics database or an export bucket created for a project. Without a trigger that updates the inventory, stores added after the scope was set will be missed at assessment. Tie store creation to the change process so that each new sensitive store is classified, listed and encrypted before it receives data. Re-check the population at least at each review cycle.

How an assessor tests Safeguard 3.11 coverage

This table shows what an assessor samples, what evidence they request and where coverage usually fails for each part of Safeguard 3.11. The CIS Controls Assessment Specification defines four measures for this Safeguard, combined into one coverage metric, and it describes what to measure rather than how, so the test approach below is an illustrative pattern to confirm with your assessor. Read each row as a step that feeds the final coverage result.

Test area	Test approach and evidence requested	Common findings
Population of sensitive stores	Assessor compares the store list against the enterprise asset inventory (Safeguard 1.1) and software inventory (Safeguard 2.1), then asks which databases, file stores, application data sets and backups hold sensitive data per the data management process.	Stores missing from the list, such as shadow databases, exports, test copies or backup targets that no inventory records.
Encryption state of each store	Assessor samples stores from the population and requests configuration exports showing storage-layer encryption status, with timestamps and the scope each setting covers.	Encryption enabled on the primary volume but not on replicas, snapshots or backups; settings that were never verified after a migration.
Application-layer encryption (where used)	Where teams use application-layer encryption as the stronger option, assessor requests design documentation and a sample record showing ciphertext in storage.	Documentation describes the design, but sample records show plaintext fields, or only some fields are encrypted.
Key handling	Assessor requests key inventory, key custodians, rotation records and whether keys are stored apart from the encrypted data.	Keys stored next to the data or in configuration files, no rotation history, or keys shared across unrelated stores.
Coverage result	Assessor calculates coverage as the share of sampled sensitive stores that meet the encryption requirement, then checks the population was complete before accepting the figure.	A high coverage figure based on an incomplete store population, which the assessor will reject once the inventory gap is found.

Which evidence shows sensitive stores are encrypted at rest

Safeguard 3.11 is verified through records that connect each sensitive store to its encryption state, its keys and its exceptions. The cards below are the artifacts an assessor will ask to see, and each one needs a refresh rhythm so the package still matches production when the audit starts.

Reconciled list of sensitive stores

This is the list of every database, file store, object bucket and application data volume that holds sensitive data, reconciled against the data inventory from Safeguard 3.2. Reconciliation means each store on the list maps to a data type and owner, and each data inventory entry maps to at least one store. Because the assessment specification relies on the asset and software inventories (Safeguards 1.1 and 2.1), check that stores discovered in those inventories appear here. Refresh it on a schedule and whenever a new store is provisioned.

Encryption configuration exports per store

For each store on the list, keep a configuration export or a dated screenshot that shows encryption at rest is enabled and which key source it uses. Exports from infrastructure-as-code state or the platform's own CLI are more reliable than screenshots because they can be diffed over time. For self-hosted file platforms, the server-side encryption settings in Nextcloud are one example of what to capture. Schedule exports so no store goes unverified for a full review cycle.

Key management records

Record who can create, read, rotate and destroy the keys that protect each sensitive store, and keep a rotation history with dates and reasons. Assessors look for separation between the people who administer the data and the people who hold the keys, and for evidence that rotation actually happened. A transit encryption service such as OpenBao keeps versioned keys and rotation events that can be exported into this record. Confirm with your own environment how key access is logged before you rely on it.

Approved exceptions with risk acceptance

Some stores cannot be encrypted at rest for a technical reason, such as a legacy appliance or a vendor platform without native support. Each exception needs a written description of the store, the data it holds, the compensating controls, a named risk owner and a review date. An exception without a signed risk acceptance is a finding, not a documented gap. Review the exception register at each change window, and close entries when the store is migrated or replaced.

Secret scanning and credential exposure checks

Encryption at rest fails quietly when keys or passwords are stored in plain text beside the data they protect, in repositories, configuration files or pipeline logs. Keep the output of secret scanning jobs that run on commits and pushes, and treat each detected secret as a finding with a remediation record. GitLab Community Edition writes pipeline secret detection results to a JSON job artifact that can be archived with each release. Confirm that scans cover the repositories that hold infrastructure definitions.

Recurring coverage report

A coverage report compares the reconciled store list with the configuration exports and exceptions register, and states the percentage of sensitive stores with verified encryption at rest. This matches the single coverage metric the assessment specification defines for Safeguard 3.11. Generate it on a fixed cadence and after any change to the store list, then have the owner of Safeguard 3.11 sign it. Ask your auditor which reporting period they expect before you set the cadence.

Implementing Safeguard 3.11 from inventory to coverage evidence

This sequence takes an organization from a confirmed list of sensitive data to a recurring report that shows which sensitive data stores are encrypted, how keys are managed and where exceptions are recorded. Each step names the artifact the reader should hold before moving on.

Confirm the sensitive data population
Start from the data inventory and the classification scheme that Safeguards 3.2 and 3.7 produce, and list the data types that count as sensitive for your organization. The data owner and the security lead should sign off on this list, because it defines what Safeguard 3.11 covers. Done means you hold a written list of sensitive data categories, each tied to an owner and to the systems where it is believed to reside. If either inventory is incomplete, record that gap now, since every later step inherits it.
Build the store list from Safeguards 1.1 and 2.1
Use the enterprise asset inventory from Safeguard 1.1 and the software inventory from Safeguard 2.1 to list every server, application and database that holds the sensitive categories from the previous step. The CIS assessment specification treats these two inventories as prerequisites because they usually produce the data the measurement needs. Done means you have a store register with one row per database, file share, application data volume or object store, including the owning team and whether it is hosted in your own infrastructure or by a service provider.
Choose the encryption layer for each store class
Group the stores in the register by class, such as relational databases, file storage, application data stores and backups. For each class, record storage-layer (server-side) encryption as the minimum, and decide whether application-layer encryption is justified for stores where access to the underlying storage must not reveal plaintext. The decision and its reason should be written down per class. Done means each store has an assigned layer and a short rationale that an assessor can read without asking the author.
Enable and verify encryption on each store
The system owners enable encryption on each store according to the chosen layer, then verify it with a check that inspects the store itself rather than the configuration document. For server-side file storage, the Nextcloud admin manual describes server-side encryption, which protects file contents at rest but does not encrypt file names or folder structure, so record that limit explicitly. Done means each store has a dated verification result, and any store that fails verification is moved to the exceptions record.
Set up key management and rotation
Decide where encryption keys are generated, stored and rotated, and keep keys separate from the data they protect. For application-layer encryption, OpenBao's transit secrets engine can encrypt and decrypt application data without storing it and supports versioned keys with rotation, which you should confirm against your own deployment design. Document key owners, rotation procedure, and the steps for recovering access if a key is lost. Done means a key management record exists for every key class, and a test rotation has been run and logged.
Record exceptions with owners and review dates
Some stores will not meet the encryption standard on the planned date, whether because of legacy platforms, vendor limits or technical constraints. Record each exception with the store name, the sensitive data it holds, the compensating measures in place, the accountable owner and the date by which it will be reviewed or closed. Done means the exceptions register is complete, reviewed by the data owner, and linked from the coverage report so that no store is silently excluded.
Establish a recurring coverage report
Produce a coverage report that shows, for each store in the register, whether encryption is enabled, which layer applies, when it was last verified and which exceptions remain open. The CIS assessment specification measures Safeguard 3.11 with a coverage metric built from four measures, so the report should let you calculate that coverage consistently each cycle. Confirm the measures and metric definitions in the assessment specification before you finalize the report template. Done means the report has been produced once end to end and the owner has agreed on the schedule for repeating it.

Which open-source platforms produce encryption-at-rest evidence

Nextcloud is a self-hosted file sharing and collaboration platform licensed under AGPL-3.0-only. Its server-side encryption module protects file contents at rest on local and external storage, and the encryption keys are kept on the server. This makes it a candidate for the storage-layer encryption that Safeguard 3.11 treats as the minimum for files holding sensitive data. The evidence an assessor will want is a record that the module is enabled, which storage backends are covered, and how the keys are managed and protected.

File contents are encrypted: Server-side encryption protects the contents of files at rest, including on external storage mounts.
Metadata stays visible: File names and folder structure are not encrypted, so sensitive information in names must be handled by other controls.
Keys sit on the server: Because keys are held server side, the key storage and access controls become part of the evidence.
Configuration is the evidence: Exported configuration, a dated screenshot of the encryption status and the list of mounted storage locations show the control in operation.
Coverage needs a check: Confirm which external storage types and app integrations your version supports before you count them as covered.

Confirm each capability against the Nextcloud version and storage setup you run, using the Nextcloud admin manual on encryption configuration.

What it costs to encrypt sensitive data at rest

This table compares the main cost components of encrypting sensitive data at rest under Safeguard 3.11, showing who is paid, whether each cost is one-time or recurring, what drives it, and how to keep it down. Read it as a checklist for a written quote, since no price or duration is stated here and the largest variables depend on your storage, key management and application architecture.

Cost component	One-time or recurring	What drives it	How to reduce it
Licenses or cloud-provider encryption features	Recurring	Whether storage encryption is included in the platform or billed as a separate feature, and which key management service it calls	Confirm with each provider which encryption features are included at your tier. Self-hosted open-source platforms such as Nextcloud remove per-seat license spend for the encryption feature itself
Key management infrastructure	One-time setup, recurring operation	Whether keys sit in a hardware security module, a managed key service or a self-hosted secrets engine such as OpenBao, and the redundancy you require	Ask the provider to quote hardware and managed key service fees separately. OpenBao is open source under MPL-2.0, so its software cost is zero, but hardware and operations staffing remain
Engineering time to enable and verify encryption per store	One-time, with ongoing effort for new stores	The number of servers, databases, file stores and applications holding sensitive data, and how many use different encryption configurations	Build an inventory of sensitive data stores first (Safeguards 1.1, 2.1 and 3.2 feed this), then enable encryption store by store with a repeatable verification check
Application-layer encryption development and testing	One-time build, recurring maintenance	How many applications need field-level or client-side encryption, the data types involved and the testing needed to confirm plaintext is not exposed	Limit application-layer encryption to the data types that need it. Scope it in a fixed written plan before development starts
Key rotation and evidence upkeep	Recurring	Key rotation frequency set by your data management process, the number of key versions retained, and how much evidence is generated per store	Automate rotation and export logs as evidence on a schedule. Versioned keys in OpenBao support rotation without re-encrypting every record at once
External review or assessor sampling	Recurring, per assessment cycle	The assessment scope, how many stores an assessor samples, and whether the review is a CIS Controls assessment, a framework audit or an internal check	Keep one current inventory and evidence pack so sampling is quick. Ask the independent assessor for its sampling approach in writing before fieldwork begins

Who owns encryption at rest: your team, a partner and the auditor

Your organization owns Safeguard 3.11. CIS states that the Controls are used by the enterprise to improve its own cybersecurity, so the accountable people are yours: the security leader who accepts residual risk, the data owners who decide which data is sensitive, and the platform owners who run the stores. Classification decisions come first, because the encryption scope follows from them. Key custody also stays with you. Decide who holds key material, how keys are rotated, and who can revoke them.

Classification decisions: Define which data counts as sensitive and which stores hold it, drawing on the data management process and data inventory.
Key custody: Name the key owners, approve the key hierarchy and document separation of duties between administrators and key holders.
Risk acceptance: Record any store that cannot yet be encrypted, with a compensating control and an owner who signs the exception.
Operations: Run rotation, monitor encryption status and keep the coverage inventory current after every new store is added.
Final sign-off: Review evidence before the auditor sees it and confirm the scope matches what the business actually runs.

Check that every sensitive store has a named owner and that no encryption exception exists without a signed acceptance.

Where organizations fall short on encryption at rest and how to close it

Most organizations that claim encryption at rest for sensitive data have the cipher right and the surrounding evidence wrong. The gaps below sit in the store inventory, key handling, rotation records, application claims, ownership and exception handling. Each card names one closing action that produces evidence an assessor can test.

Sensitive copies missing from inventory

Backups, database replicas and analytics extracts often hold the same sensitive data as production but never appear in the data inventory built under Safeguard 3.2. An encryption check that only covers the primary database measures a fraction of the exposure. Close the gap by tracing each sensitive data source to every copy, then recording encryption status per copy. Ask the team to show the backup target and the analytics warehouse on the same list as production.

Keys stored beside the data

Encryption turned on with the key kept on the same volume, in the same configuration file or in the same bucket is encryption in name only. Anyone who can read the storage can usually read the key. Check where each key lives and who can read it. Move keys into a dedicated key management service, such as OpenBao's transit secrets engine for application data, and keep an access log of key use as evidence.

No key rotation record

Teams often enable versioned keys but cannot show when a key was last rotated, who approved it, or whether older ciphertext was re-encrypted. Assessors look for a dated record linking each key version to its rotation event. Set a documented rotation schedule for each key class, then export the rotation history from the key store as recurring evidence. Confirm whether the platform supports key versioning and rewrap before promising it.

Application-layer claims without tests

A product page or design document may say that application-layer encryption protects sensitive fields, yet nobody has tested whether a database administrator can read plaintext. Safeguard 3.11 accepts application-layer encryption as the stronger option only when access to the storage does not reveal plaintext. Run a test that reads the raw storage as a privileged operator and record the result. Keep the test script and output in the evidence set.

Unclear ownership of the store population

When no one owns the list of sensitive stores, new databases, buckets and file shares appear without encryption review. Assign a named owner for each store class, and make that owner responsible for keeping inventory entries current. Tie the owner to the data management process from Safeguard 3.1. Evidence is a register with an owner field that is reviewed on a set cycle, showing who signed off on each store.

Exceptions without approved risk acceptance

Legacy systems that cannot encrypt at rest are often left running with an informal note or a verbal agreement. An assessor will ask for the approved exception, its compensating controls and its end date. Record each exception in a risk register with a named approver, a compensating control such as network isolation, and a review date. Confirm the approval chain with your own governance process before the assessment begins.

Safeguard 3.11 cost, effort and what you can do in-house

How much effort does meeting Safeguard 3.11 take, and what drives it?

The effort depends mostly on how many data stores hold sensitive data and how many of them already encrypt at rest. Safeguard 3.11 asks for sensitive data on servers, in applications and in databases to be encrypted, with storage-layer encryption as the minimum and application-layer encryption as a stronger option. Each store needs to be identified, checked, configured and evidenced, so a small estate with a few managed databases is far less work than a sprawling one with self-built applications and file shares. Application-layer encryption adds design, key handling and code changes, which usually costs more than enabling storage-layer encryption. Before estimating effort, confirm the store count with your own inventory, and ask any implementation partner to base its quote on that list.

Does an IG1 organization have to meet Safeguard 3.11?

No. CIS Controls v8.1 assigns Safeguard 3.11 to Implementation Groups 2 and 3 only, so it is not part of the IG1 essential cyber hygiene baseline. An IG1 organization can still choose to encrypt sensitive data at rest, and doing so is a sound practice, but the Safeguard itself is not expected at that level. Organizations that handle sensitive data and are subject to a regulation or contract may need equivalent encryption regardless of their CIS Implementation Group, so check those requirements separately. Confirm your Implementation Group against the CIS Implementation Groups page before scoping this work.

How long does encrypting sensitive data at rest take?

The timeline is set by the number of stores, the change windows available for production systems, and whether applications need code changes. Enabling storage-layer encryption on a server or database is often a bounded task, while application-layer encryption requires design decisions, key management integration, testing and data migration, which extends the schedule. Key management also sets the pace, because keys must be generated, stored, rotated and recoverable before data is re-encrypted. Ask for a phased plan in any quote, with one milestone per store group and a separate milestone for the evidence package. A fixed-scope agreement fixes the timeline only after the scope is written down.

Can a small team implement Safeguard 3.11 without outside help?

A small team can do it alone if it has someone who administers each data store, a clear inventory of where sensitive data lives, and time to test changes without disrupting service. The harder parts are usually application-layer encryption, key custody and backup handling, because a mistake there can make data unrecoverable. Teams without database or security engineering skills often bring in a partner for the design and the evidence work while keeping day-to-day operation in house. Whichever route you choose, the organization owns its controls. An independent auditor or certification body, not the implementer, issues any report or certificate.

What does the work need from our side?

It needs three kinds of input. First, access to the enterprise asset and software inventories, since Safeguards 1.1 and 2.1 are prerequisites for measuring Safeguard 3.11 and typically supply the data the measurement needs. Second, named store owners for each database, server group and application who can confirm what sensitive data they hold and approve changes. Third, key custodians who control key generation, storage, rotation and recovery and who can attest to who has access to those keys. Ask your provider to list these roles and the hours expected from each before work starts.

Do self-hosted open-source tools remove the license cost?

They remove software license fees for the tools themselves, but not the other costs of meeting the Safeguard. Nextcloud server-side encryption protects file contents at rest with keys kept on the server, and it does not encrypt file names or folder structure, so you must account for that gap. OpenBao's transit secrets engine can encrypt and decrypt application data without storing it and supports versioned keys with rotation, which fits application-layer designs. Labor, infrastructure, testing, key ceremony and evidence collection remain. Check each tool's license terms and support model with its publisher, and confirm current capabilities in the vendor documentation before relying on them.

How DeployOpen scopes and prepares encryption at rest evidence

DeployOpen plans, implements and documents self-hosted open-source platforms inside the client's own infrastructure, so encryption at rest for sensitive data is set up where the data actually lives. The organization keeps ownership of its controls, and DeployOpen prepares the systems and evidence that an independent assessor would review.

How we scope

Engagements are fixed-scope, with the systems, data stores and encryption layers agreed in writing before work starts.
The written scope lists which servers, applications and databases holding sensitive data fall under Safeguard 3.11.
Scope records whether storage-layer encryption, application-layer encryption or both are in place for each data store.
Prerequisite inventories of enterprise assets and software are confirmed as inputs before the encryption design begins.

How we build

Storage-layer encryption is configured on the chosen platforms, with key storage kept separate from the encrypted data.
Where application-layer encryption is in scope, key handling and rotation are designed with the client's security team.
Platforms such as Nextcloud server-side encryption or OpenBao's transit secrets engine are configured to the client's requirements.
Configuration is documented so that each encrypted store can be traced to a named key and a named owner.

How we hand over

Deliverables include configuration records, key management procedures and a coverage listing of encrypted sensitive data stores.
Evidence packs map each encrypted store to its Safeguard 3.11 measure, so the client can show coverage to an assessor.
Test results confirm that data at rest is unreadable without the keys, and the findings are recorded for remediation.
The client receives documentation it can maintain, and DeployOpen does not issue audit reports or certifications.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the initial handover.
Key rotation schedules, platform upgrades and new data stores are reviewed as the environment changes.
Clients should confirm with DeployOpen how retainer support covers evidence refresh before an assessment cycle.
Independent auditors or assessors remain responsible for any formal review of the encryption controls.