Business Continuity & Disaster Recovery Policy

This Business Continuity and Disaster Recovery (BC/DR) Policy describes how Persoon.ai Inc. prepares for, responds to, and recovers from events that could disrupt the availability or integrity of the ShipReady Metrics platform or the data it processes. The goal is to limit downtime and data loss and to restore service in a controlled, prioritized manner.

This policy covers the production platform and its core dependencies: the Next.js application hosted on Vercel, the Supabase Postgres database, authentication, and storage, transactional email via Resend, AI features via Anthropic, and source/cloud connectors such as GitHub. It applies to all personnel involved in operating or recovering these systems.

ShipReady Metrics defines recovery objectives that express how quickly service should be restored (Recovery Time Objective, RTO) and how much data loss is tolerable (Recovery Point Objective, RPO) for its core service tiers. The values below are draft targets and must be confirmed and committed to by the platform owner before publication; they are not contractual service-level guarantees.

Continuity planning is driven by an assessment of plausible disruption scenarios and their impact on customers and operations. Representative scenarios include:

• Outage or degradation of a critical third-party provider (Vercel, Supabase, Resend, Anthropic, or a connector source).
• Data corruption or accidental deletion within the database.
• A security incident affecting availability (e.g., ransomware, denial of service, or credential compromise).
• Regional cloud infrastructure failure.
• Loss of access to operational tooling or key personnel.

Each scenario is evaluated for likelihood and impact, and mitigations are prioritized accordingly. The platform’s reliance on managed providers means that some availability outcomes depend on those providers’ own resilience and published service levels.

Customer data resides primarily in the Supabase Postgres database, with files in Supabase storage. Backups are relied upon as the primary mechanism for recovering from data loss or corruption.

• Automated database backups are performed using Supabase’s managed backup capabilities; frequency and retention are configured to meet the RPO targets above and must be confirmed by the platform owner.
• Backups are stored by the managed provider with encryption at rest.
• Backup restoration is intended to be validated periodically rather than assumed to work (see Testing).
• Source-derived data from connectors (e.g., GitHub) can, where supported, be re-synced from the originating system as an additional recovery path.

ShipReady Metrics builds on managed cloud platforms that provide redundancy and availability features. The application layer on Vercel is stateless and horizontally scalable, allowing the hosting platform to route around individual failures, while persistent state is concentrated in the managed database and storage layer.

• Application hosting (Vercel): managed, redundant edge/serverless infrastructure; deployments are immutable and can be rolled back to a previous known-good version.
• Database and storage (Supabase): managed Postgres with provider-level durability and backup tooling.
• Configuration as code: infrastructure and deployment configuration are version-controlled to support reproducible recovery.

On detection of a disruptive event, ShipReady Metrics follows a structured response: assess and declare, communicate, contain, recover, and review. Recovery prioritizes restoring core customer-facing functionality first, then secondary capabilities.

• Assess and declare: determine severity and whether to invoke this BC/DR plan.
• Communicate: notify affected internal responders and, where appropriate, customers; status updates may be published as the situation develops.
• Contain and recover: redeploy or roll back the application, restore the database from backup as needed, and re-establish connector syncs.
• Validate: confirm data integrity and service health before declaring full recovery.
• Review: conduct a post-incident review and capture remediation actions (see Testing and Review).

Detailed step-by-step runbooks for these procedures are maintained operationally and are being formalized; the runbook set should be confirmed as complete by the platform owner.

During a significant disruption, ShipReady Metrics aims to keep affected customers informed in a timely manner through its status communications and direct notification where warranted. Security incidents involving customer data are additionally handled under the Incident Response and applicable privacy obligations.

• Internal escalation paths and on-call responsibilities are defined operationally.
• Customer-facing updates are issued for incidents that materially affect availability or data.
• Security or data-breach notifications follow the timelines and channels described in the relevant privacy and security documents.
• Contact for continuity and security matters: security@persooninc.com.

A continuity plan is only as good as its last test. ShipReady Metrics intends to validate backup restoration and recovery procedures on a regular cadence and to refine the plan based on results and on lessons learned from real incidents.

• Backup restore drills and recovery exercises are planned on a periodic basis; a formal, documented test cadence is in progress and must be confirmed by the platform owner.
• Findings from drills and post-incident reviews feed remediation actions and updates to this policy and the underlying runbooks.
• Independent attestation of these controls (e.g., SOC 2) is in progress / not yet obtained — see the Trust Center for current status.

The platform owner is accountable for maintaining this policy, ensuring recovery objectives are realistic, and confirming that backups, runbooks, and test cadence reflect the live environment. This policy is reviewed at least annually and after any major incident or significant architectural change.

This document is an AI-generated draft and is not legal advice, a warranty, or a binding service-level commitment until reviewed and approved by Persoon.ai Inc. and counsel. Questions may be directed to security@persooninc.com.