How your data is protected

Separation between railroads, roles and permissions, the permanent record history, sign-off integrity, signing in, what is logged, and what leaves your workspace.

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.

A login that belongs to several railroads works in one railroad at a time, and can only switch into railroads where it holds active access. Revoking someone's access takes effect on their very next click. The one page that reads across railroads is a crew member's own My Career, and it reads only that person's own records from the railroads they belong to. No railroad ever sees another railroad's records about them.

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.

Roles and permissions inside your railroad

Inside your railroad, what a person can do is set by their role, by your railroad's permissions matrix, and by two authorities granted to individuals: certifying inspections and approving purchases. The matrix is checked by the server on every page and every change, not just hidden in the menus — a general member who is not allowed to change an area cannot change it by any route. A handful of things are always administrators' own: settings and permissions, billing, accounts and roles, share links and public pages, unlocking a completed work order, correcting a stock count, and certifying the volunteer report. See Users & access and Settings & permissions.

The railroad's owner is always an administrator and cannot be locked out by anyone at the railroad; ownership moves only when the owner hands it over, with their password, and both people are emailed.

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, the entry's own time, and which railroad's history it belongs to. Altering, backdating, or removing anything breaks every link after it, which is detectable. The latest position of each chain is recorded too, so cutting entries off the end is caught as well.
• 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.

Every railroad's chain is also verified automatically once a day, and the RailCompliant team is alerted the same day if a check fails.

• Signed by an independent time-stamping authority, every day. After each day's check, one fingerprint covering the latest entry of every railroad's history is signed by a public time-stamping authority (DigiCert, or Sectigo as a fallback), using the RFC 3161 standard. The signed timestamp proves where every chain stood on that day. Anyone, an auditor for instance, can check it with standard tools and the authority's public certificate, without having to trust Foxx Cyber or the database. Only the fingerprint is sent, never your records.
• Copied to a separate mailbox, every month. Once a month the same fingerprint, with the list of that month's timestamps, is also sent to a separate mailbox kept by Foxx Cyber.

Together they are a record of where each chain stood that someone holding the database alone could not quietly rewrite. If you need the timestamp for a particular day, and how to check it, ask through Help & support.

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. If two officers certify the same 6180.49A at once, the first certification stands. Changes to a 6180.49A's header are themselves written to the record history. A superseded Form 4 stays on file as history rather than being overwritten.

Completed work orders lock the same way: once a job is marked complete, its details, hours, and parts cannot change unless an administrator unlocks it, and every change made while it is unlocked is in its history.

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, and repeated failed attempts for an address are paused for a few minutes. Sign-up works the same way: it answers "check your email" whatever the address, and only the mailbox's owner learns whether it already had an account.

Automated sign-ups are limited per browser with a cookie that holds a random number and a signature, nothing about you. It is not linked to your account, not kept in the database, and not used for tracking or analytics. A browser without it gets the stricter limit for its network address. The privacy policy lists every cookie RailCompliant sets.

Sessions are long random tokens, held in a cookie that is HTTP-only, same-site, and marked secure. 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. A session ends after 30 days, or sooner if it goes unused for 14 days, so a login left on a shared shop computer does not stay open indefinitely. Changing your password signs out every other session on your account, and resetting a forgotten password signs out all of them.

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

Whether or not you use two-step sign-in (below), use a strong password that you do not use anywhere else.

Two-step sign-in

Two-step sign-in asks for a six-digit code from an authenticator app on your phone (Google Authenticator, Microsoft Authenticator, 1Password, Authy) after your password. Turn it on from Two-step sign-in under your name in the sidebar: scan the QR code with the app, then enter the code it shows. RailCompliant staff accounts must use it.

Recovery codes

When you turn two-step sign-in on, RailCompliant shows you ten recovery codes, once. Save them in a password manager or print them, and keep them somewhere other than your phone. If you lose the phone, each code signs you in once in place of a code from the app.

