21 CFR Part 11 Compliant Software Development

Purpose-built pharmaceutical software with electronic records, electronic signatures, audit trails, and data integrity controls that satisfy FDA requirements from day one.

Building Software That Meets FDA Electronic Records Requirements

21 CFR Part 11 is the FDA regulation governing electronic records and electronic signatures in the pharmaceutical, biotech, and medical device industries. First published in the Federal Register on March 20, 1997, it established the criteria under which the FDA considers electronic records and electronic signatures to be trustworthy, reliable, and generally equivalent to paper records and handwritten signatures. For any organization developing or deploying computerized systems that create, modify, maintain, archive, retrieve, or transmit records required under any FDA predicate rule, Part 11 compliance is not optional. It is the regulatory foundation upon which all GxP software systems must be built.

The regulation comprises three subparts. Subpart A (General Provisions) defines the scope and applicability of the regulation. Subpart B (Electronic Records) specifies the controls required for closed and open systems. Subpart C (Electronic Signatures) details requirements for electronic signatures and their components. Together, these subparts create a comprehensive framework that dictates how pharmaceutical software must handle data creation, modification, storage, retrieval, and authentication. Our software development practice is built from the ground up to satisfy every technical requirement of this regulation while also addressing the broader data integrity expectations from the FDA's Data Integrity and Compliance guidance, EU Annex 11, and international regulatory expectations.

The consequences of non-compliance are severe and well-documented. The FDA's warning letter database contains hundreds of citations related to electronic records and data integrity failures. Form 483 observations for data integrity issues have increased dramatically over the past decade, reflecting the FDA's intensified focus on electronic systems. Organizations that fail to implement proper Part 11 controls risk regulatory action that can delay product approvals, halt manufacturing operations, and damage market reputation. Building compliance into the software architecture from inception is orders of magnitude more cost-effective than remediating non-compliant systems after deployment.

Pharmaceutical regulatory compliance software architecture diagram

Section 11.10 -- Controls for Closed Systems

Section 11.10 is the core of Part 11, establishing the baseline controls that every closed system must implement. A closed system is one where access is controlled by the persons responsible for the content of electronic records on that system. Most pharmaceutical software systems qualify as closed systems. The regulation specifies eleven distinct control requirements:

11.10(a) -- System validation: Systems must be validated to ensure accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records. In practice, this means every Part 11 system requires a validation plan, documented requirements, executed test protocols (IQ/OQ/PQ or equivalent under CSA), and a validation summary report. We build our systems with automated regression testing that can be executed as part of ongoing validation.
11.10(b) -- Generating accurate and complete copies: The system must be able to generate accurate and complete copies of records in both human-readable and electronic form suitable for inspection, review, and copying by the agency. We implement export functionality that produces PDF reports, CSV data extracts, and structured XML/JSON outputs that include all metadata, audit trail entries, and electronic signature information.
11.10(c) -- Record protection: Records must be protected throughout their required retention period to enable accurate and ready retrieval. This requires database-level encryption at rest, backup and disaster recovery procedures with tested restoration, and data archival strategies that account for technology obsolescence.
11.10(d) -- System access limitation: Access must be limited to authorized individuals. We implement role-based access control (RBAC) with the principle of least privilege, mandatory authentication before any system interaction, automatic session timeout, account lockout after failed authentication attempts, and formal user provisioning and deprovisioning workflows that require quality unit approval.
11.10(e) -- Audit trails: Computer-generated, time-stamped audit trails must independently record the date and time of operator entries and actions that create, modify, or delete electronic records. Audit trail information must not obscure previously recorded information, must be retained for a period at least as long as the subject electronic records, and must be available for agency review and copying. Our audit trail implementation uses immutable append-only storage with cryptographic integrity verification.
11.10(f) -- Operational system checks: The system must use operational checks to enforce permitted sequencing of steps and events. We implement workflow engines that enforce defined business processes, prevent out-of-sequence operations, and require prerequisite conditions before allowing progression through regulated workflows.
11.10(g) -- Authority checks: The system must use authority checks to ensure that only authorized individuals can use the system, electronically sign a record, access the operation or computer system input or output device, alter a record, or perform the operation at hand.
11.10(h) -- Device checks: Use of device checks to determine validity of data input sources or operational instruction sources. For systems with instrument integration, we implement device identification, calibration status verification, and data source authentication.
11.10(i) -- Personnel training: Determination that persons who develop, maintain, or use electronic record/electronic signature systems have the education, training, and experience to perform their assigned tasks. We build training acknowledgment tracking and competency verification directly into our systems.
11.10(j) -- Written policies: Establishment of and adherence to written policies that hold individuals accountable for actions initiated under their electronic signatures. We provide SOP templates and policy frameworks as part of every system deployment.
11.10(k) -- Documentation controls: Use of appropriate controls over systems documentation including adequate controls for distribution, access, and use of documentation for system operation and maintenance.

