GAMP 5 Software Categories and Validation Strategy

GAMP 5 software categories provide a practical way to characterize software components according to how they are developed, configured, and maintained. Categorization helps determine what supplier evidence may be used, which specifications are appropriate, what configuration or code controls are needed, and how verification should be structured.

The categories are not GxP risk levels. They do not determine whether a computerized system is critical, how extensively it must be validated, or whether a fixed Installation Qualification (IQ), Operational Qualification (OQ), and Performance Qualification (PQ) package is required.

Validation scope should be based primarily on:

• intended use;
• patient-safety and product-quality impact;
• data criticality;
• regulated records and decisions;
• credible failure scenarios;
• configuration and customization;
• novelty and complexity;
• interfaces;
• supplier capability;
• available evidence;
• and the ability of other controls to prevent or detect failure.

A highly configurable commercial system can support a critical manufacturing or laboratory process. A custom application can support a limited administrative function. Software category helps determine how assurance should be established; intended use and risk determine what requires assurance.

The four categories commonly applied under GAMP 5 are:

• Category 1 — infrastructure software;
• Category 3 — nonconfigured commercial products;
• Category 4 — configured products; and
• Category 5 — custom applications or components.

The absence of Category 2 is intentional. Earlier GAMP models treated firmware as a separate category, but current categorization addresses software according to its applicable infrastructure, standard-product, configured-product, or custom characteristics.

Categorize Components, Not Merely Product Names

A computerized system often contains components from several software categories. For example, a laboratory information management system (LIMS) may include:

• an operating system and database platform—Category 1;
• a standard document-viewing utility—Category 3;
• the configured LIMS application—Category 4;
• custom calculations, scripts, reports, or interfaces—Category 5;
• supplier-managed cloud infrastructure—Category 1;
• and standard monitoring or backup agents—Category 1 or Category 3, depending on how they are used and controlled.

Assigning one category to the entire LIMS as if every component had the same characteristics would conceal important differences in supplier responsibility, documentation, testing, and lifecycle control.

Categorization should therefore be performed at a level that supports validation decisions. Depending on the architecture, the assessment may identify categories for:

• the principal application;
• infrastructure;
• individual modules;
• custom extensions;
• scripts and macros;
• calculations;
• reports;
• interfaces;
• middleware;
• low-code applications;
• instrument firmware;
• and supporting utilities.

The purpose is not to create an excessively detailed software inventory. Components should be separated when their development method, supplier evidence, failure risk, configuration, customization, or maintenance responsibility materially affects the assurance strategy.

Category 1—Infrastructure Software

Category 1 includes software used to establish, operate, manage, secure, monitor, or support the technical environment in which GxP applications function.

Examples may include:

• operating systems;
• database-management systems;
• network services;
• virtualization platforms;
• cloud infrastructure services;
• storage systems;
• directory and identity services;
• domain services;
• time-synchronization services;
• middleware platforms;
• web servers;
• application servers;
• backup agents;
• monitoring tools;
• endpoint-management tools;
• antivirus or malware-protection software;
• and infrastructure-management utilities.

Infrastructure software may not execute the regulated business process directly, but its failure can affect:

• system availability;
• authentication;
• authorization;
• record integrity;
• timestamps;
• electronic signatures;
• data transfer;
• backup;
• restoration;
• security;
• performance;
• and recovery.

Category 1 should therefore not be interpreted as low risk or non-GxP. Infrastructure components can have significant indirect impact on regulated applications and records.

Category 1 Assurance Strategy

Assurance commonly focuses on:

• approved products and versions;
• defined technical architecture;
• supported operating environments;
• installation or provisioning;
• enabled services;
• configuration baselines;
• environment separation;
• security configuration;
• user and service accounts;
• network connectivity;
• time synchronization;
• storage;
• capacity;
• availability;
• monitoring;
• backup;
• restoration;
• patching;
• vulnerability management;
• change control;
• and technical support.

Supplier or platform evidence may provide significant assurance for standard infrastructure products. The regulated organization should still verify that the infrastructure is correctly provisioned, configured, connected, secured, monitored, and supported for its intended role.

For shared infrastructure, qualification evidence may be established once and referenced by several application systems. Each application should still identify its infrastructure dependencies and evaluate whether the shared controls adequately support its intended use.

Category 1 Documentation

Depending on risk and complexity, lifecycle evidence may include:

