21 CFR Part 11 and EU GMP Annex 11: clause mapping
| Document id | CS-VAL-09 |
| Title | 21 CFR Part 11 and EU GMP Annex 11 clause mapping |
| Version | 1.0 |
| Applies to | Countersign 1.0.0 |
| Status | Template supplied with the software; to be completed, reviewed and approved by the regulated user |
1. Read this first
- This document is not legal or regulatory advice. It is a technical description written to help a regulated organisation make its own assessment.
- Countersign is not "Part 11 compliant", "Annex 11 compliant", certified or approved by any authority, and software cannot be. Compliance is a property of a validated system in use: software, infrastructure, procedures and trained people together. Most of the clauses below are met mainly by what the organisation does.
- The column "What the clause asks" is a short paraphrase in this document's own words, written to orient the reader. It is not a quotation and it leaves things out. Read the regulation's own text, in the version in force for you, and the guidance of your authority before relying on anything here. Annex 11 in particular is under revision; check which version applies.
- "Supports" means the software has a mechanism that helps. It never means the clause is satisfied.
- Whether Part 11 or Annex 11 applies to your records at all is decided by your predicate rules and your authority's scope guidance, not by the software.
Requirement ids (FR-…) refer to requirements.json; mechanisms are described in the functional specification and data integrity.
Assessment column: complete with Met / Met with procedure ___ / Not applicable / Gap accepted (reference).
2. Summary of known gaps and limits
Read these before the tables. Each is repeated at the clause it concerns.
| No. | Limit in version 1.0.0 | Clauses | What it means for you |
|---|---|---|---|
| G-1 | An approval is not executed by entering a password or other credential in the application at the moment of signing. It requires a session whose sign-in at the identity provider is no older than COUNTERSIGN_SIGN_MAX_AGE_MINUTES (default 15). Inside that window any number of approvals can be given without entering anything again |
11.200(a), Annex 11 clause 14 | Your organisation decides whether this meets its interpretation. A very small maximum age forces authentication for practically every signature |
| G-2 | The recent-sign-in rule is enforced only with OpenID Connect sign-in (entra, oidc). With reverse-proxy sign-in there is no authentication time and no rule. If the provider omits auth_time, the token's issue time is used instead, and the check that a requested fresh sign-in really re-authenticated (authentication no older than 5 minutes) cannot be made |
11.200(a), 11.10(d) | Use OpenID Connect; confirm in the IQ that auth_time is delivered and that a forced sign-in really prompts |
| G-3 | Only "approve" is treated as a signature. Confirming, stepping back (including revoking an approval), retiring and removing are attributable audited actions without the recent-sign-in rule and without a stated meaning | 11.50, 11.200 | Define in procedure which action is the signature required by your predicate rule |
| G-4 | Imports, and configuration changes applied in one step (config apply), are made with the command-line tool. There the acting person and the reviewer are named by the operator; neither is authenticated by the identity provider. (Configuration changes proposed and approved in the application are signed by two authenticated people.) |
11.10(d), 11.10(g), Annex 11 clauses 10, 12 | Procedural and infrastructure control over who can run the tool; a signed change record |
| G-5 | Reading is not restricted: every signed-in person can read every record and the whole audit trail. Read access is not logged | 11.10(d), Annex 11 clause 12 | Limit who can sign in; do not hold data here that some signed-in users must not see |
| G-6 | Refused commands and failed sign-ins are not written to the audit trail | 11.10(d), 11.300(d), Annex 11 clause 12 | Web-server and identity-provider logs, reviewed |
| G-7 | Time stamps come from the application server's clock, not from a trusted time-stamping service. The interface shows times in the viewer's local time zone; stored and exported times are UTC | 11.10(e), Annex 11 clause 9 | Time synchronisation and its monitoring; state the time zone convention in procedure |
| G-8 | The audit trail is tamper-evident, not tamper-proof. A database owner or superuser can disable the append-only triggers. Alteration of the middle of the trail is found by verification; removal of the newest entries after a restart is found only by comparison with an anchored head hash | 11.10(c), 11.10(e), Annex 11 clauses 7, 9, 12 | Scheduled verification, anchoring, segregation of duties |
| G-9 | No retention, archiving or disposal function beyond export and database backup | 11.10(c), Annex 11 clause 17 | Retention and archive procedure |
| G-10 | The CSV export of the audit trail is a summary: it has the signer, time and signature meaning, but describes the change in words instead of giving the full before and after values. The JSON and JSON Lines exports contain everything. There is no print layout | 11.10(b), Annex 11 clause 8 | Use the JSON exports for complete inspection copies; print from the browser or convert exports under your own control |
| G-11 | A session lasts until sign-out or COUNTERSIGN_SESSION_HOURS (default 8); there is no inactivity lock and no server-side revocation; role changes apply at the next sign-in |
11.10(d), 11.300, Annex 11 clause 12 | Screen lock policy; short session lifetime; secret rotation for urgent withdrawal |
| G-12 | The reason for a change is mandatory only for step back, retire, remove, configuration change and the change of an approved record. It is optional on creation and on edits of a draft | Annex 11 clause 9 | Require it by procedure where you need it; approvers reject changes without it |
| G-13 | The project has no certified quality system and offers no supplier audit | 11.10(a), Annex 11 clauses 3, 4 | See supplier assessment; compensate with your own verification |
| G-14 | Imported records are approved versions without an approver of this system; the source system's approver and date are carried as text from the source file and are not verified | 11.10(e), 11.70, Annex 11 clauses 4.8, 14 | Migration validation; use review mode when the source approval cannot be relied on |
3. FDA 21 CFR Part 11
3.1 Subpart B: electronic records
| Clause | What the clause asks (paraphrase) | How Countersign supports it | What remains with the organisation | Assessment |
|---|---|---|---|---|
| 11.10(a) | The system is validated so that it performs accurately, reliably and consistently as intended, and invalid or altered records can be recognised | Requirement catalogue, requirement-tagged automated tests, generated traceability matrix, execution report (node scripts/oq-report.ts), this pack. Altered records are recognised by the hash chain and replay: FR-INT-01 to FR-INT-06, FR-OPS-02, FR-OPS-03; countersign verify; the integrity page: FR-UI-07 |
The validation itself for the intended use: plan, IQ, OQ, PQ, report, change control (G-13). Scheduled verification and anchoring (G-8) | |
| 11.10(b) | Accurate and complete copies of records can be produced in human-readable and electronic form for inspection, review and copying | Export of the audit trail (JSON, JSON Lines, CSV), of all records with all versions (JSON) and of the configuration (JSON): FR-EXP-01, FR-UI-06, countersign export. Exports of the trail can be verified against the hash chain independently of the application |
Procedure for producing inspection copies; choice of format (G-10); a viewer for JSON if inspectors need one; verification that copies are complete | |
| 11.10(c) | Records are protected so that they can be retrieved accurately and readily throughout the retention period | Nothing is ever deleted or overwritten by the application; every version is kept: FR-VER-01, FR-VER-02, FR-LIFE-02; the store is append-only at database level: FR-STO-04; state is rebuilt from the trail: FR-INT-06 | Database backup, restore testing, retention period, archive, media and format longevity (G-9); protection against privileged database users (G-8) | |
| 11.10(d) | System access is limited to authorised individuals | Nothing can be read or written without signing in: FR-SIG-06; identity from the organisation's identity provider by OpenID Connect: FR-SIG-02, FR-SIG-03; tamper-proof session cookie: FR-SIG-01; demo sign-in only when explicitly enabled: FR-SIG-10; proxy headers only with a shared secret: FR-SIG-09 | Account management, password and multi-factor policy, assignment of users to the application, leaver process, access review; access to servers, database and the command-line tool (G-4); no read restriction (G-5); no log of refused attempts (G-6); session handling (G-11) | |
| 11.10(e) | Secure, computer-generated, time-stamped audit trails independently record the date and time of operator entries and actions that create, modify or delete records; changes do not obscure earlier information; the trail is kept as long as the records and is available for review and copying | Every accepted command writes exactly one entry, generated by the server, with time, person, roles, action, record, version, before, after, reason and how the person was identified: FR-AUD-01, FR-AUD-04; refused commands write nothing: FR-AUD-02; entries are in time order: FR-AUD-03, FR-OPS-04; entries cannot be changed or deleted through the application or its database role, and alteration is detectable: FR-STO-04, FR-INT-01 to FR-INT-04; earlier versions stay visible: FR-VER-02, FR-UI-04; the trail is the record store itself, so it lives exactly as long as the records; it can be searched, filtered and exported: FR-UI-06 | Clock synchronisation (G-7); retention (G-9); periodic audit trail review; anchoring (G-8); assessment of imported records (G-14) | |
| 11.10(f) | Operational checks enforce the permitted sequence of steps and events where sequence matters | The state machine Created, Confirmed, Approved is enforced by the engine for every record type; a version cannot be approved unless Confirmed, cannot be edited while Confirmed, a record cannot be retired while others refer to it: FR-WF-01 to FR-WF-08, FR-LIFE-01 to FR-LIFE-04; data is re-validated at each stage: FR-VAL-07 | Business sequences across records (for example "approve the parent before the child is used elsewhere") are yours to define and, if needed, enforce by procedure | |
| 11.10(g) | Authority checks ensure that only authorised individuals can use the system, sign a record, access input or output devices, alter a record or perform an operation | Permissions per role, record type and option level for writing and for approving: FR-ACC-01, FR-ACC-02, FR-WF-05; four eyes: FR-WF-04; import and configure as separate permissions, not available from the web: FR-ACC-03, FR-SIG-08; the actor is taken from the session only: FR-SIG-08 | The role matrix and its approval; group membership in the identity provider; the role map; the command-line tool's stated identity (G-4) | |
| 11.10(h) | Device checks determine, where appropriate, the validity of the source of data input or operational instruction | Writes are accepted only from the application's own pages (custom header and origin check): FR-SIG-07. There is no check of the terminal or device, and no data input from instruments | Decide whether device checks are appropriate for your use (for manually entered master data they usually are not); network restrictions if required | |
| 11.10(i) | People who develop, maintain or use the system have the education, training and experience for their tasks | User guide and operator documentation as training material. The project gives no evidence of its contributors' qualifications (G-13) | Training and training records for users, reviewers, administrators and validation staff | |
| 11.10(j) | Written policies hold individuals accountable and responsible for actions initiated under their electronic signatures | Each signature is attributable to one identity with name, time and meaning: FR-WF-06, FR-AUD-01 | The policy, its communication and acknowledgement | |
| 11.10(k) | Controls over system documentation: distribution, access and use of operating and maintenance documentation; revision and change control with a time-sequenced record of changes to documentation | Documentation is versioned with the source code in the repository; CHANGELOG.md records changes per release |
Controlled copies of this pack, the SOPs and the operator documentation in your document management system | |
| 11.30 | For open systems, additional measures such as document encryption and digital signature standards ensure authenticity, integrity and confidentiality from creation to receipt | The application is meant to be run as a closed system: access controlled by the organisation responsible for the records. TLS is not provided by the application; it is terminated in front of it. Records are not encrypted at rest by the application and audit entries are hashed, not digitally signed with a private key | Classify the system (closed or open). TLS on every hop; encryption at rest in the database or storage if required. If your arrangement is an open system, the additional measures are yours | |
| 11.50(a) | A signed record shows the printed name of the signer, the date and time of signing and the meaning of the signature | The approval entry and the approved version hold the signer's id and name (actor, actorName), the time (at, approvedAt) and the meaning (after.meaning, meaning), stated by the signer before signing: FR-WF-06, FR-UI-02 |
The interface offers one fixed meaning per kind of approval ("I have reviewed this change and approve it for use.", "I approve retiring this record.", "I approve removing this record."), which the signer must tick before the button is enabled; if your predicate rule needs other meanings (for example review versus approval as separate signatures), that is not available. The name shown is the name the identity provider delivers, so keep it the person's full name | |
| 11.50(b) | These items are under the same controls as electronic records and appear in any human-readable form of the record, such as display or printout | They are part of the hashed audit entry and of the version shown in the record's history: FR-UI-04, FR-AUD-04; they are in the CSV export (actor_name, at_utc, signature_meaning), in the JSON and JSON Lines exports and in the database view (signature_meaning) |
No print layout is provided (G-10); decide which human-readable form you present | |
| 11.70 | Signatures are linked to their records so that they cannot be removed, copied or transferred to falsify a record by ordinary means | The approval is an audit entry naming the record and version; its hash covers the signer, time and meaning and chains to the entry before it, and through that chain to the entries that created the version's content: FR-INT-01, FR-INT-02, FR-INT-03, FR-AUD-04. Changing the content afterwards, or moving the signature to another version, breaks verification. A changed record needs a new version and a new approval: FR-VER-01 | Verification schedule and anchoring (G-8). Exports are copies; their link to the original is the hash chain, which the recipient can verify |
3.2 Subpart C: electronic signatures
| Clause | What the clause asks (paraphrase) | How Countersign supports it | What remains with the organisation | Assessment |
|---|---|---|---|---|
| 11.100(a) | Each electronic signature is unique to one individual and is not reused by or reassigned to anyone else | A signature is bound to the identifier the identity provider issues (oid with Entra ID by default, sub otherwise): FR-SIG-02, FR-SIG-04. The application has no accounts of its own to reuse |
The provider must issue unique, never reassigned identifiers; no shared or generic accounts; correct choice of COUNTERSIGN_ID_CLAIM |
|
| 11.100(b) | The organisation verifies an individual's identity before establishing or assigning their electronic signature | None; accounts are created outside the application | Identity verification when accounts are issued | |
| 11.100(c) | Persons using electronic signatures certify to the agency that they are intended to be the legally binding equivalent of handwritten signatures | None | The certification, and the internal acknowledgement by signers | |
| 11.200(a)(1) | A non-biometric signature uses at least two distinct identification components such as an identification code and a password. In a series of signings during one continuous period of controlled system access, the first uses all components and later ones at least one that only the individual can execute; signings outside such a period use all components each time | The identification components are entered at the identity provider, under its policy (commonly user name, password and a second factor), not in the application. The application accepts an approval only when that authentication is no older than the configured maximum age, and otherwise sends the person back to the provider with a request to authenticate again: FR-SIG-05. Within the window, approvals are given by a deliberate action in the signature panel (FR-UI-02) without entering a component again | Gap G-1, G-2, G-3: decide and document whether authentication at the identity provider within N minutes, followed by a deliberate approval action, satisfies your reading of this clause, including for the second and later signings in a session. Options: set the maximum age so low that each signature needs a fresh authentication; define the "continuous period" in procedure; or conclude that the mechanism does not meet your interpretation | |
| 11.200(a)(2) | Signatures are used only by their genuine owners | Session bound to the authenticated person; recent sign-in for approvals: FR-SIG-01, FR-SIG-05; four eyes means a misused account still needs a second, different account: FR-WF-04 | Policy against sharing credentials; screen lock; training (G-11) | |
| 11.200(a)(3) | Signatures are administered so that use by anyone other than the owner requires the collaboration of two or more individuals | Depends on the identity provider (for example password plus a personal second factor, administrator resets that are logged) | The provider's administration controls; segregation between identity administrators and application roles | |
| 11.200(b) | Signatures based on biometrics are designed so that only their genuine owners can use them | Not applicable to the application; if the identity provider uses biometrics as a factor, that is within the provider | Assessment of the provider if biometrics are used | |
| 11.300(a) | Each combination of identification code and password is unique | Not in the application; it stores no passwords | Identity provider | |
| 11.300(b) | Identification codes and passwords are periodically checked, recalled or revised | Not in the application | Identity provider policy; periodic access review | |
| 11.300(c) | Lost, stolen or compromised tokens, cards and devices are deauthorised and replaced under suitable controls | Not in the application. A running session is not revoked when an account is disabled (G-11) | Identity provider procedures; for urgent cases rotate COUNTERSIGN_SESSION_SECRET to end all sessions |
|
| 11.300(d) | Transaction safeguards prevent unauthorised use of passwords or identification codes, and attempts at unauthorised use are detected and reported urgently | Sign-in answers that fail any check give no session: FR-SIG-03; altered cookies are rejected: FR-SIG-01. The application does not record or report refused attempts (G-6) | Identity provider lockout and alerting; review of web-server logs for status 401 and 403 | |
| 11.300(e) | Devices that bear or generate identification codes or passwords are tested initially and periodically | Not in the application | Identity provider and device management |
4. EU GMP Annex 11
| Clause | What the clause asks (paraphrase) | How Countersign supports it | What remains with the organisation | Assessment |
|---|---|---|---|---|
| 1 Risk management | Risk management is applied through the lifecycle, considering patient safety, data integrity and product quality; the extent of validation and of data integrity controls is justified by documented risk assessment | A proposed functional risk assessment; a risk rating on every functional requirement in requirements.json | Your own assessment for your use, kept current | |
| 2 Personnel | Close cooperation between process owner, system owner, qualified persons and IT; appropriate qualifications, access levels and defined responsibilities | Roles proposed in the validation plan, section 4 | Naming, qualifying and training the people | |
| 3 Suppliers and service providers | Formal agreements with third parties; supplier competence and reliability assessed, audit need based on risk; documentation of commercial products reviewed against user requirements; supplier quality information available to inspectors | Facts for the assessment in supplier assessment. There is no contract partner, no agreement and no audit unless you engage one (G-13) | The supplier assessment decision; agreements with your hosting, database and identity providers; review of this documentation against your requirements | |
| 4 Validation | Validation documents cover the lifecycle; change control and deviations recorded; an inventory of systems; current system description; user requirements traceable through the lifecycle; supplier assessed; evidence of adequate test methods and scenarios, including limits and error handling; data migration checked | This pack; UR to FR to test traceability generated and checked on every test run; negative and limit tests in the suite and in the OQ; migration with rehearsal, per-row accounting, reconciliation and cross-reference: FR-MIG-01 to FR-MIG-08 | Everything executed and approved by you; your system inventory; migration validation (G-14) | |
| 5 Data | Systems exchanging data electronically with other systems include built-in checks for correct and secure entry and processing | No electronic interface for data entry exists except the migration tool, which applies the same validation as manual entry: FR-MIG-03. Outgoing data: exports and the database view | Validation of any interface or report you build on the exports or the view; build them on the view or the exports, not on the table's plain columns, which are not covered by the hash chain (data integrity, section 5) | |
| 6 Accuracy checks | Critical data entered manually gets an additional check of accuracy, by a second operator or by validated electronic means | The core function: every version is confirmed by its author and approved by a second authorised person before it takes effect: FR-WF-04 to FR-WF-06; field validation by type, range, pattern, uniqueness and reference: FR-VAL-01 to FR-VAL-07 | Defining which fields are critical and configuring their rules; the diligence of the approver | |
| 7 Data storage | Data is secured against damage by physical and electronic means; stored data is checked for accessibility, readability and accuracy; access is ensured throughout the retention period; regular backups; backup integrity and restore ability checked during validation and periodically | Append-only store with chain triggers: FR-STO-01 to FR-STO-04; the whole trail is re-checked at every server start and by countersign verify, which can be run on a restored backup: FR-OPS-02, FR-INT-06 |
Backup, restore tests, physical security, retention (G-8, G-9). Verification of a restore needs the anchored head hash to prove it is complete | |
| 8 Printouts | Clear printed copies of electronically stored data can be obtained; for records supporting batch release, printouts indicate whether data was changed since original entry | Exports in open formats; the record's history shows every version and whether it was changed: FR-UI-04, FR-UI-06. No print layout (G-10) | Procedure for inspection copies; print from the browser or convert exports under your own control | |
| 9 Audit trails | Based on risk, the system records all GMP-relevant changes and deletions in a system-generated audit trail; the reason for change or deletion is documented; audit trails are available, convertible to a generally intelligible form and regularly reviewed | Every change is an audit entry; there are no deletions, only retire and remove as audited changes: FR-AUD-01, FR-LIFE-01, FR-LIFE-02; reasons mandatory for the cases listed in G-12: FR-WF-09, FR-UI-08; searchable, filterable, exportable: FR-UI-06, FR-EXP-01; the trail cannot be switched off because it is the data store | Regular review (SOP templates, SOP 2; checklist in data integrity, section 9); reasons where not enforced (G-12); clock (G-7) | |
| 10 Change and configuration management | Changes to the system, including configuration, are made in a controlled manner under a defined procedure | Configuration is a versioned document; a change is proposed with a reason by one authorised person and takes effect when a second one approves it with a fresh sign-in, each step an audit entry with the document's hash: FR-CFG-07 to FR-CFG-09, FR-CFG-13; it is refused while it would strand existing records: FR-CFG-04, FR-CFG-10, FR-CFG-11; from the command line a change in one step needs the permission, a reason and a second named person: FR-CFG-01 to FR-CFG-06; the web interface cannot set a configuration in one step: FR-SIG-08; software releases are versioned with a changelog | Change control procedure for configuration, role map, environment, software and infrastructure (G-4); validation plan, section 9 | |
| 11 Periodic evaluation | Systems are periodically evaluated to confirm they remain valid and compliant, covering functionality, deviations, incidents, problems, upgrades, performance, reliability, security and validation status | countersign status and verify, /api/health, exports and the audit trail provide the data |
The evaluation (SOP templates, SOP 8) | |
| 12 Security | Physical and logical controls restrict access to authorised persons; extent depends on criticality; creation, change and cancellation of access rights are recorded; the system records the identity of operators entering, changing, confirming or deleting data with date and time | Sign-in required: FR-SIG-06; role-based write and approve permissions: FR-ACC-01 to FR-ACC-03; identity, roles and time on every entry: FR-AUD-01; the roles a person held at each action are in the trail (actorRoles), so changes of rights become visible when they act |
Physical security; the identity provider's record of granting and withdrawing access (the application records roles only as they are used); read access (G-5); refused attempts (G-6); sessions (G-11); privileged database access (G-8); the command-line tool (G-4) | |
| 13 Incident management | All incidents, not only failures and data errors, are reported and assessed; root causes of critical incidents identified, corrective and preventive actions taken | The service stops accepting changes and reports an integrity fault with the entry number and cause: FR-OPS-02, FR-OPS-03, FR-OPS-06 | Incident procedure; integrity-fault handling (SOP templates, SOP 6); monitoring | |
| 14 Electronic signature | Electronic signatures have, within the company, the same impact as handwritten ones, are permanently linked to their record, and include the time and date they were applied | Approval recorded with signer, time and meaning; linked to the record version by the hash chain: FR-WF-06, FR-AUD-04, FR-INT-01 to FR-INT-03; recent sign-in required: FR-SIG-05 | The internal rule giving these signatures their standing; G-1, G-2, G-3; imported approvals (G-14) | |
| 15 Batch release | Where a system records certification and batch release, only qualified persons can certify, identified and recorded by electronic signature | Not designed for batch certification. If used for it, only the generic approve mechanism is available | Do not use for batch release without your own assessment; restrict the approve permission to qualified persons through the configuration and the identity provider | |
| 16 Business continuity | Provisions ensure continuity of support for critical processes if the system fails; the time to bring alternatives into use is based on risk; arrangements are documented and tested | Several application servers can share one PostgreSQL store: FR-STO-05; health endpoint for failover decisions: FR-OPS-06; with an integrity fault reading continues while writing stops: FR-OPS-02 | Continuity plan, fallback procedure, later entry of changes made on paper (SOP templates, SOP 9), database high availability, tests | |
| 17 Archiving | Data may be archived; archived data is checked for accessibility, readability and integrity; after relevant changes to the system the ability to retrieve it is ensured and tested | Exports in open formats; a documented hash algorithm and a standalone verification procedure that does not need the application (data integrity, section 6). No archive function (G-9) | Archive procedure, media, periodic readability and integrity checks, retrieval tests after upgrades |
5. Assessment sign-off
| Item | Entry |
|---|---|
| Regulations and versions assessed against | |
| Gaps accepted, with justification and compensating controls (reference the risk assessment) | |
| Decision on gap G-1 (execution of signatures) | |
| Open actions |
| Role | Name | Signature | Date |
|---|---|---|---|
| Assessed by | |||
| Process owner | |||
| Quality assurance |