Part 11 closed system controls architecture for pharmaceutical software

Sections 11.30, 11.50, 11.70 -- Open Systems, Signatures, and Record Linking

Section 11.30 applies to open systems where the persons responsible for the content of electronic records do not control system access. Cloud-hosted systems, web applications accessed over the internet, and multi-tenant platforms may qualify as open systems depending on the architecture. Open systems must implement all the controls required by Section 11.10 plus additional measures such as document encryption, digital signature standards, and other controls to ensure record authenticity, integrity, and confidentiality. In modern cloud deployments, this translates to TLS 1.3 for data in transit, AES-256 encryption at rest, mutual TLS for API communications, and comprehensive network segmentation.

Section 11.50 requires that signed electronic records contain information associated with the signing that clearly indicates the printed name of the signer, the date and time when the signature was executed, and the meaning associated with the signature (such as review, approval, responsibility, or authorship). We implement signature manifestation panels that display all three elements prominently and persist them as part of the permanent record. The signature meaning is selected from a controlled vocabulary defined during system configuration, ensuring consistency across the organization.

Section 11.70 requires that electronic signatures be linked to their respective electronic records to ensure that the signatures cannot be excised, copied, or otherwise transferred to falsify an electronic record by ordinary means. Our implementation uses cryptographic hash-based linking where the signature record includes a hash of the signed content at the moment of signing. Any subsequent modification to the signed record would invalidate the hash, making tampering detectable. The signature link is stored in a separate, integrity-protected table with its own audit trail, providing an independent verification mechanism.

Electronic signature and record linking workflow for FDA compliance

Sections 11.100, 11.200, 11.300 -- Electronic Signature Controls

Section 11.100 establishes general requirements: each electronic signature must be unique to one individual and not reused by or reassigned to anyone else. Before an organization establishes, assigns, certifies, or otherwise sanctions an individual's electronic signature, the organization must verify the identity of the individual.

Section 11.200 specifies that non-biometric electronic signatures must employ at least two distinct identification components (such as an identification code and password), that the first use in a continuous session must use both components, and that all subsequent uses may use one component. It also requires that the identification code and password issuance be periodically checked, recalled, or revised.

Section 11.300 provides controls for identification codes and passwords: they must be maintained with uniqueness so no two individuals share the same combination, they must be periodically revised, and procedures must be in place for electronically deauthorizing lost or compromised credentials and for detecting unauthorized use. We implement all of these through our identity management module with enforced password complexity, expiration policies, multi-factor authentication options, and real-time anomaly detection for unusual authentication patterns.

Electronic signature identity management for pharmaceutical systems

Predicate Rules and Part 11: Understanding What Systems Need Compliance

Part 11 does not exist in isolation. It applies specifically to records that are required to be maintained under what the FDA calls predicate rules -- the underlying regulations that govern pharmaceutical manufacturing, clinical research, and product quality. Understanding which predicate rules apply to your operations determines which systems fall under Part 11 scope. The FDA's 2003 guidance on Part 11 Scope and Application (FDA Part 11 Scope and Application guidance) adopted a narrow interpretation, focusing enforcement on predicate rule requirements for record keeping.

Drug Manufacturing (cGMP)

21 CFR Part 211 (21 CFR Part 211) -- Current Good Manufacturing Practice for Finished Pharmaceuticals. This predicate rule requires batch production records (211.188), laboratory records (211.194), distribution records (211.196), complaint files (211.198), and records retention (211.180). Any electronic system managing these records must comply with Part 11.

Medical Devices (QSR)

21 CFR Part 820 (21 CFR Part 820) -- Quality System Regulation for medical devices. Requires design history files (820.30), device master records (820.181), device history records (820.184), and quality system records (820.186). Software used for device design, manufacturing, or quality management must be Part 11 compliant and may also fall under IEC 62304 (IEC 62304) and ISO 13485 (ISO 13485).

Good Laboratory Practice (GLP)

21 CFR Part 58 (21 CFR Part 58) -- Good Laboratory Practice for Nonclinical Laboratory Studies. Requires raw data preservation, protocol documentation, and final study reports. LIMS, electronic lab notebooks, and chromatography data systems used in GLP studies must implement Part 11 controls. Read our detailed guide on 21 CFR Part 58 and GLP compliance at /articles/21-cfr-part-58-glp-guide.

