Regulated Quality Systems: FDA QMSR and ISO 13485:2016

Consequential GRC Engineering

Quality management system engineering for medical device software under the FDA Quality Management System Regulation (QMSR, 21 CFR Part 820, effective February 2, 2026), which incorporates ISO 13485:2016 by reference. We build IEC 62304 software lifecycles, ISO 14971 risk management and IEC 62366-1 usability engineering into the way your team already works, and leave a design and development file your quality organization can stand behind.

FDA QMSR (21 CFR 820, Feb 2026) ISO 13485:2016 §7.3 IEC 62304 · ISO 14971 IEC 62366-1

The Customer Problem: Four QMSR Transition Gaps

The February 2, 2026 line

FDA now inspects under the Quality Management System Regulation. An ISO 13485 certificate does not exempt a manufacturer from FDA inspection.

Records under retired names

Procedures and records still use the former Part 820 vocabulary, while QMSR expects the ISO 13485 structure: a Design and Development File and a Medical Device File.

Risk management in pockets

ISO 14971 work lives in design controls. QMSR expects documented, risk-based decisions across suppliers, records, labeling and post-market activity.

Newly inspection-visible records

Internal audits, management reviews and supplier audits are now within FDA inspection scope, and labeling and packaging controls have their own section (21 CFR 820.45).

The Consequential Solution: Executable Design Controls

Design controls kept as linked records rather than documents assembled at the end. Each design input points to the risk controls it carries, the software requirements that implement it and the verification that proves it, so the design and development file is regenerated from the work, not reconstructed after a design freeze.

The QMSR and ISO 13485:2016 record structure
Record ISO 13485:2016 clause What it holds
Design and Development File (DDF)§7.3.10Design inputs and outputs, reviews, verification, validation, transfer and changes for one device or family, with the history of changes kept.
Medical Device File (MDF)§4.2.3The device description, specifications, production and service procedures, labeling and the records that show conformity.
Production and service records§7.5What was built or serviced, when, by whom and against which version of the specification.

Existing design history content does not have to be recreated: QMSR expects it to be mapped and structured under the ISO 13485 terms.

What Netspective Offers: Engineering Responsibility

QMSR readiness gap assessment

An inspection-oriented review of your quality system documents, records and terminology against QMSR and ISO 13485:2016.

DDF and MDF structure

Design and development files (§7.3.10) and medical device files (§4.2.3) structured for reviewer traceability, with existing content mapped in.

IEC 62304 lifecycle and traceability

Software lifecycle processes and requirement-to-test traceability, using Qualityfolio to keep tests and evidence in Git.

Risk across the quality system

ISO 14971 risk management extended to suppliers, labeling and post-market activity; usability engineering under IEC 62366-1 through Human Factors Engineering.

Technical Architecture: The Design Trace Chain

  1. Design inputISO 13485:2016 §7.3.3
  2. Risk controlISO 14971, for a named hazard
  3. Software requirementIEC 62304 §5.2
  4. Verification§7.3.6, a dated record per cycle
  5. Design and Development File§7.3.10, compiled from the links
Each link is a field in a version-controlled record, so a reviewer can follow a design input to its evidence. Validation (§7.3.7) and usability evidence join the same file.

Where QMSR widens risk expectations

What changes under QMSR, and the evidence that answers it
Area What QMSR expects Evidence we build
Scope of riskRisk management across the whole quality system and product lifecycle, not only design controls.A risk file linked to suppliers, labeling and post-market records.
DecisionsDocumented, risk-based decisions with controls scaled to risk and monitored.Decision records that name the risk and the control they rely on.
SuppliersEvaluation plus ongoing, risk-based performance monitoring.Supplier records with criteria, monitoring results and dates.
Records and auditsInternal audits, management reviews and supplier audits within inspection scope.Audit and review records kept accessible and traceable.
Labeling and packaging21 CFR 820.45 controls: UDI, expiration date, storage, handling and processing instructions.Label records checked for each required element.

Design Trace Explorer

Four steps from a Markdown design record to questions an inspector can ask again. All data here is illustrative.

Panel 1: A design input traced in Markdown

One design input with its risk control, software requirement and verification evidence, in the public Qualityfolio format.

---
doc-classify:
  - select: heading[depth="1"]
    role: project
  - select: heading[depth="2"]
    role: case
  - select: heading[depth="3"]
    role: evidence
---

# Infusion Rate Calculator: Design and Development File (illustrative)
@id ddf-example

## DI-014: Rate entry rejects values above the configured maximum
@id TC-DI-014

```yaml META
  requirementID: DI-014        # design input, ISO 13485:2016 §7.3.3
  riskControl: RC-031          # ISO 14971 risk control for hazard H-007
  softwareRequirement: SRS-112 # IEC 62304 §5.2 software requirement
  Priority: High
```

### Evidence
@id TC-DI-014

```yaml META
  cycle: 2.0
  cycle-date: 2026-10-12
  assignee: Verification engineer
  status: passed
```

- [Verification record](./evidence/TC-DI-014/2.0/result.auto.json)

