ISO/IEC 42001: the technical layer inside an AI management system
ISO/IEC 42001 asks an organisation to govern the AI systems it develops or uses. Most of that work is governance: policy, roles, risk and impact assessment, lifecycle decisions, third-party management. The question an auditor eventually asks is whether any of it is running. That is the gap AI-FW fills.
- The instrument
- ISO/IEC 42001:2023, the AI management system standard, with its Annex A controls
- Status
- In force (first edition)
- Who it applies to
- Organisations building or operating an AI management system, and suppliers asked to evidence controls inside a customer's system.
Where AI-FW fits
AI-FW is a technical control layer inside your AI management system, and the assurance mechanism that shows the controls are live rather than declared. It provides the inventory and category evidence that risk and impact assessments consume, enforces runtime behaviour, and produces reproducible evidence for monitoring, internal audit and management review.
What stays with you
Read this list first. It is the boundary of what a product can do for you, and it is where the remaining work sits.
- The management system itself: AI policy, objectives, roles, competence and documented information
- The AI risk assessment and the AI system impact assessment, including societal and individual impacts. The product supplies evidence rather than performing the assessment
- Lifecycle decisions: design, verification and validation, deployment, monitoring and decommissioning choices
- Third-party due diligence and contracts for every AI provider in the inventory
- Internal audit, management review, corrective actions and the certification audit
What the framework asks, and what the product does
The obligations that touch the AI path, paired with the capability that answers each one. Everything else in this framework is organisational work, listed above.
A defined policy, with roles and responsibilities people understand
Enforcement boundaries that make the policy concrete, and role policies that map onto the roles your management system defines
Document the resources behind AI systems, and assess their impact
A model inventory plus the mix of data categories crossing the gateway, which is the factual basis an impact assessment needs
Document how each AI system is intended to operate, and under what constraints
Per-model configuration covering approved endpoint, request style, streaming and parameter policy, with every change audited
Verify and validate systems before deployment
Guard rules that must exist before traffic is allowed, so validation is a precondition rather than a line in a checklist
Monitor systems once they are in operation
Live dashboards, risk profiles, drift findings and assessment history, with each period comparable to the last
Retire systems under control
Removing a model from the inventory and blocking its traffic is an auditable change, so retirement leaves a trace
Govern acquisition, quality and provenance of data
Sensitive-data rules constrain what may enter prompts, and category telemetry records what actually crossed
Keep use within the intended purpose, with human oversight
Approval queues for sensitive operations, risk thresholds and per-agent grants, with unapproved use blocked rather than flagged afterwards
Manage suppliers, customers and partners
A model inventory enumerating every external provider and endpoint, ready for supplier assessment and contract review
Inform interested parties about incidents
Error, violation and blocked-call signals with attribution and timestamps, and an audit trail that reconstructs what happened
Evaluate how well AI controls perform
Scheduled assessment, a posture score that trends over time, and gaps reported into management review
Take corrective action and show that it worked
A gap list with owners and expiry dates becomes the corrective-action backlog, and re-assessment shows effectiveness
A rule pack to start from
The enforcement that makes the controls real. Severity runs 1 to 5, and a rule that is switched off reports as a gap, so these are meant to be live from day one.
The policy you wrote, enforced rather than published
Data governance for AI systems, applied at the boundary
Intended purpose, with the inventory behind it
Robustness and security for the deployed system
Output integrity: observe first, then block where your policy requires it
What the evidence pack contains
Per period, and without prompt or response content, which is what makes it safe to hand over.
- Control statusesAgainst the AI management system controls in scope
- Model inventory snapshotThe asset view your impact assessment consumes
- Enforcement stateLive rule state, including anything currently switched off
- Approval and incident activityOversight decisions and incident signals in the period
- Assessment trendShows the controls improving, or drifting, over time
Customer responsibilities and sources
- Run the management system: AI policy, objectives, roles, competence and documented information.
- Complete the AI risk assessment and the AI system impact assessment, for which the product supplies evidence rather than answers.
- Record lifecycle decisions, including verification, validation, deployment and decommissioning.
- Perform supplier due diligence, and hold contracts for every AI provider in the inventory.
- Run internal audit and management review, and complete the certification audit with your chosen body.
Common questions
27001 is an information security management system that covers your AI traffic incidentally. 42001 is a management system for AI itself, so it asks about AI policy, impact assessment, lifecycle and AI literacy. The same gateway supports both, and organisations running AI at scale usually need the pair, because they answer different auditor questions.
An impact assessment needs facts: which systems exist, what data they handle, who uses them, what is blocked, and what trends are emerging. Those facts come from telemetry and inventory rather than from a workshop. The product supplies the facts and the audit trail behind them, and your assessors draw the conclusions.
That is one of the more practical uses. If a supplier runs a governed AI path, the assessment history and evidence packs answer much of an Annex A style questionnaire with artefacts rather than assertions, which is what makes the answers worth reading.
Validate it yourself with our Technical Plan
Ask us to run this framework against your own environment: the rules that would be created, what the assessment reports, and what the evidence pack contains for a real period.
This page maps product capabilities to published expectations. It is not legal, audit or certification advice, and it creates no compliance representation. Applicability and sufficiency are judgements for your counsel and, where relevant, your auditor, assessor or certification body. Framework details are current as reviewed; check the primary sources above, and the page itself, before relying on a date or a threshold.