Clinical Investigations

21 CFR Part 312 (21 CFR Part 312) for Investigational New Drug Applications and 21 CFR Part 314 (21 CFR Part 314) for New Drug Applications require extensive record keeping throughout the clinical development lifecycle. EDC systems, CTMS, safety databases, and regulatory submission systems all fall under Part 11 when they maintain records required by these predicate rules.

FDA Warning Letters and 483 Observations: Common Part 11 Findings

Analysis of FDA warning letters (FDA warning letters database) and 483 inspection observations (FDA 483 inspection observations) reveals consistent patterns in Part 11 and data integrity citations. Understanding these patterns allows us to design software that proactively addresses the most common inspection findings.

Inadequate or Absent Audit Trails

The most common citation involves systems that either lack audit trail functionality entirely or have audit trails that are incomplete, can be disabled by users, or do not capture all required metadata. Inspectors frequently find systems where audit trails do not record the reason for changes, where audit trail data can be modified or deleted by administrators, or where the audit trail does not capture the original value before modification. Our systems generate immutable audit trails that cannot be disabled, modified, or deleted by any user role, including system administrators.

Shared User Accounts and Inadequate Access Controls

Inspectors frequently cite instances of shared login credentials, generic user accounts (such as "Lab1" or "QC_User"), and systems where access privileges are not aligned with job responsibilities. Shared accounts make it impossible to attribute actions to specific individuals, fundamentally undermining data integrity. Our identity management enforces unique individual accounts, prohibits credential sharing through technical controls, implements configurable session timeouts and lockout policies, and provides automated periodic access review workflows.

Insufficient Backup and Disaster Recovery

Citations in this category involve organizations that cannot demonstrate they can recover electronic records after a system failure, that have not tested their backup restoration procedures, or that do not maintain backups for the full retention period required by predicate rules. We implement automated backup procedures with regular restoration testing, generate documented evidence of each restoration test, and maintain backup copies with the same access controls and data integrity protections as production data.

Data Integrity Failures

The FDA has placed increasing emphasis on data integrity since the mid-2010s. Common findings include the ability to delete or overwrite original analytical data, absence of controls preventing backdating of entries, systems that allow re-processing of data without retaining original results, and metadata that is not adequately controlled. The FDA's Data Integrity Q&A guidance (FDA Data Integrity Q&A guidance) clarifies expectations for computerized systems.

Incomplete or Missing Validation

Systems deployed without adequate validation documentation or systems where validation has not been maintained following changes are regularly cited. This includes missing validation plans, test protocols that do not cover critical functionality, absence of traceability between requirements and test cases, and failure to revalidate after system changes. We deliver complete validation packages with every deployment and maintain traceability matrices that link user requirements through functional specifications to executed test cases.

ALCOA+ Data Integrity: Principles and Software Implementation

The ALCOA+ framework, originally articulated by the WHO Technical Report Series No. 996, Annex 5 (WHO TRS 996, Annex 5) and reinforced by the FDA (FDA Data Integrity Q&A guidance), MHRA (MHRA Data Integrity guidance), PIC/S PI 041-1 (PIC/S PI 041-1), and the Australian TGA (TGA Data Integrity guidance), is the definitive standard for data integrity in regulated environments.

Attributable

Every data entry, modification, and deletion must be traceable to the individual who performed the action. In electronic systems, this means mandatory user authentication before any data interaction, automatic capture of the authenticated user identity with every transaction, and prohibition of shared or generic accounts. For instrument-generated data, attribution extends to identifying the specific instrument, its calibration status, and the method used. Our systems enforce individual login, capture the full attribution chain (user, workstation, timestamp, instrument if applicable), and make this information part of the permanent record.

Legible

Data must be readable and permanent throughout its required retention period. For electronic records, legibility means the data must be presented in human-readable form, not stored in proprietary binary formats that may become inaccessible as technology evolves. We use open, standards-based data formats (such as XML, JSON, and PDF/A for archived records) and implement format migration procedures to ensure data remains readable even after the original system is retired.

Contemporaneous

Data must be recorded at the time it is generated, not retrospectively. Electronic systems have a significant advantage here because server-side timestamps can be automatically applied at the moment of data creation, making post-hoc backdating technically impossible. Our systems use NTP-synchronized server clocks as the sole timestamp source, never relying on client-side clocks that can be manipulated.

Original

