How your data is protected

Separation between railroads, the permanent record history, sign-off integrity, and what leaves your instance.

Compliance records are only worth keeping if they can be trusted years later, by someone who was not there. This page describes, in plain terms, what RailCompliant does to make that true. It is written for the people who have to answer for the records — a board, a chief mechanical officer, an auditor.

Separation between railroads

Every railroad's records live in their own isolated space. This is not a filter applied to a shared pile of data — the separation is structural, and a request made while signed in to one railroad has no path to another railroad's locomotives, inspections, crew, or costs.

Inside your railroad, what a person can do is set by their role and permissions, described in Users & access.

Foxx Cyber staff who operate the platform are not members of your railroad. A small number of operators can, for support purposes, open your railroad in a "view as" mode; doing so is restricted to full platform administrators, and every occurrence is written to our own permanent operator log. Support staff who answer tickets do not have that ability at all.

The permanent record history

Every create, amendment, approval, return, and deletion is appended to a record history. Each entry carries who did it, when, and the values before and after.

Three things make that history evidence rather than a log file:

• It is append-only. The application has no ability to update or delete an entry. Corrections are made by adding a new record, which is what a maintenance history should look like anyway.
• It is chained. Each entry is sealed with a cryptographic hash that includes the hash of the entry before it. Altering or removing anything in the middle breaks every link after it, which is detectable.
• It can be re-verified. Every time you generate an audit binder, the chain is verified live and the result is printed in the binder's integrity appendix — including when verification fails. The binder is built to never look more compliant than the data behind it.

You can export the entire history as CSV, including each entry's hash pair, and re-verify the chain outside RailCompliant. See Importing & exporting data.

Sign-off integrity

Authority to certify is a permission granted deliberately by an administrator, separate from a person's role. Only the named certifying officer can approve or return an inspection routed to them.

Certification also freezes the record. When a 6180.49A annual record or a Form 4 boiler specification is certified, RailCompliant stores an immutable snapshot of exactly what was certified. Afterwards the page always renders that snapshot — later edits elsewhere in your data cannot change what a certified document says. A superseded Form 4 stays on file as history rather than being overwritten.

Signing in

Passwords are stored using Argon2id, a memory-hard hashing algorithm designed to make offline cracking expensive; they are never recoverable, by anyone, including us. Sign-in is deliberately constant-time so it cannot be used to discover whether an email address has an account.

Sessions are long random tokens, held in a cookie that is HTTP-only, same-site, and marked secure over HTTPS. Only a hash of the session token is stored on our side, so a copy of the database is not a set of live sessions.

Links that grant access — the invitation to set a password, and a password reset — are single-use and expire (48 hours and one hour respectively).

Photographs and attachments

Every uploaded image is decoded and re-encoded before it is stored. This strips embedded camera metadata, including GPS coordinates, and neutralizes files disguised as images. Uploads are size- and dimension-bounded.

Images and attachments are served only through the application to signed-in members of your railroad, never as direct storage URLs.

There are exactly two ways something leaves that boundary, and both are opt-in:

• Public restoration pages. An administrator can publish a page for one locomotive at an address you choose. It shows a blurb, photos, and optionally a total volunteer-hours figure and a fundraising progress bar. It never exposes individual names, compliance status, or inspection detail — that restriction is enforced in the code, not just hidden in the interface. Unpublish at any time.
• Binder share links. An administrator can mint a link that lets an FRA inspector read one locomotive's audit binder without an account. Links carry an expiry you set (14 to 90 days), are revocable immediately, are excluded from search engines, and every access is recorded to your railroad's own record history with the time and origin.

Continuity and portability

RailCompliant runs on managed cloud infrastructure with a managed, backed-up database and separate object storage for media. Deployments are gated on a health check that verifies both before any traffic reaches a new release.

The durable answer to continuity, though, is that your data is yours and portable. Every dataset exports as CSV at any time, including the full record history. Railroads with a records-retention policy generally take a periodic export and keep it with their own archives; we recommend it.

Reporting a concern

If you believe you have found a security problem, open a ticket from Help & support and say so in the subject. Include what you did and what you observed. We will confirm receipt and tell you what we find.