Every requirement that applies to a handwritten record applies to an electronic one. The difference is that a computer can enforce the rules, and an inspector expects it to. Annex 11 of EU GMP is the text, with PIC/S PI 041-1 section 9 explaining how it is inspected, and it is shorter than people think. This guide takes the sections that generate findings, in the order an inspector asks about them.
Who can log in
Annex 11 section 12.1 requires physical and logical controls to restrict access to computerised systems to authorised persons, and 12.3 requires that the creation, change and cancellation of access authorisations are recorded. PIC/S PI 041-1 section 9 adds that each user must have a unique identity, so that no two people share a login, and that the system should enforce it rather than a procedure. The consequence is a rule with no exceptions: one person, one login.
A shared login is the finding that inspectors find most quickly and classify most severely, because it makes every record the system has ever produced unattributable. It does not help that the analysts wrote their initials on the printout; the initials attribute the paper, not the electronic record or the audit trail. It does not help that a logbook records who was on the instrument; the audit trail is what the inspector reads, and it says 'QCLAB'. The only fix is a unique account for every user, and it is worth every licence fee.
What each person can do
Unique identity is necessary but not sufficient. The second question is what each identity is allowed to do. The principle in Annex 11 and PI 041-1 is that privileges match the role, and the specific expectation, stated in PIC/S PI 041-1 section 9.3 and the EMA data integrity Q&A, is that people who generate data should not be able to delete it, change the audit trail configuration, or alter the system clock. Administrator rights belong to IT or a named system owner, in a separate account from the one they use for any routine work.
- A documented list of roles for each system, with the privileges of each role, approved by the system owner and QA.
- A current user list with each person's role, reviewed at a defined interval and whenever someone leaves or changes job.
- Administrator accounts held by named people who do not generate GMP data on that system, or if they must, held separately from their user account.
- No routine user able to delete raw data, disable or modify the audit trail, or change date and time.
What the audit trail must capture
Annex 11 section 9: 'Consideration should be given, based on a risk assessment, to building into the system the creation of a record of all GMP-relevant changes and deletions (a system generated audit trail). For change or deletion of GMP-relevant data the reason should be documented. Audit trails need to be available and convertible to a generally intelligible form and regularly reviewed.' PIC/S PI 041-1 section 9 adds the practical expectations: the audit trail is secure, generated by the system, time-stamped, records the previous value as well as the new one, cannot be edited by the user, and is retained as long as the record it belongs to.
Put together, an adequate audit trail records who made a change, what the value was before and after, when, and why. It is generated by the system, not by the user. The user cannot edit it. It is retained with the record for the same period. And, the clause that generates findings, it is reviewed.
Electronic signatures: Annex 11 section 14 and eIDAS
Annex 11 section 14 requires electronic signatures to have the same impact as handwritten ones within the company, be permanently linked to their record, and include the time and date. Annex 11 leaves the mechanics to the site, and the eIDAS Regulation (EU) 910/2014, which governs electronic signatures across the single market, supplies the vocabulary. Four expectations do most of the work.
- Manifestation: the signed record must show the name of the signer, the date and time, and the meaning of the signature (review, approval, responsibility, authorship). Annex 11 section 14(c) requires the time and date; the meaning is what makes the signature usable by a reviewer.
- Linking: Annex 11 section 14(b) requires the signature to be permanently linked to its record, so that it cannot be excised, copied or transferred to falsify another record. eIDAS Article 26(d) says the same for advanced electronic signatures: linked to the signed data so that any subsequent change is detectable.
- Uniqueness and identity: eIDAS Article 26(a) and (b) require the signature to be uniquely linked to the signatory and capable of identifying them. Each electronic signature belongs to one individual, is never reused or reassigned, and the organisation verifies identity before assigning it.
- Sole control: eIDAS Article 26(c) requires the signature to be created using data under the signatory's sole control. A non-biometric signature uses at least two components, typically user ID and password, and they are used only by their genuine owner. Annex 11 section 14(a) then gives the signature the same impact as a handwritten one within the company, which is what makes a shared password a falsification rather than a convenience.
The common failures are a system that shows a user ID rather than a printed name, a 'meaning' that is not displayed, and a password shared with a colleague so they can approve something while the signer is on holiday. That last one is the electronic version of signing someone else's initials.
Backups, and what they are not
Annex 11 section 7.2 requires regular backups of all relevant data, with the integrity and accuracy of the backup and the ability to restore it checked during validation and monitored periodically. Section 7.1 requires data to be secured against damage by physical and electronic means. Two things go wrong. The first is that the backup is never tested by restoration, so nobody knows whether it works until the day it is needed. The second is that the backup is treated as the archive: a rolling backup that overwrites itself every thirty days is not retaining anything for five years.
Module 3 of the course walks a real standalone instrument and a real LIMS through each of these sections, with the user list, the role matrix, the audit trail configuration screens and the questions an inspector asks at each one.