An EDMS Annex 11 evaluation needs evidence for the configured GMP workflow, its interfaces and operating responsibilities. A vendor's “Annex 11 compliant” statement is not a completed evaluation. Use the checklist below to identify the applicable controls, request evidence and record unresolved gaps.
This article addresses EDMS use in human-medicines GMP activities. An EDMS holding only unrelated commercial documents is not automatically within this scope. Mixed-use systems need an explicit boundary for GMP records, functions and dependencies.
As checked on October 6, 2026, the Commission's current EudraLex index lists Annex 11 revision January 2011. The separate 2025 revision consultation is closed; its linked text is a draft, not the adopted baseline used here. Current Volume 4 index, Commission consultation.
Define the evaluation and result rules
Enter the system name, release/configuration, record families, GMP processes, sites, interfaces, service providers and evaluation date. Identify the process owner, system owner and designated quality approver. Separate a purchasing assessment from operational acceptance: an unconfigured demonstration cannot establish that your eventual configuration works.
Each checklist row needs applicability, criterion, evidence reference, result, owner and closure date. Use the following results:
- Pass: relevant evidence supports the criterion for the stated scope and version.
- Fail: observed evidence contradicts the criterion.
- Unknown: evidence or applicability remains unresolved; a blank has this meaning.
- Not applicable: a documented scope reason has been accepted by the designated reviewer.
Mandatory failed or unknown checks hold the affected acceptance decision. Not applicable cannot mean “the product lacks it.” If one row covers several records or interfaces with different outcomes, create separate execution rows rather than averaging the results.
The clause references below use Annex 11 revision 1, effective June 30, 2011. The EDMS evidence examples and acceptance tests are proposed working methods, not additional regulatory text or a complete legal compliance determination.
A. Establish responsibility and the evidence boundary
| Check / Annex 11 reference | Evidence to inspect | Practical acceptance test |
|---|---|---|
| A1. Intended GMP use / Principle | Approved process and record-scope statement | Identify which controlled documents support which GMP activity; resolve unexplained exclusions |
| A2. Risk basis / 1 | Current system risk assessment | Trace the chosen verification depth for a consequential document error to a documented risk decision |
| A3. Accountable personnel / 2 | Responsibility and qualification records | Identify the person authorized to resolve each evaluation gap |
| A4. Supplier responsibilities / 3.1 | Executed service agreement and responsibility schedule | Locate who performs and supplies evidence for restore, updates and retention services |
| A5. Supplier assessment / 3.2 | Assessment and audit-decision record | Confirm the decision to audit or not audit is supported for this supplier and service |
| A6. Product documentation / 3.3 | Reviewed supplier documentation | Trace a material EDMS requirement to evidence relevant to the proposed edition/configuration |
| A7. Inspection information / 3.4 | Agreed access route to supplier quality/audit information | Establish how authorized personnel obtain the relevant information when requested |
A cloud contract that says “backups included” leaves A4 unresolved if it does not identify who obtains restoration evidence or initiates recovery. Likewise, a supplier assessment for an unrelated product is not automatically evidence for the EDMS service being purchased.
Record evidence ownership separately from task performance. A service provider may execute a technical activity while the manufacturer's designated owner reviews the resulting evidence. The contractual split should match the actual operating arrangement.
B. Connect the configured system to controlled records
| Check / Annex 11 reference | Evidence to inspect | Practical acceptance test |
|---|---|---|
| B1. Lifecycle evidence / 4.1–4.2 | Applicable validation records and deviations | Confirm the evaluated release/configuration is covered and unresolved deviations remain visible |
| B2. System boundary / 4.3 | Inventory and appropriate system description | Find the archive, identity provider and document interfaces in the documented boundary |
| B3. Requirements / 4.4 | Approved requirements and traceability | Follow a critical document workflow from requirement to its verification result |
| B4. Development assurance / 4.5 | Supplier quality-system assessment | Identify the reviewed basis for relying on development evidence |
| B5. Customization / 4.6, if applicable | Custom-function assessment/reporting process | Identify how a custom approval rule receives lifecycle assessment |
| B6. Boundary and error behavior / 4.7 | Relevant test protocols/results | Inspect a rejected invalid input or failed-interface case, not just a successful upload |
| B7. Migration / 4.8, if applicable | Source/target mapping and reconciliation | Retrieve a migrated version and verify that its approval-state meaning was preserved |
| B8. Electronic interfaces / 5, if applicable | Interface specification and exception evidence | Trace a failed or rejected transfer without silently creating an apparently complete record |
| B9. Critical manual entry / 6, if applicable | Critical-field assessment and checking method | Verify the additional accuracy check for an identified consequential field |
| B10. Infrastructure / Principle | Qualification evidence for the defined IT infrastructure | Confirm the relevant hosting/platform configuration is covered, with responsibility assigned |
For B9, identify the field and why an error matters. A critical manually entered effective date may warrant a different control from an optional descriptive keyword. Do not assume every metadata field requires two people, or that every field can be exempted because it is “only metadata.”
B1–B6 point to the validation evidence; this checklist does not reproduce a complete validation procedure. Use the computerized-system validation guide to plan that wider work. For an evaluation, insist on evidence tied to the intended workflow and configuration rather than treating a generic validation package as the final result.
C. Verify records remain usable and attributable
| Check / Annex 11 reference | Evidence to inspect | Practical acceptance test |
|---|---|---|
| C1. Stored-record protection / 7.1 | Implemented protection controls | Inspect evidence for the defined storage boundary, including relevant administrative access |
| C2. Retained-record retrieval / 7.1 | Retrieval checks and retention requirements | Retrieve the required version with its necessary context through the approved route |
| C3. Backup operation / 7.2 | Backup scope and execution records | Reconcile the protected population with the relevant document data and dependencies |
| C4. Restore capability / 7.2 | Validation and periodic restore evidence | Inspect a restored record and required context; a successful backup-job status alone does not pass |
| C5. Printed copies / 8.1 | Representative printed output | Confirm the selected record can be read and identified without omitted consequential content |
| C6. Batch-support printout / 8.2, if applicable | Output for records supporting batch release | Determine whether the printout indicates changes since original entry |
| C7. Audit-trail design / 9 | Risk assessment and applicable configured history | Evaluate an example GMP-relevant change/deletion against the approved control design |
| C8. Change reason / 9 | Relevant change/deletion record | Locate the documented reason for the selected event |
| C9. Audit-trail usability / 9 | Accessible, intelligible history output | Have the reviewer interpret the selected event without relying on a database specialist |
| C10. Audit-trail review / 9 | Review procedure and completed records | Find the review evidence required by the established procedure |
| C11. Authorized access / 12.1–12.2 | Permission design and access tests | Verify an allowed action and an unauthorized document/action request |
| C12. Access changes / 12.3 | Grant, change and cancellation records | Trace a departed user's authorization cancellation |
| C13. Operator identity / 12.4 | Attributable event records | Identify actor, action, date and time for a selected document event |
| C14. Signature effect / 14(a), if used | Approved signature policy and workflow | Confirm the electronic signature has the intended handwritten-signature effect within the company |
| C15. Signature linkage / 14(b), if used | Signed-record retrieval and linkage test | Confirm the signature stays linked to its correct record |
| C16. Signature timing / 14(c), if used | Signed-record evidence | Locate the date and time the signature was applied |
Keep C6 distinct from the batch-certification check below. Holding a record that supports batch release does not necessarily mean the EDMS performs Qualified Person certification. Conversely, excluding certification from the EDMS does not automatically make batch-supporting printouts irrelevant.
A displayed signature image alone does not answer C14–C16. Evaluate the internal effect, permanent record linkage and timestamp separately. Document a justified non-electronic-signature boundary where appropriate, including where the authoritative signed record resides.
D. Evaluate continued operation and exit
| Check / Annex 11 reference | Evidence to inspect | Practical acceptance test |
|---|---|---|
| D1. Controlled changes / 10 | Change procedure and selected configuration change | Trace authorization and assessment for a changed workflow rule |
| D2. Periodic evaluation / 11 | Evaluation procedure and due/completed review | Confirm the review addresses the system's relevant current condition, not only the original installation |
| D3. Incident assessment / 13 | Incident register and selected assessment | Trace a document-access incident even if the server never failed |
| D4. Critical incident response / 13 | Applicable investigation and CAPA | Follow the identified cause into corrective/preventive action |
| D5. Batch certification/release / 15, if performed here | Function scope, QP authorization and signature evidence | Test the permitted QP operation and denial for an unauthorized actor; inspect attribution |
| D6. Continuity / 16, for critical processes | Tested contingency arrangements and activation criteria | Walk through loss of the EDMS against the agreed process need and activation time |
| D7. Archive condition / 17, if archiving | Archive retrieval/integrity evidence | Retrieve the selected archived record and verify the approved integrity checks |
| D8. Archive after relevant change / 17, if applicable | Retrieval test covering the change | Confirm records remain retrievable after the affected software or infrastructure change |
Backups, continuity and archives answer different questions. Restoring last night's data may not supply the controlled instructions needed during today's outage. An archive may support long-term retrieval without operating the live approval workflow. Assign evidence and owners to each required outcome.
Do not infer a fixed retention period or universal annual test interval from this table. Record the applicable retention obligations, procedure and risk-based scheduling decisions for the actual records and processes.
Worked example: four different results
Consider a fictional human-medicines manufacturer evaluating its configured EDMS for GMP procedures and associated change records. An external quality system performs QP certification. The EDMS also stores a record used in batch-release review. Supplier and customer document IDs below are illustrative evidence references, not real test results.
| Condition | Evidence location | Result | Action and owner |
|---|---|---|---|
| C2: required procedure revision and approval context are retrieved through the accepted route | RET-07, completed retrieval record for SOP-104 revision 3 | Pass | Record reviewer/date; repeat when an applicable change triggers verification |
| C4: recovery is claimed, but restored SOP-104 lacks its required approval context | REST-02, restored-object comparison | Fail | System owner investigates the missing dependency, corrects recovery scope and retests |
| A4: supplier/customer restore responsibility cannot be located in the agreement | AGR-01, unresolved agreement review | Unknown | Supplier manager obtains the missing allocation; designated approver reviews it |
| D5: EDMS does not perform certification/release; controlled scope shows that function in another system | SCOPE-03, approved process boundary and system map | Not applicable to this EDMS function | Quality approver records the reason; evaluate the certification system separately |
The fourth result does not close C6. The EDMS contains a batch-supporting record, so its applicable printout behavior still needs evaluation. This is the boundary a simple “we do not release batches in the EDMS” answer can miss.
Apply that distinction to two more fictional records. CHANGE-09 shows a correction to a batch-supporting record after original entry. PRINT-09 is the executed printout test: the output contains the corrected value but no indication that data changed. C6 fails even if the output is readable and D5 is justified as not applicable. The document owner and system owner resolve the output behavior and retain a successful affected retest before closing C6. If PRINT-09 has not been executed, C6 is Unknown instead. Neither result requires guessing whether a QP would have noticed the correction; the evidence question is what this record's printout shows.
The evaluation cannot be accepted while C4 remains failed and A4 unknown. Buying additional storage does not by itself repair either problem. Correct the missing restore dependency, obtain the operating responsibility evidence and repeat the affected checks against the controlled configuration.
An unexecuted restore test would be unknown, rather than failed. Once an executed test demonstrates missing required context, retain the failure until documented correction and successful retest; do not relabel it unknown to improve a completion percentage.
Keep consultation monitoring separate from acceptance
The Commission consultation opened July 7, 2025 and closed October 7, 2025. Its revised Annex 11 document remains linked as draft guidelines on the consultation page reviewed for this article. A closed consultation is not evidence of an implementation deadline. Commission consultation and draft links.
Keep a separate change-monitoring entry: source checked, status, proposed impact, owner and next review trigger. Do not mix draft clause numbers into a checklist labeled as the January 2011 baseline. If a supplier markets against a draft, ask them to separate currently supported controls from future plans.
This article does not assess veterinary GMP applicability; the current Commission index has a separate veterinary legal framework. Nor does an Annex 11 evaluation substitute for a US Part 11 assessment; determine that separate scope from the electronic records and applicable US requirements.
Before accepting the EDMS scope, have the designated owners review all mandatory results and justified exclusions. An exception cannot waive an applicable obligation, and this editorial worksheet is not a regulator-issued certification. If you are evaluating a regulatory-document workflow with Assyro, bring the completed evidence checklist to a discussion and resolve the proposed product boundary before making a purchase decision.
About the author
Assyro Team
Expert regulatory operations consultants helping pharmaceutical companies navigate complex compliance challenges.