EN ISO 13485:2016+A11:2021 clause 4.1.6 requires you to validate every software application used in your QMS before first use and after changes, with the extent of validation proportionate to the risk. That means your eQMS, document control, training, and CAPA tools each need a written validation — but a Class I paper-tracker and a multi-tenant eQMS do not need the same depth.

By Tibor Zechmeister and Felix Lenhard.

TL;DR

  • EN ISO 13485:2016+A11:2021 clause 4.1.6 is the hard requirement: validate QMS software, proportionate to risk, before use and after changes.
  • The scope is broad — any software that supports a QMS process is in scope, not only "quality modules." Training platforms, CAPA trackers, document control, complaint intake, audit management.
  • Vendor IQ (installation qualification) and vendor validation packages are useful inputs, but they do not replace your own intended-use validation.
  • The validation protocol must cover: intended use, risk assessment, user requirements, test cases, acceptance criteria, results, and a signed validation report.
  • Revalidation is triggered by changes — to the software, the configuration, the intended use, or the underlying risk.
  • Notified body auditors check this clause in every Annex IX audit. It is one of the top ten non-conformities for software-forward startups.

Why this matters

A founder I worked with had chosen a popular eQMS platform on a startup discount. Fine choice. The problem came at their stage 2 audit: the notified body asked to see the validation of the eQMS itself. The founder showed the vendor's ISO 13485 certificate and the vendor's own validation package. The auditor said, politely, that none of that was a validation of the tool as used by this company for this intended purpose. The non-conformity was major. The CAPA ate two weeks of engineering time.

This is avoidable. Clause 4.1.6 is short, explicit, and easy to comply with if you treat it as a real requirement instead of a box to check after the auditor asks.

And this is not a "documentation tax." A poorly validated eQMS creates real operational risk. I have seen training records vanish during a migration, document revisions silently overwritten by a permission bug, and a CAPA workflow that quietly skipped a mandatory review step for three months. Each of those was a software defect in a QMS tool that had not been properly validated for the organization's intended use.

What ISO 13485 and MDR actually say

MDR Article 10(9) requires manufacturers to have a QMS in place. Annex IX point 2 covers the assessment of the QMS by a notified body for Class IIa, IIb, and III devices. The harmonized standard that provides presumption of conformity for the QMS requirement is EN ISO 13485:2016+A11:2021.

Clause 4.1.6 of that standard reads, in substance: the organization shall document procedures for the validation of the application of computer software used in the quality management system. Such software applications shall be validated prior to initial use and, as appropriate, after changes to such software or its application. The specific approach and activities associated with software validation and revalidation shall be proportionate to the risk associated with the use of the software. Records of such activities shall be maintained.

Four operative concepts:

  1. Documented procedures. You need a procedure that describes how you validate QMS software. Not a checklist. A real SOP.
  2. Prior to initial use. You cannot retroactively validate a tool you have been using for eight months.
  3. Risk-proportionate. A simple training log and a regulated eQMS do not get the same treatment. The depth is scaled to risk.
  4. After changes. Configuration change, vendor update, new intended use — any of these can trigger revalidation.

The scope is broad. Any software that supports a QMS process is in scope. That includes your document management system, your training platform, your CAPA tracker, your complaint intake form, your internal audit tool, your supplier qualification database, your calibration tracker, your risk management tool if it is used as part of the QMS, and your e-signature service. Typical startup stack: Google Workspace, a tool like Matrix or Greenlight Guru or Qualio, maybe a training tool, a ticket tracker. Each needs a risk-based validation record.

Vendor materials are helpful. A vendor's IQ (installation qualification) package, their SOC 2 report, their own validation documentation, their ISO 13485 or ISO 9001 certificate — all of these are inputs. They demonstrate that the vendor builds a reliable product. They do not demonstrate that the tool, as configured and used in your specific quality processes, meets your specific intended use. Only you can test that. The auditor will expect to see your own testing.

A worked example: validating an eQMS at a seven-person startup

A Class IIb implantable startup selects an eQMS to manage documents, training, CAPA, supplier qualification, and internal audits. Six users. Here is the validation they do, proportionate to risk.

Step 1: Intended use statement. "This eQMS is used to control quality management documents (ISO 13485 clause 4.2), manage training records (clause 6.2), run CAPA (clause 8.5.2), qualify suppliers (clause 7.4), and manage internal audits (clause 8.2.4). It is not used for design controls or risk management, which are in a separate tool."

Step 2: Risk assessment. One page. For each QMS process the tool supports, identify what could go wrong (e.g., "a controlled document could be edited without a review workflow," "a training completion could be recorded for a user who did not complete it"), the consequence, and the likelihood given the vendor's track record and the configuration. Conclusion: medium risk overall, high risk for document control integrity and training records.

Step 3: User requirements (URS). A numbered list of what the tool must do. URS-01: "Only users with the Document Controller role can approve a controlled document." URS-02: "Every document change creates an immutable audit trail entry." URS-03: "Training assignments send reminders at T-7, T-3, and T-0 days before due." URS-04: "CAPA records cannot be closed without a completed effectiveness check." Twenty to forty requirements is typical.

Step 4: Test protocol. For each URS, a test case: preconditions, steps, expected result, pass/fail. Risk-proportionate depth — the document control URS gets tested with multiple permission combinations, while the training reminder gets a single test run.

