Security
PetGrid runs every practice on shared infrastructure. That only works if the wall between them is real, so here is exactly where it is and what holds it up.
How the wall works
Application code that forgets to filter by practice is the usual way this goes wrong, so the check does not live in application code.
The database refuses, not the code
Every clinical and billing table carries the practice it belongs to, and Postgres row-level security is enabled and forced on all of them. A query that arrives without a practice context returns nothing. Not a partial result: nothing.
The connection cannot opt out
The role the apps connect as cannot bypass those policies. That is a property of the role itself, so no query written later can opt out of it, deliberately or by mistake.
Writes are checked the same way
A write aimed at another practice is rejected by the policy rather than silently accepted, so a bug cannot quietly file a record under the wrong clinic.
What PetGrid does not hold
Card details
There is no card number, expiry or security code anywhere in the schema, because PetGrid does not take card payments. Invoicing records what your practice was paid and how.
Your records as training data
Records belonging to one practice are never used to train anything, and are never pooled with another practice's.
An open front door
Pet owners reach your practice through an invitation your team sends. There is no open signup that lands a stranger inside your client list.
Consent
Every pet has an AI permission setting its owner controls, and a practice has one of its own above it. Both exist today. No AI feature is built yet. The controls are there first so that nothing can be switched on over anyone’s head later.
Being straight with you
PetGrid is early and has no customers yet. You will hear this from us before you hear it from a security questionnaire.
If any of these is the thing standing between you and a pilot, say so on the call and we will tell you honestly whether it is weeks away or not on the map.