21 CFR Part 11 for cloud and SaaS systems

Part 11 does not change when your records move to a vendor's cloud. The rule binds the persons who use a system, and no contract moves that duty. FDA's 2024 question-and-answer guidance on clinical investigations says it plainly for data hosting and cloud software, platform and infrastructure services: “Regulated entities are responsible for ensuring that electronic records meet applicable part 11 requirements.”

What does change is who does the work. The provider runs the servers, the backups, the product testing and the release train. You decide whether the system fits your intended use, who may get in, how signatures are governed, and whether you can hand an inspector a complete copy of a record from five years ago. Your job is to choose a provider that can carry its half, put that half in writing, and keep evidence that it is carried. Before any of it, confirm the records are Part 11 records at all with the Part 11 applicability checker.

Part 11 sorts systems by one test: who controls access. A closed system is “an environment in which system access is controlled by persons who are responsible for the content of electronic records that are on the system” (§ 11.3(b)(4)); an open system is the same sentence with “not” in it (§ 11.3(b)(9)). Closed systems carry the § 11.10 controls. Open systems carry those controls as appropriate plus the § 11.30 measures, such as document encryption and digital signature standards, from the point a record is created to the point it is received.

FDA called control of access “the most important factor” in the 1997 preamble (comment 41), and it gave cloud teams a sentence they still quote: where records are stored “on systems operated by third parties, such as commercial online services, access would be under control of the third parties and the agency would regard such a system as being open” (comment 44). The same preamble also left the basis for granting access, a “contractual relationship” included, to each firm.

Our reading. A contracted GxP system is not the 1997 commercial online service. Where the agreement puts every account under your approval, the vendor's admin and support accounts included, logs the vendor's access and lets you audit it, the people responsible control access and the system can be called closed. Where nothing in writing covers the vendor's own access, treat it as open. The rule does not settle the contracted case, which is why the open vs closed system check answers it with “depends” and names the terms. The panel below runs six common cloud setups through that same check.

Two things follow whichever way you land. First, the classification is per record flow, not per product: a LIMS can be closed for results at rest and need § 11.30 for the certificates it emails. Second, FDA no longer lets the label decide the security work. Footnote 51 of the 2024 Q&A says that “because of changing technologies and the increased risk of cybersecurity threats, a risk assessment should be conducted for all electronic systems”, open or closed.

FDA's 2024 Q&A lists what to weigh before choosing an IT service provider: the oversight it lets you perform, how it validates the services you will use, whether it can produce accurate and complete copies and give access to data for as long as the records must be kept, its migration, backup, recovery and contingency procedures, its access controls and the SOPs for granting and revoking access, secure time-stamped audit trails, protection of data at rest and in transit, its e-signature controls, and its relevant experience. Read as a split of work, it gives the table below.

The left column never moves, because it is about your records and your intended use. The right column is where a good provider saves you work, and where a poor one leaves you holding gaps you cannot test your way out of. The three rows that cause the most trouble after go-live are data, the audit trail and the exit.

Data ownership means a copy you can produce

Part 11 never uses the word ownership. It asks for “the ability to generate accurate and complete copies of records in both human readable and electronic form suitable for inspection, review, and copying by the agency” (§ 11.10(b)), and for protection that allows “accurate and ready retrieval throughout the records retention period” (§ 11.10(c)). A contract line saying the customer owns its data is worth little if the export leaves the audit trail and the signatures behind. For clinical records FDA puts it as access: the sponsor should have access to all study-related records an IT service provider keeps (2024 Q&A, Q19).

Before go-live, export one closed record end to end, a CAPA with its approvals for example, and open it outside the service:

1. 01The record itself: every field, in the version that was approved, and every earlier version.
2. 02Its metadata: units, instrument or method identifiers, status, the user and time behind each entry.
3. 03The audit trail: who created, changed or deleted what, when, and the old value next to the new.
4. 04The signatures: printed name, date and time, and meaning for each one, still shown with the record (§ 11.50).
5. 05Attachments: the files linked to the record, opened, not just listed.

Watch instrument data in particular. FDA's 2018 drug CGMP Q&A treats a spectral file that can be reprocessed as dynamic, and says a static printout of it “would not satisfy CGMP requirements to retain original records or true copies”. An export that flattens such data to PDF is a copy for reading, not a true copy.

Audit-trail access: read it yourself, and see the vendor in it

§ 11.10(e) asks for “secure, computer-generated, time-stamped audit trails” that record who created, changed or deleted a record, never obscure the old value, and are kept at least as long as the record. In a SaaS system put four questions to the provider. Can your QA read the trail in the application without raising a ticket? Does it record actions taken by the provider's support staff on your tenant? Does it export with the record? Is it kept, and returned, after you leave?

The second question carries the most weight. If support engineers can fix data from the back end and leave no line in your trail, neither your review nor a closed classification holds. Part 11 sets no review frequency; Annex 11 § 9 asks that trails be “regularly reviewed”, and the 2018 drug CGMP Q&A expects people who review a record to review the audit trail that goes with it. The guide to audit trails covers what a good one records, and the audit trail review checklist turns the review into a routine.

Retention outlives the subscription

