Information Security Policy

This Information Security Policy is the master security policy of Persoon.ai Inc. (“ShipReady Metrics”, “we”, “us”). It establishes the objectives, governance, and principles under which we protect the confidentiality, integrity, and availability of the ShipReady Metrics platform and the customer data it processes, and it anchors the family of topic-specific policies published in the Trust Center.

This policy applies to all personnel acting on behalf of ShipReady Metrics, to all environments of the platform (the production Next.js application on Vercel, the Supabase-hosted Postgres database and authentication layer, and supporting development and CI systems), to the source code repository and its delivery pipeline, and to third-party services that process customer data (see the Subprocessors document).

Where a topic-specific policy in the family below states more detailed requirements, the specific policy controls for that topic. This document is an AI-generated draft pending legal and owner review and is not binding until approved and dated.

ShipReady Metrics is an early-stage company operated by its founder. Security accountability is deliberately simple and honest: the founder/owner is the accountable owner of this policy, of the policy family, and of the platform’s security posture. We do not claim a security committee, a dedicated security team, or organizational structures that do not exist.

• Policy owner and approver: Sukhjit Dhillon, President, Persoon.ai Inc. Accountability for this policy — and for the information security programme it governs — rests with that role.
• Day-to-day security operations (dependency updates, migration review, incident handling) are performed by the owner, supported by the automated controls described in Section 5.
• External advisors or counsel involved in policy review: [Owner to confirm: whether outside counsel or security advisors participate in review].
• As the company grows, ownership of individual policies may be delegated; any delegation will be recorded in the affected policy’s next revision.

This master policy is implemented through topic-specific policies, each published in the Trust Center. Together they form the ShipReady Metrics security policy family:

• Access Control Policy — who can access systems and customer data; RBAC (admin / engineer / executive), least privilege, and tenant isolation.
• Secure Development Lifecycle Policy — how software is designed, written, tested, and verified before it reaches production.
• Change Management Policy — how application, database, and configuration changes are controlled, deployed, and traced.
• Incident Response Policy — how security incidents are detected, triaged, contained, and communicated.
• Business Continuity & Disaster Recovery Policy — how the platform recovers from outages and data-loss events.
• Vulnerability Disclosure Policy — how external researchers report vulnerabilities to us responsibly.
• Acceptable Use Policy — the conduct, content, and security rules that apply to users of the Service.
• Privacy Policy, Data Processing Agreement (DPA), and Subprocessors — how personal data is processed, protected, and shared with vendors.
• Security Overview — a plain-English summary of the platform’s implemented security controls.

Documents in the Trust Center carry a status of draft or published; only published documents with a real effective date have been through owner and legal review.

Security effort is prioritized by risk, not by checklist theater. We maintain a security risk register that records identified risks to the platform and their treatment, and the compliance module’s readiness tooling evaluates controls against collected evidence rather than assumptions.

• Risks are identified from the architecture itself (multi-tenant isolation, connector credentials, supply chain), from operational incidents, and from external reports received under the Vulnerability Disclosure Policy.
• The platform’s evidence-collection design follows an explicit honesty rule: a control with no verifiable evidence is treated as a gap — never assumed to pass. Collected evidence artifacts are content-hashed (SHA-256) for tamper-evidence and traceability.
• Risk acceptance decisions rest with the owner. [Owner to confirm: cadence for reviewing the risk register, e.g. quarterly.]

ShipReady Metrics does not currently represent that it holds third-party certifications such as SOC 2 or ISO/IEC 27001. Where customers require attestations for our infrastructure vendors, we rely on and collect those vendors’ own attestations (see Subprocessors).

The following principles are implemented in the platform today and are verifiable in its codebase and delivery pipeline:

