Computerized System Validation: An EDMS Worked Example

Computerized system validation establishes documented evidence that a system is fit for its intended regulated use and remains controlled through change. The system includes the application, configuration, interfaces, infrastructure and operating procedures that affect that use. A supplier certificate, successful demonstration or completed test script is only part of the evidence.

For an electronic document management system, the practical question is whether the configured process reliably delivers the right controlled document to the right person, preserves its history and prevents unauthorized changes. This guide follows one fictional EDMS approval workflow from requirements to production release, then through an update and retirement. It also retains the broader CSV foundations useful to pharmaceutical QA, IT and validation teams.

The regulatory discussion distinguishes US drug manufacturing, EU GMP and device production or quality-management software. Clinical systems require their own applicability assessment. Sources and revisions were checked on October 6, 2026; the worked controls are an illustrative company design, not a universal regulatory template.

Start with intended use and the applicable rule

“Used by a pharmaceutical company” is not a sufficient validation scope. Identify what the system does, which records the organization relies on, who uses them and which regulated activity they support. An expense tool and an application releasing manufacturing instructions do not have the same intended use merely because they share a supplier.

For the US drug-manufacturing row, 21 CFR 211.68 addresses checks, authorized changes and accuracy of computerized input/output within its scope. It does not prescribe one universal binder structure.

21 CFR 11.10(a) describes validation for accuracy, reliability, intended performance and detection of invalid or altered records. FDA's August 2003 scope guidance explains its interpretation and specified enforcement discretion; underlying record obligations remain. Neither “Part 11 does not matter” nor “every electronic file needs identical validation” follows from that guidance.

What is current for Annex 11 and CSA?

The European Commission's current EudraLex Volume 4 index lists Annex 11 as the January 2011 revision. The Annex 11 PDF identifies revision 1 and June 30, 2011 as its date for coming into operation. It covers computerized systems used in GMP activities and distinguishes application validation from infrastructure qualification. Its risk-management principle considers patient safety, data integrity and product quality throughout the lifecycle.

The Commission also hosts a 2025 consultation on revised Annex 11, Chapter 4 and new Annex 22. That page is a closed consultation with draft documents. Do not relabel those drafts as the currently operative Annex 11 simply because the consultation deadline has passed.

FDA's final Computer Software Assurance guidance, issued February 3, 2026, supersedes its September 24, 2025 version. It concerns software used in medical-device production or the quality management system. It supports proportionate assurance activities and objective evidence; it does not abolish validation or universally replace pharmaceutical CSV. Its scope also excludes recommendations for design/development verification or validation of software functions that are themselves devices.

A drug GMP team may use sound risk-based methods, but should not cite the device CSA guidance as permission to discard its applicable drug requirements. For clinical investigations, use the separate October 2024, Revision 1 electronic-systems guidance, including its risk-based validation discussion, alongside the relevant clinical obligations.

Use GAMP 5 to organize decisions, not to manufacture obligations

ISPE's GAMP 5 Second Edition, published in July 2022, is industry guidance. Its public description emphasizes critical thinking, supplier involvement, iterative development and appropriate automation. ISPE expressly describes GAMP as practical guidance rather than a prescriptive method or standard. See the Second Edition overview and ISPE's GAMP explanation.

The familiar categories help describe components: Category 1 infrastructure, Category 3 non-configured products, Category 4 configured products and Category 5 custom software. ISPE's discussion of software architecture uses these distinctions. They are not a substitute for understanding the actual process risk.

For this guide's EDMS example, describe the standard application, configured approval workflow, identity service and any custom connector separately. A label assigned to the application does not establish that a custom export connector has been evaluated. Conversely, a custom component does not mean every ordinary screen deserves the same test depth.

Requirements, design choices and verification must connect. A V-model is one way to make those relationships visible; an iterative project can maintain the same traceability as requirements and tests evolve. The practical test is whether the team can explain why a requirement exists, how it is implemented and which evidence supports accepting it.

Where IQ, OQ and PQ fit

Installation qualification usually concerns the installed environment and configuration. Operational qualification concerns specified functions and boundaries. Performance qualification concerns suitability in representative intended workflows. These labels can organize an organization's approach, but are not proof by themselves and should not be presented as a universal three-document mandate for every computer system.

For SaaS, the customer may evaluate supplier infrastructure evidence while verifying its own tenant configuration and workflow. A production-like test environment can support evidence when its relevant differences are understood. There is no need to expose confidential real records merely to make a scenario representative: designed synthetic records can include realistic revision histories, permissions, long titles, failed transitions and unusual values.

Decide the required evidence first, then organize it under the organization's approved procedures. Avoid declaring a requirement covered simply because a document called “OQ” exists.

