Third-Party Risk Management Policy

This Third-Party Risk Management Policy ("Policy") defines how Persoon.ai Inc. ("ShipReady Metrics", "we", or "us") identifies, assesses, monitors, and reviews the third-party service providers the ShipReady Metrics service ("Service") depends on — including the subprocessors that process customer personal data on our behalf.

It covers the full vendor lifecycle: inventory and disclosure, pre-engagement due diligence, risk assessment, ongoing attestation monitoring, periodic review, and offboarding. It applies to all vendors engaged to deliver or operate the Service; vendors that process customer personal data are additionally governed by our Data Processing Agreement and disclosed in the Subprocessors document.

Our authoritative outward-facing vendor inventory is the Subprocessors document in this Trust Center, which lists each subprocessor with its purpose, the categories of data it may process, and its primary processing region. Internally, the same population is managed in the platform's vendor risk register, where each vendor record captures:

• Identity and classification: name, category, and whether the vendor is a subprocessor (processes customer personal data) or a supporting vendor.
• Data touched: the categories of data the vendor handles, kept to the minimum needed for its purpose.
• Region and purpose: where processing primarily occurs and why the vendor is engaged.
• Lifecycle status: active, offboarding, or retired.
• Public listing: an explicit flag controls whether a vendor appears on the public subprocessor list — only active, explicitly listed subprocessors are published, and the published projection exposes no internal risk scores or assessment details.

Additions and changes to the inventory are recorded in an append-style audit trail; a change to a vendor's subprocessor or public-listing status is independently logged, so a change to what is publicly disclosed is always attributable.

Before engaging a vendor that will process customer personal data, we perform proportionate due diligence, taking into account the nature of the data, the provider's security posture, and the sensitivity of the processing — as described in the Subprocessors document. This includes reviewing the provider's publicly available security and privacy documentation, confirming appropriate written data protection terms, and minimizing the data shared to what the service requires.

Each vendor's due-diligence state is tracked explicitly in the risk register through a defined lifecycle: not started, in progress, complete, or expired. An expired state means the vendor's review has lapsed and is due again — it is never silently treated as complete.

Each vendor may be assessed with an inherent risk score (before controls) and a residual risk score (after controls), evaluated against a defined risk appetite. The vendor's risk status is derived from the residual score and appetite using the platform's single, canonical risk model — the same model used for the company's cyber risk register — so vendor risk and other operational risk share one consistent vocabulary.

A vendor that has not yet been assessed is shown honestly as unassessed: the register never assumes an unassessed vendor is within appetite. Assessment updates are recorded in the audit trail.

[Owner to confirm: the risk appetite thresholds per vendor category, and which roles perform and approve vendor risk assessments.]

We monitor our key subprocessors' public security attestations through an automated evidence-capture process: a script captures the public trust/security pages of the subprocessors disclosed on our Trust Center (currently Supabase, Vercel, Resend, and Anthropic) as dated, cryptographically hashed (SHA-256) full-page screenshots, stored in a private evidence bucket and mapped to the vendor-management controls of recognized frameworks (SOC 2 CC9.2 and ISO 27001 A.5.19).

• Artifact-only, human-reviewed: a captured page is stored as evidence without any automatic verdict — a screenshot of a vendor's trust page never by itself proves a vendor-management control; a human reviews each artifact.
• Never fabricated: a vendor page that fails to load is skipped and logged, not substituted or guessed.
• Change-aware: unchanged captures deduplicate by content hash, so the evidence trail distinguishes a page that changed from one that was merely re-captured.
• Independent per vendor: each vendor's capture series is tracked separately, so one vendor's newer capture never displaces another's current attestation.

[Owner to confirm: the capture cadence — the process is designed for periodic (e.g., quarterly) runs, and the operative schedule should be stated here once fixed.]

Each assessed vendor carries a review cadence — monthly, quarterly, semiannual, annual, or biennial — and the next review date is derived from the last completed review. A vendor with no scheduled review is shown as unscheduled rather than presumed current.

A sweep flags any vendor whose next review date has lapsed: its due-diligence status is marked expired and an auditable review-due event is recorded, so overdue vendor reviews surface rather than silently aging. Re-completing the review restores the vendor's due-diligence status and schedules the next cycle.

[Owner to confirm: the default review cadence per vendor tier — e.g., annual for subprocessors handling customer personal data, biennial for supporting vendors — and the role responsible for completing reviews.]

For each significant vendor, the register can record a shared-responsibility matrix: per control area, whether the responsibility sits with the vendor, with us as the customer of that vendor, or is shared. This keeps the boundary explicit — for example, our infrastructure providers own physical and environmental security under their programs, while we own our application-level access control, tenant isolation, and configuration.

We do not operate our own data centers; the Subprocessors document describes the infrastructure split in more detail.

When a vendor is replaced or retired, its register record moves through the offboarding and retired lifecycle states; retired subprocessors are removed from the public list. Material changes to the subprocessors that process customer personal data are handled as described in the Subprocessors document — we intend to update the public list and, where required by the applicable customer agreement or DPA, provide advance notice and a mechanism to object.

Offboarding includes confirming the return or deletion of our data where applicable under the vendor's terms and our DPA obligations. [Owner to confirm: the offboarding checklist and data-return verification steps.]

ShipReady Metrics is an early-stage company: this program is operated by the company's leadership rather than a dedicated vendor-management team, and its maturity is evolving alongside the product. We do not claim a completed third-party audit (such as SOC 2 or ISO 27001) for our vendor-management program; the current status of those efforts is tracked in our Trust Center.

Questions about this Policy or our vendors: security@persooninc.com. Postal contact: Persoon.ai Inc., 525 Randall Ave Ste 100 PMB 228, Cheyenne, WY 82001. This document is an AI-generated draft pending legal and owner review and is not legally binding.