Generative AI Governance Policy Template for Enterprises
A working generative AI governance policy template for enterprises — 13 clauses, mapped to ISO 42001, NIST AI 600-1, and the EU AI Act. Written for the CISO, CAIO, DPO, or governance lead actually drafting the document.
A generative AI governance policy is a topic-specific policy under an organisation's parent AI policy (required by ISO/IEC 42001 clause 5.2). It translates the standard's principles into rules for how employees and third-party foundation models produce content, code, and decisions on the organisation's behalf. This article gives you a working template with clause-by-clause wording, mapped to ISO 42001 controls, NIST AI 600-1 risk categories, and the EU AI Act's transparency and GPAI provisions. It is written for the person actually drafting the document (the CISO, CAIO, DPO, or governance lead), not the person still working out what generative AI is. If you already have a draft and want to pressure-test it, jump to Section 7 first.
Key Takeaways
ISO 42001 requires an AI policy, not a GenAI policy. Annex B.2.2 permits topic-specific policies (GenAI qualifies) cross-referenced from the parent AI policy.
The template covers 13 clauses. Purpose, scope, definitions, principles, roles, use-case tiering, prompt data handling, oversight, third-party approval, shadow AI, training, incident reporting, exceptions, and review.
NIST AI 600-1 defines 12 risk categories the policy must address, covering confabulation, prompt injection, IP, and value-chain dependency on foundation model providers.
Most enterprises are deployers, not GPAI providers under the EU AI Act. The policy must operationalise Article 50 transparency obligations, not the Article 53 and 55 obligations that fall on foundation model providers.
Policies address "why" and "what", never "how". PECB's ISO 42001 Lead Implementer guidance is explicit: procedures carry the operational detail, not the policy itself. Mixing the two produces a document nobody reads.
Certification does not equal legal compliance. ISO 42001 is a management system standard. It disciplines governance; it does not exempt the organisation from GDPR, the EU AI Act, UAE PDPL, or SDAIA PRPL obligations.
On This Page
- Why generative AI needs its own governance policy
- What ISO 42001 requires from an AI policy
- The GenAI risks the policy must address
- The template: clause by clause
- EU AI Act, GDPR, and regional regulation alignment
- Implementation: from published policy to enforceable control
- Common failure modes practitioners should avoid
- Conclusion
- Frequently asked questions
Why generative AI needs its own governance policy
An organisation implementing ISO/IEC 42001 needs one AI policy. Clause 5.2 is unambiguous on that. Clause 5.2 also authorises topic-specific policies for higher-risk domains, referenced from the parent (Annex B.2.2 reinforces this). Generative AI qualifies as a topic-specific domain, for reasons that predictive and discriminative AI systems do not raise in the same combination.
Traditional machine learning models classify, score, or forecast. Their inputs are structured, their outputs constrained, and their failure modes largely understood: dataset drift, biased training data, calibration decay. A GenAI system does something different. It produces open-ended content (text, code, images, audio, decisions expressed in natural language) from open-ended inputs, using a foundation model the organisation almost never trained itself. That inversion changes what the policy has to cover.
Four differences are worth naming explicitly, because each of them maps to a policy clause you will not find in a generic AI policy:
The foundation model is a third-party dependency. When a business uses ChatGPT Enterprise, Microsoft Copilot, Claude for Work, or an open-source model hosted internally, the base capabilities and safety properties are set by the provider, not the organisation. The policy has to address supplier oversight, contract terms, and how model updates are managed, because the model will change under the organisation and the organisation's controls will need to keep up.
Prompts are a new class of information exposure. An employee pasting a customer contract into a public chatbot to summarise it has just performed a data disclosure. Most information security policies were written before the concept of a prompt existed. The GenAI policy has to define prompt hygiene as its own category of information handling, distinct from email, file-sharing, or system access.
Output attribution is unresolved. When a GenAI system produces marketing copy, code, or a legal analysis, three questions arise that a predictive model never triggers: who owns the output, was any of it derived from copyrighted training data, and does the audience need to be told a machine wrote it. The policy has to take a position on each, even if that position is "defer to legal counsel case by case".
Shadow AI is the default state. By the time governance functions notice, employees have been using consumer-tier tools for months. Every enterprise engagement I have run in the last two years has found this. Unlike shadow IT, shadow AI leaves few artefacts: no software installation, no procurement paper trail, often just a browser tab. A policy that regulates approved enterprise tools but ignores what people are actually using will be evaded, not followed.
These are the reasons a separate GenAI governance policy is not bureaucratic duplication but a genuinely different governance object from the parent AI policy. The rest of this article treats it as such.
What ISO 42001 requires from an AI policy
Before writing the GenAI-specific clauses, the drafter needs to know what the parent standard actually demands. ISO/IEC 42001 puts policy squarely on top management, and sets specific criteria any AI policy has to satisfy. Generic or topic-specific, the bar is the same.
Clause 5.2 requires top management to establish an AI policy that is appropriate to the purpose of the organisation, provides a framework for setting AI objectives, includes a commitment to satisfy applicable requirements, and includes a commitment to continual improvement of the AI management system. The policy must be available as documented information, communicated within the organisation, and available to interested parties as appropriate.
Every one of those elements applies to the GenAI-specific policy too, either directly or by cross-reference to the parent policy. Auditors will not accept a topic-specific policy that skips them on the basis that "the parent policy already covers it" unless the cross-reference is explicit.
Annex B.2.2 adds implementation guidance beyond the bare clause 5.2 requirements. The policy should be informed by business strategy, organisational values and culture, the amount of risk the organisation is willing to pursue or retain, the level of risk posed by the AI systems in scope, legal requirements including contracts, the risk environment, and impact on relevant interested parties.
Beyond those inputs, the policy itself should include principles that guide all AI-related activities and processes for handling deviations and exceptions. Annex B.2.2 also names three topic areas that warrant additional guidance or cross-reference: AI resources and assets, AI system impact assessments, and AI system development. A GenAI policy touches all three.
Annex B.2.3 requires that the AI policy be reconciled with existing policies in adjacent domains: information security, privacy, ethics, HR, sustainability. The organisation is expected to analyse where AI intersects with those domains and either update the existing policies or include cross-references in the AI policy.
In practice, this is one of the most common places a GenAI policy falls over. The team drafting it does so in isolation, and only discovers on rollout that its data-handling rules conflict with the ISMS acceptable use policy, or that its transparency requirements are looser than the privacy policy's disclosure obligations. The cross-reference work is not optional.
Annex B.2.4 requires that a role approved by management be responsible for the development, review, and evaluation of the AI policy. The review must assess opportunities for improvement in response to changes to the organisational environment, business circumstances, legal conditions, or technical environment.
For a GenAI policy, this is the clause with the most real-world bite. Foundation models change quarterly. Regulation is changing yearly. An annual review cadence (the default for most policies) is almost certainly too slow. The policy should specify a shorter interval, or a trigger-based review that fires when the underlying model, provider, or regulatory environment changes materially.
PECB's ISO/IEC 42001 Lead Implementer material describes a four-step policy drafting process that applies equally well to a GenAI-specific policy. First, define the policy components: a list of every topic the policy will address, at minimum covering clause 5.2. Second, draft each section in language simple enough that every affected party can understand it, avoiding operational specifications and product references. Third, validate the content and format against clause 7.5.3 and against other organisational policies to ensure no contradictions. Fourth, validate the policy with interested parties by obtaining feedback before publication.
The guidance is precise on one point that drafters routinely violate: the policy addresses the "why" and especially the "what", never the "how". The "how" belongs in procedures. A GenAI policy that lists which specific browser extensions to install or which prompt templates to use is doing procedure work in policy clothing, and will be obsolete inside a quarter.
One more piece of ISO 42001 vocabulary matters. Clause 3.5 defines a policy as "intentions and direction of an organization, as formally expressed by its top management." That differs from a guideline (a general rule), a standard (a mandatory requirement in a specific domain), and a procedure (a documented sequence of actions). The GenAI policy sets intent and direction. It does not tell people which model to use, what to type into it, or how to log the interaction. Those live in procedures, work instructions, and technical standards downstream.
The GenAI risks the policy must address
The most rigorous public catalogue of GenAI risks is NIST's Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, published as NIST AI 600-1 in July 2024. It identifies twelve risk categories that are unique to or exacerbated by generative AI. A defensible policy addresses each one. Not by listing all twelve verbatim (that reads like a compliance checklist), but by covering every one somewhere in the operative clauses.
The twelve categories fall into three groups: technical failures of the model itself, misuse by humans, and broader ecosystem and societal risks. NIST's own framing draws on the UK's International Scientific Report on the Safety of Advanced AI for that structure. What follows is the mapping every drafter should have in front of them when writing the policy.
NIST defines confabulation as the production of confidently stated but erroneous or false content. It is not a bug. It is a mathematical consequence of how generative models work, since they approximate the statistical distribution of their training data rather than retrieve verified facts. GenAI outputs may also include confabulated logic or citations that appear to justify the answer.
Policy response: human-in-the-loop verification for any output used in consequential decisions, prohibition on using GenAI as a source of legal, medical, financial, or safety-critical facts without independent verification, and disclosure requirements for any published content that a GenAI system produced.
NIST's data privacy category covers leakage and unauthorised use, disclosure, or de-anonymisation of biometric, health, location, or other personally identifiable or sensitive data. In GenAI systems, this manifests in two directions: sensitive data pasted into prompts by employees, and sensitive data reproduced in model outputs due to training data memorisation.
Policy response: explicit categories of data prohibited from prompts (PII, PHI, PCI, trade secrets, source code, unreleased financials), a mandate for enterprise-tier tools with data processing agreements over consumer tools, retention rules for prompt and output logs, and integration with the organisation's ISO 27701 or GDPR privacy programme.
NIST's IP category covers the still-unresolved legal question of whether the use of copyrighted works in training data constitutes fair use, and whether outputs displaying training data memorisation infringe copyright. The category also extends to use or emulation of personal identity, likeness, or voice without permission.
Policy response: prohibitions on inputting proprietary or third-party IP into public GenAI tools, a position on ownership and usability of generated outputs, requirements to check any generated content used commercially against source materials, and integration with the organisation's existing IP and legal review process.
NIST's information security category is where GenAI creates genuinely new attack surface. Direct prompt injection involves attackers crafting malicious prompts that make a GenAI system behave in unintended ways. Indirect prompt injection is worse: adversaries inject prompts into data that an LLM-integrated application later retrieves (a poisoned web page, a manipulated document, a compromised email), and the model treats the injected text as instructions. Data poisoning, where an adversary compromises training data to manipulate outputs, is a related risk. Merely querying a closed production model can also elicit previously undisclosed information.
Policy response: integration with the ISMS (Annex A controls in ISO 27001 or the equivalent in the organisation's existing framework), specific controls for GenAI-enabled applications that retrieve external content (retrieval-augmented generation systems, browsing agents, tool-using agents), and incident reporting categories for prompt injection and model theft.
NIST's information integrity category covers content that may not distinguish fact from opinion or fiction, or acknowledge uncertainties, including content that can fuel large-scale disinformation. For enterprises, the relevant instance is content published externally under the organisation's name: marketing copy, customer communications, analyst reports, social media posts.
Policy response: labelling requirements for AI-assisted external content (aligned with EU AI Act Article 50 transparency obligations where applicable), review workflows for any GenAI-produced public-facing content, and prohibitions on undisclosed impersonation of humans in customer-facing GenAI applications.
NIST covers amplification of historical, societal, and systemic biases, performance disparities between sub-groups or languages due to non-representative training data, and homogeneity that skews outputs. In enterprise applications, this materialises in hiring, credit, promotion, and customer segmentation decisions where GenAI outputs feed downstream processes.
Policy response: prohibited use cases for high-impact automated decisions (employment, credit, benefits) without documented bias evaluation, integration with the organisation's ISO 42001 AI system impact assessment process, and mandatory human review for outputs that affect individuals' rights or opportunities.
NIST identifies the risk that users inappropriately anthropomorphise GenAI systems or experience automation bias, over-reliance, or emotional entanglement. This is the failure mode where a doctor accepts a confabulated summary because the model sounded confident, or a junior analyst accepts a plausible-looking financial forecast without checking the arithmetic.
Policy response: mandatory training on GenAI limitations, explicit guidance on when human judgement is required rather than optional, and rules on how GenAI output is attributed and disclosed inside the organisation so that downstream reviewers know what they are looking at.
NIST identifies the risks that arise when the organisation does not control the components upstream of its GenAI applications: foundation model, training data, safety-tuning, model updates. A vendor's decision to change the model version, adjust its safety-tuning, or deprecate a feature can silently break the enterprise's controls.
Policy response: procurement gates for third-party GenAI tools, requirements for contract terms covering model changes and notification periods, and integration with supplier management processes (ISO 27001 A.15 or A.5.19 in the 2022 edition, and ISO 42001 A.10 for third-party AI).
NIST groups four categories here: dangerous or violent content, obscene or abusive content (including non-consensual intimate imagery and CSAM), and eased access to chemical, biological, radiological, or nuclear information. Most enterprises will not build or fine-tune models where these are direct concerns, but any organisation deploying a GenAI application accessible to employees or the public still needs guardrails against generating this content on the organisation's infrastructure.
Policy response: acceptable use rules that prohibit generating or attempting to generate this content, incident reporting obligations for any output that falls into these categories, and reliance on the underlying provider's safety-tuning as one control among several (never the only one).
NIST's twelfth category covers the compute resource intensity of training and operating GenAI models and the downstream environmental consequences. For enterprises using third-party foundation models, this becomes a scope 3 emissions and supplier reporting question, not a training-compute question.
Policy response: alignment with the organisation's sustainability policy, procurement criteria that include model provider disclosures on compute intensity, and use-case gating that discourages high-compute GenAI where lower-compute alternatives would work.
The template: clause by clause
What follows is the working template. Every clause below is written as policy language: the "why" and "what", not the "how". Where a clause needs to be tailored to the organisation, the placeholder text says so. Where a clause refers out to a procedure that the organisation must write separately, it says that too.
How to use the template
Read every clause. Decide if it applies. Delete what does not. Expand what does. The finished document should run no more than eight pages. Anything longer starts to fail the PECB drafting test: that the policy be understandable to every party affected by it.
Policy Template
Generative AI Governance Policy
Version: [1.0]
Effective date: [DD Month YYYY]
Owner: [Chief AI Officer / Head of AI Governance]
Approved by: [Board / Executive Committee]
1. Purpose and scope
This policy establishes the principles and rules under which [Organisation Name] develops, procures, deploys, and uses generative artificial intelligence systems. It is a topic-specific policy under the [Organisation Name] AI Policy and inherits all commitments therein.
This policy applies to all employees, contractors, and third parties acting on behalf of [Organisation Name], and to every generative AI system used in connection with the organisation's activities, whether developed internally, procured from a third party, or embedded as a feature within another product.
2. Definitions
Generative AI (GenAI) system: an AI system that can generate content (text, images, audio, video, code) in response to natural language or other prompts.
Foundation model: a large-scale AI model trained on broad data, adaptable to a wide range of downstream tasks.
Prompt: the input, in any form, provided to a GenAI system to elicit an output.
Output: the content produced by a GenAI system in response to a prompt.
Agentic system: a GenAI system that can autonomously take multi-step actions in the world, including using tools, calling APIs, or executing code.
3. Guiding principles
Every use of generative AI at [Organisation Name] is governed by the following principles:
Lawfulness: use must comply with all applicable laws and regulations in every jurisdiction of operation.
Human oversight: a human is accountable for every consequential decision informed by GenAI.
Transparency: the use of GenAI is disclosed where required by law, contract, or the reasonable expectations of affected parties.
Fairness: GenAI is not used in ways that produce unlawful or unjustified discrimination.
Security by design: GenAI systems are subject to the same information security controls as any other information system, plus additional controls specific to GenAI risks.
Proportionality: the level of governance applied to a GenAI use case is proportional to the risk it poses.
4. Roles and responsibilities
The Board / Executive Committee approves this policy and receives an annual report on its operation.
The AI Governance Committee reviews the policy, approves exceptions above the threshold defined in Clause 12, and reviews the risk register for GenAI systems.
The Chief AI Officer (or equivalent role) is the policy owner, is accountable for its implementation, and maintains the inventory of approved GenAI systems.
Business owners of GenAI use cases are accountable for compliance with this policy in their domain, and for conducting AI system impact assessments where required.
Users of GenAI systems are responsible for compliance with the operating procedures issued under this policy.
5. Approved and prohibited use cases
Every GenAI use case is classified into one of four risk tiers:
Tier 1, Low risk: internal productivity uses (drafting, summarisation, research) with no external audience and no PII. Pre-approved on approved tools; no case-by-case review required.
Tier 2, Limited risk: internal decisions of moderate consequence, or external outputs subject to human review before release. Requires business owner approval and adherence to procedure.
Tier 3, High risk: consequential decisions affecting individuals (employment, credit, benefits, access to services), agentic systems taking autonomous action, or use cases falling within the EU AI Act Annex III high-risk categories. Requires AI Governance Committee approval, documented AI system impact assessment, and defined human oversight.
Prohibited: use cases that violate applicable law (including Article 5 of the EU AI Act where in scope), that involve GenAI as a sole decision-maker in employment or credit decisions, that generate content prohibited under Clause 11, or that use GenAI to impersonate real individuals without consent.
6. Data handling in prompts
The following data categories must not be entered into any GenAI system that is not on the approved enterprise tools list:
• Personal data as defined in [applicable data protection law].
• Special category personal data, including health, biometric, and financial data.
• Trade secrets, unreleased financial information, and confidential business information.
• Source code from proprietary systems, unless the tool is approved for that specific use.
• Third-party confidential information subject to non-disclosure agreements.
Approved enterprise-tier GenAI tools with an executed data processing agreement may accept the above categories subject to the operating procedure for each tool.
7. Human oversight and disclosure
GenAI output used to inform a decision that materially affects a person's rights, obligations, or opportunities is reviewed by a competent human before that decision is made or communicated.
External-facing content produced with material assistance from a GenAI system is disclosed as such where required by law, contract, or the reasonable expectations of the audience. Synthetic content (including but not limited to deepfake images, audio, or video) is labelled at the point of publication.
Customer-facing GenAI applications identify themselves as AI systems to the customer at the start of any interaction.
8. Third-party GenAI tools and services
Any GenAI tool or embedded GenAI feature procured from a third party is subject to the organisation's supplier management process before use. The procurement gate includes review of the provider's data processing terms, the provider's position on training on customer inputs, the provider's incident notification commitments, and the provider's disclosures on model changes and deprecation.
The list of approved third-party GenAI tools is maintained by the Chief AI Officer and reviewed at least quarterly.
9. Shadow AI
Use of GenAI tools that are not on the approved list is not permitted for any purpose covered by Clause 6.
Employees who identify a business need not served by the approved tools list should raise it through the process defined in the operating procedure, rather than adopting unapproved tools. Enforcement rests on policy communication, network-level detection, and periodic review, not on prohibition alone.
10. Training and awareness
Every employee whose role involves the use of GenAI systems completes mandatory training on this policy and the operating procedures under it. Training addresses the limitations of GenAI (including confabulation and bias), the categories of data that must not be entered into prompts, the disclosure requirements, and the incident reporting process. Training is refreshed at least annually.
11. Incident reporting
The following events must be reported through the organisation's incident management process without delay:
• Any suspected leak of data covered by Clause 6 into a GenAI system.
• Any successful or attempted prompt injection against an organisational GenAI application.
• Any GenAI output that materially misled a decision.
• Any GenAI output generating content prohibited under Clause 5.
• Any material change in an approved third-party GenAI tool's capabilities, safety-tuning, or terms of service.
12. Deviations and exceptions
Requests to deviate from this policy are submitted to the Chief AI Officer. Deviations that affect Tier 1 or Tier 2 use cases may be approved by the Chief AI Officer for a defined period. Deviations affecting Tier 3 use cases or any prohibited category require AI Governance Committee approval. All approved deviations are recorded, time-bound, and reviewed at the next policy review cycle.
13. Policy review
This policy is reviewed at least [semi-annually / annually], and additionally whenever a material change occurs in the applicable regulatory environment, in the organisation's use of GenAI, or in the underlying capabilities of approved GenAI systems. The Chief AI Officer is responsible for initiating each review.
The template above is the deliverable. What follows are the things a drafter needs to know to defend it, extend it, and make it survive contact with the regulator, the auditor, and the board.
EU AI Act, GDPR, and regional regulation alignment
A GenAI policy that only satisfies ISO 42001 leaves the organisation exposed. ISO 42001 is a management system standard. Certification confers conformity with the standard's governance requirements, not compliance with any specific law. The policy has to be drafted to satisfy both. This section covers the regulatory obligations that need to sit inside it.
EU AI Act: the deployer distinction and Article 50 transparency
The first thing to get right is the classification. The EU AI Act imposes different obligations on different actors, and most enterprises are getting themselves into the wrong bucket. The categories that matter for a GenAI policy are:
General-Purpose AI (GPAI) model providers are organisations that train and place a general-purpose AI model on the EU market. Their obligations sit in Articles 53 and 55, and cover technical documentation, information for downstream providers, a policy on EU copyright law, and a training data summary. If cumulative training compute exceeds 10²⁵ floating-point operations, the model is presumed to present systemic risk and Article 55 obligations stack on top. Providers of open-source GPAI models are exempted from parts of Article 53. Enforcement sits with the AI Office within the European Commission. Most enterprises are not GPAI providers. If your organisation is not training a foundation model, Articles 53 and 55 do not apply to you.
AI system providers are organisations that develop an AI system, or have one developed, and place it on the market under their own name. This is where many enterprise-built GenAI applications land, particularly those that integrate a foundation model into a specific product or workflow.
Deployers are organisations that use an AI system under their own authority for a professional activity. This is what most enterprises actually are when they roll out Microsoft Copilot, ChatGPT Enterprise, Claude for Work, or a custom application built on top of a foundation model API.
For deployers, the operative obligations are Article 50 transparency and, where the deployed system is high-risk under Annex III, the deployer obligations in Article 26. Article 50 is short but consequential. It requires that natural persons interacting with an AI system be informed of that fact unless obvious from the context, and that outputs of AI systems producing synthetic audio, image, video, or text content (including deepfakes) be marked as artificially generated. Article 50 obligations sit alongside, not in place of, GDPR obligations on automated decision-making and personal data processing.
The policy clauses in the template above that map directly to Article 50 are Clause 7 (human oversight and disclosure) and the prohibited categories in Clause 5. Drafters in the EU or serving EU markets should reference Article 50 explicitly in Clause 7 to make the connection auditable.
GDPR: automated decisions, data minimisation, and DPIAs
GDPR predates the AI Act, but its GenAI touch-points are sharp. Article 22 restricts solely automated decision-making producing legal or similarly significant effects on individuals. A GenAI system that generates a hiring shortlist, a credit score, or a benefits determination without meaningful human involvement is squarely within Article 22's scope. The policy's Tier 3 controls in Clause 5, requiring documented human oversight for consequential decisions, are what makes Article 22 operational at the working level.
The Article 5 principles (lawfulness, purpose limitation, data minimisation, storage limitation) apply to the personal data an enterprise processes in prompts and outputs. The prohibited categories in Clause 6 of the template are the concrete implementation of data minimisation for GenAI.
Article 35 mandates a Data Protection Impact Assessment where processing is likely to result in high risk to individuals' rights and freedoms. GenAI processing frequently meets that threshold, and European data protection authorities and the EDPB have published guidance on this. The AI system impact assessment required by ISO 42001 (Annex A control A.5) and the GDPR DPIA can be run as one integrated exercise, provided both sets of requirements are covered. The policy should reference this in Clause 5 (Tier 3) and in the cross-reference to the privacy programme.
UAE PDPL and SDAIA PRPL: regional obligations for MENA-based operations
Enterprises operating in the UAE are subject to Federal Decree-Law No. 45 of 2021 on the Protection of Personal Data (PDPL), enforced by the UAE Data Office. The PDPL's provisions on lawful basis, data subject rights, and cross-border transfer apply to any personal data entered into a GenAI prompt or produced in an output. Free zone regimes (DIFC and ADGM) operate their own data protection laws with GDPR-aligned structures. Policy drafters should replace generic "applicable data protection law" placeholders in Clauses 6 and 12 with named citations for each jurisdiction the organisation operates in.
In Saudi Arabia, the Personal Data Protection Law (PDPL) is enforced by the Saudi Data and AI Authority (SDAIA), which also publishes the AI ethics framework and, for regulated sectors, more specific guidance on AI use. SDAIA's guidance evolves, and the policy's Clause 13 review trigger should include SDAIA publications as a monitored source.
Other jurisdictions: Brazil, Canada, UK, Singapore
The pattern generalises. Where the organisation operates in a jurisdiction with its own data protection law or AI-specific guidance (Brazil's LGPD and the ANPD's GenAI guidance, Canada's PIPEDA and forthcoming AIDA subject to legislative revival, the UK's ICO guidance on AI and data protection, Singapore's PDPC AI governance framework), the policy's applicable-law placeholders must reflect each. The policy owner is responsible for keeping the list current; that responsibility should be explicit in Clause 4.
The certification-versus-compliance point, one more time
ISO/IEC 42001 certification demonstrates that the organisation has implemented a management system meeting the standard's requirements. It does not demonstrate compliance with any law. This distinction matters because regulators (including the EU AI Office in its published statements) have been clear that adherence to voluntary standards can support, but does not substitute for, statutory obligations. The policy should not state or imply otherwise. Any Clause 3 language framing ISO 42001 alignment as evidence of legal compliance is a defect and should be removed before publication.
Implementation: from published policy to enforceable control
Publishing the policy is the easy part. The harder work is making it operational: turning policy statements into procedures, training, tooling, and metrics that regulators and auditors can actually inspect. The PECB Lead Implementer material lays out a workable sequence.
Start with the four-step drafting process. Define the components (use the template above as the starting list). Draft each clause in language every affected party will understand. The finance team, the marketing team, the customer-facing engineers, and the legal team all need to be able to read the policy and know what it means for them. Validate the content against clause 7.5.3 of ISO 42001 (control of documented information) and against every adjacent policy in force. Validate with interested parties before publication. That means the works council or equivalent employee representation body where required, and the business owners of the largest GenAI use cases.
Map each policy clause to Annex A controls. ISO 42001's Annex A is where the policy meets the auditable control set. Clause 3 (principles) maps to A.2 Policies related to AI. Clause 4 (roles and responsibilities) maps to A.3 Internal organization. Clauses 5, 6, 7, and 11 map into A.5 (impact assessments), A.6 (AI system life cycle), A.7 (data for AI systems), and A.9 (use of AI systems). Clauses 8 and 9 map to A.10 (third-party and customer relationships). Every policy statement should trace to at least one control the organisation can evidence. Statements that do not trace anywhere are policy theatre and should either be operationalised or cut.
Cross-reference the ISMS. Annex B.2.3's alignment requirement is not an optional courtesy. Every GenAI policy clause dealing with information handling, access control, or incident response should cross-reference the ISO 27001 policy of the same domain, and the ISO 27001 policies should be updated in return where the GenAI policy imposes stricter controls. If the two policies say different things, the auditor will notice, and one of them will need to give way.
Communicate and train. Clause 5.2 of ISO 42001 requires communication of the policy within the organisation and availability to interested parties. Training is the operational implementation of communication. The training itself is not policy content (it belongs in the procedure), but the requirement to train belongs in the policy (Clause 10 of the template).
Instrument the metrics. A policy that cannot be measured cannot be reviewed effectively at Clause 13 intervals. Useful metrics for a GenAI policy include: adoption rate of approved tools, count and duration of active exceptions, GenAI-related incident count by category, training completion rate, and the delta between the approved tools list and observed traffic (a proxy for shadow AI). These metrics feed the management review under ISO 42001 clause 9.3.
Ready to lead ISO 42001 implementation in your organisation?
The PECB ISO 42001 Lead Implementer certification equips you to design and roll out the AI management system that this policy sits inside, clause by clause and control by control. Delivered by reconn with a private 1-on-1 session and WhatsApp access to Shenoy until you clear the exam.
Common failure modes practitioners should avoid
I have reviewed enough of these policies in the wild to spot the same failure modes recurring. All of them are preventable by a drafter who knows what to look for.
The vendor-template copy-paste. Large tech vendors publish "sample AI policies" that read reasonably. The problem is that they are written to a generic organisation with a generic risk appetite. A policy adopted with no material tailoring to the specific organisation's risk tolerance, use cases, and existing control environment fails the ISO 42001 Annex B.2.2 requirement that the policy be informed by business strategy, values, and the level of risk the organisation is willing to pursue. When the auditor asks for the analysis behind the risk tolerance, there is nothing to show.
Prohibitions with no approved alternatives. A policy that says "employees may not use ChatGPT" without providing an approved alternative for the underlying use case does not eliminate the use case. It drives it into the shadows. Shadow AI is far harder to detect than shadow IT, and the policy that produced it looks fine on paper. Every prohibition should either be paired with an approved alternative or be genuinely absolute (as with prohibited use cases in Clause 5 of the template).
No exception process, or an exception process nobody uses. If Clause 12 exists on paper but every practical request results in a "no", exceptions stop being requested and the policy stops being followed. The exception process needs to be usable in a business timeframe, and the approval criteria need to be legible. An exception log with zero entries after a year of operation is almost always a signal of policy evasion, not policy compliance.
No cross-references to existing policies. The GenAI policy that lands in an organisation with no acknowledgement of the existing ISO 27001 information security policy, the privacy policy, the HR acceptable use policy, and the intellectual property policy creates immediate conflicts. Employees will not read four policies to reconcile the differences. The reconciliation belongs in the policy design phase, not in the employee's head at the moment of decision.
Annual review only. Foundation models change quarterly. Regulation changes yearly. The annual review cadence familiar from ISO 27001 will leave the GenAI policy materially out of date between reviews. Clause 13 of the template allows for a shorter interval or a trigger-based review. The choice between them should be conscious, not inherited from the ISMS by default.
Treating the policy as a legal defence. The policy is a governance instrument. It disciplines decisions and creates audit trails. It does not shield the organisation from regulatory action if the underlying use of GenAI itself violates the law. This is the single most common source of drift in policy language and the single most important thing to strip out during final review. Clause 3 principles frame lawfulness as the organisation's own obligation; nothing in the policy should read as if adherence to the policy itself is sufficient.
Conclusion
A generative AI governance policy is the working document that turns ISO/IEC 42001's principles into rules people can actually follow. Written well, it is short, specific, and readable. Eight pages of policy, not eighty pages of aspiration. It sits under the parent AI policy required by clause 5.2, cross-references the existing information security and privacy policies, addresses each of the twelve GenAI risk categories in the NIST AI 600-1 profile, and operationalises Article 50 of the EU AI Act, the applicable data protection law, and any regional AI-specific guidance the organisation is subject to.
The template above is a working starting point, not a finished policy for any specific organisation. The drafter's job is to keep what applies, delete what does not, and expand what needs local detail, always addressing the "why" and "what", never the "how". The "how" belongs in the procedures written under the policy, and that is where most of the operational effort should actually go.
Certification against ISO 42001 is a legitimate goal and a useful signal to customers and regulators. It is not, and cannot be sold internally as, compliance with any law. The policy that gets both parts right, governance discipline through the standard and statutory compliance through the regulation, is the one that survives audit, enforcement action, and the next round of foundation model updates.
Ready to audit an ISO 42001 AI management system?
The PECB ISO 42001 Lead Auditor certification is the credential for professionals who will audit AI management systems against the standard: first-party, second-party, or as part of a certification body. Delivered by reconn with the same 1-on-1 practitioner mentorship as our Implementer track.
Further Reading
- ISO 42001: The Complete Global Guide to Artificial Intelligence Management Systems. The parent guide covering the standard's structure, clauses, Annex A controls, and certification pathway.
- ISO 42001 Implementation Guide: Step-by-Step Methodology. The operational sequence for standing up an AI management system, of which the GenAI policy is one deliverable.
- ISO 42001 Lead Implementer. The credential and course for professionals leading the implementation of an ISO 42001 AI management system.
- ISO 42001 Lead Auditor. The credential and course for professionals auditing AI management systems against the standard.
Frequently asked questions
ISO/IEC 42001 requires one AI policy, but Annex B.2.2 explicitly permits topic-specific policies for higher-risk domains, cross-referenced from the parent. Generative AI qualifies because it introduces risks (foundation model dependency, prompt-based data exposure, output attribution, shadow AI) that a generic AI policy does not adequately cover. Most organisations end up with both: a short parent AI policy and a longer, more operational GenAI policy underneath it.
No. ISO 42001 clause 5.2 mandates an AI policy. Annex B.2.2 permits topic-specific policies but does not name generative AI specifically. The decision to write a GenAI-specific policy is a risk-based decision the organisation makes, and one that auditors will accept as reasonable given the distinct risk profile of GenAI systems.
The Chief AI Officer, Head of AI Governance, or equivalent role, reporting to the AI Governance Committee or executive body that approves the policy. Where an organisation has no dedicated AI role yet, the policy typically sits with the CISO (if the primary framing is risk) or the DPO (if the primary framing is data protection). Both are workable transitional homes, but neither is a durable one; the AI policy needs an owner whose remit is AI governance specifically.
Annex B.2.4 requires review, but does not specify a cadence. For a GenAI policy, annual review is almost certainly too slow. Foundation models change quarterly and regulation is moving on similar timescales. Semi-annual review, supplemented by trigger-based review when a material change occurs in the regulatory environment, the organisation's use of GenAI, or the underlying capabilities of approved tools, is a more defensible default.
Not if the organisation intends to comply with ISO/IEC 42001. Annex B.2.2 requires that the policy be informed by the organisation's business strategy, values, risk tolerance, and level of risk posed by the AI systems in scope. A vendor template cannot know any of those. Vendor templates are a useful reference for structure and language; they are not a substitute for the analysis that produces a policy fit for this specific organisation.
They should be reconciled explicitly. ISO 42001 Annex B.2.3 requires alignment between the AI policy and adjacent policies including information security. The GenAI policy's clauses on data handling in prompts, incident reporting, and third-party tools should cross-reference the ISO 27001 policy statements in the same domains, and vice versa. Where the GenAI policy imposes stricter controls than the ISO 27001 policy (for example, on data classification for prompt inputs), the ISO 27001 policy needs to be updated to acknowledge the stricter rule, not simply left in conflict.
An acceptable use policy addresses what individual users may and may not do with a specific tool. A governance policy addresses how the organisation as a whole develops, procures, deploys, and oversees a class of systems. The GenAI governance policy in this article covers approved and prohibited use cases (which are governance decisions), but its scope is broader: roles and accountability, third-party procurement, incident reporting, exceptions, review. An acceptable use policy is one downstream artefact under the governance policy, not a substitute for it.
No. The EU AI Act imposes statutory obligations that no voluntary policy can substitute for. Adopting a strong governance policy operationalises many of the deployer obligations under Article 26 and the transparency obligations under Article 50 and can support a defence that the organisation acted diligently. It does not exempt the organisation from Article 5 prohibitions, from the high-risk system provider obligations if the organisation is a provider under Article 6, or from any other statutory duty. ISO 42001 certification is a management-system conformity signal, not a legal-compliance signal.
Ready to certify on both sides of the standard?
The PECB ISO 42001 Lead Implementer and Lead Auditor bundle covers both credentials at a combined price, with shared foundation modules and two exam attempts for each. Delivered by reconn with a 1-on-1 practitioner session with Shenoy and WhatsApp access until you clear both exams.
About the Author
Shenoy Sandeep
Shenoy Sandeep is the Founder of reconn, an AI-first cybersecurity firm based in Dubai, UAE. With 20+ years across cybersecurity focussing on offensive security and threat intelligence portfolio, and over 10 years in Enterprise AI, AI governance and data protection, he has assisted over 25+ startups in scaling their business in the Middle East and African region.
Training is Shenoy's passion project and reconn has associated themselves with PECB, the global leaders in personal certifications for AI, cybersecurity, data protection, privacy and business continuity professionals. He is a PECB-certified trainer and one of the world's early PECB-certified AI professionals, also specialising in ISO/IEC 27001, ISO/IEC 27701, ISO 42001, ISO 22301, and GDPR.
Via Reconn, Shenoy runs an advisory service assisting organisations in the EMEA with compliance and certification on ISO 42001, ISO 27001, ISO 27701, ISO 22301 and local data protection and privacy laws. His current interests include EU AI Act, NIS2, DORA, EU/UK GDPR, UAE PDPL and SDAIA PRPL.
