Trust Center

Veripsa Core is content-free by design. To warn about cross-PR collisions before merge, file contents are read transiently in memory to produce operational metadata, and then discarded. Only the minimal content-free service metadata below is retained.

What we do store

• Minimal repository and pull-request metadata needed to run advisory checks and explain their state.
• GitHub account and repository numeric IDs, and installation IDs — opaque, immutable identifiers used as our tenancy key.
• Operational freshness and processing state needed to keep checks current and deduplicated.
• Public GitHub login handles and content-free structural metadata, including repository and branch names, PR numbers, commit and content fingerprints, path and symbol names, language and symbol kinds, changed line ranges, relationship types, and timestamps. These names can still be customer or personal data.
• First-party install-intent metadata such as sanitized CTA source, locale, optional campaign slug, and coarse same-site public page bucket.

What we do not store

• File bodies or diff contents. Veripsa Core never persists source code.
• Commit message bodies.
• Secret values.Veripsa does not access GitHub's secret stores. Values committed to tracked files, including committed .env files, can be read transiently with source content but are not intentionally extracted or retained; configuration key names may be retained as structural metadata.
• Private profile fields returned at sign-in.We do not persist a dashboard user's name, email, or avatar. Public GitHub login handles and repository/path/symbol names used by Core are retained as scoped customer metadata as described above.
• Payment card data. Veripsa Core early access has no active checkout or card collection.
• Analytics or advertising identifiers. No third-party analytics or ad SDKs are wired into the platform.
• Raw install referrer URLs or arbitrary CTA query parameters. The install redirect keeps only the approved attribution fields.

For the full policy statement of these boundaries, see the Privacy Policy.

Retention is short by policy and short by construction — inactive repo working sets are rebuilt on demand instead of kept warm forever, and the content-free working set is purged on uninstall.

To request erasure of any data outside an uninstall, email support@veripsa.com. See Privacy for the policy form of the same statements.

Veripsa Core enforces tenant isolation at the database and application layers, in policy and in code path:

• Tenant-isolated database controls are enabled for multi-tenant Core data.
• Immutable GitHub account identifiers scope tenant data. Logins, names, and emails — which can rename or rotate — are not used as the tenancy boundary.
• Any cross-tenant read path is gated by explicit authority checks, never ambient elevation.
• On the platform side, the dashboard's view of a tenant is derived from your GitHub installations, re-checked on every request — what you can see is bounded by your own GitHub access, not by who you signed in as.

We test isolation on every change, with a target of zero cross-tenant reads.

We use the smallest possible set of subprocessors. The summary below is the procurement-review view; the full list — vendor entity, data category, processing region, and what is explicitly not in use — lives on the dedicated Subprocessors page.

We do not use third-party analytics or advertising SDKs. Material changes to the subprocessor list will be reflected on the Subprocessors page with a new Last updated date; we aim for at least 30 days notice before a material change takes effect, though there is no contractual subprocessor-notification SLA on the default plans today.

Veripsa does not offer a contractual uptime SLA today. The dashboard and GitHub App are operated on a best-effort basis.

A live health probe of the Core App is published at /status — it runs a server-side service-health check on every request and reports the outcome honestly (it does not claim a contractual uptime SLA). If your evaluation requires formal uptime terms, email support@veripsa.com.

Report a suspected security issue by emailing support@veripsa.com. Please include enough detail to reproduce; please do not paste source code or secrets — Veripsa is content-free by design, and we will not need them. The full reporter-facing flow — what to include, coordinated-disclosure window, and safe-harbor stance — lives on /security/disclosure.

• Acknowledgement — we aim to acknowledge a suspected security report within a few business days; we prioritize security and outages above other inbound.
• Triage — we assess scope and severity, and if a service outage is involved we begin remediation in parallel.
• Content-free communication — incident updates describe what happened in structural terms (which subsystem, which tenants were affected). We do not echo source code or repository contents.
• Customer notification— if your account's data was affected, we will notify you with what we know, what we've done, and what you may want to do.
• Coordinated disclosure — please give us a reasonable chance to fix and notify before disclosing publicly.

Material service incidents, when published, appear on the public incident log.

Public, verifiable trust signals

• Our org-default security policy is published at GetVeripsa/.github/SECURITY.md as the organization default. An individual repository may publish a superseding policy.
• The public data boundary and GitHub integration contract live at GetVeripsa/veripsa-webhook-spec. User-visible changes are published on the What's new page.

A baseline Data Processing Addendum (DPA) template is published at Data Processing Addendum (DPA). If you need a signed DPA or want us to review your form, email support@veripsa.com. Veripsa Core is content-free and PII-minimal by construction, which keeps the DPA narrow in scope: no source or diff bodies are retained, while public GitHub handles and content-free repository, path, and symbol metadata remain scoped customer data.

Sign-in to the Veripsa dashboard is GitHub OAuth only. We do not operate passwords.

• Identity persisted — only the opaque GitHub user ID (the immutable numeric sub) is persisted. Name, avatar, and email are not stored.
• Scope — identity-only (read:user); the email scope is not requested.
• Session — a signed JWT cookie that carries only the opaque user ID. Signing out clears the cookie.
• Provider changes — GitHub OAuth is the only sign-in provider today. If another provider is added later, it will be documented before use.

Current status: today, Veripsa does not hold:

• SOC 2 (Type I or Type II).
• ISO 27001.
• FedRAMP or other government-cloud accreditation.
• HIPAA readiness — Veripsa is not designed for protected health information.
• A contractual uptime SLA on the default plans (see SLA stance above).

The structural posture above — content-free by design, PII-minimal, tenant-isolated storage, a small subprocessor set — is what we offer today, on the merits, without a certification badge. If your organization needs one of the above to adopt Veripsa, please email support@veripsa.com so we can scope it together.

• Procurement & security review — the same answers in questionnaire shape.
• Subprocessors — the full subprocessor list, change policy, and what is explicitly not in use.
• Privacy Policy — the policy form of the data and retention sections above.
• Security overview — the policy form of the isolation and protection sections above.
• Data Processing Addendum (DPA) — the baseline DPA template.
• Security disclosure — how to report a suspected security issue (scope, what to include, coordinated-disclosure window, and safe harbor).
• SECURITY.md (GetVeripsa org) — the GitHub-side org-wide security policy, the same content in the format reviewers expect to find on GitHub.
• Terms of Service — the terms for using Veripsa Core.
• Support — how to reach us.
• Status — live health probe for Veripsa Core.
• Incidents — the public incident log.