Last month I sat in a tender meeting where the hospital's CISO asked for our ISO 27001 Statement of Applicability and risk treatment plan — within forty minutes of asking for our ISO 13485 certificate and Technical File index. It was a SaMD tender, Class IIa, nothing exotic. The CISO didn't actually want to read all of it. She wanted to know that the two were managed in the same place, by the same people, with the same document control discipline.
That is not the question most QMS pitches are built to answer.
The surface story for medical device eQMS is ISO 13485, MDR Annex IX, sometimes IEC 62304. ISO 27001 has been quietly arriving on the side, mostly through hospital procurement, and most medical device QMS tools don't treat it as a first-class requirement.
If you sell software into hospitals, you will be asked for both. Here is the underrated point: the value is not that they coexist in the vendor's marketing slides. The value is whether the evidence for both lives in the same workflow, with real traceability between them.
Why ISO 27001 is creeping into medical device tenders
Three places it surfaces, in my experience:
- Hospital procurement infosec questionnaires — increasingly modelled on ISO 27001 Annex A controls. NHS England, London teaching trusts, several Nordic procurement frameworks I have read recently all run the same shape of questionnaire.
- MDR Annex I, Section 17.2 on IT security — the regulation itself expects manufacturers of software to consider unauthorised access, data integrity, and confidentiality. A documented ISMS is the most efficient way to demonstrate that consideration.
- Post-market cybersecurity expectations under Article 84 and the MDCG 2019-16 guidance on cybersecurity. If you cannot show your security risk treatment is being actively maintained, the notified body will find something to write up.
ISO 13485 alone does not give you a clean answer to any of these. It is about product quality and the QMS that supports it. It does not give you Annex A control mapping, a risk treatment register that survives an audit, or a defensible Statement of Applicability.
The two-system drift problem
The default response, in most SMEs I have seen, is to run two systems: the eQMS for ISO 13485, MDR, technical files, CAPAs, change control — and a separate ISMS tool, or worse, a SharePoint folder, for ISO 27001 evidence.
This is where the audit and inspection pain really shows up. The drift is not dramatic. It is just slow and quiet.
- A change to a SaMD release process affects both the design control record under 13485 and the change-management control under 27001 Annex A.8.32. In two systems, those get approved separately, by different people, sometimes months apart.
- A supplier non-conformance that touches both device components and the hosted infrastructure shows up as one CAPA in one system and a separate incident record in the other. Two root cause analyses. Two effectiveness checks. Two versions of the truth.
- A CAPA-driven risk assessment in one system, a separate risk treatment action in the other. Cross-references are manual. They rot.
What I want, when I am the RA owner, is that when a CAPA is opened, the linked ISO 27001 controls are visible. When a change is initiated, the security Annex A controls are assessed in the same impact-mapping step. When an SoA control status flips, the linked design history and post-market records get a flag.
What that single system looks like in qmsWrapper
The underrated thing about qmsWrapper is that it keeps ISO 27001 evidence in the same system as ISO 13485. This is not the headline of their pitch. Their pitch is the medical-device-first QMS — 13485, MDR, validation per ISO/TR 80002-2:2017, risk management per ISO 14971. The 27001 side is there, less visible, and worth knowing about for SaMD and connected-device manufacturers.
In practice, this means:
- Change impact analysis can flag ISO 27001 Annex A controls alongside 13485 design and document controls in the same reviewable step.
- Risk registers can hold both ISO 14971 product risks and ISO 27001 information security risks in the same record family.
- Document control approvals apply to SoA, risk treatment plans, and information security policies with the same retention and signature discipline as Technical File documents.
- CAPAs and audit findings link to both standard sets, with one effectiveness check.
The benefit is not that you have fewer systems. The benefit is that when a notified body asks for evidence and a CISO asks for evidence in the same week, the answer is one set of records, not two sets you have to manually reconcile.
An honest caveat about vendor certifications
qmsWrapper's own ISO 27001 and SOC 2 certifications are still in progress as of my last conversation with the team. Granted, a vendor's own certification is not the same thing as the vendor giving you tools to manage your own certification. A vendor with a mature ISO 27001 ISMS for themselves is reassuring but not strictly required to manage yours. A vendor with none for themselves is fine for picking the right tools; it just means your own audit and your hospital CISO will not be able to point to their certificate.
The right questions to ask any eQMS vendor selling into hospitals, in my experience:
- Where are you on your own ISO 27001 certification, and when is the audit?
- Which Annex A controls does your tool give me native support for?
- If I have a security incident, can I open a CAPA that links to both my 13485 design history and my Annex A risk treatment in one record?
- If my SoA control status changes, does it generate a linked change request automatically, or is that manual?
- Show me one change record where 13485 and 27001 evidence are actually connected in the same workflow.
That last question is the one that separates the demos from the real product.
Open question
For those of you running SaMD or connected device QMS today: are you managing ISO 27001 evidence in your medical device eQMS, or in a parallel system? And if parallel — what has the experience looked like at audit time, or at hospital tender time?
Disclosure: I work on qmsWrapper.
Top comments (0)