IEC 62304: Software Safety Classes, Lifecycle Deliverables, and SOUP Requirements

IEC 62304 is the software lifecycle standard for medical device software. LAC Health’s standards glossary has a shorter IEC 62304 reference aimed at device buyers rather than developers. It does not tell you whether your software is a device — that is a SaMD classification question, answered separately. IEC 62304 assumes the answer is already yes, and tells you what development, maintenance and configuration-management records you must be able to produce, scaled by a software safety class you assign yourself.

Two things trip teams up more than anything else in the standard, and both are covered in depth below: safety classification changed materially in Amendment 1, so guidance written against the 2006 text is wrong; and every third-party and open-source component you pull in is SOUP, which carries a specific, clause-level documentation obligation that a lockfile does not satisfy.

The edition that actually applies

There is one active edition and it has a confusing number of names:

• IEC 62304:2006 — the original, Medical device software — Software life cycle processes.
• IEC 62304:2006/AMD1:2015 — Amendment 1, published June 2015. This is not a cosmetic revision; it rewrote the safety-classification rule in clause 4.3 and added clause 4.4 on legacy software.
• IEC 62304 Edition 1.1 (2015-06) — the consolidated version, base standard plus Amendment 1 in one document. This is what you should actually buy.
• ANSI/AAMI/IEC 62304:2006/A1:2016 — the identical US adoption. Note the year: the international amendment is dated 2015, the ANSI/AAMI adoption of that same amendment is dated 2016. They are the same technical content, and FDA treats them as interchangeable.

FDA recognises the standard in full. Per FDA’s Recognized Consensus Standards: Medical Devices database, the record reads:

• Recognition number 13-79, Federal Register recognition list 051
• Date of entry 14 January 2019
• Extent of recognition — Complete standard. There are no FDA carve-outs, exclusions or deviations attached to this recognition, and the Supplementary Information Sheet lists no FDA-specific supplemental requirements — only related guidance documents.
• Standard as recognised — IEC 62304 Edition 1.1 2015-06 consolidated version, with ANSI/AAMI/IEC 62304:2006/A1:2016 listed as the identical adoption.

The practical consequence: when a US premarket submission refers to “the FDA-recognized version of IEC 62304”, it means Edition 1.1 — the 2006 base plus Amendment 1. If your quality system still cites bare “IEC 62304:2006”, your classification rationale is being written against superseded text. See FDA recognized consensus standards for how the recognition mechanism and Declarations of Conformity work generally.

On the standard’s text. IEC 62304 is copyrighted and is not reproduced here. This page cites clause numbers and describes what each clause requires; the standard’s own table of which requirements apply to which safety class is the authority and you need the purchased document to work from it. Buy it from the IEC Webstore or from ANSI/AAMI. (ISO’s and IEC’s own catalogue pages are frequently unreachable from automated tooling; the FDA database above is the freely-accessible authority for which edition applies in the US.)

What IEC 62304 is not, and what it presumes you already have

62304 is a narrow standard that leans hard on two others. Clause 4 establishes the general requirements before any lifecycle process starts:

• Clause 4.1 — a quality management system. The manufacturer must have one. In practice that is ISO 13485, which supplies document control, design controls, CAPA, supplier controls and management responsibility. 62304 does not restate any of that; it sits inside a 13485 QMS and assumes those controls exist. In the US the same expectation now arrives through the QMSR in 21 CFR Part 820, which incorporates ISO 13485:2016 by reference.
• Clause 4.2 — a risk management process complying with ISO 14971. This is the load-bearing dependency. You cannot assign a software safety class without a hazard analysis, because the class is defined in terms of hazardous situations and the acceptability of risk after risk control. ISO 14971 produces that input; 62304 consumes it.
• Clause 4.3 — software safety classification. See the next section.
• Clause 4.4 — legacy software. Added by Amendment 1. See below.

Equally important is what the standard explicitly excludes. FDA’s own summary of the scope in its recognition record puts it plainly: the standard “does not cover validation and final release of the medical device, even when the medical device consists entirely of software.” 62304 governs the software lifecycle up to software release. Device-level validation, clinical evaluation and market release sit outside it, under the QMS and the relevant regulatory pathway — which is why a 62304 Declaration of Conformity is never a substitute for a 510(k) or De Novo submission.

Safety classification: what Amendment 1 changed, and why it matters

