GAMP 5 Category 3Good Automated Manufacturing Practice (GAMP) 5 Category 3 – Non-configured Product

GAMP 5 Category 3 (non-configured product) denotes commercial off-the-shelf (COTS) software used as provided by the supplier without functional configuration or custom code. In regulated manufacturing, Category 3 components often support MES-level activities (ISA-95 Level 3) such as device drivers, label-printing utilities with default templates, file viewers, communications middleware, or standard calculation/visualization tools where the organization does not modify logic or workflows. Under GAMP 5 (2nd ed.), Category 3 remains in scope for validation when used for GxP-relevant processes or records, but assurance should be proportionate to risk, leveraging supplier testing and focusing on fitness for intended use.

Regulators do not prescribe GAMP categories; they expect validated computerized systems commensurate with risk. FDA 21 CFR Part 11 and EU GMP Annex 11 require controls for electronic records/signatures and computerized systems. Therefore, Category 3 is not an exemption: it is a risk- and evidence-scaling mechanism. The validation package typically includes intended use definition, supplier assessment, installation qualification, minimal functional checks, data integrity controls, procedures, and ongoing change control.

• Used as-is: no functional configuration or custom logic impacting process outcomes
• COTS provenance: standard product with supplier development and testing history
• Validation focus: intended use, supplier competence, security/integrity controls
• Lifecycle: documented installation, basic functional verification, procedural controls

Boundary clarity prevents under- or over-validation. If you adjust functional logic, workflows, or build templates that encode decision rules, you generally drift beyond Category 3. GAMP 5 (2nd ed.) emphasizes critical thinking: classify by how the software is actually used. A label utility with default, vendor-supplied templates and fixed content could be Cat 3; the same utility with custom templates encoding variable logic, calculated data merges, or product-quality algorithms likely becomes Category 4 (configured) or 5 (custom).

Examples commonly and defensibly treated as Category 3 when used strictly as-is: protocol stacks and drivers (e.g., serial-to-ethernet adapters), standard readers/viewers, checksum or hash utilities, agent components of endpoint protection when not configured for process logic, and basic data movers with fixed mappings provided by vendor. Document your rationale and keep it consistent across the inventory.

FDA and EU authorities expect that any computerized system impacting product quality or GxP records is validated and maintained in a state of control. Part 11 applies when electronic records/signatures are used; Annex 11 covers computerized systems more broadly, including supplier and service provider oversight. For Category 3, regulators expect proportionate evidence of fitness for intended use, procedural controls, and data integrity safeguards appropriate to the risk of the process and records handled.

• Intended use definition tied to requirements (what the software must reliably do in your process)
• Supplier assessment (qualification appropriate to reliance on supplier testing and support)
• Installation Qualification (IQ) with environmental prerequisites, versions, and baseline settings
• Targeted functional verification of intended use (not exhaustive re-testing of vendor QA)
• Data integrity controls (access, audit trail if records are modified, backup/restore, time sync)
• SOPs and training (use, security, change control, incident management, backup/restore)
• Change control and periodic review (including supplier patches and end-of-support monitoring)

"Assurance activities should be commensurate with risk and leverage supplier activities where appropriate to demonstrate fitness for intended use."

The FDA’s Computer Software Assurance (CSA) guidance encourages focusing testing on what matters to patient and product risk. For Category 3, that typically translates to concise intended-use scenarios that demonstrate correct installation, security controls, and key functional behaviors relied upon by the process, while avoiding redundant re-testing of supplier-verified standard features. Evidence can mix scripted, unscripted, and automated checks; critical thinking is favored over volume.

A pragmatic Cat 3 test set

• Verify environment pre-requisites and versions (IQ) including hash/signature of installers from the supplier
• Execute intended-use scenarios (e.g., default label print with fixed template renders correctly, driver relays data without transformation)
• Negative/abnormal scenarios for highest risks (e.g., interrupted service restarts cleanly; access rights block restricted operations)
• Backup/restore and time synchronization checks where records are stored or timestamped
• Document configuration baseline (if any security or non-functional settings are applied)

Traceability should connect intended-use requirements to the minimal set of verification activities. The objective is confidence, not paperwork volume. Where appropriate, rely on supplier testing certificates, release notes, and defect histories to justify a reduced re-test scope.

Annex 11 expects appropriate supplier and service provider oversight; GAMP 5 recommends scaling the depth of assessment to reliance and risk. For Category 3, organizations often lean more on supplier development practices, test coverage, and vulnerability management. A lightweight but effective dossier typically includes supplier quality certifications (where applicable), development lifecycle summaries, change management approach, security posture, and support SLAs.

