Companies building Software as a Medical Device (SaMD) sometimes ask whether holding a QMS makes an ISMS unnecessary, or the reverse. Neither holds. A QMS and an ISMS protect different things and cannot substitute for one another.
But running them as two entirely separate systems duplicates procedures, duplicates audits, and makes staff record the same thing twice. The practical answer is to share what can be shared and separate only what differs in purpose.
This article works out how to fit the two together. For SaMD's regulatory position itself, see What Is Software as a Medical Device (SaMD)?.
Disclaimer: General information only. Application of Japan's Pharmaceuticals and Medical Devices Act and the QMS Ministerial Ordinance is governed by MHLW and PMDA publications; requirements of the standards, by the standards and the accreditation and certification bodies. Confirm device status and regulatory obligations with the authorities, registered certification bodies, and specialists.
Two Systems That Protect Different Things
The word "risk" means different things in each.
| QMS (ISO 13485 / QMS Ordinance) | ISMS (ISO/IEC 27001) | |
|---|---|---|
| Objective | The device is safe and performs as intended | Confidentiality, integrity, availability of information |
| What is protected | Patients and users — prevention of harm | Information assets — leakage, tampering, outage |
| Definition of risk | Probability and severity of harm (ISO 14971) | Threats and vulnerabilities against assets, business impact |
| Basis | PMD Act / QMS Ordinance, ISO 13485 | ISO/IEC 27001 (JIS Q 27001) |
| Third-party check | Conformity assessment, regulatory inspection | ISMS certification audit |
| Coverage | Design, manufacture, post-market of the marketed device | The organisation and activities declared in scope |
One incident can register in both. If the database holding a SaMD's inference outputs is tampered with, the ISMS sees an integrity breach; the QMS sees a defect in which incorrect information could reach a clinical decision and harm a patient. The reporting destinations and timelines differ, so incident procedures must branch on this determination first.
Not everything overlaps. A leak that cannot harm a patient is an ISMS event; a configuration change that cannot affect device performance is a QMS change-control event.
What Each Demands
Marketing a SaMD in Japan requires conformity with the QMS Ministerial Ordinance, which is structured on the basis of ISO 13485; in practice companies build to ISO 13485 and layer domestic requirements on top.
For software specifically, IEC 62304 defines the medical device software lifecycle: development process, software safety classification, post-market maintenance, and management of SOUP (software of unknown provenance). These go further than a general ISMS "secure development" control.
| Area | QMS side | ISMS side | Integration |
|---|---|---|---|
| Policy and objectives | Quality policy and objectives | Security policy and objectives | Separate documents — bind them under one management policy |
| Document and record control | Document control, retention periods | Control of documented information | Integrate into one procedure |
| Competence and training | Competence, training records | Competence, awareness, training records | Integrate — one plan, split by content |
| Supplier management | Purchasing information, supplier evaluation | Supplier security management | Partially — one evaluation sheet, both lenses |
| Design controls | Design plan, inputs/outputs, verification, validation, transfer, changes | Secure development, change management | Partially — use design controls as the frame and embed security |
| Risk management | ISO 14971 (harm to patients) | Information security risk assessment | Keep separate — but connect the inputs and outputs |
| Nonconformity and CAPA | Nonconforming product, CAPA | Nonconformity and corrective action | Integrate into one process |
| Internal audit | QMS audit | ISMS audit | Integrate into one audit programme |
| Management review | QMS review | ISMS review | Integrate into one meeting |
| Post-market | Complaints, adverse event reporting, surveillance | Incident management | Partially — one intake, branch on determination |
The lesson: the "how you run it" layer integrates cleanly; the product-specific layer should stay separate.
Two Sets of Documents, or One?
① Fully separate
Clear to explain at inspection and at audit, but document control, training, CAPA, and internal audit all duplicate. At 20–50 people this does not survive contact with reality — missing records become a permanent fixture of your corrective actions.
② Fully integrated
Minimum operational load, but it becomes hard to read which requirement a document answers, slowing audits and inspections. Merging risk management is the worst case: ISO 14971's harm-based analysis and information security risk assessment blur and both lose precision.
③ Shared layer plus specific layers (recommended)
Shared: document control / training / corrective action / internal audit / management review
QMS-specific: design control / ISO 14971 risk management / IEC 62304 software lifecycle /
post-market safety
ISMS-specific: risk assessment / Statement of Applicability / access control /
incident response / business continuity
One audit programme covers both, and one management review meeting considers both sets of inputs. CAPA flows through a single process with an attribute recording its origin.
See ISMS Documentation: How Much to Build.
Design Controls and ISO 14971
This is the delicate part. Do not merge ISO 14971 risk management with ISMS risk assessment. The axes differ.
| ISO 14971 | ISMS risk assessment | |
|---|---|---|
| Subject of risk | Harm to patients and users | The organisation's information assets |
| Axes | Severity × probability of harm | Impact × likelihood (C, I, A) |
| Acceptance | Benefit–risk balance | Organisational risk acceptance criteria |
| Output | Risk management file | Risk treatment plan, SoA |
But you must connect them, at two points.
1. The path from security vulnerability to patient harm
In a SaMD, broken authentication, tampering, or loss of availability can lead directly to harm. Tampered prescribing-support logic yields wrong suggestions; an outage in an urgent-use feature stalls care. So threats identified in the ISMS risk assessment that bear on product safety must feed into ISO 14971 risk analysis.
The reverse also holds. Where ISO 14971 concludes that malfunction of a given function causes serious harm, the components, data, and access paths supporting it become the assets warranting the highest protection level in the ISMS.
2. Security requirements as design inputs
ISO 13485 design control runs inputs → outputs → verification → validation → transfer → change. Putting security requirements explicitly into design inputs automatically pulls them into verification and validation, with records. There is then no need for a separate "secure development record" on the ISMS side.
This is the same logic as Security by Design for Medical Systems: a security requirement absent from design inputs either never gets built or becomes an expensive retrofit.
Post-market, software updates are the live question. Whether applying a security patch constitutes a product change requiring a regulatory procedure depends on the change and on the scope of the approval or certification. "It is a security fix, so we can ship it immediately" is not guaranteed — design vulnerability management around realistic patch lead times, and confirm specifics with the authorities or your registered certification body.
Certification, Inspection, and Scope
The two regimes bring different external parties to your door, potentially several times a year. Plan the calendar accordingly.
- Whether SaMD design, development, and post-market work sit inside ISMS scope. Hospitals and distribution partners want security evidence covering the development organisation; excluding it hollows out the proof
- Manufacturing and development subcontractors. Evaluated as purchasing/supplier control on the QMS side and supplier security on the ISMS side — one shared evaluation sheet with both lenses is more efficient
- Where server-side operation sits. For cloud-executed inference, server availability and integrity bear directly on device performance: central to the ISMS, and a premise of QMS validation
See Designing ISMS Scope for a Healthcare Company. If you supply hospitals directly, three-ministry work overlaps too (Integrating ISMS Documents with the Three-Ministry Guidelines).
Conclusion
- A QMS protects patients from harm; an ISMS protects information assets. Neither substitutes for the other
- Use a shared layer plus specific layers: integrate document control, training, CAPA, internal audit, and management review; keep design control and risk management separate
- Never merge ISO 14971 with ISMS risk assessment — different axes, and merging degrades both
- Do connect them: feed security threats that bear on safety into ISO 14971, and give the assets behind high-harm functions the highest ISMS protection
- Put security requirements into design inputs so verification and validation records cover them
- Settle the relationship between security patches and change control before you need it
Pottech supports ISMS certification with a focus on healthcare. Where a QMS already exists, we start by determining how much of the existing documentation and records can be reused. Support for building quality management processes is available as an option.
See ISMS Certification Support or contact us. For the overall picture, see What Is an ISMS (ISO/IEC 27001)?.
References and Sources
- Pharmaceuticals and Medical Devices Agency (PMDA)
- Medical devices and in vitro diagnostics | MHLW
- ISO (standards information for ISO 13485 and ISO 14971)
- ISO/IEC 27001 Information security management systems | ISO
- Information Management System Accreditation Center (ISMS-AC)
Note: device status, application of the QMS Ordinance, and whether a change requires a regulatory procedure all turn on the specific product and change. Confirm final regulatory positions with the authorities, registered certification bodies, and specialists.