How to write an AI governance policy (+ what to include)

Only 11% of organizations are fully ready on AI security, according to The Netwrix 2026 Data and Identity Security Report.

AI adoption in most organizations happened through individual tool choices before security reviews caught up: employees connected Microsoft Copilot, ChatGPT, and dozens of embedded AI features to their daily work before anyone wrote access rules governing what those tools could access.

That risk persists because AI access follows a different review pattern than normal user requests. These tools and the agent identities behind them can inherit permissions, query sensitive content, and create new audit questions faster than manual review can catalog them.

Security teams need visibility into which tools exist, what data they can access, who approved them, and how teams escalate exceptions. A written policy closes that gap by defining what AI can touch before an incident forces the question, strengthening cyber resilience while keeping AI adoption accountable.

What is an AI governance policy?

An AI governance policy is the document that defines the rules for how an organization's employees, contractors, and vendors may use AI tools: what data those tools can access, which tools the organization approves, and how teams escalate violations.

Teams often use "AI governance" and "AI policy" interchangeably, but they describe different layers of the same problem, and the distinction determines who owns what.

An AI governance framework is the broader, ongoing program within which the policy operates: the roles, review cycles, and tooling that keep the policy current. External reference frameworks, such as the NIST AI Risk Management Framework (AI RMF) and ISO/IEC 42001, provide the framework's structure, while the policy translates that structure into rules your workforce can follow.

What are examples of AI governance policies?

Abstract principles are easy to agree with and hard to implement. Reference policies from enterprise software, healthcare, financial services, and defense contracting show how requirements change by data type and regulation.

Enterprise Copilot and large language model (LLM) data-access policies

These are the closest analogs to what most mid-market security teams need to write, aside from any sector-specific regulations to follow. They focus on data access rules tied to a specific tool category already in use, such as Microsoft 365 Copilot or ChatGPT, which keeps enforcement grounded in real workflows. These policies often pair sensitivity labels with an operating model that separates taxonomy ownership from technical enforcement.

Healthcare AI governance policies

Healthcare organizations build these around the Health Insurance Portability and Accountability Act (HIPAA), separating clinical AI use (diagnostic or patient-facing tools, subject to the strictest access and audit rules) from administrative AI use (scheduling, billing, internal documentation), since the two carry different risk levels under the same regulation. A defining clause in a model policy: organizations may enter protected health information (PHI) into an AI tool only when the vendor has executed a Business Associate Agreement.

Financial services and defense-contracting AI governance policies

These lead with the specific frameworks that drive them: financial services carries Service Organization Control 2 (SOC 2), the General Data Protection Regulation (GDPR), and the Digital Operational Resilience Act (DORA), while defense contracting carries the Cybersecurity Maturity Model Certification (CMMC). Both tie risk tiers directly to whether an AI tool touches customer financial data or controlled unclassified information (CUI).

Defense policies go further: under Information Security Oversight Office (ISOO) guidance, contractors can't enter CUI into public or consumer AI tools at all, and any AI tool that processes CUI must appear in the contractor's System Security Plan.

Use these examples to anchor your own policy in the tools, data types, and compliance obligations your organization actually has.

Why an AI governance policy matters

A written policy gives AI adoption a governance model that security teams can measure, enforce, and improve. It also turns tool approval, data access, monitoring, and escalation into reviewable evidence.

AI adoption expands the attack surface faster than security can assess it

Every new Copilot, ChatGPT, or embedded AI feature needs access to organizational data, and each one creates a new access path to govern. The Netwrix 2026 Data and Identity Security Report found that 76% don’t fully govern or monitor non-human identities in their environments, so most AI tool adoption happens without continuous visibility.

Regulatory frameworks are moving from voluntary guidance to enforcement

The EU AI Act's conformity assessment obligations for high-risk systems generally apply from August 2, 2026, with high-risk systems covered by Annex I product legislation following on August 2, 2027. A documented policy helps show that the organization tracked the requirement before it became mandatory. Waiting for a regulation to bind before writing anything down leaves no evidence of good-faith effort.

Auditors and boards now expect a documented policy

When leadership asks, "Are we secure on AI?" a written policy is the evidence that the answer is more than an opinion. A verbal assurance falls apart during an audit or incident review. The policy translates a security posture into something an auditor can read and a board can point to, which aligns with the expectation formalized in ISO/IEC 42001.

Least privilege applies to AI tools only when a policy defines their access

Security teams have spent years restricting human access by role. Teams frequently exempt AI tools from that same discipline by default, treating them as either extensions of the human who deployed them or as generic service accounts. Identity guidance discourages both approaches because least privilege requires scoped, accountable access. A policy names AI tools as their own account class, subject to real access limits.

Organizations without one are already paying for it

The Netwrix 2026 Data and Identity Security Report found that 72% of organizations say identity-related risk to sensitive data has risen over the past two years due to AI and automation. The policy gap already shows up in risk data, and the organizations reporting it are the ones adopting AI fastest.

