Enforced by the database, not promised by the application
On a life-safety platform, security controls that live in application code are conventions, and conventions drift. WillowCreek pushes its hardest guarantees down to the storage layer, where a policy is refused rather than merely discouraged, and keeps an honest, tamper-evident record of everything that happens above it.
The site is the isolation boundary
Row-level policy, on every request
Isolation is enforced by database row-level policy per request, evaluated against a scope the server computes. The caller cannot supply its own scope, so a compromised or misbehaving client cannot widen what it sees. There is no code path that reads another site's rows and merely promises not to.
Cross-tenant isolation is verified on every promotion. A leak between tenants is a release-blocking defect, not a ticket.
How the site boundary shapes the platform →The database enforces the scope. The caller never gets to choose it.
Default-deny, extended by context
- Default-deny on every route. A route with no explicit policy is denied. Nothing is reachable because somebody forgot to protect it.
- Role-based access, extended by context. On-shift and on your own ward permits; out-of-hours or another ward denies. The same role does not mean the same access at 3am.
- Session revocation, effective next request. Revoking a session kills its live tokens on the very next request, not at the next expiry.
- TOTP step-up. Sensitive operations demand a second factor at the moment of the action, not just at login.
- SCIM lifecycle. Joiners, movers and leavers flow from your identity system. An account that shouldn't exist any more, doesn't.
The one exemption is enforced at the storage layer. Life-safety is never gated by access policy: a policy attempting to gate incident raising is refused by a database CHECK constraint. The exemption isn't a guideline for administrators to remember. The database will not store a configuration that violates it.
A record that can prove itself
Every audit trail claims to be complete. Ours is built so that tampering is detectable, exceptional access is visible while it happens, and even the provider operates in the open.
Tamper-evident by construction
A per-tenant SHA-256 hash chain, append-only, with signed checkpoints. Alter or remove a row and the chain breaks at that row. In testing, a privileged-operator tamper was detected and pinpointed to the exact row. The property is demonstrated, not theoretical.
Break-glass with a ceiling
Emergency access requires a written reason before it opens and carries a hard time ceiling enforced by the database. It cannot be quietly extended, and every action taken inside it lands on the audit chain.
Provider access in the open
When our support staff access your deployment, a persistent banner is on screen for the whole session and the access is audited twice, in your trail and in ours. You never discover a support session after the fact.
Legal hold by trigger
A legal hold is enforced by database trigger: records under hold cannot be deleted by any application path, including administrative ones. The hold does not depend on software above the database behaving well.
Your people's data, treated as the sensitive thing it is
A safety platform necessarily knows where people are. That is exactly why its privacy posture has to be deliberate, recorded and enforceable.
Protecting the data
- TLS everywhere. Every connection, internal and external.
- Per-tenant keys, rotated. Each tenant's data is encrypted under its own keys, with rotation and crypto-shred. Destroy the keys and the data is gone, provably.
- Field-level encryption for the most sensitive attributes, over and above encryption at rest.
- Backups that are proven, not hoped. Encrypted at rest with AES-256, physical rather than logical so the tamper-evident audit chain survives byte for byte, and the restore path exercised end to end, because a backup that has never been restored is a hope, not a backup.
Respecting the person
- A classification register records what each data class is and how it may be used. Purpose limitation is off by default. New uses are enabled deliberately, never assumed.
- Every PII access is audited. Looking is an event, and it lands on the chain like any other.
- Erasure, honestly handled. Where safety evidence stands behind a record, erasure is refused with a written reason, and the refusal itself is recorded and disclosable.
- DPIA as part of deployment, and data residency as a recorded, enforced provisioning parameter, not a deployment convention.
What never gets into the platform
Signed images, promoted by digest
Every release ships as signed, scanned container images promoted by digest. The exact artefact that passed assurance is the artefact that runs. Nothing is patched in place, so there is no drift between what was verified and what is deployed. How releases reach you →
No payment instrument, ever
Billing runs entirely outside the platform. No card number, no bank account, no stored payment token ever enters it, so a control-room compromise isn't a financial-data breach and your clinical safety review never has to cover a payments system. The commercial model →
Control expectations, stated honestly
ISO 27001, IRAP, Essential Eight and the Australian Privacy Principles are the control expectations the architecture is built to satisfy. We state it that way deliberately: a framework name on a website is not evidence. Certification status is provided per deployment, in writing, as part of your commercial documentation, where it can be checked, dated and held against us.
If a claim on this page matters to your assessment, ask us to demonstrate the mechanism behind it. Each one has a demonstration.
Honest state over plausible state
It's the principle behind everything on this page: a record that proves itself, a scope the caller cannot choose, a gap that shows as a gap. Bring your security assessor. We'd rather answer the hard questions early.