Data Retention Policy

This Data Retention Policy defines how long Persoon.ai Inc. retains each category of data processed by the ShipReady Metrics platform, and how data is deleted when its retention period ends. It applies to all data in the production platform: the Supabase Postgres database, Supabase storage, and authentication records.

Where this policy states a specific retention period, that period is implemented as an automated control in the platform — not merely a written intention. Periods that depend on organizational decisions not yet formalized are marked for owner confirmation.

• Data is retained only as long as needed to provide the service, meet customer commitments, or satisfy legal and audit obligations.
• Automated retention is preferred over manual cleanup: where a retention period exists, a scheduled job enforces it.
• Retention rules are visible: the audit page displays the effective audit-log retention policy to operators and auditors, from the same source of truth the prune job uses — the displayed policy and the enforced policy cannot diverge.
• Deletion is deliberate and audited: automated pruning records what was removed, and customer-initiated erasure is a confirmed, intentional action — never a side effect.

The table below is the consolidated schedule. Sections 4–7 explain the mechanisms behind each row.

The platform keeps an audit log of security-relevant and administrative actions. Retention is two-tiered: high-volume read-access events are kept for 90 days by default, while all other audit events are kept for 730 days (two years) by default. A scheduled retention job prunes rows past these horizons.

• The defaults are configurable by the platform operator via environment settings; setting a tier to zero disables pruning for that tier (indefinite retention).
• One code module is the single source of truth for the effective policy: it feeds both the prune job and the audit page that displays the policy to operators and auditors, so the published policy always matches what is enforced.

Compliance-evidence artifacts (JSON snapshots and binary files such as screenshots and vendor attestations) each carry a retention class that determines their lifecycle. Retention is enforced by a database prune function invoked from the same retention cron as the audit log; it is callable only by the service role.

• audit_cycle (the default): hard-deleted 400 days after the evidence was last re-confirmed by a collector — the clock runs from last confirmation, not first collection, so evidence that is still being re-verified never expires while current.
• point_in_time: the latest version of each artifact is always kept; superseded versions are removed 90 days after being superseded.
• permanent: never pruned automatically.
• Storage blobs are removed only when no surviving database row references them, so a deduplicated artifact still referenced by a live record is never orphaned or lost.
• Every prune run records per-organization pruned counts as an audit-log marker, so evidence deletion is itself evidenced.

Connector credentials exist only while a connector is connected. Disconnecting a connector deletes the connection record and, by cascade, its stored encrypted credential; the disconnection is written to the audit log. A failed deletion blocks the flow rather than silently leaving the credential active.

Metrics, scores, and findings previously derived from a connector remain available to the owning organization after disconnection (so history is not silently destroyed) and are removed with the account under Section 7. [Owner to confirm: whether an automated pruning horizon for stale connector-derived metrics should be added.]

Personal data is retained for the life of the account and deleted or anonymized after account closure, as stated in the Privacy Policy. Two subject-facing mechanisms exist:

• Export: signed-in users can download a self-service export of their personal data (GDPR right of access, Art. 15). The export includes only data tied to the requesting user's own id — profile, memberships, notifications, pulse responses, audit and product events, and metadata of passports and share links they created — never other members' data or organization-level analytics.
• Erasure: account and data erasure are handled on request as a deliberate, confirmed action. Erasure is never triggered implicitly or as a side effect of another operation.
• There is no public or programmatic API; export and erasure run inside the authenticated, access-scoped application.

Database backups are produced by the managed database provider (Supabase) and expire on the provider's configured schedule; data deleted from the live database therefore persists in backups until those backups age out. [Owner to confirm: backup frequency and retention window, aligned with the Business Continuity & Disaster Recovery Policy.] Backups are not used to resurrect data that was deliberately erased, except as an unavoidable consequence of a full disaster recovery — in which case erasure requests are re-applied.

Retention periods may be extended where required by law, litigation hold, or an active security investigation. [Owner to confirm: the process for placing and releasing a legal hold.] Exceptions are documented and time-bounded; the configurable audit-log horizons above are the supported mechanism for extending audit retention.

The platform owner reviews this policy at least annually and whenever a new data category or retention control is introduced. This document is an AI-generated draft and is not legal advice or a binding commitment until reviewed and approved by Persoon.ai Inc. and counsel. Questions may be directed to security@persooninc.com.