• infrastructure architecture;
• approved product and version inventory;
• configuration standards;
• installation or provisioning records;
• network diagrams;
• environment specifications;
• security baselines;
• service-account records;
• backup configuration;
• monitoring configuration;
• restoration evidence;
• support agreements;
• patch records;
• and change history.

The boundary between infrastructure qualification and application validation should be clearly defined. Infrastructure qualification establishes confidence in the shared technical environment; application validation establishes confidence that the configured application and complete business process are fit for intended use.

This boundary is addressed further in IT Infrastructure Qualification for GMP Computerized Systems.

Category 3—Nonconfigured Commercial Products

Category 3 includes commercially available software products used largely as supplied, with limited configuration of the application’s functional behavior.

Examples may include:

• standard utilities;
• commercial document viewers;
• basic data-acquisition tools;
• standard operating-system utilities;
• commercial analytical tools used without configurable workflows;
• simple monitoring applications;
• and packaged applications whose standard functions are used without material business-process configuration.

Ordinary setup parameters do not necessarily make a product Category 4. Examples of basic setup may include:

• installation paths;
• printer selection;
• display preferences;
• network addresses;
• language;
• time zone;
• connection parameters;
• or similar technical settings that do not establish regulated workflows or business rules.

The distinction depends on what the settings control. A parameter that appears simple may be significant if it determines a critical calculation, specification, security permission, record-retention rule, or process sequence.

Category 3 Assurance Strategy

The supplier generally determines the product’s standard functionality. Assurance may rely substantially on:

• established commercial use;
• supplier reputation;
• product documentation;
• release information;
• installation instructions;
• technical specifications;
• and supplier testing.

Site verification should confirm the functions relied upon for the actual intended use.

Relevant activities may include:

• confirming the approved version;
• verifying installation;
• identifying enabled functions;
• testing critical standard functions;
• verifying calculations;
• challenging error handling;
• confirming record creation and retention;
• verifying access restrictions;
• testing interfaces;
• and confirming operation in the site environment.

A Category 3 product does not automatically require minimal testing. If a standard function performs a critical calculation or produces the sole regulated record, focused and rigorous verification may be necessary.

Category 3 Documentation

Documentation may include:

• intended-use statement;
• product description;
• supplier assessment;
• installation record;
• user requirements;
• standard-function assessment;
• risk assessment;
• focused test evidence;
• procedures;
• training;
• release approval;
• and change-control records.

Separate functional and design specifications may provide little value when the organization does not control the product design and reliable supplier documentation already defines its operation. Requirements and verification should still clearly establish which standard functions are relied upon.

Category 4—Configured Products

Category 4 includes commercially available products whose behavior is adapted through configuration to support the organization’s business process.

Examples include configured:

• laboratory information management systems;
• chromatography data systems;
• manufacturing execution systems;
• electronic quality-management systems;
• enterprise resource-planning systems;
• warehouse-management systems;
• document-management systems;
• building-management systems;
• environmental-monitoring systems;
• electronic batch-record systems;
• training-management systems;
• and cloud-based software-as-a-service applications.

Configuration uses mechanisms intentionally provided by the supplier to define system behavior without modifying the product’s underlying source code.

Configuration may establish:

• workflows;
• status transitions;
• user roles;
• permissions;
• approval steps;
• electronic signatures;
• audit-trail settings;
• code tables;
• master data;
• specifications;
• analytical methods;
• recipes;
• calculations;
• alarm limits;
• notifications;
• forms;
• screens;
• reports;
• dashboards;
• interface mappings;
• retention settings;
• and business rules.

Category 4 Assurance Strategy

The supplier remains responsible for the core product, while the regulated organization is responsible for establishing that the selected configuration supports its intended use.

Assurance should address:

• supplier capability;
• product suitability;
• requirements;
• configured functions;
• configuration specifications;
• architecture;
• security;
• data integrity;
• interfaces;
• configuration records;
• configuration review;
• functional testing;
• representative workflows;
• migration;
• release;
• and configuration change control.

Supplier testing may provide assurance for the underlying product. It does not demonstrate that the site’s workflows, roles, calculations, reports, master data, interfaces, or other configuration elements are correct.

Category 4 Documentation

Lifecycle documentation may include:

• intended use;
• system architecture;
• user requirements;
• functional specifications;
• configuration specifications;
• data and interface specifications;
• configuration workbooks;
• role and permission matrices;
• supplier evidence;
• risk assessments;
• test scripts or test charters;
• migration evidence;
• traceability;
• approved configuration baseline;
• release documentation;
• and change records.