Synthetic illustration Synthetic: no client data. It uses the public Qualityfolio Markdown structure to show the chain design input → risk control → software requirement → verification evidence. Field names beyond requirementID are illustrative.

Panel 2: Compile the records into SQLite

The records and their evidence files become one queryable database and a local dashboard.

# Parse the records and evidence into resource-surveillance.sqlite.db
spry rb run qualityfolio.md

# Serve the dashboard on this machine only
surveilr web-ui -d ./resource-surveillance.sqlite.db --port 9227 --host localhost

Writes: resource-surveillance.sqlite.db. Commands from the public Qualityfolio documentation, bound to localhost.

Panel 3: Design inputs without passing verification

Each design input with its risk controls and verification records; unverified and failing inputs come first.

-- Synthetic illustration: design inputs traced to risk controls and
-- verification, ISO 13485:2016 §7.3. Each table stands in for records in your
-- design and development file.
CREATE TABLE IF NOT EXISTS design_input (input_id TEXT PRIMARY KEY, title TEXT NOT NULL);
CREATE TABLE IF NOT EXISTS risk_control (control_id TEXT PRIMARY KEY, hazard_id TEXT NOT NULL, input_id TEXT REFERENCES design_input (input_id));
CREATE TABLE IF NOT EXISTS verification (
  record_id TEXT PRIMARY KEY,
  input_id  TEXT NOT NULL REFERENCES design_input (input_id),
  status    TEXT CHECK (status IN ('passed', 'failed', 'blocked')),
  run_date  TEXT
);

SELECT d.input_id,
       d.title,
       group_concat(DISTINCT r.control_id)             AS risk_controls,
       COUNT(DISTINCT v.record_id)                     AS verification_records,
       COALESCE(MAX(v.run_date), '-')                  AS last_run,
       CASE
         WHEN COUNT(v.record_id) = 0 THEN 'not verified'
         WHEN SUM(v.status = 'passed') = 0 THEN 'no passing record'
         ELSE 'verified'
       END                                             AS trace_status
FROM design_input d
LEFT JOIN risk_control r ON r.input_id = d.input_id
LEFT JOIN verification v ON v.input_id = d.input_id
GROUP BY d.input_id, d.title
ORDER BY CASE trace_status WHEN 'not verified' THEN 1 WHEN 'no passing record' THEN 2 ELSE 3 END, d.input_id;

Synthetic illustration Table names are illustrative, not a Qualityfolio schema. Runs as written in SQLite 3.

Panel 4: Label records missing a required element

Label records checked against the elements 21 CFR 820.45 names.

-- Synthetic illustration: label records missing an element 21 CFR 820.45
-- asks to be checked (UDI, expiration date, storage, handling and processing
-- instructions). label_record stands in for your labeling records.
CREATE TABLE IF NOT EXISTS label_record (
  label_id   TEXT PRIMARY KEY,
  device     TEXT NOT NULL,
  udi        TEXT,
  expiration TEXT,
  storage    TEXT,
  handling   TEXT,
  processing TEXT
);

SELECT label_id,
       device,
       trim(
         CASE WHEN udi        IS NULL OR udi        = '' THEN 'UDI '        ELSE '' END ||
         CASE WHEN expiration IS NULL OR expiration = '' THEN 'expiration ' ELSE '' END ||
         CASE WHEN storage    IS NULL OR storage    = '' THEN 'storage '    ELSE '' END ||
         CASE WHEN handling   IS NULL OR handling   = '' THEN 'handling '   ELSE '' END ||
         CASE WHEN processing IS NULL OR processing = '' THEN 'processing ' ELSE '' END
       ) AS missing
FROM label_record
WHERE missing <> ''
ORDER BY device, label_id;

Synthetic illustration A check of record completeness, not of label content or legibility. Runs as written in SQLite 3.

Verified Proof Ledger (Engineering Ground Truth)

Proof ledger: each claim, its status and what it rests on
Claim Status What it rests on
Markdown test and trace records compiled into SQLite with a traceability dashboardBuilt and testedThe public Qualityfolio repository and documentation.
Design and development file trace fields beyond requirementIDDesignedThe synthetic illustration on this page; the record schema is set per engagement.
QMSR readiness gap assessment methodDesignedDelivered per engagement against QMSR and ISO 13485:2016; no public tool.
FDA clearance, inspection or audit outcomeNot establishedFDA, notified bodies and auditors decide. We claim no outcome.
A replacement for regulatory counsel or your quality organization's sign-offNot establishedEngineering and documentation support; approval stays with your quality system.
21 CFR Part 11 compliance of the tooling itselfNot establishedPart 11 controls belong to the validated process the tools run in.

Real-World Scenarios

FDA, notified bodies and auditors decide every outcome. These are the records we help build.

A SaMD start-up before its 510(k)

IEC 62304 Class B software gets a design and development file whose design inputs trace to risk controls and verification records.

An established manufacturer re-mapping records

Records kept under the former Part 820 structure are mapped into DDF and MDF form without recreating historical design work.

Supplier oversight by risk

