ISO 42001, NIST AI RMF, and the AI Act: connect the roles

AI governance can combine a management system, a risk framework, and legal obligations. The engineering challenge is to connect them without pretending they are interchangeable. A policy, an evaluation report, and a legal classification decision may support the same AI service, but each answers a different question.

ISO/IEC 42001 establishes how an organization manages AI. NIST’s AI Risk Management Framework helps teams investigate and manage risks in context. The EU AI Act establishes legal duties according to the system, its intended purpose, and the organization’s operator role.

For a CTO, the useful outcome is one reviewable governance chain: a defined use case, accountable owners, implemented safeguards, test evidence, release decisions, and monitoring. Framework mappings should point into that chain while preserving requirements that still need technical, legal, or conformity-related work.

Understand what each instrument establishes

ISO 42001: make governance repeatable

ISO/IEC 42001 specifies requirements for establishing, implementing, maintaining, and continually improving an AIMS. Its management-system requirements cover organizational context, leadership, planning, support, operation, performance evaluation, and improvement.

This structure matters when several teams build or buy AI. It provides a basis for deciding who authorizes deployment, how impact and risk assessments are conducted, how supplier dependencies are handled, and how failures lead to corrective action.

The standard also includes reference controls in Annex A and implementation guidance. Control selection is risk-based and requires documented justification; copying the annex into a checklist does not establish that the management system works.

An independent certification body can assess the scoped AIMS. ISO itself does not certify organizations. Certification provides assurance about that management system within its stated boundary, not an unrestricted claim that every model or output is safe.

NIST AI RMF: investigate the actual risk

The NIST AI RMF organizes risk work around Govern, Map, Measure, and Manage. Govern is cross-cutting; the functions are not simply four sequential project phases.

Its trustworthiness characteristics include validity and reliability, safety, security and resilience, accountability and transparency, explainability and interpretability, privacy enhancement, and fairness with harmful bias managed. These characteristics can involve trade-offs. More detailed explanations, for example, may disclose information that needs privacy protection.

NIST guidance helps teams turn broad objectives into use-case-specific questions and evaluations. It also addresses accountability; governance is not reserved for ISO 42001. There is no NIST AI RMF certification scheme comparable to ISO management-system certification. An external assessment can support assurance, but its scope and methodology must be stated.

The AI Act: determine duties, not just risks

The EU AI Act regulates specified practices, AI systems, and general-purpose AI models through different provisions. Legal applicability is not determined by a technical risk score alone. Intended purpose, territorial scope, operator role, and specific classification rules matter.

A provider’s obligations differ from a deployer’s. A model is not the same thing as the application incorporating it, and calling software an “agent” does not settle its legal role or classification.

Start with scope and legal applicability

Maintain an AI inventory at the level of operational use cases, not just vendor names. One underlying model may support both an internal drafting assistant and an employment screening tool. Those deployments have different affected people, consequences, controls, and potential obligations.

For each use case, record:

• Intended purpose, supported decisions, prohibited uses, and deployment locations.
• System owner, technical owner, users, and affected people.
• Model and application suppliers, hosting arrangements, and dependencies.
• Data sources, outputs, integrations, and permitted actions.
• The organization’s operator role and the reasoning supporting it.
• Classification, applicable obligations, review date, and unresolved questions.

An organization outside the EU can still fall within the Act’s scope in specified circumstances. Conversely, having EU customers does not justify assigning every possible obligation to every product. Review the actual territorial and role conditions.

Separate prohibited practices, high-risk system requirements, particular transparency duties, and general-purpose AI model obligations. These are not interchangeable levels in a single engineering severity scale. An apparently low-impact chatbot may have transparency obligations; a high-impact use case requires a more detailed legal assessment.

Use the current implementation timetable

The European Commission’s AI Act overview, in the checked context of 7 October 2026, gives the following timetable:

Assess amended provisions, transitional arrangements, and the specific system separately. Do not postpone already applicable duties because a later high-risk date exists. Keep the legal assessment dated and use our AI Act readiness guide for timeline and role-assessment context.

