Why Cloud Systems Raise Part 11 Questions

When Part 11 was written in 1997, enterprise software lived on servers in your data center. You controlled the hardware, the network, the backups, and the physical security. Compliance was complex but conceptually straightforward: you could point to the server room and say "our records are there."

Cloud computing changed the equation. When your regulatory records live in Azure, AWS, or a vendor's proprietary cloud, several Part 11 requirements become more nuanced:

  • Where are the records physically stored? Multi-region cloud deployments mean records might exist in multiple geographic locations simultaneously.
  • Who has access to the infrastructure? The cloud provider's staff, the SaaS vendor's operations team, and your own users all have different levels of access.
  • How are records protected during transmission? Data moves between your browser and the cloud, between data centers for replication, and between systems for integration.
  • What happens if the vendor goes out of business? Your records need to be accessible and retrievable regardless of vendor continuity.
  • How do you validate a system you don't control? Traditional IQ/OQ/PQ validation assumed you were testing hardware and software you owned and operated.

These are real questions that every regulatory team should ask their software vendors. But they're also largely solved problems in 2026 — cloud platforms can absolutely meet Part 11 requirements, and in many cases offer stronger controls than on-premise alternatives.

The Core Part 11 Requirements

Part 11 has three main categories of requirements. Here's what each means for cloud-based regulatory systems:

1. Electronic Records (§11.10)

Controls for closed systems — systems where access is controlled by the organization responsible for the records:

Validation (§11.10(a)): The system must be validated to ensure accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records. For cloud systems, this means the SaaS vendor should provide IQ/OQ/PQ documentation or support your organization's validation activities. Risk-based validation approaches (per GAMP 5) are accepted and practical for SaaS platforms.

Audit trails (§11.10(e)): The system must generate 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. For cloud systems, audit trails should be immutable (not editable by any user, including administrators), include user identification, timestamps, and details of what changed. The audit trail itself must be retained for at least as long as the records it covers.

Access controls (§11.10(d), §11.10(g)): The system must limit access to authorized individuals. This includes unique user identification (no shared accounts), role-based permissions, and procedures for handling lost, stolen, or compromised credentials. Cloud systems should support SSO (Single Sign-On) integration with your organization's identity provider and enforce password policies or multi-factor authentication.

Authority checks (§11.10(f)): The system must verify that only authorized individuals can use the system, electronically sign records, access the operation or input devices, alter records, or perform operations. This maps directly to role-based access control (RBAC) — users should only see and do what their role permits.

Device checks (§11.10(h)): The system should verify the validity of data input sources. For cloud systems, this translates to input validation, data integrity checks, and verification that data hasn't been corrupted during transmission.

Record retention (§11.10(c)): Records must be available and retrievable throughout their required retention period. Cloud vendors should provide data export capabilities and guarantee that records remain accessible for the required duration (typically the life of the product plus additional years). Service Level Agreements (SLAs) should address data retention and portability.

Operational checks (§11.10(f)): The system should enforce proper sequencing of events where required. For example, a regulatory submission should require all required approvals before it can be published.

2. Electronic Signatures (§11.50, §11.70, §11.100–§11.300)

Electronic signatures must be unique to one individual and not reusable. They must include:

  • The printed name of the signer
  • The date and time of signing
  • The meaning of the signature (e.g., "reviewed," "approved," "authored")

For cloud systems, e-signatures are typically implemented as username/password authentication at the moment of signing, with the above information captured and stored as part of the record. Biometric signatures (fingerprint, facial recognition) are also permitted but rare in regulatory operations.

Important: Organizations must notify the FDA that they intend to use electronic signatures as equivalent to handwritten signatures (per §11.100(c)). This is a one-time certification that many organizations overlook.

3. Open Systems (§11.30)

If your system is "open" (meaning access is not exclusively controlled by the organization responsible for the records), additional controls are required, particularly encryption of records during transmission and storage. In practice, most cloud-based regulatory systems operate as "closed systems" because access is controlled by your organization (through account provisioning, SSO, and role-based access), even though the infrastructure is shared.

What to Ask Your Cloud Regulatory Vendor

When evaluating a cloud-based regulatory platform for Part 11 compliance, ask these specific questions:

Audit Trails

  1. Are audit trails immutable? Can any user (including administrators) modify or delete audit trail entries?
  2. What data is captured in each audit trail entry? (User, timestamp, action, before/after values)
  3. How long are audit trails retained? Can they be exported?
  4. Are audit trails maintained during system upgrades and data migrations?

