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 pushed to TRACE runs a battery of automated gates: dependency vulnerability audits, and coverage checks that turn red if a new table escapes the audit trail, the demo's read-only wall, the staff support window, 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 every week, and again whenever we audit the product. The weekly run works against a separate staging copy of the database — the same structure as the live one, holding the demo workspace and test records but no customer data — and a smaller set of weekly checks runs against the live site itself: backups, DNS, the public pages and security.txt. It is a check, not a gate: a release does not wait for it to pass.
Defense in depth
Fifteen 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 — and one of them assumes they all did, and watches for the signs.
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. When a page reads as you, even a bug in it couldn't hand out another account's data — the database refuses the query. The one exception is the service's own keys, described in the next card, where our code has to make that check itself.
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. What you write to us is the exception, and an obvious one: a support request you send, and the replies on it, are read by our support staff without a window, because that is a message addressed to us rather than a record of yours — and gating it would mean we could not read a request for help from somebody who cannot sign in. For everything else, seeing any of it takes a support window, which any consultant at your firm can open — whoever we are helping never has to wait on a colleague to let us look — and we can ask for one but can never let ourselves in. It runs for four hours or twenty-four, whichever they choose, and closes by itself; our staff can close it early but never extend it, 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. Since October 3, 2026 some support requests are answered by TRACE help desk logins, who are not full staff: the same window is their only way to your records, and inside it they can read but not change anything. One limit, stated plainly: the keys that run the service — the nightly backup, a change to the database, the scheduled jobs, an import you ask us for, maintenance we decide on ourselves such as converting or correcting filed records across every firm, and parts of the ordinary work the application does on your behalf — sit underneath these rules, because a backup the rules could refuse would not be a backup. Work of that kind reads your files, on our own machines and with the tools on them, and none of it sends a document outside TRACE. Where the application uses one, its own code has to make the check the database would have made. They are held by the people who operate TRACE and by the application they run, and they are not a way around the window.
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, encrypted with keys that neither that provider nor the job that writes the backup holds, and each night's database copy is restored into a scratch database and checked against the live system before it counts as verified.
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. The database enforces this, not just the sign-in screen: until the second step is done, the session can read none of your records — the only thing it can ask for is what the page needs to show you the second step itself — and an authenticator or passkey only counts if it was added from a sign-in that had already finished it. Client portal logins take the same second step, and a consultancy can require it of its technicians too. The read-only demo workspace is where that stops, in two slightly different ways. The step is not asked while the workspace you are working in is the demo — including of someone who has a firm of their own and is looking around, and only for as long as they are in it: switch back to your own firm and the step is required again before any of your records will open. And an account that belongs to the demo and to no real firm — the shared one we publish, and any account that has only ever been let into the demo — is the one place TRACE refuses to let anyone add an authenticator or a passkey at all, because that workspace is shared: one visitor's authenticator would demand a code from everyone else who uses it, and one visitor's passkey would leave them a way in of their own. Join a real firm and both come back. Those shared demo logins cannot change or reset their password either, for the same reason — one visitor's new password would take the demo away from the tablet and from everybody after them — and that one is refused when the form is submitted rather than by the database, and only for those logins: a login of your own that was let into the demo keeps its own password. Every other account can add either, and change its own password.
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. A password already published in somebody else's breach is refused when you choose it, and the check does not send your password anywhere: it is scrambled one way and only the first five characters of that go out, so the comparison happens on our own server.
Watched every hour, and you hear first
Recording everything is worth nothing if nobody looks. Once an hour TRACE reads its own records of the hour just gone and speaks up. If your account is signed in to from a network address you have never used before, or used on the website from two places too far apart to travel between in the time between them, the email goes to you — when, what device, where from — with a "this wasn't me" link that signs that device out on the spot and then walks you through a new password. It works once, for a day, and can do nothing but sign you out. An impossible-travel sign-in is also sent to your firm's primary user. The heavier patterns are reported to the people who run TRACE, so that a person looks at them: one login opening more than sixty documents in an hour, one person deleting more than twenty-five records, a change to someone's role or to a firm's primary contact, someone joining or leaving a firm, every support window opened, and an API key making more than a thousand calls, or reading more than twenty-five thousand records, in an hour. Those reports carry a name, a firm and a count — never a document, a record, or anything anyone typed. Your firm sees its own share of all of this under Account → Security → Security Findings: your primary user always, and the consultants they choose. Nothing here blocks anybody: it is a smoke alarm, not a lock, and the thresholds are deliberately generous, because a consultant building an audit pack really does open forty documents in an hour.
A password already in a breach is refused
When you choose a password — signing up, changing it, or resetting it — TRACE checks it against the public record of passwords exposed in known breaches and will not accept one that appears there. Your password never leaves the server to be checked: only the first five characters of its fingerprint are sent, which stand for hundreds of thousands of possibilities at once, and the comparison happens here. One limit, stated plainly: if that check can't be reached, you are let through rather than locked out. A password checker must never become the reason nobody can set a password.
No forced password changes — on purpose
TRACE does not make you change a working password on a schedule. Current guidance says not to: NIST 800-63B dropped the advice in 2017 and 800-171 rev 3 removed the requirement, because a clock produces Spring2026, then Spring2026!, rather than better passwords. What actually protects an account is here instead — a mandatory second step for staff, sessions that expire at the server, throttled sign-in, and a record of what changed. If your own customer contract requires scheduled changes, your consultancy's primary user can switch them on for your firm from the Account page.
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 — and, since October 4, 2026, the invoices, payments, credits and expenses in Ledger. 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 one of your documents is opened or downloaded — a certificate, a procedure, a job report — TRACE records who did it and when, on the website and in the phone app alike. 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. One gap, stated plainly: a file attached to a task-board card is not a document in its own right, so opening one is not in this log — on the website or the phone — and nor is a photo on a field report opened in the phone app, though that same photo is logged when it is opened on the website.
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. Past that, signing in again is required. A stolen session token stops working on its own rather than lasting forever.
Switched off means switched off
Deactivate a login — someone left, a client changed their contact, a firm was suspended — and it stops that moment rather than whenever their session happened to run out. The sessions they already had are ended, a fresh sign-in is refused at every door with the plain reason that the account has been deactivated, and the refusal comes from the sign-in service and the database rather than from a check a page has to remember to make. A suspended firm takes its client and technician portals with it: those logins reach nothing of the firm's until it is switched back on.
Keys for other programs, on your terms
If another program needs your records, your firm's primary user makes it an API key — after the second sign-in step, and never from the demo. The key is shown once and TRACE keeps only a scrambled fingerprint of it, made with a secret held on the server, so a copy of our database would not give anyone a working key, and nobody at TRACE can read one back to you. Each key reaches only your own firm's records, only the record types it was given, and writes nothing unless you allowed that; it can be limited to your own network addresses and set to expire. Every call is recorded — which key, what it asked for, how many records came back, and where it came from — every change a key makes is in your audit trail under that key's name, unusual volume is flagged to you and to us, and revoking a key stops it on its next call.
Hardened in the browser
Strict security headers on every page: browsers told to reach TRACE, and every tracendt.com address, over HTTPS only; no embedding TRACE inside other sites; no running any script our own pages haven't vouched for; no sniffing around content types. A technician can choose to keep field reports, charge sheets and hours on their own computer for working with no signal, and a consultant their office reports: everything kept is encrypted under an offline passcode only they know (TRACE never sees it, and a forgotten one cannot be recovered), the offline page locks itself after fifteen idle minutes, signing out deletes the copy of TRACE's data, and the one script TRACE installs for it caches only our own page code and public font files — never a record and never an answer from our servers. A charge sheet kept offline carries hours and quantities, never prices, and a work-in-progress PDF made there says DRAFT on every page. An office report written offline is filed only in the firm it was written in, every send is judged again by the same rules as on the website, and approving a report still happens on TRACE. Not offered to the shared demo workspace or to our own staff.
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
No card or bank number reaches TRACE through a payment. Paying for TRACE happens on Stripe's own pages, and all we learn is whether the payment went through. A firm that connects its own Stripe account can take online invoice payments: its clients pay on Stripe's pages too, into the firm's own Stripe account, and TRACE records the amount and the card brand or bank with its last four digits, nothing more. The one place a bank detail is typed into TRACE at all is a firm's own books: Ledger's register takes the last four digits of an account, and the database refuses anything longer — there is no field for a full account number or a routing number anywhere in it. 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 change history and the document-access log mean we could tell you what happened to the records they cover — and we would.
Spotted a weakness?
If you think you've found a security problem in TRACE, email security@tracendt.com. Our vulnerability disclosure policy says what is in scope, what we promise in return, and that good-faith research is authorized. We'd rather hear about the same issue ten times than miss it once.