ISO 42001 for healthcare AI and medical software: scope and timing

Does ISO 42001 for healthcare AI cover medical software, and when does it apply?

ISO/IEC 42001:2023 is a voluntary management system standard that applies to any organization that provides or uses products or services built on AI systems, including hospitals, health AI vendors and medical software makers. A certificate is never issued by the standard itself or by the organization: only an accredited external certification body can certify conformity, and ISO does not certify organizations. A health AI vendor facing a procurement questionnaire or a regulator's request should therefore first confirm which AI systems are in scope, since the standard covers the management system around them rather than any single product. Whether ISO 42001 covers medical software depends on the systems in scope, not on the word "medical" in the product description. The first question is whether an AI system falls under EU AI Act Article 6(1), which makes it high-risk when it is a safety component of a product, or is itself a product, covered by Annex I legislation that requires third-party conformity assessment. Under the amended timing in Article 113, those Article 6(1) and Annex I rules apply from 2 August 2028 instead of 2 August 2027. Teams should map each AI feature to its sectoral conformity route now, because under Article 43(3) the AI Act requirements are assessed inside that sectoral procedure, and the classification draft guidance from the Commission (19 May 2026) is the next document to read. The scope decision also sets the cost and timing, because it determines how much of the health information security estate must be covered. Ask the certification body and your advisers to confirm which systems, data flows and hosting environments fall inside the boundary, and which health information controls from ISO 27799:2025 will be mapped alongside the AI controls. Scoping, the number of systems, and whether existing ISO 27001 controls can be reused drive the effort, and each of these should be written into a fixed scope before any quote is accepted.

What ISO 42001 work for health AI costs, and who is paid for each part

This table lists each cost component of an ISO 42001 effort for a health AI product or service, who is paid for it, whether it is one-time or recurring, and what drives its size. Read it as a checklist to bring into quote requests, since the certification body, the implementation partner and your own clinical and quality staff each carry different parts of the bill. The main takeaway is that the certification fee is only one line, and the internal time and any sectoral medical device conformity work often matter more.

Cost component	Who is paid	One-time or recurring, and driver
Certification body stage 1 and stage 2 audits	Accredited certification body	One-time for initial certification. Driver: scope of AI systems, number of sites and the body's quoted audit days.
Surveillance audits after certification	Accredited certification body	Recurring between recertification cycles. Driver: the surveillance schedule in the body's contract and any scope changes.
Implementation partner fees	Implementation partner, such as DeployOpen, under a written fixed scope	One-time for the build, with optional retainers for upkeep. Driver: number of AI systems, existing management system maturity and evidence gaps.
Clinical, regulatory and quality staff time	Your own payroll or contractors	Largely one-time for the initial build, then recurring for reviews. Driver: how many clinical use cases, impact assessments and sign-offs are in scope.
Tooling for AI governance evidence	Your own infrastructure budget, licenses or open-source hosting	Often recurring for hosting and licenses. Driver: whether existing ITSM, document control and logging systems can hold the records.
ISO/IEC 42001 and ISO 27799:2025 standard copies	ISO and national standards bodies	One-time purchase per edition. ISO 27799:2025 is listed by ISO at CHF 204, so confirm current pricing on the ISO store.
Conformity assessment under sectoral medical device rules	Notified body or other conformity assessment body, where the product falls under Annex I legislation	One-time per product version, with later changes. Driver: device classification and whether the AI system is a safety component under Article 6(1).
Independent legal and regulatory advice	External counsel or regulatory consultants	Varies by question. Driver: how many jurisdictions and whether patient data crosses borders.

What makes health AI ISO 42001 scope larger or smaller

The scope of an ISO 42001 management system for healthcare AI depends less on the size of the organization than on which AI systems it builds, buys or runs, and what those systems do to patients. The six factors below decide how many Annex A controls apply, how deep the impact assessments go, and how much existing security work can be reused.

AI systems and Article 6(1) product status

Start by listing every AI system in the management system, then mark which ones are safety components of a product, or are products themselves, covered by Annex I legislation that requires third-party conformity assessment. Those systems fall under Article 6(1) of the EU AI Act and carry a separate conformity route. Under the amended Article 113, the high-risk rules for these systems apply from 2 August 2028. Confirm the classification with your regulatory team and the product's notified body before setting the scope.

Patient impact and clinical decision support

