Policies

Incident Response Policy

Effective date: TODO — set on legal approval

AI draft— pending legal & owner review; not legally binding.

1. Purpose and Scope

This Incident Response Policy ("Policy") defines how Persoon.ai Inc. ("ShipReady Metrics", "we", or "us") prepares for, identifies, responds to, and recovers from security and availability incidents affecting the ShipReady Metrics service ("Service"). Its goal is to limit harm to customers, protect personal and customer data, restore normal operations quickly, and meet our notification commitments.

This Policy applies to all personnel, contractors, and service accounts that operate, support, or have access to ShipReady Metrics production systems — including the application hosted on Vercel, the Supabase Postgres database and authentication layer, transactional email via Resend, AI features powered by Anthropic, and source-control connectors such as GitHub and other cloud integrations.

For the purpose of this Policy, a "security incident" is any actual or reasonably suspected event that compromises the confidentiality, integrity, or availability of the Service or the data it processes. This includes unauthorized access, data exposure, malware, account takeover, denial-of-service conditions, and the loss or misuse of credentials or secrets.

2. Roles and Responsibilities

Incident response is coordinated by a designated Incident Commander, supported by engineering, security, and communications roles. In a small team these roles may be held by the same individuals; the responsibilities below remain distinct regardless of headcount.

RolePrimary responsibilities
Incident CommanderOwns the incident end to end: declares severity, coordinates responders, approves containment actions, and authorizes external communications.
Technical Lead / EngineeringInvestigates root cause, executes containment and remediation in the Vercel and Supabase environments, and preserves logs and evidence.
Security ContactAssesses data-protection impact, determines notification obligations, and serves as the point of contact at security@persooninc.com.
Communications OwnerDrafts customer, status-page, and regulator messaging and ensures consistency across channels.

Contact details and an on-call rotation are maintained outside this document and reviewed periodically. Every responder is expected to know how to reach the Incident Commander at any time.

3. Severity Classification

Incidents are assigned a severity level that drives response urgency, escalation, and communication timing. The Incident Commander may raise or lower severity as understanding evolves.

SeverityDescriptionExamples
SEV-1 (Critical)Confirmed breach of customer data, or total loss of Service availability across tenants.Cross-tenant data exposure; database compromise; full outage.
SEV-2 (High)Partial data exposure risk or significant degradation affecting many customers.Authentication failure, RLS misconfiguration under investigation, major performance degradation.
SEV-3 (Moderate)Limited-impact issue with a known workaround or affecting a single tenant.Single-tenant data anomaly, isolated connector failure.
SEV-4 (Low)Minor issue with no customer data risk and minimal availability impact.Non-production alert, cosmetic defect, suspicious but unconfirmed activity.

4. Detection and Reporting

We aim to detect incidents through a combination of automated and human signals. Internal personnel must report any suspected incident to the Security Contact without delay, regardless of confidence level.

  • Application, platform, and database logs and alerts from Vercel and Supabase.
  • Error and anomaly monitoring on the application and background jobs.
  • Audit-trail review of administrative and authentication events.
  • Reports from customers, employees, or external security researchers (see our Vulnerability Disclosure Policy).
  • Notifications from subprocessors regarding incidents on their platforms.

Suspected or confirmed incidents should be reported to security@persooninc.com. Reports should include what was observed, when, the systems involved, and any immediate actions already taken.

5. Response Lifecycle

Once an incident is declared, responders follow a consistent lifecycle. Steps may run in parallel, but each must be addressed before an incident is closed.

  • Triage and declare: confirm the event, assign an Incident Commander, and set an initial severity.
  • Contain: stop ongoing harm — for example, rotating compromised credentials and secrets, revoking sessions or tokens, isolating affected components, or disabling an affected connector.
  • Eradicate: remove the root cause, such as patching a vulnerability or correcting a misconfiguration (including any tenant-isolation or RLS defect).
  • Recover: restore affected systems and data from trusted backups, verify integrity, and confirm normal operation before closing.
  • Preserve evidence: capture relevant logs, timelines, and artifacts to support investigation and any required notifications.

Throughout the lifecycle the Incident Commander maintains a running timeline of actions, decisions, and findings to support the post-incident review.

6. Notification and Communication

Where an incident affects customer or personal data, we will notify affected customers without undue delay and, where applicable, in accordance with our contractual commitments and applicable law (including any Data Processing Agreement). Notifications aim to describe the nature of the incident, the data and systems involved, the measures taken, and recommended customer actions.

Specific statutory deadlines and the identity of supervisory authorities depend on the applicable legal framework and will be confirmed with counsel; this draft does not state any fixed deadline as a commitment. Customers acting as data controllers remain responsible for notifying their own end users and regulators where required.

External status updates may be published through our status page where availability is affected. All external communications are approved by the Incident Commander to ensure accuracy and consistency.

7. Post-Incident Review

For SEV-1 and SEV-2 incidents — and for lower-severity incidents at the Incident Commander’s discretion — we conduct a blameless post-incident review after recovery. The review documents the timeline, root cause, customer impact, and the effectiveness of the response.

  • Confirmed root cause and contributing factors.
  • What detection, containment, and recovery steps worked, and what did not.
  • Concrete corrective and preventive actions with owners and target dates.
  • Any updates needed to this Policy, runbooks, or monitoring.

Action items are tracked to completion and reviewed in subsequent reviews to confirm they reduced the likelihood or impact of recurrence.

8. Testing and Maintenance

This Policy is reviewed at least annually and after any significant incident or material change to our architecture or subprocessors. We intend to exercise the response process periodically through tabletop or simulation exercises to validate readiness; the cadence and results of such exercises are tracked internally.

ShipReady Metrics has not yet obtained SOC 2, ISO 27001, or an independent incident-response audit. The current status of any such effort is reflected in our Trust Center and should be treated as the authoritative source rather than this draft.

9. Contact

Security and incident matters: security@persooninc.com. Postal contact: Persoon.ai Inc., 525 Randall Ave Ste 100 PMB 228, Cheyenne, WY 82001. Data-protection inquiries may be directed to our info@persooninc.com. This document is an AI-generated draft pending legal and owner review and is not legally binding.

AI draft— pending legal & owner review; not legally binding.

Back to Legal