What to include in an AI governance policy

A usable policy needs clauses that security, legal, IT, and data owners can translate into decisions on approval and access. Each clause should connect a policy statement to the owner, tool, data category, or control that makes it enforceable.

• Scope and applicability: Defines who the policy covers and what it applies to, including employees, contractors, vendors, and shadow AI tools already in use. Without an explicit scope, the policy governs only the tools people already know about, leaving the rest ungoverned.
• Governance roles and steering committee: Names of those who own the policy and whom to escalate to when something falls outside it. Without a named owner, "policy enforcement" defaults to whoever notices the problem first.
• Risk classification: Sorts AI use cases into low, medium, and high risk based on what data or decisions they touch. Without tiers, every AI use case gets the same level of scrutiny, so high-risk uses get under-reviewed and low-risk ones create needless friction.
• Data access and usage rules: Specifies what data each risk tier of the AI tool can and can't access. It's the clause that turns a values statement into an enforceable control. Without it, "responsible AI use" has no technical meaning.
• Approved tools and vendor review process: Establishes how security, legal, and data owners vet and approve a new AI tool before anyone connects it to company data. Without this, tool adoption occurs through whoever found it first, rather than through a security review.
• Monitoring and audit requirements: Defines how the organization verifies that teams follow the policy in practice. A policy that nobody checks against reality exists only on paper.
• Incident response and escalation: Sets out what happens when an AI tool causes or reveals a security or compliance issue. Without this, teams handle an AI-related incident ad hoc, under the wrong playbook, or too late.
• Regulatory alignment: Maps the policy to applicable frameworks, including the NIST AI RMF, ISO/IEC 42001, and the EU AI Act. This lets one policy satisfy multiple compliance obligations instead of requiring a separate document per regulation.
• Review and update cadence: Commit to revisiting the policy on a set schedule and after major triggers, such as new tool categories, regulatory change, or incidents. AI tooling changes faster than most policy review cycles account for, so a policy without a cadence goes stale within months.

How to write an AI governance policy that balances adoption with accountability

Leadership wants AI adoption to move fast; security owns the consequences if it moves carelessly. Write the policy in the order security teams need evidence: owners first, then tools and data flows, then risk tiers, access rules, regulatory mapping, and review cadence. Access rules written before the inventory usually miss the tools already creating exposure.

1. Assemble a cross-functional governance team before you write a word

Start by naming the actual seats: an information security or Identity and Access Management (IAM) lead to own enforcement, legal and compliance for regulatory language, an IT or data owner who knows where sensitive data lives, one business-unit representative who uses AI tools day to day and an executive sponsor who can approve exceptions.

Pick the chair based on which role already has standing to bind business units outside of security, not just inside it. In security-led organizations, that's the CISO. In risk-first organizations, it's a senior risk executive instead, because business units already answer to that role on enterprise risk, and AI governance needs the same standing or those units will treat it as optional.

Keep it to one person per role, with a secondary only where workload demands it. If security writes the policy alone, it reads like a security document and may lack the authority to govern the business units that generate the risk.

2. Inventory the AI tools and data flows you already have, including shadow AI

Build the inventory from four sources at once: SaaS spend, procurement records, browser extension, Open Authorization (OAuth) grant audits, and a direct survey of business units.

Cross-reference all four, because employees routinely omit tools they assume are "just a writing assistant," and procurement records miss anything expensed individually. Individual subscriptions can slip under approval thresholds, and spend reviews may miss bundled AI tiers inside existing SaaS contracts.

For Microsoft 365, enumerate enterprise applications and service principals in Entra ID, and flag any that hold delegated or application Microsoft Graph permissions, since each grant is an access path AI tools can use.

OAuth consent grant audits and Microsoft's remediation steps for illicit consent grants help expose and clean up risky authorizations. Capture each tool's purpose, the business owner, and the data it touches in an AI system inventory as you go.

3. Classify AI use cases by risk tier

Classify each use case on two criteria together:

1. What data the tool touches (public, internal, regulated, or personally identifiable information (PII)).
2. What it does with that data (summarizes and displays it, informs a business decision, or takes autonomous action).

A tool that only rewrites public marketing copy is low risk regardless of how sophisticated it is. A tool that pulls customer records to answer support tickets is high risk even if its output looks routine.

An autonomous tool that executes transactions or modifies production sits at the top tier and requires mandatory human approval. If you operate in the EU, layer these internal tiers on top of the EU AI Act categories so both schemes remain visible.

4. Define what data each risk tier can and can't access

Write each access rule as a direct mapping from risk tier to data category. Low-risk tools get access to non-sensitive, already-public content. Medium-risk tools are scoped to access specific, already-classified data sets. High-risk tools require explicit written approval, access logging, and a named human reviewer before deployment.

For regulated data, name the condition explicitly: PHI requires a signed Business Associate Agreement, and CUI can't be entered into any tool outside an accredited environment.