The documentation structure should reflect the system’s complexity. A configuration workbook may combine several specification types when it remains clear, approved, traceable, and maintainable.

Configuration Verification

Configuration verification should confirm that:

• approved values were entered correctly;
• workflows follow approved business rules;
• roles and permissions enforce intended access;
• electronic signatures operate correctly;
• audit trails capture required events;
• calculations use approved formulas;
• units, precision, and rounding are correct;
• reports display complete and accurate information;
• interfaces use approved mappings;
• invalid values are rejected or controlled;
• configuration changes are restricted;
• and the production baseline matches the approved configuration.

A configuration review alone may not demonstrate correct functional behavior. Important configured workflows and controls should be exercised under representative conditions.

Category 5—Custom Applications and Components

Category 5 includes software developed specifically for the regulated organization or custom code added to a commercial platform.

Examples may include:

• fully custom applications;
• custom modules;
• custom extensions;
• bespoke middleware;
• scripts;
• macros;
• custom calculations;
• custom reports containing executable logic;
• custom interface code;
• database procedures;
• low-code components with custom logic;
• robotic-process-automation scripts;
• and supplier-developed bespoke functionality.

Custom software may be developed internally, by an integrator, by the principal application supplier, or by another contracted developer. Supplier development does not make bespoke code a standard commercial product.

Category 5 Assurance Strategy

Category 5 generally requires greater visibility into design and development because the organization cannot rely solely on broad commercial use or standard product evidence.

Assurance may address:

• approved requirements;
• software architecture;
• detailed design;
• algorithms;
• data structures;
• coding standards;
• source-code control;
• code review;
• unit testing;
• integration testing;
• build management;
• deployment;
• defect management;
• cybersecurity;
• technical documentation;
• maintenance responsibilities;
• and regression testing.

The required depth should reflect the custom component’s intended use, complexity, novelty, and failure risk.

A short script performing a critical calculation may require focused review and testing rather than the complete documentation structure used for a large custom application. The script should still have controlled requirements, source code, independent review, version identification, verification, release, and change control.

Category 5 Supplier Oversight

When custom software is developed by a supplier, the regulated organization should determine:

• who owns the requirements;
• who owns the source code;
• where the source is maintained;
• which development procedures apply;
• how code is reviewed;
• how defects are managed;
• what testing is performed;
• what evidence will be delivered;
• how builds are identified;
• how changes are authorized;
• how cybersecurity is addressed;
• what happens if the supplier fails;
• and how the software will be supported or transferred.

A contractual statement that the supplier follows a development lifecycle is not sufficient evidence by itself. The organization should assess whether the supplier’s practices and records are adequate for the specific component and intended use.

Category 5 Documentation

Depending on scope and risk, documentation may include:

• requirements;
• architecture;
• functional specifications;
• detailed design specifications;
• data models;
• interface specifications;
• algorithm descriptions;
• source-code records;
• code-review evidence;
• unit-test evidence;
• integration-test evidence;
• build records;
• deployment records;
• system tests;
• traceability;
• defect records;
• release notes;
• maintenance documentation;
• and change history.

The purpose is not to create documents for their own sake. The records should permit review of what was designed, what was built, how it was verified, what version was released, and how it can be maintained safely.

Configuration Versus Customization

The distinction between configuration and customization is fundamental to categorization.

Configuration

Configuration uses supported mechanisms supplied with the product to adapt its behavior.

Examples include:

• selecting workflow steps;
• defining user roles;
• assigning permissions;
• setting status transitions;
• entering specifications;
• defining code tables;
• setting alarms;
• creating forms using supplier-provided tools;
• setting report parameters;
• defining retention periods;
• and mapping fields using a supported interface engine.

Configuration generally remains within the supplier’s documented product architecture and upgrade path.

Customization

Customization introduces or modifies executable logic beyond standard supplied behavior.

Examples include:

• writing source code;
• modifying supplier code;
• developing scripts;
• creating macros;
• writing database procedures;
• implementing custom algorithms;
• developing plug-ins;
• adding custom interface code;
• creating executable report logic;
• and developing unsupported extensions.

Customization usually creates additional ownership for design, code control, testing, defect management, regression, and maintenance.

The Boundary Is Not Determined by the Tool’s Label

