GxP relevance: which IT systems need validation?

Establish the applicable scope first

GxP covers several frameworks. An assessment for pharmaceutical manufacturing cannot simply be transferred to clinical trials, distribution or medical devices. This article addresses computerised systems in the EU GMP context for human medicinal products. Before assessing a system, identify the activity, site and requirements that actually apply.

Annex 11 covers computerised systems used as part of GMP-regulated activities. It distinguishes validation of the application from qualification of the IT infrastructure. Risk management considers patient safety, data integrity and product quality.

The practical starting question is therefore: what does this system do in our process? Buying standard software does not answer it, and neither do labels such as cloud, office software or ERP. A system outside the GMP scope considered here may still fall under other requirements. A negative GMP classification is not a general exemption from obligations.

The same software can have different uses

Describe the intended use in one sentence covering the activity, users and output. Add which uses are explicitly excluded. This keeps the assessment understandable when someone else takes responsibility for the system.

These examples are not completed classifications. The actual workflow and its controls remain decisive. For mixed use, ask whether areas are separated, information is processed further or an informal export later becomes a decision input. Calling something “just a supporting tool” does not explain these dependencies.

A ten-field assessment worksheet

This structure is a practical working aid, not a prescribed regulatory form. Complete it with the process owner and relevant specialists. Link existing documents rather than repeatedly copying the same information.

Follow the data through to the decision

Start with a representative record rather than a long feature list. Follow it from entry to use. Who enters it? Which calculation changes it? Where is it checked? Who makes a decision using the result? Include exports, emails and manual intermediate steps.

Then consider three different failures: the result is wrong, the result is unavailable or it is changed without detection. For each, record the affected process and the existing control that would actually detect the error. A control supports your rationale only when its operation and effectiveness can be explained.

Record unresolved dependencies openly and assign someone to clarify them. An unknown interface does not become uncritical because nobody could explain it in the first discussion. If you rely on a manual check, identify who performs it and where its completion is recorded.

Keep classification separate from validation

Initial classification identifies the use being assessed and why it may be relevant. It does not demonstrate that the application is suitable for that use. For systems within Annex 11 scope, justified risk assessment determines the extent of validation and data-integrity controls; it does not replace validation.

A relevant classification therefore creates a further assignment. Clarify requirements, available supplier evidence, necessary checks, unresolved deviations and operational responsibilities. Annex 11 addresses an up-to-date system inventory, traceable user requirements and, for critical systems, descriptions covering data flows and interfaces. The evidence needed must be established for the particular context.

A supplier certificate or completed standard training does not automatically answer questions about your configuration, interfaces and use. Reuse available documentation deliberately and record the remaining gaps. An assessment should make the next validation activities clearer, rather than suggest they have already happened.

Make a decision that remains understandable

A useful decision contains more than a yes or no checkbox. It states the assessed use, supporting facts, conclusion and next action. Unresolved information needs an owner. An assessment still in progress must not look like an approved conclusion.

Agree who reviews the rationale and who approves it under the quality system. IT understands the technical environment, the process owner understands the workflow, and quality contributes the applicable requirements. A generic product classification should not replace any of these perspectives.

Reconsider the classification when intended use, important data flows or the decision-making function changes. Connect this with change control and the planned periodic evaluation. The BASG inspection guidance illustrates the attention given to inventories, changes and maintaining the validated state. Keep the assessment accessible alongside the records it references.

Begin with a clearly bounded work package

You do not need a collection of unchecked templates to get started. Assemble an initial system list, the affected processes and a contact for each system. Select the cases where decisions, evidence or responsibilities remain unclear.

A bounded work package can cover documenting intended use, facilitating the assessment and identifying follow-up activities. Daniel Herrmann Consulting supports that structure and subsequent specialist implementation. Decisions and approvals remain within your agreed responsibility model. Relevant starting points are system validation, CSV consulting and getting evidence under control.