Encryption at Rest Policy

1. Purpose & Scope

This Encryption at Rest Policy (“Policy”) defines the requirements DataChimp Labs enforces to protect the confidentiality and integrity of data while it is stored on persistent media, including primary data stores, caches, message queues, backups, snapshots, logs, and any other durable copy of DataChimp Labs or customer data.

The Policy applies to:

All persistent data stores operated by DataChimp Labs in AWS or any other cloud environment, including relational and non-relational databases, object storage, block storage, secrets stores, caches, and message queues.
All backups, snapshots, replicas, and disaster-recovery copies of the above.
All log stores, observability stores, and analytical warehouses that hold DataChimp Labs or customer data.
Any workforce endpoint that may hold DataChimp Labs or customer data.

This Policy supplements the Information Security Policy and works in conjunction with the Encryption in Transit Policy.

2. Policy Statement

All persistent DataChimp Labs and customer data is encrypted at rest, without exception. This includes:

All consumer data retrieved from the Plaid API — account, item, balance, identity, transaction, liability, investment, income, and any other Plaid product surface that DataChimp Labs receives on behalf of a consumer or a customer of DataChimp Labs. Every store that holds Plaid-derived data is encrypted at rest with a KMS-managed key, as is every backup, snapshot, and replica of that store.
All other customer data, PII, PHI, credentials, secrets, and internal business data classified Confidential or Restricted.

Unencrypted persistent storage of DataChimp Labs or customer data is prohibited. Snapshot, backup, and replication features that would produce an unencrypted copy are disabled at the platform level.

3. Governance & Ownership

Role	Responsibility
Security Lead	Owns this Policy; owns the KMS key hierarchy; owns key access review and rotation policy; approves exceptions.
Engineering Leadership	Implements encryption at rest in application and infrastructure code; owns envelope encryption patterns in code.
Cloud Platform Owner	Enforces account-level defaults (default EBS encryption, S3 default encryption, RDS storage encryption); owns KMS provisioning.
Compliance Lead	Confirms encryption controls satisfy HIPAA Security Rule, SOC 2, and other applicable frameworks.
All Personnel	Do not create unencrypted stores; do not export data to unencrypted media; report suspected unauthorized access to key material.

4. Cryptographic Baseline

Symmetric algorithm. AES-256 (or the cloud-provider equivalent FIPS-validated implementation) is the minimum for at-rest data.
Asymmetric algorithm. Where asymmetric keys are used (signing, envelope key wrap), RSA-2048 or stronger, or elliptic curves P-256 / P-384, are used.
Hashing. SHA-256 or stronger for integrity and derivation. SHA-1 and MD5 are not used for security-relevant operations.
FIPS 140. Key material for regulated workloads is generated, stored, and used within FIPS 140-validated modules provided by the cloud provider (AWS KMS) or an HSM.

5. Key Management with AWS KMS

DataChimp Labs uses AWS Key Management Service (KMS) as the primary key management system.

5.1 Key Hierarchy

Customer master keys (CMKs) are created per-workload, per-environment, and per-data-classification tier. A shared “one KMS key for everything” is prohibited.
AWS-managed keys are acceptable only where a service does not support customer-managed keys, and only for data classified Internal or below. Data classified Confidential or Restricted uses customer-managed keys.
Envelope encryption. Where the volume of data would make direct KMS encryption inefficient, applications use envelope encryption: KMS generates and wraps a data encryption key (DEK), the application uses the DEK to encrypt payloads locally, and only the wrapped DEK is stored alongside the ciphertext. The plaintext DEK is never persisted.

5.2 Key Policies & Access

