All Docs
FeaturesCalmony Sanctions MonitorUpdated March 12, 2026

SOC2-10: Data Retention — Policy vs. Enforcement Gap

SOC2-10: Data Retention — Policy vs. Enforcement Gap

Status: Open compliance finding — automated enforcement not yet implemented.

Overview

As part of our SOC 2 compliance programme, we have documented data retention periods for the three primary data categories processed by the platform. These periods are published in the privacy policy (src/app/privacy/page.tsx) and visible in the settings page.

However, as of v0.1.150, these periods are not programmatically enforced. No scheduled jobs, TTL policies, or automated anonymisation routines exist. Data is only removed through manual intervention.

This document describes the current state, the documented retention rules, and the planned remediation.

Documented Retention Periods

Data CategoryRetention PeriodBasis
Screening records6 yearsUK regulatory compliance requirement
Billing records7 yearsHMRC / financial record-keeping requirement
Usage analytics2 yearsInternal operational policy

Current State

  • Retention periods are written into the privacy policy and surfaced in the product settings UI.
  • No cron jobs, scheduled workflows, or database TTL policies enforce these periods automatically.
  • All deletion is manual only — an administrator must identify and remove or anonymise overdue records by hand.
  • This constitutes an open gap against SOC 2 Control SOC2-10.

Planned Remediation

The following changes are recommended to close the SOC2-10 finding:

1. Scheduled Workflow

Create .github/workflows/data-retention.yml as a monthly scheduled workflow:

name: Data Retention Enforcement

on:
  schedule:
    - cron: '0 2 1 * *'  # 02:00 UTC on the 1st of each month
  workflow_dispatch:     # allow manual trigger

jobs:
  enforce-retention:
    runs-on: ubuntu-latest
    steps:
      - name: Trigger retention purge
        run: |
          curl -X POST https://<your-domain>/api/admin/retention \
            -H "Authorization: Bearer ${{ secrets.RETENTION_API_SECRET }}" \
            -H "Content-Type: application/json"

2. Retention API Endpoint

Implement POST /api/admin/retention to:

  • Query each data store for records that have exceeded their retention window.
  • Anonymise records rather than hard-deleting where compliance metadata must be preserved. Anonymisation should nullify all PII fields (e.g. names, addresses, identifiers) while retaining non-personal metadata (e.g. screening outcome, record timestamp, case reference).
  • Hard-delete records where no compliance metadata is required (e.g. raw usage analytics beyond 2 years).
  • Return a summary of records processed, anonymised, and deleted for audit logging.

3. Anonymisation Logic

For screening and billing records that must be retained in anonymised form:

PII fields to nullify:   full_name, date_of_birth, address, national_id, email
Metadata to retain:      record_id, created_at, screening_outcome, case_reference, billing_period

Risk Until Remediated

Until automated enforcement is in place:

  • Records may be retained beyond their documented periods, creating regulatory and reputational risk.
  • The SOC 2 audit finding for Control SOC2-10 remains open.
  • Compliance teams should perform manual reviews on a monthly cadence as an interim control.

Related

  • Privacy Policy — src/app/privacy/page.tsx
  • SOC 2 Control: SOC2-10
  • Affected data stores: screening records, billing records, usage analytics