Security
Scanned for weaknesses. Enforced at the database.
Your certification records, vision exams, and audit documents are the paper trail your business runs on. Here's how TRACE keeps them safe — and how we keep checking that it does.
We run security scans
Trust is checked, not assumed.
Most software is secured once and trusted forever after. TRACE is re-checked as it changes — by scans that hunt for vulnerabilities, and by checks that try to break our own access rules the way an attacker would.
Changes are security-scanned
Every change to TRACE runs a battery of automated gates before it ships: dependency vulnerability audits, and coverage checks that fail the build if a new table escapes the audit trail, the demo's read-only wall, or the delete safeguards — so the controls can't silently stop covering what's new.
We attack our own access rules
A battery of verification checks signs in as real accounts of every role — consultant, client, technician, demo, and TRACE's own staff — and deliberately attempts what each one must never do: reading another consultancy's data, writing from a read-only account, reaching a module that isn't licensed, or looking at customer records without an open support window. Every attempt has to come back denied. The battery runs weekly and after significant changes, against the live application — a failure is treated as a release blocker until it's resolved.
Defense in depth
Eleven layers between your data and everyone else.
No single protection is trusted to hold on its own. Each layer assumes the one in front of it could fail.
Enforced by the database
Who can see what is decided inside the database itself (row-level security), not by the website in front of it. Even a bug in a page couldn't hand out another account's data — the database refuses the query.
Invisible even to our own staff
By default, TRACE's own staff can't read your records either — not your documents, financials, technicians, certifications, or exam results. When you ask for help that requires looking, support access is opened for a fixed window measured in hours, it closes by itself, and the grant is written into your consultancy's own audit trail — so you can see exactly when we had access and when it ended. The database enforces this the same way it separates consultancies from each other.
Encrypted everywhere
Every connection is encrypted in transit (HTTPS), and data is encrypted at rest. Backups go further: a full encrypted copy is written nightly to a separate provider with keys held offline, and each copy is restore-tested against the live system before it counts as a backup.
Two-factor, required for staff
No staff account with access to customer data signs in on a password alone. It takes a second step — an authenticator app, or a one-time code emailed for that sign-in. A passkey stands on its own instead, because it is bound to the device and unlocked by your fingerprint or face. Every other account can add an authenticator or a passkey too — and a consultancy can require the second step of everyone who signs in to its records, client portal and technician logins included.
Throttled sign-in
Sign-in, password-reset, and two-factor attempts are rate-limited, so guessing at a password means hitting a wall after a handful of tries — and when that wall goes up on your address, you get an email saying so, with what to do if it wasn't you.
Password rotation
Staff accounts — the ones that reach across a whole portfolio — must change passwords every 30 days. Client and technician logins rotate on a gentler 90-day clock.
Expiring file links
Uploaded documents live in private storage. Downloads use short-lived signed links generated per click — there are no public URLs to leak or forward.
An audit trail on the records that matter
Every compliance record keeps its own history in the database — who changed it, when, and what it said before. Certifications and vision exams, written practices, exam results, dose readings and leak tests, calibration checks, and every audit finding. Not optional, not editable. And it's yours to read: your own consultancy's trail is visible to your own staff, so when an auditor asks who changed a record you answer them yourself instead of emailing us.
Who opened the file, not just who changed it
Every time a document is opened or downloaded, TRACE records who did it and when. Change history answers what happened to a record; this answers who looked at one — which is the first question an investigation actually asks, and the one most systems cannot answer at all.
Sessions end
A signed-in session is time-boxed at the server, not just in the page — thirty days for staff, ninety for client and technician logins, the same two windows as password rotation. Past that, signing in again is required. A stolen session token stops working on its own rather than lasting forever.
Hardened in the browser
Strict security headers on every page: no embedding TRACE inside other sites, no loading scripts from anywhere we haven't named, no sniffing around content types.
What TRACE is not authorized to hold
TRACE is built for compliance records — certifications, vision and audiogram exams, training hours, written practices, and the procedures and audit evidence your consultancy owns. It is not an authorized environment for controlled government information, and nothing in it should be.
Do not upload Controlled Unclassified Information (CUI), technical data controlled under ITAR or the EAR, or classified information at any level. A technician's certification record is not CUI. What gets attached to one might be — a defense program's drawing, technique sheet, procedure, or radiograph carrying a distribution statement or an export-control marking.
This is a deliberate boundary, not an oversight. TRACE runs on commercial cloud infrastructure that is not FedRAMP Moderate authorized, and DFARS 252.204-7012 requires that of any cloud service which stores, processes, or transmits CUI. Keeping CUI out is what keeps TRACE outside your CMMC assessment boundary — an outcome that serves you at least as much as it serves us.
If your contracts require these records to live inside an accredited boundary of your own, ask us about running TRACE self-hosted on your infrastructure, inside the enclave you've already had assessed.
The safest data is data we never hold
Card numbers never touch TRACE — billing happens on Stripe's own pages, and all we learn is whether a payment went through. And because there are no analytics trackers, ad networks, or fingerprinting anywhere on the site, there is no behavioral profile of you to steal in the first place.
Honesty about limits
No system is perfectly secure, and anyone who claims otherwise is selling something. What we promise instead: security is engineered into TRACE at the database layer rather than bolted on top, it's re-verified as the product changes, and if something ever did go wrong, the audit trail means we could tell you exactly what happened — and we would.
Spotted a weakness?
If you think you've found a security problem in TRACE, tell us through the contact form and we'll take it from there. We'd rather hear about the same issue ten times than miss it once.