Procurement & security review

What classes of customer data does Veripsa store?

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

What we do store

• Minimal repository and pull-request metadata needed to run advisory checks and explain their state.
• GitHub account, repository, and installation numeric IDs (opaque, immutable tenancy key).
• Public GitHub login handles and content-free repository, branch, PR, path, symbol, language, line-range, relationship, timestamp, advisory, and delivery metadata. Names in this set are treated as scoped customer data.
• Operational freshness and processing state needed to keep checks current and deduplicated.

What we do not store

• File bodies or diff contents. Source code is never persisted.
• Commit message bodies.
• Secret values are not intentionally extracted or retained, and GitHub's secret stores are not accessed. Values committed to tracked files (including committed .env files) can be read transiently with source content; configuration key names may be retained as structural metadata.
• Dashboard profile names, emails, or avatars returned at sign-in. Public GitHub handles and repository/path/symbol names used by Core are retained as scoped customer metadata as listed above.
• Payment card data. Veripsa Core early access has no active checkout or card collection.
• Analytics or advertising identifiers.

Source of record: Trust Center, section 1; policy form in the Privacy Policy.

Where is customer data stored?

The content-free working set is stored on managed cloud hosting in the US. The Veripsa platform front end (this site and the dashboard) uses the same managed-hosting posture. Veripsa Core early access has no active checkout, card collection, or paid subscription data.

GitHub data is read via the GitHub App and posted back as check runs and pull-request comments; the GitHub platform itself is global and operated by GitHub. Future paid plans are expected through GitHub Marketplace, but paid plans are not available yet.

Source of record: Subprocessors page (vendor entity, data category, processing region, and what is explicitly not in use).

How long is customer data retained?

Retention is short by policy and short by construction — inactive repo working sets are rebuilt on demand instead of kept warm forever, the content-free working set is purged on uninstall, and operational telemetry rolls forward on a 30-day window.

• Working set (in-flight reservations and content-free caches) — kept while active. Inactive repo working-set/cache rows may be pruned after a period of inactivity, normally 30 days. The working set is rebuilt on the next default-branch push or pull request; co-change history is repopulated asynchronously. Purged on uninstall and on account deletion via the enumerated erase/purge gate.
• Operational telemetry (push and landing events) — retained 30 days, then pruned.
• Advisory history — kept as an append-only content-free record until account erasure; not used as a live working set.
• Webhook delivery audit — terminal (completed or failed) entries pruned after 30 days by the nightly retention sweep; the delivery payload is cleared as soon as an entry completes. Also covered by the same account-deletion erase/purge gate.
• Account-lifecycle events — append-only operational record; deleted on account deletion via the enumerated erase/purge gate.
• Sign-in session cookie — signed JWT in the browser carrying only the opaque GitHub user ID; cleared on sign-out. No parallel server-side session record.

Source of record: Trust Center, section 2.

Who else processes customer data?

The smallest possible set. 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.

• GitHub — GitHub App platform and OAuth sign-in to the dashboard. Reads repository structure; writes check runs and PR comments; identity at sign-in (opaque GitHub user ID only).
• Managed cloud hosting — compute and managed database hosting for Veripsa Core and the Veripsa platform; US. All content-free working-set data is stored here.

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 (a DPA covering this is available on request — see Compliance below).

How is customer data protected on the wire and in storage?

• In transit.Traffic to the Veripsa platform (this site, the dashboard, the API), to the Core GitHub App, and to GitHub's API is protected with TLS.
• At rest. The content-free working set is held in a managed database, which encrypts data at rest at the platform layer. Backups are encrypted under the same posture.
• Least-privilege application access. The application connects to its database with a restricted role, scoped to the access it needs.
• Tenant isolation in the database. Multi-tenant data is scoped with immutable GitHub account identifiers, and cross-tenant reads require explicit authority checks.
• Card data. Never seen by Veripsa. Early access has no active checkout or card collection.

Source of record: Security overview and Trust Center, section 3.

How do users sign in? What identity do you store?

