Conformance 21 CFR Part 11 & EU GMP Annex 11
What is this page for?
This page is LiteLog's conformance matrix for regulated (GxP) environments. It maps every requirement of FDA 21 CFR Part 11 and EU GMP Annex 11 to the LiteLog feature that fulfils it and names the evidence you can use to verify it within your validation: fields of the signature manifest, events of the session log and the automated tests in the source code. Items not yet implemented are honestly marked as planned.
LiteLog is not a pre-validated system; validation (IQ/OQ/PQ) is performed by the operator within their quality system. This page is the supplier evidence for it — together with the audit trail, the Digital Signature and change control.
:::info Plan Digital Signature and audit-proof audit trail belong to the Compliance add-on (included in the Enterprise contract) — see Choose a plan. The data-handling fundamentals (server-side timestamps, immutable originals, correction instead of overwriting) apply in every plan. :::
How to read the evidence
| Type of evidence | What it is | Where to find it |
|---|---|---|
Signature manifest (signature_events) | One immutable row per signature and per missing mandatory signature. Fields: signer (signer_name, signer_username, account_id), times (signed_at = moment of signing on the device, received_at = arrival on the server), method (password, PIN, NFC chip, QR code), meaning (submission / archiving), verification (verified, rejected, missing) with failure_reason, payload_hash (SHA-256 of the signed data), device (device_unique_id), IP, meta (e.g. offline check). Without foreign keys — survives deletion of record and account. | Detail views of report, incident report and task ("Digitally signed" / deviation), form PDF (signature section), API GET /esignature/events |
Session log (account_session_log) | Append-only log of account events: sign-in, sign-out, failed attempts, password changed, two-factor, SSO link, lock/unlock — and for the signature: esignature (every check of password or PIN at the moment of signing, with outcome and reason) and pin_changed (PIN set, changed or reset; meta.source self_service / admin_reset, meta.channel app / portal, meta.first_setup, meta.pin_version). | History → source Sessions, sign-in history of the account |
| Automated tests | Unit and integration tests in LiteLog's source code that run on every change. File names below are repository paths (api/…). | Part of every release; test report available on request |
| Manual | This documentation (versioned, every change traceable). | docs.litelog.de |
21 CFR Part 11 — Subpart B: Electronic records
§11.10 Controls for closed systems
| § | Requirement (summary) | LiteLog feature | Evidence | Status |
|---|---|---|---|---|
| 11.10(a) | Validation of the system for accuracy, reliability, consistent performance and the ability to discern invalid records | The operator validates (IQ/OQ/PQ). LiteLog provides supplier evidence: this matrix, automated tests per release, release test plan, signature manifest with verification status (invalid signatures become visible as rejected/missing, never accepted silently). | all test files on this page; api/tests/integration/esignature-verify-block.integration.test.ts (11 cases: valid / foreign chip / expired ticket / missing signature) | fulfilled (supplier part) |
| 11.10(b) | Generation of accurate and complete copies in human-readable and electronic form | Form PDF with signature section, reports and history as PDF/CSV export, manifest rows via GET /esignature/events, data export | Data & Reports, History | fulfilled |
| 11.10(c) | Protection of records throughout the retention period | Signature manifest is immutable at database level (trigger rejects UPDATE, DELETE and TRUNCATE), without foreign keys — survives deletion of object and account; originals are never overwritten (correction = new record); daily backups | migration api/src/db/migrations/1836200000000-SignatureEventsImmutable.ts; Security & Privacy; Data Integrity | fulfilled — planned: the same database trigger for the session log (today append-only as code convention, partitioned monthly) |
| 11.10(d) | Access limited to authorized individuals | Sign-in with username + password, optionally two-factor (TOTP) or Microsoft Entra SSO; in the app additionally NFC chip / QR code; roles and permissions per account; property scope for site managers and customer access; signature APIs only for tenants with the active Compliance add-on | Two-factor sign-in, Sign-in with Microsoft, Roles & permissions; api/tests/integration/access-audit.integration.test.ts; package gate tests api/src/router/app-routes/__tests__/package-gates.routes.test.ts | fulfilled |
| 11.10(e) | Secure, computer-generated, time-stamped audit trail; changes do not obscure previous entries | Server-side receipt timestamp independent of the device clock; changes to time entries, roles, work schedules, rules and accounts are logged with user, time and mandatory change reason; archiving instead of deletion; signature manifest and session log append-only | api/tests/integration/config-audit-tx.integration.test.ts, worktime-audit.integration.test.ts, account-audit-tx.integration.test.ts, access-audit.integration.test.ts, record-archive.integration.test.ts (8 cases) | fulfilled |
| 11.10(f) | Operational system checks to enforce permitted sequencing | The server enforces the signature before acceptance: a signature-mandatory action without a valid signature is rejected in the portal and via APIs (response "Esignature required" with the methods allowed at the property); change control: request → decision by a second person → effectiveness | api/tests/integration/esignature-form-response-enforcement.integration.test.ts, esignature-task-completion.integration.test.ts, change-control.integration.test.ts (7 cases) | fulfilled |
| 11.10(g) | Authority checks: only authorized individuals can sign, alter records or use functions | Permission check per action and property; manifest rows are visible only to those allowed to see the object; four-eyes principle of change control (own request cannot be approved); signature only by the signed-in account (foreign chip/QR is rejected and logged) | change-control.integration.test.ts; esignature-verify-block.integration.test.ts (cases chip_mismatch, qr_mismatch, ticket_account_mismatch); api/src/service/esignature/esignature-attempt.test.ts | fulfilled |
| 11.10(h) | Device checks to determine the validity of the data source | Device identifier (device_unique_id) in the manifest and the session log; the offline grant of the PIN is issued only to registered app devices and accepted only in the app's synchronization path — portal and APIs neither receive nor redeem a grant | api/src/service/esignature/offline-pin-grant.test.ts (6 cases: account, tenant and PIN-version binding, expiry); esignature-verify-block.integration.test.ts | fulfilled |
| 11.10(i) | Education, training and experience of persons | Operator obligation. LiteLog supports it with this manual and with notes in the signature dialog (signer, meaning, binding nature). | Digital Signature | operator |
| 11.10(j) | Written policies holding individuals accountable for their electronic signatures | Operator SOP. LiteLog shows the binding statement (equivalence to the handwritten signature) and the note not to share the PIN at every signature. | Digital Signature → Signing in the portal | operator — planned: logged acknowledgement at the first PIN setup (pin_changed.meta.acknowledged_at) |
| 11.10(k) | Controls over system documentation (distribution, access, change history) | Manual and technical documentation are versioned; every change is traceable with time and author; the published version matches the delivered release | docs.litelog.de; change history of the documentation repository | fulfilled |
§11.30 Controls for open systems
LiteLog is operated as a closed system (access only for persons created by the operator; TLS transport encryption; encryption of data at rest). The additional measures for open systems therefore do not apply — see Security & Privacy.
§11.50 Signature manifestations
| § | Requirement | LiteLog feature | Evidence | Status |
|---|---|---|---|---|
| 11.50(a)(1) | Printed name of the signer | signer_name and signer_username are stamped into the manifest at the moment of signing (survive renaming or deletion of the account); the dialog shows "You are signing as …" before entry | manifest fields; detail views; form PDF | fulfilled |
| 11.50(a)(2) | Date and time of the signature | signed_at (moment of signing on the device, relevant offline) and received_at (server receipt, independent of the device clock); the dialog points out the server timestamp | manifest fields | fulfilled |
| 11.50(a)(3) | Meaning of the signature | meaning: submission (form response, incident report, task completion, "Not feasible", tour completion) or archiving/approval (change control decision); the dialog states the meaning before entry | manifest field meaning; Change Control | fulfilled — planned: finer meanings (completion, not feasible, tour completion) in the manifest as well |
| 11.50(b) | Manifestations are part of every human-readable form of the record | Signature status in the detail views, dedicated signature section in the form PDF, manifest rows via the API | Digital Signature → Evidence | fulfilled |
§11.70 Signature/record linking
| § | Requirement | LiteLog feature | Evidence | Status |
|---|---|---|---|---|
| 11.70 | Signature is inseparably linked to the record and cannot be excised, copied or transferred | payload_hash = SHA-256 of the canonicalized record in the manifest; assignment via object_type + object_uuid; manifest immutable at database level; signature ticket bound to account, method and tenant and expiring after 10 minutes | api/src/service/esignature/esignature.service.test.ts (computePayloadHash: deterministic, order-independent); api/src/service/token/auth-token-service.test.ts (7 cases: ticket ≠ access token, binding, lifetime); migration 1836200000000-SignatureEventsImmutable.ts | fulfilled — planned: single use of the ticket (jti) so that a ticket cannot be used twice within its 10 minutes |
21 CFR Part 11 — Subpart C: Electronic signatures
§11.100 General requirements
| § | Requirement | LiteLog feature | Evidence | Status |
|---|---|---|---|---|
| 11.100(a) | Signature is unique to one individual and never reused or reassigned | Username unique per tenant; every account has an internal identifier that is never reassigned; the signature PIN is set exclusively by the person — the administration can only remove it, never set or view it; NFC chip and QR code are bound to the account | api/tests/integration/esignature-pin.integration.test.ts (8 cases); session log pin_changed with meta.source | fulfilled |
| 11.100(b) | Identity verification before assigning the signature | Operator obligation when creating the account (onboarding). LiteLog logs creation, invitation and property assignment of the account. | api/tests/integration/account-invite-audit.integration.test.ts, account-property-assignment-audit.integration.test.ts | operator |
| 11.100(c) | Certification to the FDA that electronic signatures are legally binding | Operator obligation (letter to the FDA). LiteLog shows the binding statement at every signature. | — | operator |
§11.200 Signature components and controls
LiteLog's interpretation of §11.200(a)(1): The electronic signature consists of two components. The first component is the signed-in session — username + password, optionally with two-factor or Microsoft SSO; in the LiteLog app also NFC chip or QR code as sign-in credential. The second component is the secret signature component at the moment of signing: the signature PIN (or the re-entered password). In the portal a session expires after 20 minutes of inactivity (access token); the app session is bound to the registered device and can be locked.
| § | Requirement | LiteLog feature | Evidence | Status |
|---|---|---|---|---|
| 11.200(a)(1)(i) | First signing in a session with all components, subsequent signings with at least one | LiteLog is stricter: every signature requires the secret component (PIN or password); the session (first component) is a prerequisite for every call. A signature ticket is valid for 10 minutes, only for this account and this method. | esignature-pin.integration.test.ts; auth-token-service.test.ts | fulfilled |
| 11.200(a)(1)(ii) | Signings outside a continuous session with all components | After the session expires a new sign-in is required; the offline grant of the PIN in the app only replaces the server check, not the PIN entry — and it expires on sign-out, PIN change or reset | offline-pin-grant.test.ts | fulfilled — planned: sign-in method of the session in the manifest (meta.session_amr) |
| 11.200(a)(2) | Only the genuine owner can use the signature | PIN can only be set by the person (password confirmation), never stored in clear text (hash), administration can only remove it; NFC chip/QR code must belong to the signed-in account; lock after 5 failed attempts for 15 minutes | esignature-pin.integration.test.ts; api/src/service/account/pin-lockout.test.ts; esignature-verify-block.integration.test.ts | fulfilled |
| 11.200(a)(3) | Misuse requires the collaboration of at least two individuals | The administration does not know the PIN and cannot set it; a reset is logged (pin_changed, admin_reset, with the acting account) and forces the person to set a new one; binding statement and no-sharing note in the dialog | session log; Digital Signature → Setting up the PIN | fulfilled |
| 11.200(b) | Biometric signatures | Not used. | — | not applicable |
§11.300 Controls for identification codes/passwords
| § | Requirement | LiteLog feature | Evidence | Status |
|---|---|---|---|---|
| 11.300(a) | Uniqueness of the identification code/password combination | Username unique per tenant; passwords as bcrypt hash; PIN as hash with version counter (pin_version) | Security & Privacy | fulfilled |
| 11.300(b) | Periodic checking, recalling or revising | Password and PIN can be changed by the person at any time (each with password confirmation); the administration can reset the password, remove the PIN, reset two-factor, lock or archive the account; all events in the session log. Forced rotation is governed by the operator's SOP. | session log (password_changed, password_reset, pin_changed, mfa_reset) | fulfilled (rotation: operator) |
| 11.300(c) | Loss management procedures | Password reset via e-mail link; forgotten PIN → new PIN with password; compromised PIN → change immediately or removal by the administration (offline grants expire); reassign NFC chip; two-factor via recovery codes or administration | Digital Signature → FAQ, Two-factor sign-in | fulfilled |
| 11.300(d) | Transaction safeguards against unauthorized use with detection and reporting | Signature PIN: lock after 5 failed attempts for 15 minutes per account (online and offline); sign-in: account lock after 10 failed attempts for 15 minutes; signature APIs additionally IP-throttled; every failed attempt in the session log (esignature with reason, login_failed); rejected signature attempts in the app (foreign chip) are reported as manifest row rejected | pin-lockout.test.ts; esignature-attempt.test.ts (8 cases); session log | fulfilled — planned: account lock for the password signature as well (today IP throttle + log) |
| 11.300(e) | Testing of devices that bear codes (tokens, cards) | NFC chips and QR codes are checked server-side against the account at every signature; a chip can be assigned to one account only; replacement via the administration | Digital Signature, esignature-verify-block.integration.test.ts | fulfilled |
EU GMP Annex 11 — Computerised systems
| § | Requirement | LiteLog feature | Evidence | Status |
|---|---|---|---|---|
| 9 Audit trails | Record of all GMP-relevant changes and deletions with reason, time and person; regular review | Mandatory change reason for correction and deletion of time entries; archiving instead of deletion; configuration audit (templates, rules, roles, work schedules); server-side timestamps; history with filters and export for review | see §11.10(e); History | fulfilled |
| 12 Security | Physical and logical access control, logging of access and changes, management of user permissions | Roles and permissions, two-factor, SSO, property scope; session log for sign-in, sign-out, failed attempts and credential changes; hosting in the EU with encryption | see §11.10(d); Security & Privacy | fulfilled |
| 14 Electronic signature | Same impact as a handwritten signature, permanent link to the record, date and time | Binding statement in the dialog; payload_hash and immutability of the manifest; signed_at / received_at | see §11.50, §11.70 | fulfilled |
Open items (planned)
These items are planned and will be implemented with upcoming releases. Until then they are to be considered in your risk assessment:
- Single use of the signature ticket — A ticket is currently valid for 10 minutes for account and method; an identifier per ticket (
jti) is to rule out reuse within that time. - Account lock for the password signature — Failed attempts of the password signature are logged and IP-throttled; the lock per account (as for PIN and sign-in) follows.
- Database trigger for the session log — The session log is write-only in the application; the hard database protection against change and deletion (as for the signature manifest) follows.
- Acknowledgement at the first PIN setup — A logged confirmation of the binding nature (
acknowledged_at) when setting the PIN for the first time. - Sign-in method of the session in the manifest — Which first component (password, two-factor, SSO, NFC, QR) the session was based on.
- Finer meanings in the manifest — Completion, "Not feasible" and tour completion as separate values alongside submission and archiving.
Frequently asked questions
Is LiteLog "Part 11 validated"?
No — no vendor can validate a system for you. Validation (IQ/OQ/PQ) is part of your quality system and relates to your specific use. LiteLog provides the supplier evidence: this conformance matrix, automated test evidence, the audit trail and the signature manifest.
Where do I get the test evidence?
The test files named here are part of LiteLog's source code and run on every change. For your validation file, the LiteLog team provides a test report of the release in use on request.
Is signing with the PIN alone sufficient — or does it have to be the password?
Both are equivalent secret signature components; the PIN is intended for mobile use (fast, offline-capable). Which methods are permitted at a property is configured under tamper protection. For accounts that sign in via SSO and have no LiteLog password, the PIN is the signature component.
Related pages
- Digital Signature — setup, signing in app and portal, signature PIN, offline behavior
- Data Integrity & ALCOA+ — data-handling fundamentals
- Change Control — four-eyes approval for corrections, archiving and settings
- Security & Privacy — hosting, encryption, backups
- History (activity log) — view and export session events
- Two-factor sign-in — second factor for sign-in