Data-at-rest protection — encryption, access, processor controls
Primary statement
Data at rest is protected through: (1) encryption at rest using FIPS 140-2 / industry-standard algorithms; (2) access restriction per classification and least-privilege (ISO A.8.3); (3) privileged access management for data stores (A.8.2); (4) for personal data — DPDPA Section 8(2) processor agreements flowing equivalent protection; (5) integrity protection (NIST PR.DS-01) ensuring data is not tampered with; (6) for incident data — preservation of integrity and provenance (NIST RS.AN-07).
Audit-fatigue payoff
A unified data-at-rest programme — encryption inventory + access matrix + PAM for data stores + processor agreements + integrity controls — satisfies data-at-rest requirements across all 12 contributing frameworks. Sample 3 data stores → verify encryption configuration + access matrix + integrity protection = answer to all 12.
Strictness matrix
Scope
Scope: confidentiality, integrity AND availability of data-at-rest. Three properties (not just confidentiality). Encryption protects confidentiality; integrity controls protect against tampering; availability addresses backup and recovery (linked to cl-backup).
Ceiling source: nist_csf:PR.DS-01
Rationale: NIST CSF PR.DS-01 specifies the three CIA properties explicitly. Other frameworks address subsets (encryption-only typically). Three-property scope is the audit-defensible specification.
Threshold
Threshold for processor-held data: a Data Fiduciary engaging a Data Processor shall do so only under a valid contract; Section 8(2) holds the Fiduciary responsible regardless of processor location. The contractual threshold extends data-at-rest obligations to processors.
Ceiling source: dpdpa:DPDP.29
Rationale: DPDPA DPDP.29 + Section 8(2) sets the strictest threshold for processor-held personal data — fiduciary responsibility regardless of processor location. This extends the data-at-rest control scope beyond the controller's direct infrastructure.
Method
Method: (1) encryption at rest (FIPS 140-2 / equivalent); (2) access restriction per topic-specific access control policy; (3) privileged access via PAM (A.8.2) with session recording for high-privilege; (4) classification-driven differential controls; (5) for personal data — processor agreements flowing equivalent protection (DPDPA Section 8(2) + Rule 6(h)); (6) integrity verification (NIST PR.DS-01); (7) for incident-related data — provenance preservation (NIST RS.AN-07).
Ceiling source: iso27001:A.8.3
Rationale: ISO 27001 A.8.3 combined with A.8.2 privileged access + DPDPA Section 8(2) processor flow-down provides the most prescriptive method. The processor flow-down element is uniquely strict.
Frequency
Encryption configuration review: annual + on material change. Access matrix review: quarterly (per cl-access-rights cadence). Key rotation per the documented key lifecycle (typical: annual for signing keys, quarterly for encryption keys). Processor agreement review: annual.
Ceiling source: iso27001:A.8.5
Rationale: Annual encryption review with quarterly access review is the consistent cadence across frameworks. Quarterly access review is the strictest tier.
Evidence
Required evidence: (1) encryption-at-rest configuration per data store with algorithm + key length + key custody; (2) access matrix per data store; (3) PAM session recordings for privileged data access; (4) classification-controls mapping; (5) processor agreements (sample) showing DPDPA-compliant flow-down; (6) integrity verification evidence (hash checks, signed audit logs); (7) for incident data — provenance/chain-of-custody records.
Ceiling source: nist_csf:PR.DS-01
Rationale: NIST CSF PR.DS-01 evidence covers the three CIA properties. Combined with DPDPA processor evidence, this is the audit-defensible package.
Auditor test pattern
Step 1: Sample 3 data stores; verify encryption-at-rest configuration. Step 2: Inspect access matrix; verify least-privilege. Step 3: For one data store, verify PAM session recording for a recent privileged access event. Step 4: For processor-held personal data, sample one processor agreement; verify DPDPA Section 8(2) flow-down. Step 5: Verify integrity controls (hash checks, signed logs) for one critical data store. Step 6: For incident data preservation, sample one historical incident and verify chain-of-custody.
Common findings
Common 2024–26 findings: (1) Application-layer encryption claimed but transport-only; database stores plaintext; (2) Backups encrypted but restoration produces plaintext copies in non-production environments; (3) Access matrix theoretical — actual permissions broader; (4) Processor agreements pre-date DPDPA, use generic "reasonable security" not Section 8(2) flow-down; (5) Integrity verification absent — tampered data not detected; (6) Incident data preserved but chain-of-custody documentation absent.