Security Overview

Overview

PreStartGo is built to hold compliance-critical records — pre-start inspections, defects, bypass events — so the platform's own security posture matters as much as the checks it runs. This article is the single overview: tenant isolation, the audit trail, authentication, encryption, data residency, and where our certifications stand today. For a deeper look at what gets logged and how, see Understanding Audit Trails.

Tenant isolation

Every table in the database is scoped to an organisation ID. Cross-organisation access does not return another organisation's data — it returns a plain 404, the same response you would get for a record that does not exist. There is no code path that leaks a record across the organisation boundary by returning it with a permission error instead of hiding it entirely, which would itself confirm the record's existence to someone who should not know.

This is enforced at the query layer on every request, not as an after-the-fact filter on the response.

The audit trail

Every significant action in PreStartGo — inspections, unlock events, bypass events, defect transitions, service transitions, user and role changes, device events — is written to an append-only event log. Records can be inserted, never updated or deleted; the database itself rejects any attempt to alter or remove a row, so this isn't just an application-level convention.

On top of that, the audit trail is hash-chained: each organisation's monthly sequence of events is linked cryptographically, so any attempt to insert, delete, or reorder a historical entry breaks the chain. A scheduled job verifies every organisation's chain automatically each night, so tampering doesn't wait to be discovered during an audit — it's caught within 24 hours. See Understanding Audit Trails for what gets recorded and how PII is redacted from log entries.

Authentication and app attestation

Account Owner and Administrator accounts require multi-factor authentication — it is not optional for the roles that can change organisation settings, billing, or user access. Organisations can also turn on org-wide MFA enforcement for every user, not just those two roles.

Every request is also checked for app attestation, which confirms it actually came from a genuine PreStartGo client rather than a scripted or tampered one:

• Mobile app — Play Integrity on Android, App Attest on iOS.
• Web dashboard — reCAPTCHA Enterprise, invisible to the user.

Attestation runs alongside authentication, not instead of it — a valid login from a client that fails attestation is still rejected.

Encryption

• API and dashboard traffic — TLS 1.2+ in transit (1.3 negotiated where the client supports it); Cloud SQL encryption at rest.
• Mobile offline cache — AES-256-GCM at rest, with a hardware-keystore key.
• BLE commands to the Interlock — HMAC-SHA256 signed.

BLE commands between the mobile app and the Interlock are cryptographically signed so a device only accepts genuine, unaltered commands, matching the signing approach used across every other channel above.

Data residency

Your data is hosted in Australia (australia-southeast1), with daily backups held in Australia. If your organisation has a specific residency requirement, raise it with your account team.

Subprocessors

Third-party services that process data on PreStartGo's behalf, and where that processing happens. Some recipients are outside Australia; the data location column is the authoritative statement of where each one processes your data.

This table is generated from the same source the rest of the site uses, so it cannot drift from what we publish elsewhere. For the categories of personal information involved, see /legal/privacy.

Certification posture

• SOC 2 Type II — audit in progress.
• ISO 27001 — certification audit under way.
• Customer trust portal — a self-service home for security and compliance evidence, coming soon.
• Vulnerability disclosure — PreStartGo runs a public, RFC 9116-compliant disclosure programme with a Safe Harbor policy. See /legal/vulnerability-disclosure or /.well-known/security.txt.

Offline security

The field runs offline, and the security model runs with it: the mobile cache is encrypted at rest, every BLE command to an Interlock is individually signed and replay-protected, and the app enforces licences — including their expiry — locally, with no server in the loop. Signing keys for each machine are issued to a phone only after the platform's authorisation checks pass, and are held in the phone's secure storage. See Working Offline.

Troubleshooting