The concept of "original" in the age of electronic systems requires careful consideration. The WHO TRS 1033, Annex 4 (WHO TRS 1033, Annex 4) clarifies that for electronic data, the original is the first-captured electronic record. A printout of electronic data is a copy, not the original. Our systems preserve the original electronic data in its first-captured state, protect it from modification through write-once storage patterns, and retain it for the full retention period.

Accurate

Data must be free from errors and must reflect actual observations. Software controls for accuracy include input validation rules (range checks, format validation, referential integrity constraints), real-time calculation verification, instrument calibration status checks before accepting instrument data, and elimination of manual transcription through direct electronic data capture. Our systems implement multi-level validation: client-side for immediate feedback, server-side for security, and database-level constraints as a final safeguard.

Complete

All data, including repeat or reanalysis results, must be retained. Deleting data because of an unexpected result is a serious data integrity violation. Our systems enforce completeness by making data deletion technically impossible for standard users, retaining all iterations of analyses and results, requiring documented justification for any out-of-specification investigation, and ensuring that invalidated data remains accessible and clearly marked as invalidated rather than deleted.

Consistent

Data must be internally consistent: timestamps should be sequential, cross-referenced data should agree, and the same data should not exist in conflicting states across different systems. We implement cross-field validation to detect inconsistencies at the point of entry, use timestamps from a single authoritative time source, implement database referential integrity constraints, and design integration interfaces with conflict detection and resolution mechanisms.

Enduring and Available

Data must be durable and accessible for the full retention period mandated by applicable predicate rules. Enduring means the data is stored in a manner that protects against loss, deterioration, or technological obsolescence. Available means authorized users and regulatory inspectors can access and retrieve the data promptly. We implement redundant storage with geographic distribution, regular backup verification, media integrity monitoring, and technology refresh planning.

Computer Software Assurance: The Modern Approach to GxP Validation

The FDA's Computer Software Assurance (CSA) guidance, first issued as a draft in September 2022 and finalized in September 2024, represents a fundamental shift in how the agency expects regulated organizations to validate computerized systems. Moving away from the documentation-heavy approach of the 2002 General Principles of Software Validation, CSA emphasizes risk-based testing, critical thinking, and assurance activities proportional to the risk the software poses to patient safety and product quality.

The core principle of CSA is that validation effort should be commensurate with risk. Software features that directly affect patient safety, product quality, or data integrity (GxP-critical functions) warrant rigorous, documented testing including scripted test protocols with pre-defined expected results and acceptance criteria. Lower-risk features that support operational efficiency but do not directly impact GxP outcomes can be assured through unscripted testing approaches such as exploratory testing, ad hoc testing, or error guessing. This risk stratification, aligned with ISPE GAMP 5 Second Edition risk assessment methodologies and ICH Q9(R1) quality risk management principles, can reduce validation timelines by 40-60% while actually improving the quality of testing.

Our development methodology integrates CSA principles from project inception. During the requirements phase, we conduct a risk assessment that classifies each requirement as high, medium, or low impact to GxP. This classification drives the testing strategy: high-impact requirements receive scripted protocol testing with formal deviation management, medium-impact requirements receive a combination of scripted and unscripted testing, and low-impact requirements are addressed through unscripted exploratory testing. This approach is fully consistent with PIC/S PI 011-3 guidance on computerized systems in GxP environments and the ISPE GAMP Records and Data Integrity Guide.

Computer Software Assurance risk-based validation methodology

Why Build Part 11 Systems With IntuitionLabs?

Deep regulatory expertise combined with modern software engineering for pharmaceutical-grade systems. Part 11 requirements are baked into our software architecture from the first line of code, not bolted on as an afterthought.

Compliance by Design

Audit trails, access controls, and electronic signatures are core infrastructure, not add-on modules. Inspection-ready documentation ships with every system including validation plans, test protocols, traceability matrices, and summary reports that satisfy FDA, EMA, and international regulatory authorities.

Schedule a consultation

CSA-Aligned Validation

We apply the FDA's Computer Software Assurance methodology, focusing testing effort on GxP-critical functions while using efficient unscripted testing for lower-risk features. This reduces validation timelines without compromising quality or regulatory compliance.

Custom development services

International Regulatory Coverage

Our systems comply with EU Annex 11 (EU GMP Annex 11), PIC/S guidelines (PIC/S PI 011-3), MHRA data integrity guidance (MHRA Data Integrity guidance), and WHO data integrity requirements (WHO TRS 996, Annex 5), not just FDA Part 11.

Learn more

Veeva Ecosystem Integration

As a Veeva XPages partner, we build systems that integrate seamlessly with Veeva Vault, CRM, and other Veeva solutions while maintaining full Part 11 compliance across the integration layer.

