Security Questionnaire Mapper
Data protection and encryption ยท question family

Encryption at rest: the clause the question tests

Whether stored data is encrypted, with what, and who controls the keys.

How the customer usually asks it

example

"Do you encrypt customer data at rest? Specify the algorithm."

Read this question

Anchor clauses

9 frameworks
FrameworkAnchor clause
ISO/IEC 27001:20228.24 Use of cryptography
SOC 2 (Trust Services Criteria)CC6.1 Implements logical access security software, infrastructure and architectures over protected information assets
SIG (Shared Assessments)domain D Asset and Information Management
CSA Cloud Controls Matrix v4.0.1CEK-03 Data Encryption
NIST Cybersecurity Framework 2.0PR.DS-01 The confidentiality, integrity, and availability of data-at-rest are protected
NIST SP 800-53 Rev 5SC-28 Protection of information at rest
PCI DSS v4.0.13.5.1 PAN rendered unreadable wherever stored
HIPAA Security Rule (45 CFR 164)164.312(a)(2)(iv) Encryption and Decryption (Addressable)
GDPR, Regulation (EU) 2016/679Art. 32 Security of processing

Every framework that anchors this family is listed here; a register shows the ones ticked for the customer.

Evidence expected

The cryptography standard naming the algorithms and key lengths, where stored data is encrypted, and who holds and rotates the keys.

The clauses, with what an assessor asks for

ISO 27001 8.24 Use of cryptography

Define and implement rules for effective use of cryptography and key management.

Evidence an assessor expects: Encryption policy; Key management procedures; Algorithm inventory; Key usage records
Where answers usually fall short: Missing documented key lifecycle; Use of outdated or weak algorithms
Source: ISO/IEC 27001:2022
SOC 2 CC6.1 Implements logical access security software, infrastructure and architectures over protected information assets

Named, not quoted: the criteria text is not held in full here.

Evidence an assessor expects: Inventory of information assets with classification and owner; Access control software configuration and the rule sets that enforce it; Joiner, mover and leaver records showing credential issue and removal for people, infrastructure and software; Network segmentation design with firewall or ACL rule review evidence; Register of points of access used by outside entities and the data that flows through each
Where answers usually fall short: Physical access evidence offered against a criterion that is logical only, which belongs at CC6.4; Asset inventory incomplete, so unmanaged systems sit outside the access control rule sets
Source: SOC 2 (Trust Services Criteria)
SIG domain D Asset and Information Management

What it asks for, in one line (the standard's own text is not quoted here):

Maintain a complete and current inventory of information assets, data classification, ownership, and handling requirements throughout the asset lifecycle.

Evidence an assessor expects: Asset inventory with owner and classification; Data classification policy and labeling guide; Onboarding and decommissioning records; Data flow diagrams
Where answers usually fall short: Inventory missing cloud assets; Classification labels inconsistent across systems
Source: SIG (Shared Assessments)
CSA CCM CEK-03 Data Encryption

What it asks for, in one line (the standard's own text is not quoted here):

Apply cryptographic protection to stored data and to data moving across networks, using libraries that hold certification against an approved standard.

Evidence an assessor expects: Configuration evidence showing encryption enabled at rest and in transit per system; The certification of the cryptographic libraries or modules in use, such as a validation certificate; Inventory of data stores and transport paths with their encryption status; Exceptions where encryption is not applied and the risk acceptance behind them
Where answers usually fall short: Encryption at rest claimed from a provider default without verification per data store; Uncertified or self-built cryptographic implementations in use
Source: CSA Cloud Controls Matrix v4.0.1
NIST CSF PR.DS-01 The confidentiality, integrity, and availability of data-at-rest are protected

The confidentiality, integrity, and availability of data-at-rest are protected.

Evidence an assessor expects: Data at rest encryption inventory by store type; Key management standards and rotation evidence; Storage configuration baselines with attestation; Sensitive data discovery findings remediated; Audit findings on data at rest protection
Where answers usually fall short: Encryption inventory misses backup media; Key rotation manual and missed
Source: NIST Cybersecurity Framework 2.0
SP 800-53 SC-28 Protection of information at rest

Requires the confidentiality or integrity, as the organization determines, of organization-defined information at rest to be protected, so that stored information is safeguarded independently of the access controls in front of it.

Evidence an assessor expects: Definition of the information at rest in scope and whether confidentiality, integrity or both are protected; Encryption configuration for storage, databases and backups; Key management arrangements supporting the protection; Verification evidence such as storage configuration reports
Where answers usually fall short: Primary storage encrypted while backups, exports and logs are not; Encryption keys held beside the data they protect
Source: NIST SP 800-53 Rev 5
PCI DSS 3.5.1 PAN rendered unreadable wherever stored

What it asks for, in one line (the standard's own text is not quoted here):

PAN is rendered unreadable anywhere it is stored using one of: one-way hashes, truncation, index tokens with secure pads, or strong cryptography with key management.

Evidence an assessor expects: Inventory of PAN storage locations with method per location; Encryption configuration; Tokenisation vendor SAQ; Hash algorithm and salt documentation; Sample database extracts showing rendered output
Where answers usually fall short: Cleartext PAN in backups; Reversible hash without keyed function
Source: PCI DSS v4.0.1
HIPAA 164.312(a)(2)(iv) Encryption and Decryption (Addressable)

Implement a mechanism to encrypt and decrypt ePHI. NIST recommends FIPS 140-validated cryptography, encryption at rest for all ePHI stores, and key management aligned to SP 800-57.

Evidence an assessor expects: Encryption standard; FIPS 140 validation references; Key management procedures; Database, file, and endpoint encryption coverage report
Where answers usually fall short: Legacy databases unencrypted; Endpoint encryption not enforced
Source: HIPAA Security Rule (45 CFR 164)
GDPR Art. 32 Security of processing

Implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, taking into account the state of the art, the costs of implementation, the nature, scope, context and purposes of processing, and the risk of varying likelihood and severity for the rights and freedoms of natural persons. Those measures include, as appropriate, the pseudonymisation and encryption of personal data, the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services, the ability to restore the availability of and access to personal data in a timely manner after a physical or technical incident, and a process for regularly testing, assessing and evaluating the effectiveness of the technical and organisational measures. Assess the appropriate level of security against the risks presented by the processing, in particular accidental or unlawful destruction, loss, alteration, unauthorised disclosure of or access to personal data transmitted, stored or otherwise processed. Take steps to ensure that any person acting under the controller's or processor's authority who has access to personal data processes it only on instructions.

Evidence an assessor expects: The security risk assessment per processing activity, expressed as risk to the rights and freedoms of individuals rather than only as risk to the organisation; Encryption and pseudonymisation coverage at rest, in transit and in backup, with the decision recorded where either was judged not appropriate; Restoration testing results showing personal data was actually recovered inside the intended timeframe, with the date and outcome; The regular testing programme Article 32(1)(d) requires: penetration tests, vulnerability scanning and control effectiveness reviews, with findings closed out; Evidence the measures were reassessed after material change in processing, technology or threat
Where answers usually fall short: Risk assessed as impact to the business, so processing that is low risk to the organisation and high risk to individuals attracts weak measures; Backups taken and never restore tested, so the ability to restore in a timely manner is assumed rather than demonstrated
Source: GDPR, Regulation (EU) 2016/679

Other families in data protection and encryption