• Signing in with one. On the code page, choose Lost your phone? Use a recovery code, enter one (capitals and dashes don't matter) and choose Sign in with a recovery code. A code that has been used is refused.
• We email you each time one is used. This email can't be turned off. If it wasn't you, reply right away: someone has your password and one of your recovery codes.
• How many are left shows on the Two-step sign-in page. Make new recovery codes asks for your password and a code from the app, then shows ten new codes; the old ones stop working.
• We can't read them. RailCompliant keeps only a one-way hash of each code, never the code itself.
• No codes yet? If two-step sign-in is on and you have no recovery codes (for example, you turned it on before recovery codes existed, or you have used them all), a banner at the top of every page asks you to make them.

A new or lost phone

Sign in with a recovery code. On the Two-step sign-in page, open New phone, or turn it off, enter your password and a code from the app or another recovery code, and turn two-step sign-in off. Then set it up again with the new phone, which gives you ten new recovery codes.

No phone and no recovery codes? Contact support to reset two-step sign-in for your account. A reset signs you out everywhere; you sign in with your password and set it up again.

What is logged

For security and abuse investigation, Foxx Cyber keeps a security log of account activity: sign-ins and failed sign-ins, sign-outs, password changes and reset requests, two-step sign-in turned on or off and recovery codes made and used, switching between railroads, data exports, accounts granted, changed, and revoked, changes to the permissions matrix, and inspector share links created, revoked, and opened. Each entry records who, which railroad, when, the network address, and the browser. The log is kept for a limited period and is separate from your railroad's own record history.

RailCompliant also counts how its website and app are used, on its own servers and without any third-party analytics. Page views and clicks are counted without cookies: instead of your network address, a one-way code is made from your address and browser with a random value that is replaced every day and then deleted, so a visit can be counted but you cannot be recognized from one day to the next. In the app, what is counted is which kinds of page each railroad's members open — "a locomotive's page", never which locomotive, and never by person. The counts are kept for 400 days, stay with Foxx Cyber, and anything shared or published is aggregated so it does not identify you, your railroad, or anyone else.

Files you upload

Every file a person uploads — a photo of a locomotive or a work order, an attachment on a support ticket, a crew member's certificate, a CSV import — passes two checks before RailCompliant keeps it. Nothing is stored until both pass, and a file that fails either is refused in full: no half-saved upload, no quarantine folder.

1. Antivirus scanning. Every file is streamed, exactly as it was sent, to a ClamAV scanner — an industry-standard open-source antivirus engine used by mail gateways and file servers worldwide, whose signature database is refreshed several times a day. A file that matches a signature is refused, and the refusal is written to our operator log with the signature's name. The scanner is a separate service beside the application; if it is ever unreachable, RailCompliant refuses uploads rather than storing something it could not scan, and says so plainly. The rest of the app is unaffected.

2. A structural check that fits the file.

• Images (JPEG, PNG, GIF) are decoded and rebuilt from their pixels before they are stored. None of the uploaded bytes are kept, which strips embedded camera metadata — including GPS coordinates — and neutralizes a file disguised as an image. Uploads are size- and dimension-bounded.
• PDFs are the one upload kept as sent, so each is inspected for the features that turn a document into a program: scripts, launch actions, embedded files, form-submission actions, rich media, and password protection (an encrypted PDF cannot be inspected, so it is refused). A PDF carrying any of these is refused with a message that names what was found; printing the document to a new PDF removes all of them. A scanned certificate or an exported form passes unchanged.
• CSV imports are parsed and only the rows survive; the file itself is never stored.

Images and attachments are served only through the application to signed-in people entitled to see them, never as direct storage URLs. PDFs are served as downloads or inside a sandboxed viewer, never as a page on the application's own address. Certification documents a crew member keeps on My Career are stored separately from any railroad's files, belong to that person, and are visible to a railroad only while the person shares that certification with it.

There are exactly three ways something leaves your workspace without a sign-in, and all three 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. A published page is public: anyone with the address can open it. 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.
• Calendar links. A member can subscribe their phone's calendar to their own schedule or to the railroad's calendar. A calendar app cannot sign in, so the address is the key: it contains a long random code, is shown once when it is made, and only a one-way fingerprint of it is stored, so it cannot be read back out of RailCompliant. Each time a calendar fetches it, the answer is worked out from what that member is allowed to see at that moment — it never shows more than they could see in the app, and it stops answering if they leave the railroad or the railroad's access lapses. The member can replace the address or turn the link off at any time, and the old address stops working immediately. Repeated wrong addresses from one network address are blocked, and the address is kept out of server logs. See Calendar & work days.

Who processes your data

RailCompliant runs on a short list of service providers, each under contract and only as needed to run the service:

The full list and the rest of our commitments are in the RailCompliant privacy policy. For the personal information in your railroad's records, such as your crew's names, qualifications, and hours, RailCompliant is your processor under the Data Processing Agreement, which is part of the Terms of Service: nothing separate to sign. Customer data is never used to train machine-learning models, and never sold.

Continuity and portability

RailCompliant runs on managed cloud infrastructure with a managed, backed-up database and separate storage for photos and documents. 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. If your subscription ends, you can ask for an export within 30 days; after that your railroad's data may be deleted, including its photos, documents, and support attachments, and routine backup copies age out on the normal backup cycle.

Reporting a concern

If you believe you have found a security problem, open a ticket from Help & support and say so in the subject, or email help@foxxcyber.com (the address published in railcompliant.com/.well-known/security.txt). Include what you did and what you observed. We will confirm receipt and tell you what we find.