Veeva services

AI-Accelerated Development

We leverage AI-assisted development to deliver compliant systems faster and at lower cost without compromising regulatory rigor. Our modern engineering practices accelerate time to market while maintaining the highest compliance standards.

Custom pharma development

Domain Experts, Not Generalists

25 years of pharmaceutical technology experience including GxP system validation, Part 11 compliance, and regulated software development across the drug lifecycle. Our team speaks your language and knows your workflows.

Meet the team

Your Part 11 Compliance Lead

Adrien Laurent, Founder & Principal Engineer

25+ years of enterprise software development in regulated industries
Deep expertise in 21 CFR Part 11, EU Annex 11, and GAMP 5 validation
Specializes in audit trail architecture, electronic signatures, and data integrity controls
Builds GxP-compliant software systems for pharmaceutical and biotech companies daily

Schedule a consultation

Adrien Laurent, Founder & Principal Engineer

Cloud Qualification for GxP Systems

The migration of GxP systems to cloud infrastructure introduces additional qualification requirements beyond traditional on-premise validation. Cloud service providers (CSPs) operate on a shared responsibility model where the provider is responsible for the security and availability of the cloud infrastructure, while the regulated organization retains responsibility for the compliance of the application and data.

Our cloud qualification process begins with a CSP assessment that evaluates the provider against pharmaceutical industry requirements. We verify that the CSP maintains current ISO 27001 certification for information security management, SOC 2 Type II attestation covering security, availability, processing integrity, confidentiality, and privacy, and CSA STAR registration demonstrating cloud-specific security controls.

The qualification protocol documents the CSP assessment findings, maps each Part 11 requirement to the responsible party (CSP or customer), verifies that CSP-managed controls are independently audited, and establishes ongoing monitoring procedures. Encryption requirements for open systems under Section 11.30 are satisfied through TLS 1.3 for data in transit and AES-256 for data at rest, with customer-managed encryption keys where required for maximum control.

For organizations operating under multiple regulatory frameworks, we ensure cloud deployments simultaneously satisfy EU Annex 11 requirements, MHRA expectations for data hosted by third parties, and ICH Q10 pharmaceutical quality system requirements.

Cloud qualification architecture for GxP pharmaceutical systems

Types of Systems We Build With Part 11 Compliance

Purpose-built pharmaceutical software across the entire regulated lifecycle, each designed with full Part 11 controls from the ground up.

Laboratory Information Management Systems (LIMS)

Sample tracking, test execution, result capture, out-of-specification investigations, instrument integration, and certificate of analysis generation with complete audit trails and electronic approvals.

Learn more

Electronic Batch Records (EBR)

Digital batch production records replacing paper-based manufacturing documentation. Real-time data capture, in-process checks, deviation management, and electronic release with enforced workflow sequencing.

Learn more

Quality Management Systems (QMS)

Deviation tracking, CAPA management, change control, document management, and supplier qualification with role-based approvals and complete traceability.

Learn more

Clinical Data Management Systems

Electronic data capture (EDC), clinical trial management, safety database (pharmacovigilance), and regulatory submission systems with Part 11 electronic signatures.

Learn more

Stability Management Systems

Stability study design, chamber management, sample scheduling, trend analysis, and shelf-life determination with automated alerting for out-of-trend results and regulatory reporting.

Learn more

Training Management Systems

Training curriculum design, assignment tracking, competency assessment, training record management, and compliance reporting to satisfy 11.10(i) personnel qualification requirements.

Learn more

Environmental Monitoring Systems

Particle count monitoring, viable sampling management, temperature and humidity tracking, excursion alerting, and trend analysis for cleanroom and controlled environment compliance.

Learn more

Complaint Handling Systems

Complaint intake, investigation tracking, root cause analysis, regulatory reporting (MedWatch, MHRA Yellow Card), and trend analysis with automated escalation workflows.

Learn more

Supplier Qualification Databases

Supplier assessment, audit management, qualification status tracking, approved supplier lists, and material traceability for compliance with 21 CFR 211.84 component qualification requirements.

Learn more

Document Management Systems (DMS)

Controlled document creation, review and approval workflows, version control, periodic review scheduling, and distribution management with electronic signatures and full document lifecycle audit trails.

Learn more

Regulatory Information Management (RIM)

Submission tracking, regulatory commitment management, labeling management, and regulatory intelligence with structured data for eCTD compilation and health authority correspondence.

Learn more

Equipment Qualification & Calibration

