CIS Control 3 Data Protection: Safeguards and Evidence

Organisations encrypt laptops and buy data loss prevention tools, yet still cannot say where their sensitive data lives, who can reach it or when it should be deleted. CIS Control 3, Data Protection, asks you to develop processes and technical controls to identify, classify, securely handle, retain and dispose of data. With 14 Safeguards it is one of the largest of the 18 CIS Controls, and its early, process-heavy Safeguards decide whether the later encryption, segmentation and DLP work is aimed at the right data. This guide covers each Safeguard in CIS Controls v8.1 by Implementation Group, the dependencies the CIS Controls Assessment Specification builds in, the evidence assessors expect, and where machine credentials and service accounts fit. It is for data protection, security engineering and GRC teams running or auditing a CIS programme; for the programme overview see the CIS Controls Guide.

Key takeaways

Six IG1 Safeguards set the foundation. A data management process (3.1), a data inventory (3.2), need-to-know access lists (3.3), retention (3.4), secure disposal (3.5) and end-user device encryption (3.6) apply to every organisation.
The process comes first, by design. The Assessment Specification makes 3.4, 3.5, 3.7 and 3.8 depend on 3.1 and 3.2, so retention, disposal and classification cannot be assessed until the process and inventory exist.
Retention means minimum and maximum. Safeguard 3.4 requires both timelines; keeping everything for ever fails it as surely as deleting too early.
Encryption is split by location. End-user devices at IG1, removable media, data in transit and data at rest on servers at IG2; DLP (3.13) and sensitive data access logging (3.14) at IG3.
Secrets are sensitive data. API keys, tokens, private keys and connection strings belong in the 3.2 inventory, and service accounts belong in the 3.3 access lists and the 3.14 access logs.

What it is and who it applies to

Control 3 is the third CIS Critical Security Control and the main data-centric control in v8.1. Every Safeguard sits in the Data asset class. CIS v8.1 expanded the glossary definition of "sensitive data", which matters here because most Control 3 Safeguards are scoped to it: you only have to inventory, encrypt and log what your own process classes as sensitive, but you must be able to show how you decided.

The control applies to any organisation adopting the CIS Controls, since six Safeguards are IG1. It covers data wherever the enterprise holds it:

Endpoints and removable media: laptops, desktops, mobile devices, USB drives.
Servers, databases and applications: on-premises and cloud, including file shares, object storage and data warehouses.
Service providers: 3.8 requires documented data flows to include service provider flows, and 3.13 requires DLP coverage of service provider assets.
Data in transit: between users, applications, services and partners.

Control 3 depends on Control 1 (asset inventory), Control 2 (software inventory, which lists the encryption and DLP tools), Control 4 (the configuration standard that encryption is measured against) and Control 5 (the account inventory used for access lists). Data recovery and backups are covered separately in the CIS Control 11 Data Recovery Guide.

Structure and key requirements

The 14 Safeguards below are taken from the CIS Controls Assessment Specification for v8.1, with the dependencies it lists.

