What regulated QA actually requires
Practice · Regulated Quality Assurance
Regulated QA under ISO 13485 and IEC 62304 is a specific, auditable set of obligations, not more testing: a documented quality system, a safety classification behind every requirement, verification and validation evidenced separately, and a requirements traceability matrix an outside reviewer can follow across all 5 clauses of IEC 62304 life-cycle process.
What does regulated QA require beyond testing?
Regulated QA under ISO 13485 and IEC 62304 is a specific, auditable set of obligations, not more testing. It requires a documented quality system, a safety classification behind every requirement, separately evidenced verification and validation, and a traceability matrix an outside reviewer can follow.
Miss any one of these and the software may work perfectly and still fail an audit.
Four obligations a "we test thoroughly" claim doesn't cover
Most engineering teams already test their software. Regulated QA adds four specific, checkable obligations on top of that — each one independently auditable, each one a place audits actually find gaps.
1. A documented quality system, not tribal knowledge
ISO 13485 and IEC 62304 both require a quality management system that exists independent of any one engineer's memory: who approves a requirement, who verifies a unit, who releases a build, and where the record of each lives. If the process only exists in a senior engineer's head, it does not exist for audit purposes.
2. Risk-based classification before rigor is assigned
Per IEC 62304 §4.3, every MedTech software item gets a Safety Classification (A/B/C) driven by the severity of harm it could contribute to if it failed — determined through an ISO 14971 risk analysis and its hazard analysis, not by how complex the code looks. Classification comes first; it's what tells you how much rigor Clause 5 actually demands for that item.
3. Verification AND validation, evidenced separately
"We tested it" collapses two distinct, separately-required activities into one claim. See Verification vs. Validation in High-Consequence Systems for the full distinction — the short version: verification proves you built the thing right; validation proves you built the right thing. Regulated QA requires evidence of both, not one standing in for the other.
4. A traceability chain a stranger can follow
The single most common MedTech regulated-QA audit finding under IEC 62304 isn't a missing document — it's a broken link in the requirements traceability matrix between a requirement, the design element that implements it, the test that verifies it, and the risk control it satisfies. See Requirements-to-Test Traceability Matrix Guide for how to keep that chain from drifting.
Minimum-viable regulated QA checklist
A working self-check — five yes/no items, each independently auditable.
[ ] A documented quality system names who approves, verifies, and releases
[ ] Every software item has a Safety Classification (A/B/C) with a recorded
rationale traced to an ISO 14971 risk analysis
[ ] Verification and validation are each independently evidenced
(not one used to imply the other)
[ ] Every requirement traces to a design element, a test, and a risk
control -- and that chain is regenerable, not hand-maintained
[ ] A release record exists that references all of the above by ID,
not by narrative summaryEngineering reference only. Not formal regulatory counsel. Consult your own quality system and legal counsel for a specific regulatory determination.
Useful next step
Provenance & review state
- Last reviewed
- Sources
-
- IEC 62304:2006+AMD1:2015 — International Electrotechnical Commission
- ISO 14971:2019 — International Organization for Standardization
- ISO 13485:2016 — International Organization for Standardization
- Ingested from
-