Best tools for ISO 42001 readiness: GRC platforms vs runtime control planes

What ISO/IEC 42001 asks tooling to support

ISO/IEC 42001:2023, titled "Artificial intelligence — Management system", specifies requirements for establishing, implementing, maintaining and continually improving an AI management system (AIMS). It is a management system standard. It is not a technical enforcement specification, and it does not name a tool category.

That shapes the buying decision. Establishing and maintaining an AIMS involves scope, roles, policy, risk assessment and improvement cycles. Those are organizational activities, and a GRC platform is built to run them. Implementing and operating the system also means the AI systems in production behave in line with what the policy says. Documentation cannot show that on its own. A written control and an operating control are different things, and an audit can ask for both.

NIST AI RMF reinforces the distinction. Its MEASURE 2.4 states that the functionality and behavior of the AI system and its components are monitored when in production. NIST treats production monitoring as its own activity, separate from governance documentation. It is a supporting reference here, not an ISO 42001 requirement.

Comparison by requirement area

The table compares the two categories across the areas a readiness program has to cover. It describes typical strengths, not a ranking. Individual products vary, so confirm each against your own scope.

• Management system scope and roles: GRC platform: strong fit for defining scope, assigning owners and managing policy approval workflow. Runtime enforcement: not designed for this. Organizational roles and management system governance sit outside its coverage.
• Risk assessment: GRC platform: strong fit for risk registers, assessment workflows and treatment tracking. Runtime enforcement: can apply the resulting policy decisions to individual interactions and tool calls, but does not perform the assessment.
• Operational control: GRC platform: records the control and who owns it. Runtime enforcement: applies the control in the execution path, for example allow, redact, block, rate limit or escalate for human approval.
• Monitoring of AI behavior: GRC platform: holds monitoring procedures and review results, often attached manually or by attestation. Runtime enforcement: observes and decides on live interactions and tool calls as they happen.
• Audit evidence: GRC platform: organizes documents, assessments and attached artifacts. Runtime enforcement: generates evidence from enforcement itself, showing what the AI was permitted to do and what it did.
• Model and dataset lineage: GRC platform: can record lineage information supplied by other systems. Runtime enforcement: does not cover model or dataset lineage.

Documented controls versus operating controls

When you work through the Annex A control objectives, sort each one by the kind of proof it needs. Some objectives are satisfied by a defined policy, an assigned responsibility, a completed assessment or a recorded decision. Those are documentation-and-workflow controls, and a GRC platform handles them well.

Other objectives only mean something if the AI system actually behaves a certain way: sensitive data is not exposed, an agent calls only the tools it is permitted to call, a high-risk action waits for a person. For these, a policy document shows intent and nothing more. The evidence that matters is a record of the decision made at the moment of each interaction or tool call.

The common failure is treating the first kind of evidence as if it covered the second. A risk register entry that says an agent must not send certain data externally is a documented control. Whether the agent was stopped from doing so is an operating control, and it needs enforcement and a durable record. Evidence compiled by hand or by attestation depends on someone recalling and summarizing behavior. Evidence produced by enforcement is generated as a by-product of the control operating. Readiness work should say, objective by objective, which kind applies.

Where a runtime layer fits, and where it stops

A runtime enforcement layer is relevant where controls must be applied inside the execution path of models, agents, tools and MCP servers. Trussed operates in this category. It enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants, using allow, redact, block, rate limit and escalate for human approval. Enforcement is at the level of individual interactions and tool calls, and it generates continuous audit-ready evidence. Policy is enforced at runtime, not reviewed after the fact. Trussed can be self-managed in the customer cloud, with configurable retention and data residency.

Its evidence is mapped to HIPAA, NAIC, NYDFS, EU AI Act and NIST. Mapping that evidence to your own AIMS controls remains part of your readiness work. In production it has run continuously for 18+ months in a regulated enterprise, at 99.95% uptime on live production traffic, with 100+ models under one policy plane and 30+ GB of audit evidence generated per day.

The limits matter as much. Trussed is not a GRC platform and does not manage management system governance, organizational roles, policy approval or risk registers. It does not provide model provenance, model lineage or dataset provenance. It does not provide business transaction identity or end-to-end tracing of agentic workflows. Those needs stay with your GRC platform, your engineering systems or other tools.

Choosing a GRC platform, a runtime layer, or both

If your AI use is limited and mostly human-reviewed, and your open work is policy, scope, ownership and risk assessment, a GRC platform may be enough to start. If you already have a governance program and the gap is proving that live models, agents and tool calls follow policy, a runtime enforcement layer addresses that gap. A GRC platform cannot supply it, because the evidence has to come from the execution path.

For most regulated enterprises running agents or tool-connected models in production, the practical answer is both. Use the GRC platform as the system of record for the AIMS: scope, roles, risk treatment and control mapping. Use runtime enforcement where a control has to operate on every interaction, and let its evidence support the matching entries in the GRC record.

A sensible sequence is to list your Annex A control objectives, mark each as documentation-and-workflow or operating, and confirm which tool produces the evidence for each. Any objective without an evidence source is a readiness gap, whichever category you buy.