Most LIMS vendors handle 21 CFR Part 11 with written policies — they tell you what you're supposed to do and leave the enforcement to your team. AILS enforces Part 11 at the code level. The controls aren't optional, configurable, or bypassable by a user with the right role. Here's what that means, clause by clause.
💡
The FDA's core question during an inspection
Investigators don't just ask "do you have a policy for this?" — they ask for live system evidence. They want to see audit logs that can't be edited, re-authentication that actually fires before a signature, and record exports that include an integrity hash. AILS is built to answer every one of those requests with a live demonstration, not a binder.
Systems used to create, modify, maintain, archive, retrieve, or transmit electronic records must be validated to ensure accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records.
AILS
AILS ships with a Vendor Validation Package (VVP) — a pre-built IQ/OQ/PQ bundle including a Requirements Traceability Matrix, 16 executed OQ test cases with pass/fail evidence, GAMP 5 Category 4 classification, and a §11.100(c) e-signature declaration. Generated on demand from your Compliance module, always reflecting the current system version.
The ability to generate accurate and complete copies of records in both human readable and electronic form suitable for inspection, review, and copying by the agency.
AILS
Every COA, CAPA, deviation, SOP, audit log, and management review is exportable as PDF with embedded SHA-256 integrity hash. The hash can be independently verified via the public certificate verification endpoint — confirming the record has not been altered since issuance.
Protection of records to enable their accurate and ready retrieval throughout the records retention period.
AILS
Every record is scoped to its tenant on every query, checked by an isolation test suite on every release. Bring-your-own database and EU hosting give a tenant a dedicated database. Default retention is 7 years, configurable to match your accreditation requirements. Records are never deleted during the retention window — only archived. Full export is available at any time in standard formats.
Limiting system access to authorized individuals.
AILS
Role-based access control with four tiers — Admin, Manager, Technician, Read-Only — enforced at the API level on every request. Module-level licensing gates access to COC, COA, QMS, and Equipment independently. Training currency enforcement: expired training blocks the five signing and issuing actions (COA issue, COC acceptance, SOP signoff, test-report issue, Report Builder issue), regardless of role.
Use of secure, computer-generated, time-stamped audit trails to independently record the date and time of operator entries and actions that create, modify, or delete electronic records. Record changes shall not obscure previously recorded information.
AILS
5-year immutable audit trail on every action across the platform. Each entry captures: user ID, full name, IP address, timestamp, action type, affected record ID, and the previous and new values for any field changed. The audit log is append-only — no record can be modified or deleted. Suspicious activity detection flags critical events. Exportable as PDF for inspections.
Use of operational system checks to enforce permitted sequencing of steps and events, as appropriate.
AILS
Workflow sequencing is enforced at the system level. A COA cannot be issued until all required results are entered. A CAPA cannot be closed until root cause and corrective action are documented. A batch release cannot be initiated until the batch record is complete. These gates are not warnings — they are hard stops enforced by the API.
Use of authority checks to ensure that only authorized individuals can use the system, electronically sign a record, access the operation or computer system input or output device, alter a record, or perform the operation at hand.
AILS
Re-authentication is required before every critical signing event — COA issuance, SOP approval, CAPA closure, batch release, COC acceptance. Active session state alone is not sufficient. The user must re-enter their credentials at the point of signature. This fires regardless of how recently they logged in, closing the session-hijacking gap that policy-only systems miss.
Use of device checks, as appropriate, to determine, as warranted, the validity of the source of data input or operational instruction.
AILS
Token-based authentication with short-lived access tokens and rotating refresh tokens. Account lockout after 5 failed attempts with a 15-minute lock and a critical audit event. Generic error responses prevent account enumeration. All authentication events — success and failure — are logged with IP address and device metadata.
Determination that persons who develop, maintain, or use electronic record/electronic signature systems have the education, training, and experience to perform their assigned tasks.
AILS
Training records are maintained per user, linked to specific roles and test methods. The system enforces training currency — a user with expired training is blocked from the five signing and issuing actions: issuing a COA, accepting a COC, signing off an SOP, issuing a test report and issuing a Report Builder report. Training records are included in audit exports and are accessible for inspection without manual compilation.
The establishment of, and adherence to, written policies that hold individuals accountable and responsible for actions initiated under their electronic signatures, in order to deter record and signature falsification.
AILS
Three §11.10(k) policy documents are available from the Compliance module: Incident Response Policy, Periodic System Validation Review Schedule, and Intended Use Statement. Each is version-controlled and signed electronically on acceptance, with the signing record stored in the audit trail.
Each electronic signature shall be unique to one individual and shall not be reused by, or reassigned to, anyone else.
AILS
Every user account has a unique identifier that cannot be shared, transferred, or reassigned. Signing credentials are bound to the individual user account — not a role or team account. Shared login accounts are architecturally prevented; each user must have their own credentials to access the platform.
Before an organization establishes, assigns, certifies, or otherwise sanctions an individual's electronic signature, or any element of such electronic signature, the organization shall certify to the agency that the electronic signatures in their systems are the legally binding equivalent of traditional handwritten signatures.
AILS
The §11.100(c) vendor declaration letter is included in the Vendor Validation Package — certifying that all electronic signatures in AILS are intended to be the legally binding equivalent of handwritten signatures. This letter is generated on demand, always reflecting the current platform version, and is ready for FDA submission without additional preparation.
Electronic signatures not based upon biometrics shall employ at least two distinct identification components such as an identification code and password.
AILS
All signatures require two-factor authentication: the user's password plus a TOTP (time-based one-time password) from an authenticator app. 2FA is enforced on all signing events for regulated workflows. Signed records capture the authentication method used alongside the signature timestamp, user identity, and record state.