• Tenant isolation by default: every tenant table is protected by Postgres Row-Level Security (RLS); an automated pgTAP test suite re-proves tenant isolation on every change by applying all database migrations from scratch and asserting that cross-tenant reads are denied.
• Least privilege and default deny: application roles (admin / engineer / executive) gate actions server-side; the most sensitive tables (e.g. connector secrets) are deny-all to every client role and readable only by the service role.
• Defense in depth at the browser boundary: a per-request Content-Security-Policy with a cryptographic script nonce and strict-dynamic, plus HSTS, X-Frame-Options DENY, and related security headers.
• Secrets hygiene: no secrets in the repository; environment secrets live in the hosting platform’s environment configuration; connector tokens are encrypted at the application layer with AES-256-GCM; bearer tokens (SCIM, telemetry, invites) are stored only as SHA-256 hashes.
• Input validation and output encoding: schema validation (Zod) at trust boundaries and framework-level output escaping.
• Auditability: privileged actions (authentication events, connector changes, administrative operations) are recorded in an append-oriented audit log.
• Automated guardrails in CI: every change runs typecheck, lint, tests, a production build, a SECURITY DEFINER function-grant audit, and the database isolation suite before it ships (see the Change Management Policy).

All personnel with access to production systems or customer data must follow this policy and the Acceptable Use Policy. Given the company’s current size, personnel controls are minimal and stated honestly rather than aspirationally:

• Persoon.ai Inc. has no employees. Access is stated at two distinct levels, because they are not the same thing: INFRASTRUCTURE access (source repository, hosting, database) is held by the founder/owner alone — the repository is private with a single collaborator. CROSS-TENANT access to customer data through the platform console is held by three principals: the founder/owner, one contracted sales engineer engaged for customer onboarding, and one automated service account used by the end-to-end test suite.
• Console roles follow a least-privilege capability matrix rather than a single administrator level. The automated test account is deliberately NOT granted the highest role: it cannot grant, change, or revoke staff access, so a leaked build credential cannot escalate itself or lock out the owner. The current roster is visible to any authorized reviewer in the console.
• The company has no employees, so no background-screening programme is operated today. Screening requirements will be established before any employee is engaged. This is stated as an absent control, not an implemented one.
• For the same reason, no recurring security-awareness training programme is operated today. A training approach will be established as personnel are added; it is not claimed here in advance of existing.
• Contractors or third parties granted any access must be bound by written confidentiality obligations before access is provisioned. The company maintains a written Contractor Confidentiality & Data Protection Agreement for this purpose, covering purpose limitation, a prohibition on exporting customer data or using it to train AI systems, 24-hour incident reporting, and obligations that survive the end of access.

ShipReady Metrics maintains its security evidence with the same discipline it sells to customers. The compliance module stores control verdicts and evidence artifacts with traceability (which control, which source, when collected, by what collector, and a content hash), and treats missing evidence as a visible gap rather than a silent pass.

• Evidence for infrastructure controls operated by vendors (hosting, database, email) is collected as vendor attestations and tracked alongside the Subprocessors list.
• Customer-facing summaries of implemented controls are published in the Security Overview; drafts are clearly labeled as drafts.
• Requests for security documentation or due-diligence support can be made through the Trust Center contact channels.

Violations of this policy or of any policy in the family by personnel may result in revocation of access and, where applicable, termination of the engagement. Violations by users of the Service are handled under the Acceptable Use Policy and the applicable terms.

Exceptions to any policy in the family must be explicit: recorded in writing with the reason, scope, compensating controls, and an expiry or review date, and approved by the policy owner. Undocumented exceptions are treated as violations.

This policy and each policy in the family are reviewed and re-approved on a defined cadence and additionally whenever a material change to the platform, its vendors, or applicable law warrants it. [Owner to confirm: review cadence, e.g. at least annually.]

• Policies are maintained as version-controlled documents; every revision is traceable through the repository’s immutable git history.
• Material changes to published policies are reflected in the Trust Center; the effective date is updated on approval.
• Questions about this policy may be directed to Persoon.ai Inc. via the contact channels listed in the Trust Center.