Data Retention and Disposal Policy

1. Purpose and Scope

This Data Retention and Disposal Policy (“Policy”) establishes how DataChimp Labs identifies, retains, and securely disposes of data across its services, systems, and backups. The Policy applies to:

  • All data processed, stored, or transmitted by DataChimp Labs, including customer data, personal information, protected health information (PHI), financial account data, transaction records, telemetry, logs, and backups.
  • All DataChimp Labs personnel, contractors, and third parties that access DataChimp Labs systems or data.
  • All environments where DataChimp Labs data is stored, including production cloud accounts, backups, disaster-recovery replicas, developer sandboxes, and archived object storage.

This Policy operationalizes the retention commitments made in the DataChimp Labs Privacy Policy §5 and complements the Information Security Policy, Access Control Policy, Encryption at Rest Policy, and Encryption in Transit Policy.

2. Vendor Questionnaire Response — Documented and Enforced

Q. Does your organization have a defined and enforced data deletion and retention policy that is in compliance with applicable data privacy laws, and is this policy reviewed periodically? Please provide your Data Retention and Disposal Policy.

A. Yes. DataChimp Labs maintains this documented Data Retention and Disposal Policy. Retention periods are enforced technically through cloud-native lifecycle rules and application-level deletion routines, reviewed annually by the Security Lead, and aligned with GDPR, UK GDPR, CCPA/CPRA, HIPAA, and applicable financial-services retention laws.

Evidence:

  • Defined. Retention periods and disposal methods for every data category we process are enumerated in §4 (Retention Schedule) and §6 (Disposal Standards) of this Policy.
  • Enforced. Retention is enforced by AWS S3 Lifecycle rules, DynamoDB Time-to-Live (TTL) attributes, RDS/Aurora automated snapshot windows, CloudWatch Logs retention settings, and application-level scheduled deletion jobs. Enforcement is codified in infrastructure-as-code and reviewed on every change.
  • Compliance with privacy laws. Retention periods are set to satisfy the shortest of statutory maximums and the longest of statutory minimums for each applicable regime (see §3, Regulatory Alignment).
  • Reviewed periodically. The Policy is reviewed at least annually by the Security Lead. See §9 (Policy Review Cadence).
  • Public commitment. This Policy is published at https://trust.datachimplabs.com/policies/data-retention-and-disposal-policy.

Detailed sections:

  • Retention Schedule — see §4.
  • Data Subject Deletion Requests — see §5.
  • Disposal Standards — see §6.
  • Backups and Replicas — see §7.
  • Legal Holds — see §8.
  • Policy Review Cadence — see §9.

3. Regulatory Alignment

This Policy is designed to satisfy retention and disposal requirements under, at minimum, the following regimes and frameworks:

  • GDPR (EU) and UK GDPR — storage limitation principle (Article 5(1)(e)) and right to erasure (Article 17).
  • CCPA / CPRA (California) — right to delete (Cal. Civ. Code §1798.105) and disclosure of retention periods (Cal. Civ. Code §1798.100(a)(3)).
  • HIPAA Security Rule — retention of security-relevant documentation for a minimum of six (6) years and secure disposal of ePHI (45 CFR §164.316(b)(2) and §164.310(d)).
  • SOC 2 Trust Services Criteria — Common Criteria CC6.5 (logical and physical protections over disposal) and Privacy criteria P4.
  • Financial-services retention — anti-money-laundering (AML), tax, and audit statutes where applicable (typically five (5) to seven (7) years for transaction records).
  • ITAR / EAR — segregation and controlled destruction of export-controlled technical data.

Where regimes conflict, DataChimp Labs applies the more protective standard for the data subject and the longer retention for regulator-facing evidence.

4. Retention Schedule

Retention is measured from the later of (a) the date the data was collected and (b) the last date the data was materially updated. Where a category is subject to a statutory minimum, we retain for that minimum; otherwise we retain only for the operational period listed.

Data Category Retention Period Enforcement Mechanism
Account and profile information Life of the account, plus 90 days after account closure for legal and audit purposes Application-level scheduled deletion job
Authentication events (login, MFA, password change) 13 months CloudWatch Logs retention setting
Financial account connections (Plaid tokens, account metadata) While the connection is active; deleted or de-identified within 30 days after disconnection, subject to statutory retention (AML, tax, audit) Application-level scheduled deletion job + DynamoDB TTL where applicable
Transaction history Per feature enabled and applicable statutory minimum (typically 5–7 years for financial-services transactions) S3 Lifecycle rules to Glacier, then expiration
Usage and analytics data (product telemetry) 13 months in identifiable form; aggregated or de-identified thereafter Scheduled aggregation job + DynamoDB TTL
Application and infrastructure logs 90 days hot / 1 year cold, unless required longer for security investigations CloudWatch Logs retention setting + S3 Lifecycle rules
Security event logs (authentication, access, admin actions) 1 year hot / 6 years cold (HIPAA §164.316(b)(2) minimum) CloudWatch Logs → S3 Lifecycle to Glacier
Support and customer communications Life of the account plus 2 years Ticketing system retention configuration
Marketing and outreach data Until unsubscribe or 2 years of inactivity, whichever is sooner CRM automated purge job
Employee and contractor records Statutory minimum for the applicable jurisdiction (typically 4–7 years post-termination) HRIS retention configuration
Vendor and contract records Contract term plus 7 years Document management system retention
Backups (production databases and object storage) Rolling 35-day point-in-time recovery window; older snapshots expire per lifecycle rule RDS/Aurora automated backup window + S3 Lifecycle rules
Disaster-recovery replicas Kept in lockstep with production; subject to the same deletion when source is deleted Cross-region replication configuration
Developer sandbox and non-production data 30 days for data derived from production; production PII/PHI is never permitted in non-production environments Sandbox reset automation + policy enforcement

