Quality & Compliance · regulatory and quality
Significon builds the quality system in which GMP and GDP rules become a tested specification, validates the single system state within the project, and closes with test management the gap that opens at every system boundary. Audit readiness is the result of this chain — not a separate project.
The problem
The four patterns below sit in almost every system landscape that has grown over years, whatever the current state of the rules. None of them is an individual’s mistake. Each is made visible by a revision, not caused by one.
01
The binder is complete; the picture in it is two releases old. Between the documented and the running system state sit changes that each looked too small for a re-test. In an inspection what counts is not how much is documented, but whether what is documented describes the system that runs.
02
Two failures with one cause: either everything is tested to the same depth, or what gets tested is what is easy to test. Annex 11 places the extent, in section 1, under a justified and documented risk assessment. Without one, you have either tested too much and cannot justify it — or too little and have not noticed.
03
Each system is validated on its own. The process runs across three. What happens at the interface — which field was carried over, which status won, which timestamp applies — is not a test object in any of the three projects, because it is not a requirement in any of them. Migrations expose this gap reliably, and usually too late.
04
SOPs are written, the quality management system is certified, the documentation standard exists. Yet every project decides afresh what “validated” means. A rule that does not appear in the URS is not tested — and in an inspection it is not a defence but the question why it was not followed.
The approach
We work from the rule to the specification and from the specification to the evidence, in that direction. So what stands at the beginning is not the test protocol but the question of which condition has to be met and who sets it: the guideline, the quality system, the process. Only after that is it settled what has to be specified and what has to be tested.
The depth is decided by the risk assessment, not by the template. Annex 11 requires the validated state and places the extent under a justified and documented risk assessment; GAMP 5 is the established framework in which that state is produced, and ICH Q9 in its Q9(R1) revision supplies the method for the justification. The justification itself is owed by the company — no guideline takes it off your hands.
AI appears in these processes as a framed step: defined input, human approval, audit trail. The binding frame for it is Annex 11 — not a draft.
What the guideline demands becomes a requirement that can be tested; the requirement becomes a function, the function a test case. Every step has a predecessor it refers to and a successor that evidences it.
Before any test plan comes the question of which failure would have which effect on patient, product and data. That answer sets the depth. An inherited template does not — and an audit asks for the justification, not for the template.
Change control and periodic review are not follow-up work. They are the condition under which an acceptance remains a statement beyond the day it was signed. So they belong inside the project, not in the time after it.
The chain
Specification on the left, evidence on the right, the mapping in between. What sits above sets the rules; what closes below comes round again.
Three things sit in this picture that come apart in daily practice. First the mapping: every requirement is tested against exactly the level on which it was written — the traceability matrix is not an appendix, it is the connection itself. Second the distinction from Annex 11: the application is validated, the IT infrastructure is qualified, and the extent is decided by a justified and documented risk assessment. Third the return path: release to operation closes the project, not the state. Every change leads back into the chain, and the periodic review asks whether it did.
The solution
The chain is one; the work on it divides into three responsibilities. They act on the same requirements and differ in reach: what applies to every project, what a single project delivers, and what reaches beyond the project.
Rules
Before a single system is validated, what it is measured against has to exist. We build this level and maintain it: the GDP quality system with its SOPs, the quality management system under ISO 9001 or ISO 13485, and the state in which an inspection is not an exceptional event.
Validated state
A system enters the validated state through a project with a beginning and an end. The end is documented acceptance and release for productive operation — not the last test report. The depth is decided by the risk assessment, with ICH Q9 as the method.
Evidence
The process runs across system boundaries; the project ends at them. What lies in between needs its own test strategy and its own evidence: migration, interfaces, regression across the lifecycle, user acceptance across several business areas.
Additional info · status of the Annex 11 revision
Annex 11 has been in force since 30 June 2011. On 7 July 2025, the revision of Annex 11, the revision of Chapter 4 and a new Annex 22 were put out for consultation; the consultation closed on 7 October 2025, and no final version or transition period has been set. What is affected is not a single project but the entire estate of validated systems built on Annex 11 since 2011.
On Annex 22: the draft excludes generative AI and large language models from its scope. Anyone running an AI step in a GxP process today works under Annex 11 — the instrument in force, not the draft.
Why Significon
Whoever writes the documentation standard knows the test case that will later check it. Split rule, specification and test across three suppliers and the gap appears exactly at the handovers — which is where an inspection starts asking.
This page names the status of every instrument it cites: in force, binding part of the guide, industry guide, draft. The same separation underlies our documents. A requirement that quietly rests on a draft is open to challenge — we mark it before anyone asks.
We sell no software and issue no certificates. It follows that a recommendation on system choice, test scope or remediation triggers no revenue for us elsewhere — and that in system selection we sit on your side of the table.
Which part of your validated estate becomes rework when the rulebook changes?
A conversation about the estate and the order of work — not a proposal.