Access Controls

  1. Does the system support unique user identification with no shared accounts?
  2. Is role-based access control available? How granular are the permissions?
  3. Does the system support SSO integration and multi-factor authentication?
  4. How are account lockouts and password policies managed?

Data Integrity

  1. Is data encrypted at rest and in transit? What encryption standards are used?
  2. How is data integrity verified during storage and transmission?
  3. What is the disaster recovery strategy? What is the RPO (Recovery Point Objective) and RTO (Recovery Time Objective)?
  4. Can data be exported in a format that preserves its integrity and metadata?

Validation

  1. Does the vendor provide IQ/OQ/PQ documentation?
  2. Does the vendor support risk-based validation approaches (GAMP 5)?
  3. How are system updates validated? Is there a release validation process?
  4. Is there a shared validation model where the vendor handles baseline validation and the customer handles configuration-specific testing?

Electronic Signatures

  1. Are electronic signatures implemented with unique user authentication?
  2. Are the printed name, date/time, and meaning of signature captured with each e-signature?
  3. Is the link between the e-signature and the signed record maintained securely?

Infrastructure and Continuity

  1. Where is data physically stored? Which cloud region(s)?
  2. Is data isolated between tenants? How is tenant separation implemented?
  3. What is the vendor's business continuity plan? What happens to your data if the vendor ceases operations?
  4. Is the vendor SOC 2 compliant or aligned?

How DnXT Addresses Part 11

DnXT Solutions was designed from the ground up for 21 CFR Part 11 compliance. Here's how the platform addresses each category:

Audit Trails: Every action in DnXT generates an immutable, computer-generated, time-stamped audit trail entry. Entries capture the user, timestamp, action performed, and specific change details (before/after values). Audit trails cannot be modified or deleted by any user, including system administrators. Trails are retained for the required duration and can be exported for inspection purposes.

Access Controls: DnXT uses role-based access control with granular permission configuration that maps to your organizational structure. Every user has a unique account — shared accounts are not permitted. The platform supports SSO integration and enforces configurable password policies. Multi-factor authentication is available.

Electronic Signatures: DnXT implements electronic signatures with unique user authentication, capturing the signer's identity, date/time, and the meaning of each signature. Signatures are securely linked to the signed record and cannot be repudiated.

Data Security: DnXT runs on Microsoft Azure with encryption at rest and in transit. Tenant data is fully isolated with dedicated encryption keys per tenant. The platform aligns with SOC 2 controls for security, availability, and confidentiality.

Validation: DnXT provides IQ/OQ/PQ documentation packages and supports risk-based validation approaches. The platform is designed for CSV compliance, and the DnXT team works with customers to support their validation activities.

Data Retention and Portability: Records are retained throughout the required retention period. Data export capabilities ensure records remain accessible and portable. SLAs address uptime, data availability, and disaster recovery.

EU GMP Annex 11: The European Equivalent

If your organization files submissions with the EMA or national European authorities, you should also be aware of EU GMP Annex 11 (Computerised Systems). Annex 11 covers similar ground to Part 11 but with some differences in emphasis:

  • Risk management is more explicitly required — Annex 11 requires a formal risk assessment as part of the validation lifecycle.
  • Data integrity receives stronger emphasis, including requirements for regular data integrity checks and backup verification.
  • Cloud and outsourced systems are addressed more directly, with requirements for formal agreements between the regulated entity and the service provider.
  • Periodic review of validated systems is required to confirm they remain in a validated state.

Modern cloud-based regulatory platforms that meet Part 11 requirements generally also satisfy Annex 11, but organizations should verify coverage with their vendor and quality team.

The Bottom Line

21 CFR Part 11 compliance for cloud-based regulatory systems is not a barrier — it's a baseline. Modern SaaS platforms like DnXT are built with Part 11 requirements designed into their architecture from the start, often providing stronger controls than on-premise alternatives (where organizations must manage their own infrastructure security, backup, and access controls).

The key is asking the right questions during vendor evaluation and ensuring your vendor can demonstrate — not just claim — compliance with each Part 11 requirement.

→ See DnXT's compliance architecture
→ Request a demo

DnXT Solutions is a 21 CFR Part 11 compliant regulatory operations platform built on Microsoft Azure. We provide cloud-native eCTD publishing, review, and compliance tools for life sciences companies. Learn more at dnxtsolutions.com.

About DnXT Solutions

DnXT Solutions provides cloud-native eCTD publishing, review, and regulatory compliance tools for life sciences companies. With 340+ submissions published and 20+ customers, DnXT is the regulatory platform purpose-built for speed and accuracy.