Safeguard	Title	Function	IG	Key requirement	Depends on
3.1	Establish and Maintain a Data Management Process	Govern	IG1, IG2, IG3	Documented process addressing data sensitivity, data owner, handling, retention limits and disposal; reviewed annually	None
3.2	Establish and Maintain a Data Inventory	Identify	IG1, IG2, IG3	Inventory based on the process, sensitive data at minimum; reviewed annually	1.1
3.3	Configure Data Access Control Lists	Protect	IG1, IG2, IG3	Access lists based on need to know, for local and remote file systems, databases and applications	3.2, 4.1, 5.1
3.4	Enforce Data Retention	Protect	IG1, IG2, IG3	Retain data per the process, with minimum and maximum timelines	3.1, 3.2
3.5	Securely Dispose of Data	Protect	IG1, IG2, IG3	Disposal method commensurate with sensitivity	3.1, 3.2
3.6	Encrypt Data on End-User Devices	Protect	IG1, IG2, IG3	Encrypt end-user devices containing sensitive data, for example BitLocker, FileVault, dm-crypt	1.1, 2.1, 4.1
3.7	Establish and Maintain a Data Classification Scheme	Identify	IG2, IG3	Enterprise classification scheme, for example labels such as Sensitive, Confidential and Public; reviewed annually	3.1, 3.2
3.8	Document Data Flows	Identify	IG2, IG3	Data flow documentation including service provider flows; reviewed annually	3.1, 3.2
3.9	Encrypt Data on Removable Media	Protect	IG2, IG3	Encrypt data on removable media	1.1, 2.1, 4.1
3.10	Encrypt Sensitive Data in Transit	Protect	IG2, IG3	For example TLS and OpenSSH	3.2, 4.1
3.11	Encrypt Sensitive Data At Rest	Protect	IG2, IG3	On servers, applications and databases; storage-layer encryption meets the minimum	1.1, 2.1
3.12	Segment Data Processing and Storage Based on Sensitivity	Protect	IG2, IG3	Do not process sensitive data on assets intended for lower-sensitivity data	3.2, 12.4
3.13	Deploy a Data Loss Prevention Solution	Protect	IG3	Automated tool, such as host-based DLP, to identify sensitive data stored, processed or transmitted, onsite and at service providers, and update the inventory	2.1, 3.2
3.14	Log Sensitive Data Access	Detect	IG3	Log sensitive data access, including modification and disposal	1.1, 2.1, 4.1

Implementation Group summary

IG1 (six Safeguards): write the process, find the sensitive data, restrict access to it, keep it only as long as needed, dispose of it properly and encrypt laptops. Most of the effort is in 3.1 and 3.2.
IG2 (six more): formal classification, data flow maps, encryption on removable media, in transit and at rest on servers, and segmentation by sensitivity.
IG3 (two more): DLP and logging of access to sensitive data, both measured as coverage of the assets that hold it.

Encryption choices by Safeguard

Safeguard	Typical technology	Configuration point to standardise in 4.1	Common gap
3.6 End-user devices	BitLocker, FileVault, dm-crypt (LUKS)	Algorithm and key length, pre-boot authentication, recovery key escrow	Recovery keys not escrowed, or escrowed where too many admins can read them
3.9 Removable media	BitLocker To Go, encrypted USB devices, endpoint DLP device control	Block write to unencrypted media	Exceptions for "trusted" devices that are never reviewed
3.10 In transit	TLS, OpenSSH, mTLS between services	Minimum TLS 1.2, TLS 1.3 preferred; NIST SP 800-52 Rev. 2 is the US federal baseline	Internal service traffic and database connections left in clear text
3.11 At rest	Storage, volume, database (TDE) or application-level encryption	Key ownership, rotation and separation from the data	Keys stored alongside the encrypted data

Storage-layer encryption meets the 3.11 minimum but does not protect against anyone who can query the database or read the bucket through its normal interface. Where the threat is a stolen credential, access control (3.3) and logging (3.14) matter more than another encryption layer. See the Encryption Guide and the Cryptographic Key Management Guide.

Identity and NHI requirements

Most sensitive data is read by software, not people. Control 3 only works if machine identities are treated as first-class users of data:

Inventory secrets as sensitive data (3.2): API keys, OAuth tokens, private keys, certificates and connection strings should appear in the data inventory with an owner and location, including where they leak into code repositories, CI logs and object storage. The Sisense breach illustrates the chain: a credential in a code repository reportedly opened S3 buckets holding customer tokens. See the OWASP NHI Top 10 NHI2 Secret Leakage Guide.
Include service accounts in access lists (3.3): the Assessment Specification maps accounts from the Control 5 account inventory to sensitive data. Service accounts, managed identities and integration users often hold broader read access than any human. Scope them to the specific tables, buckets or shares they need. See the OWASP NHI Top 10 NHI5 Overprivileged NHI Guide.
Protect the keys that protect the data (3.6, 3.11): encryption is only as strong as access to the key. In the GoTo breach, attackers exfiltrated encrypted backups and an encryption key for a portion of them. Hold keys in a key management service or HSM, under identities separate from those that read the data.
Log non-human access (3.14): access logs must attribute reads to a specific workload identity, not a shared account, otherwise bulk extraction by a compromised integration looks like normal traffic.
Document flows that run on tokens (3.8): every data flow to a service provider is carried by an API key, OAuth grant or service account. Record that identity on the flow so revoking it is part of ending the relationship. See the Service Account Security Guide.

