Data Classification Policy

This Data Classification Policy defines how Persoon.ai Inc. classifies the information processed by the ShipReady Metrics platform and the minimum handling requirements for each classification tier. Classification drives access control, encryption, retention, and disclosure decisions.

This policy applies to all data stored or processed by the production platform — the Next.js application on Vercel, the Supabase Postgres database, authentication, and storage — and to all personnel and systems that handle that data. The tiers below are defined around the categories of data the platform actually holds; no tier is aspirational.

ShipReady Metrics uses four classification tiers. Every category of data the platform stores maps to exactly one tier, and each tier's examples below are real data categories in the production system — not hypothetical ones.

The most sensitive data the platform holds is customer connector credentials — the tokens and keys customers provide so ShipReady Metrics can read their systems. These are never stored in plaintext: credentials are encrypted at rest with AES-256-GCM before storage, in a dedicated secrets table with deny-all row-level security that only the service role can reach. Encryption and decryption happen exclusively in server-side code; the encryption key is supplied via a platform environment secret and is never sent to a client or written to logs.

• Connector credentials are requested with the narrowest scopes the provider supports, and the connect flow documents the exact scopes per provider.
• Disconnecting a connector deletes the connection and its stored encrypted credential, and the disconnection is recorded in the audit log.
• Platform-level secrets (database service keys, the credential-encryption key, email and AI provider keys) are held as environment configuration on the hosting platform, not in the codebase.
• Restricted data is never included in data exports, reports, or the public Trust Center.

Customer tenant data is the substance of the product: engineering metrics, scores, findings, and configuration metadata derived from each organization's connected sources, plus compliance-evidence artifacts. It is confidential to the owning organization and isolated by multi-tenant row-level security — tenant rows carry an organization id, and Postgres policies built on membership helper functions (checking that the requesting user is a member of the row's organization, with role checks where required) enforce that members only ever see their own organization's rows.

• Connectors ingest aggregate signals — counts, rates, statuses, and versions — from provider APIs, and source code is never stored. Aggregate does not mean anonymous: the derived metrics also carry the identifiers the numbers describe, including repository names, contributor display names from the source system, and the names of affected cloud resources. A per-repository readiness breakdown that cannot name the repository is not actionable, so these identifiers are retained deliberately and classified as confidential tenant data.
• Observability connectors read summaries only and never request or store raw log events or search-result bodies.
• Compliance-evidence artifacts (JSON snapshots and binary files such as screenshots and vendor attestations) are stored with SHA-256 integrity hashes; binary blobs live in a private storage bucket with no tenant-accessible storage policies — access is mediated by the application.
• There is no public or programmatic API: confidential tenant data stays inside the authenticated, access-scoped application.

Personal data is classified Confidential. The categories the platform holds are exactly those enumerated in the self-service GDPR data export: the user's profile, organization memberships, notifications, pulse survey responses, audit events, and product analytics events tied to their user id (plus metadata for any ShipReady Passports, snapshots, or share links the user created).

• Pulse survey responses are reported only as anonymized aggregates subject to a minimum-respondent threshold, never as individual answers.
• Lead and contact records (company names plus contact names and business email addresses) held in the internal sales pipeline are also personal data and are handled at this tier.
• Handling of personal data — lawful bases, subject rights, export, and erasure — is governed by the Privacy Policy and the Data Retention Policy.

Internal data covers operational content such as runbooks, design documents, and Trust Center documents still in draft status. It is not published, but its disclosure would not expose customer data or secrets. Public data is content deliberately published: marketing pages, Trust Center documents once approved and marked published, and the public data-access page — which is rendered directly from the same connector registry the product enforces, so its published claims about read scopes cannot drift from what the platform actually requests.

The platform owner is accountable for keeping this classification aligned with the data the platform actually holds: any new data category introduced by a feature must be assigned a tier before launch. [Owner to confirm: whether a formal classification review is embedded in the feature-release checklist.] This policy is reviewed at least annually and whenever a new category of data 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.