Retention periods are reviewed annually and updated as new products, data categories, or regulatory obligations emerge.

5. Data Subject Deletion Requests

DataChimp Labs honors data subject deletion requests as required by applicable law. The end-to-end flow is:

  1. Intake. Requests are submitted to privacy@datachimplabs.com or through in-product controls where offered. Identity is verified using a risk-proportionate method that avoids unnecessary collection of additional personal information.
  2. Scope confirmation. The Security Lead confirms the data categories in scope and identifies any statutory retention obligations that prevent deletion (see §8, Legal Holds).
  3. Execution on active systems. Data is deleted or irreversibly de-identified within the timeframe required by applicable law (typically 30–45 days) using the disposal methods in §6.
  4. Backups. Requests are applied to active systems immediately. Point-in-time backups are not selectively edited; the deletion is propagated to backups on the next rotation cycle (typically within 35 days), and any restore of an older backup triggers a re-application of pending deletions before the restore is used.
  5. Confirmation. A response confirming action taken (or explaining a lawful basis for retention) is sent to the requester.

Records of deletion requests and their disposition are themselves retained for the period required to demonstrate compliance (typically 3 years).

6. Disposal Standards

When retention expires or a deletion request is executed, data is disposed of using methods that are appropriate to the data classification and the storage medium:

  • Cloud storage (S3, EBS, EFS, RDS, DynamoDB). Logical deletion via API is followed by AWS-managed cryptographic erasure at the storage layer. Encryption keys used for at-rest encryption of deleted data may additionally be scheduled for deletion via AWS KMS ScheduleKeyDeletion where appropriate.
  • Application-layer records. Rows are deleted via parameterized SQL or the equivalent SDK call, followed by verification that the record no longer exists in the primary table. Soft-delete tombstones are purged per §4.
  • Backups and snapshots. Expiration via the retention window in §4; older snapshots are removed automatically by the cloud provider.
  • Removable media and endpoints. All corporate endpoints use full-disk encryption (per the Encryption at Rest Policy). At end of life, endpoints are cryptographically erased and, where physically practical, the storage device is destroyed following NIST SP 800-88 Rev. 1 guidance (“Purge” or “Destroy” as appropriate to the media).
  • Physical documents. Sensitive physical documents are shredded via a cross-cut shredder or a certified shredding service.

7. Backups and Replicas

  • Backups are encrypted at rest using AWS KMS-managed keys (see the Encryption at Rest Policy).
  • Backup retention windows are set to the shortest window that satisfies our recovery-point objective (RPO) and any statutory minimums.
  • Cross-region replicas exist for disaster recovery and are subject to the same retention and deletion propagation as the primary region.
  • Restores from backup that predate a deletion request trigger a re-application of pending deletions before the restored data is placed back into production use.

When DataChimp Labs receives, or reasonably anticipates receiving, a lawful request that requires the preservation of data (e.g., litigation hold, regulator inquiry, law-enforcement subpoena, or a specific statutory retention obligation), the Security Lead in coordination with Legal will:

  1. Identify the data in scope of the hold.
  2. Suspend automatic deletion for the affected data categories.
  3. Document the hold, its scope, and its expected duration in the compliance record.
  4. Release the hold and resume normal disposal once the obligation is satisfied.

Legal holds take precedence over the retention schedule in §4 and over data subject deletion requests where a lawful basis for retention exists.

9. Policy Review Cadence

  • This Policy is reviewed at least annually by the Security Lead.
  • The retention schedule in §4 is reviewed at the same cadence and after any material change to the product surface, data model, third-party processor set, or applicable regulatory landscape.
  • Material changes are communicated to affected customers where required by contract or by law, and the effective date on this Policy is updated accordingly.

10. Enforcement

Failure to adhere to this Policy — including bypassing retention enforcement, exporting production data outside sanctioned environments, or destroying data subject to a legal hold — may result in disciplinary action up to and including termination, and, where applicable, civil or criminal liability.

11. Contacts

12. Approval and Version History

Version Date Author Change
1.0 2026-09-02 DataChimp Labs — Security Initial published version.

Copyright © 2026 DataChimp Labs. Public Trust Center.