Trust

Security and data protection

Written for whoever fills in the vendor questionnaire. It is organised the way those forms are — access, isolation, payments, sub-processors, incidents — and it says plainly where an answer does not exist yet.

Last updated 26 August 2026

Who can get in

Resident sign-in

Passwordless. A resident receives a single-use sign-in link at the email address on file. We never set, store, or reset a password, so there is no password database to breach and no reused password to inherit from somewhere else.

Staff sign-in

The same mechanism, with an explicit administrative role attached to the account. Access to a department’s data requires both a valid session and a role naming that department.

Authorisation model

Role and department are carried as signed claims on the session token and checked on every request. There is no “admin” flag a client can set and no shared department login.

Removing access

A department administrator’s access is revoked by removing the role from their account; the change takes effect on their next request. Departure of a staff member does not require a password rotation, because there is no shared secret.

How departments are kept apart

One system serves every department, which is what makes it affordable for a township of nine hundred people. Isolation is therefore the thing to get right, and it is enforced in two independent places rather than one.

The database denies all client reads and writes by default. Nothing is readable because it was forgotten; it is readable only because a rule names it.

All writes go through the server, which validates the shape of every record against a schema before it is stored, and checks the caller’s department against the record’s department.

A department administrator can read and write their own department’s records and nothing else. There is no cross-department view outside our own support access.

Our access to your data

Support access is a named role on a named account, used to operate and troubleshoot the service. It is not shared and not anonymous.

Vendor access to your data

Our support access uses named individual accounts holding an explicit elevated role — never a shared login, and never anonymous. A department-reviewable log of what a support account looked at is not yet available; we would rather say that than imply an audit trail we cannot produce.

Where the data lives

Infrastructure

Google Cloud. Data is encrypted in transit over TLS, and Google Cloud encrypts stored data at rest by default.

Hosting region

Permit records and resident accounts are stored in Google Cloud’s Canadian region in Montréal (northamerica-northeast1). Stripe, Twilio and Resend each process their own slice in the United States; §5 says which is which rather than burying it.

For United States departments

Canadian storage is worth knowing about before you ask. Most US fire departments have no residency requirement for permit records, but some states and some grant conditions do, and a few purchasing policies ask the question outright. If in-country storage is a requirement for you, say so early — it is a hosting decision rather than a redesign, and we would rather resolve it in week one than in the security review.

Backups

Point-in-time recovery is enabled, giving a rolling seven-day window from which the database can be restored to any moment. On top of that, a full export is written to Cloud Storage daily and kept for thirty days.

Availability

We run to a 99.5% availability target. That is an operating goal, not a contractual service level with credits attached — at this contract value we would rather state the target we actually hold to than sell a remedy.

Payments

Permit fees are taken by card through Stripe and settle to the department’s own bank account. This matters to a treasurer for a reason that is not obvious: the cash handling, the float, and the reconciliation risk all leave the fire hall with it.

Card details are entered into fields hosted by Stripe and never reach our systems. We receive the outcome of the payment and a reference, nothing more.

Because no card data touches our infrastructure, the PCI DSS obligation sits with Stripe, a Level 1 service provider, and our scope is limited to using their hosted fields correctly.

Refunds and chargebacks are handled through the same channel, so the audit trail stays in one place.

Sub-processors

The complete list of third parties that touch data on our behalf. It is short on purpose, and it is the same list published in the privacy policy.

Google Cloud — hosting, database, authentication.

Stripe — payment processing.

Twilio — text messages, including burn-ban alerts.

Resend — transactional email.

Google Maps — map display. Environment and Climate Change Canada and OpenWeatherMap supply weather and air-quality data; those we only read from, and no resident information is sent to them.

Notice of change

This page is the notice mechanism: the list above is kept current, and it is the same list published in the privacy notice. There is no separate per-department notification before a sub-processor is added.

If something goes wrong

Two obligations run in parallel here, and they are worth separating because they land on different desks.

Ours, under PIPEDA: where a breach creates a real risk of significant harm, we notify affected individuals and the Office of the Privacy Commissioner of Canada.

Yours, under whichever law governs your records. In Ontario, MFIPPA as amended requires municipal institutions to notify the Information and Privacy Commissioner and affected individuals of certain privacy breaches from 1 January 2027, with annual statistics from 2028. In the United States, every state has a breach notification statute with its own trigger and its own clock, and most give you days rather than weeks. Either way you cannot meet the deadline unless we tell you first.

So the commitment that matters is not that we will never have an incident. It is that we will tell your department about one in time for you to meet your own deadline.

Notification window

Within 24 hours of becoming aware of a breach affecting your department’s data, in the agreement rather than as a courtesy. Your clock to the IPC starts whether or not we are quick, so ours has to be shorter than yours.

Reporting a vulnerability

Email info@firepermit.online with the details. We will confirm receipt, and we will not pursue anyone who reports a problem in good faith and does not access data that is not theirs.

Penetration testing

No third-party penetration test has been performed. We would rather tell you that than let the row go blank — read it against the architecture above: no client can write to the database, there is no password store, and card data never reaches us.

Independent certification

We hold none. Google Cloud holds SOC 2 and ISO 27001 for the platform underneath us, which is worth knowing but is not our certification and we will not present it as one.

Support

Hours

Weekdays, 9am to 5pm Eastern.

Channels

Email to info@firepermit.online, and phone — we will give your department a number to call rather than publish one here. A person answers; there is no ticket portal to argue with.

Onboarding

Setup, configuration to your by-law, and staff training are included rather than billed as professional services.

What we do with the data, and what we do not

“Do you use our data for AI?” is four questions wearing one label, and answering it as one is how a vendor ends up either frightening you or quietly reserving something. So they are separated here.

Personal information and models

Resident personal information is never used to develop or train machine-learning models, ours or anyone else’s, and is never sent to a third-party model or AI provider. There is no such provider in our system to send it to.

Selling or sharing

We do not sell personal information and we do not share it with advertisers.

Automated decisions

No decision about a person is made automatically. A permit is issued under the rules in your own by-law, or by a member of your staff. Nothing scores, ranks or profiles a resident.

Aggregate statistics

We do produce aggregate statistics across departments — the kind that let a chief say how their program compares with towns of similar size. Your department is included by default, this is set out in the agreement rather than buried, and you can withdraw at any time by telling us.

What “aggregate” means here, in numbers rather than adjectives: no published figure draws on fewer than five departments or fewer than ten permit records; nothing is published at a finer granularity than municipality and calendar month; and no address, coordinate, name or contact detail is part of an aggregate in any form. “Anonymised” on its own is a word, not a safeguard — a permit is an address and a date, and in a township of nine hundred people that is not anonymous however you label it.

Incident and SIR records

Not covered by any of the above. Incident records are a different class of sensitivity and are not part of the aggregate arrangement; if that ever changes it will be a separate conversation with a separate agreement, not an extension of this one.

Something here not answered?

Send the questionnaire, the by-law, or the question. A person answers it — we would rather write the answer down once than have you guess at it.

info@firepermit.online · Procurement pack