A supplier may describe a development environment as a configuration tool even when it allows substantial executable logic. Conversely, a report designer may provide fixed supplier-supported functions that do not create meaningful custom code.

The assessment should determine:

• whether executable logic is created;
• whether the user defines algorithms or decision logic;
• whether the result operates within supported product functions;
• whether supplier testing covers the mechanism;
• whether source-like artifacts must be version controlled;
• whether independent code or logic review is possible;
• how upgrades affect the component;
• and who is responsible for maintaining it.

A documented rationale should be used for borderline components.

Scripts and Macros

Scripts and macros should be evaluated as software components, not dismissed because they are short or embedded in another application.

Examples include:

• spreadsheet macros;
• instrument-control scripts;
• statistical scripts;
• data-transformation scripts;
• scheduled jobs;
• shell scripts;
• database scripts;
• robotic-process-automation scripts;
• and report-generation scripts.

The assessment should consider whether the script:

• performs a regulated calculation;
• changes or transforms data;
• controls equipment;
• transfers records;
• assigns status;
• automates approvals;
• creates reports;
• modifies configuration;
• or supports recovery or archival.

Controls may include:

• approved requirements;
• controlled source files;
• unique version identification;
• restricted modification;
• independent logic or code review;
• test inputs and expected results;
• boundary and error testing;
• release approval;
• production deployment control;
• and change history.

A simple script with low GxP impact may require concise evidence. A script that transforms laboratory results or assigns batch status may require rigorous design review, testing, and traceability.

Custom Reports

Not every custom report is Category 5.

A report may remain part of Category 4 when it is created entirely through supported configuration using:

• approved fields;
• fixed filters;
• standard groupings;
• standard calculations;
• and supplier-controlled report functions.

A report may contain Category 5 elements when it uses:

• custom queries;
• executable expressions;
• custom code;
• database joins not controlled by the application;
• data transformations;
• custom calculations;
• or externally developed reporting logic.

Report assurance should address:

• source fields;
• authoritative data sources;
• selection criteria;
• joins;
• filters;
• units;
• calculations;
• rounding;
• record status;
• time zones;
• omitted or duplicated records;
• output format;
• and reconciliation to source data.

Visual comparison of a report layout is not sufficient when underlying selection or calculation logic could be incorrect.

Interfaces and Middleware

Interfaces may include Category 1, Category 3, Category 4, and Category 5 components.

Examples include:

• standard application programming interfaces;
• supplier-provided connectors;
• configured middleware mappings;
• custom interface programs;
• file transfers;
• message queues;
• database integrations;
• and robotic-process-automation transfers.

A standard connector may be Category 3. A configured mapping in a commercial integration platform may be Category 4. Custom transformation or routing code may be Category 5. The middleware platform itself may depend on Category 1 infrastructure.

Interface assurance should address:

• source and destination;
• authoritative source;
• transfer direction;
• field mapping;
• units;
• precision;
• transformations;
• timestamps;
• record status;
• security;
• acknowledgments;
• rejected messages;
• duplicates;
• retries;
• reconciliation;
• monitoring;
• and recovery.

Supplier evidence may support the standard transfer mechanism, but site-specific mapping, transformation, exception handling, and end-to-end behavior require appropriate verification.

Further guidance is provided in Computerized System Interfaces and Data-Transfer Controls.

Low-Code and No-Code Components

Low-code and no-code platforms can produce configured or custom components depending on how they are used.

A component may align with Category 4 when it uses supplier-supported features to establish:

• standard forms;
• documented workflow steps;
• standard approval rules;
• supported notifications;
• role assignments;
• and predefined data operations.

A component may contain Category 5 elements when users create:

• executable expressions;
• custom functions;
• scripts;
• complex decision logic;
• external code;
• custom connectors;
• algorithms;
• or unsupported extensions.

The terms “low-code” and “no-code” do not establish low risk. Visual logic can be as consequential and difficult to review as conventional source code.

Controls should consider:

• application ownership;
• developer permissions;
• segregation of development and approval;
• platform version;
• environment separation;
• component versioning;
• logic review;
• testing;
• deployment;
• auditability;
• supplier updates;
• data retention;
• and retirement.

Citizen-development programs should define when business users may create applications, when formal development controls apply, and when an application must be replaced by a more controlled solution.

Custom Calculations

A calculation should be assessed according to its logic and intended use, regardless of whether it is implemented through configuration, a formula editor, a report, a spreadsheet, a script, or custom code.

