Security & Compliance
This page explains how StationOne handles the security and integrity of your data. We know that brigade management platforms hold information about real people and real operational assets, so we take a practical, best-practice approach even though we are not currently ISO 27001 or SOC 2 certified.
If you have a specific security question not covered here, contact us at support@stationone.com.au.
Data Residency
Section titled “Data Residency”All customer data is stored in Australia. This is a commitment, not a best-efforts policy.
| Data type | Location |
|---|---|
| Application database | DigitalOcean — AU-Southeast (Melbourne) |
| Database backups | AWS S3 — Asia Pacific (Melbourne) |
| File storage (photos, attachments) | AWS S3 — Asia Pacific (Melbourne) |
Production infrastructure is hosted in DigitalOcean’s Australian data centre. Backups are intentionally stored in a separate provider and region to the live application — if either provider experienced an outage, the other would remain unaffected.
What Personal Data We Store
Section titled “What Personal Data We Store”StationOne is designed to minimise the collection of personally identifiable information (PII). We collect only what is operationally necessary for running a brigade.
We store:
- Member names
- Email addresses — only for members who are granted platform access (email is optional for non-login members)
- Licence class (e.g. car, LR, MR) — we do not store licence numbers
- Qualifications and endorsements (operational, e.g. chainsaw competency)
- Availability (day/time preferences) — no location or GPS data is collected
We do not store: licence numbers, identity documents, financial details (payments are processed directly by Stripe and subject to their security standards), or location/GPS data.
Database Backups
Section titled “Database Backups”Automated backups run hourly and are retained for 30 days.
Backups are stored in AWS S3 (Melbourne region) — a separate provider from the live application hosted on DigitalOcean. This means a failure or incident affecting either provider does not compromise both the application and its backups simultaneously.
Backup integrity is verified as part of our routine maintenance. In the event of data loss, we can restore to any hourly snapshot within the 30-day window.
Disaster Recovery
Section titled “Disaster Recovery”StationOne maintains an internal recovery runbook covering full environment rebuild from the S3 backups.
| Metric | Target |
|---|---|
| Recovery Point Objective (RPO) | Up to 1 hour (maximum data loss in a worst-case failure between backup snapshots) |
| Recovery Time Objective (RTO) | Under 30 minutes from detection of failure to restored service |
In a full infrastructure failure scenario, the recovery process is:
- Provision a fresh server in DigitalOcean AU-Southeast
- Deploy the application from the current release
- Restore the most recent database snapshot from AWS S3 (Melbourne)
- Verify application health and restore DNS
Because application data and backups are on separate providers, a total loss of the primary hosting environment does not affect access to backup data.
Infrastructure Security
Section titled “Infrastructure Security”Hosting & Network
Section titled “Hosting & Network”- Production runs on DigitalOcean in the AU-Southeast (Melbourne) region
- All traffic is served over HTTPS/TLS via a Let’s Encrypt certificate with automatic renewal
- The application sits behind an Nginx reverse proxy — the application server is not directly exposed to the internet
- Direct access to the production database is restricted by IP allowlist — only authorised IP addresses can connect
- Access to production infrastructure requires SSH public/private key authentication — password-based SSH access is disabled
Secrets Management
Section titled “Secrets Management”Application secrets (API keys, database credentials, encryption keys) are stored and managed outside of version control. Access to application credentials requires a master authentication key (AES-256 Cipher), this is used to encrypt credentials at rest, credentials and the master authentication key are never committed to the repository.
Application Security
Section titled “Application Security”Authentication
Section titled “Authentication”- User accounts are authenticated via email and password using the industry standard authentication framework.
- Passwords are hashed using bcrypt — plaintext passwords are never stored
- Magic link (passwordless) login is available as an alternative
- Invitation-based onboarding means new accounts are created only in response to an explicit invitation from an existing brigade admin
Authorisation
Section titled “Authorisation”StationOne uses a strict policy-based authorisation system (RBAC). Every controller action checks whether the authenticated user has permission to perform that operation before any data is accessed or modified. Users cannot access data outside their assigned unit hierarchy — this is enforced at the application layer, not just the UI.
See Permissions Reference for the full model.
Multi-Tenancy Isolation
Section titled “Multi-Tenancy Isolation”StationOne is a multi-tenant platform. Each organisation’s data is scoped at the application layer — queries are automatically filtered to the current tenant, making cross-tenant data leakage a known and actively mitigated risk pattern.
Public Access Tokens
Section titled “Public Access Tokens”Some features (public inspection forms, station portals, vehicle QR codes) are accessible without a login via URL-safe random tokens. These tokens:
- Are cryptographically random (not predictable or sequential)
- Are scoped to a specific resource and brigade
- Can be regenerated by a brigade admin at any time, immediately invalidating the old token
- Enact a key exchange process to validate the request to the server, where only the server knows the decryption key.
Staff Access to Customer Data
Section titled “Staff Access to Customer Data”Our support team can access customer data in two ways:
- In-app impersonation — support staff can log in as any organisation to investigate issues, with the impersonation session clearly logged. This is the standard support path.
- Direct database access — restricted to the engineering team and accessible only from approved IP addresses. Used for diagnostics, debugging, data recovery, and running operational queries as required.
We do not access customer data without a support reason. Data access for support purposes is an accepted and disclosed practice under our Privacy Policy.
Security Scanning & Vulnerability Management
Section titled “Security Scanning & Vulnerability Management”We run automated security tooling as part of our development process.
All commits to the applications repository result in a action pipeline which includes various security and vulnerability scans. These process actively blocks application deployment to our production environment where issues are detected.
We follow a policy of applying security patches promptly, particularly for critical or high-severity vulnerabilities in application dependencies.
Compliance & Standards
Section titled “Compliance & Standards”Australian Privacy Act
Section titled “Australian Privacy Act”StationOne complies with the Australian Privacy Act 1988. Our Privacy Policy describes how we collect, use, and protect personal information.
Notifiable Data Breaches
Section titled “Notifiable Data Breaches”In the event of a data breach that is likely to result in serious harm to any individuals, we follow the Australian Notifiable Data Breaches (NDB) scheme obligations — including notifying affected individuals and the Office of the Australian Information Commissioner (OAIC) where required.
Insurance
Section titled “Insurance”StationOne carries appropriate business insurance including coverage relevant to our operation as a SaaS provider, these policies are held by FireHouse Labs Pty. Ltd. - developers and owners of the StationOne Platform.
Certifications
Section titled “Certifications”We are not currently ISO 27001 or SOC 2 certified. We implement security controls aligned with those frameworks where practical for a platform of our size and stage, and we are transparent about this posture. If certification is a hard requirement for your organisation, please contact us to discuss.
Payment Processing
Section titled “Payment Processing”StationOne does not store, process, or transmit payment card data. All subscription billing is handled by Stripe, a PCI DSS Level 1 certified payment processor — the highest level of certification available in the payments industry.
When subscribing, you are redirected to Stripe’s hosted payment portal to enter your payment details. StationOne’s servers never receive or store your card number, CVV, or expiry date — payment status is communicated back to StationOne via secure webhooks only.
Stripe’s security posture and compliance certifications are documented at stripe.com/docs/security.
Reporting a Security Issue
Section titled “Reporting a Security Issue”If you believe you have found a security vulnerability in StationOne, please report it responsibly by emailing support@stationone.com.au with a description of the issue. We ask that you do not publicly disclose vulnerabilities before we have had the opportunity to investigate and respond.
We aim to acknowledge security reports within 2 business days.
Questions
Section titled “Questions”For questions about data handling, privacy, or security practices, contact us at support@stationone.com.au or refer to our Privacy Policy.