Equipment lifecycle management, calibration scheduling, preventive maintenance tracking, and qualification status monitoring with integration to CMMS and ERP systems.

Learn more

Data Migration Under Part 11: Maintaining Compliance During System Transitions

Migrating data between pharmaceutical systems is one of the most risk-laden activities in IT, and doing so while maintaining Part 11 compliance requires a rigorous, validated approach. Data migration is not simply an IT project; it is a regulated activity that must be planned, executed, documented, and verified with the same rigor as any other GxP process. The ISPE GAMP 5 framework provides guidance on data migration within the context of system lifecycle management, and the GAMP Records and Data Integrity Guide specifically addresses the requirements for maintaining data integrity during migration.

Our data migration methodology follows a structured protocol that begins with a comprehensive data inventory. We catalog every data element in the source system, including records, metadata, audit trail data, electronic signatures, and system configuration data. A data mapping document specifies how each source element maps to the target system, identifying any transformations, format changes, or structural differences.

Migration validation includes multiple verification activities. Automated record count reconciliation confirms that all records were transferred. Field-level data comparison using cryptographic checksums verifies data integrity at the individual value level. Referential integrity verification confirms that relationships between records are preserved. Audit trail continuity verification ensures that the historical record of data changes is maintained. Electronic signature linkage confirmation verifies that signed records remain properly linked to their signatures in the target system.

Legacy data presents a particular challenge. When a source system is being retired but its data must remain accessible for the full predicate rule retention period, organizations have several options: migrating all data to the new system, maintaining the legacy system in a read-only state, or creating a qualified data archive. We assess each situation and recommend the approach that best balances compliance risk, cost, and operational needs, always ensuring that the chosen approach satisfies the record protection and retrieval requirements of Section 11.10(c).

Data migration validation process for Part 11 pharmaceutical systems

Periodic Review and System Retirement

Validation is not a one-time event. Maintaining the validated state of a Part 11 system requires ongoing periodic review activities that verify the system continues to operate as intended and that all compliance controls remain effective. The ISPE GAMP 5 Second Edition recommends periodic reviews at least annually for GxP-critical systems, with the frequency determined by the system's risk classification. EU Annex 11 Section 11 explicitly requires periodic evaluation to confirm that systems remain in a validated state.

We build periodic review capabilities directly into our systems. Automated compliance dashboards provide real-time visibility into the health of all Part 11 controls. Specific review activities include: user access review (verifying that all active accounts are appropriate), audit trail integrity verification (confirming that audit trail records have not been tampered with using cryptographic checksums), backup and restore testing (executing and documenting a test restoration from backup media), change control review, security incident review, performance review, and environmental review.

When a system reaches end of life, a formal decommissioning protocol ensures that data integrity is maintained through the transition. The decommissioning process includes data disposition planning, data migration or archival execution per validated protocols, verification that archived data remains accessible and readable, formal documentation of the retirement decision and approval by the quality unit, and removal of all system access. Records subject to 21 CFR 211.180 must be retained for at least one year after the expiration date of the last batch manufactured under those records, which can extend decades beyond system retirement.

Periodic review and compliance monitoring dashboard for GxP systems

International Regulatory Alignment: Beyond FDA Part 11

Pharmaceutical companies operating globally must comply not only with FDA Part 11 but with equivalent electronic records regulations from multiple international authorities. Designing systems that satisfy the most stringent requirements across all applicable regulations ensures compliance everywhere, avoiding the need for region-specific system variants. Our systems are designed to the union of all these regulatory expectations, ensuring that a single system deployment satisfies FDA Part 11, EU Annex 11, PIC/S, WHO, MHRA, TGA, and ICH requirements simultaneously.

EU GMP Annex 11

Annex 11 to the EU GMP Guide (EU GMP Annex 11) addresses computerised systems used in manufacturing, quality control, and storage of medicinal products. Updated in 2011, it is more prescriptive than Part 11 in several areas, including requirements for formal risk management, data migration validation, business continuity planning, and the specific clause requiring that third-party system providers demonstrate their quality system and competence.

PIC/S Guidance

The Pharmaceutical Inspection Co-operation Scheme issues guidance documents adopted by over 50 member regulatory authorities worldwide. PIC/S PI 011-3 (PIC/S PI 011-3) provides guidance on computerised systems in GMP environments, while PIC/S PI 041-1 (PIC/S PI 041-1) specifically addresses data integrity expectations. These documents influence inspection practices across PIC/S member states, creating a de facto global standard.

WHO Technical Reports

