Security at On-Scene

Most applications decide who may see what in application code, then trust that code to ask the database the right question. A bug in that code is a data breach.

On-Scene does it the other way around. Every table in the database is protected by PostgreSQL row-level security, default-deny: unless a policy explicitly permits a row, it does not exist for that caller. A new table with no policy is unreachable, and stays unreachable until someone writes one. The application cannot ask a question that returns data it should not have, because the database will not answer it.

That is also why our web administration console is read-only for the fireground record — not because we hide the buttons, but because the database refuses the writes. Only an appliance holding command may edit a tactical picture, and a human account is never an appliance.

Every agency shares one database, separated by row-level security. That is a deliberate choice, and it puts an obligation on us: we have to prove the separation rather than assert it.

So we test it, automatically, on every change. A suite of around 970 database-level assertions signs in as each kind of user — a truck at one station, a truck at another, an administrator at a different agency, an unauthenticated stranger — and checks what each of them can actually read and write through the real security policies. Cross-agency reads fail. Cross-station reads fail. Unauthenticated reads fail at the privilege layer, before a policy is even consulted. If any of those assertions stops holding, the build stops.

We think an automated proof that runs on every change is a stronger assurance artefact than separate databases asserted in a document — and if an agency’s procurement requires a dedicated instance anyway, our architecture supports one without a separate build of the app.

The incident timeline, the command history and the command acknowledgements are append-only. Not by convention, and not by an application rule that a future feature could forget: no client of any kind holds the database privilege to update or delete those rows. A request to change them fails at the permission layer.

Everything else is soft-deleted. Removing a symbol from the tactical map marks it removed and writes a timeline entry in the same transaction; it does not erase it. Changing an incident’s address goes through a function that records the change. Once a radio message is sent, its text is frozen.

Administrative changes — memberships, rostering, licensing, appliances — are captured with their before and after state and the person who made them, written by a database trigger that no client can bypass or suppress. The record of what somebody did outlives their account.

The timestamps that decide who holds command are generated by the server, not sent by the device, because a wrong clock — or a deliberate one — must not be able to reorder the record of who arrived first.

Your incident data is stored and processed in Sydney, in AWS’s ap-southeast-2 region, on Supabase’s platform. It is encrypted at rest with AES-256 and in transit with TLS.

Nothing else receives your incident data. We run no analytics, no crash-reporting service, no attribution or advertising SDK, and no customer-support widget. There is no third-party script in the tablet app at all. This is unusual, and it is deliberate.

The same is true of this website. It sets no cookie, loads no font, script or image from anywhere else, and its content security policy names no external origin at all.

The one third party the app talks to is our map provider, which serves the basemap. It receives the map tiles the app asks for — which reveals roughly where a crew is looking — and nothing else. No address, no casualty information, no crew names, no tactical data. We are switching off the map SDK’s optional usage telemetry entirely.

We publish our full sub-processor list — every third party that could touch your data, what it sees, and where it is hosted — in the evidence pack.

The tablet in a fire appliance is signed in as the appliance, not as a person. A retained crew responding to a structure fire does not have time for a login screen, and a security control that gets defeated in practice is not a control. Who was actually on the truck is captured separately, by a one-tap crew sign-on when the incident starts, and by the command request-and-acknowledge protocol that every tablet takes part in.

Because every access decision is made from live database state rather than from a token, taking access away is immediate. Revoke a person’s membership, retire an appliance, or suspend a station’s licence, and their next request — the next statement, not the next login — returns nothing. There is no window in which a revoked user keeps working.

A tablet signed in as an appliance can see its own station’s incidents and any incident it has been invited to. There is no “nearby incidents” view, and there never will be: a station cannot discover another station’s jobs, and cannot opt itself in to somebody else’s fireground. Mutual aid happens because an incident controller calls a truck in.

Administrator accounts on the web console use individual logins with multi-factor authentication. Passwords are a minimum of twelve characters with complexity requirements, hashed by our authentication platform and never stored or logged in plain text, with rate limiting on sign-in attempts.

No credential that can bypass our security policies exists in any app, any browser bundle, or any hosting environment. The elevated database key lives in our secrets store and is used by nothing today.

You own your incident records. We do not sell, share, or mine them, and we do not use them to train anything.

You can export your incident records at any time in an open, standard format, including a human-readable record of each incident suitable for an investigation or an inquest. A finished incident exports as a PDF report written to be read, and a zip archive of the same incident as structured data with that report inside it.

Every export is itself recorded. The register of who exported what, and when, is append-only — no client holds the privilege to change or remove a row in it — and the register entry is written before any data leaves the system, so an export that cannot be recorded does not happen.

We think this section matters more than the rest of the page.

On-Scene holds no security certification. We are not ISO 27001 certified, we are not SOC 2 audited, and we have not completed an IRAP assessment. Our hosting platform holds SOC 2 Type II and ISO 27001 certification for the infrastructure layer — those are its attestations, covering the database and hosting platform, and they do not cover our application.

We have not had an independent penetration test. We will say so, in writing, in any procurement response, and we would rather lose a deal than imply otherwise.

We are two people. That means fast fixes and a short line to the person who wrote the code. It also means we do not have separation of duties, a 24/7 security operations centre, or a compliance team, and we do not pretend to.

We publish this list because a supplier who claims everything is a supplier you cannot verify.

If you believe you have found a security issue in On-Scene, please tell us. We will acknowledge your report within two business days and keep you updated until it is resolved.

Write to security@onscenecommand.com.au. Our disclosure policy and machine-readable contact details are at /.well-known/security.txt and in SECURITY.md in our repository.

We do not currently run a paid bug bounty. We will credit researchers who ask to be credited, and we will not pursue anyone who reports a genuine issue in good faith and gives us a reasonable chance to fix it.

On-Scene handles personal information, and some of it is health information about people involved in emergencies. We operate under the Australian Privacy Principles and treat the Privacy Act 1988 as applying to us in full.

Our data breach response process follows the Notifiable Data Breaches scheme: we assess a suspected breach without delay and within 30 days at the outside, and we notify the Office of the Australian Information Commissioner and affected individuals where a breach is likely to result in serious harm. Because our customers are agencies, we notify the agency at the same time — usually sooner.