This is a ready-to-use worksheet for assigning the GAMP 5 software category and, just as important, for catching the custom elements hidden inside an otherwise configured system. Replace every <<FILL: ...>> placeholder with your specifics. A worked filled specimen follows. The category is the baseline posture, an input to a full risk assessment, not the final verdict on test scope.
Document control header
| Field | Entry |
|---|---|
| Worksheet title | GAMP 5 Software Categorization |
| Record number | <<FILL: FORM-ID, e.g. FRM-VAL-021-02>> |
| Parent SOP | <<FILL: SOP-ID for risk-based validation scoping>> |
| System name / ID | <<FILL: SYSTEM NAME / ID>> |
| Assessment date | <<FILL: date>> |
| Assessor | <<FILL: name, role>> |
1. Purpose
This worksheet assigns the GAMP 5 category for <<FILL: SYSTEM NAME / ID>> and identifies any custom software elements embedded in it, so the baseline validation approach and the occurrence input to risk scoring are set on a documented basis. It exists mainly to prevent two errors: treating a custom calculation inside a configured platform as “just configuration,” and carrying the retired Category 2 forward from a stale template.
2. The categories
| Category | What it is | Typical examples | Baseline approach |
|---|---|---|---|
| 1: Infrastructure | Layered software the application runs on | Operating system, database engine, virtualization, network services | Qualified as infrastructure, not validated as an application; installation records, version control, vendor documentation |
| 3: Non-configured | Used as delivered, no GxP-meaningful configuration | Firmware-driven instruments, off-the-shelf tools used as-is | Verify it does what the vendor claims for your use; rely on supplier testing |
| 4: Configured | Standard platform configured for site use | LIMS, MES, eQMS, CTMS, chromatography data systems | Risk-based verification focused on configured GxP functions |
| 5: Custom | Built specifically for the organization | Bespoke applications, custom scripts, custom control logic, custom interfaces | Highest rigor; development lifecycle evidence, design review, code review where relevant, full functional testing |
Category 2 no longer exists. Seeing it in a current document is a sign the template is stale.
3. Category decision aid
Work down the questions; the first Yes sets the primary category, then complete section 4 for embedded custom elements.
| Question | If Yes |
|---|---|
| Is this layered software the GxP application depends on (OS, DB, hypervisor, network)? | Category 1 (infrastructure qualification) |
| Is it used exactly as delivered, with no configuration that changes a GxP outcome? | Category 3 |
| Is it a standard product you configure (workflows, rules, roles, reports) for your use? | Category 4 |
| Is it, in whole or part, built specifically for you (bespoke code, custom scripts, custom logic)? | Category 5, for the built part |
4. Embedded custom elements
A Category 4 platform almost always contains Category 5 elements. Custom code has no installed base, so it carries higher latent-defect likelihood and inherits Category 5 expectations even inside a configured system.
| Element | Description | Standard config or custom? | Category | Rationale |
|---|---|---|---|---|
<<FILL: e.g. stability trend calculation>> | <<FILL>> | Custom | 5 | <<FILL>> |
<<FILL: e.g. ERP interface>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
<<FILL: e.g. approval workflow>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
5. Determination
| Field | Entry |
|---|---|
| Overall system category | <<FILL: 1 / 3 / 4 / 5>> |
| Rationale | <<FILL>> |
| Embedded Category 5 elements | <<FILL: list, or None>> |
| Effect on occurrence scoring | <<FILL: e.g. custom elements raise baseline occurrence; treat as input to FMEA, not a second axis>> |
| Baseline validation posture | <<FILL: derived from the category table>> |
6. Acceptance criteria
- A single overall category is assigned with a written rationale.
- Category 2 is not used.
- Every custom element inside a configured platform is listed and assigned Category 5.
- The category is used as an input to the occurrence score, not double-counted as a separate risk axis.
- The worksheet is signed and filed with the risk assessment.
7. Signatures
| Role | Name | Signature | Date |
|---|---|---|---|
| Assessor | <<FILL>> | ||
| Quality Assurance | <<FILL>> |
8. References
ISPE GAMP 5 (Second Edition), A Risk-Based Approach to Compliant GxP Computerized Systems. FDA guidance, Computer Software Assurance for Production and Quality Management System Software. EU GMP Annex 11 (computerised systems).
Confirm the current version of each reference before issue.
Filled specimen
The following shows the worksheet completed for an example manufacturing execution system (MES). The specifics are illustrative.
Category decision: The MES is a standard vendor product configured with site recipes, workflows, roles, and reports. First Yes lands at “standard product you configure,” so the overall category is 4.
Embedded custom elements
| Element | Description | Standard config or custom? | Category | Rationale |
|---|---|---|---|---|
| Yield calculation script | Site-authored script computing batch yield from weigh steps | Custom | 5 | Bespoke code, no vendor installed base; feeds a batch-record value |
| Historian interface | Standard connector, out-of-box mapping | Standard config | 4 | Vendor-supplied connector, configured mappings only |
| Deviation-trigger workflow | Custom-scripted branch beyond the configuration toolkit | Custom | 5 | Logic scripted beyond configuration; can suppress a deviation flag |
Determination: Overall Category 4. Embedded Category 5 elements: yield calculation script, deviation-trigger workflow. Effect on scoring: both custom elements raise the baseline occurrence and warrant design and code review in addition to functional testing. Baseline posture: risk-based verification of configured functions, plus custom-software rigor on the two scripted elements.
In this example, treating the yield calculation and the deviation-trigger workflow as “just configuration” would have missed exactly the two elements most able to corrupt a batch record. Flagging them as Category 5 sends them to code review and boundary testing, which is where a custom calculation belongs.
Common findings this worksheet prevents
- A custom calculation or script inside a “configured” system that never received custom-software scrutiny, a classic inspection finding.
- A stale template still listing the retired Category 2.
- A whole enterprise platform labelled Category 4 with no acknowledgement of the bespoke code it contains.
- Category treated as a second risk axis and double-counted with occurrence.
How to adapt this worksheet
- Set your record number and parent-SOP reference.
- Add rows to section 4 for every integration, report calculation, and scripted workflow; these are where embedded custom code hides.
- Feed the category and the embedded-custom list straight into the FMEA occurrence scoring on your risk assessment.
- Confirm the reference versions in section 8 before issue.