Build the plan around a defined EDMS process

Consider fictional company Northstar Pharma, which wants to manage manufacturing SOP approval at one site. Its proposed intended use is:

“

Maintain controlled SOPs; route a specific revision through authoring, review and authorized approval; make it available for operational use only after a separate effective-status decision; preserve earlier revisions and attributable history.

The first release excludes batch release, clinical-trial records, automated scientific conclusions and external partner access. These exclusions constrain the release decision; they do not excuse controls needed by the included workflow.

Northstar identifies four roles: author, reviewer, QA approver and administrator. Its own approved process prohibits an author from providing the final QA approval of the same revision. The administrator may maintain configuration but receives no routine QA approval authority. These are scenario requirements, not claims that every organization must use these exact role names or separation rules.

Before writing test steps, record the application/release, tenant, configuration version, identity integration, export route and document types. Name the process owner, technical owner, evidence reviewers and release authority. Identify dependencies such as login, timestamp handling, backup, restoration and the ability to retrieve records after personnel leave.

The planning handoff should answer three questions: What use is proposed? What could go wrong in that use? What evidence would justify accepting the remaining risk? “Vendor says validated” answers none of them sufficiently.

Convert risks into requirements and evidence

A useful risk statement connects failure to consequence. “Permissions are high risk” is vague. “An author can approve their own revision contrary to our process, allowing an unreviewed instruction into operational use” identifies a testable failure and its significance.

Use the following as Northstar's initial traceability matrix. Add the actual evidence identifiers and observed result during execution; the table supplies expected controls, not completed test results.

Assess risk before and after controls, explaining severity, realistic failure conditions, detectability and uncertainty using the organization's method. A calculated score is not mandatory for this example. More importantly, a low aggregate score must not conceal an unresolved failure of a control the organization has designated release-blocking.

For electronic signatures within scope, translate the applicable requirements into the test rather than assuming every implementation must use the same screen. Sections 11.50 and 11.70 address signature manifestations and record linkage; other signature provisions also apply as relevant. A password prompt alone does not prove the complete signing process works. Retain the exact signed revision and verify the meaning of the signature in the resulting record.

Execute one complete approval path, then challenge it

Create synthetic SOP N-100 revision 1 as effective and revision 2 as a draft. Give author Elena draft-editing rights, reviewer Sam review rights and QA approver Jo the final approval authority. Administrator Ravi configures the environment but cannot approve under this scenario. Define revision 2's effective transition as a separate authorized action after approval.

The ordinary path is Elena edits rev2, Sam reviews that revision, Jo approves it, and the authorized process makes it effective. Confirm that operational retrieval now returns rev2 while rev1 remains identifiable as superseded. Retrieve the supporting history and record copies, not just the green status badge.

Then execute adverse cases separately:

1. Elena tries to perform final approval. The action must not succeed under Northstar's defined process.
2. After Sam reviews rev2, create rev3 and attempt to carry that approval forward without the required review. The outcome must respect the approved revision-specific rule.
3. Request the routine effective SOP while rev2 is approved but not yet effective. The workflow must not substitute approval status for operational effectiveness.
4. Attempt a permitted revision after signing and inspect what happens to the earlier signed record. The accepted behavior must preserve its identity and history rather than silently overwrite it.
5. Interrupt a transition or repeat a request. Establish the final authoritative state and confirm the result does not appear twice or disappear without explanation.

For every run, record requirement ID, risk reference, environment/configuration, data and roles, prerequisites, action, expected result, actual result, evidence location, tester, date, deviation and review disposition. Use Pass, Fail, Blocked or Not applicable with justification. A supplier assertion without relevant execution evidence is not a passing customer test.

Blocked means the test could not establish the result, such as when the proposed role mapping is unknown or the export service is unavailable. It should not be silently converted into Pass to complete a report. Correct the prerequisite or explicitly narrow the proposed use, then assess whether the remaining scope is independently defensible.

For the interrupted-transition case, define the evidence before retrying. Suppose Jo's approval request times out. A timeout alone does not show whether the server recorded the approval. Northstar's expected behavior is one attributable decision for the identified revision, with a retrievable final status. Check the authoritative record before repeating the action, then retain the response and resulting history. Two approvals created by one retried request fail the example's uniqueness requirement; one preserved approval with an explainable retry can pass that requirement. If the history cannot be retrieved, record Blocked for the reconciliation and hold the affected release decision. Do not guess “no approval” from the missing browser response.

Evaluate supplier evidence and cloud responsibilities