5. Define escalation and incident response before you publish

Name what happens when an AI tool causes or reveals a security or compliance issue: who gets notified, how fast, and which existing incident response process picks it up. Tie the escalation path to the governance roles named in step 1, so an issue has a named owner instead of defaulting to whoever notices it first.

Without this step written down, teams end up handling an AI-related incident ad hoc, under the wrong playbook, or too late, exactly the gap a policy is supposed to close before an incident forces the question.

6. Map your policy to the regulatory frameworks that apply

One control matrix can serve every framework you carry. Align the four AI RMF functions (Govern, Map, Measure, and Manage) against ISO/IEC 42001's management-system clauses and the AI Act risk tiers, then write the policy language once against that combined matrix.

The two standards complement each other: the NIST AI RMF provides the operational risk management actions, and ISO/IEC 42001 provides the governance architecture and audit trail. Using the same control language across these frameworks reduces duplicate documentation across every obligation you carry.

7. Set a review cadence before you publish

Commit to a specific interval, annual at minimum, plus named triggers that force an off-cycle review: adoption of a new AI tool category, a regulatory change, an incident, or an acquisition or reorganization, including major changes in business processes and related data requirements.

Tier the cadence to risk, with teams reviewing higher-risk systems more often and the governance committee meeting on a recurring schedule regardless. Write the cadence, triggers, and owner in the document itself. A review schedule that lives only in someone's head lapses the moment that person changes roles.

How to enforce an AI governance policy in practice

Policy clauses need technical controls that security can verify. "The policy says no" only matters when visibility, access review, alerts, and revocation make that answer true.

Get full visibility into what your AI tools can actually access

Enforcement starts with a live map of AI tool-to-data connections: OAuth grants, Microsoft 365 and Microsoft Entra ID permissions, browser extensions, and any embedded AI features inside existing SaaS platforms.

Close the front door at the same time: disable user consent for unverified applications and route new requests through the admin consent workflow, so new AI integrations enter the review process by default.

Security teams can usually answer "who has access to what" for human accounts; this step builds the equivalent answer for AI tools and agents, including effective permissions that result from nested groups and inherited access.

Native Microsoft tooling helps here, though Purview DSPM for AI runs its automated risk assessment against only the top 100 SharePoint sites, so a broader data security posture view helps validate the native picture and identify gaps.

For Copilot specifically, pair sensitivity labels with SharePoint site access restrictions and Restricted Content Discovery so oversharing never reaches the grounding data Copilot draws from.

Enforce least privilege for AI the same way you do for people

Treat AI tool and agent identities as their own account class, subject to the same access review and attestation workflow already used for human accounts. Require scoped, expiring access instead of broad, standing permissions and run the joiner-mover-leaver process that governs human offboarding against AI tool decommissioning as well.

Zero Standing Privilege models this discipline by using task-scoped, ephemeral accounts instead of persistent elevated credentials.

Eastern Carver County Schools applied exactly this discipline: instead of leaving admin accounts standing around student data, the district scoped privileged access only when needed using Netwrix Privilege Secure, and the rollout took days rather than a quarter-long project.

Anchor every agent identity to a human sponsor so each account keeps an accountable owner when the human owner leaves. Current identity guidance recommends shorter review cadences for agents than for people, quarterly at minimum and monthly for high-privilege agents, because agent access changes faster than annual certification catches.

Monitor AI-driven data exposure on an ongoing basis

Monitoring has to run continuously, because a one-time access review goes stale the moment a new AI tool or integration appears. Track what data AI tools actually query and retrieve, going beyond recorded permissions, and flag volume or sensitivity patterns that fall outside approved use.

In Microsoft 365, Copilot interactions are captured in the unified audit log, so confirm that audit retention matches the evidence window the policy commits to before an auditor asks for last year's records. This provides security teams with evidence that the policy's access rules align with actual AI behavior.

Netwrix AI Governance, delivered through Netwrix 1Secure™, adds Copilot interaction tracking and reporting that security teams can preserve as audit evidence.

Automate alerts and escalation when an AI tool crosses its access boundary

Detection only has value if it triggers the escalation path the policy already defines. Route findings automatically to the incident response process named in the policy's governance section, and log every alert as audit evidence. The escalation path must connect to a functioning revocation process with clear ownership and timing.

Turn your AI governance policy into an enforceable control

A written policy reduces risk when each clause maps to a technical control: visibility into what AI tools can access, least privilege for AI identities, and continuous monitoring.

Many AI-related risks follow the same access path as identity incidents: attackers use legitimate credentials to reach data, and an AI tool with overbroad standing access becomes another over-permissioned identity in the environment.

Data security and identity security are the same problem seen from two angles, and the policy reduces risk only when both are enforced together.

Request a demo to see how 1Secure maps AI tool access, tracks Copilot interactions, and turns your policy's access rules into audit evidence.