What this page is
FDA 21 CFR Part 11 governs electronic records and electronic signatures. It asks three kinds of thing: what the software must do, what the organization must do, and what depends on how the software is run. This page takes the regulation clause by clause and says which kind each is, what Trialion does, and where the detail is. The clause-by-clause list of every question answered on this site is the generated Part 11 matrix.
Nothing here is a certification. Software is not "Part 11 compliant" on its own; an organization running validated software under its own procedures is. The status words are the ones used throughout this library: Built, Partly built, Customer responsibility and Not built yet.
Subpart B: electronic records
§11.10 Controls for closed systems
| Clause | Status | What Trialion does | What is yours |
|---|---|---|---|
| (a) Validation | Not built yet | Automated engineering tests and release gates, a test cycle (UAT) with three sign-offs for every study's own design, and installation-qualification tooling (Testing and quality). No validation package is supplied | Validate for your intended use (GAMP 5 and CSV) |
| (b) Accurate and complete copies | Built | Exports in CSV, Excel and CDISC ODM-XML, each audit-trail and design export, and a readable screen for every record (Export data, Exports reference). SAS, PDF and signed exports are refused, not faked | Deciding what an inspector receives, and when |
| (c) Protection of records | Built (retention is yours) | Clinical records are retired or withdrawn, never deleted: a governance test fails the build on a new hard delete, and the application's database role holds DELETE on two tables only, neither of which holds a record (The database). A locked database refuses every write | Retention period, backups and restore, which belong to the hosting (Security and hosting) |
| (d) Limiting access to authorized individuals | Built | Role-based access with 15 standard roles and 68 permissions, custom roles with guardrails, one role per person per study, site staff confined to their site, a signed delegation before any site access, and every refusal recorded (Roles and permissions, Who can and cannot) | Deciding who holds which role; removing people who leave |
| (e) Secure, computer-generated, time-stamped audit trails | Built | Every change writes an event in the same transaction, with the person, the server's time, the earlier and new value and the reason; events cannot be updated or deleted; they are hash-chained, anchored outside the table, and verified by the platform (Audit trail and evidence). Reads are not recorded (Not built yet) | Reviewing the trail on a schedule your procedures set |
| (f) Operational checks that enforce the sequence of steps | Built | State machines on the server: consent before screening, eligibility determined by the investigator before enrollment, ethics approval and training before a site opens, delegation before site access, a complete record before signing, three independent sign-offs before release, a completed study before lock (Statuses) | |
| (g) Authority checks | Built | Every operation checks the caller's permission on the server. The clinical and signing operations have no administrator bypass, and the hard guardrails of the role editor are refused for everyone (Who can and cannot) | |
| (h) Device checks | Not applicable | No instrument or device is connected; the source of input is a signed-in person | |
| (i) Education and training of users | Partly built | A site cannot be activated without GCP training confirmed, and a team assignment carries a training complete flag that blocks nothing | Training, its records and its enforcement |
| (j) Written policies for accountability under signature | Customer responsibility | The signature meaning is shown at signing | The written policy and the training that make people accountable |
| (k) Control of systems documentation | Built | Documents version rather than overwrite; a study's design is a sealed, versioned unit released after three sign-offs and changed only through a new version (Review and release a study, Manage documents) | Controlling this library and your own SOPs |
That is a policy of the organization, not a function of software. The system shows the signer the meaning of the signature before it is applied and records it with the name and the time; the written statement that a signature is the equivalent of a handwritten one, and the training that goes with it, are the organization's to write and to keep (Sign records).
§11.30 Controls for open systems
Trialion is used over the internet, so Part 11 would treat a deployment as an open system if the records pass over networks the organization does not control. What the software contributes:
- Encrypted transport. The API sends strict transport security in production, the web application sends it on every response, and a production deployment refuses a database connection that is not encrypted (Security and hosting).
- A session no script can read. The tokens live in a sealed,
httpOnlycookie that client-side code cannot read. - Records that prove themselves. Signatures and the audit trail carry hashes of what they cover, so a record changed in transit or at rest no longer matches.
- Documents move between the browser and storage over short-lived single-purpose links and are stored encrypted when the storage is S3.
In part. Production traffic is protected by transport security headers and a content-security policy, the session cannot be read by script, a production database connection must be encrypted, and a signature is bound to a hash of what it signs.
Limits: terminating TLS, certificates, the network boundary and key management belong to the hosting. The application sets the headers; it does not install the certificate.
Evidence: server api/middleware/security.ts (Helmet, HSTS when hardened)client next.config.ts and proxy.ts (HSTS, CSP, frame and content-type headers)lib/bff/session.ts (sealed httpOnly cookie)config invariants (database TLS refused if unencrypted in production)
§11.50 Signature manifestations
Every signature records the signer's printed name, the date and time and the meaning of the signing (authorship, review, approval or responsibility), shown with the record and in the signatures register. The detail and the dialog's wording are on Sign records.
§11.70 Signature and record linking
A signature stores a SHA-256 fingerprint of exactly what was signed. If the values change afterwards, the record is shown as changed since it was signed and the discrepancy is written to the audit trail; a change that is authorized withdraws the signature visibly rather than leaving it attached. A signature is never edited or deleted. Release sign-offs carry the fingerprint of the design they approved, and release is refused if the design has changed since.
Subpart C: electronic signatures
| Clause | Status | Position |
|---|---|---|
| §11.100(a) Unique to one individual, never reused | Built | A signature is made by the authenticated person; a person's identity is never deleted or reassigned (Invite and manage members) |
| §11.100(b) Identity verified before a signature is issued | Customer responsibility | The software cannot verify who someone is in the physical world; the organization's procedure for issuing an account does |
| §11.100(c) Certification to the FDA | Customer responsibility | The organization files it; no software can |
| §11.200(a) Two distinct components | Partly built | The authenticated session plus a fresh six-digit code sent to the signer's address and the typed name. There is no password, authenticator application or hardware key |
| §11.200(a)(1) Continuous session signing | Not applicable | Not offered: every signature needs a fresh code, which is stricter than the regulation's minimum |
| §11.200(a)(3) Used only by the genuine owner | Customer responsibility | Depends on the control of the mailbox |
| §11.300 Identification codes and passwords | Partly built | There are no passwords. A sign-in code is valid five minutes, allows three attempts, can be asked for again after 60 seconds and no more than three times in 15 minutes, and is stored only as a hash. Repeated failures pause sign-in in that browser window for fifteen minutes and are recorded; the account itself is never locked by someone else's guessing. Sessions end after 15 minutes without activity and at most 12 hours after they began (Signing in) |
The aims of §11.300 are met by a different mechanism: nobody shares or guesses a password because there is none, and a code is single-purpose, short-lived, limited in attempts, sent only to the account's address and stored only as a hash. A code requested for signing cannot sign anyone in, and a code for one record cannot sign another.
Limits: ageing, complexity and reuse rules do not apply, and nothing stronger than control of the mailbox is offered as a second component. If your policy needs a stronger second factor it is not available in this release, and single sign-on is not built (Not built yet).
Evidence: server auth (one-time code, argon2id hash, 5 minutes, 3 attempts, cooldown)session idle and absolute limitsclient sign-in pagessimulation of 20 and 21 Oct 2026
The honest summary
Built: the audit trail with tamper evidence, reason for change, authority checks with no administrator bypass on clinical acts, operational sequencing, signature manifestation and linking, a fresh code for every signature, the two-person database lock, and retention of records.
Partly built: the second signature component, user training checks, and the open-system controls that sit in the hosting.
Not built yet: a validation package (GAMP 5 and CSV), and a record of who read what (Not built yet).
Yours by definition: the §11.100(b) and (c) steps, written policies, training, the review of the audit trail, and the controls behind backup, retention and the network.
Related
Part 11 matrix · Audit trail and evidence · GAMP 5 and CSV · Sign records · ALCOA+ · Security and hosting