GxP Software Development: FDA 21 CFR Part 11 Guide

Most software teams discover GxP requirements after they've built the product. A pharma company signs off on the scope, the development team builds it like any other SaaS application, and then someone from the quality assurance department asks: "Where's the validation documentation? Where are the audit trails? How do electronic signatures meet 21 CFR Part 11?"

The project stalls. The development team retrofits audit trails, adds electronic signature workflows, and produces hundreds of pages of validation documentation after the fact. What was a 12-week project becomes a 6-month project. The budget doubles.

This guide is written to prevent that outcome. If you're building software for a pharmaceutical company - or any life sciences organization subject to GxP regulations - here's what you need to know before writing a single line of code.

What GxP Actually Means for Software

GxP is an umbrella term for regulatory requirements governing pharmaceutical and life sciences operations. The "G" stands for Good, the "P" stands for Practice, and the "x" is the variable:

• GMP - Good Manufacturing Practice (manufacturing and production)
• GLP - Good Laboratory Practice (non-clinical laboratory studies)
• GCP - Good Clinical Practice (clinical trials)
• GDP - Good Distribution Practice (distribution and supply chain)

When software touches any of these areas - manufacturing execution systems, lab information management, clinical trial databases, supply chain tracking - it becomes subject to GxP requirements. The specific requirements depend on which practice area the software serves, but the engineering fundamentals are the same across all of them.

FDA 21 CFR Part 11: The Three Pillars

Title 21, Code of Federal Regulations, Part 11 is the FDA's regulation governing electronic records and electronic signatures. Published in 1997 and enforced since, it's the baseline compliance standard for any software system used in pharma operations in the US or by companies that export to the US.

Part 11 has three pillars that every developer needs to understand.

Pillar 1: Audit Trails

Every electronic record must have a computer-generated, timestamped audit trail that records:

• Who made the change (user identity)
• What was changed (previous value and new value)
• When the change was made (timestamp)
• Why the change was made (reason for change)

The "why" is what catches most development teams off guard. Standard database audit logging captures who, what, and when. Part 11 requires a "reason for change" - a mandatory field that the user must fill in before the system accepts the modification.

Engineering implementation: Build the audit trail as an append-only event log, not a modified-timestamp column on the record. Every state change creates a new event with the full context. The audit trail must be tamper-evident - meaning it should be computationally infeasible to modify or delete audit entries without detection.

// Simplified audit event structure
{
  eventId: "uuid",
  recordType: "training_certification",
  recordId: "cert-4521",
  action: "status_change",
  previousValue: { status: "pending", score: null },
  newValue: { status: "passed", score: 92 },
  reasonForChange: "Assessment completed successfully",
  userId: "user-1847",
  userRole: "medical_representative",
  timestamp: "2026-03-22T14:32:18.445Z",
  ipAddress: "203.45.67.89",
  sessionId: "sess-a8f3c"
}

Pillar 2: Electronic Signatures

Electronic signatures must be:

• Linked to their respective records - a signature can't be copied from one record and applied to another
• Composed of at least two distinct identification components (e.g., username + password, or biometric + PIN)
• Non-repudiable - the signer can't plausibly deny having signed

Each electronic signature must include the printed name of the signer, the date and time of signing, and the meaning of the signature (e.g., "reviewed and approved," "authored," "verified").

Engineering implementation: Electronic signatures are not the same as authentication. A user logging in with their credentials is authentication. An electronic signature is a deliberate act where the user re-enters their credentials (or provides biometric authentication) specifically to sign a record. The signature event gets logged with the record context, signature meaning, and full audit trail.

Pillar 3: System Controls

Part 11 requires operational system controls including:

• Access controls - only authorized individuals can use the system, and permissions match their job functions
• Authority checks - the system verifies that users are authorized to perform specific operations (input, modify, approve, delete)
• Device checks - the system determines the validity and identity of the source device
• Session controls - automatic session timeouts after inactivity

Engineering implementation: This is standard RBAC (Role-Based Access Control) with pharma-specific role granularity. A medical representative can complete training. An area manager can view their team's compliance status but can't modify certification records. A compliance administrator can configure requirements but can't override assessment results. Every permission boundary must be documented in the validation specification.

EU Annex 11: The European Counterpart

If your software serves EU markets, you also need to comply with EU GMP Annex 11 - the European equivalent of Part 11. While the principles are similar, Annex 11 adds specific requirements:

• Periodic review - validated systems must be periodically evaluated to confirm they remain in a validated state
• Data migration - when migrating data between systems, the process must be validated and documented
• Business continuity - backup and recovery procedures must be validated
• Incident management - all incidents must be reported, assessed, and documented

Annex 11 also places greater emphasis on supplier assessment - the pharma company must evaluate and document the quality systems of their software development partner. If 1Raft builds your pharma software, your quality team will audit our development processes, and we provide the documentation to support that assessment.

GAMP 5: How to Categorize and Validate Your Software