Implementation steps

Write the data management process (3.1). One document covering sensitivity levels, data owners, handling rules per level, minimum and maximum retention per data type, and disposal methods. Get it approved and set an annual review date. The Data Classification Policy Template is a starting point.
Build the sensitive data inventory (3.2). Start with the systems you already know hold regulated data (HR, finance, customer, payment), then use discovery tooling to find copies. For each item record sensitivity, owner and the asset from the Control 1 inventory that stores it.
Fix access lists (3.3). For each storing asset compare actual access with the owner's need-to-know list. Remove broad groups such as "Everyone" and "Domain Users" from sensitive shares first, then review service account permissions.
Turn on device encryption (3.6). Enforce through endpoint management with recovery keys escrowed. Report coverage against the end-user device count from Control 1.
Enforce retention and disposal (3.4, 3.5). Configure retention policies in your collaboration, email and storage platforms; schedule deletion of data past maximum retention; follow NIST SP 800-88 Rev. 2 for media sanitisation, including cryptographic erase where supported. See the Data Retention and Secure Deletion Guide.
Classify and map flows (3.7, 3.8). Publish labels, apply them by default where your platform supports it, and draw flows for each sensitive data type, including external providers. See the Data Classification Guide.
Encrypt removable media, transit and rest (3.9 to 3.11). Set the standards in your Control 4 configuration baseline, scan for weak TLS and unencrypted storage, and remediate by sensitivity.
Segment (3.12). Place assets handling sensitive data in separate network zones or cloud accounts; the Assessment Specification assumes an asset takes the highest sensitivity of any data it handles. See the Network Segmentation Guide.
Deploy DLP in simulation first (3.13). Most DLP platforms offer a test or simulation mode; Microsoft Purview, for example, applies no actions while a policy is in simulation mode. Tune for two to four weeks, enforce with policy tips and user override on a pilot group, then block for the highest sensitivity only. Roll back by returning the policy to simulation. See the Data Loss Prevention (DLP) Guide.
Log sensitive data access (3.14). Enable object-level and database audit logging on the assets in the inventory, forward to your SIEM and retain per Control 8.

Small versus large organisations

Small (IG1): a short process document, an inventory spreadsheet of a dozen systems, built-in retention in your email and file platform, and enforced device encryption satisfy most of the IG1 set.
Mid-sized (IG2): automated discovery becomes necessary to keep 3.2 current, and the classification scheme should drive labelling in collaboration tools.
Large or regulated (IG3): data security posture tooling, DLP across endpoint, email, cloud apps and service providers, and central access logging for every sensitive store.

Evidence and assessment

Safeguard	Evidence to prepare	How the Assessment Specification measures it
3.1	Approved process document and review date	Whether it addresses sensitivity, owner, handling, retention and disposal (five equal parts)
3.2	Sensitive data inventory mapped to sensitivity and to storing assets	Share of items fully and partially mapped; fails if sensitivity is not addressed or the inventory is older than 12 months
3.3	Access list exports for storing assets, owner approvals, account mapping	Users mapped to data, and share of assets configured to allow only authorised users
3.4, 3.5	Retention schedule with minimum and maximum per type, disposal methods, deletion and destruction records	Policy completeness, then share of inventoried data that complies
3.6, 3.9	Encryption compliance reports from endpoint management, configuration standard	Devices or media with approved encryption installed and properly configured
3.7, 3.8	Classification scheme, labelled data samples, data flow diagrams	Scheme coverage and correct classification; documented external flows; fails if older than 12 months
3.10, 3.11	TLS scan results, storage encryption settings per sensitive store	Coverage of inventoried data with approved encryption
3.12	Network or account diagrams showing sensitive zones	Share of sensitive-data assets separated from less sensitive networks
3.13, 3.14	DLP deployment and policy reports; audit log configuration per store	Coverage of sensitive-data assets with the tool installed and correctly configured

The Assessment Specification has some known rough edges in this control (for example, inconsistent wording between "end-user devices" and "mobile devices" in 3.6), so agree interpretations with your assessor before fieldwork.

