Security
August 31, 2026
Bushfire.io is operated by Disaster Science Pty Ltd. We run our own infrastructure, and we secure it the way an operator does rather than the way a checklist does. This page sets out what is actually in place, and what we don’t yet hold, so most security reviews can be completed without a questionnaire.
How to use this page
This page is our self-attestation, and most security reviews can be completed from it directly. If your process requires a completed template, the fastest path is to complete it from this page; we are glad to review the finished document.
Table of Contents
Controls in place
| Area | Status | What that means here |
|---|---|---|
| Multi-factor authentication | Enforced | Required on every account, with a managed compliant device as a second condition. Privileged access uses phishing-resistant FIDO2 hardware keys. |
| Zero Trust access | Enforced | All access to production is brokered with device posture checks. There is no network path that bypasses it. |
| Network exposure | Minimal | No management or administrative interfaces are directly reachable from the internet. Application traffic arrives through a filtered and monitored edge. |
| Encryption | In place | TLS 1.3 externally and mutual TLS between services. Encrypted storage for platform data, encrypted off-site backups, full-disk encryption on every endpoint. |
| Endpoint management | Managed | Every device centrally managed and continuously assessed for compliance, with endpoint detection and response and hardening policies enforced in blocking mode. |
| Vulnerability management | Continuous | Dependency and container scanning block merges; weekly scheduled audits; continuous endpoint assessment. Critical findings block the pipeline on detection. |
| Change control | Enforced | Protected branches, signed commits, required security checks. Nothing reaches production outside version control and automated deployment. |
| Logging and monitoring | Centralised | Telemetry aggregated on our own platform, with continuous monitoring for unexpected exposure and alerting to a continuously watched channel. |
| Incident response | Documented | Severity classification, notification matrix and defined timeframes. Rehearsed against real events. |
| Backup and recovery | Proven | Multi-region with automatic failover and encrypted off-site backups. Recovery demonstrated under real failure. |
| Email security | Enforced | SPF, DKIM and DMARC at quarantine on operational domains; DNSSEC across all zones; pre-delivery filtering of malicious mail. |
| Supplier governance | Registered | Maintained supplier register with jurisdiction, data reach and published assurance recorded. Suppliers sourced from Five Eyes jurisdictions. |
Certification and assurance
| Item | Status | Position |
|---|---|---|
| ISO/IEC 27001 | In progress | Policy set, risk register, control documentation and evidence records in place. Not yet certified, and we won’t commit to a date we can’t hold. |
| Penetration test | Not held | No current third-party test, so no executive summary to share. A scoped engagement is the next planned step, and we are open to a customer sponsoring one. |
| SOC 2 | Not held | Not planned. ISO 27001 is the path we’ve chosen for an Australian customer base. |
What we lack is external attestation, not the controls it would attest to. In a business this size the binding constraint is engineering hours, not dollars, and we spend ours on the platform.
What we are
Disaster Science is an Australian company operating Bushfire.io, a hazard information and alerting platform used across web, iOS and Android. We are a small, owner-operated engineering business, and that shapes the architecture in ways that work in your favour.
Platform capability is built and run in-house by default. Compute, virtualisation, orchestration, service mesh, secrets management, logging and search all run on hardware we own, in Australian colocation facilities. There is no public cloud tenancy holding platform data, no sprawl of managed services to inventory, and a supplier list short enough to fit on one page.
How we run it
Access
Every account requires multi-factor authentication and an enrolled, centrally managed device that is continuously assessed for compliance, so a stolen credential on its own is not sufficient to reach anything. Privileged and development access additionally requires a phishing-resistant hardware security key. Administrative access to infrastructure is brokered through a Zero Trust layer that re-checks device posture, and there is no route that bypasses it.
Infrastructure
Immutable infrastructure managed as code: components are replaced rather than patched in place, so configuration drift has nowhere to accumulate and every change is reproducible from source. No management or administrative interfaces are directly reachable from the internet. Application traffic passes through a filtered edge with a managed rule set and denial-of-service protection active. Service-to-service traffic is mutually authenticated and encrypted, and hosts are continuously monitored for exposure that shouldn’t be there.
Software supply chain
Protected branches with signed commits, linear history and required status checks. Dependency advisory checking and container image scanning run on every pull request and every push, backed by a weekly scheduled audit of all dependencies and production images. Critical findings block the merge rather than raising a ticket someone closes later. Images are minimal builds from a base we curate ourselves and run unprivileged.
Endpoints
Every company device is centrally enrolled under per-platform compliance policy: disk encryption, host firewall, minimum operating system version, screen lock and malware protection are conditions of access, not suggestions. Endpoint detection and response runs in blocking mode rather than detect-only, with hardening policies that constrain what can run and hardware-backed protection for credentials.
Monitoring and response
Application and infrastructure telemetry is aggregated on a platform we operate ourselves. Alerting covers critical system state rather than service availability alone, and delivers to a continuously watched channel. Security detection on the corporate estate applies vendor threat intelligence continuously, and advisory feeds are wired into the build pipeline so new findings change what ships rather than waiting for a review cycle. Incidents follow a documented Incident Response Plan with severity classification, a notification matrix and defined timeframes.
Resilience
Multi-region with automatic failover and a defined degraded single-site mode. Encrypted off-site backups. Recovery has been demonstrated under real failure conditions rather than only in exercise, which is a stronger position than a tested restore plan, and we would rather have earned it that way.
Data and privacy
We are a ‘small business operator’ within the meaning of the Privacy Act 1988 (Cth). Even where the Act’s requirements do not strictly apply to us, we align our privacy practices with the Australian Privacy Principles, and we maintain a data inventory and record of processing activities built from an audit of the codebase rather than from recollection.
By design we hold considerably less than you might expect. No passwords are stored; authentication is delegated or uses one-time codes. No payment card data reaches our systems. No health or other sensitive information is collected. Live device location is processed on the device and never transmitted to our API. We do not sell personal information and third-party advertising networks are not integrated into our platform.
Infrastructure sits in Australia and Canada, with requests served from the nearest region. Suppliers are sourced from Five Eyes jurisdictions and recorded in a maintained register with their jurisdiction, data reach and published assurance. Our Privacy Policy covers collection, use and disclosure in detail.
Reporting a vulnerability
If you believe you have found a security issue in Bushfire.io or our infrastructure, tell us at [email protected], and thank you. We welcome good-faith research and will not pursue legal action against anyone acting in good faith under this policy. We will acknowledge your report within 14 days, usually much faster, and keep you informed through to resolution.
When testing, please do not degrade the service, access or modify data that is not yours, or use social engineering against our team; people rely on this platform during emergencies. If you encounter personal information, stop and include only what is needed to demonstrate the issue. We ask for a reasonable window to remediate before public disclosure, and we are glad to credit you if you would like it.
Common questions
Do you hold our data?
Only what you choose to give us. For most users and business users that is a name, an email address, sometimes a phone number, and the locations you choose to receive alerts about; this is collected on an opt-in basis and is what makes accounts and notifications work. If your organisation integrates through our public APIs instead, we hold nothing of yours beyond the access logs your own requests generate. If your use case involves us holding anything more, tell us and we will document exactly what, where and for how long.
Where is data held?
On infrastructure we own and operate: Australian colocation facilities, plus a Canadian node. Requests are served from the region nearest the user, so Australian traffic is served from Australia. Our core data store replicates between regions, so platform data is resident in both. Facility detail is available under a supplier assessment.
You have no ISO 27001 or SOC 2. Should that concern us?
It should inform your assessment rather than end it. Certification demonstrates that an auditor has verified a management system; it does not by itself mean stronger controls. Everything listed above is in place and verifiable today.
It is worth being direct about the trade-off. For a business our size, ISO 27001 runs to roughly twenty to fifty thousand dollars in the first year once certification-body audit and readiness support are counted, and recurs annually through surveillance audits. That buys verification, not security.
The larger cost is not the invoice. It is engineering time. The hours that go into audit preparation, evidence packaging and surveillance are the same hours that would otherwise go into hardening the platform, and on a team this small there is no slack to absorb them. We have consistently chosen the platform, which is why several of the controls above go beyond what certification would actually require of us.
We are working toward ISO 27001 regardless, because customers reasonably want independent verification and because the underlying work is already done. If certification is a firm requirement for your organisation to proceed, we are open to discussing it as part of the commercial arrangement; sponsorship that covers implementation support is what makes a timeline realistic, and it is a conversation we are glad to have.
Can we see a penetration test report?
No; we have no current third-party test, and we would rather say so than send you something stale. A scoped engagement covering application authorisation, access configuration and the build pipeline is the planned next step. If a test report is important to your assessment, we are open to a customer sponsoring one.
Who has access to production?
Access is limited to a very small operating team, and at that size segregation of duties is not achievable; we do not claim it. The compensating controls are real ones: every production change flows through version control and automated deployment with signed commits, leaving a complete and independently reviewable audit trail, and all access requires hardware-backed authentication from a managed, compliant device.
What happens if you have a breach?
Our Incident Response Plan defines classification, containment and a notification matrix with fixed timeframes for affected customers and partners. Where personal information is involved we will notify affected individuals and the Office of the Australian Information Commissioner, applying the triggers and timeframes of the Notifiable Data Breaches scheme as our standard.
Which third parties are involved?
A short list, kept short deliberately: content delivery and security, error diagnostics, push notification delivery, mapping and search, SMS delivery, and payment processing. Some are located overseas, primarily in the United States; SMS is delivered through Australian carriers by default. Details are in our Privacy Policy.
Will you complete our security questionnaire?
Generally, no. This page is our self-attestation, and it is written so that most questionnaires can be answered from it directly. If your process requires a completed template, the fastest path is for your team to complete it from this page; we are glad to review the finished document and confirm or correct its answers.
Where we are genuinely progressing toward an agreement, we will support your review with some light-touch work. Beyond that, completing or authoring documentation to your template is scoped work at cost recovery. It is a small team, and that time comes out of engineering.
Documents and contact
- Privacy policy: disasterscience.co/privacy
- Terms of service: disasterscience.co/terms
- Security contact: [email protected]
- Privacy contact: [email protected]
- security.txt: /.well-known/security.txt