Security
Last updated: 2026-07-10
Mobilize handles the information fire districts trust us with — personnel rosters, contact details, apparatus, and mobilization records — and we built the platform around a simple idea: security and public accountability are features, not paperwork. We designed for them from the first line of code, because retrofitting trust doesn't work.
Mobilize is passwordless. Your personnel sign in with your district's existing Microsoft or Google accounts, or with single-use secure email links. There is no Mobilize password to phish, reuse, leak, or crack — and when you sign in through your district's own identity provider, your MFA and access policies come with it automatically.
There is no public signup. Only people your coordinators have placed on the roster can sign in at all — everyone else is turned away before they reach any data. Access to your data is a function of your roster, full stop.
Every meaningful change in Mobilize — every sign-in, every record edit, every export, every administrative action — is written to a tamper-evident, append-only audit log that can be cryptographically verified. Even we can't quietly rewrite history. When a rotation assignment is disputed or a records request arrives, the answer is on the record, not in someone's memory.
Your agency answers to RCW 42.56 — so Mobilize does too. Every field in our data model is classified for disclosure (public vs. exempt) and every record carries a retention class aligned to records schedules, from day one. Records-request support isn't an add-on we'll get to; it's in the schema.
All data is encrypted in transit and at rest: TLS on every connection (including between our application and the database), and full-database encryption under keys we manage in our own cloud account with automatic rotation. Data lives in the AWS US-West (Oregon) region, and backups stay there too.
Mobilize runs serverless on AWS — no fleet of aging servers to patch, no maintenance-window downtime baked into deploys. The database runs in a private network with multi-availability-zone failover and 30 days of point-in-time recovery, behind AWS's web application firewall and edge network. Our entire infrastructure is defined in version-controlled code, which means every security setting is reviewable, reproducible, and impossible to quietly drift.
Production deployments are cryptographically signed and verified — our cloud provider refuses to run an artifact that wasn't produced by our pipeline. Dependencies are automatically audited and updated, and our build pipeline uses short-lived federated credentials instead of stored cloud keys.
Personal information is scrubbed from logs and telemetry before it leaves the application, error reporting runs with PII collection disabled, and SMS/email providers see only what's needed to deliver a message. Our full sub-processor list — every third party involved in running Mobilize, and their own security attestations — is published and version-controlled.
Mobilize exists for the worst weeks of the year. The platform is built to be quiet in the off-season and dependable during a mobilization: multi-AZ database failover, edge caching, SMS as a first-class channel so a page reaches crews even where data coverage doesn't, and a public status page you can check anytime.
We're a young company, and we'd rather show you exactly where we are than hand you a glossy PDF that overstates it — we've read plenty of those from the other side of the table.
In place today: every security control above — verifiable in code, and we're happy to walk your technical reviewer through any of it.
On the road ahead, in order:
Before production customer data, with results available to customers.
We'll publish RPO/RTO numbers after we've run the timed restore drills to back them, not before.
Attestation as we grow into it — our stack was chosen so certification is process work, not re-architecture.
Questions, or want the detailed technical version? We'll answer your security questionnaire in writing — ask us the hard ones.