Compliance Guide | Financial Services

    Should Banks Pursue ISO/IEC 42001 Certification? Scope Decisions and Examiner Expectations

    Certification can be worth pursuing when a specific audience, such as the board, counterparties or vendor reviewers, needs independent confirmation of your AI management system, and when the scope covers the AI activities that audience cares about. Certification is voluntary. It attests to a management system, not to any model's behavior, and it does not replace the model risk management, third-party risk and interaction-level evidence that examiners review directly.

    What an ISO/IEC 42001 certificate attests to

    ISO/IEC 42001 is the international standard for AI management systems. It defines how to establish, implement, maintain and continually improve one. An AI management system, in the standard's terms, is the set of interrelated elements of an organization that establish policies, objectives and processes for the responsible development, provision or use of AI systems.

    Certification is voluntary. Independent certification bodies, which may be accredited by national accreditation bodies, confirm that the management system meets the requirements of ISO/IEC 42001:2023. ISO/IEC 42006:2025 adds requirements for the bodies that audit and certify against the standard, which matters when you vet a certifier.

    Two points follow. First, ISO says adopting the standard already delivers significant value and that certification adds stakeholder confidence, so implementing the management system and certifying it are separate decisions. Second, read plainly, the certificate concerns an organizational system. It is not a statement that a particular model performs well or that a particular interaction complied with policy.

    How examiners are likely to treat it

    Examiners assess banks against existing supervisory frameworks: model risk management guidance (SR 11-7 and OCC 2011-12), third-party risk management, and applicable state or international AI rules. ISO/IEC 42001 is not a regulatory requirement, and a certificate does not stand in for any of those reviews.

    The interagency third-party guidance offers a useful reading. It says a bank may consider conformity assessments or certifications by independent third parties against relevant domestic or international standards, and may consider whether their scope and results are relevant to the activity performed. Expect the same logic to apply to your own certificate: a reader will ask what it covers before asking what it proves.

    The OCC's November 2026 supervisory framework on 'super intelligence' states that it establishes no new supervisory expectations and tells examiners to tailor reviews to the materiality of the use case. It does not mention ISO/IEC 42001. As of November 2026, nothing in these materials treats certification as a requirement. The practical stance is to position a certificate as a supporting artifact in examiner dialogue, never as the evidence itself.

    Scope options and what each one buys

    The scope statement is where certification gains or loses credibility. A narrow scope that leaves out the AI systems examiners care most about invites questions. A broad scope you cannot evidence at audit creates its own exposure. Match scope to the decision the certificate is meant to support.

    • Enterprise-wide: Strongest signal of organization-wide accountability. Highest preparation effort, and every in-scope system must be evidenced consistently.
    • Selected business lines: Aligns with where AI is most material and where governance is already mature. The certificate says little about AI used elsewhere in the bank.
    • Selected AI systems or use cases: Focuses effort on the highest-materiality uses. Value depends on whether a reader sees those systems as the relevant ones.
    • Vendor and embedded AI treatment: Decide whether third-party and embedded AI sit inside the management system. Excluding them leaves a visible gap, since third-party due diligence must be tailored to the activity.
    • Lifecycle stages: Covering development, provision and use separately clarifies who owns what. Omitting operation leaves the certificate silent on live behavior.

    Mapping the management system to model risk management

    Avoid building a parallel structure. Map management-system requirements to the model inventory, validation, monitoring and third-party processes you already operate, and assign named owners from existing model risk and third-party risk roles. ISO describes accountability under the standard as embedded across operations, so ownership mapping is where the standard becomes concrete.

    Impact assessment is a required element in ISO's description of the standard, with ISO/IEC 42005 supporting system-level assessment. Decide early how those assessments connect to model validation and risk assessment documentation so one record serves both purposes.

    The NIST AI RMF organizes activity into govern, map, measure and manage, and offers a second lens for the mapping. A crosswalk between the NIST AI RMF and ISO/IEC 42001 is hosted by NIST's AI Resource Center, but it was submitted by the user community and is not shown as regulator-endorsed. Use it as a starting aid and validate it internally. Expect gaps where the standard describes organizational policies, objectives and processes while model risk management expects evidence about individual models and their use.

    The evidence certification alone will not provide

    A certification audit examines the management system. Examiners also want to see what specific systems were permitted to do and what they did. Plan for those requests separately, because the management-system audit does not generate them.

    • Model inventory, validation and ongoing monitoring records for in-scope models
    • Third-party due diligence tailored to the specific vendor activity, with the vendor's certificate scope checked for relevance
    • Documented limits on what each AI system, agent or tool was permitted to do
    • Interaction-level records of what the AI actually did, including tool calls
    • Records of blocked, redacted or escalated actions and the human approvals that followed
    • Retention and data residency arrangements for that evidence

    Where runtime enforcement evidence fits

    Trussed addresses the runtime part of this gap. It enforces policy in the execution path across models, agents, tools, MCP servers and coding assistants: allow, redact, block, rate limit, or escalate for human approval. Enforcement is applied to individual interactions and tool calls, and it produces audit-ready evidence of what the AI was allowed to do and what it did.

    That evidence can support management-system controls and respond to examiner requests. It does not certify a management system and is not a route to ISO/IEC 42001 certification. Trussed's deployments are deepest in insurance, another regulated sector, and the value for a bank is the same question examiners ask everywhere: can you show what happened at the interaction level.

    What certification covers and what examiners test

    Certificate attests to

    An AI management system meeting ISO/IEC 42001:2023 requirements, confirmed by an independent certification body.

    Examiners test against

    Existing frameworks: model risk management guidance, third-party risk management and applicable state or international AI rules.

    Scope decides value

    Business units, AI systems, vendors and lifecycle stages determine whether a reader finds the certificate relevant.

    Evidence gap

    Records of what AI was allowed to do and what it did come from systems, not from the management-system audit.

    Decide the scope before you decide on certification

    Start from the audience the certificate must satisfy and the evidence examiners will request. Then test whether your current records show what AI was allowed to do and what it did.

    Talk to an Expert