21 CFR Part 820 Software: What Medical Device Teams Need to Know

Overview

21 CFR Part 820 software usually means one of three things: an eQMS platform used to manage quality processes, computerized tools that run inside your quality system, or software that is part of a medical device and falls under design controls. Which meaning applies determines what you buy, how deeply you validate it, and what evidence you keep. The regulation itself, now the Quality Management System Regulation (QMSR), governs your quality system, not any particular tool.

The current text of 21 CFR Part 820 sets device current good manufacturing practice requirements, and the QMSR that amends those requirements took effect in 2026, incorporating ISO 13485:2016 by reference. That change reshaped the structure of the regulation, but it did not turn Part 820 into a software specification. As one practitioner discussion on r/MedicalDevices puts it, quality system regulations like ISO 13485 and 21 CFR 820 do not specify the "how"; they are concerned with the "what."

The short answer

Software can support 21 CFR Part 820 compliance, but no software makes you compliant on its own. Compliance comes from documented procedures, trained people, controlled records, and objective evidence. A tool helps you produce and manage that evidence; it does not substitute for it. Vendors that market "Part 820 compliant" platforms are describing capabilities, not a regulatory status FDA has granted.

Who this guide is for

This guide is written for quality assurance managers, regulatory affairs leads, quality systems owners, document control managers, validation leads, and the engineering and IT owners who support regulated systems. If you are deciding whether you need an eQMS, how much validation a spreadsheet requires, or what evidence an auditor will expect for a cloud-hosted platform, the sections below map those decisions to the regulation.

What 21 CFR Part 820 software can mean

The keyword hides three distinct regulated contexts, and misreading which one applies to you is a common way to over-validate low-risk tools or under-control critical ones. Before evaluating any product, classify what role the software plays relative to your quality system and your device.

QMS software used to manage compliance

The most common meaning is an electronic quality management system: software that manages document control, CAPA, complaints, training records, supplier files, and audit evidence. Vendors in this category, such as Cognidox with its "Lean eQMS" positioning ("A Quality Management System right-sized to your needs," per Cognidox), sell workflow and record-keeping infrastructure for the processes Part 820 requires you to define. The software holds regulated records and executes regulated approvals, so it needs controlled configuration and validation for its intended use.

Software used inside the quality system

The second meaning is broader and easier to miss: spreadsheets that calculate risk scores, databases that track nonconformances, low-code automations that route approvals, and reporting tools that feed management review. These tools may never be labeled "QMS software," yet they can create, modify, or store quality records that Part 820 expects you to control. Your obligation follows the record and the decision, not the product name on the license.

A short worked example shows how this classification plays out in practice. A 20-person device manufacturer inventories its tools and finds a spreadsheet that tracks CAPA due dates and calculates an "overdue" flag with a formula. Inputs: the spreadsheet is the only place CAPA status lives, the overdue flag drives escalation to management review, and three people can edit formulas without review. Constraint: the team has no budget for an eQMS this quarter. Outcome logic: because the spreadsheet determines a compliance-relevant state (CAPA escalation) and holds required records, it needs documented intended use, locked and verified formulas, restricted edit access, a change log, and periodic review, or the CAPA process needs to move into a controlled system. A second spreadsheet that only holds a convenience copy of a training calendar, with the official records kept elsewhere, needs none of that depth. Same tool category, different regulated impact, different control burden.

Software that is part of the device or supports device design

The third meaning is software in or around the device itself: embedded firmware, software as a medical device, and the engineering tools used to develop them. Here the design controls in the regulation apply, covering design inputs, outputs, verification, validation, and change control, with traceability maintained in the design history file. Development toolchains, requirements repositories, and test automation raise their own control questions because their outputs become design evidence. If your device is software-heavy, plan for engineering traceability tooling alongside, not instead of, your QMS platform.

How QMSR and ISO 13485 change the software conversation

The transition from the Quality System Regulation to the QMSR restructured Part 820 substantially. According to Greenlight Guru's analysis, the new Part 820 retains only two of the original 15 subparts that made up the QSR, with the substance now flowing through ISO 13485:2016 incorporated by reference. For software owners, the practical question is whether existing system configurations, terminology, and validation rationales still match the framework your auditors will use.

That question matters most in three places: process names and record labels configured in your eQMS, the risk rationale behind your validation scope, and supplier controls for the software vendors themselves. None of these requires ripping out a working system, but each deserves a documented review against the QMSR structure and the FDA's QMSR resources.

Part 820 still points to controlled processes and reliable evidence

Terminology changed, but the underlying expectation did not. The Johner Institute's QMSR analysis notes that Part 820 requires a complete quality management system in which standard operating procedures are documented and implemented. Whether your records were historically organized as DHF, DMR, and DHR or are now mapped to ISO 13485 documentation structures, you still must demonstrate equivalent control and traceability from design input through complaint closure. Software configured around the old labels does not become noncompliant because of a name, but your procedures, your system configuration, and your records should tell one consistent story.

