Encryption Policy

This Encryption Policy describes how ShipReady Metrics, operated by Persoon.ai Inc., uses encryption to protect customer data in transit and at rest. It covers the customer-facing application, its APIs, the managed database and storage layer, and the application-layer encryption ShipReady itself performs on sensitive credentials.

ShipReady Metrics runs on managed infrastructure (Vercel for hosting, Supabase for the Postgres database, authentication, and file storage). This policy is explicit about which encryption controls ShipReady implements directly in its own code and which are provided by those infrastructure vendors under their own security programs. Vendor-provided controls are identified as such throughout; see the Subprocessors document for the full provider list.

All connections to the ShipReady Metrics application are served over HTTPS. TLS termination is provided by Vercel, our hosting provider, as a vendor-managed control. The application reinforces transport security with an HTTP Strict-Transport-Security (HSTS) header set on every response — max-age of 63072000 seconds (two years) with includeSubDomains and preload — instructing browsers to refuse plaintext HTTP connections to the platform and its subdomains.

• HSTS and companion security headers (X-Frame-Options: DENY, X-Content-Type-Options: nosniff, Referrer-Policy, Permissions-Policy, Cross-Origin-Opener-Policy) are set platform-wide in the application configuration.
• A Content-Security-Policy with a fresh per-request script nonce is attached to every response by the request middleware, restricting where scripts can load from and where forms can submit.
• Application connections to the Supabase database, authentication, and storage services are made over HTTPS/TLS (and secure WebSockets where applicable).
• Transactional email is delivered through Resend; transport security between mail providers is a vendor-managed control.

Customer data is stored in a Supabase-managed Postgres database and Supabase-managed storage buckets. Encryption at rest for this infrastructure is VENDOR-PROVIDED: it is implemented and operated by Supabase and its underlying cloud providers under their security programs, not by ShipReady Metrics. ShipReady does not operate its own data centers, disks, or storage-level encryption. The same applies to Vercel-hosted build and log infrastructure.

ShipReady relies on these providers' published security documentation and certifications for storage-level encryption claims and does not restate them as its own controls. The engaged providers, the data categories each processes, and their hosting regions are listed in the Subprocessors document in this Trust Center.

In addition to vendor-provided infrastructure encryption, ShipReady Metrics applies its own application-layer encryption to the most sensitive data it holds: the OAuth tokens and API credentials customers grant when connecting external sources (such as GitHub and cloud connectors). These tokens are never stored in plaintext.

• Algorithm: AES-256-GCM (authenticated encryption), with a cryptographically random 12-byte IV generated per encryption and a 16-byte GCM authentication tag that causes decryption to fail on any tampering.
• Storage: only the ciphertext is persisted, in a dedicated table protected by deny-all Row-Level Security that is accessible solely to the server-side service role — never to end-user database sessions.
• Decryption is server-only: the module that encrypts and decrypts these credentials is marked server-only and cannot be bundled into or executed by client-side code.
• If no encryption key is configured in an environment, connector flows that would store credentials are gated off rather than falling back to plaintext.

The connector-credential encryption key (CONNECTOR_ENC_KEY) is a 32-byte AES-256 key held as a managed environment secret in the hosting platform's environment configuration. It is never committed to source control, never sent to the client, and never written to logs.

• Keys for vendor-provided encryption at rest (database, storage, hosting) are generated, stored, and rotated by the respective providers under their own key-management programs.
• There is currently no automated rotation mechanism for the connector-credential key; rotating it requires re-encrypting stored ciphertexts (or having customers reconnect their sources). [Owner to confirm: key-rotation procedure and cadence.]
• [Owner to confirm: where a secure offline copy of the connector-credential key is escrowed, given that loss of the key renders stored connector credentials unrecoverable — see the Backup & Recovery Policy.]

Encryption is supported by strict handling rules that keep secrets out of places encryption does not reach — source code, logs, audit trails, and error reports.

• Production secrets and API keys live in managed environment/secret stores and are never committed to source control.
• The audit log's metadata contract explicitly forbids recording secrets, tokens, or passwords.
• The structured server logger serializes errors to name and message only — never raw stacks or secret payloads.
• The error-reporting pipeline redacts sensitive-looking keys (token, secret, password, API key, and similar) and additionally scrubs free-text error messages and stack traces for recognizable credential shapes (GitHub, GitLab, Stripe, AWS, Slack tokens, and JWTs) before any event leaves the platform.

ShipReady Metrics never stores full payment card numbers. When billing is enabled, card details are collected and held by Stripe, the payment processor, under its own PCI-DSS obligations; ShipReady retains only billing contact details, subscription status, and payment metadata. See the Subprocessors document.

Any exception to this policy (for example, a temporary need to handle a credential outside the standard encrypted path) must be approved by the platform owner, time-bounded, and recorded. Violations may result in revocation of access and other consequences described in the Access Control Policy.

This policy is reviewed at least annually and whenever the platform's cryptographic architecture changes. 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.