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

GAMP 5 Category 3 covers non‑configured products: commercial off‑the‑shelf software used essentially as delivered, with only local environment settings such as preferences, user accounts, or printer choices. There is no bespoke code, no supplier‑delivered configuration layer, and no user‑authored templates that materially alter business logic. The aim is to demonstrate that the product is fit for its intended use in the regulated process without imposing life‑cycle controls meant for configurable or custom applications.

Typical examples include file viewers, checksum utilities, basic data importers that do not transform data, simple instrument communication drivers, or vendor‑supplied desktop clients used solely to read device data. If the same software is extended with configuration that changes processing logic or data structures, it likely migrates to Category 4. If it is part of the underlying platform stack (operating systems, database engines, anti‑malware), it is usually treated as Category 1 infrastructure.

Because Category 3 software is used as‑is, documented assurance emphasizes intended use clarity, supplier dependability, proper installation, security controls, and basic functional checks that are proportionate to process risk. When the software creates, processes, or stores regulated records, the assurance envelope must also cover electronic records and signatures controls.

Regulators do not recognize GAMP categories as law, but they accept them as a risk‑based shorthand for scoping assurance. U.S. FDA requirements derive from predicate rules such as 21 CFR Parts 210 and 211 for drugs, Part 820 for medical devices, and Part 11 for electronic records and signatures. In the EU, EudraLex Volume 4 and Annex 11 set expectations for computerized systems, including validation, data integrity, security, and periodic evaluation.

GAMP 5 aligns with ICH Q9 risk management principles by focusing effort where failure could impact product quality, patient safety, or data integrity. Within that frame, Category 3 systems require defined intended use, proportionate verification, and documented control of suppliers, installation, security, and change. The same foundational controls apply whether the software is on‑premises or delivered as a cloud service, with additional attention to service levels and updates in hosted models.

Authority guidance has increasingly emphasized right‑sized evidence. FDA’s software assurance messaging encourages testing that demonstrates process outcomes rather than paperwork volume. EU inspectorates and PIC/S have likewise reinforced data integrity expectations for access control, audit trails, and record retention. Category 3 therefore does not mean minimal effort; it means targeted assurance commensurate with risk.

Two cross‑cutting themes dominate inspections for Category 3: demonstrating that the software is suitable for its specific use in the regulated process, and proving that records are trustworthy, complete, attributable, and available for the defined retention period.

The Category 3 label depends on how the software is used, not on the vendor’s marketing description. A viewer that only displays records may be Category 3, yet the same product becomes Category 4 if configured to transform or route data. Similarly, a desktop client that launches predefined vendor queries can be Category 3 when used without altering logic, but moves categories if users compose new workflows or templates that drive business rules.

Infrastructure components such as operating systems, database engines, drivers, and anti‑malware are usually Category 1 and managed through IT quality controls rather than process validation. Custom scripts, macros, or integrations that implement business logic are Category 5. When in doubt, determine whether user choices constitute mere preferences or whether they create or alter executable logic and data structure.

Cloud delivery does not change classification by itself. A non‑configured cloud app used strictly as delivered can still be Category 3; however, the assurance package must include vendor service commitments, change notification, and update management suitable for hosted services. This is especially important where software can impact regulated records or decision making in production and quality contexts.

The following examples illustrate typical classification outcomes and the core evidence normally expected for Category 3 uses.

Hosted delivery models add obligations for availability, backup, and patch cadence. For software accessed over the internet, verify service levels, update windows, and data export options to avoid vendor lock‑in and to ensure continuity of operations under GxP cloud computing.

A practical approach starts with a concise statement of intended use that ties the software to a specific regulated task. This statement drives classification and determines the depth of evidence. For example, a checksum utility intended only to verify file integrity before loading data into a quality system warrants focused verification on hashing accuracy and security, rather than broad system testing.

Next, evaluate supplier reliability. Review release history, defect responsiveness, security posture, and the availability of product documentation. Supplier assessment does not transfer validation obligations, but it can justify leveraging vendor evidence and reduce duplicate testing. The more mature the supplier’s quality and security practices, the more you can rely on risk‑based sampling to confirm fitness for use.

Installation verification for Category 3 is typically straightforward: confirm version, checksum or signature, environment prerequisites, and that security settings reflect policy. Functional checks should directly demonstrate intended use. Access control, user roles, backup and restore, and time synchronization are confirmed when records are in scope.

1. Define intended use and impact on product quality, patient safety, and data integrity.
2. Classify the software and document justification.
3. Assess the supplier and decide what vendor evidence to leverage.
4. Perform targeted installation and functional verification aligned to IQ/OQ/PQ needs.
5. Establish security, backup/restore, and retention controls where electronic records are impacted.
6. Release to use with traceable approval and train users on the defined use.

Deliverables scale with risk, but certain artifacts recur across Category 3 implementations. The intended use statement anchors all other evidence. A brief requirements set is acceptable when the software is used as delivered; the point is to document what must work in the regulated process, not to rewrite the vendor manual. Supplier assessment records and installation evidence show that the chosen version is suitable and deployed correctly.

Verification should be concise and traceable to intended use. Where electronic records or signatures are in play, verify identity management, privileges, audit trails when available, time stamps, and backup or archival arrangements. If the product cannot provide intrinsic audit trails for actions that matter, procedural compensating controls are documented and justified.