This is the single most consequential difference between the 2006 text and the edition in force, and it is why third-party blog posts about 62304 are so often wrong.

The 2006 test — severity only

The original clause 4.3 assigned a class purely on the severity of possible harm: Class A where no injury or damage to health was possible, Class B where non-serious injury was possible, Class C where death or serious injury was possible.

The Amendment 1 test — contribution to a hazardous situation, assessed after external risk controls

Amendment 1 replaced that with a two-limb test. A software system is Class A if it cannot contribute to a hazardous situation at all, or if it can contribute to a hazardous situation but the resulting risk is acceptable after risk control measures external to the software system are taken into account. Where the risk is not acceptable after external controls, severity of the resulting harm then separates Class B (non-serious injury possible) from Class C (death or serious injury possible).

The three consequences teams miss

1. The bare “no injury is possible” route is gone. Under the 2006 wording you could assert Class A directly from a severity judgement. Under Amendment 1 you must show either that the software cannot contribute to a hazardous situation at all, or that a documented, non-software risk control brings the residual risk to acceptable. A Class A claim is now an output of the ISO 14971 file, not an assertion in a software plan.
2. External means external. The escape route is explicitly risk control measures external to the software system — a hardware interlock, a mechanical limit, an independent monitoring circuit, a procedural control. A second software module inside the same software system is not an external risk control. This is the point most Class A rationales fail on: teams cite an internal watchdog or a validation routine in their own code and call it a risk control.
3. The probability of software failure is assumed to be 100%. This carried over from 2006 and survives in the amended text. You may not argue a lower class on the grounds that the software is unlikely to fail — reliability arguments, test-coverage figures and field-history data do not reduce the assumed failure probability for classification purposes. Only severity and external risk controls move the class. Where teams try to negotiate a class downwards, this is the rule that stops them.

The offsetting effect is real and worth stating: because external risk controls now count, a piece of software whose failure could theoretically contribute to injury can legitimately be Class A where a hardware or procedural control makes the residual risk acceptable. Amendment 1 did not simply make classification stricter — it made it evidence-based in both directions. What it removed was the ability to reach Class A without an argument.

Decomposition and segregation

Classification applies to the software system, but the standard allows software items within it to carry different classes. The default is unforgiving: a software system takes the classification of its highest-classified software item unless you document that the items are adequately segregated, and the architectural-design requirement covering segregation for risk control (clause 5.3.5) is itself a Class C requirement. In practice this means you cannot informally declare “the UI is Class A and the pump driver is Class C” — you must design and document the segregation, including the mechanism that makes it effective, and verify it.

The realistic strategy for most device software is therefore to classify the whole system at the highest class you can justify cheaply, and only invest in a segregation architecture when the delta in required deliverables genuinely pays for the design and verification work it creates.

Deliverables by safety class

The following maps the standard’s processes to the classes that require them. Clause numbering follows Edition 1.1. Sub-clause-level applicability varies within some of these processes and the standard’s own table is the authority — treat this as the planning-level map, not a substitute for the document.

Clause / process	Class A	Class B	Class C
4.3 Software safety classification	Required	Required	Required
5.1 Software development planning	Required	Required	Required
5.2 Software requirements analysis	Required	Required	Required
5.3 Software architectural design	—	Required	Required
5.4 Software detailed design	—	—	Required
5.5 Software unit implementation and verification	Implementation only	Required	Required (with additional acceptance criteria)
5.6 Software integration and integration testing	—	Required	Required
5.7 Software system testing	—	Required	Required
5.8 Software release	Required	Required	Required
6 Software maintenance process	Required	Required	Required
7 Software risk management process	—	Required	Required
8 Software configuration management process	Required	Required	Required
9 Software problem resolution process	Required	Required	Required

What that means as a document set

Class A is not “no documentation”. You still owe a software development plan, a software requirements specification, a release record (including documented known residual anomalies), a maintenance plan, configuration management including a SOUP inventory, and a problem resolution process. What you do not owe is architecture, detailed design, unit verification records, integration testing or system testing documentation, or the software-specific risk management activities of clause 7.

Class B adds the architecture, the unit verification and integration/system testing evidence, and the whole of clause 7 — which is where the SOUP anomaly-list obligation lives.

Class C adds detailed design down to the unit level, verification of that detailed design, additional unit acceptance criteria, and the segregation requirements if you are relying on segregation.

