ISO 27001 Requirements: A Clause-by-Clause Reference
ISO/IEC 27001 has been the reference standard for information security management systems since 2005, and its third edition, ISO/IEC 27001:2022, was published on 25 October 2022 (ISO/IEC 27001:2022 and Amendment 1:2024). The transition from the 2013 edition ended on 31 October 2025 under IAF MD 26, so every certified organisation is now audited against the 2022 edition. At the same time, hospitals and other customers increasingly ask digital health and medical device suppliers for ISO/IEC 27001 (or NEN 7510 in the Netherlands), often before anyone in the company has read what the ISO 27001 requirements actually are. Many then approach certification as a list of controls to collect.
That approach creates avoidable problems. This article sets out what ISO/IEC 27001:2022 requires, clause by clause, then connects the ISMS to ISO 13485, cloud-hosted SaMD and the separate cybersecurity obligations that apply to the product itself.
Background and Transition Timeline
The 2022 edition retains the management-system structure of Clauses 4 to 10 that the 2013 edition introduced, but restructured Annex A and added a new clause on planning of changes (6.3).
Amendment 1:2024 added climate-change considerations to Clauses 4.1 and 4.2. The change is limited in wording, but it still requires an organisation to consider whether climate change is a relevant issue and whether interested parties have climate-related requirements. It doesn’t turn an information security standard into an environmental management standard.
The standard is easy to misread because Annex A is more visible than the management system that gives it meaning. The certifiable requirements are in Clauses 4 to 10. Annex A provides a reference set of 93 controls, but the organisation selects controls through its risk assessment and risk treatment process. A certificate therefore concerns the operation of an ISMS, not the possession of a completed security checklist.
The rest of the analysis follows that distinction. For a medical device company, information security should be connected to the existing quality system, risk processes and supplier controls rather than built as a detached security project.
Clauses 4 to 10 of ISO 27001
Clauses 4 to 10 contain the requirements against which the ISMS is assessed. Clauses 0 to 3 provide introductory material and references, but they don’t create the certifiable management-system obligations.
| Clause | Subject | What the organisation must establish or perform |
|---|---|---|
| 4 | Context of the organisation | Determine internal and external issues, identify interested parties and their relevant requirements, and define the ISMS scope. Clause 4.3 requires the scope to be available as documented information. |
| 5 | Leadership | Demonstrate leadership and commitment, establish an information security policy under 5.2, assign roles and responsibilities, and ensure the ISMS is integrated into organisational processes. |
| 6 | Planning | Establish the information security risk assessment process under 6.1.2, define risk treatment under 6.1.3, set information security objectives under 6.2, and plan changes under 6.3. |
| 7 | Support | Provide resources, establish competence, create awareness, manage communication and control documented information under 7.5. |
| 8 | Operation | Plan and control ISMS operations, perform risk assessments under 8.2, and implement the risk treatment plan under 8.3. |
| 9 | Performance evaluation | Monitor, measure, analyse and evaluate the ISMS under 9.1, conduct internal audits under 9.2, and perform management reviews under 9.3. |
| 10 | Improvement | Address nonconformities, take corrective action and continually improve the suitability, adequacy and effectiveness of the ISMS. |
Where the risk decision is made
Clause 4 establishes the boundaries. A company can’t meaningfully assess information security risk until it has decided which locations, people, services, information assets and interfaces belong to the ISMS.
Clause 5 then puts responsibility with top management. A signed policy without management decisions, resources and assigned authority is weak evidence. The requirement concerns leadership and integration, not ceremonial approval.
Clause 6 is the centre of the system. The organisation must define a risk assessment methodology that produces consistent, valid and comparable results, identify risks and owners, analyse and evaluate those risks, and select treatment options. The treatment process produces the Statement of Applicability, the treatment plan and the control decisions that later become operational work.
From documents to operation
Clause 7 addresses the conditions needed for the system to work. Competence records, awareness and controlled documented information matter because security decisions often depend on people outside the security function.
Clause 8 is where the planned system operates. Risk assessments must be performed according to the defined process, and the organisation must implement the treatment plan. A policy that says privileged access is reviewed isn’t equivalent to evidence that reviews occur, exceptions are handled and the results are retained.
Clause 9 requires performance evaluation. The audit programme must examine conformity and effectiveness, while management review must consider the system’s performance, changes in context, audit results, risks, treatment status and improvement needs. Clause 10 closes the loop through nonconformity, corrective action and continual improvement.
For a medical device company, these requirements fit naturally beside the existing management system structure. They don’t eliminate the need for product-specific risk management or software lifecycle evidence.
Documented Information the Standard Requires
ISO/IEC 27001:2022 doesn’t require an organisation to create every document commonly found in a consultant’s implementation folder. It requires specific documented information, while allowing the organisation to decide what additional information is necessary for the effectiveness of its ISMS.
The list below covers the documented information that Clauses 4 to 10 explicitly require. Annex A controls can add documentation where the organisation selects them, but those depend on the Statement of Applicability rather than on the clauses. Operational evidence can be extensive, but it should support a requirement, a risk decision, a control or an evaluation activity rather than exist for its own sake.
| Documented information | Clause | Purpose |
|---|---|---|
| ISMS scope | 4.3 | Defines the organisational, physical, functional and technical boundaries of the ISMS. |
| Information security policy | 5.2 | States the direction and framework for information security. |
| Risk assessment methodology | 6.1.2 | Defines criteria and the method for producing consistent, valid and comparable results. |
| Risk treatment methodology | 6.1.3 | Defines how risks are selected, treated and accepted. |
| Statement of Applicability | 6.1.3 d) | Records selected controls, inclusion justifications, implementation status and exclusions with their justifications. |
| Information security objectives | 6.2 | Establishes objectives that can be monitored and evaluated. |
| Risk treatment plan | 6.1.3 e) | Records how selected treatments will be implemented, by whom and under what conditions. |
| Evidence of competence | 7.2 | Demonstrates the competence of persons doing work that affects ISMS performance. |
| Documented information needed for ISMS effectiveness | 7.5.1 | Defines what the organisation determines is necessary to operate and control the ISMS. |
| Results of information security risk assessments | 8.2 | Demonstrates that assessments were performed as planned. |
| Evidence of results of risk treatment | 8.3 | Shows that the treatment plan has been implemented. |
| Monitoring and measurement results | 9.1 | Provides evidence for performance analysis and evaluation. |
| Internal audit programme and results | 9.2 | Demonstrates planned audits, criteria, scope, impartiality and findings. |
| Management review results | 9.3 | Records top management’s evaluation and decisions concerning the ISMS. |
| Nature of nonconformities, actions taken and results | 10.2 | Demonstrates correction, corrective action and evaluation of effectiveness. |
The list is short because ISO/IEC 27001 is a management-system standard, not a document-production exercise. Adding policies that nobody uses won’t improve conformity. Auditors generally test whether the required information reflects actual decisions and whether records demonstrate repeatable operation.
Annex A Themes and Control Counts
Annex A contains 93 controls grouped into four themes. The 2022 revision changed the structure from 114 controls across 14 domains to 93 controls across four themes.
| Theme | Clause range | Number of controls |
|---|---|---|
| Organisational | 5.1 to 5.37 | 37 |
| People | 6.1 to 6.8 | 8 |
| Physical | 7.1 to 7.14 | 14 |
| Technological | 8.1 to 8.34 | 34 |
The themes and control references are part of the standard. Selection isn’t. An organisation first identifies the controls needed to treat its information security risks, then compares those controls with Annex A to verify that no necessary control has been omitted. An Annex A control that isn’t selected must be justified in the Statement of Applicability (ISO/IEC 27001 auditing practices note on the SoA).
That means Annex A isn’t a universal checklist. A small organisation with no owned premises may have a different physical control profile from a manufacturer operating laboratories, offices and technical infrastructure. A cloud-hosted SaMD company may need substantial technological and supplier-related treatment even if it owns little physical infrastructure.
ISO/IEC 27002:2022 provides guidance for the Annex A controls, including control attributes and implementation guidance. It is guidance, not a separate certifiable standard, and it doesn’t convert every suggested implementation practice into a mandatory ISO/IEC 27001 requirement (ISO/IEC 27002:2022).
The 2022 grouping also reflects how security work is delivered in practice. Organisational controls govern policies, suppliers and threat intelligence. People controls address competence and behaviour. Physical controls cover premises and equipment. Technological controls address systems, development, access, monitoring and data handling.
New Annex A Controls Added in 2022
The 2022 revision added 11 controls to the Annex A reference set.
| Control | Title | Theme | Primary concern |
|---|---|---|---|
| 5.7 | Threat intelligence | Organisational | Turning relevant threat information into security decisions. |
| 5.23 | Information security for use of cloud services | Organisational | Governing the acquisition, use, management and exit of cloud services. |
| 5.30 | ICT readiness for business continuity | Organisational | Ensuring information and technology can support continuity requirements. |
| 7.4 | Physical security monitoring | Physical | Detecting and reviewing unauthorised physical access or activity. |
| 8.9 | Configuration management | Technological | Maintaining controlled and appropriate configurations. |
| 8.10 | Information deletion | Technological | Removing information when retention or business needs no longer justify it. |
| 8.11 | Data masking | Technological | Reducing exposure of sensitive information during use or processing. |
| 8.12 | Data leakage prevention | Technological | Preventing unauthorised disclosure or extraction of information. |
| 8.16 | Monitoring activities | Technological | Monitoring systems and activity to identify information security events. |
| 8.23 | Web filtering | Technological | Controlling access to malicious or inappropriate web resources. |
| 8.28 | Secure coding | Technological | Integrating security into software development and coding practices. |
Control 5.30 has dedicated guidance in ISO/IEC 27031. The new controls are significant for software manufacturers because they address areas that often fall between quality, IT and engineering ownership. Cloud service governance, configuration drift, monitoring, deletion and secure coding can’t be treated as policy subjects alone.
The risk assessment should be revisited when the organisation’s technology, suppliers or threat assumptions change. AI agent attacks, model exfiltration and prompt-injection scenarios may alter the treatment required for threat intelligence and secure development. Leon Doorn’s analysis of ISO/IEC 27001 and NEN 7510-1 versus AI agents illustrates why a new threat class can require the organisation to reconsider both its risk model and its Annex A mapping.
Statement of Applicability
The Statement of Applicability, or SoA, is required by Clause 6.1.3 d). It is the document that connects the information security risk assessment to the selected control set, which is why it is often one of the first documents an auditor examines.
A compliant SoA must address:
-
Selected controls: Which Annex A controls are included in the treatment of identified risks.
-
Inclusion justification: Why each selected control is needed.
-
Implementation status: Whether the control is implemented, partially implemented, planned or not applicable according to the organisation’s chosen status model.
-
Exclusion justification: Why any Annex A control not selected doesn’t apply to the defined ISMS scope or risk treatment decisions.
The selection must follow the risk treatment plan. An organisation shouldn’t include controls merely to make the SoA look complete, and it shouldn’t exclude controls because implementation is inconvenient. The stated reason must relate to the ISMS scope, the assessed risks or the chosen treatment approach, and an auditor must be able to test that reasoning against evidence.
The SoA also provides the audit map. It shows where the auditor can sample implementation, which controls are still planned, how exclusions were justified and whether the control population is consistent with the scope and risk register.
The common failure is internal inconsistency. The scope says the company operates a cloud platform, the risk assessment identifies supplier and availability risks, but the SoA excludes cloud-service governance or continuity controls without a specific explanation. Alternatively, the SoA marks secure coding as implemented while engineering records show no defined coding criteria or review evidence. That gap is more serious than an unattractive template.
ISO 27001 and ISO 13485 in a Medical Device Company
ISO/IEC 27001:2022 and ISO 13485:2016 address different management-system objectives, but they rely on several of the same organisational processes. The overlap is useful only if responsibilities, records and decision criteria remain clear.
| Management process | ISO/IEC 27001:2022 reference | ISO 13485:2016 reference | Integration note |
|---|---|---|---|
| Document and record control | 7.5 | 4.2.4 and 4.2.5 | One controlled documentation process can serve both systems if security records receive appropriate handling. |
| Competence and training | 7.2 | 6.2 | Existing competence records can be extended to information security roles and awareness. |
| Internal audit | 9.2 | 8.2.4 | A combined audit programme can assess both systems, provided each standard’s criteria are tested. |
| Management review | 9.3 | 5.6 | One review meeting can consider QMS performance, security objectives, risks, audit results and corrective actions. |
| Supplier and external provider control | Risk treatment under 6.1.3 and relevant Annex A controls | 7.4 | Supplier controls can share qualification, monitoring and escalation processes, with security criteria added where relevant. |
| Nonconformity and corrective action | 10.2 | 8.5.2 and 8.5.3 | A shared CAPA process can record security nonconformities alongside quality issues. |
| Change management | 6.3 and 8.1 | 7.3.9 and related change controls | One change process can assess quality, security, regulatory and product effects separately. |
The ISMS still adds specific work. The organisation must define its information security context and interested parties, establish a security risk assessment and treatment methodology, set information security objectives and maintain the SoA. ISO 13485 certification doesn’t discharge those obligations.
A sensible integration model uses one procedure set where the process is shared, one management review agenda with separate quality and security inputs, a combined internal audit programme and a single corrective-action process. The evidence must still show which requirement was assessed. A combined audit isn’t a reason to omit security sampling.
A medical device manufacturer can also extend supplier controls to cloud providers, hosting providers, software libraries and other external services. The security assessment should remain distinct from supplier quality qualification because the relevant risks differ, even when the same supplier record contains both evaluations. A documented ISO 13485 QMS reference can help establish that distinction.
ISMS versus Product Cybersecurity under MDR and FDA
An organisational ISMS protects information assets and manages security risk across the business. Product cybersecurity concerns the medical device itself, its software, interfaces, users and operation in the field.
Under Regulation (EU) 2017/745 (MDR), Annex I requires software to be developed according to the state of the art, taking into account the development life cycle, risk management including information security, and verification and validation (Section 17.2), and requires manufacturers to set out minimum IT security measures, including protection against unauthorised access (Section 17.4). In the United States, section 524B of the FD&C Act requires manufacturers of cyber devices to provide a plan to monitor and address postmarket vulnerabilities, processes that provide reasonable assurance of cybersecurity, and a software bill of materials, and FDA’s premarket cybersecurity guidance describes the documentation it expects.
These obligations overlap in subject matter but not in scope. ISO/IEC 27001 can govern how a manufacturer controls development access, suppliers, incidents and corporate information, while MDR and FDA requirements assess whether the device has been designed and maintained to resist relevant threats. One doesn’t substitute for the other. A broader discussion of those product obligations is available in this cybersecurity and privacy reference.
Worked Example for a Cloud-Hosted SaMD Company
Hypothetical example: A SaMD company already holds ISO 13485 certification for a cloud-hosted diagnostic platform. Its hospital customers now require ISO/IEC 27001 certification.
The first decision is scope. The company includes the diagnostic product line, its development environment, production cloud accounts, customer support operations and corporate functions that access those systems. It excludes unrelated consultancy work and a separate business unit with no access to the platform or its information assets. The scope statement records the exclusions and the interfaces between the included and excluded activities.
Existing ISO 13485 processes can be extended rather than duplicated. Document control supports ISMS policies and records. Training records support competence evidence. The CAPA process can handle security nonconformities and incidents where corrective action is required. Supplier control can be extended to the cloud provider and critical software suppliers, while management review can consider security objectives, risk treatment and audit results alongside QMS performance.
The genuinely new work begins with the information security risk assessment. The company must identify risks to patient-related information, development assets, production services, support records and supplier dependencies, then establish treatment decisions and create the SoA.
Several Annex A controls are likely to require specific treatment. 5.23 concerns cloud-service governance, including the relationship with the provider. 8.16 concerns monitoring activities across production and supporting systems. 8.28 concerns secure coding and the development lifecycle. Those controls may connect to existing software lifecycle management processes, but ISO 13485 records alone won’t prove that each security requirement is operating.
For a real example of a combined implementation, see our ISO 27001, ISO 13485 and GDPR case study. A sensible sequence is risk assessment first, followed by the SoA and treatment plan, then control implementation, evidence collection and internal audit before the certification assessment. Starting with a generic Annex A checklist would reverse that logic and leave the scope, risks and evidence misaligned.
Conclusion
ISO 27001 requirements describe a management system, not a parallel control project. A medical device company with ISO 13485 already has much of the machinery needed for documented information, competence, supplier control, internal audit, management review and corrective action. The additional work sits mainly in the information security risk assessment, the Statement of Applicability and the controls that affect cloud platforms, monitoring, threat intelligence and secure development.
The ISMS should therefore be integrated with the QMS while retaining its own risk register, objectives, competence evidence and audit criteria. Dutch organisations processing health information should also assess NEN 7510-1:2024, the Netherlands-specific healthcare information security standard (NEN 7510-1:2024). Certification won’t replace MDR or FDA product cybersecurity evidence, but a properly scoped ISMS can provide the governance structure in which that evidence is maintained.
Frequently asked questions
Is Annex A mandatory in full?
No. Annex A is a reference set of 93 controls, not a requirement to implement every control. The organisation must compare its risk treatment with Annex A and justify selected controls and exclusions in the Statement of Applicability under Clause 6.1.3 d).
Does ISO 13485 certification make ISO 27001 certification easier?
It can reduce duplicated management-system work, but it doesn’t remove ISO/IEC 27001 requirements. Existing processes for document control, competence, supplier management, audits, management review and corrective action can be extended, while information security risk assessment, risk treatment and the SoA require their own evidence.
What must an ISO 27001 risk assessment produce?
It must produce repeatable and comparable results using a defined methodology, identified risks and owners, risk analysis, evaluation and treatment decisions. Clauses 6.1.2, 6.1.3 and 8.2 establish the relevant requirements.
Does ISO 27001 cover medical device product cybersecurity?
Not by itself. ISO/IEC 27001 addresses the organisation’s ISMS and information assets, while product cybersecurity is addressed through applicable requirements such as Regulation (EU) 2017/745, Annex I Sections 17.2 and 17.4, and section 524B of the FD&C Act in the United States.
How often should the ISMS risk assessment be reviewed?
The risk assessment should be reviewed according to the organisation’s defined methodology and when material changes affect information security risk. New technologies, suppliers, systems or threat classes can require a reassessment of both treatment decisions and Annex A applicability.
Is NEN 7510-1 the same as ISO/IEC 27001?
No. NEN 7510-1 is the Dutch healthcare information security standard and should be assessed separately where its sector requirements apply. It relates to ISO/IEC 27001 but doesn’t make the international standard’s clauses or audit evidence disappear.
If your medical device or digital health organisation needs to scope an integrated ISO/IEC 27001 and ISO 13485 system, contact the MedQAIR team for a focused assessment of the requirements and evidence.