Build one evidence chain, not three document libraries

A practical governance chain starts with the use case and ends with a reviewed decision:

Purpose → impacts and risks → requirements → safeguards → evaluations → approval → monitoring.

Each connection needs enough detail for someone outside the implementation team to inspect it. “Human oversight implemented” is insufficient if the reviewer cannot determine who can intervene, what they see, and whether intervention works.

Use a requirements record that distinguishes the source requirement from its implementation. A useful minimum schema includes the source and version, scope, requirement text or reference, local interpretation, control owner, linked evidence, reviewer, status, and residual gap.

Treat this table as an implementation aid, not an authoritative equivalence map. Relationships are many-to-many: one evaluation may support several requirements, while one requirement may need multiple controls and records.

Before reusing evidence, check its scope, date, system version, and conclusion. A test for one model configuration cannot automatically support another configuration. A corporate policy proves a documented rule exists; operational records are needed to demonstrate its execution.

Use NIST functions to define the engineering work

The NIST functions provide a useful way to organize implementation questions inside the AIMS. They should produce concrete artifacts rather than completed questionnaire fields alone.

Govern: establish decision authority

Define who owns the system, who independently reviews significant risks, and who can approve exceptions or stop deployment. Specify competence requirements and escalation paths. Connect these responsibilities to existing security, privacy, procurement, and incident-management processes.

A useful deliverable is a release procedure identifying required reviewers and evidence. Risk acceptance should name the decision-maker, rationale, conditions, and review trigger rather than merely recording “accepted.”

Map: describe context and consequences

Document the workflow before choosing metrics. Identify where AI influences decisions, who experiences the consequences, and what happens when outputs are wrong, unavailable, or misused.

Include foreseeable misuse and dependency failures. For an agent that can execute actions, map tools, credentials, accessible data, approval boundaries, and recovery paths. For third-party AI, record what the supplier controls and what remains your responsibility.

Measure: test the claims that matter

Choose evaluations tied to identified risks. Depending on the use case, these may include task accuracy, subgroup performance, robustness, privacy leakage, prompt injection, unauthorized actions, and operator comprehension.

Document dataset provenance, representativeness, test conditions, metrics, limitations, and acceptance thresholds. Measure the complete application where possible: retrieval, prompts, permissions, interfaces, and human workflow can change outcomes even when the underlying model stays constant.

Manage: implement treatment and follow-up

Translate findings into safeguards, restrictions, remediation, or a decision not to deploy. Examples include reducing tool permissions, requiring approval for consequential actions, excluding unsupported uses, or providing a reliable non-AI fallback.

Set monitoring thresholds and response procedures. A metric without an owner or response rule is only telemetry. Record which events trigger reassessment, including supplier updates, changed data sources, expanded uses, and incidents.

Make ISO 42001 auditable through operating records

If certification is an objective, define the AIMS boundary before preparing for an external audit. The scope may cover a particular product, business unit, or set of lifecycle activities, but it should clearly describe included activities and interfaces. A narrow scope must not be presented as organization-wide assurance.

Perform a gap assessment against the management-system requirements and applicable controls. Establish policy, objectives, risk and impact assessment methods, documented control applicability, responsibilities, and operational procedures. Then generate evidence that these processes actually operate.

Useful records include completed assessments, supplier reviews, training records, release approvals, monitoring reviews, corrective actions, internal audit findings, and management review decisions. Internal audit and management review are distinct activities: one evaluates conformity and effectiveness; the other supports leadership’s assessment and direction of the management system.

An independent certification process commonly includes readiness and implementation assessment stages. Agree the scope and audit arrangements with the certification body rather than treating certification as a paperwork submission. Continue monitoring, internal review, and improvement after certification.

Neither a certificate nor an RMF assessment replaces an applicable AI Act conformity assessment. The conformity route depends on the system and relevant provisions; not every high-risk system requires the same third-party route. Declaration, registration, marking, and reporting requirements must likewise be checked for the relevant role and system.

Worked example: a hiring-related AI deployment

