Security and data handling

Where the audio goes

You record in the browser. The audio is processed into text and then it is done with: we do not store the audio. There is no audio bucket, no audio column in the database, and no recording history to browse.

• Processing runs on a small number of established, US-based service providers acting on our behalf. We do not publish which ones — how the pipeline is put together is part of what you are paying us to get right — but if your department needs the current list for a data agreement, ask us and we will share it in writing.
• Where we have a department's local street and place names loaded, they are used during processing so local spellings come back right. That vocabulary contains place names, not incident content.

Where the text goes

The transcript is processed into structured NERIS fields — the draft report you review — and stored with the report for your department. Producing your report is processing, not training: that step does not add your transcript to anyone's training set.

What is stored, and where

In our database:

• Reports, including the raw transcript of what you said. That transcript is the evidence for what is in the report, and deleting it would make a filed federal record unverifiable, so it is kept with the report.
• Roster: names and roles of members, plus a PIN for officers and admins stored only as a one-way hash. We cannot read a PIN back, and a copy of the database on its own does not yield them.
• Attachments (photos you add to a report) in a private storage bucket. There are no public read policies on it. Uploads go direct from your browser using a one-time signed URL our server mints; downloads are signed links. The shipped browser key cannot list or read the bucket.
• Anonymous trial drafts in a separate table with a separate lifetime (see below).

Who can read a report

• The database denies direct access by default. Nothing is readable straight from the browser; every read goes through our API.
• The API derives your department from your session on the server. It never takes a department id from the request body. That is the difference between "scoped" and "scoped until someone edits a request".
• Membership is re-read from the database on every request, so deactivating someone takes effect on their next action rather than when their token happens to expire.
• Sessions are short where it matters: officer and admin sessions expire after 12 hours; a firefighter's lasts 30 days, because the alternative is a login screen at 3am on a personal phone.
• On a shared station tablet, sessions are per-tab and are not shared between people using the device.
• Our own staff can technically reach the database; anyone honest about a hosted product will tell you the same. There is no engineering control that would let us claim otherwise, so we do not claim it.

The anonymous trial

If you record without an account:

• The draft is stored in a different table from any department's records. It is not in any department's dashboard, export, review queue, or statistics.
• It is deleted after 30 days unless you sign in and claim it. That is enforced by a job that runs daily and deletes the rows, not by a column nobody acts on. Reads also filter on the expiry, so an expired draft is invisible even in the hours before the job runs.
• It cannot be filed to NERIS. Not "is not"; cannot: the submit path only reads the department reports table, and an anonymous draft is not in it.
• It is excluded from training data. The endpoint that writes training examples requires a real department membership, which an anonymous caller cannot obtain. A test in our suite scans that file and fails the build if someone adds an anonymous branch to it.
• Your browser's anonymous id partitions drafts but does not authorize them. Reading a draft back also requires a secret key the server mints and stores only as a hash, in a cookie your browser cannot read from JavaScript. Someone who learns your anonymous id gets nothing with it.

The privacy policy states all four of those in full.

Deletion

• Anonymous trial drafts: deleted automatically after 30 days, as above.
• Attachments: can be deleted from a report.
• Filed reports: there is deliberately no self-serve delete button for a report in the product today. Ask us and we will delete a department's data from our database.
• Anything already filed into NERIS: that record belongs to NERIS, not to us. We cannot delete a department's federal filing on request, and a vendor who tells you otherwise is describing a system they do not control. Corrections go through NERIS.

Error reporting and analytics

• Error reporting is off entirely unless a reporting key is configured. When it is on, request bodies and cookies are stripped before an event leaves the process, an explicit list of sensitive keys (transcripts, report contents, NERIS payloads, audio, email addresses) is redacted at a single choke point, and user email is redacted from the identity. Session replay is off.
• Usage analytics is off entirely unless a key is configured. When it is on: no autocapture (autocapture would hoover up form text, which in this app is incident narrative), no session recording, and a scrubber that drops any property whose name looks like a name, email, address, transcript, narrative, phone, street, patient, city, ZIP, date of birth, or SSN, plus any string long enough to be narrative content.
• This marketing site sends nothing at all unless an analytics key is configured for it, and it has no server side and no database.

What we are not claiming

Because you will be asked these in a budget meeting and you should have the honest answer:

• The "NERIS V1 Data Exchange Compatible" badge on this site means exactly what it says: FireMic meets the technical requirements for connecting to the NERIS V1 API. It is not a certification or endorsement of the product beyond that technical compatibility.
• We do not hold SOC 2, ISO 27001, or any equivalent certification.
• We have not had a third-party penetration test.
• We do not claim HIPAA compliance. Incident narratives can contain patient information; treat this product the way your department treats any other system that touches it, and involve whoever handles that question for you.
• We are a small company. The controls described above are real and you can ask us to demonstrate any of them, but they are engineering controls, not an audit.

Reporting something

If you find a security problem, tell us before you tell anyone else and we will fix it and credit you if you want the credit. Contact: Show email address, Show phone number, or text us.