A system that informs diagnosis, triage or treatment choices widens the scope more than an administrative tool. ISO 42001 clause 6.1.4 and clause 8.4 require AI system impact assessment separately from AI risk assessment, and control A.5.4 asks you to document potential impacts on individuals or groups over the life cycle. Record which decisions the system influences, who can override them, and what happens when the output is wrong. Expect the impact assessment to be the longest document in the set.

Hosting in your own cloud or on premises

Systems hosted in the client's own cloud accounts, data centers or on-premises networks bring the hosting environment fully into scope, including access control, logging, patching and backup. A vendor-hosted model adds a supplier boundary instead, and the evidence must come from that vendor. Decide early which environment owns each component, because the statement of applicability must justify controls for each one. Confirm where clinical data is stored and processed before drawing the boundary.

Third-party AI components and model suppliers

Pretrained models, cloud AI services, imaging algorithms and embedded libraries each add a supplier relationship. Controls in the third-party objective area cover allocation of life cycle responsibilities, supplier management and customer expectations. Ask each supplier for its own AI governance evidence, any ISO/IEC 42001 certificate it holds and its scope statement, and confirm what the certificate covers. A supplier certificate covering a service does not automatically cover your product built on it.

Clinical data sources and data quality

Training, validation and operational data from electronic records, imaging archives or device feeds determine how much of the data objective area applies. Document where each dataset came from, how it was labeled, which populations it covers and how missing or biased values are handled. Gaps in representation across age groups, sexes or care settings are a scope issue, not only a model issue. Check whether the data includes personal health information, which brings GDPR obligations into the same review.

Reusing ISO 27001 and ISO 27799 controls

An organization already certified to ISO/IEC 27001 or operating health information controls under ISO 27799 can reuse access control, logging, incident handling and supplier security evidence instead of creating it again. ISO 27799:2025 provides health-specific implementation guidance on ISO/IEC 27002 controls. Map each reused control to the AI management system requirement it supports, and document where the AI system adds new evidence, such as model change records, that existing controls do not cover.

How impact assessment for patients differs from AI risk assessment

ISO/IEC 42001:2023 places AI system impact assessment in clause 6.1.4, under planning. It sits next to AI risk assessment in clause 6.1.2, but the two answer different questions. Risk assessment asks what could go wrong for the organization and how likely and severe each failure is. Impact assessment asks what the system could do to people, including patients, clinicians and other affected groups, if it works as designed or fails. A diagnostic triage model can be low risk to the hospital's systems and still have a serious impact on a patient who is wrongly deprioritized.

Scope of the affected population: List the patient groups, clinical settings and staff roles the system touches, including groups the vendor's training data may under-represent.
Foreseeable misuse: Record uses outside the intended clinical purpose, such as a model run on a population it was not validated for.
Benefit and harm: Describe both the expected clinical benefit and the harms, such as delayed care, false reassurance or over-reliance by clinicians.
Human oversight points: Name where a clinician can override, question or stop the system.
Decision and owner: Record who approved the assessment and the conditions under which deployment proceeds.

Confirm with your certification body how it expects impact and risk assessments to be recorded as separate documents or as linked sections of one.

Where ISO 27799 fits alongside ISO 42001 for health information security

ISO 27799 and ISO 42001 answer different questions, so a health organization or health AI vendor needs both. ISO 27799:2025 is the health-specific companion to ISO/IEC 27002: it gives implementation guidance for the information security controls that health organizations apply to patient data. The current edition is edition 3, published on 18 December 2025 by ISO/TC 215, and it replaced the 2016 edition. ISO/IEC 42001 does not replace it. ISO/IEC 42001 governs the AI management system itself, including policy, roles, risk and impact assessment, life cycle controls and third-party responsibilities. Neither standard substitutes for the other, and an assessor will expect to see the AI governance evidence and the health security evidence as separate, traceable records.

The practical work is mapping. For each AI system, list the health data it touches across training, validation, deployment and operation, such as training extracts, labeled imaging sets, prompts and model outputs written into the record, and logs. For each data flow, identify the information security control in ISO 27799 that governs it, and the ISO 42001 control that governs the AI decision or use, such as the data management and data quality controls in A.7 or the operation and use controls in A.6 and A.9. Record both references against the same system in the statement of applicability and the asset inventory so that a single review answers both questions. Confirm with your certification body how it expects dual references to be recorded, because the mapping format is an assessment choice, not a standard requirement.