Risk-based thinking matters for software validation scope

ISO 13485's risk-based language gives you a defensible way to scale validation effort. A module that executes electronic release approvals or changes CAPA status directly affects compliance-critical states and warrants full validation with documented test evidence. A module that generates QR code links to already-controlled procedures is a convenience feature, and a documented low-risk rationale may be enough. The common claim that "all QMS software must always be fully validated" overstates the requirement; what you need is a documented, risk-based justification for the depth you chose, applied consistently across your software inventory.

Software capabilities that support Part 820 quality processes

Part 820 and ISO 13485 define processes, and software earns its place by making those processes controlled, traceable, and retrievable. When you evaluate 21 CFR Part 820 QMS software, map each regulated process to a specific capability rather than accepting a general "compliance" claim. The SG Systems Global glossary frames the regulation plainly: it is about proving you control design, suppliers, production, labeling, complaints, and CAPA.

The core capability mapping looks like this:

• Document control: versioning, approval routing, effective dates, and retrieval
• Design controls: input-to-output traceability, verification and validation records, change impact
• CAPA and complaints: owned workflows, due dates, escalation, effectiveness checks
• Suppliers and training: qualification records, requalification triggers, completion evidence
• Audits and management review: findings, actions, and evidence linked to source records

Treat each item as a requirement you can test during selection, not a checkbox on a vendor datasheet. The subsections below expand the three areas where software fit matters most.

Document control and records

Document control is where most teams start because it underpins everything else: controlled procedures, approved changes, effective-date management, restricted access, retention, and fast retrieval during an inspection. The failure pattern is familiar in any regulated document workflow: reviewers working from stale copies, approvals scattered across email, and no single answer to "which version was effective on that date." Assyro's platform addresses the adjacent submission-document problem with document management that connects SharePoint, Box, and Google Drive, keeps version history aligned, and lets regulatory, quality, and submission teams review against the same version with shared comments, owners, and traceability. If your quality records and your submission documents live in different silos, version drift between them becomes its own audit finding waiting to happen.

Design controls, DHF, DMR, and DHR

Design control software should let you trace a design input to its outputs, verification results, and validation evidence, then carry approved specifications into production records. For software-heavy devices this traceability spans requirements tools, test automation, and risk files, and the design history file must stay reconstructable even when the engineering artifacts live in developer-native systems. Submission preparation stresses the same records: Assyro's medical device solution page cites that 90% of first-submission 510(k) packages receive a Refuse to Accept notice, and its cross-section consistency checks surface mismatches between indications for use, device description, and labeling during drafting rather than during FDA review. The same page describes predicate research with full-text search across 200,000+ cleared devices and side-by-side substantial equivalence comparison tables, which shortens work that previously took a week of database triage. Design control discipline in the QMS and consistency discipline in the submission are two views of the same evidence.

CAPA, complaints, suppliers, training, and audits

These processes share a workflow shape: an owner, a due date, defined approval steps, escalation when things stall, and evidence captured at each transition. Software fit means the tool enforces that shape, records who did what and when, and produces the trend data management review needs without manual re-entry. Watch for the drift problem: configured workflows accumulate customizations over time, and after two years the system may no longer match the written procedure. Periodic reconciliation between SOP text and system configuration should be a scheduled activity, not an audit-eve scramble.

21 CFR Part 820 software versus Part 11 controls

Part 820 and Part 11 answer different questions, and conflating them produces both over-engineering and gaps. Part 820, as the QMSR, defines what your quality system must accomplish: controlled processes, records, and evidence. 21 CFR Part 11 governs how electronic records and electronic signatures are made trustworthy when you rely on them in place of paper records and handwritten signatures. A tool can matter for Part 820 without triggering Part 11, and vice versa.

When electronic records and signatures matter

Part 11 becomes relevant when your regulated evidence exists electronically: an electronic CAPA approval, a digitally signed design review, an audit trail that establishes who released a document. At that point you should expect capabilities such as unique user identity, access controls, time-stamped audit trails, signature manifestation, and reliable record retrieval. Vendor pages such as ComplianceQuest's Part 820 software overview describe meeting Part 11 requirements through secure eSignatures and complete traceability of approvals and actions, which is a reasonable capability description, though you still must confirm those controls work in your configuration.

Avoid blanket Part 11 assumptions

Part 11 obligations attach to actual electronic record and signature use, not to every application on your network. A read-only dashboard that displays data whose official record lives in a controlled system does not carry the same burden as the system of record itself. Equally, a paper or hybrid quality system is not automatically deficient; auditors care whether records are trustworthy and retrievable, whatever the medium. Scope Part 11 analysis record by record, document your conclusions, and resist applying the label as a vague quality stamp on every tool.