GAMP 5 (Good Automated Manufacturing Practice, 5th edition) provides the framework for how pharma companies validate computerized systems. The key concept is risk-based categorization:

Category 1: Infrastructure Software - Operating systems, databases, network infrastructure. Validated through installation qualification.

Category 3: Non-Configured Software - Commercial off-the-shelf (COTS) software used as-is. Validated through operational qualification.

Category 4: Configured Software - COTS software with configuration (Salesforce, SAP, Veeva). Requires design specification of configuration and operational qualification.

Category 5: Custom Software - Purpose-built applications. Requires the full validation lifecycle: URS → FS → DS → code review → IQ → OQ → PQ.

Most pharma software projects that 1Raft builds are Category 5. This means the full set of validation deliverables:

• URS (User Requirements Specification) - what the system must do
• FS (Functional Specification) - how the system meets user requirements
• DS (Design Specification) - technical architecture and design decisions
• Traceability Matrix - mapping from URS → FS → DS → test cases
• IQ (Installation Qualification) - verify the system is installed correctly
• OQ (Operational Qualification) - verify the system operates as specified
• PQ (Performance Qualification) - verify the system performs as intended in production

Data Integrity: The ALCOA+ Framework

Data integrity is the regulatory concept that underpins everything in GxP. The framework is ALCOA+:

• Attributable - every record is traceable to the person who created or modified it
• Legible - records are readable and permanent
• Contemporaneous - records are created at the time the activity occurs
• Original - the first recording of the data (or a verified copy)
• Accurate - records are correct and reflect the actual observation

The "+" adds: Complete, Consistent, Enduring, and Available when needed.

For software developers, ALCOA+ means:

• No record deletion - mark as inactive, never delete
• No backdating - timestamps are system-generated, not user-editable
• No data overwriting - every change creates a new version with full audit trail
• No unattributed changes - batch processes and system jobs must also have attributable audit trails

Sprint-Integrated Validation: How 1Raft Eliminates the Bottleneck

The traditional pharma software development model follows a waterfall pattern:

1. Write requirements (4-6 weeks)
2. Build the software (8-12 weeks)
3. Write validation documentation (4-6 weeks)
4. Execute IQ/OQ/PQ (4-8 weeks)
5. Fix deviations and re-test (2-4 weeks)

Total: 22-36 weeks.

We compress this to 12-16 weeks by integrating validation into each development sprint:

Sprint planning includes validation. When we plan a sprint, we include the corresponding validation deliverables. If we're building the compliance engine, the sprint also includes the Functional Specification for that module and the OQ test cases.

IQ/OQ runs per sprint. Installation and Operational Qualification isn't a phase - it's a continuous process. Each sprint ends with IQ/OQ for the features built in that sprint. By the final sprint, 80% of the validation is already complete.

Traceability is maintained in real time. The traceability matrix - linking URS → FS → DS → test cases → test results - is updated every sprint. By the end of development, the matrix is complete. No scramble.

Deviations are caught early. When validation runs alongside development, deviations (differences between the specification and the built system) are caught in the same sprint. Fixing a deviation in the same sprint costs hours. Fixing it 8 weeks later costs days or weeks.

This is how we built the pharma training platform in 12 weeks - a timeline that would typically take 6-9 months with traditional validation approaches.

Common Mistakes to Avoid

Treating compliance as a phase. If your project plan has "compliance" as a phase after "development," you're already in trouble. Compliance is an architectural concern, not a phase.

Using consumer-grade authentication for electronic signatures. OAuth social login, magic links, and passwordless authentication don't meet Part 11 signature requirements. Electronic signatures need two distinct identification components and must be re-entered at the point of signing.

Assuming cloud platforms handle compliance. AWS, Azure, and GCP provide infrastructure compliance (SOC 2, ISO 27001), but they don't make your application GxP-compliant. Your application layer must implement its own audit trails, electronic signatures, and access controls.

Deleting test data. In GxP, test environments must be managed with the same data integrity controls as production. Test data used during OQ execution is regulatory evidence. Don't clean up test databases after testing.

Skipping the reason-for-change field. This is the most commonly missed Part 11 requirement. Every modification to a GxP record requires the user to enter a reason. "Updated" is not a valid reason. "Corrected certification date per email from regional compliance director dated March 15, 2026" is.

Getting Started

If you're building software for pharma, start with these three steps:

1. Classify your system per GAMP 5. Understand which category your software falls into and what validation deliverables are required.

2. Map your regulatory requirements. Which regulations apply? FDA 21 CFR Part 11, EU Annex 11, CDSCO requirements, WHO-PQ standards? The answer depends on which markets your pharma client serves.

3. Build compliance into your architecture from sprint one. Audit trails, electronic signatures, RBAC, data integrity controls - these are the foundation layer, not the finishing touches.

1Raft has built GxP-compliant software for pharma companies including training platforms, compliance systems, and field force tools. If you're evaluating how to approach a pharma software project, we can help you scope the compliance requirements before you start building.