WHO TRS 996, Annex 5 (WHO TRS 996, Annex 5) on data integrity and WHO TRS 1033, Annex 4 (WHO TRS 1033, Annex 4) on good data and record management practices set standards adopted by regulatory authorities in emerging markets and are referenced by WHO prequalification assessments.

MHRA and TGA Data Integrity Guidance

The UK MHRA Data Integrity guidance (MHRA Data Integrity guidance) updated March 2018 and the Australian TGA data integrity guidance (TGA Data Integrity guidance) provide additional perspectives on electronic records expectations. The MHRA guidance is particularly influential and widely referenced for its practical approach to data governance.

ICH Quality Guidelines

ICH Q7 (ICH Q7) for GMP for Active Pharmaceutical Ingredients, ICH Q9(R1) (ICH Q9(R1)) for Quality Risk Management, and ICH Q10 (ICH Q10) for Pharmaceutical Quality System form the quality management framework within which electronic records systems operate.

ISPE GAMP and Baseline Guides

ISPE GAMP 5 Second Edition (ISPE GAMP 5 Second Edition) is the industry-standard framework for GxP computerized system validation, providing a risk-based approach to system categorization, specification, verification, and lifecycle management. The GAMP Records and Data Integrity Guide (GAMP Records and Data Integrity Guide) specifically addresses data integrity in electronic systems. ISPE Baseline Guides provide additional operational guidance for specific system types and facility configurations.

Our Technical Architecture for Part 11 Systems

Achieving Part 11 compliance requires deliberate architectural decisions that cannot be retrofitted. The following patterns form the foundation of every system we build.

Immutable Audit Trail Architecture

Append-only database tables with cryptographic hash chains that prevent any modification of audit records, even by database administrators. Every change to regulated data generates an audit entry before the change is committed.

Cryptographic Signature Binding

Electronic signatures are bound to the signed record through SHA-256 content hashing. Any modification to the signed content invalidates the hash, making tampering immediately detectable during routine integrity checks.

Server-Side Timestamp Authority

All timestamps originate from NTP-synchronized server clocks, never from client devices. Timestamp integrity is verified through periodic NTP drift monitoring with automated alerting if synchronization deviates beyond configurable thresholds.

Defense-in-Depth Access Control

Multi-layer access enforcement: network-level segmentation, application-level RBAC with least privilege, API-level authorization, database-level row security, and field-level encryption for sensitive data. No single compromised layer exposes regulated data.

Validated Backup and Recovery

Automated backup procedures with geographic redundancy, point-in-time recovery capability, and quarterly restoration testing with documented evidence. Recovery time objectives and recovery point objectives are defined per system criticality.

Continuous Compliance Monitoring

Automated dashboards that monitor audit trail integrity, access control compliance, backup health, certificate validity, and system performance against validated parameters. Deviations trigger real-time notifications to quality personnel.

21 CFR Part 11 Software Development: Frequently Asked Questions

21 CFR Part 11 is the FDA regulation that establishes criteria for accepting electronic records and electronic signatures as equivalent to paper records and handwritten signatures. Published in 1997 and clarified by the 2003 Scope and Application guidance FDA Part 11 Scope and Application guidance, it applies to any computerized system that creates, modifies, maintains, archives, retrieves, or transmits records required by FDA predicate rules. Non-compliance can result in FDA warning letters, 483 observations, consent decree requirements, and in severe cases, product seizure or injunction. Every pharmaceutical software system that handles regulated data must be designed with Part 11 controls from the ground up, not retrofitted after development.

The 2003 FDA guidance FDA Part 11 Scope and Application guidance adopted a risk-based approach, narrowing the scope of Part 11 enforcement. The FDA stated it would exercise enforcement discretion for certain requirements while focusing on predicate rule compliance. Systems that maintain records required by predicate rules and use electronic signatures in lieu of handwritten signatures remain fully subject to Part 11. Systems that merely automate internal processes without regulatory record obligations may have reduced compliance requirements. However, the FDA emphasized that data integrity expectations from predicate rules still apply regardless of Part 11 enforcement discretion.

CSV is the traditional approach defined in the 2002 General Principles of Software Validation guidance General Principles of Software Validation guidance, emphasizing exhaustive scripted testing and comprehensive documentation. CSA, introduced in the 2022 draft CSA guidance and finalized in September 2024 FDA CSA guidance, shifts toward risk-based testing with critical thinking. CSA encourages unscripted exploratory testing for lower-risk functions and reserves rigorous scripted testing for high-risk GxP-critical features. The practical difference is a significant reduction in documentation overhead for non-critical functions while maintaining the same level of assurance for patient safety and data integrity. We design our validation approach using CSA principles where appropriate, focusing testing effort where it matters most.