Step 5: Execution. Two people execute the tests in the production tenant before it goes live. Screenshots and results attached to each test case. Any failures become configuration changes or vendor tickets, then retested.

Step 6: Vendor package review. The vendor's ISO 13485 certificate, their SOC 2 Type II report, their release notes, their own change control evidence — reviewed and referenced in the validation report as supporting evidence.

Step 7: Validation report. A short document summarizing intended use, risk, URS, test execution, deviations, conclusions, and sign-off. Signed by the process owner and the PRRC.

Step 8: Ongoing. The vendor pushes a release every two weeks. A quarterly review of release notes is performed. Any release that touches a validated feature triggers a targeted retest of that URS. Major vendor version upgrades trigger a full revalidation of affected features.

Total effort for initial validation: about two days of a QA person's time plus half a day each from two other users for test execution. Ongoing effort: two hours per quarter.

That is what risk-proportionate validation looks like at startup scale. It is real, it is auditable, and it does not break the team.

Revalidation triggers

Clause 4.1.6 requires revalidation "as appropriate, after changes." Here is the practical list:

  • Vendor software updates that affect validated functionality. Read release notes. Classify.
  • Configuration changes you make — adding a new role, changing a workflow, enabling a module.
  • Intended use changes — you start using the tool for a process you did not validate it for.
  • Risk changes — a near-miss or a CAPA that reveals a control gap in the tool's use.
  • Infrastructure migrations — new data center, tenant migration, SSO integration.

Build revalidation triggers into the validation procedure. Do not rely on memory.

The Subtract to Ship validation playbook

1. One procedure, one template. Write a two-page SOP called "QMS Software Validation." Write a validation protocol template with the eight steps above. Everything else is an instance of the template.

2. Inventory your QMS software first. Before you validate anything, list every tool that touches a QMS process. Most startups underestimate this list by half. The tools you forgot are the ones the auditor will find.

3. Risk-classify in three buckets. High (document control, CAPA, training, e-signature), medium (audit management, supplier qualification, complaint intake), low (calendars, task lists used only as reminders). Validate effort scales with the bucket.

4. Reuse vendor materials, but do not rely on them. Attach the vendor's ISO 13485 certificate, SOC 2 report, and validation package to your report as evidence. Still run your own intended-use tests.

5. Pre-production tenant for testing. Never validate in the live tenant with real data. Use a sandbox. Most eQMS vendors provide one on request.

6. Make revalidation part of the change process. When you change a workflow or the vendor ships a major update, the validation procedure is invoked automatically, not as an afterthought.

7. Archive the validation record with the tool. The validation report lives inside the validated tool (or in your document control system, which must itself be validated first). Version control it. Auditors ask for it by name.

8. Do not skip the simple tools. The Google Sheet used as a CAPA tracker is still QMS software. Either validate it or move it into a real tool. Either is fine. Ignoring it is not.

Trace: EN ISO 13485:2016+A11:2021 clause 4.1.6 → MDR Article 10(9) → MDR Annex IX point 2 (QMS assessment). That is the chain. Every step defensible.

Reality Check

  • Do you have a documented SOP for validating QMS software? When was it last reviewed?
  • Can you list every piece of software currently supporting a QMS process? Are any missing from your validation inventory?
  • For each validated tool, can you produce a signed validation report with URS, test execution, and sign-off?
  • When did your eQMS vendor last push a release, and did you review the release notes against your validated features?
  • Is your validation depth genuinely proportionate to risk, or is it one-size-fits-all?
  • Would a notified body auditor accept your validation package without a major finding?
  • Are training records, document revisions, and CAPA state changes protected by validated workflows?
  • When was your last revalidation? What triggered it?

Frequently Asked Questions

Does the vendor's ISO 13485 certificate count as validation? No. The vendor's certificate confirms the vendor's QMS. It does not confirm that the tool as you configured and use it meets your intended use. You need your own validation.

Do we need to validate Google Workspace? If you use any Google tool (Docs, Drive, Sheets) as part of a QMS process, yes — at least for the way you use it. Most startups validate Drive for document storage with specific access controls. If Drive is your document control system, the validation is heavier. If it is only used for internal drafting, the scope is smaller.

How often do we revalidate? There is no fixed interval in clause 4.1.6. Revalidation is triggered by change. Many startups also run a light annual review to catch drift even when no changes were logged.

Can we use the vendor's URS as our URS? Only as a starting point. Your URS must reflect your intended use and your configuration. The vendor does not know either.

What if we change eQMS vendors? New tool, new validation. Full validation, not a shortcut. Also plan a data migration validation — records moved from one tool to another need integrity checks.

Is this the same as computerized system validation (CSV)? It is the ISO 13485 flavor of CSV. Principles overlap heavily with GAMP 5 concepts, but clause 4.1.6 is the specific hook for medical device QMS software.

Sources

  1. Regulation (EU) 2017/745 on medical devices, consolidated text. Article 10(9); Annex IX point 2.
  2. EN ISO 13485:2016+A11:2021 — Medical devices — Quality management systems — Requirements for regulatory purposes. Clause 4.1.6 Software validation.
  3. Zechmeister Strategic Solutions audit experience: clause 4.1.6 is among the ten most common non-conformities in startup Annex IX audits.