Logging & Monitoring Policy

This Logging & Monitoring Policy describes how ShipReady Metrics, operated by Persoon.ai Inc., records security-relevant activity, monitors the platform for errors and abuse signals, and manages the lifecycle of the resulting logs. It covers the application audit trail, server logs, error reporting, and operational alerting across the production platform.

ShipReady Metrics is an early-stage company operated by its platform owner. This policy describes the controls actually implemented in the platform today; it does not claim a 24/7 security operations center, a dedicated monitoring team, or certifications the company does not hold.

• Attributability: security-relevant actions are recorded with the acting identity and, where applicable, the tenant organization they belong to.
• Tamper resistance: the audit trail is append-only; no application path can update or delete audit entries outside the sanctioned retention prune.
• Data minimization: logs and audit metadata record the scope of an action (identifiers, counts, filters), never secrets, tokens, passwords, or bulk personal data.
• Non-interference: logging and alerting are best-effort by design — a logging failure must never break or block the action it records.
• Bounded retention: logs are kept long enough to support investigations and compliance, then pruned on defined horizons.

ShipReady Metrics maintains an application audit trail in an append-only database table. Row-Level Security forbids updates and deletes on this table, so entries cannot be altered after the fact; the only sanctioned removal path is the retention prune described in Section 7. Each entry records the action, the acting user (or null for system/external events), the tenant organization where applicable, a human-readable target, and structured non-sensitive metadata.

The set of auditable actions is a closed, code-reviewed union rather than free-form strings, which keeps the trail queryable and every recordable event reviewable in one place. Audited categories include:

• Authentication events: login, logout, password change, and MFA factor removal.
• Connector lifecycle: connect, test, sync, failure, disconnect, and reconnect of customer data sources.
• Membership and organization administration: invitations, joins, role changes, removals, and settings updates.
• Platform-operator actions, including cross-tenant reads of personal-data surfaces and every bulk CSV export — the prime exfiltration surfaces are each individually recorded.
• Compliance-module lifecycle events (document, evidence, vendor, and due-diligence workflows) and GDPR data exports.
• Denied permission attempts.

Audit metadata is scope-only by contract: it records which surface was read, which filters were applied, or how many rows were affected — never the personal data or secret values themselves. Inbound external contacts (for example vulnerability-report or due-diligence requester emails) are stored hashed upstream, so raw contact data does not reach the audit trail.

Server-side code logs through a structured logger that emits one JSON object per line in production, carrying a severity level, a stable message, and structured fields. Errors are serialized to their name and message only — raw stack traces and secret payloads are never written to the log stream. Log lines are captured by the hosting platform (Vercel) as a vendor-provided log pipeline.

[Owner to confirm: the retention period applied to platform logs in the hosting provider, which is governed by the Vercel plan in effect rather than by ShipReady code.]

The platform includes a centralized server-side error-reporting pipeline compatible with Sentry. Reported events are scrubbed before they leave the platform: sensitive-looking keys (token, secret, password, API key, and similar) are redacted, and free-text messages and stack traces are additionally scanned for recognizable credential shapes (GitHub, GitLab, Stripe, AWS, Slack tokens, and JWTs), which are replaced with a redaction marker.

Error reporting is capture-safe by contract: it never throws and never masks the original failure. When no Sentry DSN is configured in an environment, errors fall back to the platform log stream rather than being silently dropped. [Owner to confirm: whether a Sentry DSN is currently configured in production.]

The platform proactively alerts its operator on signals that indicate login is broken or the platform is misbehaving, rather than waiting for user reports.

• Login-failure alerts: when a user's sign-in fails at the OAuth callback, an email alert is sent to the platform-owner roster with the failure reason, host, and time. Alerts are throttled to at most one per 15 minutes so an outage cannot flood the inbox, and dispatch is decoupled from the login path so alerting never slows a user down.
• Alerting is best-effort and self-reporting: if email is unconfigured or no owner is on the roster, the skip is itself logged.
• [Owner to confirm: any additional alerting channels (e.g., Sentry notification rules or uptime monitoring) configured outside the codebase.]

Audit-log retention is enforced automatically by a daily scheduled job (Vercel Cron), authenticated with a dedicated secret so no one else can trigger a delete. The job calls a single database function that is the one sanctioned delete path for audit rows; the same policy values the job enforces are displayed on the in-app audit page, so operators and auditors see the policy that is actually applied.

The platform owner is responsible for reviewing alerts, error reports, and audit activity, and for initiating the Incident Response Policy when monitoring surfaces a suspected security incident. Organization administrators can review their own organization's audit trail in the application.

• [Owner to confirm: the cadence of routine (non-alert-driven) log and audit review.]
• Anomalies that indicate a security incident are handled under the Incident Response Policy in this Trust Center.

Attempts to disable, bypass, or tamper with logging or the audit trail are treated as security violations. This policy is reviewed at least annually and whenever the logging or monitoring architecture changes.

Questions should be directed to security@persooninc.com. 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.