Change control software: six quality systems read against the change record

A lab runs change control twice, often in the same module. The first kind changes what you make or test: a method, a procedure, a specification, a supplier. A predicate rule asks for it. The second kind changes the computerised system itself, and Part 11 and Annex 11 ask for it in different words.

The two meet in the software. Revising an HPLC method is a process change that also changes the processing method in the chromatography data system; a new eQMS release is a system change that can alter how every approval in the quality system is signed. A good module holds both kinds on one record type, with an impact assessment that asks about each.

Part 11 and Annex 11 also split the work differently. § 11.10(k)(2) controls the documentation of the system; Annex 11 § 10 controls changes to the system itself, configuration included. A lab that only supplies the US can read (k)(2) narrowly; one that supplies the EU cannot (our Annex 11 guide covers when it applies).

Whatever the software, a change record carries six parts: the request, the impact assessment, the approvals, the implementation, the verification and the closure. The impact assessment decides how much work follows. The worked example below asks four questions of every change: does it touch validation, which documents change, who needs training, and does it reach a regulatory filing (the question ICH Q10 3.2.3(b) asks outright).

Count the signatures. The first example carries seven, each with its own meaning: authorship for the request, review for each assessor, approval, responsibility for the work, review for the verification, and approval again at closure. Part 11 asks that each show the printed name, the date and time, and “the meaning (such as review, approval, responsibility, or authorship)” (§ 11.50(a)), and that each be linked to this record so it cannot be “excised, copied, or otherwise transferred” (§ 11.70). A module with one approve button and no meaning puts the meaning in a free-text comment, where nothing enforces it.

This is the question that costs most when it is skipped. ICH Q10 asks for “an assessment to determine whether a change to the regulatory filing is required under regional requirements”. In the US, three rules set the answer for most products a small team ships.

A contract lab or a GLP test facility usually holds no application of its own; the filing belongs to the sponsor. The change record still needs the question answered and the name of the sponsor contact who was told. In software that is one field and one routing rule: when the filing flag is set, regulatory affairs signs before quality can approve. Our register has no row for it, so it sits in the demo tests below.

For a device maker, the design change itself runs through the design controls that § 820.10(c) brings in from ISO 13485 Clause 7.3. We could not read the paywalled standard, so check its change clause in your own copy.

The rows run in the order a change record meets them: who may raise and approve, the signatures, the trail, copies, then the vendor's own validation documents and the Annex 11 statement. The open-system row (§ 11.30) is left out: it is about records moving through systems you do not control, not about approving a change. The eQMS comparison carries it.

TrackWise Digital's statuses come from the vendor's Part 11 and Annex 11 assessment. We read it on 2026-10-22; the document itself is dated March 2019, so ask for the assessment that matches the release you would buy.

Veeva QMS documents eight of the nine rows on its current help pages; TrackWise Digital's 2019 assessment covers nine. Veeva takes best overall here because the rows include the vendor's own release documents, and for a cloud system whose releases change your validated state, current documentation weighs more than older, fuller documentation. On the CAPA software comparison TrackWise Digital takes best overall, because CAPA is the job it is built around; here it takes the row for teams that run change, CAPA and quality events together.

Reliance and Dot Compliance eQMS state more of these rows than they describe. For them, the demo tests below carry most of the weight.

A cloud eQMS changes under you: the vendor ships, and your validated system is now a different system. Annex 11 § 10 makes that release a change you control, and your validation documentation should include its change record (Annex 11 § 4.2). What keeps that work affordable is the vendor's own release documentation, so this is the one row worth reading vendor by vendor.

A release package covers what the vendor tested, not your configuration. Your part is the change record, a retest of the features you rely on sized by risk, and the updated system documents. The CSV lifecycle for small labs covers the documents; the CSA vs CSV guide covers how far risk-based testing can go.

These are the rows that make change control software different from a document system, and our register does not rate them: we read no vendor pages on them, so we give no status. Run them as a script in each demo, and write the ones you need into your user requirement specification.

Two tests reach into other modules. A change that comes out of a CAPA should link back to it, which the CAPA comparison reads from the CAPA side, and the training items a change opens land in your training system, read in the Part 11 LMS comparison.

Each card shows the six rows a change approval leans on. Some quality vendors' pages could not be read on the read date, so they are not in this lineup; a missing vendor is not a verdict on it. This lineup also has no suite built for device makers alone, so the third verdict row names a use case instead; device makers should read the medical device QMS comparison.

1. 21 CFR Part 11, Electronic Records; Electronic Signatures, eCFRread 2026-10-22
2. Part 11, Electronic Records; Electronic Signatures: Scope and Application (guidance, 2003), FDAread 2026-10-22
3. 21 CFR 211.100, Written procedures; deviations, eCFRread 2026-10-22
4. 21 CFR 211.160, Laboratory controls: general requirements, eCFRread 2026-10-22
5. 21 CFR Part 211, CGMP for Finished Pharmaceuticals (§ 211.68(b)), eCFRread 2026-10-22
6. 21 CFR 58.81, Standard operating procedures (GLP), eCFRread 2026-10-22
7. 21 CFR 314.70, Supplements and other changes to an approved NDA, eCFRread 2026-10-22
8. 21 CFR 807.81, When a premarket notification submission is required, eCFRread 2026-10-22
9. 21 CFR 814.39, PMA supplements, eCFRread 2026-10-22
10. 21 CFR Part 820, Quality Management System Regulation (§ 820.10), eCFRread 2026-10-22
11. Q10 Pharmaceutical Quality System (guidance, April 2009), FDAread 2026-10-22
12. EudraLex Volume 4, Annex 11: Computerised Systems (2011), European Commissionread 2026-10-22