Compliance Mapping · FDA 21 CFR Part 11
How Jope.SMB satisfies FDA 21 CFR Part 11 (Electronic Records; Electronic Signatures). Each control maps to the system layer that implements it, plus the evidence source (code path, test, audit table, or artifact).
note
This page is a design-intent mapping. Full CSA (Computer System Assurance) evidence — including IQ / OQ / PQ protocols and test execution records — lives in the internal CSA package (not published here).
§11.10 · Controls for Closed Systems
| Sub-control | Requirement | Implementation Layer | Evidence |
|---|---|---|---|
| §11.10(a) | Validation of systems | Full stack | IQ / OQ / PQ protocols; CSA package |
| §11.10(b) | Accurate & complete records | Jope.Core · Historian | TimescaleDB schema, 7-year retention, append-only tables |
| §11.10(c) | Record protection | Jope.Core · FileStorage + Backup | WAL-mode SQLite snapshots; encrypted backups (AES-256); scheduled + on-demand |
| §11.10(d) | Limit access to authorized | Jope.Core · Identity + Jope.UI · Login | User / Role / Permission store; RBAC enforced at command boundary; session idle lock |
| §11.10(e) | Audit trail (append-only, computer-generated) | Jope.Core · Compliance · AuditTrail | audit_events table; hash-chained; writes are append-only; cannot be edited via UI |
| §11.10(f) | Operational system checks | Jope.SMB.App · DeviceValidationService | Device state machine; connection health; alarm on comm loss |
| §11.10(g) | Authority checks | Jope.Core · Identity · RBAC | Permission check on every privileged command; UI disable + tooltip when lacking permission |
| §11.10(h) | Device checks | Jope.SMB.App · Device I/O | Driver-level validation; firmware version recorded; calibration expiration tracked |
| §11.10(i) | Personnel training | HR + audit | Training records in operator profile; linked to electronic signature |
| §11.10(j) | Written policies for electronic signatures | Organizational SOPs | Not implemented by software; referenced in User Manual |
| §11.10(k) | Documentation control | Versioned SOPs + this doc site | Git history; versioned spec releases |
§11.30 · Controls for Open Systems
Jope.SMB is a closed system (Plant IPC, no public network access, authenticated-only access). §11.30 additional controls (encryption in transit, digital signatures) therefore do not apply beyond what §11.10 already requires.
§11.50 · Signature Manifestations
| Requirement | Implementation |
|---|---|
| Printed name of signer | Recorded in signature record |
| Date & time of execution | UTC timestamp, server-side, second-precision |
| Meaning (review / approval / authorship) | Required field in signature dialog; enum-enforced |
§11.70 · Signature / Record Linking
- Every signature record stores
context_ref(e.g.,BatchId:PR-2026-0487/transition:start) - The corresponding record carries
signature_id - Signature record is hash-chained, making unlinking detectable
§11.100 · Signature Uniqueness
| Sub-control | Requirement | Implementation |
|---|---|---|
| §11.100(a) | Signature unique to individual | One electronic signature per User record; employee id is unique |
| §11.100(b) | Verified identity before allocating | User creation requires HR verification; evidence attached to user record |
| §11.100(c)(1) | Certified to FDA that signatures are legally binding | Organizational — done once at system commissioning |
§11.200 · Electronic Signature Components & Controls
| Requirement | Implementation |
|---|---|
| At least two identification components | Employee ID + password (something you know × 2) |
| Both components used for each signature | Required by Jope.UI signature dialog |
| All components revocable | Admin can reset password / disable user; changes audited |
| First signing of session uses all components; subsequent may be abbreviated if within session | Configurable session policy (default: re-enter password every time for safety) |
§11.300 · Controls for Identification Codes / Passwords
| Requirement | Implementation |
|---|---|
| §11.300(a) Unique combination (ID + password) | Employee ID uniqueness enforced; password hashing (Argon2id) |
| §11.300(b) Periodic password changes | Password expiration policy (default 90 days), expired-password dialog |
| §11.300(c) Loss/disablement procedure | User.Status = Disabled immediately blocks login; audit event emitted |
| §11.300(d) Unauthorized use safeguards | Session idle lock (default 120 s); 3 failed logins → lockout |
| §11.300(e) Testing of tokens | N/A (password-based); future 2FA will add hardware token testing |
Signature Flow Summary
See Data Flow · Electronic Signature for the detailed sequence.
4-Eyes Principle (Segregation of Duties)
Beyond §11 strict requirements, Jope.SMB enforces 4-eyes principle for high-risk mutations:
- User creation / modification / deletion
- Role / permission changes
- Backup restore (dual approval)
Implemented as ChangeRequest state machine (Stateless) with guards:
approver ≠ requester(no self-approve)- For dual approval: two distinct approvers required
This exceeds §11 baseline and aligns with SoD principles from industry best practice.
Backup & Restore
- Scheduled: daily full backup, encrypted with AES-256, retention 90 days
- On-demand: manual backup button in Backup page
- Storage: local + NAS (
\\nas01\backup) + optional cloud (AWS S3 / Azure Blob) - Restore: requires dual approval (see 4-eyes above), produces audit event
RestoreQueued
Traceability
Every audit event is traceable to:
- User — actor (employee id, display name, role at time of action)
- Session — session id, IP address, client machine name
- Signature (if required) — signature id + hash-chain position
- Data subject — the batch / recipe / user / role being acted on
Query examples are in the Audit Log Viewer operator documentation (coming soon).