What GMP Actually Is
Good Manufacturing Practice is a set of legally enforceable minimum standards for the manufacturing, testing, and quality control of medicines. In simple terms: GMP defines what a pharmaceutical company must do to consistently produce a product that is safe, effective, and of the required quality.
Every country with a pharmaceutical industry has a GMP framework. The FDA's is written into US federal law under 21 CFR Parts 210 and 211. The EU's is codified in EU GMP — a series of guidelines published by the European Commission, of which Annex 11 specifically covers computerised systems. Japan, Canada, Australia, and most other regulated markets have equivalent frameworks, many of them harmonised through the ICH (International Council for Harmonisation).
As an automation engineer, the framework that applies to you depends on which market your client is supplying. If they sell medicines in Europe, Annex 11 applies. If they sell in the US, 21 CFR Part 11 applies. Many global manufacturers have to satisfy both simultaneously — which is why so much pharma validation documentation is written to meet the stricter of the two requirements.
GMP doesn't regulate automation engineers directly. It regulates the pharmaceutical company. But the pharmaceutical company is your client, and they cannot meet GMP requirements without the documentation you produce. Your validation deliverables are their compliance evidence.
Why GMP Exists — The Short History
GMP exists because people died. The modern framework traces back to catastrophic drug quality failures in the mid-twentieth century. The 1937 Sulfanilamide disaster — in which over a hundred people died from a medicine dissolved in a toxic solvent that had never been tested — prompted the US Federal Food, Drug, and Cosmetic Act of 1938. The thalidomide crisis of the late 1950s and early 1960s, which caused severe birth defects in thousands of children, drove further regulatory tightening on both sides of the Atlantic.
These events established a core principle that underpins everything you will do on a pharma project: the consequences of a manufacturing error are not a product recall and a refund — they are patient harm or death. GMP is the regulatory framework built to make such errors systematically less likely.
Understanding this is the most important context shift you need to make when moving from industrial to pharmaceutical automation. On a standard industrial project, a software bug causes downtime or product waste. On a pharma project, a software bug that corrupts a batch record, bypasses an interlock, or corrupts a dosing calculation can harm a patient who will never know your name. GMP is the framework that prevents that from happening at scale.
What GMP Means for Computerised Systems
GMP was written before modern automation existed. The original regulations talk about manufacturing records, equipment calibration, and laboratory testing. As the industry adopted computers, a question arose: how does GMP apply when the record is an electronic file, the signature is a click, and the equipment is controlled by software?
The answer came in two forms. In the EU, Annex 11 to EU GMP was developed specifically to address computerised systems. In the US, 21 CFR Part 11 was published in 1997 to govern electronic records and electronic signatures. Both establish the same fundamental principle: an electronic system used in GMP activities must be validated — meaning you must produce documented evidence that it does what it is supposed to do, consistently and reliably.
This is why your PLC and SCADA system needs an IQ, OQ, and PQ protocol. It is why your software version needs to be under configuration control. It is why your audit trail cannot be disabled. These are not arbitrary bureaucratic requirements — they are the mechanism by which a regulator can trust that the system controlling a medicine's manufacture is fit for purpose.
GMP vs non-GMP automation: what actually changes
The engineering is largely the same. The difference is the evidence trail. In GMP automation, you are required to prove — in writing, with signatures — that:
- The system was designed to meet defined requirements (URS → FDS → SDS → HDS)
- The system was built as designed (IQ verifies installation against design documents)
- The system functions correctly across its full operating range (OQ tests every function)
- The system performs reliably under actual production conditions (PQ)
- Any deviations from expected behaviour are formally raised, assessed, and closed
- Any subsequent changes are assessed, approved, and re-validated where necessary
None of this changes what the system does. All of it changes how much work surrounds it — and what happens if you can't produce the paperwork.
How GMP Directly Impacts Your Work
Let's make this concrete. Here are the practical ways GMP touches your day-to-day work as an automation engineer on a pharma project.
| Standard Project | GMP Pharma Project |
|---|---|
| Requirements in an email chain | URS: a controlled document, approved and signed |
| Design decisions discussed verbally | FDS / HDS / SDS: formal design specifications with sign-off |
| Testing done informally, results in a spreadsheet | IQ / OQ protocols: pre-approved, each test case signed by executor and reviewer |
| Software fix pushed live, colleagues informed | Change Control Request raised, impact assessment written, re-test executed, QA approved |
| Audit trail: optional / nice to have | Audit trail: mandatory, tamper-evident, retained per data retention policy |
| Backup: IT's problem | Backup & Recovery Procedure: validated, tested, documented in IQ |
Where GAMP 5 Fits In
GMP regulations tell you what must be achieved — a validated system, documented evidence, controlled changes. They don't tell you exactly how to achieve it. That's where GAMP 5 comes in.
GAMP 5 — Good Automated Manufacturing Practice, published by the International Society for Pharmaceutical Engineering (ISPE) — is industry guidance, not law. It describes a practical methodology for validating computerised systems in a GMP environment. It introduces the software category framework (Categories 1–5), the risk-based approach, and the V-model lifecycle that maps every design document to a qualification test.
Regulators routinely reference GAMP 5 as an acceptable approach to compliance. FDA investigators and EU GMP auditors both expect to see a validation methodology that is consistent with GAMP 5 principles — even if the words "GAMP 5" never appear in your documentation.
GAMP 5 is guidance — it represents industry consensus on best practice. EU GMP Annex 11 and 21 CFR Part 11 are law. Failing to follow GAMP 5 is not a regulatory violation. Failing to meet the validated state requirements of Annex 11 or Part 11 is. In practice, following GAMP 5 is the most reliable route to satisfying both.
The Document That Governs Everything
On a GMP project, the first document you should look for — and if it doesn't exist, help create — is the Validation Plan. The VP is the governing document for the entire project. It defines the validation scope, the GAMP 5 category, the V-model lifecycle that will be followed, all the deliverable documents, and who is responsible for each.
Nothing in GMP validation happens ad hoc. The Validation Plan defines the game before it starts. If the system scope changes, the VP must be updated and re-approved. If additional testing is required, the VP defines how it fits into the framework.
Understanding the VP is the fastest way to orient yourself on a new pharma project. It tells you what documents exist, what each one does, who owns it, and what the exit criteria are for each phase.
What This Means for You as an Engineer
You don't need to be a regulatory expert. You need to understand the purpose of the framework so that your engineering decisions are compatible with it.
The most important mental shift: in a GMP project, the document is the product. A perfectly engineered system with poor or missing documentation will fail a regulatory inspection. A competently engineered system with excellent documentation — including properly raised deviations, thorough test cases, and a clear audit trail — will pass.
That's not a criticism of engineering. It's a recognition that the regulator cannot inspect your engineering brain. They inspect your documentation. Your job is to produce documentation that faithfully represents what you built and how you tested it.
The QLean Automation framework gives you the document set that a well-run GMP validation project requires — structured to satisfy both Annex 11 and Part 11 requirements, built around the GAMP 5 V-model lifecycle.
If you're new to pharma projects, the best reading sequence is: this article → the V-model → GAMP 5 categories → the Validation Plan. Those four articles give you the conceptual framework that makes every other GMP document make sense.