Part 11 sets no retention period; the predicate rule does. Drug batch records are kept at least one year after the batch's expiration date (§ 211.180); GLP study records for the shortest of two years after approval, five years after submission, or two years after the study ends (§ 58.195). Periods like these can outlast the subscription, so the plan for the years after it ends has to exist on day one. FDA's 2024 Q&A asks for exactly that in the agreement: “A plan that ensures the sponsor will have access to data throughout the regulatory retention period.”

An exit plan names the export format, its scope (records, metadata, audit trails, signatures, attachments), a read-only period while you check it, and who deletes what afterwards. Annex 11 asks that a migration check data are “not altered in value and/or meaning” (§ 4.8) and that archived data be checked for accessibility, readability and integrity (§ 17). FDA's 2003 guidance does not object to archiving in a standard format such as PDF or XML as long as content and meaning are preserved, which is the test the dynamic-data point above applies.

The validation side of the split, from the URS to the summary report, is the subject of the computer system validation guide; this page stays with what the cloud adds to it. When you are choosing the provider, the comparisons of Part 11 eQMS software and LIMS for Part 11 labs read what vendors publish against the same rows.

FDA's 2024 Q&A recommends “a written agreement (e.g., a master service agreement with an associated service level agreement or quality agreement)” with IT service providers, and names three things it should hold: the scope of the work and service, the roles and responsibilities of both sides “including those related to quality management”, and “a plan that ensures the sponsor will have access to data throughout the regulatory retention period”. It adds that sponsors stay responsible for any obligation not specifically and lawfully transferred to the provider. Annex 11 § 3.1 asks for the same in one line: formal agreements with “clear statements of the responsibilities of the third party”.

In practice the commercial contract and the service level agreement cover price, uptime and liability. The quality agreement is the document that carries the GxP terms, and it is the one an inspector will ask for next to your oversight records (Q18). The sheet below is the clause list we would start from. Change the terms at the top and the clauses follow; copy or print it for the negotiation.

Large multi-tenant providers often will not sign a customer's own quality agreement. Then map their standard documents (security addendum, data processing terms, release policy, support access policy) against the sheet, clause by clause, and record each gap in the system's risk assessment with what you do instead: your own scheduled exports, a tighter review of the audit trail, a shorter periodic review. A gap you wrote down and compensated is a decision; a gap nobody noticed is a finding.

GxP-focused SaaS vendors often offer a validation package: some mix of a product validation summary, test evidence from their own release testing, a requirements trace and sometimes scripts you can execute on your tenant. What it contains varies by vendor, so read it before you count on it. Wherever it sits, it is evidence for your supplier file and a head start on your own testing, not your validation. Systems built to keep those supplier files, with their audits and approvals, are read in the supplier quality management software comparison.

The guidance agrees on where it fits. Annex 11 says documentation supplied with off-the-shelf products “should be reviewed by regulated users to check that user requirements are fulfilled” (§ 3.3). FDA's 2024 Q&A says that when an IT service provider performs validation, you may review its development and management processes, validation processes, functional testing, and change control procedures and tracking logs to judge whether the system is fit for purpose (Q7). FDA's CSA guidance goes furthest: a manufacturer can take the developer's own testing and validation work “as the starting point and determine what additional activities may be needed”, and “for some lower-risk software features, functions, and operations, this may be all the assurance that is needed”.

What no vendor pack can cover is anything that is yours: the configuration you chose, the roles you set, the workflows that carry your records, data migrated from the old system, interfaces to instruments, and the procedures around it all. Those are where your test effort goes. The comparison of Part 11 validation software covers tools that run that test execution paperlessly.

FDA's own SaaS example

The CSA guidance works one SaaS case through end to end: a device maker adopting a SaaS product life cycle management system for project records. It is the clearest public statement of how FDA expects a vendor's work and the customer's to fit together.

Note what the vendor carried (product testing, update documentation) and what the manufacturer kept (intended use, risk, the supplier decision, the agreement, configuration checks, the update assessment). That is the split in the table above, in FDA's own words.

Regulation text quoted from the eCFR, the Federal Register and EudraLex; guidance quoted from FDA. Where the text says “our reading”, the rule does not settle the point. General information, not regulatory advice; check what the Part 11 requirements say for your own records.

1. 21 CFR Part 11, Electronic Records; Electronic Signatures, eCFRread 2026-10-22
2. Electronic Records; Electronic Signatures, final rule and preamble, 62 FR 13430 (1997), Federal Registerread 2026-10-22
3. Part 11, Electronic Records; Electronic Signatures: Scope and Application (2003), FDAread 2026-10-22
4. Electronic Systems, Electronic Records, and Electronic Signatures in Clinical Investigations: Questions and Answers (October 2024), FDAread 2026-10-22
5. Computer Software Assurance for Production and Quality Management System Software (2026-02-03), FDAread 2026-10-22
6. EudraLex Volume 4, Annex 11: Computerised Systems (2011), European Commissionread 2026-10-22
7. Data Integrity and Compliance With Drug CGMP: Questions and Answers (2018), FDAread 2026-10-22
8. Letters of Non-Repudiation Agreement, FDAread 2026-10-22
9. 21 CFR Part 211, CGMP for Finished Pharmaceuticals, eCFRread 2026-10-22
10. 21 CFR Part 58, Good Laboratory Practice for Nonclinical Laboratory Studies, eCFRread 2026-10-22