On the day of the inspection, the question is not whether your software is compliant. It is who created the account that signed, and who reviewed the audit trail last month.
An instrument bought as “21 CFR Part 11” arrives and measures well. Eighteen months later, the auditor finds a single shared account, with the password written on the cabinet. The software is compliant; the system cannot be defended. The gap is organisational, and it shows up late.
What we provide, what you own
| What we provide | What you approve and own |
|---|---|
| Analysis of the selected software’s declaration: what is native, what is configured, what is missing | The purchase decision |
| Configuration: named accounts, profiles, segregation of roles, audit trail | Account management, audit trail review |
| The qualification protocols | Their approval and execution within your quality system |
| The method and model file | Its integration into your document system |
We involve your computerised system validation team from scoping onwards. Consulted early, it steers. Consulted at deployment, it blocks.
Show us the declaration you received: we will tell you what it covers. Book a call.
What a declaration of conformity really covers
A manufacturer declaration, when it is well made, is a serious document: signed, dated, referenced. Its perimeter is exact, and it repays reading.
One software version, rather than a range
The declaration names one software in one precise version, sometimes with its part number. The version you install three years later is covered by its own document, so the update and its requalification are settled at purchase.
A standard cited by name
Good declarations cite their texts: 21 CFR Part 11, Annex 11 of the European GMP. A generic mention of electronic records and signatures, with no named standard, is a sentence rather than a commitment.
A GAMP 5 classification
The software is placed in a category, and that category sets the validation effort that falls to you. The most useful information in the document, and the one most often read last.
Category 3 deserves an explanation, because its label misleads. It is rendered as non-configurable products, which suggests that a software with settings would be excluded. It is not. A software can offer many settings and stay in category 3 on two conditions. That it is always used with a standard configuration established at installation and qualification. And that those settings are run-time parameters rather than the development of new functions.
The consequence is direct: in category 3 the code is not validated, the installation and the use are qualified. The effort moves from the publisher to you.
What remains your responsibility, whatever the software
This is not an opinion on our part. Serious declarations of conformity say so themselves. Overall compliance also depends on the operator’s procedural controls: notification, training, procedures, administration. That reservation appears in black and white in the best-written documents on the market, and it is to their credit. A manufacturer who writes it is doing you a service. The mention alone, however, does not say where the software’s responsibility stops and yours begins.
Here is what remains on your side, whatever the quality of the software:
- Account management. One named account per person, a password policy, a leavers procedure. The software offers the mechanism. You decide to use it.
- Your procedures. Who has the right to create a method, who checks it, who approves it, and what happens when a result is set aside. None of that is configured in a menu.
- Your training plan. An electronic signature only has value if the person signing has been trained and that training is recorded. It is one of the first things checked: team training is not an optional extra.
- Your data governance. Where raw data are stored, who accesses them, how they are backed up, how long they are kept, how they will be read back in ten years.
- The qualification of your installation. The manufacturer qualifies its product in its workshop. Your installation (this probe, on this equipment, with this cabling) has never been qualified before you. It is the heart of an integration project.
The questions to ask before signing a purchase order
This list fits on a page and saves months. Ask it in writing: the quality of the answer tells you as much as its content.
For each requirement, a single question: native, configurable, or to be developed? The answer changes everything. Native: the function is in the delivered software and covered by its declaration. Configurable: it exists but depends on a configuration you will have to specify, test and document. To be developed: it does not exist yet; it has a cost, a lead time, and falls outside the scope of the declaration.
| Requirement | What to obtain | Native, configurable or to be developed? |
|---|---|---|
| Audit trail | Named, time-stamped, unalterable, and readable without the vendor’s tool | To be asked in writing |
| Electronic signature | Linked to the signed record: signer, date, meaning of the signature | To be asked in writing |
| Segregation of duties | Whoever creates a method is not whoever approves it, and the software enforces it instead of suggesting it | To be asked in writing |
| Profiles and rights | Roles defined by you, not a list fixed by the vendor | To be asked in writing |
| Model and method versions | Each result tied to the version that produced it | To be asked in writing |
| Raw data | Export in an open format, readable without the software | To be asked in writing |
Segregation of duties is the line that most often makes the difference in an audit. Software that offers profiles without preventing the same person from creating and approving does not meet the requirement: it leaves it to your procedure.
- Is there a compliance matrix? A table that takes each requirement of the standard and states opposite it how the software answers. With a matrix, a declaration becomes verifiable.
- Which version does it cover? And which version will you receive. The two do not always coincide.
- Which account policy is specified? Named accounts, roles, privileges, expiry, as they appear in the functional requirements rather than as they are possible in theory.
- Is the electronic signature specified or stated? A compliant signature assumes an inseparable link between signer, document, date and the meaning of the act. Ask where that is written.
- Which mechanism locks a method? An approved method becomes unmodifiable, or every modification creates a traced version. Ask for the behaviour rather than the tick box.
- Is the event stream to a third-party system identical to the local audit trail? Where the flow exported to supervision or historisation is poorer than the local trace, your regulatory archive is the poorer of the two.
Watch the regulatory references that belong elsewhere
A product sheet may cite 21 CFR 1040.10, the performance standard for laser products: it is a safety reference, distinct from 21 CFR Part 11. Both sit in the same federal code. Verify which text the sheet is quoting before attaching it to a qualification.
The communication server that stays open
Many instruments expose an industrial communication server to talk to the PLC or supervision. The question to ask: does that server stay active after the main software is closed, and does it accept writes from third-party clients? Where it does, the access control of the software has a side door, which sits awkwardly with the notion of a closed system. It is an architecture characteristic, common and often useful, and it is documented and framed. That calls for having asked.
What is about to change
The Annex 11 in force dates from January 2011. It is under revision, and the draft does not travel alone. From 7 July to 7 October 2025 the European Commission ran a consultation on three texts drafted jointly by the EMA Inspectors’ Working Group and PIC/S: a revised Chapter 4, a revised Annex 11, and a new Annex 22 on artificial intelligence. The consultation is closed. Nothing has been adopted to date: the applicable Annex 11 is still the 2011 one, and Annex 22 exists only as a draft.
Why the draft Annex 22 concerns you even if you do no artificial intelligence
Its scope is explicit, and it surprises. The draft applies where models are used in critical applications with direct impact on patient safety, product quality or data integrity, “e.g. to predict or classify data“. It covers models that obtained their functionality “through training with data, rather than being explicitly programmed“, static models — those that do not adapt their performance in use — and models with a deterministic output.
And it rules out of critical GMP applications the dynamic self-learning models, the probabilistic-output models, generative AI and large language models.
A chemometric model ticks all four inclusion criteria. A PLS regression draws its functionality from a calibration on data rather than from explicit programming; it is frozen after validation; it returns a deterministic output; and it serves to predict a quantity that decides. The draft contains no exclusion for chemometrics.
Most of the draft’s requirements cover what a serious practice already does: predefined acceptance criteria, performance at least equal to that of the method replaced, specified and justified preprocessing, explainability of the prediction, a confidence score, monitoring of performance and of the inputs staying inside the model’s domain. That is the subject of watching a model over time.
One point, by contrast, has no equivalent in current chemometric practice: test data independency. The draft asks that the people who developed and trained the model “have never had access to the test data“, that the test set be protected by access control and audit trail, and that where the people cannot be separated a four-eyes principle applies. Yet it is usually the same chemometrician who builds the model and tests it.
Our reading, given as such: the debate the consultation opened is about admitting generative models, not about removing static ones. A relaxation for chemometrics therefore looks unlikely to us, and the gap to close sits in the governance of test data rather than in the modelling. None of this is enforceable today — but an installation project that will live five years is better designed knowing it. Status verified on 20 September 2026.
ALCOA+, the audit trail and data review
The ALCOA+ principles hold in a few words: data is attributable, legible, contemporaneous, original and accurate, and, for the plus, complete, consistent, enduring and available. It is the definition of what makes data support a decision.
A continuous measurement puts them to the test, since a sensor produces a stream rather than a result. What is kept, the raw spectrum, the pre-processed spectrum, the predicted value? Our answer is constant: keep the raw spectrum, time-stamped and attributed. It is the only original datum in the sense of the text, and the only one that allows a calculation to be replayed on the day a model is revised. A prediction whose source spectrum has been lost is a number.
The audit trail is worth what its reading is worth. The requirement is to review it, at a defined periodicity, with a trace of that review. It is a gap often observed: the trail exists, it is complete, and it has yet to be opened. Provide for who reviews it and what triggers an investigation, exactly as for model drift monitoring. What becomes of a model over time.
What sits between the two
Compliant software is a necessary condition: it saves you from compensating with procedures for what a poorly designed product leaves out. Between it and a validated system there is a space that no purchase fills.
That space holds a risk analysis, a specification of your needs, a validation plan, qualification protocols written and executed, procedures, a training plan, account governance and change management. None of it arrives in a crate. It is scoping work and then deployment work, run with your quality teams, and it starts before the instrument arrives.
Between compliant software and a validated system, what sits in between is work rather than a product. Naming it early is budgeting it.
Frequently asked questions
"21 CFR Part 11 ready" and validated system: what exactly separates them?
The first describes a product: the software offers the expected mechanisms, accounts, traceability, signature, locking. The second describes a state of your installation: those mechanisms are configured, qualified, documented, used by trained people and maintained over time. Both are needed, and the second half is yours.
Who is responsible for a gap found at inspection?
The operator, unambiguously. The reservation in the declarations of conformity is therefore a description of the real division of roles rather than a lawyer’s precaution. The manufacturer answers for the product. You answer for your system, including how you use that product.
Does the chemometric model itself need validating?
Yes, and it is a separate file. A prediction model is an analytical procedure and it is validated as one. The compliance of the software hosting it says nothing about the accuracy of what it predicts.
Can a non-compliant instrument still be used?
Yes, in development, in proof of concept, or in steering with no effect on a release. What matters is to name the intended use from the start, since it determines the rest, budget included, and to revisit it before an exploratory use becomes a regulated one.
Where do we start if nothing has been done yet?
With an inventory of what exists: the manufacturer declaration, its version, its matrix if there is one, the configuration actually installed, the list of accounts, the procedures in force. That inventory is enough to know what is missing. Adding a second instrument of the same model adds one question: two instruments do not necessarily produce the same datum. Two instruments, two figures.
Show us the declaration you received. You will know what it covers and what it leaves with you.
Forty-five minutes is enough to read a compliance document, spot the questions that have yet to be put to the supplier, and place the effort that remains: qualification, procedures, training, data governance.