In modern corporate activities, software has become an indispensable element. However, treating all software uniformly is not appropriate from the perspectives of quality management and risk management. This is where software category classification becomes essential.
This classification method is recommended by GAMP 5 (Good Automated Manufacturing Practice), an international guideline, and is a practical approach adopted by companies worldwide. It is particularly important to note that GAMP 5 Second Edition, published in July 2022, reflects significant technological advancements and regulatory developments that have occurred since the First Edition in 2008. The updated guidance emphasizes critical thinking by knowledgeable subject matter experts (SMEs), increased reliance on service providers including cloud computing, and integration with modern software development methodologies such as Agile.
Furthermore, in September 2022, the U.S. Food and Drug Administration (FDA) released draft guidance on Computer Software Assurance (CSA) for Production and Quality System Software, which was finalized in 2024. This guidance represents a paradigm shift from traditional Computer System Validation (CSV) to a more risk-based, efficient approach that aligns with GAMP 5 principles. CSA emphasizes focusing validation efforts on areas with the highest risk to patient safety, product quality, and data integrity, rather than generating extensive documentation for its own sake.
Software Categories: Four Classifications
Software is primarily classified into the following four categories based on its characteristics and usage. Each category has distinct features, and management approaches differ significantly. It is important to understand that GAMP 5 Second Edition emphasizes viewing these categories as a continuum rather than rigid boundaries, as computerized systems are generally composed of a combination of components from different categories.
Category 1: Infrastructure Software
This category includes software, systems, and tools that support computerized system lifecycle activities, IT processes, and infrastructure processes, as opposed to directly supporting business, pharmaceutical, or medical device lifecycle processes. This represents a significant update from GAMP 5 First Edition and aligns with FDA’s CSA approach, recognizing that infrastructure components typically have minimal or no direct impact on GxP-critical processes.
Specific Examples:
Operating systems (Windows, Linux, macOS) Database management systems used as platforms (Oracle, MySQL, PostgreSQL) Virtualization platforms (VMware, Hyper-V) Network infrastructure software Firewalls and antivirus software Software development and testing tools used in system lifecycle activities Backup and archiving systems Email systems (when used for general communication, not GxP-critical recordkeeping)
These software components form the foundation upon which other applications run. Since manufacturers or vendors have already conducted thorough testing and validation, verification work at implementation can be minimal. The focus should be on installation verification and assessing tool adequacy for use, rather than extensive functional testing.
Note Regarding Category 2: In GAMP 4, Category 2 referred to firmware. However, GAMP 5 removed this category because modern firmware has evolved significantly in complexity. Depending on its function, configurability, and complexity, firmware is now classified as Category 1 (infrastructure), Category 3 (non-configurable), Category 4 (configurable), or Category 5 (custom), allowing for a more accurate, risk-based validation approach.
Category 3: Non-Configurable Software (Standard, Off-the-Shelf Software)
Software in this category is ready to use immediately after installation without requiring configuration changes or adjustments by users. Commercial package software that cannot be modified falls into this category.
Specific Examples:
Standard office software (Microsoft Office when used without macros) Calculator applications PDF readers Image viewer software Static report viewers Data acquisition software without configuration capability Simple spreadsheet applications used only for basic calculations and data entry Standard firmware for simple instruments
These software products have undergone sufficient testing by manufacturers, so verification work at implementation can be minimal. The focus is on confirming that the software installs correctly, operates as expected for its intended use, and is fit for purpose. However, it is critical to assess the intended use of the software to determine the appropriate level of assurance activities.
Category 4: Configurable Software (Configurable Commercial Software)
Configurable software requires various parameter settings and initial configuration before use. Users need to configure the operating environment, enable or disable functions, and set parameters according to their requirements.
Specific Examples:
Database management systems requiring configuration (Oracle, SQL Server, MySQL when configured for specific applications) Accounting software (requiring chart of accounts configuration) Manufacturing Execution Systems (MES) (requiring process and parts master configuration) Environmental monitoring systems (requiring alarm thresholds, user access levels, and reporting configurations) Security software (requiring scan level settings) Enterprise Resource Planning (ERP) systems configured for specific business processes Laboratory Information Management Systems (LIMS) configured for laboratory workflows Serialized ERP systems like those managing unique supply chain workflows
Since software behavior changes depending on configuration settings, more careful verification is required than for Category 3. Configuration settings must be documented with their rationale, and testing should focus on verifying that configured features function as intended. The configuration itself becomes part of what needs to be validated.
Category 5: Custom Software (Custom Developed Software)
This is the most complex category, requiring significant modifications or new development tailored to users’ specific needs. This includes cases where new functions are added to existing software, interfaces are modified, or completely new applications are developed from scratch.
Specific Examples:
Order management systems developed to match a company’s unique business processes Special functions added to existing ERP systems Business processes automated using macros or scripts Custom programs that integrate with other systems using APIs Bespoke applications built entirely from scratch for specific business requirements Complex spreadsheets with custom formulas, macros, and multi-sheet links used for GxP-critical processes Custom middleware for system-to-system integration AI/ML models developed or significantly customized for production or quality system use
This category carries the highest risk and requires detailed management throughout the entire development process. Full lifecycle validation is essential, including requirements definition, design reviews, source code reviews (where appropriate and feasible), comprehensive testing at multiple levels (unit, integration, system, user acceptance), performance testing, and security testing.
Comparison Table of Software Categories
| Category | Type | Configuration Required | Development Required | Typical Validation Effort | Risk Level | Examples |
|---|---|---|---|---|---|---|
| Category 1 | Infrastructure | Minimal | None | Installation verification, adequacy assessment | Lowest | Operating systems, databases (as platforms), development tools, network infrastructure |
| Category 3 | Non-configurable | None | None | Installation qualification, operational qualification focused on intended use | Low | Office software, PDF readers, simple calculators, static viewers |
| Category 4 | Configurable | Extensive | None | IQ, OQ with focus on configured features, configuration documentation | Medium | Configured ERP, LIMS, MES, environmental monitoring systems with alarm settings |
| Category 5 | Custom | Required | Extensive | Full lifecycle validation: requirements, design, code review, comprehensive testing | Highest | Custom applications, heavily modified systems, complex macros, bespoke integrations |
The Necessity of Category Classification
Why is such classification necessary? This is because managing all software according to the same standard leads to inefficiency and excessive costs, while also failing to adequately address risks where they are most significant.
1. Differences in Depth of Validation (Computer Software Assurance)
The depth of validation or assurance required for quality assurance differs significantly by category. It is important to note that modern approaches emphasize Computer Software Assurance (CSA) rather than traditional Computer System Validation (CSV). CSA represents a risk-based approach that focuses on establishing confidence that software performs as intended, rather than generating extensive documentation for compliance purposes alone.
For Category 1:
Installation verification (confirming proper startup and operation) Assessment of tool adequacy for intended use Documented records of infrastructure qualification Virus scanning implementation Focus on “one qualification, many implementations” model for infrastructure
For Category 4:
Validation of configuration settings (why those values were set) Post-configuration operational verification (confirming expected operation) Verification of impact on other systems Procedure verification for configuration changes Documentation of configuration rationale and traceability Risk assessment of configured features and functions Testing focused on critical, configured capabilities
For Category 5:
Validation of requirements definition Design reviews implementation Source code review (where appropriate and feasible based on risk) Unit testing, integration testing, system testing User acceptance testing Performance testing, security testing Comprehensive documentation throughout the software development lifecycle (SDLC) Risk-based approach to determine appropriate level of testing for each feature or function
The CSA approach emphasizes that validation effort should be scaled based on the intended use of the software and the process risk it poses, rather than following a prescriptive, one-size-fits-all documentation approach. High process risk features require scripted testing with documented test cases, while features that are not high process risk may be addressed through unscripted testing methods such as scenario testing, exploratory testing, or error-guessing.
2. Differences in Required Documentation
Documentation requirements also differ significantly by category. This is critical for root cause analysis when problems occur and for fulfilling accountability to regulatory authorities. The CSA approach encourages focused, value-added documentation rather than excessive screenshots and redundant paperwork.
Category 1:
Infrastructure qualification documentation Installation records Tool adequacy assessment Basic operational verification records Vendor assessment documentation
Category 4:
Configuration specification documents (what configurations were made) Configuration rationale documents (why those settings were chosen) Standard operating procedures (SOPs) for daily operations Change management records (history of configuration changes) Risk assessment documentation for configured features Testing records focused on configured functionality Vendor assessment and supplier involvement documentation
Category 5:
Requirements specification documents (what to build) Basic design documents and detailed design documents (how to build) Test specifications and result reports at multiple levels Source code management records (where applicable) Change management records (history of program changes) Training records Risk assessment and mitigation documentation throughout the lifecycle Development methodology documentation (Agile sprints, iterative development records) Continuous monitoring and post-release surveillance data
The emphasis should be on creating documentation that adds value to quality assurance rather than generating extensive documentation for its own sake. Digital records, audit trails, system logs, and automated testing results should be leveraged to reduce manual documentation burden.
3. Cost and Resource Optimization
Appropriate category classification enables the following optimizations:
Prevention of Over-Management: Eliminating wasteful costs from applying Category 5-level management to Category 3 software
Risk-Based Management: Concentrating resources intensively on high-risk areas while applying appropriate, proportionate controls to lower-risk areas
Efficient Quality Assurance: Achieving both quality and speed through necessary and sufficient verification, avoiding both under-testing and over-documentation
Leveraging Supplier Involvement: Modern approaches emphasize maximizing supplier involvement to leverage their knowledge, experience, and documentation, reducing duplication of effort
Critical Thinking Application: Utilizing experienced SMEs to apply critical thinking in determining appropriate validation strategies rather than following rigid, prescriptive checklists
Agile Compatibility: Supporting modern Agile and iterative development methodologies while maintaining compliance, enabling faster time-to-market with appropriate quality controls
Addressing Complexity in IT Applications
The Reality of Mixed Categories
Modern IT applications often do not fit into a single category. For example, let us examine an ERP system in detail.
ERP System Configuration Example:
1. Basic Functional Modules (Category 3):
Standard accounting functions Standard inventory management functions Standard report functions (when used as-is without configuration)
2. Configuration-Based Functions (Category 4):
Organizational structure settings Approval workflow configurations Chart of accounts system settings User access control settings Alarm threshold configurations
3. Customized Functions (Category 5):
Unique performance evaluation reports Automated integration functions with other systems Industry-specific special processing logic Custom workflows and business rules AI/ML algorithms for predictive analytics
4. Infrastructure Components (Category 1):
Underlying database platform Operating system Network infrastructure Backup and recovery systems Development and testing tools used in system maintenance
Importance of Function-by-Function Classification
For such complex systems, it is crucial to classify by functional unit rather than classifying the entire system into one category. This “functional approach” or “component-based approach” provides the following benefits:
Merit 1: Application of Appropriate Management Levels
Standard functions can be addressed with simplified verification Customized parts receive sufficient verification effort Configuration parts focus on validation of configuration settings and their rationale Infrastructure components focus on installation verification and adequacy assessment
Merit 2: Clarification of Scope of Impact During Changes
Clear understanding of which functions belong to which categories Clear scope of necessary work during changes Easy assessment of impact on other functions Focused change control on affected components
Merit 3: Efficient Resource Allocation
Assignment of specialists to high-risk functions Standard procedures for low-risk functions Overall project efficiency improvement Optimal balance of effort across components
GAMP 5 Second Edition explicitly emphasizes that computerized systems are generally composed of a combination of components from different categories, and that categories should be viewed as a continuum rather than rigid classifications. The validation strategy must consider the combined risk of all components, with particular attention to the highest-risk elements that drive overall system criticality.
Relationship with Risk-Based Approach
Software category classification is positioned as part of a “risk-based approach” philosophy. This is a rational way of thinking that varies the strictness of management according to the level of risk. Both GAMP 5 Second Edition and FDA’s CSA guidance strongly emphasize this principle.
Risk Assessment Perspectives
Impact on Business and Patients:
Does it directly affect sales or revenue? Does it handle customer or patient data? Is it related to legal and regulatory compliance? What is the potential impact on product quality? What is the potential impact on patient safety? What is the risk to data integrity?
Technical Complexity:
Extent of integration with other systems Complexity of data processing Degree of customization Novelty of technology being implemented Use of emerging technologies (AI/ML, blockchain, cloud computing)
Process Risk Assessment:
Rather than assessing risk based solely on software category, the CSA approach emphasizes assessing the risk of the business process that the software supports Focus on the consequences if the software does not perform as intended for its specific use Consider the intended use of each feature, function, or operation separately
Practical Application Examples
High-Risk Function Examples:
Functions processing financial transactions → Strict management as Category 5, with comprehensive validation Functions handling personal information → Detailed security testing implementation, data integrity verification Functions controlling manufacturing lines → Comprehensive operational verification, extensive testing AI/ML models used for critical decision-making → Risk-based validation focusing on training data quality, model performance monitoring, and bias detection
Low-Risk Function Examples:
Simple aggregation tools for internal use → Basic verification as Category 3 Reference-only report functions → Minimal operational verification Backup data export functions → Standard verification procedures General communication tools → Installation verification and adequacy assessment as Category 1
Risk-Based Documentation:
For high process risk features: Scripted testing with documented test protocols and results For not high process risk features: Unscripted testing methods with documented testing approach and findings Leveraging digital records, audit trails, and system logs to reduce manual documentation Focus on documentation that adds value to quality assurance
Practical Classification Points
1. Importance of Initial Assessment
In the initial stage of software implementation, it is critical to clearly identify which category each function belongs to and to assess the overall risk profile of the system.
Initial Assessment Checkpoints:
☐ Which parts are provided as standard functions? ☐ Which parts require configuration? ☐ Which parts require customization? ☐ What is the degree of business importance of each part? ☐ What is the intended use of each feature, function, or operation? ☐ What process risks are associated with each component? ☐ What is the appropriate balance between scripted and unscripted testing? ☐ How can we leverage supplier documentation and testing? ☐ What level of critical thinking and SME involvement is needed?
This assessment clarifies the project’s scale, required resources, and schedule. It also forms the foundation for developing a risk-based validation strategy that is both efficient and compliant.
2. Coordination with Change Management
Even after operation begins, categories may change with system modifications and updates. The CSA approach emphasizes that software assurance is not a one-time activity but an ongoing process that includes continuous monitoring and post-release surveillance.
Examples of Category Changes:
Adding macros to standard functions (Category 3) → That part becomes Category 5 Customizing configuration-only functions (Category 4) → Becomes Category 5 Standardization of custom functions (Category 5) → May become Category 3 if adopted as vendor standard Infrastructure upgrades (Category 1) → Require re-assessment of adequacy for intended use
Change Management Best Practices:
Implement risk-based change control that distinguishes between minor changes with low risk and major changes with high risk For minor changes, consider streamlined procedures with reduced QA involvement based on documented risk assessment Maintain clear traceability between changes and their risk assessments Leverage automated change tracking tools where appropriate Document the rationale for risk-based decisions in change management
3. Documentation Best Practices
Effective Documentation Tips:
Create and maintain a category classification table that is regularly updated Always review categories when changes occur Maintain a function list and its corresponding category mapping Conduct periodic reviews to verify category appropriateness Integrate with risk assessment documentation to justify validation approaches Leverage digital recordkeeping systems to reduce manual documentation burden Focus on value-added documentation rather than excessive screenshots and redundant paperwork Ensure documentation supports critical thinking and justified decision-making
Master Validation Plan Integration:
The Master Validation Plan (MVP) should reference the software categorization and risk assessment Document the overall validation strategy, including how categories influence validation approaches Clearly define roles and responsibilities across categories Establish criteria for determining high process risk vs. not high process risk Document the approach to leveraging supplier information and testing Define the balance between scripted and unscripted testing based on risk
Integration with Modern Regulatory Landscape
GAMP 5 Second Edition Updates
The Second Edition of GAMP 5, released in July 2022, introduces several key updates that reflect the modern technology landscape:
Emphasis on Critical Thinking: Rather than following prescriptive checklists, experienced SMEs should apply critical thinking to determine appropriate validation strategies based on documented risk assessments
Agile Development Support: Recognition that modern software development is largely non-linear, with explicit support for Agile, iterative, and DevOps methodologies
Service Provider Focus: Increased emphasis on leveraging supplier knowledge, documentation, and testing, particularly relevant for cloud-based solutions and Software-as-a-Service (SaaS)
Emerging Technologies: New appendices addressing AI/ML, blockchain/distributed ledger technology, cloud computing, and open-source software
Categories as a Continuum: Explicit guidance that categories should be viewed as a continuum rather than rigid classifications, with systems typically composed of components from multiple categories
Infrastructure Modernization: Updated guidance on IT infrastructure that aligns with the concept of “one qualification, many implementations”
Reduced Documentation Burden: Emphasis on avoiding over-documentation such as excessive screenshots, focusing instead on value-added documentation and leveraging digital records
FDA Computer Software Assurance (CSA)
The FDA’s draft guidance on Computer Software Assurance for Production and Quality System Software, released in September 2022 and finalized in 2024, represents a significant shift in regulatory thinking:
Risk-Based Process Focus: Rather than software-centric risk assessments, CSA emphasizes process risk with focus on patient safety, product quality, and data integrity
Four-Step CSA Approach:
- Identify the intended use of the software
- Determine a risk-based approach depending on possible outcomes if software does not perform as intended
- Determine appropriate assurance activities based on that risk
- Establish an appropriate record with sufficient evidence to demonstrate software assessment and performance
High Process Risk vs. Not High Process Risk: Clear distinction between features requiring rigorous scripted testing and those appropriate for unscripted testing methods
Leveraging Supplier Information: Strong encouragement to maximize use of supplier documentation, testing, certifications (such as ISO 13485), and quality management system information
Least Burdensome Approach: Focus on establishing confidence through appropriate means rather than generating extensive documentation for compliance sake alone
Digital Records Emphasis: Encouragement to leverage system logs, audit trails, and digital records rather than manual documentation and screenshots
Applicability: Applies to software used as part of medical device production or quality systems, but principles are equally applicable across pharmaceutical and biotech industries
Alignment Between GAMP 5 and FDA CSA
Both GAMP 5 Second Edition and FDA CSA guidance share common principles:
Risk-Based Approach: Both emphasize focusing effort where risk is highest to patient safety, product quality, and data integrity
Critical Thinking: Both require knowledgeable SMEs to apply judgment rather than following rigid checklists
Supplier Leverage: Both encourage maximizing use of supplier information, testing, and documentation
Efficiency Focus: Both aim to reduce unnecessary documentation and testing while maintaining appropriate quality controls
Modern Technology Support: Both address contemporary technologies including cloud computing, AI/ML, and Agile development
Process-Centric Risk Assessment: Both emphasize assessing risk based on business process and intended use rather than software classification alone
Summary
Software category classification is not merely a formal exercise. This method, recommended by international guidelines such as GAMP 5, provides the following practical value:
Efficiency of Quality Assurance Activities: Implementation of necessary and sufficient validation or assurance based on risk
Cost Reduction: Elimination of excessive management and over-documentation
Risk Management Optimization: Appropriate response according to risk, focusing effort where it matters most
Clarification of Regulatory Compliance: Fulfillment of accountability during audits and inspections
Alignment with Modern Practices: Support for contemporary software development methodologies including Agile, cloud computing, and emerging technologies
Critical Thinking Integration: Empowerment of experienced SMEs to make justified, risk-based decisions
Patient Safety Focus: Primary emphasis on protecting patient safety and ensuring product quality rather than generating documentation for compliance sake alone
Particularly for complex IT applications, detailed classification by functional unit is directly linked to project success. When organizations implement and operate software, it is essential to understand this category classification concept and establish an appropriate management system tailored to their specific circumstances.
Key Takeaways for Implementation
Adopt a Risk-Based Mindset: Shift from prescriptive, checklist-driven approaches to risk-based strategies that focus validation effort on high-risk areas
Leverage Supplier Involvement: Maximize use of supplier documentation, testing, and certifications to avoid duplicating effort
Apply Critical Thinking: Utilize experienced SMEs to make justified decisions about validation strategies rather than following rigid procedures
View Categories as a Continuum: Recognize that systems typically contain components from multiple categories and should be validated accordingly
Focus on Intended Use: Assess each feature, function, or operation based on its specific intended use and associated process risk
Balance Testing Approaches: Use scripted testing for high process risk features and unscripted testing for not high process risk features
Embrace Modern Documentation: Leverage digital records, audit trails, and system logs rather than generating excessive manual documentation
Support Agile Development: Integrate validation activities throughout iterative development cycles rather than concentrating them at the end
Continuous Assurance: Recognize that software assurance is an ongoing process, not a one-time validation event
Regulatory Alignment: Ensure practices align with both GAMP 5 Second Edition principles and FDA CSA guidance for optimal compliance and efficiency
By adopting these principles, organizations can avoid cost increases from excessive management while ensuring necessary quality and compliance. Category classification, integrated with risk-based Computer Software Assurance principles, is an essential concept in modern software quality management. This approach enables organizations to confidently adopt modern technologies while maintaining the highest standards of patient safety, product quality, and data integrity in an efficient, practical manner.
Comment