Detection and metrics

What to monitor: bulk reads or exports from sensitive stores, new sharing links to external domains, access by identities not on the owner's list, disabled encryption or audit settings, DLP overrides by the same user or service.
Relevant attacker behaviour: T1005 Data from Local System, T1530 Data from Cloud Storage, T1052 Exfiltration Over Physical Medium and T1567 Exfiltration Over Web Service.

Metrics:

Percentage of sensitive data inventory items with owner, sensitivity and storing asset recorded.
Percentage of end-user devices encrypted with recovery keys escrowed (target 100 per cent of devices holding sensitive data).
Number of sensitive stores accessible to broad groups or over-scoped service accounts, trending to zero.
Volume of data held beyond maximum retention, by system.
Percentage of sensitive stores with access logging forwarded to the SIEM.
DLP true positive rate and override rate per policy after tuning.

Mapping to other frameworks

Control 3 area	NIST CSF 2.0	NIST SP 800-53 Rev. 5
Process, classification (3.1, 3.7)	ID.AM-08	RA-2 Security Categorization, SI-12 Information Management and Retention
Data inventory, flows (3.2, 3.8)	ID.AM-07, ID.AM-03	PM-5(1) Inventory of Personally Identifiable Information, AC-4 Information Flow Enforcement
Access lists (3.3)	PR.AA-05	AC-3 Access Enforcement
Retention and disposal (3.4, 3.5)	ID.AM-08	SI-12, MP-6 Media Sanitization
Encryption at rest and media (3.6, 3.9, 3.11)	PR.DS-01	SC-28 and SC-28(1) Cryptographic Protection, MP-5 Media Transport, SC-12 key management
Encryption in transit (3.10)	PR.DS-02	SC-8 and SC-8(1) Cryptographic Protection
DLP and access logging (3.13, 3.14)	PR.DS-01, PR.DS-02, DE.CM-09	AC-4, AU-2 Event Logging

In ISO/IEC 27001:2022 Annex A the closest controls are 5.12 (classification of information), 5.13 (labelling of information), 5.14 (information transfer), 7.10 (storage media), 8.3 (information access restriction), 8.10 (information deletion), 8.12 (data leakage prevention) and 8.24 (use of cryptography). The CIS Controls Navigator also maps Control 3 to privacy and sector frameworks such as HIPAA, PCI DSS v4.0, NIS2 and DORA. Where personal data is involved, the Control 3 process should feed your DPIA Guide work.

Common pitfalls

Buying DLP before the inventory: 3.13 depends on 3.2. A DLP tool with no agreed definition of sensitive data generates noise and is switched to monitor-only for good.
Retention without a maximum: keeping everything is the default in most platforms, and old data is what extortion groups take. See the Data Extortion Without Encryption Guide.
Encryption as a tick box: storage-layer encryption passes 3.11 but does nothing against a valid credential querying the data; keys held next to the data, as the GoTo case shows, undo it entirely.
Human-only access reviews: 3.3 reviews that ignore service accounts and integrations miss the identities with the widest reach.
Undocumented provider flows: data sent to SaaS and analytics providers through API integrations rarely appears on data flow diagrams, so it is outside DLP and retention.
Unescrowed recovery keys: device encryption enforced without central recovery key escrow leads to data loss and pressure to disable encryption.

Practitioner checklist

Approve a data management process that covers sensitivity, owner, handling, retention limits and disposal, with an annual review.
Build a sensitive data inventory mapped to storing assets from Control 1, and include secrets and credentials.
Remove broad groups from sensitive stores and scope service accounts to the data they need.
Set minimum and maximum retention per data type and schedule deletion.
Enforce device encryption with escrowed recovery keys and report coverage monthly.
Require TLS 1.2 or higher for sensitive data in transit and encrypt sensitive stores at rest with keys held separately.
Document data flows to service providers, including the identity each flow uses.
Run DLP in simulation before enforcement and roll out by pilot group.
Enable access logging on every sensitive store and forward it to the SIEM.

CIS Control 3 Data Protection Guide: Safeguards, Implementation Groups and Evidence