The assessment should identify:

• formula;
• input data;
• source and units;
• constants;
• lookup tables;
• transformations;
• precision;
• rounding;
• boundary conditions;
• missing data;
• invalid data;
• error handling;
• output;
• record retention;
• and downstream use.

Verification should use independently established expected results and include:

• representative values;
• boundary values;
• zero and negative values where applicable;
• invalid inputs;
• decimal precision;
• unit conversion;
• rounding points;
• and relevant worst-case combinations.

A custom calculation embedded in a Category 4 platform may need Category 5-style logic review and testing even when the remainder of the application remains Category 4.

Firmware and Embedded Software

Firmware is not assigned automatically to a separate Category 2 under the current GAMP 5 model.

Embedded software should be considered according to how it is supplied and used.

For example:

• standard supplier-controlled firmware may be treated as part of a nonconfigured commercial product;
• configurable equipment-control software may include Category 4 elements;
• custom-developed embedded logic may include Category 5 elements;
• and supporting operating or communication software may include Category 1 components.

The regulated organization may have limited access to firmware design records or source code. Assurance may therefore rely heavily on:

• supplier assessment;
• product history;
• equipment specifications;
• version identification;
• functional and challenge testing;
• alarm and interlock verification;
• calibration;
• maintenance;
• supplier change notification;
• and controlled firmware updates.

Limited design access does not remove the requirement to verify the functions relied upon for the intended GxP use.

Mixed-Category Systems

A mixed-category system should be represented as an architecture of components and responsibilities.

A useful component assessment may identify:

The system validation plan should explain how the component strategies combine into assurance for the complete intended use.

A Category 5 component does not automatically make every component Category 5. However, custom logic should not be hidden beneath a general Category 4 designation for the application.

How Category Influences Supplier Reliance

Category affects what supplier evidence is likely to exist and how extensively it may be used.

Category 1

Supplier reliance may be substantial for standard platform development and testing. Site assurance focuses on approved selection, provisioning, configuration, integration, security, monitoring, and support.

Category 3

Supplier documentation and commercial product history may support the standard functions. Site verification focuses on the actual functions and records relied upon.

Category 4

Supplier evidence may support the core product, but the organization must verify its site-specific configuration, workflows, roles, calculations, reports, master data, and interfaces.

Category 5

Supplier evidence should extend into the development lifecycle, design, code management, code review, unit testing, integration testing, defect management, and maintenance of the custom component.

Supplier reliance should also reflect supplier capability. A Category 3 product from a weak or poorly controlled supplier may require more independent assurance than a Category 4 product supported by strong, transparent supplier evidence.

Supplier assessment and software category should therefore inform each other without being treated as equivalent.

How Category Influences Specifications

Category helps determine which specifications provide useful control.

The table is a guide, not a mandatory document list.

Specification content may be combined when:

• ownership remains clear;
• information is approved;
• requirements remain traceable;
• the configuration or design can be reviewed;
• verification can be derived;
• and the released state can be maintained.

How Category Influences Testing

Category influences test methods and evidence sources, but risk determines verification depth.

Category 1 Testing

Testing may address:

• installation or provisioning;
• approved versions;
• enabled services;
• connectivity;
• authentication;
• time synchronization;
• storage;
• backup;
• restoration;
• monitoring;
• security;
• and recovery.

Category 3 Testing

Testing may address:

• relied-upon standard functions;
• critical calculations;
• input and output behavior;
• security;
• records;
• error handling;
• interfaces;
• and operation in the intended environment.

Category 4 Testing

Testing may address:

• configured workflows;
• business rules;
• status transitions;
• roles and permissions;
• audit trails;
• electronic signatures;
• calculations;
• reports;
• master data;
• interfaces;
• exceptions;
• and representative end-to-end processes.

Category 5 Testing

Testing may include:

• code review;
• unit testing;
• integration testing;
• system testing;
• algorithm verification;
• boundary testing;
• negative testing;
• security testing;
• performance testing;
• and regression testing.

Testing should not be duplicated without purpose. Reliable supplier tests, code-level tests, configuration verification, functional testing, and user-process testing should form complementary layers of evidence.

How Category Influences Code Review

Code review is particularly relevant to Category 5 components and executable custom logic.

The review should consider:

