Skip to content

Customer data deletion

How Changineers deletes customer data on contract termination and in response to data-subject requests.

This page is the procedure that backs Changineers’ Data Management Policy commitment to delete customer data within 60 days of contract termination, and to delete personal data on a verified data-subject request.

  • On contract termination. The CTO assigns an engineer to delete the customer’s tenant within 60 days. The 60-day window covers any reactivation or data-export request the customer might raise; once it passes, deletion proceeds.
  • On a verified data-subject request. Requests arrive at security@changineers.com.au. The engineer handling the request verifies the requester’s identity against the tenant’s records, scopes what needs to be deleted, and runs a bespoke deletion. Each partial-tenant deletion is handled case-by-case.

The customer’s tenant is provisioned by Terraform. To delete the tenant, remove the tenant’s Terraform configuration and apply. The apply tears down:

  • The tenant’s Cognito user pool, which deletes the users.
  • The tenant’s rows in Aurora Postgres (tenant-scoped via the Row-Level Security policies described on Architecture § Multi-tenancy).
  • The tenant’s rows in DynamoDB.
  • The tenant’s S3 prefixes in the recordings, uploads, content, and assets buckets.

Close the deletion ticket with the Terraform apply output attached. The closed ticket is the evidence record.

  • Backups. Backup copies expire under the retention windows in the Data Management Policy retention matrix at Appendix B; they are not restored to production except for disaster recovery, in which case the tenant deletion is re-applied.
  • Sentry and PostHog. Tenant-tagged events age out under each vendor’s configured retention, listed in the Data Management Policy retention matrix.

These periods are documented in the Data Management Policy retention matrix and disclosed to the customer when they ask.

  • The CTO.
  • An engineer the CTO assigns to the ticket.

The procedure goes through the normal change-management process: the Terraform change is a pull request, reviewed and approved, then deployed via the production release flow on Change management.