FDA 21 CFR Part 11: Infrastructure vs. Application Responsibility

FDA 21 CFR Part 11: Infrastructure vs. Application Responsibility

 

Who owns what when a cloud provider hosts regulated records - and where compliance gaps actually form.

 

FDA 21 CFR Part 11 governs electronic records and electronic signatures used in FDA-regulated environments. When life sciences companies move those records to cloud infrastructure, a practical question arises: which controls belong to the infrastructure provider, and which belong to the regulated customer? The answer has direct consequences for inspection readiness, validation documentation, and regulatory accountability.

 

The core finding from FDA's own guidance and consistent industry practice is this: the FDA does not certify cloud infrastructure providers as Part 11 compliant. Compliance belongs to the organization that creates, modifies, maintains, archives, retrieves, or transmits regulated electronic records. Infrastructure providers support that compliance by implementing and documenting specific controls - but they do not transfer responsibility to themselves by doing so.

 

Why "Part 11 Certified Infrastructure" Is a Misleading Concept

 

A common misconception in life sciences procurement is that selecting a vendor with a "Part 11 certified" or "GxP-ready" infrastructure resolves the regulated customer's compliance obligations. It does not.

 

FDA's 2003 Scope and Application guidance states that Part 11 applies to records in electronic form that are created, modified, maintained, archived, retrieved, or transmitted under any records requirements set forth in Agency regulations. Compliance is determined by applicable regulations, intended system use, technical controls, procedures, and supporting evidence - not a vendor credential.

 

As REDCap Cloud's published guidance confirms, the FDA does not certify or approve any software as Part 11 compliant. Vendors can build compliant-capable systems and supply validation documentation, but compliance is established by the organization deploying the system - through validation, procedures, and training.

 

The practical implication is that a cloud infrastructure provider's documented controls form a foundation. That foundation is necessary but not sufficient. The regulated customer must validate its own use of the infrastructure, govern its own workflows, and retain its own records.

 

The 10 Control Areas Infrastructure Providers Must Address

 

The following 10 areas represent the technical prerequisites that allow regulated customers to build compliant applications on top of cloud infrastructure. They are not optional design choices; they are the implementation and documentation responsibilities that infrastructure providers must fulfill.

 

• Access control
  • What Infrastructure Providers Must Implement: Role-based access, unique user accounts, MFA, least privilege
  • Priority: Critical
• Audit trails
  • What Infrastructure Providers Must Implement: Time-stamped, protected logs of relevant activities and data changes
  • Priority: Critical
• Data integrity
  • What Infrastructure Providers Must Implement: Protection against unauthorized alteration, deletion, and corruption
  • Priority: Critical
• System validation
  • What Infrastructure Providers Must Implement: Documented testing, qualification, and change-control evidence
  • Priority: Critical
• Electronic signatures
  • What Infrastructure Providers Must Implement: Application-level identity verification, signing controls, record linking
  • Priority: Conditional
• Data retention
  • What Infrastructure Providers Must Implement: Configurable retention, secure archives, reliable retrieval
  • Priority: High
• Backup and recovery
  • What Infrastructure Providers Must Implement: Automated backups, tested recovery procedures, disaster recovery
  • Priority: High
• Change management
  • What Infrastructure Providers Must Implement: Approval, testing, traceability, and documentation of changes
  • Priority: High
• Security monitoring
  • What Infrastructure Providers Must Implement: Monitoring, incident response, and security-event review
  • Priority: High
• Documentation
  • What Infrastructure Providers Must Implement: SOPs, risk assessments, architecture diagrams, test records
  • Priority: Critical

 

Three of these areas generate the most frequent compliance findings and the most confusion about who is responsible.

 

Access Control

 

Access control at the infrastructure level means the provider implements role-based permissions, enforces unique user accounts, requires multi-factor authentication, and applies least-privilege principles at the compute, identity, storage, and network layers. FDA's guidance specifically identifies limiting system access to authorized individuals as a provision it will continue to enforce - even during the period when it exercised discretion on certain other Part 11 requirements.

 

What infrastructure access control does not cover is application-layer permission logic. Which users can approve a batch record, which roles can initiate a change order, and which accounts can sign a regulated document are decisions that live in the application, not the infrastructure. The infrastructure provider can confirm that only authenticated identities reach the system; it cannot define what those identities are permitted to do inside a customer's regulated workflow.

 

Audit Trails

 

Part 11 requires secure, computer-generated, time-stamped audit trails that independently record the date and time of operator entries and actions that create, modify, or delete electronic records. Infrastructure providers must implement logging at the infrastructure layer - storage access logs, identity events, administrative actions, and network activity. These logs must be protected from alteration and retained in a retrievable form.

 

