Procurement & security review
Veripsa — Security questionnaire response (template)
Most procurement teams ask the same ~30 questions. This is our written answer in questionnaire form. Print to PDF (⌘P / Ctrl+P → Save as PDF) and attach to your vendor file. Every answer links back to a source-of-truth page on veripsa.com so your reviewer can audit independently rather than take this packet at face value.
1. Data classification
What classes of customer data does the vendor 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 below 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.
- 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.
- GitHub secret stores are not accessed. Values committed to tracked files (including committed
.envfiles) can be read transiently with source content, but are not intentionally extracted or retained; 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.
- Third-party analytics or advertising identifiers.
2. Data residency
Where is customer data stored?
- Veripsa working set — managed cloud hosting, region US.
- Veripsa platform (this site, dashboard, admin, plan status) — same managed-hosting posture.
- GitHub data — read via the GitHub App; posted back as check runs and PR comments. GitHub itself is global, operated by GitHub.
- Billing data — none in active early access. Future paid plans are expected through GitHub Marketplace; no direct checkout is active.
Source: /legal/subprocessors.
3. Data retention
How long is customer data retained?
| Object | Retention |
|---|---|
| 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 for 30 days, then pruned. |
| Advisory history (append-only) | 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 are 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: /trust § 2.
4. Subprocessors
Who else processes customer data?
| Vendor | Purpose | Region |
|---|---|---|
| GitHub | GitHub App platform; OAuth sign-in (opaque user ID) | Global (GitHub) |
| Managed cloud hosting | Compute and managed database hosting for Core and the platform | US |
No third-party analytics or advertising SDKs are wired into the platform. Material changes to the subprocessor list are 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).
Source: /legal/subprocessors.
5. Encryption — at rest and in transit
How is customer data protected on the wire and in storage?
- In transit. Traffic to the Veripsa platform, 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 during early access; there is no active checkout or card collection.
6. Authentication & access control
How do users sign in? What identity does the vendor 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 permissions needed to read repository structure and post checks and comments on PRs. You choose which repositories the App can access, and you can change that scope or uninstall at any time.
7. Incident response
What is the incident-response process? Where are post-mortems?
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 for more than five minutes are published on the public incident log with a written incident note.
Example incident note on record: 2026-06-25 schema-drift — what happened, the affected scope, and the follow-up controls.
Source: /incidents, /security/disclosure.
8. Service-level agreement (SLA)
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. Production runs on managed infrastructure with health-gated rollouts and managed database backups; we operate it on a best-effort basis and aim for high availability of the dashboard and the GitHub App check runs.
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). Public operational metrics are at /metrics.
For an Enterprise plan with a contractual SLA and a dedicated escalation path, email support@veripsa.com.
Source: /trust § 5.
9. Compliance posture
What certifications and attestations does the vendor hold?
Current status: today, Veripsa does not hold the following — and 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 during early access, 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.
- 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 — and a public list of what is explicitly not in use.
- 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: /trust § 9.
10. Right to erasure
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.
- Billing data. There is no active direct billing store during early access. Future paid billing is expected through GitHub Marketplace.