When Category 3 functionality is delivered as SaaS, responsibilities shift but do not disappear. The regulated company remains accountable for validating intended use and ensuring Part 11/Annex 11 compliance of records, access control, audit trail, data retention, and backup/restore. Review cloud shared-responsibility models, identity integration, data residency, encryption at rest/in transit, and the provider’s change notification and incident response processes. Maintain a current record of service versions and evidence for critical controls.

• Define the reliance boundary (what you depend on the supplier to do vs. what you verify)
• Qualify the supplier proportionate to risk (paper assessment, remote/on-site audit as needed)
• For SaaS, confirm e-signature controls, audit trail behavior, and export/archival capabilities
• Capture SLAs and change notifications in quality agreements where feasible

Data integrity (ALCOA+) applies regardless of category when GxP data are created, processed, or stored. For Category 3, determine whether the software creates/maintains original records, modifies data, or only transmits/visualizes. If it impacts original, retained records, you must ensure Part 11/Annex 11-aligned controls—unique user IDs, appropriate audit trails for creation/modification, time synchronization, and secure retention. Where Category 3 tools are only transient or read-only, procedural and technical controls should still prevent data loss or tampering.

• Access control and account lifecycle: least privilege, role definitions, periodic access review
• Audit trail: required if records are created/modified; verify content, timestamps, and review workflow
• Backup/restore: prove that retained records and audit trails can be restored intact
• Time sources: NTP sync across nodes to preserve chronological trustworthiness
• Cybersecurity hygiene: hardening, patching, anti-malware, network segregation per risk (see NIST SP 800-82 for ICS contexts)
• Data export: ensure format and metadata preserve meaning for review and retention

Regulators increasingly scrutinize integrity of metadata and system-generated records. Align your Cat 3 control set with MHRA and PIC/S expectations for contemporaneous, attributable, and complete records, including operator attribution and tamper-evident storage where applicable.

Category 3 products typically update more frequently than bespoke systems. Each change can alter functions, dependencies, or security posture. Maintain a clear baseline (versions, checksums, environment pre-requisites) and evaluate the impact of supplier patches using a risk-based approach. For low-impact updates, targeted regression checks may suffice; for higher-risk changes (e.g., new default behaviors), expand verification accordingly.

• Assess supplier release notes for functional and security impact
• Classify changes (no impact, low, medium, high) and tailor regression checks
• Maintain rollback plans and clean uninstall/reinstall steps
• Periodically review user access, audit trail review effectiveness, and backup restores
• Monitor end-of-life/end-of-support; plan upgrades before security debt accrues

Document each decision and outcome in change records. Periodic review should confirm the system remains fit for intended use, that procedural controls are effective, and that supplier assurance remains adequate (e.g., no significant adverse findings in vulnerability disclosures or quality notices).

A Category 3 package should be concise yet sufficient for an inspector to understand intended use, supplier reliance, control effectiveness, and verification performed. Leverage supplier materials to avoid duplicative testing while ensuring your evidence connects directly to the GxP risks in scope.

Traceability can be simple for Cat 3—link intended-use requirements to verification steps and controls. Keep the package current and right-sized; volume does not equal compliance.

• Misclassification: Hidden functional configuration (e.g., sophisticated templates, scripts) that actually makes the system Cat 4/5. Solution: perform a structured classification review.
• Under-specification: No clear intended-use statement. Solution: write concise, testable intended-use requirements.
• Over-testing: Repeating vendor QA. Solution: apply CSA principles; test only what you rely on.
• Integrity blind spots: No audit trail where records are edited. Solution: assess if records are original/retained; implement audit trail or procedural safeguards.
• Patch drift: Untracked minor updates changing behavior. Solution: enforce change control and baseline checksums/signatures.
• Supplier opacity: Limited insight into development/controls. Solution: scale qualification depth or choose suppliers with transparent practices.

A disciplined intake process—classification, intended-use scoping, supplier assessment, and a lean test plan—prevents most issues. Periodic review catches drift and ensures continued fitness for intended use.

In deployments where specific V5 modules or adjunct tools are used strictly as-is, V5 supports a Category 3 approach by providing verifiable installation assets, version manifests, hardening guidance, and evidence of supplier quality practices. Customers then layer concise intended-use checks focused on the business process. When configurations are introduced, V5 promotes a clear transition to Category 4 governance with configuration specifications and expanded verification.

• Supplier package: release notes, defect histories, security advisories, and lifecycle policy
• Installation assets: signed installers, checksums, and environmental prerequisites
• Security and integrity: access models, audit trail behavior, backup/restore instructions
• Change control enablement: semantically versioned releases and notification practices
• Records unification: MES + QMS + eBMR/eDHR + LIMS + WMS + Maintenance on a single execution record