Sustaining controls include controlled updates, incident and deviation handling, and periodic review. Even for Category 3, changes that could impact intended use must be assessed, tested proportionately, and approved before release. Training completes the readiness package when user behavior is material to proper operation.

• Intended use statement with classification rationale
• Supplier assessment and acceptance decision
• Installation verification with version identity and prerequisites
• Targeted functional checks mapped to intended use
• Security and record controls, including backup and retention when applicable
• Release to use, training, and entry into change control and periodic review of computerized systems

Risk drives the depth of evidence for Category 3. Start by analyzing hazards related to the software’s intended use: can it alter data used for product release, conceal critical information, or create opportunities for unauthorized access? Where the impact is low and detection is high, testing can be light and focused. Where the impact is moderate, increase independence and traceability of checks.

Leverage vendor evidence sensibly. If the supplier provides a security white paper or a verification summary for core algorithms, reference it, then add targeted confirmation tests in your environment. Avoid duplicating vendor functional testing that is unrelated to intended use. Instead, demonstrate that your process works end‑to‑end with the deployed version and configuration.

FDA’s software assurance posture supports unscripted or ad hoc testing when appropriate, provided it is planned, recorded, and traceable to intended use. For Category 3, this often means a small number of well‑designed tests with clear pass criteria, documented results, and captured objective evidence such as screenshots, logs, or checksums. Independence of review should scale with risk.

Finally, document residual risk and monitoring. If compensating procedural controls are used, explain how they mitigate risk and how effectiveness will be verified over time. Maintain a concise entry in the enterprise quality risk register and link it to the system record for traceability.

The most frequent mistake with Category 3 is assuming that non‑configured means no validation. Regulators expect you to prove fitness for the defined use and to control the lifecycle proportionately. Another common error is the opposite: applying a heavy Category 4 or 5 template, generating documents that add little insight while obscuring the real risk picture.

Misclassification often arises when local settings drift into configuration that affects logic or data structure. If users create templates, mappings, or workflows that drive processing decisions, the software likely belongs in Category 4. Likewise, custom scripts or macros that interact with the software can elevate the overall solution to Category 5, even if the base product is Category 3.

Cloud updates and patches can silently change behavior. Failing to monitor release notes, change notifications, or service advisories introduces uncontrolled change. Finally, over‑reliance on supplier documentation without in‑house confirmation misses the point of intended use assurance in your environment.

• Skipping intended use definition and testing only generic features
• Treating preference changes or add‑ins that alter logic as if they were harmless
• Relying solely on vendor docs without local confirmation of critical functions
• Ignoring access control, time, and archival needs when records are involved
• Letting auto‑updates bypass evaluation and approval
• Omitting disaster recovery, backup, or restore checks for critical data paths

When Category 3 software touches regulated records, expectations align with Part 11 and Annex 11. You must show that records are attributable, legible, contemporaneous, original or true copies, and accurate, and that they are protected throughout retention. Where audit trails exist, verify that they are secure, time‑stamped, and capture who, what, when, and where for events material to the intended use.

If the product lacks audit trail capability but the intended use still impacts decisions, define procedural controls such as controlled logs, independent verification, or system‑level controls elsewhere in the process. Secure user management, role‑based access, password policy conformance, and reliable time sources are essential. Backup and restore must preserve record integrity and provenance.

Electronic signatures require identity assurance and binding to the signed record, with clear meaning and context for the action taken. Even when signatures are not used, ensure that electronic copies are accurate and that migration or export retains metadata necessary for interpretation.

Category 3 sits between Category 1 infrastructure and Category 4 configured applications. It borrows infrastructure controls from IT for hardening and patching, yet it also requires process validation elements to prove fitness for use. Where configuration begins to drive behavior or data, migrate to Category 4 and extend life‑cycle controls accordingly.

Category 5 applies when custom code is developed, including macros, scripts, or bespoke integrations that implement business logic. In such cases, user requirements, functional specifications, design reviews, and more formal verification are appropriate. The risk‑based philosophy remains the same across categories, but the depth and formality of evidence increases with configurability and novelty.

Category 3 also aligns with quality management standards that emphasize documented processes and evidence of control. ISO 9001 and ISO 13485 quality systems reinforce supplier management and change control, while ICH Q9 provides the risk framework that underpins right‑sized assurance. FDA’s modern software assurance posture and PIC/S guidance are consistent with applying critical‑thinking to select the least burdensome, most demonstrative tests.

• If preferences change behavior or data structure, escalate to GAMP 5 Category 4.
• If custom code or macros implement logic, treat as GAMP 5 Category 5.
• If the component is platform infrastructure, manage as Category 1 under IT quality controls.

V5 Ultimate operationalizes Category 3 by anchoring the entire control set to a single, auditable execution record. Supplier assessment, intended use definition, installation verification, targeted functional checks, and residual risk are managed as linked, versioned artifacts. This keeps evidence compact, coherent, and ready for inspection while aligning with risk‑based expectations from FDA, EMA, and PIC/S.

Where electronic records are in scope, V5 captures access control confirmations, backup and restore checks, and tamper‑evident attachments of objective evidence. Change intake, impact assessment, proportional testing, and approval flow are streamlined so that even security patches and minor upgrades can be released with traceability and speed.

The execution record spans manufacturing and quality contexts, enabling cross‑references to batch or device history and deviations without duplicating documentation. Integration with production and quality workflows helps ensure that Category 3 systems remain in control during operation and through their lifecycle, including periodic review and retirement.