• correctness;
• requirements coverage;
• logic;
• error handling;
• security;
• data handling;
• calculations;
• coding standards;
• maintainability;
• use of approved libraries;
• hard-coded values;
• logging;
• and known vulnerabilities.

Review depth should reflect the component’s complexity and risk. A short calculation script may be reviewed line by line. A large custom application may require architectural review, automated analysis, peer review, security review, and targeted inspection of critical modules.

Code review does not replace functional testing. Correct-looking code can still fail when deployed, configured, integrated, or used with actual data.

How Category Influences Lifecycle Documentation

Software category can help scale documentation, but it should not prescribe an automatic package.

The documentation strategy should consider:

• what the supplier controls;
• what the regulated organization controls;
• what is configured;
• what is custom;
• what evidence exists;
• what evidence is accessible;
• what must be maintained locally;
• and what will be needed for future changes or investigations.

A Category 3 product may require concise documentation but rigorous evidence for one critical function. A Category 4 platform may require extensive configuration and interface records. A small Category 5 script may require controlled source, review, testing, and release records without a large validation-plan structure.

Documentation should be sufficient to:

• explain intended use;
• identify the released version;
• reproduce the configuration;
• understand custom logic;
• trace critical requirements and controls;
• support testing;
• assess changes;
• investigate failures;
• and maintain the system throughout its lifecycle.

Categorization Process

A practical categorization process should:

1. define the intended use and system boundary;
2. identify software and infrastructure components;
3. identify the supplier and responsible owner for each component;
4. determine whether each component is standard, configured, or custom;
5. identify executable custom logic;
6. document mixed or borderline cases;
7. evaluate supplier evidence;
8. connect categories to specifications and verification;
9. integrate component evidence into the overall validation strategy; and
10. maintain the categorization when the architecture changes.

The categorization record should include:

• component name;
• function;
• supplier;
• version;
• category;
• configuration;
• customization;
• interfaces;
• rationale;
• available supplier evidence;
• required lifecycle evidence;
• and reassessment triggers.

Categorization and Change Control

Categorization should be reviewed when changes introduce or remove:

• configuration;
• custom code;
• scripts;
• macros;
• calculations;
• reports;
• plug-ins;
• low-code components;
• interfaces;
• middleware;
• infrastructure;
• or supplier responsibilities.

A standard report may become Category 5 when custom query logic is added. A manual data transfer may become a Category 4 configured interface. A low-code workflow may become custom when scripts or unsupported components are introduced.

The change assessment should determine whether documentation, code review, testing, regression scope, supplier assessment, maintenance responsibilities, or system categorization must be updated.

Common Categorization Errors

Assigning One Category to Every Component

A single system-level category can conceal custom calculations, reports, scripts, or interfaces. Components should be separated when different assurance strategies are needed.

Treating Category as GxP Risk

Category describes software characteristics. It does not describe the consequences of failure.

Assuming Commercial Software Is Automatically Category 3

Commercial applications commonly become Category 4 when workflows, roles, business rules, calculations, or other behavior are configured.

Calling Customization Configuration

Supplier-supported development tools can still create custom executable logic. The classification should reflect the resulting component, not the marketing name of the tool.

Classifying All Reports the Same Way

A standard report and a custom query containing calculations or transformations may require different controls.

Ignoring Scripts and Macros

Small executable components can perform critical calculations, transformations, or transfers and should be controlled accordingly.

Treating Category 1 as Noncritical

Infrastructure can directly affect availability, authentication, timestamps, security, data integrity, and recovery.

Prescribing Validation Packages by Category

Category should inform evidence, specifications, configuration management, testing, and code review. It should not automatically determine a fixed IQ/OQ/PQ package.

Practical Validation Outcome

A useful GAMP categorization should establish:

• what software components exist;
• how each component was developed;
• which components are configured;
• which components contain custom logic;
• what the supplier controls;
• what the regulated organization controls;
• what evidence can be leveraged;
• which specifications are needed;
• where configuration control is required;
• where code review is appropriate;
• what must be verified directly;
• and how each component will be maintained.

The central question is not simply, “What category is the system?” The useful questions are:

• What components support the intended use?
• Which components are standard, configured, or custom?
• What can fail in each component?
• What evidence is available?
• What additional assurance is needed?
• How do the component controls combine to demonstrate that the complete computerized system is fit for intended use?

GAMP 5 software categorization is valuable when it improves those decisions. It becomes counterproductive when the category label replaces system understanding, supplier assessment, quality risk management, or critical thinking.