However, the audit trail that regulators most frequently inspect is the application-layer audit trail: who changed a specific data field in a clinical trial record, what value was replaced, when it changed, and under whose authority. USDM's guidance notes that event logs alone are not enough - the system needs granular, reviewable traceability. That granularity is a customer responsibility, not an infrastructure one.

 

Lazarus Alliance's audit practice identifies missing or inadequate audit trail review procedures as one of the most common Part 11 findings in 2024 - 2025, alongside audit trails that are not enabled or not capturing meaningful data - who, what, when, why. The first two findings are often customer failures: the infrastructure may be logging correctly while the application layer is not.

 

System Validation

 

Validation is where the infrastructure-versus-application distinction becomes most consequential for inspections. Infrastructure providers should maintain documented qualification evidence - installation qualification (IQ), operational qualification (OQ), and where applicable performance qualification (PQ) records - that establish the infrastructure operates as intended and remains under change control.

 

A customer can draw on that documentation when building its own validation package. What it cannot do is cite the infrastructure provider's validation as a substitute for its own. As Greenlight Guru's published guidance explains, FDA has stated that organizations do not have to reinvent the wheel and can draw on a software provider's validation documentation - provided that documentation addresses the requirements of Part 11 as they apply to the customer's specific use.

 

The phrase "as they apply to the customer's specific use" carries weight. A pharmaceutical company running stability data calculations on a validated infrastructure must still validate that its specific application, configuration, and workflow produce reliable results for that specific purpose.

 

Where the Responsibility Line Actually Falls

 

The division of ownership runs across three layers.

 

At the top, the regulated customer - a pharmaceutical company, biotechnology firm, or clinical research organization - defines the regulated workflows, approves the intended use of the system, owns GxP validation, and owns the regulatory records themselves. No infrastructure contract transfers this accountability.

 

At the middle layer, the application handles electronic signatures, record workflows, audit trail review, and application-level validation. These functions are the customer's to configure, validate, and govern. Electronic signature controls, for example, are only necessary at the infrastructure layer where the supported application uses regulated electronic signatures. Where the application does not use them, the infrastructure provider need not implement them - but the customer's application must handle them correctly if the workflow requires them.

 

At the infrastructure layer, the provider owns dedicated compute, identity and access controls, storage and backup, logging and monitoring, network isolation, and the qualification evidence that supports customer validation. The provider's job is to implement those controls correctly and make the evidence accessible to customers for their own validation packages.

 

The division is not arbitrary. It exists because FDA inspection follows the record. When an investigator asks who approved a batch record, when a field was changed, or whether a signature is linked to the correct version of a document, those questions resolve at the application and customer layers. The infrastructure layer provides the environment; the application and customer layers generate and govern the records.

 

Lazarus Alliance states explicitly that responsibility for Part 11 compliance cannot be delegated to a cloud or SaaS vendor. Even if a provider is validated and issues an IQ/OQ or certification, the customer remains ultimately accountable. Customers must perform supplier audits, review SOC 2 and Part 11 bridge letters, and maintain risk-based oversight.

 

How Enforcement Discretion and Risk-Based Validation Affect Infrastructure Planning

 

FDA's 2003 Scope and Application guidance introduced enforcement discretion for certain Part 11 provisions, including some validation, audit trail, record retention, and record-copying requirements. Infrastructure teams sometimes interpret this discretion as permission to reduce investment in those controls.

 

FDA's guidance is clear on this point: enforcement discretion does not eliminate relevant underlying regulatory obligations. Records must still be maintained or submitted in accordance with the underlying predicate rules, and the Agency can take regulatory action for noncompliance with those predicate rules. The enforcement discretion narrows the specific Part 11 provisions FDA will pursue; it does not create a general exemption from maintaining secure, auditable, and integral records.

 

The more useful framework for infrastructure planning is FDA's 2022 Computer Software Assurance (CSA) guidance, which USDM's analysis describes as reducing validation burden while strengthening focus on the controls that matter most to Part 11 compliance. CSA encourages validation proportionate to a system's impact on product quality and patient safety. A logging subsystem that handles non-GxP activity does not require the same validation depth as a system that generates batch release records. For infrastructure providers, the practical application is to identify which components directly support regulated records and apply rigorous, documented validation there - while applying proportionate controls elsewhere.

 

What Hybrid Deployments Get Wrong

 

When infrastructure and application responsibilities are not clearly assigned, regulated enterprises face specific inspection risks.

 

The most common gap is audit trail ownership. Infrastructure logs exist; application logs are incomplete or not reviewed; and no written procedure assigns responsibility for periodic review. FDA's guidance expects audit trail review before final approval or release of records - before batch release, before clinical study data lock - and at regular intervals. If neither the infrastructure provider nor the customer has documented ownership of that review, the gap appears in an inspection.

 

