FDA 21 CFR Part 11
Software Compliance in 2026
Electronic records, e-signatures, audit trails, validation, cloud, AI — what Part 11 actually demands of your software, written for engineers
Tamper-evident audit trail
E-signatures bound to one user
CSA-style risk-based validation
By Garvita Amin· Co-Founder & CTO
June 15, 2026 · 16 min read
21 CFR Part 11 is short — about 2,400 words of regulation — but it has eaten more engineering hours in regulated industries than any other single rule. The text talks about electronic records and electronic signatures; what it actually demands is a system that an FDA investigator can interrogate three years from now and still trust. This guide is the engineering translation: what the rule requires, how the controls map to real software, what changed in 2026, and the architecture decisions that let a Part 11 system clear an FDA inspection without an emergency rewrite.
What 21 CFR Part 11 Actually Requires
21 CFR Part 11 is the FDA's rule for trusting electronic records and electronic signatures the same way the agency would have trusted paper and ink. It applies whenever a software system creates, modifies, maintains, archives, retrieves, or transmits a record that an underlying FDA predicate rule (drug manufacturing, device design history, clinical-trial documentation, food-safety records) requires. If the predicate rule says “keep this record,” Part 11 says “here are the conditions under which an electronic version of that record counts.”
For software, that turns into four enforceable controls: a validation program proving the system does what it claims, a tamper-evident audit trail covering every record change, electronic signatures bound to a single individual with intent and meaning captured, and access controls that constrain who can view or change records. The rule itself is technology-agnostic — you can satisfy it on a mainframe, a SaaS, or a serverless app. The audit story is what differs.
Part 11 is not a checklist of features. It is a written argument, signed by a quality unit, that says “here is why the FDA can trust the electronic version of this record.” The software is the easy half; the validation evidence and the procedural controls are where Part 11 programs succeed or fail.
The 2026 lay of the land
Three things have changed the Part 11 landscape since the rule was last amended: the FDA's 2022 Computer Software Assurance draft guidance reframed validation around risk and critical thinking instead of volume of documentation; cloud SaaS became the default deployment model for regulated systems with the agency's tacit approval; and generative AI started appearing in workflows that touch Part 11 records, forcing the industry to build the first AI-in-validation playbooks. The rule text is unchanged, but the lived practice of Part 11 in 2026 looks meaningfully different than it did even three years ago.
Who Has to Follow Part 11 (And Who Thinks They Don’t, But Does)
The clear-cut group is small: pharmaceutical manufacturers, medical-device companies, biotech firms, clinical-trial sponsors and sites, contract research organizations, blood and tissue banks, and food and animal-feed manufacturers regulated by the FDA. If you are one of those, every electronic system touching a predicate-rule record is in scope.
The harder group is everyone selling into them. A SaaS for clinical-trial monitoring, a quality-management system used by a device manufacturer, an e-consent platform deployed at a trial site, an analytics platform parsing manufacturing batch records — the SaaS vendor is not the FDA-regulated entity, but the customer is, and the customer cannot delegate the predicate-rule responsibility. In practice that means Part 11 ends up baked into the SaaS, because the regulated customer needs validation evidence, supplier-audit cooperation, and Part 11-conforming controls from the vendor, contract or no contract.
4
Pillars: records, signatures, audit trail, validation
2003
FDA scope-of-application guidance still in force
2022
CSA draft reframes validation around risk
If your software ever generates a record an FDA-regulated customer keeps, you are in scope
Vendor sales decks love to say “not subject to Part 11 — we are a SaaS.” The FDA does not care about the corporate boundary. If the regulated customer must keep the record under a predicate rule, the vendor must enable that customer's Part 11 compliance — or the customer cannot use the vendor.
The Four Pillars of a Part 11 System
Read against the regulation text, Part 11 compresses into four pillars. Get all four right and the inspection conversation is short.
1. Validated electronic records
Records must be accurate, complete, attributable to a person, and retrievable in human-readable form for the duration of the predicate rule's retention period — often years or decades. The software must demonstrate, through validation, that it produces those records reliably. Practically: every record field that matters has a defined data type, a constraint, a version, and a defined retention rule, and you can prove the system enforces them.
2. Tamper-evident audit trail
Every create, modify, and delete on a controlled record must be captured in a separate, secure, time-stamped log that records who did the action, what changed (old value to new value), when (server-side timestamp), and why (a reason code or free-text reason). The audit trail must itself be tamper-evident: appended only, retained for the same period as the underlying record, and reviewable. The audit-log architecture is the same shape as the one we cover in detail in our HIPAA audit-logging guide — what changes is the contents and the inspection use case.
3. Electronic signatures with intent and meaning
A Part 11 e-signature is more than a click. It must be uniquely bound to one individual, use at least two distinct identification components for enrollment (typically a userid + token or biometric + password), capture the printed name of the signer and the date/time of signing, and capture the meaning of the signature — “reviewed,” “approved,” “authored.” The signature manifestation must travel with the record (printable, exportable). And the user must, separately, sign a one-time certification with the FDA acknowledging that their e-signature is legally equivalent to a handwritten one.
4. Access controls and authority checks
Only authorized individuals can access the system, and the system enforces authority checks — can this person sign this record, can this person change this field, can this person delete this batch. Role-based access control is the standard implementation. The Part 11-specific addition: device-checks for closed systems (the system must verify that the device originating an action is authorized, not just the user) and operational checks for sequence (you cannot approve a record that is not yet authored).
Closed vs Open Systems (The Architecture Decision Most Teams Skip)
Part 11 carves software into two categories that drive different control sets.
Closed systems
A closed system is one where access is controlled by the people responsible for the records in it — typically an internal enterprise application behind SSO, with no anonymous or public access. Almost all enterprise EHR, MES, LIMS, eQMS, eTMF, and CTMS deployments are closed systems. They get the lighter Part 11 control set (§ 11.10).
Open systems
An open system is one where access is not controlled by the records' custodian — for example, a public submission portal, a patient-facing e-consent app reachable over the open internet without enterprise SSO, or any system where records traverse uncontrolled networks. Open systems get the heavier control set (§ 11.30), which adds encryption requirements and digital signatures on records leaving the trust boundary. Algorithm and key-management choices for the encryption layer are covered in detail in our PHI encryption requirements guide — the same primitives satisfy § 11.30 with different documentation.
The architecture cost of getting this wrong is large. Treating a system as closed when it has open-system exposure (e.g., a sponsor-side workflow with patient-side e-consent over the open internet) leaves you with missing encryption and missing record signatures that you cannot retrofit cleanly. Decide closed vs open during requirements, document it in the validation plan, and re-evaluate every time the network topology changes.
The boundary moves when integrations move
A closed system that integrates with a new vendor over a public API may have just crossed into open-system territory for the records that flow over that integration. Each new integration is a closed/open re-evaluation.
Picking a Validation Strategy: CSV, CSA, and Risk-Based Practice
Validation is the part of Part 11 that costs the most and is most misunderstood. The regulation requires that you prove the system does what it claims and stops doing what it claims to stop — nothing more, nothing less. How much evidence that takes depends on risk.
Computer System Validation (CSV) — the legacy approach
CSV is the GAMP 5-derived practice that dominated the 1990s through 2010s. Every release runs through a sequence of qualification protocols — Installation Qualification (IQ), Operational Qualification (OQ), Performance Qualification (PQ) — with exhaustive scripted test cases for every screen and field. CSV produces stacks of documentation. It also slows release cadence to a crawl, often forcing yearly releases on systems that could ship weekly.
Computer Software Assurance (CSA) — the 2022 reframe
CSA, published in the FDA's 2022 draft guidance and broadly adopted since, replaces the volume-of-evidence mindset with critical-thinking and risk-tiered testing. You categorize each system feature by risk to product quality and patient safety, then choose the lightest test method that gives sufficient assurance — scripted testing only for high-risk paths, exploratory or unscripted testing for medium-risk, vendor-supplied or leveraged testing for low-risk infrastructure components. The bar for high-risk paths is the same as it was under CSV; the change is in what you stop over-testing.
| Decision | CSV (legacy) | CSA (2022+) |
|---|---|---|
| Mindset | Document everything | Test what matters, justify the rest |
| Test sequencing | IQ → OQ → PQ scripted | Risk-tiered scripted/unscripted/vendor |
| Vendor testing | Rarely accepted | Leveraged for low-risk components |
| Release cadence | Quarterly or yearly | Sprintly to weekly possible |
| Evidence form | Long printed binders | Risk file + test artifacts in tools |
CSA does not lower the bar; it puts the engineering effort where the risk actually is. Teams that switch usually find they were over-testing the trivial paths and under-testing the genuinely complex ones.
Anatomy of a Part 11 Audit Trail
The audit trail is the artifact every FDA inspector reaches for first. Build it as a first-class, append-only feature, not as a logging side-effect.
Identity. The userid of the actor, captured server-side (never trust client-supplied IDs).
Timestamp. A server-side, time-synchronized timestamp (NTP-locked, UTC stored, displayed in the user's timezone).
Action. A controlled-vocabulary action code: created, modified, deleted, signed, voided, restored.
Record reference. A stable identifier for the record (UUID, not a row-number) plus the field path that changed.
Old and new values. Both pre- and post-change values, in their original data type. Mask sensitive values consistently but log the fact of the change.
Reason. A reason code or free-text reason captured at the moment of change — not derived later.
Integrity proof. A hash chain or signed-log mechanism that lets a reviewer detect any tampering with the audit trail itself.
Common Trap — "The database has triggers, we’re fine"
Database triggers are necessary, not sufficient. A trigger that fires on UPDATE captures the system-level event but typically misses the application-level reason, the user's session intent, and the action type from the user's perspective. The audit trail must capture meaning, not just byte changes.
Retention follows the predicate rule. For drug manufacturing records, that can be one year past expiry plus one year. For clinical-trial source data, the ICH retention is two years after marketing approval or two years after development discontinuation, whichever is later. For medical-device design history, the device's expected lifetime plus two years. The audit-trail-retention question is: what is the longest predicate rule any record in this system feeds, and can you produce the trail through that horizon?
Electronic Signatures That Actually Pass Inspection
The Part 11 e-signature is more procedural than technical, and that is where most engineering teams underestimate it.
Enrollment
Before a user can sign anything Part 11-eligible, they must be enrolled: identity verified, account uniquely bound (no shared logins, ever), and two distinct identification components established (typically userid + password, sometimes biometric + token). The user separately signs a § 11.100(c) certification — a one-time letter to the FDA stating that their e-signature is legally equivalent to a handwritten one. Most large organizations submit this certification once for all users; smaller organizations may submit per-user. Either way, you need a record that the certification exists.
The signing event
At the moment of signing, the system must require both identification components (the user re-enters credentials, even if already logged in, for continuous-signing sessions — § 11.200(a)(1)(ii) allows re-use only within an uninterrupted controlled session), capture the printed name, the date and time, and the meaning of the signature. The signature manifestation must be inseparable from the record — printable and exportable together.
Signature meaning
“Signed” is not enough. Each signing context must declare its meaning — “authored,” “reviewed,” “approved,” “witnessed,” “released for production.” The same record may carry multiple signatures with different meanings. The UI must present the meaning to the user at signing time and the record must store and display it after.
SSO does not replace Part 11 re-authentication
A single sign-on session that holds a user logged in for eight hours does not satisfy Part 11 for signature events. Every signing event in a non-continuous session requires re-authentication. Build the signing component as a modal that prompts for credentials again — do not just check the session cookie.
Part 11 in the Cloud (And Why That Is Now Normal)
The 2003 FDA scope-and-application guidance softened the rigid posture of the original 1997 Part 11 and, combined with two decades of inspection experience, made cloud-hosted Part 11 systems mainstream. AWS, Azure, GCP, and the major SaaS quality and clinical platforms all run thousands of Part 11 instances. What changes in the cloud is the validation story.
Shared-responsibility matrix
You must document, in writing, which controls the cloud provider owns (physical security, hypervisor, network isolation, baseline OS hardening) and which controls you own (application configuration, user provisioning, business-logic audit trail, e-signatures). Most clouds publish a shared-responsibility model; you transcribe it into your validation file with the controls explicit per Part 11 section.
Supplier qualification
The cloud provider becomes a qualified supplier in your quality system. Standard practice: leverage their SOC 2 Type II and ISO 27001 reports as initial qualification evidence, maintain a continued-monitoring file (annual report review, posture changes, incident notifications), and re-qualify on a defined cadence. SOC 2 + ISO 27001 + FedRAMP (for federal-leaning customers) is a typical baseline; do not assume HIPAA-only certifications cover Part 11 controls. If your cloud provider also signs a BAA because PHI flows through the same system, the BAA is a separate contractual instrument from the supplier-qualification file — our BAA vs HIPAA explainer covers that boundary.
Continuous deployment vs frozen baselines
Cloud platforms ship changes continuously. CSA-style risk-based validation lets you absorb those changes through change-impact-assessment workflows rather than freezing the platform version. Set up automated change-feed monitoring (the cloud provider's change log feeds your quality system), risk-tier the change, and run targeted regression on the slice of the system the change touches.
AI/ML and Part 11: The 2026 Frontier
Generative AI and traditional ML now show up inside Part 11 workflows: GenAI drafting deviation summaries, ML models classifying batch defects, LLMs answering quality-engineer questions over the eQMS. The rule has not changed; the interpretation is still being written. The defensible posture for 2026:
AI as draft-assist with human-in-the-loop signing. The model proposes; a qualified human reviews, edits, and applies an e-signature with full meaning. The signature is the Part 11 actor; the model is a tool the human used. This is the safest pattern and the one most regulated companies ship.
AI as autonomous record-writer. The model writes directly to a Part 11 record without human signature. This is technically possible but raises the validation bar sharply — you owe reproducibility, change-control of the model, bias evaluation, and a meaningful argument that the model's output is trustworthy without human review. Few teams have shipped this in 2026.
AI in advisory layers. Search, summarization, “ask your batch record” assistants — the model reads Part 11 records but does not write them. Validate the retrieval boundary (no record is silently modified by the AI flow) and treat it like any other read-only analytics layer.
The architecture pattern that survives audit, regardless of which row you sit in: every AI-touched workflow that ends in a Part 11 record passes through a clinician/quality-engineer review with a Part 11 e-signature, and the audit trail records both the AI's draft and the human's edits as separate events. The full architecture for compliant AI in regulated environments is laid out in our HIPAA-compliant AI guide; the Part 11 add-ons are the e-signature requirement and the model-validation file.
The single biggest 21 CFR Part 11 risk in 2026 is not the technology — it is the workflow where someone says “the AI wrote it” and there is no human signature to point at. Anywhere an LLM's output reaches a controlled record, an e-signature must reach with it.
Where Part 11 Meets HIPAA (And Where It Diverges)
Healthcare software companies often hit Part 11 by surprise, because their HIPAA-compliant stack solves a different problem. The two regimes overlap inside digital health and software-as-a-medical-device, but the controls do not substitute for one another.
| Concern | HIPAA | 21 CFR Part 11 |
|---|---|---|
| Regulator | HHS / OCR | FDA |
| Primary protected interest | Patient privacy | Record trustworthiness |
| Scope | Covered entities + BAs | FDA-regulated industries |
| Encryption | Required (post-2025 update) | Required for open systems |
| Audit log | Access logs | Tamper-evident change log + reason |
| Signature controls | Not central | Core requirement |
| Validation evidence | Risk analysis only | Full validation file |
| Inspection style | Complaint-driven | Scheduled + for-cause |
The overlap zone: a software-as-a-medical-device that runs in a hospital sees both regimes at once. PHI flows trigger HIPAA; the device's electronic record (firmware logs, design history, manufacturing records, post-market surveillance) triggers Part 11. The architectural goal is to share infrastructure (encryption, logging, IAM) and layer the regime-specific controls (BAAs and PHI flow maps for HIPAA, validation files and e-signatures for Part 11) on top — not to run two parallel stacks. For the broader picture of how to satisfy multiple frameworks at once, see our FDA compliance overview.
The Part 11 Software Launch Checklist
Walk this before the first record enters the system. Every line maps to a control an FDA investigator will exercise.
Validation plan written, system risk-tiered, and approved by the quality unit before testing begins
System categorized as closed or open per § 11.10 vs § 11.30, with rationale documented
Tamper-evident audit trail captures identity, timestamp, action, old/new values, and reason on every change to a controlled record
Audit trail retention period meets the longest applicable predicate rule and is enforced in storage policy
E-signature flow re-authenticates at every signing event in non-continuous sessions; meaning of signature is captured and displayed
§ 11.100(c) signature certification on file with the FDA (single org-wide certification is the common path)
Role-based access control matches written user roles; authority checks enforced at the action level, not just the screen level
Operational and device checks in place for sequence-controlled workflows (no approving a record that is not yet authored)
Records exportable in a human-readable form, with audit trail attached, for inspection delivery
If cloud-hosted: supplier qualification file, shared-responsibility matrix, and continued-monitoring evidence in place
Change-control workflow ties code changes to validated requirements; release notes flag Part 11-impacting changes
Training records exist for every user with Part 11 privileges, mapped to procedures they must follow
If AI/ML is in the workflow: model validation file, human-in-the-loop signature, and AI-event logging present
Mistakes That Sink Part 11 Programs
Mistake 1: Treating Part 11 as a feature list
Engineering teams sometimes build “e-signature” and “audit trail” as features, ship them, and assume Part 11 is done. The features are necessary; the validation evidence, written procedures, training records, and quality-unit sign-off are what the inspector actually wants to see. A perfectly engineered system without the validation file fails inspection just as cleanly as a system without the features.
Mistake 2: Conflating SSO session with signature re-authentication
An eight-hour SSO session is fine for most enterprise apps. For Part 11 signing events outside a continuous controlled session, the system must re-prompt for credentials. Skipping this is one of the most common 483 findings.
Mistake 3: Free-text reasons with no controlled vocabulary
Allowing the user to type any reason on a change capture creates an audit trail you cannot analyze and an inspector cannot trust. Provide a controlled vocabulary for common change types (correction, clarification, addendum, reprocess) and reserve free text for unusual cases — with required minimum length.
Mistake 4: Storing audit logs in the same table as the records
An audit trail that lives in the same table as the records it audits gives a deleting actor the ability to also delete their tracks. Separate the audit-log store, restrict write access to an append-only path, and consider a hash-chain or signed-log integrity proof for high-risk systems.
Mistake 5: Letting GenAI write to records without a human signature
Treating an LLM as a Part 11 actor is the fastest way to inherit an unbounded validation burden. Until the FDA publishes clearer guidance on autonomous AI in regulated workflows, ship GenAI as draft-assist with mandatory human-in-the-loop signing and log both events.
Mistake 6: Forgetting the supplier-qualification story for cloud and SaaS dependencies
Investigators will ask how you qualified AWS, Azure, the SaaS your eQMS runs on, the identity provider, the e-signature provider. “They are SOC 2 certified” is not a sufficient answer — you need a written qualification, a continued-monitoring file, and a re-qualification cadence.
Mistake 7: Validating once, never re-validating after change
Validation is not a launch event. Every release with Part 11 impact triggers a change-impact assessment and targeted re-test. Programs that validate at launch and never again rapidly drift out of compliance — the system in production no longer matches the validated specification.
How to Actually Ship a 21 CFR Part 11-Compliant System
Anchor the validation plan in risk, not features
Start the validation file with a written risk assessment: which records are Part 11-controlled, which predicate rules apply, what is the patient-safety and product-quality risk of each. The test plan flows from the risk file. Build risk-first, document-second; CSA gives you cover for this.
Build the audit trail as a first-class service before any record screen
Stand up the append-only audit store, the controlled-vocabulary action codes, the reason-capture middleware, and the integrity proof early. Every record CRUD path then writes to that service. Retrofitting an audit trail onto a shipped system is one of the most expensive Part 11 mistakes.
Treat e-signatures as a workflow primitive, not a checkbox
Implement a reusable signing component that handles re-authentication, meaning capture, name/date stamping, and inseparable record binding. Reuse it everywhere a record needs a signature. Build the § 11.100(c) certification process into onboarding.
Categorize closed vs open at design time and revisit per integration
Document the system boundary in the validation plan, mark each integration point on a diagram, and tag each as inside or outside the controlled-access boundary. Every new integration request triggers a closed/open re-check before the integration ships.
Stand up supplier qualification for every cloud and SaaS dependency
Maintain a qualified-supplier list with the qualification evidence (SOC 2, ISO 27001, vendor questionnaires, contract audit rights) and a continued-monitoring schedule. Automate alert routing for cloud change feeds, security incidents, and compliance attestation expirations.
Move to CSA-style risk-based validation deliberately
Switching from CSV to CSA is a quality-system change, not just a testing change. Update your validation SOPs, train the team, run one pilot system end-to-end under CSA, then roll the practice forward. Cite the FDA 2022 draft guidance in the SOP rationale.
Decide your AI posture in writing, before any LLM feature ships
Pick draft-assist + human signature as the default, define the exceptions, and write the model-validation expectations for any feature that goes beyond draft-assist. Log both AI events and human signing events in the audit trail.
Rehearse an inspection before you need one
Run a quarterly mock inspection: an internal auditor (or external consultant) requests records, audit trails, validation files, training records, supplier-qualification files. The exercise surfaces gaps while you still have time to close them — an FDA inspector finds the same gaps under a clock.
Frequently Asked Questions
What does 21 CFR Part 11 actually require?
Part 11 requires four things from any software touching FDA-regulated electronic records: a validation program proving the system works, a tamper-evident audit trail capturing who-changed-what-when-and-why, e-signatures uniquely bound to one user with intent and meaning captured, and access controls that limit who can view or change records. The technical bar is plain; the validation evidence and procedural controls are where most programs stumble.
Who has to follow 21 CFR Part 11?
Pharmaceutical manufacturers, medical-device companies, biotech firms, clinical-trial sponsors and sites, contract research organizations, and food/animal-feed producers regulated by the FDA. SaaS vendors selling into those markets inherit Part 11 obligations because the regulated customer cannot delegate predicate-rule responsibility — the vendor enables compliance whether the contract names Part 11 or not.
Is 21 CFR Part 11 the same as HIPAA?
No. HIPAA is administered by HHS and protects PHI privacy and security. Part 11 is administered by the FDA and governs the trustworthiness of electronic records and signatures in FDA-regulated industries. They overlap inside digital health and SaMD, but the controls Part 11 demands (validation, audit trails, e-signatures) and HIPAA demands (encryption, access logs, BAAs) are distinct — you need both stacks in parallel.
Can Part 11 software run in the cloud?
Yes. AWS, Azure, and GCP host thousands of Part 11 systems. The validation story changes: you need a qualified-supplier program for the cloud provider, a written shared-responsibility matrix mapping controls between you and the provider, and continued-monitoring evidence as the provider releases changes. Cloud-native Part 11 is normal; cloud-native Part 11 without supplier qualification is what fails inspections.
Does GenAI break 21 CFR Part 11?
It does not break Part 11, but it bends the validation story. The defensible 2026 pattern is AI as draft-assist with a qualified human reviewing and applying an e-signature — the human is the Part 11 actor and the model is a tool. Autonomous AI that writes directly to Part 11 records raises the validation bar sharply: reproducibility, model change-control, bias evaluation, and a written argument that the output is trustworthy without human review. Few teams have shipped that in 2026.
What is the difference between CSV and CSA?
Computer System Validation (CSV) is the legacy document-heavy approach: IQ/OQ/PQ scripted protocols for every release. Computer Software Assurance (CSA), introduced in the FDA's 2022 draft guidance, replaces volume-of-documentation with critical-thinking and risk-tiered testing — scripted only for high-risk paths, lighter methods for lower-risk components. The bar for high-risk paths is unchanged; the saving is on the trivial paths that were previously over-tested.
Is electronic signature the same as digital signature under Part 11?
No. An electronic signature is any electronic data attached to a record signifying the signer's intent — userid+password+meaning captured at signing satisfies Part 11 for closed systems. A digital signature is a specific cryptographic mechanism (asymmetric keys + certificates) — Part 11 § 11.30 requires digital signatures for records leaving an open system. All digital signatures are e-signatures; not all e-signatures are digital signatures.
What is a Part 11 'predicate rule'?
The predicate rule is the underlying FDA regulation that requires the record in the first place — for example, 21 CFR 211 for drug manufacturing, 21 CFR 820 for medical devices, 21 CFR 312 for clinical trials. Part 11 itself does not create record-keeping obligations; it only governs the conditions under which electronic versions of predicate-rule records are acceptable. Always identify the predicate rule before designing the Part 11 controls — retention period, content requirements, and reporting timelines all flow from it.
Ship a 21 CFR Part 11-ready system without rebuilding the compliance stack
VertiComply generates regulated-software code with tamper-evident audit trails, Part 11 e-signature workflows, role-based access, and validation-ready documentation wired in by default — so your engineering team can focus on the science, not the regulatory plumbing.
Audit trail on day one. E-signature flow built in. Validation evidence you can hand to QA.
In This Guide
01
What Part 11 actually requires
02
Who has to follow it
03
The four pillars
04
Closed vs open systems
05
Validation: CSV vs CSA
06
Anatomy of the audit trail
07
E-signatures that pass
08
Part 11 in the cloud
09
AI/ML and Part 11
10
Part 11 vs HIPAA
11
Launch checklist
12
Mistakes to avoid
13
How to actually ship it
14
FAQ
Key Numbers
Part 11 pillars
4
Closed-system controls
§ 11.10
Open-system controls
§ 11.30
FDA signature cert
§ 11.100(c)
CSA draft guidance
2022
Glossary
Topics
Related Articles
Continue reading about regulated-software compliance
How to Build a HIPAA-Compliant Healthcare App Without Code in 2026
Which no-code platforms sign BAAs, ship audit logs, and pass HIPAA out-of-the-box. Real comparison of 7 builders, with PHI-handling gotchas flagged.
Read article
How to Build a Compliant Healthcare App in 2026
The 7 phases of shipping a HIPAA-compliant healthcare app: architecture, vendor BAAs, audit logs, encryption, breach response — with real timelines.
Read article
HIPAA Compliance Checklist for Healthcare App Developers (2026)
The 27-item checklist real healthcare devs ship, mapped to § 164.308–312. Skip the legal boilerplate; this is the build spec.
Read article