Customer security questionnaires have started asking a new question: how do you govern AI? Boards are asking it too, usually after someone learns a team has been putting client data into a tool nobody approved. Most mid-market organizations do not have a good answer, because AI arrived through vendors and productivity tools, not through a program.
ISO/IEC 42001:2023 is the first certifiable management system standard for artificial intelligence. It does not certify a model, a product, or a tool. It certifies an AI Management System (AIMS): the policies, roles, risk and impact assessments, controls, and improvement cycle an organization uses to govern AI.
It applies to any organization that develops, provides, or uses AI systems, regardless of size or sector. You do not have to build models for this standard to apply to you. If you use AI, it was written for you.
Familiar disciplines, AI specific requirements
ISO 42001 uses the same Annex SL structure as ISO 27001 and ISO 9001. If you already run an ISMS, the machinery will look familiar: scope, leadership, planning, support, operation, performance evaluation, improvement. Risk methodology, document control, internal audit, and management review can be reused.
What changes is how those disciplines apply to AI. Three requirements carry most of the AI specific weight.
- AI impact assessment. A formal evaluation of what an AI system can do to individuals, groups, and society. It sits alongside organizational risk assessment, which asks what can go wrong for the business. Privacy and safety disciplines have asked about consequences to people for years. ISO 42001 brings that question into AI governance.
- AI system inventory and life cycle governance. You have to know which AI systems are in scope and govern them through data changes, retraining, model updates, vendor changes, and decommissioning.
- AI specific controls. Annex A holds 38 controls across nine objectives covering policy, roles, resources, impact assessment, life cycle, data, transparency, responsible use, and third party relationships. They are selected based on risk and impact, not implemented wholesale.
The paper AIMS
The most common way ISO 42001 fails is that it becomes a documentation project owned by compliance. Policies get written, an AI policy gets signed, and nothing about how AI decisions are actually made changes. Auditors will find it, and so will the first incident.
The pattern is consistent:
- No AI inventory, or a certification boundary that tries to cover "all AI" without defining it.
- Impact assessment treated as optional, so only risk to the business is assessed.
- A Statement of Applicability copied from a template with no justification behind it.
- Third party models and APIs left out, even though that is where most mid-market AI actually lives.
- No trigger for reassessment when a model, data source, vendor, or use case changes.
- Training delivered to technical teams while executives, procurement, and legal are left out.
- Corrective actions closed without anyone checking whether they worked.
Every item on that list is a decision someone did not make, or made without the authority to make it.
The SoA is a decision record
The Statement of Applicability is where the standard shows its real intent. It documents which Annex A controls are included or excluded, and why. Treated as a checklist, it is paperwork. Treated correctly, it is a record of decisions: which risks the organization accepted, which it treated, who owned each call, and what evidence justified it.
That is the same problem Antares sees across every security program. Failures rarely come from a missing control. They come from a decision that was never made, made by the wrong person, or made once and never revisited. ISO 42001 is useful precisely because it forces those decisions into the open and makes them auditable.
The certification does not guarantee an AI system is accurate, fair, or lawful. It certifies that the organization has a repeatable, auditable way of deciding how AI is governed. The value is in the deciding.
The mid-market reality
Most organizations between 50 and 500 employees are AI users, not AI developers. Their AI comes embedded in CRM, HR, document management, and productivity platforms, or through APIs a developer wired in last year. The governance questions are about vendors, data flowing out, and who approved what.
These same organizations usually have no CISO. Security sits with the CIO or IT director, who is already carrying infrastructure, help desk, and every vendor relationship. AI governance lands on that same desk with no added capacity.
The gap is not knowledge of the standard. Anyone can read the clauses. The gap is someone with the authority and experience to define the boundary, get leadership to own the decisions, and keep the program running after the first audit.
Where a vCISO fits
ISO 42001 does not change the work of a vCISO. The responsibilities are the same ones behind any security program: establish governance, assess risk, define accountability, implement controls, and verify they keep working. What changes is the technology being governed and the risks that come with it.
Organizations do not need to rebuild their programs for AI. They need to know where existing governance already covers it, where AI adds something, and how to fold those requirements into the structure they already have. For organizations without dedicated security leadership, that is the work a vCISO does:
- Set the boundary. Decide which AI systems, business units, and processes are in scope. A narrow, defensible boundary certified well beats a broad one nobody can evidence.
- Assign decision rights. Clause 5 requires roles and authorities: AI governance lead, risk owner, system owner, data owner, supplier owner. A vCISO maps those to real people and gets leadership to own them rather than delegate them to compliance.
- Reuse what exists. If the organization already runs ISO 27001 or SOC 2, the risk methodology, document control, internal audit, and management review carry over. Duplicating that work is wasted effort.
- Bring the vendors in. Supplier due diligence, contract terms, and model dependencies get the same scrutiny as internal systems, because for most mid-market organizations the vendors are the AI.
- Define reassessment triggers. New system, model change, new data source, new vendor, new use case, incident, regulatory change. Each one restarts the risk and impact assessment.
- Run the loop. Monitoring, internal audit, and management review are where programs stall. A vCISO keeps them on the calendar and makes sure corrective actions are verified, not just closed.
ISO 42001 gives that work a recognized structure and an outside audit. The job is making sure it runs as part of the broader security and risk program, not as one more isolated compliance exercise.
How Antares approaches it
Antares runs ISO 42001 through the same four stage decision lifecycle behind every engagement: Understand, Decide, Execute, Improve. The standard supplies the governance backbone and the evidence. The lifecycle supplies the discipline that keeps it from becoming paper.
| Stage | ISO 42001 | What gets decided |
|---|---|---|
| Understand | Clause 4, Clause 6.1 | Scope, AI inventory, risks to the business, impacts on people |
| Decide | Clause 5, Clause 6 | Policy, roles, objectives, risk treatment, the SoA as a decision record |
| Execute | Clause 7, Clause 8 | Competence, operational controls, life cycle governance, suppliers |
| Improve | Clause 9, Clause 10 | Monitoring, internal audit, management review, verified corrective action |
ISO 42001 is a useful structure and a recognized way to prove AI governance to customers and boards. It is not a prerequisite for governing AI well. Documented decision rights, assessments, monitoring, and review can exist with or without a certificate on the wall.
The technology changes. The responsibility to make sound decisions doesn't.
