Asset Management Policy

This Asset Management Policy defines how Persoon.ai Inc. identifies, inventories, protects, and retires the assets that make up the ShipReady Metrics platform. An asset here is anything whose loss, exposure, or unmanaged change would harm the service or its customers: infrastructure, source code, credentials, data stores, and the customer-connected data sources the product reads.

This policy applies to all production assets and to all personnel who operate them. It complements the Data Classification Policy (what tier each asset's data belongs to) and the Data Retention Policy (how long asset data lives).

The platform is built on a small, deliberate set of managed services and version-controlled artifacts. The core inventory is:

Because schema, deployment, and application configuration are version-controlled, the asset inventory for those layers is reconstructible from the repository rather than maintained as a separate, drift-prone spreadsheet.

The most dynamic assets the platform manages are the data sources customers connect — code hosts, CI/CD, cloud accounts, observability tools, and AI-spend providers. For each organization, the in-product Connections page is the system of record for these assets: it shows every connected provider, its status, and its sync state, and is the single place connections are created, tested, synced, and removed.

• Each connector is defined in a central registry specifying its credential type, exact scopes, what data it pulls, and which scores it feeds.
• The public data-access page in the Trust Center is rendered directly from that same registry, so the published description of what ShipReady reads cannot drift from what the product actually requests.
• Connectors that cannot yet be connected are listed as such and are never shown as functional; the platform does not claim access it does not have.
• For connectors whose target host is supplied by the customer (self-hosted instances), an egress guard blocks requests to loopback, link-local, private, and reserved addresses — including hostnames resolving to them — so a connection cannot be turned into a request-forgery path into internal infrastructure.

Credentials are tracked and protected as first-class assets. Customer connector credentials are encrypted at rest with AES-256-GCM before storage in a dedicated secrets table with deny-all row-level security; encryption and decryption happen only in server-side code, and the encryption key is held as a platform environment secret, never in the codebase or logs.

• Connect flows guide customers to create credentials with the minimum documented scopes, and recommend short expirations where the provider supports them.
• Platform secrets (service keys, encryption keys, provider API keys) live in the hosting platform's environment configuration, not in source control.
• Each credential's existence and lifecycle is visible through its connection: connecting, syncing, and disconnecting are recorded in the audit log.

Data stores are inventoried by ownership. Customer tenant data (metrics, scores, findings, configuration metadata) is org-scoped: every tenant row carries an organization id and is isolated by row-level security policies built on membership helper functions, so each organization's members can only reach their own organization's rows. Compliance-evidence artifacts are stored with SHA-256 integrity hashes, with binary files in a private storage bucket that has no tenant-accessible storage policies. Audit-log records and their retention are governed by the Data Retention Policy.

Assets change through controlled paths and are retired deliberately:

• Application changes ship as immutable deployments that can be rolled back to a previous known-good version; database changes ship as versioned migrations.
• Customer-connected sources are decommissioned by disconnecting them, which deletes the connection and its stored encrypted credential and writes an audit event; a failed deletion blocks the flow rather than leaving the credential silently active.
• Data held in retired or disconnected assets is disposed of per the Data Retention Policy.
• [Owner to confirm: cadence for reviewing and removing unused third-party services, tokens, and DNS records.]

Workstations and other devices used to operate the platform are assets in scope of this policy. [Owner to confirm: the inventory of devices with production access, disk-encryption and screen-lock requirements, and whether mobile-device management is in place.] Access to production systems is limited to authorized personnel of Persoon.ai Inc.; personnel access rights are governed by the Access Control Policy.

The platform owner is accountable for keeping the asset inventory accurate: new services, data stores, and connector types must be reflected in the registry, the Subprocessors document, and this policy before or at launch. This policy is reviewed at least annually and after any significant architectural change.

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.