Annex 11 electronic signatures and Part 11: what inspectors expect
A practical reading of EU GMP Annex 11 and 21 CFR Part 11: signatures, audit trails, access control, ALCOA+ and periodic review, and the evidence an inspector asks to see.
Your site is moving batch record review, deviation approvals or SOP sign-off from wet ink to an electronic system, or you already have and an inspection is on the calendar. Either way, somebody will soon ask you to show that an electronic signature in your system means what a handwritten one used to mean, and that nobody can quietly change a record after it was signed. This article sets out what EU GMP Annex 11 and 21 CFR Part 11 actually require of electronic records and signatures, how the MHRA and PIC/S data integrity guidance turns those requirements into inspection practice, and the specific evidence to have ready.
Two texts, one intent
EU GMP Annex 11 (EudraLex Volume 4, Computerised Systems) has applied since 30 June 2011. It is short, about five pages, and principle-based: risk management decides the extent of validation and data integrity controls. A substantially longer revision was published in draft for consultation in July 2025 alongside a revised Chapter 4 and a new Annex 22 on artificial intelligence. Until the final text is adopted and comes into operation, the 2011 version is the one you will be inspected against, though the draft is a fair guide to where inspectors' attention is heading.
21 CFR Part 11 is the US rule for electronic records and electronic signatures. It is more prescriptive than Annex 11, and if you supply the US market or a US partner audits you, you will meet it. The two texts rarely conflict. Where Annex 11 says what outcome is expected, Part 11 often says exactly which pieces of information must be present, so a system designed for both tends to satisfy each.
Electronic signatures: meaning, linking and identity
Annex 11 clause 14 is three lines long. Electronic signatures are expected to have the same impact as handwritten signatures within the boundaries of the company, be permanently linked to their respective record, and include the time and date they were applied. Clause 15 adds that where a system records batch certification, only Qualified Persons may certify, and they must do so with an electronic signature.
Part 11 fills in the detail. Section 11.50 requires a signed record to show the printed name of the signer, the date and time of signing, and the meaning of the signature, such as review, approval, responsibility or authorship, and those details must appear in any human-readable form of the record, including a printout or PDF. Section 11.70 requires signatures to be linked to their records so they cannot be excised, copied or transferred to falsify another record. Section 11.100 makes each signature unique to one person and never reassigned, and 11.200 requires at least two distinct identification components, such as a user ID and password, for signatures not based on biometrics.
The MHRA's GXP data integrity guidance (section 6.14) is blunt about the common shortcut: an inserted image of a signature, or a footnote saying a document was signed electronically, is not adequate unless it came from the validated signature process. The guidance calls the visible name, title, date and meaning the "signature manifestation". PIC/S PI 041-1 adds the test that catches most weak systems: if a signed record is changed afterwards, the signature should be invalidated until the record has been reviewed again and re-signed.
So, when you test a system, sign a deviation closure and then try three things. Edit a field on the signed record. Print or export it and check the manifestation is still there. Ask an administrator to change who signed it. In a well-designed system, the first invalidates the signature or forces a new version, the second shows name, date, time and meaning, and the third is impossible, or at minimum leaves an audit trail entry that names the administrator.
Audit trail requirements in practice
Annex 11 clause 9 asks that, based on a risk assessment, the system records all GMP-relevant changes and deletions, with the reason documented, and that audit trails are available, convertible to a generally intelligible form and regularly reviewed. Part 11 section 11.10(e) requires secure, computer-generated, time-stamped audit trails that independently record operator entries and actions that create, modify or delete records, without obscuring the information previously recorded.
The MHRA guidance (section 6.13) describes the content as the "who, what, when and why" of each action, with the time zone where relevant, and says users should not be able to amend or switch off the audit trail. PIC/S PI 041-1 section 9.6 goes further. Audit trail functionality should be enabled and locked; if an administrator can deactivate it, that act should itself be recorded automatically. Critical audit trails should be reviewed with the other records of an operation before it is complete, for example before batch release. Non-critical trails can be reviewed during periodic system review.
The review is where sites most often fall short. Nobody expects a reviewer to read every log-on event; the MHRA guidance says so directly. What inspectors expect is a documented decision about which audit trail entries matter, a procedure saying who reviews them and when, and records showing that it happened. Review by exception is accepted: filter for changes to critical fields, deletions, signatures applied after a long delay, or edits by administrators, and record what you found and what you did about it.
A worked example. A deviation is raised for a temperature excursion in a cold store. The investigator first records the excursion as 40 minutes, then changes it to 25 minutes two days later. The audit trail should show both values, who made the change, when, and the reason ("corrected after review of the logger export"). The reviewer approving the deviation closure should see that change, and the record of the audit trail review should show it was looked at. If the reason field reads "typo" and the logger data says 40 minutes, you have a data integrity finding of your own making.
Access control
Annex 11 clause 12 requires physical or logical controls restricting access to authorised people, proportionate to the system's criticality; records of creating, changing and cancelling access authorisations; and systems designed to record the identity of anyone entering, changing, confirming or deleting data, with date and time. Part 11 section 11.10(d) and (g) require access to be limited to authorised individuals and authority checks on who can sign, alter records or perform operations.
The MHRA guidance is explicit that shared logins and generic user access should not be used for GxP data, even where individual accounts cost extra licences. System administrator access should be limited to as few people as possible, and administrator rights should not go to people with a direct interest in the data, such as the analyst whose results are in the system. PIC/S adds that the system should be able to list every user with their role, and that list should be used in periodic user access reviews.
In a small company this is where things get uncomfortable. The QA manager is often also the system administrator. If that is unavoidable, record the risk assessment, keep a separate named administrator account used only for administration, and have someone else review that account's audit trail.
ALCOA+ as a working checklist
Both the MHRA guidance (section 3.10) and PIC/S PI 041-1 use ALCOA+: Attributable, Legible, Contemporaneous, Original and Accurate, plus Complete, Consistent, Enduring and Available. The MHRA notes there is no difference in expectation whichever acronym you use. It becomes useful when you apply it to one record type at a time.
| Principle | Question to ask of an electronic deviation record |
|---|---|
| Attributable | Can every entry be traced to one named person? |
| Legible | Can it be read and understood for the whole retention period, including exports? |
| Contemporaneous | Are entries timestamped by the system when made, and not backdated? |
| Original | Is the first-captured data kept, or a verified true copy? |
| Accurate | Are critical entries checked, and corrections traceable? |
| Complete | Are all versions, attachments and audit entries kept, including rejected or cancelled ones? |
| Consistent | Do timestamps run in sequence on a synchronised clock? |
| Enduring | Will it survive a system upgrade, a supplier change or a migration? |
| Available | Can you produce it for an inspector within the time they ask? |
Run that table against your deviation, CAPA, change control and training records and you have the backbone of a data integrity risk assessment.
Periodic review
Annex 11 clause 11 requires computerised systems to be periodically evaluated to confirm they remain in a valid state and compliant with GMP. The evaluation should cover, where appropriate, current functionality, deviation records, incidents, problems, upgrade history, performance, reliability, security and validation status. PIC/S PI 041-1 asks that the frequency be set by risk and that the review consider the cumulative effect of changes since the last one.
For a cloud eQMS that receives several releases a year, the cumulative point matters. Each release may have passed its own impact assessment, yet a year of them can change how approvals route or what the audit trail captures. A useful annual review compares the system as validated with the system as it runs today, re-checks user access, samples the audit trail review records, confirms a backup restore was tested (Annex 11 clause 7.2), and ends with a signed conclusion: still in a validated state, or not, with actions.
What inspectors ask to see
Inspectors will usually ask you to demonstrate the system live rather than show them a binder. Expect requests along these lines:
- The inventory of computerised systems and their GMP functions (Annex 11 clause 4.3).
- The validation summary for the system in front of them, and how user requirements trace to tests.
- A signed record, then a demonstration of what happens when someone tries to change it.
- The audit trail for a specific record they choose, and the record of its review.
- The current user list with roles, and the last periodic access review.
- The agreement with the system supplier and your assessment of them (Annex 11 clause 3).
- The last periodic review report and the evidence of a backup restore.
- For batch-release records, a printout showing whether data was changed after original entry (Annex 11 clause 8.2).
Practise this. Have the person who will drive the demonstration rehearse it on a test record, with an independent colleague playing the inspector and picking the record.
The takeaway
Annex 11 and Part 11 ask the same thing in different words: a signature has to identify one person, state what they meant, stay bound to the exact record they signed, and survive printing; an audit trail has to show who changed what, when and why, and someone has to read it. Pick three record types this week, run the ALCOA+ table and the signature tests against them, and fix what fails before an inspector finds it.
If you want to run these tests against a system built for regulated manufacturers, InnoQualis is an EU-hosted eQMS with an append-only audit trail and electronic signatures designed to support 21 CFR Part 11 and EU GMP Annex 11.