How to decide what kind of software you need

Category selection should follow your regulated use cases, team size, and evidence burden, not vendor marketing. Small teams with a handful of documents and one product line face a different problem than a multi-site manufacturer with software-heavy devices and distributed engineering. The matrix below compares the main options by what they are defensible for and where they break down.

No single row is universally correct, and most real installations combine two or three rows. Use the matrix to name your gaps first, then evaluate vendors against the specific rows you actually need.

When controlled spreadsheets may be defensible

Spreadsheets remain defensible for narrow, low-complexity uses: a supplier contact log, a simple training matrix, an equipment list, provided the official records or approvals do not depend on uncontrolled formulas. Defensibility requires a named owner, verified and locked formulas, restricted access, a documented change history, and periodic review. The moment a spreadsheet becomes the system of record for CAPA status, risk scores, or release decisions, its control burden approaches that of a validated system, and a purpose-built tool usually becomes the cheaper option once you count the manual controls honestly.

When eQMS becomes the better fit

An eQMS earns its cost when you manage multiple interacting processes, frequent document changes, cross-functional approvals, distributed teams, or growing audit pressure. The trigger is usually traceability: when you can no longer answer "show me the complaint, the investigation, the CAPA, the change, and the retraining, linked" without a day of manual assembly, workflow software is solving a real problem. Buy for the processes you run today plus the ones your next audit or submission will stress, not for a feature list you will not configure.

When PLM, ALM, or requirements tools are also needed

Software-heavy devices generate design evidence that a general eQMS handles poorly: thousands of requirements, automated test results, iterative architecture changes, and cybersecurity documentation. ALM and requirements management tools maintain requirement-to-test traceability at engineering granularity, while PLM manages product structure and specification change. The integration question then becomes central: how design outputs and change decisions flow into QMS records without manual re-entry, and who owns the boundary. Budget validation effort for the interfaces, not just the individual systems.

How to validate QMS software for regulated use

Validation for regulated use follows a consistent sequence regardless of vendor: define intended use, assess risk, write requirements, review vendor documentation, configure, test, train, go live, and maintain change control. The depth at each step scales with impact, which is why the sequence starts with intended use rather than with a test script template. Resist copying another company's validation package; your configuration, procedures, and risk profile are what make the evidence yours.

Start with intended use and risk

Intended use is a short, specific statement of what the software does in your quality system: which processes it executes, which records it holds, which decisions depend on it. From that statement, assess risk by asking what happens to product conformity and record integrity if the software fails, miscalculates, or is misused. A system executing electronic release approvals sits at the top of the scale; a tool producing convenience views of controlled data sits near the bottom. Document the classification and its rationale, because the rationale is what an auditor will test.

Document requirements, configuration, and test evidence

User requirements translate intended use into testable statements: roles and permissions, workflow rules, approval steps, audit trail behavior, and record retention. Vendor documentation can cover the platform's base functionality, but your local configuration, the specific roles, statuses, and routing rules you set up, needs your own test cases with recorded results, documented deviations, and a formal release decision. Keep the test evidence tied to requirement identifiers so that when a requirement changes, you know exactly which tests to repeat.

Keep validation current after go-live

Validation decays without maintenance. Cloud vendors push updates on their schedule, administrators adjust workflows, and users accumulate permissions they no longer need. Sustaining the validated state means change control on configuration, impact assessment of vendor releases, periodic user access reviews, confirmed backup and recovery arrangements, scheduled periodic review of the whole system, and retraining when workflows change. Treat the validation file as a living record with a review cadence, not a project deliverable filed at go-live.

Vendor qualification for cloud QMS software

When your QMS runs on a vendor's cloud, the vendor becomes a supplier of a regulated service, and your purchasing controls apply. You retain responsibility for the regulated use of the system regardless of where it is hosted, so qualification is about establishing that the vendor's practices support your obligations and that you have contractual and procedural mechanisms to stay in control.

What vendor documents can and cannot prove

Vendor validation packages, security documentation, and certifications are useful inputs: they can demonstrate the platform's base functionality was tested and that the vendor operates a controlled development process. What they cannot prove is that the system works for your intended use, because the vendor did not test your configuration, your procedures, or your data. "Pre-validated" claims deserve particular scrutiny; the gap between the vendor's test scope and your regulated use case is exactly where audit findings live. Use vendor evidence to reduce your testing of base functionality, then focus your own validation on configuration and workflow.

Questions to ask before implementation

A structured question set during selection prevents unpleasant discoveries after contract signature. At minimum, ask:

• How and when are we notified of changes and updates, and can we test before they reach production?
• What does the audit trail capture, and can we export it in a readable, durable format?
• How do we export all records and metadata if we leave the platform?
• What access controls, authentication options, and role granularity are available?
• How are incidents, outages, and data integrity events communicated and documented?
• What validation support documentation is provided, and what does it actually cover?

Record the answers as part of your supplier qualification file, and revisit them at requalification. Vendor answers that were true at purchase can drift as the product and the company evolve.

Failure modes software can create if controls are weak

Software does not only manage compliance risk; it can manufacture new risk when configuration, procedures, and review are weak. The scenarios below recur in practice, and each one begins with a tool that looked compliant on the demo.

Unvalidated spreadsheets and macros

A macro that aggregates CAPA metrics for management review gets edited to "fix" a date format, and the change silently excludes overdue records from the escalation count. No one reviews the formula change because the spreadsheet was never classified as a regulated system. Months later, an auditor traces a late CAPA that never escalated and finds the root cause in an uncontrolled formula. The lesson is not that spreadsheets are banned; it is that any logic that alters regulated data, risk scores, effectiveness metrics, release states, needs verification and change control proportionate to its impact.

Misconfigured permissions and workflow rules

Role misconfiguration undermines the very evidence the system exists to create. If an author can approve their own documents, if a status can jump from draft to effective without the required review step, or if a departed employee's account still holds approval rights, the audit trail records transitions that your procedure prohibits. These failures are testable: validation should include negative tests that confirm prohibited actions are actually blocked, and periodic access reviews should confirm the role model still matches reality.

Hybrid paper and electronic records

Hybrid systems fail at the seams. Part of a design history lives in the eQMS, verification reports sit on a shared drive, a wet-signed approval exists only in a binder, and a complaint investigation ran partly over email. Each fragment may be individually controlled, yet no one can produce the end-to-end record from design input to complaint closure when an inspector asks. Hybrid operation is legitimate, but it demands an explicit record map: which record lives where, who owns it, and how the pieces link. When general-purpose email or chat becomes the de facto CAPA channel, that map has already broken.

Audit-ready evidence to keep for Part 820 software

When an auditor examines software used in your quality system, two evidence sets are in scope: evidence about the software system itself and evidence produced by the quality processes it supports. Keeping both organized and retrievable is what turns a stressful inspection request into a routine retrieval task.

Evidence for the software system

For each regulated system, maintain a coherent file containing:

• Intended use statement and risk assessment with classification rationale
• Approved user requirements and configuration specifications
• Validation plan or documented rationale for reduced depth
• Test cases, results, deviations, and the formal release decision
• Supplier qualification records for the vendor
• Change history covering configuration changes and vendor updates
• Periodic access review records and system periodic review reports

Store these where they can be produced quickly, and keep them current through change control rather than reconstructing them before audits. A validation file that ends at go-live tells an auditor the validated state was not maintained.

Evidence for the quality process

System evidence proves the tool is controlled; process evidence proves the work was done correctly inside it. For any software-supported record, you should be able to show who performed each action, when, under which effective procedure, with what approval, and how the result traces to related records such as the originating complaint or the affected design output. If the software's audit trail, record links, and version history answer those questions without manual archaeology, the system is doing its job. If reconstructing one CAPA lifecycle requires exports from three systems and a folder of emails, that gap is the finding.

Practical next steps

The path from this article to a defensible position does not start with a purchase. It starts with knowing what software you already rely on, classifying its regulated impact, and closing the largest gaps first. Selection, configuration, validation, migration, training, go-live, and periodic review then follow in order, each producing records as it goes.

Build a software inventory first

List every system that touches quality processes or records: the eQMS or document repository, spreadsheets and databases, low-code automations, reporting tools, engineering and requirements platforms, and any communication channel where regulated decisions actually happen. For each, capture what it does, which records depend on it, who owns it, and what controls exist today. The inventory is what surfaces tools doing regulated work that no one has classified. Where submission documents intersect the inventory, tools like Assyro's free eCTD validator, which runs 358 CFR, ICH, and FDA Technical Conformance Guide structural checks across Modules 1 through 5 entirely in-browser with no files leaving the device, illustrate how validation checks can move earlier in a workflow instead of waiting for a final gate.

Prioritize the systems that affect evidence and product conformity

Effort should follow impact. Systems that execute approvals, determine release or escalation states, hold required records, or feed design and production decisions get validated first, with the deepest controls. Convenience tools get a documented low-risk rationale and a lighter touch. That prioritization is the core discipline behind every section of this guide: 21 CFR Part 820 software is not a product category you buy your way into compliance with, it is any software whose behavior affects your regulated evidence, and it deserves control proportionate to that role. Classify honestly, validate for your intended use, keep the evidence current, and the software becomes an asset in the audit room rather than a liability.