A second common gap is change control. Infrastructure providers apply change management to the infrastructure. Customers apply change management to their applications. Neither party documents the impact of infrastructure changes on validated application configurations. When an infrastructure upgrade changes a system behavior that affects a regulated workflow, and no qualification evidence covers that change, the customer's validation is no longer current.

 

A third gap involves electronic signature linkage. Part 11 section 11.70 requires that signatures be linked to records so they cannot be excised, copied, or otherwise transferred to falsify another record. As USDM's guidance explains, this linkage is an application-layer responsibility. Infrastructure that stores records securely but does not enforce signature-record binding at the application level leaves a compliance gap that the infrastructure's own controls cannot close.

 

Clarity about responsibility prevents all three gaps. Each party knows what it owns, what evidence it must produce, and what it must demonstrate during an inspection.

 

OneSource Cloud's Position in This Framework

 

OneSource Cloud operates as a private AI infrastructure provider serving pharmaceutical, biotechnology, and clinical research customers. In the framework described above, it occupies the infrastructure layer: responsible for compute, identity and access controls, storage and backup, logging and monitoring, network isolation, and the qualification evidence customers need for their own validation packages.

 

That position carries real compliance obligations - the 10 control areas above are not aspirational. It also carries a defined boundary: customer workflow definition, GxP validation, regulated-record governance, and application-layer controls remain the customer's responsibility.

 

For regulated enterprises evaluating private cloud infrastructure, the practical questions to ask any provider include: What qualification documentation do you supply? How do your change management procedures notify customers of changes that affect validated configurations? How are audit logs protected, retained, and made available for customer review? How do you handle access provisioning and de-provisioning across customer tenancies? Those questions map directly to the responsibility line and determine whether the infrastructure foundation is solid enough to support compliant applications.

 

Conclusion

 

FDA 21 CFR Part 11 does not require cloud infrastructure providers to obtain independent Part 11 certification. It requires the organization that creates, modifies, maintains, archives, retrieves, or transmits regulated electronic records to ensure those records are trustworthy, reliable, and attributable.

 

Infrastructure providers support that obligation by implementing and documenting controls across 10 areas - access control, audit trails, data integrity, system validation, electronic signatures where applicable, data retention, backup and recovery, change management, security monitoring, and documentation. These controls are foundational but not sufficient. The regulated customer must validate its own use of the infrastructure, define its own workflows, govern its own records, and review its own audit trails.

 

FDA's enforcement discretion on certain Part 11 provisions does not eliminate underlying predicate-rule obligations. Risk-based validation under the CSA framework reduces burden proportionately but does not remove the requirement to validate what matters. Responsibility for compliance cannot be delegated to a vendor, regardless of that vendor's own certification or qualification status.

 

The division between infrastructure and application responsibility determines who can answer an FDA investigator's questions about a specific record, on a specific date, under a specific signature. Both the infrastructure provider and the regulated customer need to know exactly where that line falls - and be ready to demonstrate they have fulfilled their respective obligations.

 

Frequently Asked Questions

 

Does a cloud provider's SOC 2 report satisfy Part 11 requirements?

 

A SOC 2 report provides evidence that a provider has implemented security controls relevant to availability, confidentiality, and processing integrity. It is useful background documentation for a supplier audit but does not establish Part 11 compliance for either the provider or the customer. Part 11 requires specific controls - validated systems, protected audit trails, access controls, and signature linkage - that are distinct from SOC 2's scope. Regulated customers should obtain and review any Part 11 bridge letters the provider supplies alongside SOC 2 documentation.

 

If an infrastructure provider's audit logs exist, does the customer still need to review them?

 

Yes. FDA expects audit trail reviews to occur before the approval or release of regulated records and at regular intervals thereafter. The existence of logs is not the same as reviewed logs. The customer must maintain a procedure assigning responsibility for audit trail review, documenting what was reviewed, at what frequency, and by whom. Infrastructure logs and application logs may both require review depending on the scope of the regulated system.

 

How does FDA's 2022 Computer Software Assurance guidance change validation planning for infrastructure?

 

The CSA framework encourages validation proportionate to a system's impact on product quality and patient safety. For infrastructure providers, this means identifying which components directly support regulated records and applying documented, rigorous validation there. Components with no direct impact on regulated records may require proportionately less formal validation. The framework does not eliminate the obligation to validate; it redirects effort toward the controls that carry the most regulatory risk.

 

Sources

 

• FDA, Part 11 Electronic Records; Electronic Signatures - Scope and Application
• Lazarus Alliance, FDA 21 CFR Part 11 Audit Services
• USDM, 21 CFR Part 11 Compliance Guide for Life Sciences
• REDCap Cloud, 21 CFR Part 11 Compliant Software
• Greenlight Guru, 21 CFR Part 11 Compliance Software: 6 Benefits to Look For