Our audit trail implementation follows 21 CFR 11.10(e) requirements 21 CFR 11.10 for computer-generated, time-stamped audit trails that independently record the date and time of operator entries and actions. Every audit trail entry captures the who (authenticated user identity), what (the field or record changed), when (server-side UTC timestamp from a qualified time source), the previous value, and the new value. Audit trails are stored in append-only database structures that prevent modification or deletion, even by system administrators. We implement cryptographic hashing to detect any tampering, and audit trail review interfaces allow quality personnel to filter, search, and export records for regulatory review.

Part 11 defines two categories of electronic signatures under Subpart C 21 CFR Part 11 Subpart C. Biometrics-based signatures use a unique biological characteristic such as a fingerprint or retinal scan. Non-biometric signatures use at least two distinct identification components, typically a user ID and password. For continuous signing sessions, the initial signing requires both components, while subsequent signings may use one component if the session has not been interrupted. Each electronic signature must be linked to its respective electronic record, must include the printed name of the signer, the date and time of signing, and the meaning of the signature such as review, approval, or responsibility. We implement both types and ensure signatures cannot be reused, reassigned, or repudiated.

Cloud-hosted GxP systems require a shared responsibility model where the cloud service provider handles infrastructure controls and we ensure application-level Part 11 compliance. We qualify cloud providers by verifying ISO 27001 certification ISO 27001, SOC 2 Type II attestation, and CSA STAR registration CSA STAR. A cloud qualification protocol documents the provider assessment, data residency requirements, encryption at rest and in transit, backup and disaster recovery testing, and the provider change management processes. The application layer implements all Part 11 controls including access controls, audit trails, and electronic signatures independent of the infrastructure. We also establish Service Level Agreements that address GxP-specific uptime, data integrity, and incident response requirements.

ALCOA+ is the framework for data integrity established by the WHO WHO Technical Report Series No. 996 and endorsed by the FDA FDA Data Integrity guidance. It stands for Attributable, Legible, Contemporaneous, Original, and Accurate, with the plus adding Complete, Consistent, Enduring, and Available. In software, we implement this through mandatory user attribution on every data entry, human-readable data formats with no hidden or obscured fields, server-side timestamps that cannot be manipulated, preservation of original data with any changes tracked through audit trails, input validation and range checks for accuracy, referential integrity constraints for completeness, cross-field validation for consistency, qualified database storage for endurance, and role-based access controls ensuring authorized availability.

Data migration for Part 11 systems follows a validated protocol that treats the migration as a regulated process. We begin with a complete data inventory and mapping between source and target systems, including metadata and audit trail data. Migration validation includes automated record count reconciliation, field-level data comparison using checksums, verification of data relationships and referential integrity, audit trail continuity verification, and electronic signature linkage confirmation. We execute the migration protocol with pre-approved acceptance criteria, document any discrepancies with root cause analysis, and generate a formal migration validation report. Legacy data that cannot be migrated retains accessibility through archived system access or certified data extracts per 11.10(c) requirements 21 CFR 11.10 for record protection and retrieval.

FDA investigators follow established inspection procedures that focus on data integrity and system controls. They typically review system access controls and user account management, examine audit trail configurations and sample audit trail entries for completeness, verify electronic signature implementations and their linkage to records, assess backup and disaster recovery procedures and test restoration, review validation documentation including requirements, test protocols, and deviation reports, and evaluate change control procedures for system modifications. Common findings include inadequate audit trail configurations, shared user accounts, lack of periodic access reviews, insufficient backup testing, and incomplete validation documentation. We design our systems to address every item on the typical FDA inspection checklist so your team can confidently demonstrate compliance during any inspection.

Maintaining the validated state requires ongoing periodic review, which we build into every system as automated compliance monitoring. Periodic reviews assess continued user access appropriateness, audit trail integrity verification, backup and restore testing results, change control log review, security incident analysis, and performance against validated parameters. For system retirement, we follow a decommissioning protocol that includes data archival to qualified long-term storage, verification that archived data remains accessible and readable for the full retention period required by applicable predicate rules, formal documentation of the retirement decision and data disposition, and removal of system access. Predicate rules such as 21 CFR 211.180 21 CFR 211.180 may require records to be retained for years after the last batch expiration date, so archived data must remain Part 11 compliant throughout.

Ready to Build Part 11 Compliant Software?

From LIMS to electronic batch records to clinical data systems, we build pharmaceutical software with compliance engineered in from the first line of code. Start with a free compliance architecture consultation.

Schedule Free Consultation