Supplier assessment should answer how much reliable evidence can be reused and where customer-specific evidence is still needed. Review the supplier's development/change practices, relevant test coverage, known limitations, support arrangements and proposed release. A security certification may inform supplier assessment; it does not demonstrate Northstar's configured approval sequence.

Ask for evidence matching the version and service being purchased. A test report for an older release or another deployment model needs a justified relationship to the proposed environment. Record that relationship and the uncovered gaps. Do not require access to every line of commercial source code as an automatic condition for using supplier software.

For EU GMP systems, Annex 11 sections 3 and 4 address suppliers and validation evidence. Documenting who performs each activity still leaves the evidence to assess. See the current Annex 11.

For Northstar, the supplier might operate infrastructure backup while Northstar determines which records, retention needs and recovery outcomes matter. The supplier might test standard release functions while Northstar tests its role mapping and configured transitions. Put those allocations into the plan and service agreement, including incident notification, update notice and access to supporting evidence.

Automation can collect repeatable evidence, exercise interfaces and rerun regression checks. Review the test logic, controlled inputs, expected results and retained outputs. Human judgment remains necessary for deciding whether coverage and deviations are acceptable. Avoid categorical statements that all PQ or all installation verification can never use automation; choose methods for the actual evidence question.

Make a documented production-release decision

A summary report should connect the proposed production configuration to accepted evidence and a specific scope. For this example, use the following release record. Fill it in after testing; do not treat blank fields as implicit acceptance.

Suppose R1–R5 pass but the restored archive opens without its required approval history. Record R6 as Fail for that recovery exercise and hold the proposed release. If the recovery exercise could not run at all, record Blocked instead. Both prevent acceptance here, but they require different next actions: repair and retest an observed loss, or first obtain the missing execution prerequisites. Five passing rows cannot compensate for either gap.

Now suppose a noncritical help-text defect remains while all required record controls pass. The release authority may assess the defect, document its limited effect and accept it under the approved procedure. The distinction is the effect on intended use and the predetermined acceptance criteria, not the pressure to meet a go-live date.

Restricted release needs an enforceable boundary. If the export connector has not been established as reliable, disabling it and excluding that handoff might be defensible only if the remaining approved process can operate correctly and retain required records without it. Leaving the connector accessible with a note saying “do not use” is a different control and needs its own assessment.

Keep evidence valid through updates and retirement

After release, use change control to compare the proposed change with the accepted baseline. Evaluate direct effects and shared dependencies. A change to a role name might be cosmetic, or it might alter a permission mapping; an update label alone does not determine the risk.

If a SaaS update changes approval routing, Northstar revisits R1–R4 and any affected integration or export behavior. If the supplier describes only a display change, obtain enough detail to justify the narrower assessment. Unknown impact calls for clarification or an appropriate controlled response, not an automatic low-risk classification.

Retain the change description, impact rationale, selected assurance activities, actual results, deviations and release decision. When an urgent change is necessary, follow the organization's emergency procedure and complete the necessary impact and evidence work; do not rewrite the record as if normal prospective review occurred.

Operational review should consider incidents, access changes, supplier releases, recurring deviations, recovery evidence and whether intended use has expanded. Set the timing through applicable requirements and the organization's justified procedure. The current Annex 11 includes periodic evaluation in section 11 and change/configuration management in section 10; it does not supply a universal annual interval for every system. See Annex 11.

At retirement, decide which records and metadata must remain available, for how long, and through which system. Reconcile migrated content and its relevant context; test retrieval by an authorized future user. A successful file-count match does not establish preserved approvals, readable content or usable history. Keep the legacy route available as required until the replacement/archive evidence supports the planned retirement.

Common questions that change the plan

Does every pharmaceutical computer system need the same CSV package? No. Document the regulated use, record impact and applicable obligations. Exclusions need a defensible rationale, and a tool's use may change over time.

Is a GAMP category a risk rating? It describes a software/component type within the framework. A non-configured function can still be consequential in its actual use; a category number alone does not define testing depth.

How long does validation take? Estimate from configuration readiness, supplier evidence, requirements, interfaces, test-data preparation, execution, deviations and review capacity. This guide does not provide a universal duration or savings percentage.

Does an eCTD technical validation report validate the publishing system? No. Checking a submission package against technical rules answers a different question from establishing that the configured system is fit for its intended use. Both may matter, but one report does not substitute for the other.

Start your own plan by completing the intended-use statement and identifying the first three failures that could compromise it. Then assign owners and evidence before selecting test-document labels. Our Part 11 guide and audit-trail guide provide focused follow-up reading. For an Assyro evaluation, bring the same scoped requirements to a workflow discussion; the supplier conversation should establish the offered configuration and evidence available, not promise that a product name removes your validation responsibilities.