Data Retention Policy

DanceLedger Data Retention Policy

Effective Date: 2026-04-18 Version: 1.0 Owner: Abrazo Software LLC Contact: privacy@abrazo.dev

1. Purpose

This Data Retention Policy ("Policy") defines how long DanceLedger, operated by Abrazo Software LLC, retains each category of user and operational data. Retention periods are set to be the minimum necessary to deliver the service, satisfy financial and security record-keeping obligations, and preserve forensic evidence of system integrity, consistent with the principle of storage limitation in GDPR Article 5(1)(e).

2. Retention Periods

The table below lists each data category, its storage system, its retention period, and the justification for retaining it for that duration.

Data TypeStorageRetentionJustification
User account (profile, credentials)MongoDBUntil deletion request + 30 daysService delivery
Trip data (trips, plans, members)MongoDBUntil deletion request + 30 daysService delivery
Expense records (amounts, splits, notes)PostgreSQLUntil deletion request + 30 daysFinancial record keeping
Receipt imagesS3Until deletion request + 30 daysFinancial record keeping
Plaid access tokensPostgreSQLUntil user removes bank link or deletionBank aggregation service
Plaid transactionsPostgreSQLUntil deletion request + 30 daysTransaction import feature
Stripe customer recordsPostgreSQLUntil deletion request + 30 daysSubscription management
Subscription records (Stripe, Apple, Google)PostgreSQLUntil deletion request + 30 daysEntitlement tracking
Chat conversations (AI trip planning)MongoDBUntil deletion request + 30 daysAI trip planning history
Session tokensMongoDB2 hours (auto-expiry)Authentication
Search cache (festival, flight, hotel queries)MongoDBTTL index (24 hours)Performance optimization
Audit logs (admin actions, security events)MongoDB1 yearSecurity compliance
Webhook events (Stripe, RevenueCat)PostgreSQL90 daysIdempotency and forensics

3. Soft Delete Period

When a user requests account deletion or an administrator disables an account, the associated data enters a 30-day soft-delete grace period. During this window:

  • The user cannot sign in and all active sessions are invalidated immediately.
  • User data is no longer returned through the API or visible to the user or other users.
  • Data remains recoverable by Company staff only in response to a signed, authenticated user request to reverse the deletion.

The grace period balances the user's right to erasure against the common case of mistaken or impulsive deletion requests, and against regulatory obligations to retain records that may be in active dispute.

4. Hard Purge Process

An automated cron job runs nightly at 03:00 UTC and performs irreversible hard-purge on all accounts whose soft-delete timestamp is more than 30 days in the past. The purge covers, in a single transaction boundary where supported:

  • MongoDB documents: user profile, owned trips, owned groups, chat conversations, owned festivals, tracking configurations, and user-festival bookmarks.
  • PostgreSQL records: expenses authored by the user, expense splits referencing the user, Stripe customer record, Plaid items and transactions, and subscription rows.
  • S3 objects: all receipt images under the user's prefix.
  • External services: Stripe subscription cancellation, RevenueCat subscriber deletion via REST API, and Plaid item removal via Plaid API.

The purge job emits a structured log summary (DATA_PURGE_SUMMARY) with counts per data category, consumed by monitoring dashboards. Failures are alerted via PagerDuty and re-attempted on the next nightly run.

5. GDPR Storage Limitation — Article 5(1)(e)

Data is kept no longer than is necessary for the purposes for which it is processed. The combination of scoped retention periods, TTL indexes on transient collections, a defined soft-delete window, and automated hard-purge after 30 days gives effect to the storage limitation principle. Where a data category has a fixed calendar retention (audit logs, webhook events), the Company reviews that retention annually and reduces it where operational experience permits.

6. Review Schedule

This Policy is reviewed at least annually and whenever a new data category is introduced, a storage system is added or retired, or applicable regulation changes. Material changes are versioned at the top of this document.