• Sign-in. Dashboard sign-in is GitHub OAuth only. We do not operate passwords.
• Identity persisted. Only the opaque GitHub user ID (immutable numeric sub). Name, avatar, and email are not stored.
• OAuth scope. Identity-only (read:user). The email scope is not requested.
• Session. Signed JWT cookie carrying only the opaque user ID. Sign-out clears the cookie. No parallel server-side session store.
• Authorization. What you can see in the dashboard is derived from your GitHub installations and re-checked on every request — bounded by your own GitHub access, not by who you signed in as.
• GitHub App permissions. Veripsa Core requests only the GitHub App permissions it needs to read repository structure and post checks and comments on pull requests. You choose which repositories the App can access, and you can change that scope or uninstall at any time from GitHub.

Source of record: Trust Center, sections 3 and 8; Security overview.

What is your incident-response process? Where can I see incident notes?

Suspected security issues go to support@veripsa.com. The reporter-facing flow — what to include, our coordinated-disclosure window, and our safe-harbor stance — is on /security/disclosure.

• Acknowledgement. We aim to acknowledge a suspected security report within a few business days; security and outage reports jump the queue over other inbound.
• Triage. We assess scope and severity; 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 notify you with what we know, what we've done, and what you may want to do.
• Public incident notes. Incidents that affected customer service, when published, appear on the public incident log with a written incident note.

What uptime do you commit to contractually?

We are honest about where we are. Today, Veripsa does not offer a contractual uptime SLA on the default plans. 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.

Source of record: Trust Center, section 5.

What certifications and attestations do you hold?

Current status: today, Veripsa does not hold the following — and we will not claim them until they are real:

• SOC 2 (neither Type I nor Type II).
• ISO 27001.
• FedRAMP or other government-cloud accreditation.
• HIPAA readiness — Veripsa is not designed for protected health information; do not send PHI to the service.
• PCI DSS scope — Veripsa never sees card data and early access has no active checkout, so we are not in PCI scope.
• A contractual uptime SLA on the default plans (see SLA section above).

What we do offer today

• Content-free architecture. No source code is ever persisted — the safest data is the data we never hold.
• PII-minimal identity. Only the opaque GitHub user ID; no name, avatar, or email.
• Tenant-isolated storage. Multi-tenant data is scoped with immutable GitHub account identifiers, with isolation tests on every change.
• A small subprocessor set. GitHub and Render — plus a public list of what is explicitly not in use (no third-party analytics, no advertising SDKs, no active payment processor).
• A baseline DPA available for procurement review — read the current template at /dpa. For a counter-signed instance or to review a customer-preferred DPA form, email support@veripsa.com.
• A public incident log at /incidents with written incident notes for incidents that exceeded the five-minute line.

If your organization needs one of the certifications above to adopt Veripsa, email support@veripsa.com so we can scope it together. Source of record: Trust Center, section 9.

How does a customer have their data deleted?

• Uninstall the GitHub App. The content-free working set for that installation is purged.
• Account deletion. An enumerated erase/purge gate sweeps the working set, the webhook-delivery audit, and account-lifecycle events for the account.
• Ad-hoc erasure requests. Email support@veripsa.com to request erasure of any data outside an uninstall.

Source of record: Trust Center, section 2; Privacy Policy.

This page is written so it prints cleanly. To attach it to a vendor file:

• macOS — Safari, Chrome, or Firefox. ⌘P → Destination → Save as PDF.
• Windows / Linux — Chrome, Edge, or Firefox. Ctrl+P → Destination → Save as PDF.
• Choose Default margins, paper size A4 or Letter, and enable Background graphics if you want the link colors in the PDF.

A standalone print-friendly HTML version (no site chrome) is at /procurement/security-questionnaire-template.html. Open it, print, and save as PDF — or hand it to your reviewer as the seed document for your own questionnaire.

If your team uses a specific questionnaire format (CAIQ, SIG, a custom internal form), email support@veripsa.com and we will fill it in directly.

• Trust Center — the source-of-truth page these answers cite.
• Security overview — the architecture and protection posture in policy form.
• Security disclosure — how to report a suspected security issue (scope, what to include, coordinated-disclosure window, safe harbor).
• Privacy Policy — the policy form of the data and retention sections.
• Subprocessors — vendor entity, data category, processing region, and what is explicitly not in use.
• Data Processing Addendum (DPA) — the baseline DPA template for early-access procurement review.
• Incidents — the public incident log and incident notes.
• Status — live health probe for Veripsa Core.