Separation of duties on key access. Key policies and IAM grants are scoped so that:
- Personnel who can administer a key cannot decrypt data with it in routine operation.
- Personnel who can decrypt data with a key in routine operation cannot alter the key policy or delete the key.
- Workload service roles receive only the operations they need (typically kms:Encrypt, kms:Decrypt, kms:GenerateDataKey, kms:ReEncrypt) and are scoped by encryption context.
Encryption context. Applications set an encryption context on KMS operations that pins the ciphertext to its business identity (for example, {tenant: <id>, purpose: <name>}). Decryption enforces matching context to prevent cross-tenant confusion.
Grants and cross-account access. Grants and cross-account key policies are reviewed on every change and enumerated in the quarterly access review.
Key aliases. Human-friendly aliases are used to refer to keys in configuration; direct KMS key ID references in application configuration are prohibited; enforcement is via IaC lint checks in CI, and any pull request introducing a hardcoded key ID is blocked at review.

5.3 Key Rotation

Automatic annual rotation is enabled on all AWS KMS customer-managed keys where AWS supports automatic rotation.
On-demand rotation. Keys can be rotated on demand in response to suspected exposure of a data key, personnel changes, or contractual requirements. Rotation on suspected compromise is immediate.
Data key rotation. Envelope-encrypted workloads rotate DEKs on the cadence appropriate to their volume and risk (per-object DEKs for high churn, periodic DEKs for low churn), and older DEKs remain wrapped under rotated KMS versions so historical data remains decryptable without weakening the current baseline.
Retention of old key versions. AWS KMS retains backing key material for previous versions so that ciphertext produced under older key versions continues to decrypt; deletion of key material follows a scheduled deletion process with the mandatory waiting period.

5.4 Auditability

All KMS API calls are logged to CloudTrail and centralized in the immutable log store. Anomalous key usage (unexpected principals, unexpected regions, spikes in Decrypt calls) generates alerts.
Key inventories (keys, aliases, policies, grants, rotation status) are reviewed at least quarterly.

6. Data Store Encryption

Encryption at rest is enforced at the platform layer for every persistent store:

Amazon S3. All buckets are configured for server-side encryption with KMS-managed keys (SSE-KMS). Bucket policies deny unencrypted PUTs and deny bucket creation without default encryption. Public access is blocked at the account level.
Amazon RDS / Aurora. Storage encryption is enabled at cluster creation with a customer-managed KMS key. Automated backups, read replicas, and snapshots inherit the encryption. Turning encryption off for a database instance is not possible after creation, which the Policy relies on as a hard control.
Amazon DynamoDB. Tables use encryption at rest with customer-managed KMS keys where the workload processes Confidential or Restricted data; AWS-managed keys are acceptable only for Internal or Public tables. Global tables inherit encryption in every region.
Amazon EBS. Account-level default EBS encryption is enabled in every account and region. Unencrypted volumes cannot be launched; a policy at the account level blocks the launch of unencrypted volumes.
Amazon EFS / FSx / other file systems. Encryption at rest is enabled at creation with a KMS-managed key.
AWS Secrets Manager & SSM Parameter Store. All secrets are stored as SecureString / KMS-encrypted secrets; plaintext secrets in Parameter Store are prohibited.
Message queues, streams, caches. SQS, SNS, Kinesis, MSK, and ElastiCache queues, streams, and caches that hold customer data are configured for at-rest encryption with KMS-managed keys where the service supports it. Caches that hold sensitive material additionally set short TTLs.
Log stores & observability. CloudWatch Logs log groups holding customer data are configured with a KMS key. Third-party observability vendors that receive DataChimp Labs data must document their at-rest encryption and are engaged only under DPAs / BAAs.
Analytical warehouses / data lakes. Warehouses and lakes holding customer data (for example, Redshift, Athena over S3, EMR) encrypt at rest with KMS keys inherited from the underlying store.

7. Backups, Snapshots, and Replication

All backups are encrypted. Any backup, snapshot, or replica of a DataChimp Labs data store is encrypted at rest with a KMS-managed key. Unencrypted backups are not permitted at any point in the lifecycle.
Cross-region and cross-account copies are re-encrypted under the destination’s KMS key, and the source key remains inaccessible to destinations that do not need to decrypt.
Point-in-time recovery streams (for example, RDS PITR, DynamoDB PITR) are covered by the same KMS keys as the primary store.
Restore testing. Restore drills are performed periodically to confirm that encrypted backups can be recovered and that the destination environment has the necessary KMS grants.
Retention. Backup retention is set per the retention schedule and is not extended informally; expired backups are deleted with their DEKs, rendering them cryptographically unrecoverable.

