Trust

Our operational posture, read live from the same database that runs the product - not a status page we edit by hand. Below that: our own progress running a real vendor-risk program on Vetrail.

Two layers protect the database, and every number above is one we've measured, not estimated. The 1-hour RPO is our own independent copy - an hourly pg_dump to Cloudflare R2, integrity-checked before upload and again before any restore, reported live to operators at /backupz, kept for 90 days - well beyond Render's own point-in-time recovery, which covers the last 3 days on our current plan but restores to an exact moment rather than the nearest hourly dump. Two different strengths, not one better than the other: PITR for precision within its window, the R2 copy for anything noticed after it. The RTO is a measured result, not a target: a live drill on 2 Sep 2026 - dump, wipe every table, restore - completed in 1.3 seconds against our current dataset. We re-run it as data grows rather than let an old number quietly stop being true. Detection is automated too: a watchdog pages the team the moment an outage is confirmed - two consecutive failed checks, 15 seconds apart - rather than waiting for someone to notice, and pages again when the database is reachable again. What's left after that is deliberately not automatic: initiating the actual restore is a human decision, because an automatic restore triggered by a false alarm would destroy real data to "fix" a problem that may have already resolved itself.

Data handling

In transit: every connection is TLS, enforced at the edge - there is no plain-HTTP path to the app or to emailed links. At rest: database backups live in Cloudflare R2, which encrypts every stored object by default with AES-256-GCM, using keys Cloudflare manages - this is R2's own baseline behavior, not something we configure per customer, so it applies uniformly.

Data residency is the one open item here: the backup bucket uses R2's automatic placement, which picks the nearest available region to each request rather than pinning one - fast, but not a residency guarantee. Jurisdiction-pinned residency (EU residency for GDPR purposes, for example) isn't configured today - raise it and we'll scope it against what you actually need.

Subprocessors

Every third party that touches product data or its delivery, as of this writing:

This list changes rarely and only after review - we don't adopt a new subprocessor without checking its published security posture first. If it changes, this page is updated the same day; ask at any time for the current list rather than relying on memory of a past visit here.

Account security

Passwords are hashed, never stored or logged in plain text. Two-factor authentication (TOTP - the six-digit code from an authenticator app) is available to any account from Account settings, but it's opt-in, not yet enforced account- or org-wide - kept that way while a team is still building trust with the product, before asking for a second step on day one. Recovery codes are generated at setup and hashed the same way passwords are, so losing the recovery-code list doesn't hand anyone a working credential. Session cookies are marked Secure and HttpOnly, so they're never sent over plain HTTP or readable by page JavaScript. Every access to Vetrail's own admin tools (platform KPIs, backup status, incident management) is logged - who, which page, when - retained a year and pruned automatically.

Calendar subscriptions

Action items can be published to Google Calendar or Outlook as a read-only subscription. It is off unless someone turns it on, and each person turns it on for themselves. The address it issues carries an unguessable token and is the only credential involved - a calendar application cannot log in - so anyone holding that address can read the organization's action item titles, dates, status and owner names. It carries nothing else: no assessment answers, no evidence files, no vendor contact details, and no ability to write anything back. The product says this plainly on the page that hands out the address, and the address can be replaced or switched off at any time, taking effect on the next request.

Where it is switched on, a person can instead connect their own Google or Microsoft account directly, so deadlines update within fifteen minutes and reminders fire reliably. Vetrail then holds a token for that account, encrypted at rest, and uses it for one thing: a calendar Vetrail creates there, called "Vetrail action items". On Google it is granted access to that calendar only; Microsoft has no narrower permission, so the limit there is Vetrail's own code. Disconnecting deletes the calendar and the token, and removing someone from a workspace does the same for them - otherwise a departed member would keep a copy of the register in their own account.

Security policy and incident response

We have a written Information Security Policy and Incident Response Plan, both adopted as Version 1.0 on 28 Aug 2026. The incident response plan is not a document that sits unused: on the same day it was adopted, we ran a tabletop exercise against it, walking a hypothetical security incident step by step through the response plan to find gaps before a real one does. The exercise found five things worth fixing. We fixed what could be fixed directly in the plan itself, and logged the rest for follow-up rather than leaving them unaddressed.

Security awareness training is a stated program as of 1 Sep 2026: at least annual, for everyone with access to production systems or customer data - Ayo alone today, the same requirement extending to anyone added as the team grows.

Ayo Akintayo is the named individual accountable for security - see About. What's still open: no customer-notification commitment for a confirmed security incident has been approved for publication yet - draft language exists internally and is next in line for sign-off, and an internal process already sends an immediate reminder of that draft commitment the moment an incident is declared.

How the reminder ladder and escalation actually work

Default reminder rungs: 7 and 3 days before an assessment is due, on the due date, then 7 and 14 days after - five touches, then it stops chasing and hands off to a human rather than reading as spam to a vendor's security team. Timing is stored per organization, and any workspace owner can change the ladder from the Team page - a change applies immediately, including to assessments already being chased. Escalation - the one email a founder gets - fires on exactly three conditions: a vendor unresponsive through the full ladder, an assessment more than 30 days overdue regardless of ladder length, or a submitted assessment rated Critical or rated materially worse than that vendor's previous one. Nothing else emails you. A quiet month is the product working, not a bug.

How the risk register actually works

Five steps, always in the same order: identify a risk (from the library or written from scratch), rate its inherent likelihood and impact before any controls, record the controls actually in place today, rate the residual likelihood and impact left after those controls, then treat it - a solution, an acceptance, or a transfer, each tracked to a named owner and a target date. Same four-level rating language as the vendor side (Low/Medium/High/ Critical), so the two registers read as one system rather than two products glued together.

The library that seeds the "identify" step is exhaustive by design: every published risk factor is shown to every organization, always. An industry tag only decides which boxes arrive pre-checked when you browse it - it never hides a risk a mis-tag might have missed. A risk can carry more than one open action item at once, each independently advanced to in-progress or closed. Chasing you the way the vendor ladder does - a reminder when a review date passes or an action item's target date slips - is next up, not built yet.

What "trust" means here

The app version and backup status above are read live from the same database that runs the product - not maintained separately, so they can't drift from reality the way a hand-updated status page can. You can independently confirm the app is responding right now at /healthz, which returns the same version number. For uptime history over time rather than a single point-in-time check, see /status.

What's next

SOC 2/ISO 27001 certification and a third-party penetration test are both ahead of us, not yet true for a company this early. Two-factor authentication is available today but not yet required account- or org-wide, so a password-only account is still possible. A public API isn't built yet - CSV, PDF, and full-JSON export cover data portability in the meantime. Vendor and workspace deletion is on the same list; once it ships, this page states the real retention policy behind it, not one written ahead of the feature it describes.