FDA's QMS Software Rules: What They Require, and Where Compliance Still Fails

Why Software Doesn't Make You Compliant

There's a comfortable assumption running through a lot of regulated manufacturing right now: once you move off paper and into a quality management system, the compliance risk mostly goes away. The software validates, the workflows enforce sequence, the audit trail writes itself. What could go wrong?

The regulations FDA enforces answer that question directly, and the answer is not what software vendors advertise. A digital system that isn't validated, isn't controlled, or isn't actually used the way its procedures say it's used creates the same exposure as the paper it replaced — sometimes worse, because now there's an electronic audit trail documenting exactly when the gap opened and how long it stayed open.

I want to walk through what the underlying regulations actually require of computerized systems, because the failure patterns that follow only make sense once you see the rule they're measuring against. This isn't a story about bad software. It's a story about the distance between installing a system and operating one under control.

The Regulations These Failure Patterns Are Measured Against

Three regulatory anchors show up again and again whenever FDA scrutinizes a computerized quality system, and each one is specific enough to check yourself.

21 CFR 211.68(b) governs computer and automated equipment in drug manufacturing. It requires that "appropriate controls shall be exercised over computer or related systems to assure that changes in master production and control records or other records are instituted only by authorized personnel" (21 CFR 211.68(b), verified against eCFR), and that input and output be checked for accuracy. This is the clause investigators reach for when a QMS allows records to be altered without an approval step, or when nobody can say who changed a specification and when.

21 CFR 820.70(i) does the equivalent job for medical device manufacturers, requiring that "when computers or automated data processing systems are used as part of production or the quality system, the manufacturer shall validate computer software for its intended use according to an established protocol" (21 CFR 820.70(i), verified against eCFR). Validate here has a specific meaning: documented evidence that the software does what it's supposed to do, under the conditions it will actually be used in, before it goes live.

21 CFR Part 11 sets the standard for electronic records and electronic signatures across FDA-regulated industries. Section 11.10 alone requires:

• Validation of systems to ensure accuracy and reliability
• The ability to generate accurate copies of records
• Protection of records to enable retrieval
• Limiting system access to authorized individuals
• Secure, computer-generated, time-stamped audit trails for record changes

Part 11 became effective August 20, 1997, and it is still the clause most frequently misunderstood by companies that assume "we bought software with an audit trail" satisfies it.

None of these three requirements says "use software." They say: control the software, prove it works, and don't let it become a black box between the record and the person accountable for it. That distinction is where most compliance findings against digital systems live.

Pattern One: Validation That Never Happened

One of the most common software-related compliance gaps is the absence of documented validation before go-live, or after a significant change. FDA has acknowledged part of why this keeps happening. In its September 2022 draft guidance, Computer Software Assurance for Production and Quality System Software, the agency notes that manufacturers have historically over-tested low-risk software features using the same rigor as high-risk ones. That habit slows adoption of new tools. It also has a perverse side effect: some companies skip documented assurance activities altogether rather than absorb the cost of testing everything at the highest tier.

The guidance's core proposal is to right-size validation effort to risk, but it does not remove the requirement to validate. It restates 21 CFR 820.70(i) as the standard and then argues for a more efficient path to meeting it. A company that reads "computer software assurance" as permission to skip documentation has misread the guidance.

Here's an illustrative version of how this plays out: a quality team implements a new QMS module, configures workflows to match existing SOPs, and goes live without a documented protocol showing the configured system does what the SOP says it does. Six months later, a modification changes how a deviation escalates. Nobody re-tests it. An investigator asks for the validation record for that change and there isn't one.

Pattern Two: Access Controls That Exist on Paper But Not in the System

The second recurring pattern is a mismatch between the access control policy and what the system actually enforces. In a typical version of this, a written procedure says only quality assurance can approve a deviation closure. The system, configured during a rushed implementation, lets any user with edit rights close the record. Nobody notices until a batch record review turns up a closure signed by someone outside the approval chain.

Part 11's requirement for "limiting system access to authorized individuals" is not satisfied by a policy document. It's satisfied by role-based permissions that are actually configured, actually tested, and actually reviewed when someone changes roles or leaves the company. This is one of the places digital systems fail in a way paper never could: a paper system requires someone to physically intercept a record to bypass a control, while a misconfigured digital system bypasses itself, silently, every time the workflow runs.

Pattern Three: Audit Trails That Are Incomplete, Disabled, or Never Reviewed

An audit trail that exists is not the same as an audit trail that's reviewed. FDA's expectation under Part 11 is that the audit trail is both generated and available for review, which implies someone is actually looking at it as part of routine quality oversight. A system that logs every change but where no one has ever pulled that log to check for unauthorized edits provides the appearance of control without the substance of it.

