eQMS validation: a risk-based approach for small quality teams

You have bought, or are about to buy, an electronic quality management system, and someone has asked for the validation plan. The quality team is three people. The last computer system validation anyone here saw was a lever-arch file of screenshots for a laboratory instrument, and nobody wants to repeat it for a system that will hold every SOP, CAPA and training record you own. This article sets out a proportionate way to do eQMS validation: what EU GMP Annex 11 and ISO 13485 actually require, how GAMP 5 second edition and computer software assurance thinking cut the work down, how far you can rely on the supplier's own testing, the difference configuration and customisation make, what you should test yourself, and how to keep the system validated once it is live.

What the requirements actually say

For device manufacturers, clause 4.1.6 of ISO 13485:2016 requires documented procedures for validating the application of computer software used in the quality management system. Validation happens before first use and, as appropriate, after changes to the software or its application, and the approach must be proportionate to the risk associated with the use of the software. Records of the work are kept. The technical report ISO/TR 80002-2:2017 gives guidance specifically on validating software used in device quality systems, and is worth having if you want a worked framework.

For medicinal products, EU GMP Annex 11 applies to every computerised system used in GMP-regulated activities. Section 1 asks for risk management across the system lifecycle, with the extent of validation based on a justified and documented risk assessment. Section 4 covers validation: user requirements based on risk and GMP impact, traceable through the lifecycle (4.4); assessment of the supplier (4.5); and evidence of appropriate test methods and scenarios (4.7). Section 3 covers formal agreements with suppliers, and section 11 periodic evaluation. A revised Annex 11 went out for public consultation in 2025; at the time of writing the 2011 text is still the version published on the Commission's EudraLex page, so plan against it and watch for the new one.

Neither text asks you to test every button. Both ask you to understand what the system does in your process, decide what could go wrong, and spend your effort there. ICH Q9(R1) makes the same point in general terms: the effort, formality and documentation of quality risk management should match the level of risk.

GAMP 5 second edition and computer software assurance, in practice

ISPE published the second edition of GAMP 5 in July 2022. Its software categories still help: most eQMS products are configured software (category 4), and anything written specifically for you is custom (category 5). The more useful changes are in emphasis. The second edition asks for critical thinking by people who understand the process, expects regulated companies to make full use of supplier knowledge, testing and documentation, and supports iterative development and cloud services.

Computer software assurance (CSA) pushes in the same direction. It was set out by the US FDA in guidance finalised in September 2025 and updated in February 2026, and although it is a US document, its four steps are a sound structure for any small team. Identify the intended use of each feature. Decide whether a failure of that feature would pose a high process risk. Choose assurance activities to match: scripted testing with detailed steps and expected results where the risk is high, and unscripted methods such as exploratory or error-guessing testing where it is not. Keep records that are sufficient to show the work was done, and no more.

Together they give you permission to stop producing evidence nobody uses. They do not give you permission to stop thinking.

Start with intended use

Write one page that states what the eQMS is for at your site. Which processes does it run (document control, training, deviations, CAPA, internal audits), which does it not (batch release, complaint reporting to authorities, perhaps), who uses it, and which records in it are GMP or ISO 13485 records. Add the system to your inventory of computerised systems, which Annex 11 4.3 expects you to keep current.

Then write user requirements against your own processes, in your own words. "An SOP revision becomes effective on its effective date and the previous revision is withdrawn from use on the same date" is a requirement you can test. "The system shall support document control" is not. For a small company, a few dozen requirements usually covers an eQMS. Mark each one for risk: could a failure affect product quality, patient safety or the integrity of a GMP record? Most will be low. The ones that are not, such as effective-date handover, electronic signatures, audit trail, role permissions and training assignment on revision, are where your own testing goes.

Assessing the supplier and relying on their testing

Annex 11 says the competence and reliability of a supplier are key factors, that the need for an audit should be based on risk (3.2), and that quality system and audit information about suppliers should be available to inspectors on request (3.4). A remote assessment based on a questionnaire and documents is proportionate for most small companies buying a configured cloud system; an on-site audit is for when the answers raise doubts.

Ask for a description of their development lifecycle and quality system, their release and change-notification process, a summary of their own testing of core functions, how the audit trail and electronic signatures work, where data is hosted, how backups and restores are tested, and their exit and export process. Our eQMS buyer's checklist has the full list of questions.

Now the limit. The MHRA GxP data integrity guidance (section 6.19) states that accepting vendor-supplied validation data in isolation from system configuration and the user's intended use is not acceptable, because vendor testing outside your process is likely to amount to functional verification only. Supplier testing can cover the core product: the audit trail engine records changes, signatures bind to records, permissions are enforced as configured. Your testing covers your configuration in your process. Record that division in a short reliance statement, naming the supplier documents you reviewed and the conclusions you drew.

Configuration versus customisation

Configuration means setting up the product with the tools it provides: workflows, approval routes, roles, numbering schemes, form fields, training rules. Customisation means code written or changed for you. The difference matters a great deal to validation effort.

Configuration is tested through your requirements. If your SOP approval route has two reviewers and a QA approver, test that route, including what happens when a reviewer rejects. Customisation brings category 5 into the picture, with the design, code review and testing that implies, and it must be retested every time the supplier releases a new version. For a small team, the cheapest validation strategy is to configure the system to your process and change the process where it fights the product. Treat every customisation request as something to justify in writing.

Keep the configuration itself under control. Annex 11 section 10 requires changes to configuration to follow a defined procedure, so record the configuration baseline at go-live and route later changes through change control with an impact assessment.

What to test yourself

Concentrate scripted testing on the functions where a failure would damage records or let the wrong document reach the floor. A typical split for an eQMS looks like this:

Exploratory testing still needs a record: who tested, when, which area, what they tried and what they found. A half-page per session is enough. Data migration needs its own check, since Annex 11 4.8 requires that migrated data are not altered in value or meaning.

Finish with a validation summary report that lists requirements, the evidence for each (your test, supplier evidence or both), deviations found during testing and how they were resolved (Annex 11 4.2), and a clear statement that the system is fit for its intended use.

Keeping the system validated

A cloud eQMS changes several times a year. Write a short procedure for releases: how you hear about them, who reads the release notes, how the impact is assessed against your requirements, and when a change triggers retesting. A change to signature or approval logic needs a targeted retest. A new report layout does not.

Annex 11 section 11 expects periodic evaluation to confirm the system remains in a valid state, looking at functionality, deviations, incidents, upgrade history, performance, security and validation status. For a small company, an annual review of one or two pages works: what changed, what went wrong, whether user access is still appropriate, whether a backup restore has been checked, and whether the validation pack still matches how the system is used. Include an audit trail review of a sample of records while you are there.

Keeping it proportionate

A defensible eQMS validation pack for a small manufacturer fits in a single folder: intended use, risk-assessed requirements, supplier assessment and reliance statement, configuration baseline, your test scripts and exploratory records, a summary report, and a release and periodic review procedure. An inspector will read it in an hour. If yours is much larger, ask which parts anyone used to make a decision.

The takeaway

Validate the configuration you built for the process you run, rely on the supplier for the product core once you have checked their evidence, and keep the system validated through release assessment and an annual review.

If you are scoping that work now, the InnoQualis platform page sets out the document control, training, deviation, CAPA and audit modules you would be validating, with electronic signatures designed to support 21 CFR Part 11 and EU GMP Annex 11 and an append-only audit trail.