Notice the shape of that: the jump from A to B is the expensive one, because it brings in both the full V-model verification chain and clause 7. The jump from B to C is comparatively incremental — detailed design and a tighter unit-level bar. Teams often plan as though C is the cliff. It is not; B is.

SOUP: the requirement that catches open-source users

This is the part of 62304 that surprises software teams, because it has no analogue in ordinary commercial software engineering.

What counts as SOUP

SOUP is software of unknown provenance (also rendered “unknown pedigree”). The standard’s definition, at clause 3.29, covers two distinct cases:

1. A software item that is already developed and generally available, and was not developed for the purpose of being incorporated into this medical device. This is the obvious case: your operating system, your TLS library, your JSON parser, your charting component, your database driver, your container base image, every transitive dependency underneath them.
2. Software previously developed by you for which adequate records of the development process are not available. This is the case teams forget. An internal library written three years ago by a team that has since dispersed, with no requirements, no design record and no verification evidence, is SOUP in your own codebase. You cannot promote it out of SOUP status by asserting authorship; only records do that.

There is no volume exemption and no triviality exemption. A twelve-line open-source utility package pulled from a public registry is SOUP. So is the language runtime it executes on.

The four obligations, by clause

For each SOUP item, the standard requires:

1. Identification — clause 8.1.2 (all classes). Configuration management must record, for each SOUP item, its title, the manufacturer, and a unique SOUP designator — in practice the exact version or release identifier. This applies at Class A too. It is the one SOUP obligation that never goes away.
2. Functional and performance requirements — clause 5.3.3 (Class B and C). You must specify what functional and performance requirements you are relying on the SOUP item to meet. This is a requirements statement about your use of it, not a copy of its documentation: which of its behaviours your device’s safety depends on, and to what performance envelope.
3. Required environment — clause 5.3.4 (Class B and C). You must specify the system hardware and software the SOUP item itself needs in order to meet those requirements — the target platform, runtime versions, memory and processing assumptions, other libraries it depends on. This is the clause that forces you to enumerate transitive dependencies rather than pretend the dependency tree is one level deep.
4. Published anomaly list evaluation — clause 7.1.3 (Class B and C). You must evaluate any publicly available list of anomalies for the SOUP item and determine whether any known anomaly could produce a sequence of events resulting in a hazardous situation. This sits inside clause 7 (software risk management) because that is what it is: a risk analysis input, not a procurement formality. Related, clause 7.1.2 requires SOUP failure and unexpected results to be considered among the potential causes of a software item contributing to a hazardous situation.

Beyond the initial evaluation, the software maintenance plan under clause 6.1 has to describe how you will keep monitoring information relevant to your software — including newly published anomalies affecting SOUP items — and clauses 6.2 and 6.3 govern how you analyse and implement the resulting changes. SOUP evaluation is a lifecycle activity, not a one-time premarket exercise.

Where teams actually get this wrong

• A lockfile is not a SOUP list. A package-lock.json, poetry.lock, go.sum or Maven dependency tree gives you names and versions, which covers clause 8.1.2 and nothing else. It contains no statement of what you rely on each component to do (5.3.3), no environment specification (5.3.4), and no anomaly evaluation (7.1.3). Auditors who know the standard ask for the second, third and fourth items, and a resolved dependency graph is the answer to the wrong question.
• “There is no published anomaly list.” Common for small open-source packages with no formal issue triage. The requirement is to evaluate any publicly available anomaly list — so the honest answer is a documented search of what does exist (the project’s issue tracker, its release notes and changelog, the relevant CVE and advisory databases, the maintainer’s security policy) and a recorded conclusion. A documented “we searched these sources on this date and found the following, assessed as follows” satisfies the clause. Silence does not, and neither does “the project has no bug tracker” without evidence that you looked.
• Transitive dependencies are in scope. Clause 5.3.4 makes this unavoidable — the software a SOUP item requires in order to work is part of what you must specify. A dependency you did not choose but do ship is still shipped.
• Container base images and language runtimes are SOUP. An OS image is one of the largest SOUP items most teams have, and it is routinely omitted from the inventory because nobody thinks of it as a dependency.
• Version pinning is a compliance control, not just an engineering preference. The unique SOUP designator required by 8.1.2 has to identify a specific build. Floating ranges make the identification obligation unsatisfiable, and they mean the anomaly evaluation you performed applies to a version you may no longer be shipping.
• Classifying everything Class A to escape SOUP work only escapes three of the four obligations. Identification under 8.1.2 still applies, and an unjustifiable Class A claim is a much worse finding than an incomplete SOUP file. See the classification section above for why Class A is now an argument you have to win.
• Support status is a risk input. An unmaintained SOUP item with no anomaly-reporting channel cannot be monitored under clause 6.1. That does not forbid using it, but the inability to monitor it is a fact your risk file has to carry.