8. Workforce Endpoints & Removable Media

Full-disk encryption is enforced on all workforce endpoints through the endpoint management platform. Devices that lose encryption posture are flagged and cannot access production.
Removable media. Use of removable media for DataChimp Labs or customer data is prohibited by default. Where a specific operational need requires it, media must be hardware-encrypted, inventoried, and wiped or destroyed at end of use.
Local caches. Applications that cache customer data locally on workforce devices are subject to the endpoint’s full-disk encryption and to short retention.

9. Application-Level Encryption

Restricted-tier data — including consumer financial data retrieved from the Plaid API and other Restricted-tier fields (for example, government identifiers, sensitive financial identifiers, security answers) — is protected with application-layer envelope encryption on top of the platform’s storage-layer encryption. This is a policy control applied to Restricted-tier workloads, not an optional pattern. Application-layer envelope encryption uses a dedicated KMS key per workload with an encryption context that binds the ciphertext to the tenant and record identity, so that even if a database snapshot were exfiltrated with its storage keys accessible, the Restricted fields would remain encrypted under a key that requires an authenticated KMS call to unwrap.

10. Data Deletion & Cryptographic Erasure

Deletion. When a customer requests deletion, or when retention expires, data is deleted from primary stores and backups per the retention schedule.
Cryptographic erasure. For high-volume tenant data where physical deletion across all replicas is impractical, DataChimp Labs uses cryptographic erasure: the DEKs associated with the tenant or record are destroyed under the KMS scheduled-deletion process, rendering the ciphertext unrecoverable.
Evidence. Deletion events (both physical and cryptographic) are logged and evidenced to the customer where contractually required.

11. Third-Party Data at Rest

Third parties that store DataChimp Labs or customer data on our behalf are contractually required to encrypt at rest and are reviewed for that control prior to engagement (SOC 2, ISO 27001, vendor questionnaire).
DPAs and BAAs include explicit at-rest encryption obligations.
Critical third parties are re-reviewed annually or on material change.

12. Exceptions

Any deviation from this Policy — for example, an emerging AWS service that does not yet support customer-managed KMS keys — requires a documented risk acceptance signed by the Security Lead, a compensating control (application-level encryption, tighter access, alternative store), and a defined expiration date. Exceptions are tracked in the risk register and reviewed at each Security Steering group meeting.

13. Verification & Monitoring

Cloud configuration scanning continuously checks for unencrypted stores, unencrypted snapshots, and unencrypted backups; findings are remediated per the SLAs in the Information Security Policy.
The KMS inventory (keys, aliases, policies, rotation status) is reconciled with the workload inventory quarterly.
Attempts to create unencrypted stores are blocked at the infrastructure-as-code layer and, additionally, at the account-policy layer where the platform supports it.

14. Review Cadence

This Policy is reviewed by the Security Lead at least annually and whenever there is a material change to the cryptographic ecosystem, the key management architecture, the platform, or the organization. The next scheduled review date is recorded in the front-matter of this document.

15. Enforcement

Compliance with this Policy is a condition of employment or engagement with DataChimp Labs. Attempted circumvention of encryption controls (for example, creating an unencrypted bucket for real data, exporting plaintext DEKs, or persisting secrets outside the approved secret stores) may result in disciplinary action up to and including termination, and, where appropriate, referral to law enforcement.

16. Approval & Version History

Version	Date	Author	Change
1.0	2026-09-01	DataChimp Labs — Security	Initial issue of the Encryption at Rest Policy.

Approved by: CTO, DataChimp Labs (signature on file with the Security Lead).

Contact. Security questions about this Policy should be directed to security@datachimplabs.com. Postal correspondence: DataChimp Labs, 4507 N 189th St, Elkhorn, NE 68022, USA.