Where your data lives
- The application, database and uploaded files run on a server in Brisbane, Australia. Your asset data is not sent to third-party analytics or AI services.
- Outside services are limited to DNS and web proxying, and, as they are introduced, email delivery, error monitoring configured to send no customer data, and encrypted backup storage in Australia.
Customer isolation
- Every customer record belongs to one organisation. Queries are scoped to that organisation in the application, and PostgreSQL row-level security enforces it again in the database itself, using a database role that cannot bypass it.
- Uploaded files are stored in a separate folder per organisation, and file paths are checked on every access.
- The audit log is append-only: the application can add and read entries but cannot change or remove them.
- Automated tests attempt cross-organisation access through every page, download and upload path, both in the application and directly against the database.
Access control
- Password sign-in (Argon2 hashing, at least 12 characters) plus mandatory authenticator-app two-step sign-in for every user.
- Sign-in attempts are rate limited at the web server and locked per account and per address in the application. Sessions expire after 12 hours idle.
- Roles (owner, admin, analyst, viewer) are enforced on the server for every action.
- BurstSight staff have no access to your data through the application. Any direct access is by exception, needs a written reason, and is recorded on your audit log where your administrators can see it.
Handling of uploads and models
- Only CSV, Excel, GeoPackage and zipped shapefile uploads are accepted, checked by content as well as name, with a size limit and protection against decompression bombs. Files are read by background workers and never executed.
- Each model run is a separate process with a stripped-down environment (no database or secrets), a working folder of its own, and limits on memory, CPU time and run time. Models never touch the database.
- Every run records the model version, calibration, parameters and an input fingerprint, so results are reproducible.
Application and server hardening
- HTTPS only, with strict transport security, a Content-Security-Policy that forbids inline scripts and third-party sources, and other secure headers. Fonts, scripts and maps are self-hosted.
- Dependencies are pinned to exact versions and audited for known vulnerabilities on every change.
- Key-only SSH for a named administrative user, no root or password login, a firewall that allows only web and SSH traffic, brute-force protection, and automatic security updates. The database and cache are not reachable from the network.
Backups
Nightly encrypted backups of the database and stored files, with a retention schedule and a tested restore procedure.
Status
| Control | Status |
|---|---|
| Hosting in Australia, per-customer isolation, two-step sign-in, audit log | In place |
| Sandboxed model runs (separate process, no database access, resource limits) | In place |
| Offsite encrypted backup copies in Australian cloud storage | Being set up before customer go-live |
| Disk encryption at rest on the production host | Planned with the production host |
| Independent penetration test | Planned before the first paying customer |
| Single sign-on (Microsoft Entra ID) and API access | Planned |
| Model runs in isolated containers with no network | Planned |
| Formal certification | Controls are being aligned to the ASD Essential Eight and ISO 27001 Annex A; no certification is claimed |
Your data and exit
Your data remains yours. On termination or request it is deleted from live systems on a documented schedule and from backups as they expire. We will provide this in writing.
Reporting a problem
To report a security concern or vulnerability, email [email protected]. We will acknowledge it promptly and keep you informed.
Procurement teams: for the full document set (incident response, data processing terms, control mapping), contact us.