ISO/IEC 27001 sits in the same position. Because ISO/IEC 42001 applies the harmonized structure shared by ISO management system standards, its clauses 4 to 10 line up with ISO/IEC 27001, which makes a combined management system practical. Many health organizations already run an ISO/IEC 27001 system, and ISO 27799 is commonly used to tailor its Annex A controls to health data. Decide early whether ISO/IEC 27001 is the security backbone with ISO 27799 as health guidance, and whether ISO/IEC 42001 is added as a parallel management system or integrated into one document set. Ask your certification body how it audits combined systems and whether it issues separate certificates for each standard.

How a health AI vendor moves from scoping to certification

The sequence turns an unscoped set of AI products into a documented AI management system that an accredited certification body can test in two audit stages. Each step produces a named artifact, and the organization keeps ownership of every decision in the chain.

Scope the AI systems and their Article 6(1) status
Start by listing every AI system the organization develops, supplies or deploys in or alongside clinical or health workflows, including components embedded in medical software. Regulatory counsel then decides, for each system, whether it is a safety component of a product or a product itself under Annex I legislation that requires third-party conformity assessment, which is the Article 6(1) test. Confirm the current application dates with counsel, since the topic facts record a later date for these rules. The output is a signed scope statement with a classification record for each system, which also sets the boundary for the statement of applicability and the certificate.
Run a gap analysis against clauses 4 to 10 and Annex A
Compare the current governance, risk, quality and data practices with the management system requirements in clauses 4 to 10 of ISO/IEC 42001:2023 and with the Annex A controls. Interview product, clinical safety, data science, regulatory and security owners, and review existing documents such as quality system procedures and design records. Record each gap against the clause or control it affects, with an owner and a priority. The output is a gap register that shows which items are missing, partial or already evidenced.
Write the statement of applicability with justified exclusions
Clause 6.1.3 requires a statement of applicability that lists the Annex A controls the organization needs and justifies including or excluding each one. For a health AI vendor, controls on life cycle verification, data provenance and user documentation usually carry clinical relevance, but each inclusion or exclusion must rest on the scope from step one. Have the accountable executive approve the document and keep the justification for every exclusion. The output is an approved statement of applicability that the certification body will test against the scope.
Complete the impact and risk assessments
Carry out the AI risk assessment under clauses 6.1.2 and 8.2 and the AI system impact assessment under clauses 6.1.4 and 8.4, which are separate requirements. The impact assessment covers effects on individual patients and groups, documented under control A.5.4, and effects on society. Use ISO/IEC 23894:2023 for risk method guidance and ISO/IEC 42005:2025 for impact assessment method guidance, and review the outputs with clinical safety and privacy staff. The output is a risk register and an impact assessment record for each in-scope system, with treatment decisions and residual risk accepted by a named owner.
Build out the evidence for each control
For each control in the statement of applicability, collect the artifact that shows it operates: policies, role definitions, data management records, verification and validation reports, technical documentation, event logs, supplier agreements and user documentation. Where health information security is in scope, map the relevant operational controls against ISO 27799:2025, which provides health-specific guidance on ISO/IEC 27002 controls. Store the evidence in a controlled repository with version history and retention rules. The output is an evidence index that links each control to its records and their owners.
Run internal audit and management review
Internal audit tests the management system against clauses 4 to 10 and the statement of applicability, using auditors who are independent of the systems they review. Findings go to the owners who raised them, with corrective actions tracked to closure. Top management then holds a management review covering audit results, impact and risk outcomes, incidents and objectives, and records its decisions. The output is an internal audit report, a corrective action log and minutes from a management review that show the system is being run and improved.
Undergo stage 1 and stage 2 audit by an accredited body
Select an external certification body and confirm it holds accreditation for ISO/IEC 42001 certification, since ISO does not certify organizations and accreditation of those bodies is voluntary. Stage 1 reviews the documented system and readiness for audit, and stage 2 tests whether the system operates in practice. The auditor issues any certificate; DeployOpen and other implementation partners do not. The output is an audit report and, if the outcome is positive, a certificate issued by the certification body, which is then maintained through surveillance audits.

Who owns controls, who prepares evidence, and who issues the certificate

