Security

Sign-in

• The first time you sign in, Fire-Bid emails a one-time link to the work address your department has on file. Opening it asks you to set a password, and that password is how you sign in from then on.
• If you forget it, Fire-Bid emails you a link to set a new one. That link is single-use and expires.
• Only an email address your department administrator has already put on file can be used to sign in. There is no self-registration.
• Pages that show personnel information require a valid session; signed-out visitors are redirected to the sign-in page.

Who Can Reach What

• Access rules are enforced in the database, not just the interface. Fire-Bid applies row-level access rules inside PostgreSQL. A request that asks for data the user should not have is refused at the data layer, whatever the interface did or did not show.
• Your own records stay yours. Regular accounts can read their own vacation selections, their own balance record, and their own eligibility calculations, not other people's. This is verified by direct testing against the database, not just by inspection.
• Administrator actions require an administrator. Every administrative operation re-checks the caller's role on the server before doing anything, so a request sent directly to the server by a non-administrator is rejected.
• Departments are separated. Department-owned records carry the department they belong to, and access rules restrict reads and writes to the requester's own department.

Audit History

Administrative changes (balance adjustments, overrides, bid open/close, standby promotions, manual vacation changes, role changes) are written to an audit record that captures who made the change, what changed, when, which department it affected, and the reason given.

That history is deliberately append-only: the application has no ability to edit or delete audit entries, and the database refuses deletion attempts even from an administrator account. This has been confirmed by direct testing.

Backups and Recovery

• A full copy of the database is taken nightly and stored outside the hosting provider, in a private bucket that no part of the application can read. Each copy is checksummed on the way in, and the job fails loudly rather than appearing to succeed with nothing in it.
• Restoring from one of those copies has been rehearsed, not assumed. On 08/14/2026 a real nightly copy was restored onto a separate PostgreSQL server and checked: the file matched its checksum, every table, access rule, function and constraint came back, and every row count and integrity check matched the original.
• A restore is not how a problem during a bid gets fixed. If something goes wrong while a bid is running, the bid is paused first, which holds everyone's place and advances nothing. The correction is then made in place, and logged. Restoring a backup would discard picks people have already made, so it is a last resort for damage that cannot be repaired any other way.

Fire-Bid does not claim that a complete rebuild of the running service has been rehearsed end to end. What has been tested is described above, and no more.

Connections and Hosting

• Traffic between your browser and Fire-Bid is encrypted using HTTPS/TLS, and browsers are instructed to refuse unencrypted connections to the site.
• Fire-Bid sends browser security headers that restrict where page content may be loaded from, prevent the site from being embedded in another site (clickjacking), and stop signed-in pages from being stored in shared caches.
• Privileged database credentials are used only by server-side code and are never sent to the browser.

Infrastructure Providers

Fire-Bid runs on managed infrastructure rather than self-managed servers. The certifications below belong to those providers and describe their platforms; they are not certifications of Fire-Bid itself:

• Supabase provides Fire-Bid's managed PostgreSQL database and sign-in infrastructure. Supabase reports SOC 2 Type 2 compliance and ISO 27001 certification for its platform.
• Vercel hosts the Fire-Bid application and provides HTTPS/TLS termination and content delivery.

Fire-Bid has not itself completed SOC 2, ISO 27001, HIPAA, CJIS, or FedRAMP programs, and does not claim to have done so. Using certified infrastructure is not the same as being certified.

Reporting a Vulnerability

If you believe you have found a security problem in Fire-Bid, please report it rather than testing it against a live department's data. Send details to contact@fire-bid.com. See also the Contact page.

Technical Notes

• Hiding a button is not a security control. That is why the access rules above live in the database as well as in the interface: an account that asks the server directly for something it should not have is refused by PostgreSQL, not by a missing link.
• Certified infrastructure is not the same as a certified product, and this page does not blur the two. Every certification named above belongs to a provider and is labeled as one.
• Nothing here is written from intent. Each claim is recorded with its evidence before it is published, and a claim that cannot be evidenced is left off rather than softened.