A ten-minute integration assessment, anchored to the ISO 27 and 42 series and the EU AI Act
Most organizations arrive at AI governance the same way. Something ships, someone asks who approved it, and the answer takes longer to find than anyone is comfortable with. The instinct at that point is to build something new: an AI committee, an AI policy, an AI risk register, an AI owner. Within a year that structure is running alongside the information security program rather than inside it, and the two disagree about what the organization has decided.
That is what bolted-on governance looks like. It is not a failure of intent. It is a failure of architecture. The cost shows up later, when an assessor, a customer or a regulator asks a question that requires both programs to give the same answer at once.
ISO/IEC 42001:2023 was written to be integrated. It uses the same harmonized structure as ISO/IEC 27001:2022, which means clauses 4 through 10 cover context, leadership, planning, support, operation, performance evaluation and improvement in both standards. If you already run an information security management system, you already run most of the machinery an AI management system needs. What 42001 adds is Annex A, nine control objectives numbered A.2 through A.10, covering policy, internal organization, resources, impact assessment, life cycle, data, information for interested parties, use of AI systems, and third-party relationships.
Read that list against your existing controls and the overlap is substantial. Supplier management, change control, competence, documented information, internal audit and management review do not need to be rebuilt for AI. They need to be extended to reach it. Privacy is the third pillar and it is the one most often left out of an AI program until something forces the issue. ISO/IEC 27701:2025, the second edition published in October 2025, is now a standalone privacy information management system standard rather than an extension bolted onto ISO/IEC 27001, which means it carries its own requirements and can be integrated on the same harmonized structure as the other two. Where AI touches personal data, and it usually does, the privacy management system belongs inside the same program rather than beside it. ISO/IEC 23894:2023 gives guidance on AI risk management, and ISO/IEC 5338:2023 covers AI system life cycle processes.
Certification and conformity assessment are different things, and conflating them is the most expensive mistake a board can make in this area. The EU AI Act imposes obligations directly: Article 9 requires a risk management system for high-risk AI systems, Article 10 addresses data and data governance, Article 14 requires human oversight, Article 17 requires a quality management system, Article 26 sets obligations for deployers, and Article 50 sets transparency obligations for certain systems.
ISO/IEC 42001 is a voluntary standard. It is not harmonized under the AI Act and has no Annex ZA, so certification against it does not discharge a legal obligation. It does something else that is still worth a great deal. It gives you a defensible, auditable structure in which those obligations can be met and evidenced, and it gives your assessors and customers a recognized reference point for how you run the program. Treat the two tracks as permanently separate and you will plan correctly. Treat certification as a shortcut through the law and you will not.
The assessment that follows takes about ten minutes. It does not test whether you are compliant with anything. It tests whether your AI governance is structurally attached to the management system you already run, or standing beside it. Twenty-eight statements across seven dimensions, each anchored to a specific clause or control so you can trace any answer back to its source. Score honestly. A low score is more useful than a flattering one, because it tells you where the next conversation needs to happen.
Twenty-eight statements, seven dimensions. Rate each one as it is today, not as it is meant to be. Your score updates as you go and nothing is sent anywhere.
A named individual at executive level is accountable for AI outcomes, and that accountability is documented rather than assumed.
Roles and responsibilities for AI development, deployment and oversight are defined and assigned, not left with whoever built the system.
The board or equivalent governing body receives AI risk reporting on a defined cycle.
AI policy is approved at the same level as your information security policy, and the two do not contradict each other.
You maintain a current inventory of AI systems in use, including AI embedded in software you purchased rather than built.
For each system you can state your role: AI producer or developer, AI provider, or AI customer or user.
The scope of AI governance is documented, and its boundary with your ISMS scope is explicit rather than assumed.
Interested parties and their requirements have been identified for AI specifically, not inherited wholesale from the ISMS.
AI risk is assessed using a defined and repeatable method rather than case-by-case judgment.
You assess impacts on individuals and society, not only risk to the organization.
AI risk feeds the same risk register and treatment process as information security risk.
Assessments are repeated when a system materially changes, and you can show when each was last performed.
Data used for training, tuning and testing has documented provenance.
Life cycle stages for AI systems are defined, with criteria for moving a system between them.
Changes to models, prompts and configuration are controlled and logged with the same discipline as code changes.
Retirement and rollback paths exist for AI systems and have been tested rather than assumed.
Where AI systems process personal data, that processing sits inside a privacy information management system rather than being handled case by case.
You can state the lawful basis and the purpose for personal data used to train, tune or evaluate each AI system.
Data subject rights, including access, correction and objection, are workable for personal data that has already entered an AI system.
Privacy impact assessment and AI impact assessment are run as one exercise rather than two that never meet.
People assigned to oversee AI systems have both the authority and the information needed to intervene or stop them.
Oversight is designed into the system rather than added as a review step after the fact.
Users are told when they are interacting with an AI system in the cases where that matters.
You can explain a consequential automated decision to the person affected by it.
AI capability acquired from suppliers is assessed before adoption rather than after an incident.
Supplier contracts address data use, notification of model change, and incident reporting.
You know which suppliers process your data to improve their own models, and on what terms.
Your AI controls are auditable using evidence you already produce for other management systems.
Answer the statements above to see where your program sits.
Fourteen questions, two per dimension. Once you have scored, the dimensions where you scored lowest are marked, and those are the questions to ask first.