SOUP versus FDA’s “OTS software” — related, not identical

FDA uses its own term. In the June 2023 premarket software guidance, off-the-shelf (OTS) software is defined as “a generally available software component used by a device manufacturer for which the manufacturer cannot claim complete software life cycle control (e.g., operating system, printer/display libraries).”

That is close to the first limb of the SOUP definition and it maps cleanly. It does not obviously cover the second limb — your own previously developed software with inadequate records. So SOUP is the broader category, and a component list assembled to satisfy FDA’s OTS expectations may be missing the internal legacy components 62304 counts as SOUP. Build the SOUP inventory first and derive the OTS list from it, not the other way round.

FDA also expects a software bill of materials as a way of presenting component detail — commercial, open-source, OTS and manufacturer-developed alike — and maintains a separate guidance, Off-The-Shelf Software Use in Medical Devices (August 2023), for OTS-specific expectations. An SBOM generated from your build is a good starting artefact for the 8.1.2 inventory, but the same caution applies as with lockfiles: it answers the identification question only.

Legacy software: clause 4.4

Amendment 1 added clause 4.4 to deal with a genuine problem — software already on the market, developed before the manufacturer applied 62304, where retrospectively generating a full lifecycle record is neither possible nor useful.

The route it provides is risk-based rather than archaeological. Rather than reconstructing development records that were never created, the manufacturer performs a risk-management assessment of the legacy software in its actual use, identifies the gaps against the standard’s requirements for its safety class, and produces a documented rationale and a plan for closing the gaps that matter. Continued postmarket experience with the software is admissible evidence in that assessment.

Two limits are worth being clear about. Clause 4.4 is a route for software already released; it is not a way to start a new project without a lifecycle. And it does not exempt subsequent changes — once you modify legacy software, the maintenance process in clause 6 and the risk management process in clause 7 apply to that change in the normal way.

How FDA actually consumes IEC 62304

This is where a surprising number of submissions go wrong, because the natural assumption — that FDA’s expectations track the standard’s safety classes — is incorrect.

Documentation Levels are not safety classes

FDA’s Content of Premarket Submissions for Device Software Functions (issued June 2023, replacing the May 2005 software guidance) defines two Documentation Levels:

• Enhanced Documentation Level — recommended where a failure or flaw of any device software function could present a hazardous situation with a probable risk of death or serious injury to a patient, user, or others in the environment of use. Critically, FDA says these risks “should be assessed prior to implementation of risk control measures.”
• Basic Documentation Level — everything else.

FDA additionally recommends Enhanced Documentation for specific device categories regardless of the general test: devices intended to test blood donations for transfusion-transmitted infections, devices used to determine blood donor and recipient compatibility, automated blood cell separator devices for collection of blood and blood components, and blood establishment computer software (BECS). It also generally recommends Enhanced Documentation for devices that are a constituent part of a combination product and for Class III devices, while allowing a sponsor to argue for Basic with an appropriately detailed rationale.

Compare that with clause 4.3. FDA assesses risk before risk control measures; 62304 Class A explicitly permits consideration of risk control measures external to the software system. These are different tests, and they can disagree. Software that is legitimately Class A under 62304 because a hardware interlock makes the residual risk acceptable may still fall into FDA’s Enhanced Documentation Level, because the pre-mitigation risk of death or serious injury is what FDA is asking about. Do not assume Class A implies Basic Documentation.

FDA does not want a Declaration of Conformity to the whole standard

This is stated directly in the guidance, and it is counter-intuitive enough to be worth quoting: a Declaration of Conformity to the complete ANSI/AAMI/IEC 62304 standard “is not needed due to known differences in categorization of device software functions and other recommended documentation.”

What FDA suggests instead is a Declaration of Conformity to specific clauses, as an alternative way of addressing particular documentation elements. For the software development, configuration management and maintenance practices element, the guidance names sub-clauses 5.1.1 (software development plan), 5.1.2 (keep the plan updated), 5.1.3 (plan reference to system design and development), 5.1.6 (software verification planning), 5.1.7 (software risk management planning), 5.1.8 (documentation planning), 5.1.9 (software configuration management planning), together with clause 6 (software maintenance process) and clause 8 (software configuration management process), among others as applicable.

