Direct answer. Diagnostic software is regulated as a medical device, so the question is no longer "which certificate" but "what does the regulator require before and after I sell it". I would treat safety risk management, software lifecycle, validation, cybersecurity and post-market monitoring as one evidence set, owned with a regulatory affairs lead. Counsel and regulatory affairs decide classification. Lead with the regime of the market you sell into: the US (FDA) if selling in the US, the EU (MDR, the Medical Device Regulation) if selling in Europe, and both if you sell in both. Terms: SaMD (software as a medical device) is software that performs a medical purpose on its own rather than running inside a hardware device, for example an app that flags findings on scans. Three international standards anchor the evidence in every market: ISO 14971 (medical-device risk management), IEC 62304 (software life cycle) and ISO 13485 (quality management system). Regulator terms: a clearance or approval is the regulator's permission to market the device; residual risk is the risk left after controls are applied; post-market surveillance is the monitoring you must keep doing after launch.
What governs each stage
| Stage | Expectation |
|---|
| Safety risk | ISO 14971 hazard analysis, with security risks feeding the safety file |
| Build | IEC 62304 lifecycle, usability engineering, design controls (the documented plan, inputs, outputs, reviews and change records for the design) under a quality system. FDA's QMSR took effect February 2, 2026 and incorporates ISO 13485:2016 |
| Validate and release | Verification and validation with traceability (each hazard linked to its control and its test), clinical evidence, design review sign-off, then regulator clearance before marketing |
| Labeling and consent | Intended use, limitations and instructions for use; informed consent and ethics review for clinical studies |
| Cybersecurity | FDA's premarket cybersecurity guidance (final, February 2026) and section 524B of the FD&C Act (the law's cybersecurity requirements for "cyber devices": devices that run software, connect to a network and could be vulnerable to cyber threats) |
| After launch | Complaint handling, adverse event reporting, vulnerability management, field performance monitoring and corrective action |
Differences from ISO 27001 or SOC 2. The law requires a regulator's decision on the product, the focus is patient safety, and evidence is about this product and its intended use. ISO 27001 and SOC 2 are voluntary and organization-wide, and they do not address clinical safety. In Europe, software that informs diagnosis is usually Class IIa or higher (a mid-level risk class that requires a notified body, an independent assessor, to review the file) under MDR Rule 11 (explained in guidance document MDCG 2019-11), and EN 62304 is the European edition of the software life cycle standard that supports conformity.
Worked example: one traceable row
| Hazard | Risk control | Verification | Residual risk review |
|---|
| Model misses a finding | Confidence display, mandatory clinician review | Test set and usability test | Benefit-risk sign-off |
The same row with illustrative values. ISO 14971 does not prescribe a numeric scale, so each manufacturer defines its own in its risk management plan. Suppose severity is scored 1 to 5 and probability 1 to 5. A missed finding delays a diagnosis: severity 4. Before controls, probability is 3 (occasional), so risk is 4 x 3 = 12, above the acceptance limit of 8 in the plan. Controls: the screen shows the model's confidence and a clinician must review every case. Verification: on a test set of 400 cases that each contain the finding, the model flags 372, a sensitivity of 372 / 400 = 93%, so 28 are missed by the model alone; in a usability test, reviewers catch most of those 28, which supports lowering probability to 2. Residual risk is 4 x 2 = 8, at the limit. Benefit-risk sign-off (the documented decision by named clinical, safety and regulatory owners that the benefit of the device outweighs the remaining risk) records why 8 is acceptable and what post-market monitoring will watch.
Safety case (the file of reasoned argument that the product is acceptably safe). Argue, with evidence, that the product is acceptably safe: hazards, controls, tests, labeling and monitoring. Security frameworks supply the cybersecurity controls inside that argument. For AI that learns, FDA's final guidance on predetermined change control plans (December 4, 2024) lets planned updates be pre-authorized.
