ISO/IEC 27001:2022, the third edition, was published in October 2022. Amendment 1, on climate action changes, followed in February 2024 and is free of charge (ISO). In the Netherlands, NEN 7510-1:2024 was published on 1 December 2024, with a start date of 16 December 2024, replacing NEN 7510-1:2017+A1:2020 (NEN).
Most delays in an ISMS project come from doing things in the wrong order. This article sets out the implementation steps for an organisational information security management system (ISMS) at a medical device software manufacturer, and what each step should produce. Our ISO 27001 requirements article covers the clauses, documented information and Annex A in detail.
Start with scope and risk, not policies
In our view, the order of work drives the cost. Policies written before the scope is fixed often cover the wrong activities. A tool bought before the risk method is defined builds in assumptions that may have to be undone later.
Certification is optional. Where customers want independent assurance, a certificate from an accredited certification body gives it. Decide this at the start, because it determines the timeline.
The steps and their outputs
Step 0: the mandate
Record why the ISMS is needed, which standard or standards it must meet, whether certification is sought, and what customers expect the certificate to cover. A distributor's request for certification or a hospital's procurement questionnaire should become written requirements, not assumptions held by the sales team.
Step 1: context and scope (Clause 4)
Record the internal and external issues, the interested parties and their requirements, then define the boundaries. For a SaMD manufacturer, this usually means the development environment, the production cloud and support activities.
Include interfaces with outsourced services. Clause 4.3 requires the scope to consider interfaces and dependencies. Leaving a supplier outside the scope does not remove the dependency on its service.
Step 2: leadership (Clause 5)
The output is the information security policy, assigned roles and evidence of top management commitment. Management must provide authority and resources, not just sign a document prepared by QA. Decide who can require changes to development, support and supplier arrangements when a risk treatment calls for it.
Step 3: risk assessment (Clause 6.1.2)
Define the criteria for likelihood, consequence and risk acceptance before scoring any risk. Without them, different owners reach different decisions about the same cloud outage or unauthorised repository access.
The output is a risk register in which each risk has an owner, a treatment decision and supporting evidence.
Step 4: risk treatment and Statement of Applicability (Clause 6.1.3)
Select the controls needed to carry out the treatment decisions, then compare them with Annex A to check that nothing necessary has been left out. The 2022 Annex A groups its 93 controls under four themes: organisational, people, physical and technological. Controls may also come from other sources.
The Statement of Applicability (SoA) lists the necessary controls, why they are included, whether they are implemented, and why any Annex A controls are excluded. The risk owners approve the treatment plan and accept the residual risks.
ISO/IEC 27002:2022 gives guidance on implementing the controls. It is not a standard you can certify against.
Step 5: operation (Clause 8)
Operate the controls and keep the records as you go: access approvals, recovery tests, supplier assessments and incident records. In our view, each control should have a named evidence owner from day one. Reconstructing records just before the audit rarely convinces an auditor.
Step 6: internal audit and management review (Clauses 9.2 and 9.3)
Complete the internal audit, then the management review, before the certification audit. Management needs evidence that the controls work and a view of the open risks, not just confirmation that procedures exist.
| Step | Main output | Clause | Can an ISO 13485 process be reused? |
|---|---|---|---|
| 1. Context and scope | Scope statement covering development, production cloud and support | 4 | No, new |
| 2. Leadership | Security policy, roles, management commitment | 5 | No, new |
| 3. Risk assessment | Criteria, method and assessed risks with owners | 6.1.2 | No, new |
| 4. Risk treatment and SoA | Treatment plan and SoA checked against Annex A | 6.1.3 | No, new |
| 5. Operation | Operated controls and records | 8 | Partly: document control |
| 6. Internal audit and management review | Audit results and management review decisions | 9.2, 9.3 | Yes: internal audit and management review |
Source: ISO/IEC 27001:2022. The last column is our assessment.
What the certificate does not show
MDR Annex I Section 17.2 requires software to be developed and manufactured in accordance with the state of the art, taking into account the development life cycle, risk management including information security, and verification and validation. Section 17.4 requires the manufacturer to set out the minimum hardware, IT network characteristics and IT security measures, including protection against unauthorised access, needed to run the software as intended.
An ISO/IEC 27001 certificate is evidence about the organisation, not about the device. The technical documentation must still show how the device's security requirements were defined and verified.
MDCG 2019-16 Rev.1, the MDCG guidance on cybersecurity for medical devices (December 2019, revised July 2020), is not legally binding. Its Annex III lists EN ISO/IEC 27001 for information only. A standard gives a presumption of conformity only when it is harmonised and its reference is published in the Official Journal.
In our view, the certificate belongs next to the Annex I evidence, never in place of it. Our article on SaMD technical documentation explains where the device-level evidence sits.
NEN 7510 and ISO/IEC 27001 in one scope
NEN 7510-1:2024 and NEN 7510-2 set out a management-system framework for healthcare organisations and others that manage personal health information. According to NEN, an organisation claiming conformity may not exclude any requirement in chapters 4 to 10 of NEN 7510-1. The standard is available free of charge.
Hypothetical example: a Dutch SaMD scale-up with an ISO 13485 QMS receives two requests. Its hospital customers ask for NEN 7510 conformity, and a US distributor asks for ISO/IEC 27001 certification.
Step 0: it decides to build one ISMS and have it assessed against both standards, keeping each claim traceable to the standard that requires it.
Step 1: it defines one scope covering development, production cloud and support, and checks that the scope covers the personal health information relevant to the hospitals.
Steps 2 and 3: it assigns roles once and uses one risk method, then confirms the method meets both standards.
Step 4: it prepares one SoA, and records which treatments answer any NEN 7510 requirements that go beyond ISO/IEC 27001.
The minimum IT requirements for running the device still go into the instructions for use and the technical file, not only into the ISMS records.
What the ISO 13485 system can carry
An existing ISO 13485 quality management system already has document control, internal audit, management review and corrective action. In our view, the ISMS should use these processes rather than create parallel ones.
Keep the risk decisions separate. The information security risk register covers risks to information, with its own criteria. The ISO 14971 risk file covers product safety risks, including harm to patients. Cross-reference related scenarios, but do not merge the acceptance decisions.
A shared internal audit programme can use one schedule, provided the audit criteria and auditor competence are recorded separately for each standard. Change control should show when a security change affects the device, its verification or its released documents.
Conclusion
The order of work is the same for ISO/IEC 27001 and NEN 7510: fix the scope, define the risk method, then decide which controls are needed and which ISO 13485 processes can carry the evidence. One ISMS can serve hospitals and distributors when the boundaries and criteria are written down.
In our view, the certificate is organisational assurance. It sits next to the MDR Annex I evidence for the device and does not replace it.
If you need help implementing an ISMS alongside your QMS and device documentation, our cybersecurity and privacy team can help, or contact MedQAIR.
Frequently asked questions
Can the certificate cover only part of the organisation?
Yes, provided the scope defines its boundaries and considers the interfaces and dependencies with the rest of the organisation (Clause 4.3).
Must suppliers and cloud providers be inside the ISMS scope?
No. But the requirements of interested parties and the risks arising from supplier services must still be considered under Clauses 4.2 and 6.1.2.
Who approves the risk treatment plan?
The risk owners. They approve the plan and accept the residual information security risks (Clause 6.1.3).
Must excluded Annex A controls be justified?
Yes. The Statement of Applicability must justify the exclusion of any Annex A control, as well as the inclusion of the necessary controls (Clause 6.1.3).
Does an ISO 27001 certificate prove MDR cybersecurity compliance?
No. It is evidence about the organisation's ISMS. The device must still meet MDR Annex I Sections 17.2 and 17.4, shown in the technical documentation.
