GAMP 5 is a risk based framework for validating computerized systems in regulated manufacturing and quality environments. It sorts software into categories by risk, then scales documentation and testing to match. It sets the baseline most compliance teams use to decide how much validation work a system actually needs.
GAMP 5 is industry guidance published by ISPE, not a regulation in its own right. FDA does not cite it by name in 21 CFR, but its risk based logic maps closely to what inspectors expect to see, which is why most regulated companies use it as their internal framework anyway.
The core idea is proportionality. A system that could hurt a patient if it failed gets a heavier validation package than a system that only affects internal reporting. Treating every system the same wastes effort on the low risk ones and, worse, can leave the high risk ones under tested.
GAMP 5 sorts software into four working categories. Category 1 covers infrastructure software, operating systems and database engines, controlled mainly through change management rather than full application testing. Category 3 covers non configured products used exactly as the vendor supplies them.
Category 4 covers configured products, where your team sets parameters, workflows, or business rules on top of a vendor platform. Category 5 covers custom built or heavily customized applications, which carries the heaviest documentation burden because nobody else has tested that exact code before.
A compliance leader's real job is often catching a category assignment that got fudged to save time. A configured product quietly treated as non configured, so nobody tests the custom rules built on top of it, is a common finding. The category should reflect what your team actually did to the system, not what saves the most paperwork.
No. It is guidance, not a regulation. Inspectors will not cite you for failing to follow GAMP 5 by name, but they will expect a risk based rationale that looks a lot like it.
Not necessarily. A SaaS tool used largely as supplied can sit in Category 3 or 4 depending on how much configuration your team applies on top. Custom code built specifically for your process is where Category 5 applies.
A short walkthrough of how GxPForge keeps traceability current as your team works, instead of reconstructing it before a release.
Book a demo