The health organization or AI vendor owns the AI management system, the AI policy, the risk and impact decisions, and every clinical judgment about whether an AI output is safe for patient use. Ownership does not transfer to any outside party, even when an implementation partner builds the supporting systems. Internal leaders must be named for AI governance, clinical safety, data protection and information security, and they must approve the statement of applicability and the impact assessments.

Management and accountability: Leadership sets the AI policy, assigns roles and approves the scope of the management system.
Clinical sign-off: Clinicians and clinical safety leads decide whether a model is fit for each intended use, and they record that decision.
Impact and risk decisions: The organization decides which impacts on patients are acceptable and which mitigations are required.
Statement of applicability: The organization justifies the inclusion or exclusion of each Annex A control.
Ongoing operation: Staff run monitoring, incident handling and change approval after go-live.

Before engaging anyone, confirm which named individual signs each decision and where the records will be kept.

What must be in place before a health AI audit starts

An assessor will not start testing clinical AI controls until a few foundations exist and can be shown on request. The six cards below cover the records that tie an AI system to a named owner, a documented purpose, a completed impact assessment, traceable data, operating logs and the suppliers behind it.

Documented AI policy

The policy sets management direction for AI across the organization, including clinical decision support, imaging and administrative tools. Under ISO/IEC 42001 this sits in the A.2 policy controls, and an auditor will ask for the approved version, its approval date and the review record. To check it, confirm the policy names the health AI systems in scope, states who may approve deployment, and has been reviewed since the last change to a clinical system. (Illustrative: a policy that covers only the EHR vendor's features leaves imaging AI outside the audit.)

Named accountable owners

Each AI system needs a named person who answers for its performance, risk and use, plus clinical and technical roles that are written down. The A.3 internal organization controls ask for defined responsibilities and a route for raising concerns. To check it, pick three systems at random and confirm you can name an owner for each, that the owner knows the role exists, and that a clinician can report a safety concern to someone who is expected to act on it.

Defined AI system inventory

An inventory lists every AI system the organization develops, provides or uses, with its purpose, version, vendor, deployment location and clinical use. Without one, an assessor cannot confirm the scope of the statement of applicability or know which systems need impact assessment. To check it, compare the inventory against procurement records, software licenses and medical device registrations, and look for AI features switched on inside existing platforms.

Completed impact assessments

ISO/IEC 42001 requires AI system impact assessment separately from AI risk assessment, both during planning and during operation. Control A.5.4 asks the organization to document potential impacts on individuals or groups throughout the system's life cycle, which in health means patients, clinicians and vulnerable populations. To check it, confirm each in-scope system has a dated assessment, that it covers misdiagnosis and delayed care, and that it was repeated after the last material model or data change.

Data provenance records

Provenance records show where training, validation and operational data came from, under what legal basis and consent terms, and how it was prepared. The A.7 data controls expect these records to support quality and fitness for the intended clinical use. To check it, ask for the source, licence or consent basis, collection period and de-identification method for each dataset, and confirm that a vendor's claim about training data is backed by a document you can hold.

Event logs and supplier list

Event logs record system inputs, outputs, overrides, errors and updates in a form that can be reviewed after an incident. A supplier list names every third party that provides models, hosting, data or support, along with the responsibilities allocated to each under the A.10 controls. To check them, confirm logs are retained for a period your clinical governance sets, that they can be read without the vendor's help, and that every supplier on the list has a contract clause covering incident notice and change control.

Questions health AI buyers ask before hiring outside help

What drives the cost of ISO 42001 work for a healthcare AI product?

The cost is driven by how many AI systems are in scope, how many of the Annex A controls you choose to implement, and how much of your existing quality and security management you can reuse. Three parties are paid for different things: the certification body charges for the audit, an implementation partner charges for preparing systems and evidence under a written scope, and your own staff carry the time spent on clinical, quality and engineering reviews. Ask any partner for a quote that separates one-time work (gap analysis, policy and impact assessment templates, configuration of logging and records) from recurring work (internal audits, surveillance support, control monitoring). A quote built from a written scope is the only reliable basis for comparison, since DeployOpen does not publish a price list.

Can our own team implement ISO 42001 without an outside partner?

Yes, an organization can implement ISO 42001 with its own staff, and the standard does not require a consultant. The organization owns its controls, its AI policy and its accountability, and those must stay with named internal roles. Outside help is most useful where internal teams lack experience with management system audits, need to build self-hosted evidence pipelines for logs and model records, or have no capacity to run the impact assessments alongside existing product work. Whatever you choose, the certification itself is issued only by an independent certification body, and that body must not be the same firm that prepared your evidence. Confirm with any prospective partner which tasks they will do, which they will not, and who signs off each deliverable.

How long does preparation take, and what changes the timeline?

No supplied fact gives a standard duration for ISO 42001 preparation, so treat any published timeline with caution and ask for the basis. The main variables are the number of AI systems in scope, whether the organization already runs an ISO 27001 or quality management system that the AI controls can extend, how mature its documentation is, and how many clinical or regulatory reviews are needed before audit. Preparation in a single product line is generally shorter than a multi-site programme. Ask a prospective partner to break the timeline into scoping, gap analysis, control implementation, internal audit and readiness review, and to name the dependencies on your staff. Because certification bodies schedule their own audits, confirm their lead times separately.

What do clinical and quality staff need to contribute?

Clinical and quality staff are needed for the parts of ISO 42001 that decide whether an AI system is fit for its intended use. They typically review the intended purpose statement, define the patient populations and clinical settings the system covers, approve the impact assessment for patients and clinicians, and confirm how human oversight works in practice. Quality staff usually own the link between AI controls and existing quality records, change control and post-deployment monitoring. Expect these reviews to take recurring time, not a single workshop. Your engagement scope should name the people, their approval rights and the meetings required, so that clinical sign-off does not become the bottleneck at audit.

Does ISO 42001 satisfy EU AI Act or medical device rules?

No. ISO/IEC 42001 is a management system standard and does not replace the EU AI Act or the medical device regulations. The European Commission states that ISO/IEC 42001 helps set up an AI management system but does not match the AI Act's quality management system, for which EN 18286 was cited in the Official Journal on 14 October 2026 (Implementing Decision (EU) 2026/2274). For AI in medical devices, Article 6(1) makes a system high-risk when it is a safety component of a product, or is itself a product, covered by Annex I legislation that requires third-party conformity assessment. Under the amended Article 113, those rules apply from 2 August 2028 instead of 2 August 2027. Under Article 43(3), the conformity assessment follows the sectoral legislation. ISO 42001 can supply governance and impact assessment evidence that feeds those files, but you must confirm the applicable obligations with your regulatory and notified body advisers.

Is ISO 27799 required, or is it only guidance?

ISO 27799 is not a certification and no body issues a certificate against it. It is an information security guidance standard for health informatics, based on ISO/IEC 27002, that provides controls with implementation guidance for health organizations. The third edition was published on 18 December 2025 by ISO/TC 215 and replaced the 2016 edition. Whether you must follow it depends on your contracts, your national health authority and your customers, so confirm that requirement in writing. For ISO 42001, the practical value is using ISO 27799 to shape the security controls that protect patient data used by AI systems, while the AI-specific controls come from Annex A. Ask any implementation partner to map which ISO 27799 controls they will apply and which are assessed by your certification body or auditor.

How DeployOpen prepares health AI systems and evidence for assessment

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, and prepares the systems and evidence that an ISO 42001 assessment will examine. We do not issue audit reports or certificates; an independent certification body does that, and the organization owns its controls.

How we scope

Engagements are fixed-scope, with the systems, AI use cases and deliverables agreed in writing before work starts.
The written scope names which AI systems and clinical or operational workflows fall inside the AI management system.
Scope also records which Annex A controls are in the statement of applicability and who at the client owns each one.

How we build

We implement and configure the self-hosted open-source platforms that hold AI governance records, logs and documentation.
We help structure AI system impact assessments for patients and groups, kept separate from AI risk assessments.
Security testing of applications, APIs and AI systems can be scoped to produce evidence for controls the assessor will examine.

How we hand over

Deliverables include documented configurations, procedures, evidence repositories and records mapped to the agreed controls.
Client staff are trained to operate, review and update the records that the assessor will ask to see.
Ownership of policies, approvals and sign-off stays with the organization, and all artifacts are delivered in its own environment.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the written handover.
Retainers can cover updates to impact assessments when a clinical AI system or its data changes materially.
Before any certification body engagement, confirm in writing which parts of the evidence we prepare and which the auditor will test independently.

ISO 42001 for healthcare AI and medical software