GAMP is a framework, not a product classification The term “GAMP software” refers to any computerised system that falls within the scope of the GAMP 5 framework — the ISPE’s Good Automated Manufacturing Practice guide for validation of automated systems in pharmaceutical and regulated life sciences environments. GAMP is not a software standard, a certification mark, or a product label. It is a risk-based framework that pharmaceutical companies apply to determine the validation activities appropriate for the systems they use. Any software operating within GxP scope in a pharmaceutical environment is “GAMP software” in this operational sense: it should be classified, risk-assessed, and validated using GAMP 5 principles. That spans enterprise systems (ERP, LIMS, MES), process control (SCADA, DCS), laboratory instruments with embedded firmware, custom-developed applications, and — increasingly — AI and machine learning systems. The label is not what makes something GAMP software. The framework being applied to it is. This matters because the framework is no longer static. The original GAMP 5 from 2008 assumed monolithic, on-premise software, installed once and validated once. The 2022 Second Edition explicitly extends the framework to cloud, agile, microservices, and AI/ML — and that extension changes how classification and validation actually work in practice. How GAMP 5 applies to modern software architectures Modern pharmaceutical software increasingly uses architectures the original framework did not anticipate. The Second Edition addresses each of them, which is why it is the first pharma software validation framework that explicitly covers contemporary development practices rather than retrofitting older categories. Architecture GAMP 5 challenge Second Edition response Cloud / SaaS Validation responsibility split between vendor and user Shared-responsibility guidance; supplier qualification extended to cloud providers Microservices Independent components, each potentially a different category Classify each component independently; validate interactions at integration points AI / ML Non-deterministic behaviour, continuous learning Continuous validation, performance monitoring, drift-detection expectations Agile development Iterative releases conflict with the traditional V-model Maintain validation state across sprints; release-level rather than project-level evidence Containerised deployment Infrastructure abstraction complicates IQ Category 1 qualification extends to the container runtime and orchestration layer Evidence class for the table: observed-pattern — these mappings reflect how we and our customers apply the Second Edition in live GxP environments, not a published benchmark. We see the AI/ML row triggering the most rework, because teams trained on the 2008 edition tend to default to Category 5 for anything resembling a model, and then discover during audit that the data pipeline, the trained artefact, and the inference service have to be classified separately. The structural point is that GAMP 5 Second Edition is now compositional. A single deployed product is rarely “a Category 4 system.” It is a stack of components, each with its own category and its own validation depth. The practical GAMP workflow For any new software system entering a regulated environment, the practical workflow has six steps. The steps have not changed in the Second Edition; what changed is the answers they produce. Determine GxP relevance. Does the system affect product quality, patient safety, or data integrity? If not, GAMP does not apply. If yes, proceed. Classify the system. Assign GAMP software categories (1, 3, 4, 5) to each component. Modern systems often span multiple categories — the ML model is Category 5, the underlying database is Category 1, the configured platform on top is Category 4. Assess risk. Determine the system’s risk to product quality and patient safety. High-risk systems require thorough validation; lower-risk systems require proportionate effort. This is where the move toward Computer Software Assurance (CSA) lives — risk-based testing, not exhaustive enumeration. Define the validation strategy. Document the approach: which activities, which deliverables, which testing depth — anchored to classification and risk. Apply critical thinking, not prescriptive checklists. Execute and document. Perform the validation activities, capture evidence, obtain approvals, and maintain traceability from requirements through test evidence. Maintain. Establish change control, periodic review, and ongoing monitoring that keep the system in its validated state for the rest of its operational life. Step 6 is where AI/ML breaks the older mental model most visibly. Traditional software, once validated, stays validated until somebody changes the code. A continuously-retrained model changes its behaviour every time it is retrained, even when no code changes. The framework’s response is continuous validation: monitoring, drift detection, and pre-defined re-qualification triggers built into operations. The detailed methodology for classifying and validating AI/ML software under GAMP 5 walks through the specifics for the fastest-growing category of pharmaceutical software. Why GAMP adoption matters for software vendors Vendors selling into pharmaceutical companies should care about GAMP 5 because the customer’s validation team will classify and validate the product using this framework regardless of whether the vendor engages with it. Vendors that arrive with GAMP-aligned documentation — a category self-assessment, validation test scripts, audit trail specifications, configuration management evidence — reduce the validation burden on the customer and shorten procurement. A vendor that cannot state the product’s GAMP category, describe its quality management system, or supply validation support documentation is, in effect, asking the customer to do that work. Competing vendors with better regulatory awareness have already eliminated it. In our experience across pharma engagements, this single piece of pre-work tends to be the difference between a vendor reaching the validation phase of a procurement and being filtered out before it. How does the GAMP framework apply to SaaS and cloud-native systems? SaaS challenges the traditional validation model in a specific way: the pharmaceutical company does not control the deployment, the update schedule, or the underlying infrastructure. The vendor may push updates weekly without the customer’s explicit approval — a practice that, taken at face value, conflicts with GxP change control. GAMP 5 Second Edition addresses this with a shared-responsibility model. Our approach in practice: validate the system at a specific version and configuration, monitor vendor change notifications, and assess each vendor update for GxP impact. High-impact changes (new features touching regulated workflows, modified data structures, changed calculation logic) require re-validation. Low-impact changes (bug fixes, performance improvements, UI adjustments) require a documented assessment but not full re-validation. The vendor’s side of the contract is supplying what the customer needs to make that assessment: release notes with explicit GxP impact statements, validation documentation packages, third-party audit reports (SOC 2 Type 2, ISO 27001), and access to test environments where the customer can verify changed behaviour before production cut-over. We help pharmaceutical companies build the SaaS vendor management framework that sits underneath this: vendor qualification (assessing the vendor’s quality system, development practices, and regulatory awareness), service level agreements (uptime, data integrity, change notification requirements), and ongoing monitoring (tracking vendor changes, maintaining configuration documentation, periodic vendor audits). The point is not to slow SaaS adoption down. It is to make modern SaaS solutions usable inside the validation and change-control discipline that regulators expect. FAQ
