Backup & Recovery Policy

This Backup & Recovery Policy describes how the data behind ShipReady Metrics, operated by Persoon.ai Inc., is backed up and how the platform is restored after data loss, corruption, or infrastructure failure. It covers the production database and file storage, application code and configuration, and the encryption key material recovery depends on.

This policy is the data-level companion to the Business Continuity & Disaster Recovery Policy in this Trust Center, which defines recovery objectives (RTO/RPO), continuity scenarios, and testing. Where the two overlap, the BC/DR Policy governs objectives and this policy governs the backup and restore mechanics.

Understanding what must be restored — and what can be rebuilt — keeps recovery honest and fast. The platform's data falls into three classes:

Backups of the production Postgres database and storage are VENDOR-PROVIDED: they are performed by Supabase's managed backup capabilities under Supabase's security program. ShipReady Metrics does not operate its own backup infrastructure, backup media, or backup encryption; those controls, including encryption of backups at rest, belong to the managed provider. See the Subprocessors document for the provider engagement and the Encryption Policy for the at-rest encryption posture.

• [Owner to confirm: the backup frequency, retention window, and whether point-in-time recovery (PITR) is enabled on the current Supabase plan.]
• [Owner to confirm: that the configured backup settings meet the RPO targets stated in the Business Continuity & DR Policy.]
• ShipReady does not maintain an independent, secondary backup copy outside the managed provider today; adopting one is a roadmap decision. [Owner to confirm: whether an off-provider export cadence is in place or planned.]

The application itself is recovered independently of the database. Source code is version-controlled in git, and the application is deployed on Vercel, where a bad deploy is recovered by redeploying or rolling back to a previous deployment. Production configuration (environment variables and secrets) is held in the hosting platform's environment store rather than in source control.

• Build provenance is baked into each deploy (commit SHA and build time surfaced in the application footer), so the running version is always identifiable during recovery.
• Scheduled jobs (data syncs, retention pruning, monitoring crons) are declared in versioned configuration and are restored automatically with the application deployment.
• [Owner to confirm: that a current export of production environment variables exists outside the hosting platform, so configuration can be rebuilt if the hosting account itself is lost.]

Connector credentials (customer OAuth tokens and API keys) are stored only as AES-256-GCM ciphertext, encrypted under the connector encryption key held as a managed environment secret. This makes the key itself recovery-critical: a database backup restores the ciphertext, but without the key the stored connector credentials are unrecoverable and customers would need to reconnect their sources.

• Losing the connector encryption key does NOT expose data — GCM ciphertext without the key is not decryptable — but it does force every organization to re-authorize its connectors.
• [Owner to confirm: that a secure offline copy (escrow) of the connector encryption key is maintained separately from the hosting platform's environment store.]

Recovery from data loss or corruption follows a defined order: restore the database from the vendor backup, verify the application against the restored state, then rebuild what can be re-derived.

• Database: restore the Supabase Postgres database using the provider's restore tooling (backup snapshot or point-in-time recovery, per the configured capability).
• Application: redeploy or roll back on Vercel to a known-good deployment and confirm environment configuration, including the connector encryption key.
• Connector data: re-establish connector syncs so that source-derived metrics catch up from the customers' systems of record, closing any gap between the backup point and the incident.
• Verification: confirm tenant isolation, authentication, and audit logging are functioning before declaring recovery complete.

Recovery time and recovery point objectives are defined in the Business Continuity & Disaster Recovery Policy and must be kept consistent with the backup capabilities actually configured at the vendor. A backup that has never been restored is an assumption, not a control: restore procedures are intended to be validated periodically rather than assumed to work.

• [Owner to confirm: the restore-test cadence and the date and outcome of the most recent restore validation.]
• Lessons from restore tests and real incidents feed back into this policy and the BC/DR Policy.

Backup retention interacts with data deletion, and this policy is honest about that: when data is deleted from the live database — whether by retention pruning (for example, the audit-log horizons and compliance-evidence retention classes enforced by the daily retention job) or by an erasure request — copies may persist inside vendor-managed backups until those backups expire on the provider's schedule. Deleted data is not restored to the live platform except as an unavoidable side effect of a full-database recovery, after which required deletions are re-applied.

[Owner to confirm: the vendor backup expiry window, which bounds how long deleted data can persist in backups.]

The platform owner is accountable for confirming that vendor backup settings, key escrow, and restore procedures reflect the live environment, and for executing recovery when needed. ShipReady Metrics is operated by its platform owner; this policy does not claim a dedicated operations team or on-call rotation.

This policy is reviewed at least annually, after any restore test, and after any incident involving data loss. Questions should be directed to security@persooninc.com. 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.