Supplier evaluation extended to ongoing monitoring, with criteria and results kept as records an inspector can follow.

Scoped Pilot: The 2-Week QMSR Readiness and DDF Gap Analysis

What the two weeks deliver

Week 1: assess

Review quality system procedures, records and terminology against QMSR and ISO 13485:2016, with inspection-visible gaps marked.

Week 2: trace

Trace one design input end to end into a DDF structure, then deliver a prioritized gap list your team can act on.

Boundaries

  • Engineering reference and documentation support, not formal legal or regulatory counsel.
  • FDA, notified bodies and auditors decide clearance and audit outcomes; we guarantee neither.
  • Your quality system stays yours: we build records into it; we do not operate it for you.
Submission or market

Please don't attach design records or submission files to the first message; we agree how they move during scoping.

Just start a conversation

Engagement detail

What does Netspective regulatory consulting cover?

It covers FDA strategy across the 510(k), PMA, and De Novo pathways, HIPAA program design, quality management system build-out, NIST and FedRAMP authorization support, and ISO 14971 risk management. Each engagement produces documentation a reviewer can act on, delivered by a named engineer.

Four commitments that hold across every engagement

FDA Strategy
510(k), PMA, and De Novo pathway selection grounded in device classification and predicate history.
Quality System Design
QMSR/ISO 13485 quality systems built for audit, not assembled after one is scheduled.
Risk Management
ISO 14971 risk files linked to verification records, not maintained as a standalone binder.
Submission Traceability
Requirement-to-evidence traceability a federal reviewer can actually follow.

Regulatory frameworks we specialize in

  • FDA QMSR (21 CFR 820)
  • ISO 13485
  • ISO 14971
  • IEC 62304
  • HIPAA
  • NIST SP 800-53
  • FedRAMP
  • SOC 2
Regulatory submission readiness architecture Four-stage flow: Pre-Submission Strategy, then Design Controls and QMS, then Verification and Validation, then Premarket Filing, connected by directional arrows, with a dashed perimeter marking the quality-system boundary around the design controls and V&V stages. QUALITY SYSTEM BOUNDARY Pre-Submission Strategy Predicate Analysis Pre-Sub (Q-Sub) Meetings Design Controls & QMS ISO 13485:2016 §7.3 former 21 CFR 820.30 Verification & Validation ISO 14971 Risk Controls DDF Traceability Premarket Filing 510(k) / PMA / De Novo Reviewer-Ready Dossier
ARCH-SPEC 01: Regulatory Submission Readiness Architecture

Six regulatory programs

FDA Regulatory Pathways

510(k), PMA, and De Novo submission strategy mapped to a specific device classification and predicate history.

  • 510(k) Predicate Analysis
  • PMA Clinical Strategy
  • De Novo Classification
  • Pre-Submission (Q-Sub) Meetings

QMS Design (QMSR / ISO 13485)

Quality management system build-out under the FDA QMSR harmonization with ISO 13485, from document control to internal audit. See FDA QMSR Design Controls for the governing standard.

  • Design Controls (ISO 13485:2016 §7.3 / former 21 CFR 820.30)
  • Document Control
  • CAPA Process Design
  • Internal Audit Program

ISO 14971 Risk Management

Risk management files built to ISO 14971:2019, linked to verification records instead of maintained as a standalone binder.

  • Risk Management Plan
  • Hazard Analysis
  • Risk Control Verification
  • Residual Risk Evaluation

Technical Documentation (Medical Device File & Design and Development File)

Medical device files (ISO 13485:2016 §4.2.3) and design and development files (§7.3.10) structured for reviewer traceability, the records FDA QMSR now relies on in place of the former Part 820 record types, not reconstructed after a design freeze.

  • Design and Development File (ISO 13485:2016 §7.3.10)
  • Medical Device File (ISO 13485:2016 §4.2.3)
  • Design Traceability Matrix
  • Design Change Records (§7.3.9)

HIPAA Compliance Programs

HIPAA Security Rule compliance program design — administrative, physical, and technical safeguards mapped to an organization's actual systems. See HIPAA Engineering Practices.

  • Security Risk Assessment
  • Business Associate Agreements
  • Breach Notification Procedures
  • Workforce Training Program

NIST & FedRAMP Authorization

Federal authorization support for FedRAMP (NIST SP 800-53 Rev. 5 baselines) and secure software development attestation (NIST SP 800-218 SSDF), from control mapping through continuous monitoring.

  • NIST SSDF Control Mapping
  • FedRAMP SSP Authoring
  • Continuous Monitoring Setup
  • POA&M Management
SOC 2 TYPE 1 & 2 ATTESTED FDA QMSR / 21 CFR 820 ISO 14971 HIPAA SECURITY RULE

Ready to Build?

Discuss which regulatory program applies to a specific engagement.

Engineering reference only. Not formal regulatory counsel. Consult your own quality system and legal counsel for a specific regulatory determination.

Sign in or sign up

Enter your email to receive a temporary sign-in link.

By continuing, you agree to our Terms of Service and Privacy Policy.