Your data
So here is exactly where those records live, who can reach them, and what we have not got in place yet. Every number below was measured, not estimated.
Measured against the production database on 26 August 2026.
These are properties of how the system is built, not settings someone has to remember to switch on. That is why they hold on every page rather than the ones we thought of.
Every table has row-level security switched on, without exception, and the database checks it on every single read and write. Our application code never filters by organisation at all — which means a query that forgets to scope returns nothing, rather than returning somebody else's participants.
The anonymous database role has no permission on any table. Even if one of the tenancy rules were written wrongly, an unauthenticated request still could not try — the permission it would need to attempt the read does not exist.
Files sit in a private bucket whose rules match on your organisation's own folder, so a document is protected by the same boundary as a database row. When someone downloads one, the link is signed and stops working after 60 seconds.
Clinical, compliance and financial changes are written to the trail by the database itself, and each entry carries a fingerprint of the one before it. Edit or delete an entry and the chain visibly breaks — and anyone can walk it end to end to check. Not even the account that owns the table can rewrite an entry.
Where a change touches personal information, the trail stores which field changed and a fingerprint of the value, never the value itself. So it can prove what happened and who did it without becoming a second copy of the very data it is there to protect.
Every check asks whether this person may do this specific thing to this specific kind of record. Nothing anywhere in the system decides based on what someone's role is called. That is why you can invent your own roles without us writing code, and why a role you made is enforced exactly as strictly as one we shipped.
Sign-in supports an authenticator app. The operations that could affect more than one organisation are gated on a session that has genuinely completed that second step, so knowing a password is not enough to reach them.
The database runs in Sydney and so do the servers that answer your requests. Most vendors quote you the storage location and go quiet about where the processing happens. Both of ours are here.
Typefaces are served from our own servers, and the browser is not permitted to fetch a font, script or stylesheet from anywhere else. There is no third-party network in the path between you and your records.
Only the public address and a publishable key ever reach your browser. The key that could bypass all of the above exists in no code that runs anywhere near a request.
Every vendor has a list like this and most keep it to themselves. You would find both of these out on the first procurement call anyway, so you may as well read them here. If there is something else you need to know before you can sign anything, ask us directly.
No SOC 2, no ISO 27001, no IRAP. Everything above is real and you can hold us to it, but no outside body has been through it. We would rather tell you that than say we are “aligned with” a standard we have never been assessed against.
Not because nothing sits behind it — the platform runs on managed Australian infrastructure with the same operators most of this sector is built on — but because a percentage with no operating history behind it is a guess wearing a suit. We would be quoting you somebody else's reliability as though it were ours, and it is our code that would break first. Ask how we are actually going and we will tell you the real number.
Email security@careop.com.au with enough detail for us to reproduce it. We will acknowledge it, and we will not pursue anyone who reports a genuine finding in good faith.
If you are working through a procurement questionnaire and need something that is not here, ask — the downloads page has the documents we can hand over today.