This shows up most visibly when a company migrates data between systems, or between paper and digital, and the audit trail breaks continuity. A record's history before the migration lives in one place; its history after lives in another; and reconstructing what happened to a batch across the transition takes days instead of minutes. Vendor-to-vendor cutovers are exactly where this kind of gap opens, because the migration itself is rarely validated with the same rigor as the original system — a problem worth planning around before the cutover starts, not after an investigator asks for a record that spans it.

The Table: Where Paper, Basic Digital, and Validated Systems Actually Differ

It helps to see the failure modes side by side, because "we have a QMS" collapses three very different risk postures into one phrase.

The middle column is where most citations against digital systems originate. It's not the paper systems getting flagged for software failures, obviously, and it's usually not the mature, well-governed digital systems either. It's the systems stuck in between: digitized, but not actually controlled.

Why This Keeps Happening Even to Companies That Bought Good Software

Here's the thing I keep coming back to: the software is rarely the actual point of failure. The gap is almost always in how the software was implemented, configured, and governed after go-live. A validated, well-designed QMS platform can still generate compliance findings if the company treats validation as a one-time event rather than a standing discipline, or if role configuration drifts as staff turn over and nobody re-checks who has access to what.

A quality management system doesn't remove the burden of quality oversight. It relocates that burden, from watching individual paper records to watching the system that produces them. A company that swaps paper for software but doesn't also swap its old assumption — that compliance happens automatically once the right tool is in place — has just moved the same risk into a faster-moving container.

I think the honest framing is that software raises the ceiling on what a well-run quality function can achieve, while doing nothing to raise the floor for a poorly governed one. If anything, an unvalidated or under-governed digital system can fail faster and more invisibly than paper ever did, because nobody is physically handling the record to notice something is wrong.

What These Patterns Actually Tell You to Fix

If you're evaluating your own system against these patterns, the fix isn't buying more software. It's usually three specific, checkable things:

• A documented validation record for the system as configured, and for every significant change since
• Role permissions that are tested against the written procedure rather than assumed to match it
• An audit trail review that's scheduled and actually happens, rather than existing as a theoretical capability

None of that requires enterprise-tier tooling or a six-figure implementation. It requires treating the QMS the way FDA's regulations already describe it: not a record-keeping convenience, but a controlled system that has to prove, on a documented and recurring basis, that it does what it claims to do.

Frequently Asked Questions

Does buying validated QMS software automatically satisfy FDA's computer system requirements? No. Vendor-side validation of the software product is a different thing than the manufacturer's own validation of the system as configured for its specific intended use, which 21 CFR 820.70(i) and 21 CFR 211.68(b) both require. A company still has to document that its configuration, workflows, and integrations work as intended in its own environment.

What is the FDA's Computer Software Assurance guidance and does it replace validation? It's a draft guidance titled Computer Software Assurance for Production and Quality System Software, issued in September 2022. Because it's still a draft rather than final guidance, an investigator can't cite non-compliance with it directly — they cite the underlying regulation, 21 CFR 820.70(i), instead. Practically, that means a company can use CSA's risk-based testing tiers for low-risk features, but still needs a documented rationale for why a given feature was scored low-risk, since that rationale — not the testing itself — is what an investigator will ask to see.

Are audit trail requirements different for drug manufacturers versus device manufacturers? The specific citation differs — 211.68(b) for drug manufacturers, 820.70(i) for device manufacturers — but 21 CFR Part 11's electronic records requirements, including audit trail generation and review under §11.10, apply broadly across FDA-regulated industries when electronic records are used in place of paper.

Can a digital QMS actually create more risk than paper if it's implemented poorly? Yes, in a specific way: a misconfigured access control or an unreviewed audit trail can let a compliance gap run silently for months, because nothing about the system's normal operation surfaces the problem. Paper systems require a person to physically intervene to create the same kind of gap, which tends to make paper failures visible sooner even though they're slower to detect in an audit.

How often should a QMS's access controls and audit trail actually be reviewed? FDA's regulations don't specify a fixed interval, which is itself a common misunderstanding. The obligation is to have a documented, risk-based schedule and to actually follow it — quarterly access reviews and a defined audit trail review cadence are common industry practices, but the citation risk comes from having no schedule at all, not from picking a particular number.

If you're trying to understand what "under control" actually looks like for a digital quality system, or what to check before you switch vendors and inherit someone else's migration gaps, I've written more on what FDA actually expects from a paperless QMS and on how to plan a vendor cutover without breaking record continuity.

Last updated: 2026-09-02