Compliance Guide for Healthcare

    ISO 42001 Certification for Hospitals and Health Systems: Is It Worth Pursuing?

    ISO/IEC 42001 is a voluntary management system standard. Certification by an independent body confirms that a hospital's AI management system meets the standard's requirements. It does not replace HIPAA obligations, and by itself it does not record what an individual AI system did with PHI at runtime. Certification is worth pursuing when stakeholders ask for it, the scope is defined, and the organization has a separate source of operational evidence.

    Decision criteria for certifying

      What ISO/IEC 42001 certification attests to

      ISO/IEC 42001 specifies requirements for establishing, implementing, maintaining and continually improving an Artificial Intelligence Management System (AIMS). ISO defines an AIMS as a set of interrelated or interacting elements of an organization intended to establish policies, objectives and processes for the responsible development, provision or use of AI systems. The standard is designed for entities that provide or use AI-based products or services, which covers a health system that buys, embeds or builds AI.

      It is a management system standard. ISO describes it as an integrated approach to managing AI projects, from risk assessment to effective treatment of those risks. Certification is voluntary and is carried out by independent certification bodies, which may be accredited by national accreditation bodies. A certificate is therefore independent confirmation that the management system meets the requirements of ISO/IEC 42001:2023. It is evidence of process maturity: that the organization has defined how AI is governed, risks assessed and treated, and the system improved over time.

      What a management system certificate does not show

      A management system describes how an organization manages AI. It does not, by its nature, produce a record of each interaction between a clinical, operational or administrative AI system and the PHI it touched. Those are different kinds of evidence. A certificate can show that a risk assessment process exists. It cannot show that a specific prompt containing PHI was redacted, that a tool call was blocked, or that a human approved an exception on a particular date.

      This distinction matters for HIPAA. The Security Rule technical safeguards at 45 CFR 164.312 include the audit controls standard at 164.312(b). Evidence for system-level technical safeguards comes from the technical controls themselves, which are separate from the management system. A board or auditor asking what an AI system was allowed to do, and what it did, needs that second layer in addition to a certificate.

      ISO also frames the standard as a management framework that supports compliance. It does not displace legal obligations. Under 45 CFR Part 164 Subpart C, covered entities and business associates must comply with the applicable standards, implementation specifications and requirements for ePHI regardless of whether they hold any ISO certificate.

      Mapping 42001 to existing HIPAA and NIST programs

      Most health systems already have HIPAA risk analysis and risk management records. HHS describes effective risk management as an essential component of both Security Rule compliance and broader cybersecurity preparedness. Because ISO/IEC 42001 centers on AI risk assessment and treatment, those existing records are a practical starting point for an AIMS rather than something to rebuild. NIST also publishes a resource guide for implementing the HIPAA Security Rule, which is useful reference material for the HIPAA side of any crosswalk.

      A workable approach is to build one crosswalk with three columns: the AIMS requirement, the HIPAA requirement it relates to, and the NIST AI RMF function it relates to. For each row, record the owner, the artifact that proves the control exists, and the artifact that proves it operated. The second artifact is where gaps usually appear, because process documents are easy to produce and per-interaction records for AI handling PHI are not.

      Keep the regulatory baseline current. HHS published a proposed rule in January 2025 to strengthen the cybersecurity of ePHI under the Security Rule. If finalized, it would amend the existing rule. As of November 2026, the current Security Rule text is the controlling requirement, and the proposal should be monitored rather than assumed.

      Scoping clinical, administrative and vendor AI

      Scope is the largest lever in the decision. A narrow scope, such as administrative AI used for documentation or scheduling support, is easier to describe and audit. A broad scope that includes clinical decision support raises the stakes for risk assessment and for the evidence you must be able to produce. Neither choice is wrong, but the certificate should be described accurately to stakeholders as covering only what is in scope.

      Third-party and embedded vendor AI deserves explicit treatment. Many AI capabilities arrive inside existing clinical and operational software, and the organization still carries HIPAA obligations for the ePHI those capabilities handle. Decide early whether the AIMS covers how such AI is selected, approved and monitored, and which technical controls apply to it. Certification of the management system does not change the fact that each system still needs its own enforceable limits.

      If stakeholders ask only for assurance that AI is controlled, a clearly documented program with strong operational evidence may answer the question. If they specifically ask for ISO/IEC 42001, only certification answers it.

      Where runtime enforcement and evidence complement a management system

      An AIMS defines what should happen. Runtime controls make it happen and record that it did. Trussed operates in this second layer. It enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants, with actions to allow, redact, block, rate limit or escalate for human approval. Enforcement applies to individual interactions and tool calls, so policy is enforced at runtime, not reviewed after the fact.

      Each enforcement decision generates continuous audit-ready evidence, mapped to HIPAA and NIST, among other regimes. For a health system, that supports the operational question behind 164.312(b): what an AI system was permitted to do with PHI and what it did. Trussed can be self-managed in the customer cloud, with configurable retention and data residency, and it runs in production with healthcare organizations.

      Trussed is not a certification tool and does not replace an ISO/IEC 42001 program. It supplies operational evidence that an AIMS, a HIPAA program and a NIST AI RMF crosswalk can point to when an auditor asks for proof rather than policy.

      Two layers of AI assurance in a health system

      Management system

      Policies, objectives and processes for responsible use of AI, assessed through ISO/IEC 42001 certification.

      Regulatory obligations

      HIPAA Security Rule requirements that apply independently to covered entities and business associates.

      Runtime evidence

      Records of what each AI interaction was allowed to do and did, produced by technical controls.

      Test your certification decision against operational evidence

      Talk through scope, existing HIPAA records and the runtime evidence your AI systems would need to produce.

      Talk to an Expert