Illustrative assumptions: an EU employer buys an application that ranks applicants for interview review. The vendor supplies the application, while the employer configures job criteria and uses rankings. Recruiters make final hiring decisions. Assume legal review identifies an Annex III high-risk employment use and initially identifies the employer as deployer.

This is not resolved by saying “a human makes the final decision.” Ranking can materially influence who receives consideration. The assessment must examine the actual workflow, including whether recruiters routinely ignore applicants below a cutoff.

Establish the system-specific record

The technical owner records input fields, ranking logic information available from the supplier, application version, configuration, users, and export destinations. Procurement requests supplier instructions, limitations, relevant evaluation evidence, change notifications, and support for the organization’s obligations.

Legal review documents classification and role assumptions, including whether future modification or rebranding could alter the role. Privacy review separately assesses applicant-data processing. AI governance does not substitute for data-protection analysis.

Test and implement safeguards

Using NIST’s Map and Measure functions, the team evaluates representative recruitment scenarios, missing-data behavior, and performance differences across relevant groups where lawful and feasible. It documents uncertainty and sample limitations rather than presenting a fairness metric as proof that all harmful bias has disappeared.

Human oversight includes recruiter training, visible limitations, a route to review excluded applications, and the ability to suspend ranking. The team tests whether reviewers understand outputs and can override them without operational obstruction.

Security controls restrict access to applicant records and prevent unapproved exports. Change control requires reassessment when ranking criteria, models, or supplier processing arrangements change.

Keep the three conclusions separate

The AIMS record demonstrates how assessments, ownership, supplier review, and approval processes operated. The RMF record explains the contextual risks, tests, treatment, and residual uncertainty. The legal record identifies applicable deployer duties, timing, and outstanding work.

Suppose the supplier has not provided sufficient instructions for reliable oversight. The release record should show that gap, its owner, and the decision to delay or restrict deployment—not a green status inherited from the employer’s ISO certificate.

Choose priorities and maintain evidence after release

Prioritize applicable legal duties and unacceptable operational risks first. ISO certification can proceed alongside remediation, but an audit target should not displace urgent controls.

If teams lack consistent ownership and review processes, build the AIMS foundation. If governance exists but system evaluations are weak, use the RMF to improve contextual analysis and testing. If a customer requires certification, confirm the expected scope before budgeting.

Avoid universal cost or duration assumptions. Effort depends on the number of systems, existing governance, evaluation needs, supplier visibility, and remediation. The RMF is freely available, but implementation still consumes staff time; ISO certification adds standard-access and external-assessment considerations.

After release, assign review triggers to artifacts. A supplier model update may invalidate evaluation results; a new action permission may change the threat model; a new market may require legal reassessment. Preserve previous versions and decisions so reviewers can reconstruct what was approved at the time.

Common mistakes include treating mappings as compliance, collecting policies without operational evidence, accepting supplier claims without deployment-specific analysis, and recording residual risk without a decision owner. Another is measuring model quality while ignoring application permissions and human behavior.

Secani can support the evidence workflow by connecting requirements, controls, source material, owners, tasks, and reviewed decisions. Start with one defined scope, attach evidence to what it supports, and turn missing or outdated material into assigned work. Treat AI-assisted suggestions as drafts: a human should review mappings and conclusions, with sources and approval reasoning preserved. This keeps the governance basis inspectable without replacing engineering or legal judgment.

Questions that affect implementation

Can existing security controls be reused?

Yes, where their implementation and evidence cover the AI deployment. Access control, incident response, and supplier management often contribute. They do not, by themselves, answer questions about harmful bias, intended purpose, or effective human oversight.

What if a supplier will not disclose model internals?

Record the visibility limitation. Seek evidence proportionate to the use case, evaluate the deployed application, and determine whether contractual assurances, restrictions, or alternative suppliers are necessary. Missing visibility is not automatically acceptable because the service is commercially available.

What should the team do first?

Choose one consequential use case and assemble its owner, purpose, role assessment, risk record, safeguards, tests, and approval. Review the gaps across all three instruments. That bounded exercise reveals whether the organization needs better governance, better technical evidence, or unresolved legal work before expansion.