This is practical guidance. It is not the text of ISO/IEC 27001:2022 or ISO/IEC 42001:2023, and it is not a certificate.
Zaheer Ikbal, Founder, CyHelm
For years, ISO/IEC 27001:2022 has been the backbone of how organizations design and run information security programs. It gave security leaders a shared language for risk, controls, and assurance. But 2026 is different. AI is no longer a side experiment. It is being embedded into business processes, products, and decision-making.
The real question is no longer whether an organization should use AI. The question is how to govern AI responsibly on top of the security foundation that already exists. For security leaders, that means extending the discipline of a traditional information security management system into something that can address AI-specific risk, accountability, and oversight.
Why ISO 27001 alone is not enough
ISO/IEC 27001:2022 remains a strong foundation for enterprise security governance because it structures security around risk management, asset protection, control selection, and continual improvement. Those principles still matter in the AI era.
AI systems behave differently from most traditional business applications. They do not simply store or process information. They generate content, influence decisions, adapt through changing prompts or data inputs, and introduce risks that are not always easy to capture in a conventional ISMS. Data leakage through prompts, model misuse, opaque decision logic, and unfair or biased outcomes are practical governance problems.
Trying to manage those issues using only classic security language often creates blind spots. Security may own infrastructure, legal may worry about privacy, compliance may focus on regulation, and business teams may experiment with AI tools without a clear governance model.
Why ISO 42001 matters now
ISO/IEC 42001:2023 gives organizations a management system for AI. It complements ISO 27001. It does not replace it, and holding one does not mean you hold the other.
For a security leader, the useful part is practical. You do not rebuild governance from scratch. You extend existing risk processes, ownership, and assurance so AI sits inside the operating model.
What to aim for
Do not start with a long policy. Start with five outcomes.
- Create visibility into where AI is used, what data it touches, and which decisions it influences.
- Protect models, prompts, training data, integrations, and runtime environments as business assets.
- Check AI use against the legal and regulatory duties that already apply, especially where it affects people or sensitive decisions. This article is not legal advice.
- Put AI risk into existing security, procurement, and incident processes.
- Give executives a short set of facts they can check, not an informal assurance that “we have AI under control.”
From the ISMS to AI governance
If you already run an ISMS, certified or not, use it. Do not stand up a second bureaucracy.
Scope. Bring AI systems and workflows into governance scope: internal models, external AI platforms, assistants, AI features inside third-party tools, and decision workflows that rely on model outputs.
Inventory. Each meaningful system needs a business owner, a technical owner, a purpose, a data profile, and a business-impact classification.
Risk. Add scenarios a normal register often misses: prompt leakage, model drift, adversarial manipulation, unreliable outputs, and discriminatory impact. Write them in business language.
Existing mechanisms, applied to AI. Access control includes who can change a model or a system prompt. Change management includes model updates, prompt logic, and training-data changes. Logging has to show meaningful use, not only server events.
30-60-90
Days 0-30, visibility. Cross-functional review with IT, security, data, procurement, HR, legal, and the business. Inventory: tool or model, owner, purpose, data, dependence, whether it is live, and whether it affects customers, employees, or regulated decisions. Flag the obvious high-risk patterns: confidential data in public generative tools, AI vendors with no review, model outputs used with no human check.
Days 30-60, the governance layer. Keep it short enough that teams will use it. Who approves a use case. What counts as high risk. When legal or compliance review is required. Where a person must stay in the loop. Update procurement, third-party review, acceptable use, and change management so AI is inside those workflows.
Days 60-90, embed and measure. Put the checks in project intake and architecture review. Ask vendors about model security, training-data handling, privacy, retention, and monitoring. Add incident scenarios: output manipulation, prompt-based data leakage, failure of automated decision support. Four indicators are enough: share of AI systems with a named owner, share of high-risk uses with a recorded approval, AI incidents or near misses reviewed, and AI tools that went through procurement review.
Where the value is
Boards ask five questions. Where is AI used. Which uses carry the most risk. Who is accountable. What is in place. How will we know it is working. Answer those. Do not add a framework diagram and call it governance.
Final thought
Do not treat AI governance as a stack beside the ISMS. ISO/IEC 27001:2022 is the discipline you already know. ISO/IEC 42001:2023 is a management system for AI. Neither sentence means you are certified, and this playbook does not implement either standard for you.