How to Create a GxP-Compliant Software System
Creating validation documentation for GxP compliance requires systematic evidence that your system performs as intended and is under control. In this How-to Guide you will transform a new or existing software system into a validated GxP-compliant system using Computerized System Validation (CSV) or Computer Software Assurance (CSA) principles.
This guide will help you understand the GxP landscape and provide instructions to build your compliant system with Ketryx AI agents - all while generating necessary evidence such as documentation and traceability tables as a byproduct of your work.
While GxP compliance involves many other aspects, such as building a Quality Management System (QMS) and establishing system specific SOPs and other documentation, these topics fall outside the scope of this guide.
Determining Your Validation Requirements
Understanding Key Terms
Before determining your validation needs, let’s clarify the regulatory landscape:
GxP (Good "x" Practices)
GxP is a general term for a set of quality guidelines and regulations designed to ensure that pharmaceutical and life science products are safe, effective, and of high quality. The "x" can stand for various areas, such as:
GMP = Good Manufacturing Practices (drug/biologic manufacturing)
GCP = Good Clinical Practice (clinical trials)
GLP = Good Laboratory Practice (non-clinical lab studies)
GDP = Good Distribution Practice (supply chain)
GAMP = Good Automated Manufacturing Practice
This guide focuses on GxP validation, which typically follows the GAMP 5 framework for software and computerized systems. If you’re developing medical device software, refer to this guide instead: How to generate the Design History File for your medical device
CSV vs CSA
CSV and CSA are both regulatory-compliant approaches to demonstrating that your software performs as intended. Your choice between CSV and CSA will determine how much documentation you will create, how long validation will take, and how much it may cost. The FDA encourages CSA adoption to improve software quality by focusing effort where it matters most.
CSV (Computerized System Validation)
CSV is the traditional, documentation centered approach that has been the industry standard since the 1990s. It treats all system functions with similar rigor regardless of risk.
Core Philosophy: “Test everything, document everything”
Key Characteristics:
Exhaustive documentation of every requirement, design decision, test case, and result
Step-by-step test scripts with predetermined expected results for all functions
Any changes require an impact assessment, revalidation, and full documentation
CSA (Computer Software Assurance)
CSA represents the shift to allow teams to develop and test software using a risk-based approach. Introduced through draft guidance in 2022, CSA enables teams to focus on safety-critical elements of their software rather than complete system validation.
Core Philosophy: “Think critically, test what matters, document what is valuable”
Key Characteristics:
High-risk features get rigorous testing; low-risk features get basic verification
Exploratory testing acceptable for non-critical functions
Accept vendor’s testing for core functionality (detailed in GAMP-5 Section 7)
Emphasis on ongoing monitoring as opposed to point-in-time validation
Emphasizing GxP’s Core Principle
The core principle of GxP is to ensure that products are consistently produced and controlled according to high-quality standards. The ultimate goal of GxP is to protect the public by guaranteeing the safety, quality, and efficacy of regulated products, particularly in the pharmaceutical, medical device, and food industries. Validation is a core GxP Quality Process. The V-model is a project management and software / systems engineering framework that is commonly used in GxP settings, particularly in the context of GxP-regulated software.
Highlighted above are the out-of-the-box V-model configurations available in Ketryx. These templates can be further configured to match your specific workflows.
Build a GxP System
(Video guides included)
Step 0: Key Terminology
To start, we need to explain what the system will do and how users will use it. This is called the Intended Use and is typically about a paragraph (see example below). Depending on the system's nature, the intended use can be quite complex.
Intended Use Statement Example: This Electronic Document Management System (EDMS) is intended to securely store, control, and manage GxP-critical documents, including but not limited to, Standard Operating Procedures (SOPs), batch records, and quality agreements, throughout their lifecycle. It ensures data integrity, traceability, and accessibility for regulatory compliance and supports decision-making related to product quality and patient safety.
Once we have a good Intended Use statement, and perhaps a few slides or documents that explain the product, you need to write a set of requirements that explain what users need the system to do, and how it will accomplish those functions. Collectively, these requirements are called design inputs, as they are inputs to the system design. This is where AI agents can radically accelerate your work - and we will get to that after we discuss risks.
Types of Requirements:
Systems typically include the following requirement categories:
User Requirements Specification (URS): What the end-users need the system to do.
Functional Specifications (FS): Detailed descriptions of how the system will meet the URS.
Non-functional Requirements: Performance, security, scalability, usability, and data integrity requirements.
Regulatory Requirements: Specific GxP regulations applicable to the software's intended use.
Risk Management
Risk management is crucial in GxP environments, ensuring product quality, patient safety, and data integrity by identifying, assessing, mitigating, and monitoring risks throughout a product's lifecycle. While more has been written about risk management than can be covered in this short guide, we recommend exploring standards like GAMP-5, ISO 14971, and other recognized bodies of work for deeper understanding.
GxP Risk Management Basics
For GxP compliance, risk management is a regulatory expectation. Key principles include:
Proactive, Science-Based Approach: Identify risks early using scientific evidence.
Thorough Documentation: Document all risk activities.
Lifecycle Management: Continuously review and re-evaluate risks.
Patient Safety & Product Quality Focus: Primary objective is to protect patients and ensure quality.
Proportionality: Effort should match risk level.
Common methodologies include FMEA, HACCP, PHA, and Risk Matrices. For further reading on Risk Management in Ketryx please review Manual-08: Risk Management
Step 1: Building Your Initial Requirements and Risks
To develop your requirements, risks, and design inputs, we will use Ketryx's Design Input Agent. This agent will take in your intended use statement and any other supporting materials (slides, marketing docs, product briefs) and transforms them into a comprehensive set of traced requirements, risks, and tests.
Creating Your Project and Running the Design Input Agent
🎥 Watch Video 1: Setting Up Your Project and Running the Design Input Agent Start by creating a new project in Ketryx and selecting the appropriate V-model template for your product. Once your project is set up, navigate to the Agents tab and select the Design Input Creation Agent. Attach your project brief or intended us documentation, then run the agent
Review Agent Output
🎥 Watch Video 2: Understanding the Design Input Agent Output
After the agent completes its run, review the generated configuration items in the Summary tab. You’ll see that the agent created a number of requirements, risks, designs, and tests, all with established traceability. Explore the logic the agent used and review the items in the All Items screen.
The local traceability view shows how individual items relate to each other while the global traceability view provides a full picture of all items and their relationships.
You’ll notice the traceability checks at the top of the screen that indicate completion status. For example, you might see that certain design inputs lack validation tests. These gaps are normal at this stage. We will address them in the following steps.
Refining Requirements with AI Assistance
🎥 Watch Video 3: Running Quality Checks on Items
Before completing your traceability matrix, use the Ketryx AI Assistant to run quality checks on your design inputs. This ensures they’re written clearly, meet GAMP 5 standards, and are testable.
Example prompt: "Please run a quality check on all of my design inputs, ensuring they meet GAMP 5 standards. For each requirement, make sure it is written clearly and testable, and that it aligns with the use case."
Ensuring Complete Traceability
Navigate to the traceability module to ensure full traceability. Check the traceability metrics and for any checks under 100%, as the assistant, for example “Advise me on steps to take to ensure all of my Use Cases are being covered by Design Inputs.”
Step 2: Design and Architecture
Category 3 or 4: Skip to the next section (Testing and Verification). Your configuration specifications from the requirements phase are sufficient.
Category 5: continue below. You must document how your custom code implements the requirements.
Documenting Software Design
For Category 5 systems, your software design should be well documented and address:
Data Integrity: Mechanisms to ensure data accuracy, completeness, consistency, and traceability (e.g., audit trails, electronic signatures).
Security: Measures to protect data from unauthorized access, modification, or disclosure.
Audit Trails: Comprehensive, unalterable logs of all significant actions, including who performed them, when, and what data was affected.
Error Handling: Robust error detection and recovery mechanisms.
Scalability and Performance: Ensuring the system can handle anticipated workloads.
Maintainability: Designing for ease of future updates and bug fixes.
Generating Design Outputs
Utilize the assistant to generate new Design Outputs (Software Specifications) and trace these items to the relevant Design Inputs until all of your Design Inputs are Covered by Design Outputs. This traceability check should be 100%.
Example assistant prompts:
“Find all Design Inputs that are not being Implemented by a Design Output and generate a new Software Specification that is traced to it”
“Analyze all of my Software Specifications and ensure they are written according to CSA GAMP-5 principles”
“Add traceability from [specific Design Input) to [specific Design Output]”
Step 3: Testing and Verification
Testing is a critical component of GxP software development. Testing allows us to ensure that the claims (i.e. use cases, RQs, risks) we make about the system are indeed correct, in each product version.
Core Testing Components
Traceability Matrix: Links requirements to test cases to demonstrate that all requirements are tested.
Test Plans and Protocols: Document the scope, approach, resources, and schedule of testing activities.
Test Cases: Detailed steps for executing tests, expected results, and acceptance criteria.
Types of Testing:
Unit Testing: Verifying individual components.
Integration Testing: Testing interactions between modules.
System Testing: Testing the complete system against functional and non-functional requirements.
User Acceptance Testing (UAT): Verifying that the system meets user needs and is fit for purpose.
Performance Testing: Assessing system responsiveness and stability under load.
Security Testing: Identifying vulnerabilities.
Regression Testing: Ensuring that new changes do not negatively impact existing functionality.
Defect Management: A systematic process for logging, tracking, prioritizing, and resolving defects.
Test Reports: Documenting test execution, results, and any deviations.
Generating Test Cases
🎥 Watch Video 4: Generating Validation Tests
Use the assistant to generate and trace Validation tests to your Design Inputs. These traceability checks should reach 100%.
Review the suggested test cases carefully. The assistant will generate test steps and expected behaviors that are already traced to the relevant requirements. Accept the test cases that meet your quality standards.
Executing Tests
🎥 Watch Video 5: Performing Test Executions
You need to perform test executions before releasing version 1.0 of your product. Navigate to the Test module where you can generate all test executions in bulk. Ketryx can also connect directly to your repository to report automated test executions from your CI/CD pipeline.
After completing your test executions and verifying that your requirements are validated, select your Requirements, Test Cases, and Test Executions from the All Items screen and bulk-approve all of these items.
Step 4: Risk Analysis and Control
🎥 Watch Video 6: Performing Risk Analysis
Before releasing your product, you must address all identified risks. Navigate to the Risks that need attention; these will typically be flagged in your traceability matrix.
After completing risk analysis on all risks, verify in the traceability screen that all Risks are in a controlled and approved state, all Risk Controls are controlled, and Risk coverage is complete across your Use Cases and Design Inputs. Use the Assistant to aide with these checks.
Step 5: Document Generation and Baseline Release
🎥 Watch Video 7: Release Your GxP Product
Pre-Release Checklist
Navigate to the Release screen to review your deterministic release checklist. You should see that all items are complete except for document generation.
Document Generation
Navigate to the Documents screen and generate or omit the documents using Ketryx's out-of-the-box templates.
Final Release
You can perform a GxP-compliant baseline release of your product from the Release screen.
Conclusion
In this guide, we've covered the fundamentals of designing and validating a software system to meet GxP requirements using Ketryx AI. You've learned how to:
Define intended use and create comprehensive requirements
Manage risks throughout the product lifecycle
Establish complete traceability
Generate and execute validation tests
Perform risk analysis
Generate required documentation
Release a baseline validated GxP product
This structured approach, powered by Ketryx's AI agents and assistants, dramatically accelerates the validation process while maintaining the rigor required for regulatory compliance.
Need Help?
If you encounter challenges or have questions about specific regulatory requirements:
Reference Ketryx Documentation
Consult your quality management team
Review the applicable standards and guidance documents
Contact Ketryx support for platform-specific questions
APPENDIX
Do I need GxP Validation?
This is a complex question that is very specific to a system and its use. We recommend connecting with a subject matter expert. In general, GxP validation is required if your software system is used in regulated activities.
The First Question: Are you subject to FDA and other regulations?
Are you a company that’s involved in the manufacture, processing, packing, or holding of FDA-regulated products and therefore must comply with the relevant sections of 21 CFR and analogous regulations in the EU and other jurisdictions?
If YES, you are likely subject to GxP regulations, proceed to the next question.
If NO, you are likely not subject to GxP regulation, as mentioned, we recommend connecting with a subject matter expert. It may also be recommended per Good Practice guidelines, such as GAMP-5, that you follow a QMS, preferably based on recognized standards.
The Second Question: Could a failure or error in this system lead to:
Incorrect drug reaching patients?
Invalid clinical trial results?
Inability to prove product quality?
If YES to any → GxP validation is required
Systems Commonly Considered for GxP Validation:
Manufacturing Systems
Systems that control manufacturing processes
Applications managing batch records or calculations
Relevant regulations may include 21 CFR Part 211 - “Appropriate controls … over computers”
Quality Management Systems
Electronic records and signature systems
Complain, CAPA, and change control systems
Training and document management platforms
Relevant regulations may include 21 CFR Part 11 Electronic records replacing paper
Laboratory Systems
Laboratory information management systems
Stability and environmental monitoring applications
Relevant regulations may include 21 CFR Part 211 Laboratory Records
Clinical Systems
Clinical data management platforms
Electronic trial master file systems
Relevant regulations may include ICH GCP Good Clinical Practice
Note: Regulations listed are illustrative, common examples. Specific requirements vary by product type, market, and classification—consult your regulatory team for complete applicability.
Examples of systems that may not require GxP validation (Always document your risk assessment and rationale):
General business operations (accounting, HR)
Marketing and communication tools
Standard office productivity software
Systems with no impact on product regulatory data
This guidance represents illustrative industry interpretation. Organizations must conduct their own assessment.
Determine Your GAMP-5 Category
The pharmaceutical industry widely adopts GAMP-5 (Good Automated Manufacturing Practice) as a risk-based validation framework. While we provide a high-level overview below, organizations should consult the official ISPE GAMP-5 Guide for complete definitions and approaches. is a pharmaceutical industry’s framework for risk-based validation. Once you’ve determined GxP validation is needed, GAMP-5 provides a framework for best practices. Your system’s GAMP-5 category drives downstream decisions. Determine this as soon as possible:
Software Category Overview:
One general rule of thumb is if your software is:
Infrastructure → Category 1
Not configurable → Category 3
Configurable but has no custom code → Category 4
Includes any custom code → Category 5
Makes automated GxP decisions → Treat as Category 5 regardless
Practical Application of Software Categories:
The following represents illustrative industry interpretation of risk-based validation principles. For authoritative category definitions and requirements, consult the official GAMP-5 guidance.
Category 1: Infrastructure Software
Examples: Operating systems, databases, middleware
Documentation: Minimal - leverage vendor docs
Testing: Qualify, don’t validate
Category 3: Non-configured Products
Off-the-shelf software, used as is
Examples: PDF readers, simple calculators
Documentation: Configuration specifications only
Testing: Focus on installation and basic functionality
Category 4: Configured Products
Configurable software, no custom code
Examples: LIMS, ERP, Microsoft toolsuite
Documentation: Configuration design document
Testing: Configuration-specific validation
Category 5: Custom Application
Custom-developed or heavily customized
Examples: In-house MES, custom data systems
Documentation: Full architecture and design specs
Testing: Complete lifecycle validation
Last updated
Was this helpful?