So the correct posture for a US submission is: build to the full standard, but declare conformity clause by clause against the documentation element you are addressing. FDA’s recognition record also cross-references its other relevant guidances — including the predetermined change control plan guidance for adaptive algorithms, the clinical decision support software guidance, the multiple function device products guidance, the cybersecurity guidances, and the human factors and usability engineering guidance.

Where cybersecurity sits

62304 does not contain a cybersecurity process; the amendment predates FDA’s current expectations. Cybersecurity documentation for a US submission comes from FDA’s Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions guidance, which the 62304 recognition record lists among its relevant guidance documents. The connection to 62304 in practice is the SOUP inventory: a vulnerability in a third-party component is simultaneously a cybersecurity finding and a clause 7.1.3 anomaly-evaluation trigger. Run one component inventory that serves both, or the two records will drift apart.

The EU position

In the EU, the substantive requirement is in the Medical Device Regulation (EU) 2017/745, Annex I, Chapter II, Section 17.2: software that is a device in itself, or is a component of a device, must be developed and manufactured in accordance with the state of the art, taking into account the principles of development lifecycle, risk management (including information security), verification and validation. That is a description of 62304 plus ISO 14971 without naming them.

The European adoption is EN 62304:2006/A1:2015, technically identical to the IEC text. Whether it currently appears on the Commission’s list of harmonised standards under MDR or IVDR — and therefore whether conformity with it carries a presumption of conformity with Section 17.2 — changes as the Commission publishes implementing decisions. Check the current Official Journal harmonised-standards list for MDR before relying on presumption of conformity; that status is not something to take from a secondary source, including this page. The development obligation in Annex I 17.2 applies regardless of harmonisation status.

What a reviewer or auditor actually asks for

A working checklist, in roughly the order these get requested:

1. The software safety classification and its rationale, traced to the ISO 14971 risk file — including, for any Class A claim, the identification of the external risk control measure relied on and evidence that it is external to the software system.
2. The software development plan (clause 5.1), and evidence it was kept current rather than written once at project start.
3. The software requirements specification (clause 5.2), including requirements derived from risk control measures.
4. The architecture (clause 5.3, Class B and C), showing the software items and, if you are claiming mixed classes, the segregation and how it is enforced.
5. The SOUP inventory (clause 8.1.2) — title, manufacturer, unique designator for every item including transitive dependencies, runtimes and base images.
6. The SOUP requirement and environment specifications (clauses 5.3.3 and 5.3.4) for Class B and C.
7. The SOUP anomaly evaluation (clause 7.1.3) — the sources searched, the date, the anomalies found, and the hazard analysis of each.
8. Verification and testing evidence proportionate to class (clauses 5.5 to 5.7), with traceability from requirements through to test results.
9. The release record (clause 5.8), including documented known residual anomalies and their evaluation, and evidence the release is reproducible.
10. The maintenance plan and problem resolution records (clauses 6 and 9), including how SOUP anomaly monitoring is operationalised and how software problems feed the QMS CAPA process.

Items 5 through 7 are the ones most likely to be incomplete on a first submission, and they are also the cheapest to get right if you start the inventory at the beginning of the project rather than reconstructing it afterwards.

Frequently asked questions

Is IEC 62304 mandatory?

No standard is mandatory in itself. The regulatory requirement is mandatory: EU MDR Annex I 17.2 requires a development lifecycle, risk management, verification and validation in accordance with the state of the art, and FDA requires the documentation described in its premarket software guidance. IEC 62304 is the recognised, conventional way to demonstrate both. You may in principle demonstrate compliance another way; in practice nobody does, and a notified body or FDA reviewer will read a non-62304 lifecycle as a novel argument you have to justify.

What is the current version of IEC 62304?

IEC 62304 Edition 1.1 (2015-06) — the 2006 base standard consolidated with Amendment 1:2015. The identical US adoption is ANSI/AAMI/IEC 62304:2006/A1:2016. This is the version FDA recognises in full under recognition number 13-79.

Does IEC 62304 apply to software used in manufacturing or in a laboratory?

