ISO/IEC 42001's Annex A groups its controls into nine areas: AI policies, internal organisation, resources, impact assessment, the AI system life cycle, data, information for interested parties, use of AI systems, and third-party relationships. For an agent platform, each maps to concrete controls: per-capability authority, versioned briefs, provenance of sources, event logs, oversight and supplier terms.
What do the ISO/IEC 42001 controls require?
ISO/IEC 42001 requires an organisation to determine the controls needed to treat its AI risks and to compare them with the reference set in Annex A, recording each decision in a statement of applicability. The Annex A areas, in substance:
- Policies related to AI: a documented AI policy, aligned with other policies and reviewed.
- Internal organisation: defined roles and responsibilities for AI, and a way to report concerns.
- Resources for AI systems: documented data, tooling, computing and human resources.
- Assessing impacts of AI systems: a process for impact assessment, with results documented.
- AI system life cycle: objectives and processes for responsible design and development, requirements, documentation, verification and validation, deployment, operation and monitoring, technical documentation and event logs.
- Data for AI systems: data management, acquisition, quality, provenance and preparation.
- Information for interested parties: documentation for users, external reporting, communication of incidents.
- Use of AI systems: processes and objectives for responsible use, and use in line with intended purpose.
- Third-party and customer relationships: allocating responsibilities, and managing suppliers and customers.
Not every control applies to every organisation. You justify inclusions and exclusions.
Who does it apply to?
Organisations implementing an AI management system under ISO/IEC 42001, including agent platform vendors and firms that deploy agents. A vendor and its customer will map the same areas differently, because they play different roles. The decision whether to adopt the standard is covered in do you need ISO/IEC 42001 to deploy AI agents.
What does each area mean when the system is an agent that acts?
The controls were written for AI systems in general. For agents, three areas carry most of the weight.
The life cycle area must cover briefs, not just models. An agent's behaviour changes when its instructions, sources or permissions change, often with no change to the model. Verification, validation and deployment controls must apply to those changes.
The data area must cover runtime facts. For trained models, data controls focus on training sets. Agents depend mostly on facts retrieved at the moment of use. Provenance and quality controls need to reach those facts.
The use area must define authority. "Use in line with intended purpose" for an agent means limiting what it may do, per capability, and enforcing that when it acts. Human oversight sits here too; our guide to ISO/IEC 42001 human oversight controls for AI agents goes deeper.
How do the controls map to an agent platform?
| Requirement | Control | Evidence it leaves |
|---|---|---|
| Policies related to AI | AI policy states how agents gain, keep and lose authority | Approved policy; review record |
| Internal organisation: roles | Named owner per agent; defined roles for approval and oversight | Owner register; role descriptions |
| Internal organisation: reporting concerns | Staff and customers can flag agent behaviour; flags reviewed | Concern log |
| Resources | Agent register listing model, sources, tools and people involved | Agent register |
| Impact assessment | Assessment per capability affecting people | Impact assessments |
| Life cycle: requirements and design | Brief defines role, sources and permitted actions per capability | Versioned briefs |
| Life cycle: verification and validation | Testing on real cases before any capability acts; recertification on change | Test and certification records |
| Life cycle: deployment and operation | Authority enforced at the moment of action | Verdict records |
| Life cycle: event logs | Append-only record of actions and decisions | Log store |
| Data: quality and provenance | Every fact the agent uses carries its source and class | Provenance labels in records |
| Information for interested parties | Users and customers told what agents do; incidents communicated | Disclosures; incident notices |
| Use: intended purpose | Actions outside a capability's scope refused | Refusal records |
| Third parties: suppliers | Model provider and platform assessed; change notification terms | Supplier assessments; contracts |
| Third parties: customers | Responsibilities between vendor and deploying firm allocated in writing | Responsibility matrix |
Refusal records appear twice in the table for a reason. An auditor wants to see that limits exist and work. A log showing actions refused because they fell outside scope is stronger evidence than a policy stating that they would be.
What will a certification auditor ask?
- Show us your statement of applicability. Why did you exclude any Annex A controls?
- How do life cycle controls apply when an agent's instructions change?
- Where does the agent's runtime data come from, and how is provenance recorded?
- How is intended use enforced, not just described?
- What do you tell customers about the agents that serve them?
- How are responsibilities split between you and your platform vendor?
What do the controls not cover?
They do not include detailed information security controls; those come from ISO/IEC 27001, covered in does ISO/IEC 27001 cover AI agents. They do not set performance thresholds. They do not equal legal compliance. For how the standard compares with the US framework, see NIST AI RMF vs ISO/IEC 42001 for AI agents; for the standard itself, what ISO/IEC 42001 is; and for the full regulatory map, AI agent regulation, mapped to controls.
This is an explanation of the rules, not legal advice; confirm how they apply to you with counsel.
Where Pryme fits
Several Annex A areas map directly onto Pryme. Agent Studio produces a versioned brief per agent. Attest certifies each agent before it acts. The minimum chain enforces intended use at the moment of action, and the Pryme Context Protocol records the provenance of every fact. Every verdict is filed in an append-only record that serves as the event log.
Questions people ask
Can a deploying firm rely on its vendor's controls?
For some areas, such as event logging and data provenance on the platform, yes, with evidence from the vendor. For policy, impact assessment and intended use, the deploying firm must have its own controls.
Are all Annex A controls mandatory?
No. You must consider each and justify exclusions in the statement of applicability. Excluding life cycle or use controls for an organisation running agents would be hard to justify.
How detailed should the mapping be?
Detailed enough that an auditor can follow each control to evidence. A one-line mapping per control area with references to procedures and records is usually enough.