No. 62304 applies to medical device software — software that is itself a device, or is an embedded or integral part of one. Software used to run a manufacturing process or a laboratory is governed by the quality system it operates under: computer system validation under GAMP 5, 21 CFR Part 11 for electronic records and signatures, and the relevant accreditation standard. A validation master plan is the analogous planning document in that world. The two frameworks are frequently confused because both talk about software validation; they answer different regulatory questions.

Is my software Class A if it only displays information?

Not automatically, and this is the most common misapplication of Amendment 1. The question is whether the software can contribute to a hazardous situation. Software that displays a measurement a clinician acts on can contribute to a hazardous situation by displaying the wrong measurement, or the right measurement attributed to the wrong patient. Class A requires either that no such contribution is possible, or that an external risk control makes the residual risk acceptable. “It is read-only” is not the test.

Is every open-source library really SOUP?

Yes. The definition at clause 3.29 turns on whether the software was developed for the purpose of being incorporated into this medical device and whether you have adequate development records — not on licence, size, popularity or cost. A widely used, well-maintained open-source library is SOUP. So is a commercial closed-source component you paid for. What varies is how much evidence is available to you, not whether the obligation applies.

What do I do when a SOUP item has no published anomaly list?

Document the search rather than the absence. Record which sources you checked — issue tracker, release notes and changelog, CVE and advisory databases, the project’s security policy — the date you checked, what you found, and your assessment of whether anything found could lead to a hazardous situation. Clause 7.1.3 requires evaluation of any publicly available anomaly list; a documented, dated, sourced negative result is an evaluation. An unexplained blank is not.

Does an FDA Basic Documentation Level mean I can treat my software as Class A?

No, and the inverse is also false. FDA’s Documentation Levels and 62304’s safety classes are separate schemes applying different tests — FDA assesses risk before risk control measures, 62304 Class A permits consideration of external risk controls. Assign the safety class from your ISO 14971 file under clause 4.3, and determine the Documentation Level from FDA’s guidance criteria, independently. Expect them to disagree sometimes.

Do I need IEC 62304 for a research prototype in a university lab?

Not while it stays research. The obligation attaches when the software is a medical device or part of one, which turns on intended use — see the SaMD guide for where that line sits. The practical warning for academic groups and technology transfer offices is that the SOUP inventory and the requirements record are almost impossible to reconstruct years later. If there is a realistic path to clinical deployment or licensing, keeping a versioned dependency inventory and a requirements document from the start costs very little and is the difference between clause 4.4 legacy remediation and a normal lifecycle.

Does IEC 62304 require a specific development methodology?

No. The standard specifies processes, activities and tasks with defined outputs; it does not mandate waterfall, and agile development is compatible with it provided the required outputs exist, are controlled, and are traceable. AAMI TIR45 is the conventional reference on applying agile practice within 62304. What the standard does require is that your development plan describes the lifecycle model you are actually using, and that you follow it.

Primary sources

• FDA, Recognized Consensus Standards: Medical Devices — recognition number 13-79, IEC 62304 Edition 1.1 2015-06, extent of recognition: complete standard, entered 14 January 2019.
• FDA, Content of Premarket Submissions for Device Software Functions, June 2023 — Documentation Levels, and the clause-specific Declaration of Conformity approach.
• FDA, Off-The-Shelf Software Use in Medical Devices, August 2023.
• Regulation (EU) 2017/745 (MDR), Annex I, Chapter II, Section 17.2.
• IEC 62304 Edition 1.1 (2015-06), Medical device software — Software life cycle processes, and ANSI/AAMI/IEC 62304:2006/A1:2016. The standard text is copyrighted and must be purchased from the IEC Webstore or ANSI/AAMI; clause numbers are cited here, the text is not reproduced.

Related CASRAI resources

• Software as a Medical Device (SaMD) — whether your software is a device at all, and under which pathway. 62304 answers a different question: how you develop it once the answer is yes.
• ISO 13485: medical device quality management systems — the QMS that clause 4.1 presumes you already operate.
• 21 CFR Part 820 and the QMSR transition — how the same QMS expectation arrives through US regulation.
• FDA 510(k) premarket notification — the submission a 62304 Declaration of Conformity supports but does not replace.
• FDA predetermined change control plans — for software that is designed to change after clearance.
• Computer system validation under GAMP 5 — the parallel framework for software that supports a regulated process rather than being a device.
• FDA recognized consensus standards — the recognition mechanism and Declarations of Conformity.
• Lab compliance pillar — the full standards and regulatory hub.