ISACA's 2026 AI Pulse Poll, which surveyed more than 3,400 digital trust professionals, found that 90% say employees use AI at work, while only 38% of organizations have a comprehensive AI policy, up from 28% a year earlier. A further 25% have no active policy at all. The more revealing numbers sit one level down. Only 12% of respondents said their organization has a documented process for shutting down or overriding AI systems that is tested regularly, and 56% did not know how long it would take to halt an AI system during a security incident. A written policy can exist in the same organization as an unknown stopping time.
That contrast is the subject of this guide. A policy is a statement of intent. Governance is the set of mechanisms that make the intent happen without depending on anyone's memory or goodwill: a register that shows which AI systems exist, an approval gate that new ones must pass, controls matched to risk, evidence that the controls ran, and a way to stop a system that misbehaves. The practical test is simple. If an AI system starts producing harmful output at two in the morning, who can stop it, how long does that take, and who gets told?
External pressure will not supply this discipline on a convenient schedule. India's AI Governance Guidelines, released by MeitY on 5 November 2025, are voluntary, rest on seven guiding principles, and rely on existing laws such as the IT Act and the DPDP Act, with no standalone AI statute. In the European Union, Regulation (EU) 2026/1744, the Digital Omnibus, moved the high-risk obligations to 2 December 2027, though transparency duties under Article 50 have applied since 2 August 2026 and the AI literacy duty in Article 4 remains in a reworded form. Some obligations are already live, others are arriving, and the largest part of the work is voluntary. Organizations that wait for a deadline to build governance will build it late.
This guide sets out how to move from a policy document to working governance in eight steps. It covers why policies stall, what the scope of governance has to include, how to build an inventory, tier systems by risk, match controls to tiers, embed gates in existing workflows, manage third-party AI, operate and monitor, and measure. It also translates policy lines into controls and evidence, maps the Indian and international requirements, and offers a 90-day plan. It is written for CISOs, risk and compliance leaders, legal and privacy teams, and the product and procurement leaders who have to make the policy real.
Why Policies Fail to Become Practice
Most failed AI governance programmes share a small number of patterns.
| Failure pattern | What it looks like | What fixes it |
|---|---|---|
| A policy with no inventory | Rules exist for AI the organization has not found | A maintained register of every AI system, including embedded and unsanctioned ones |
| A policy with no owner | Everyone agrees AI needs oversight and no one holds the accountability | A named executive owner and a committee with decision authority |
| A policy with no gate | New AI arrives through procurement, SaaS updates, and personal accounts without review | Approval steps inside the processes AI already passes through |
| A policy with no tiers | A chatbot for lunch menus gets the same scrutiny as a model scoring loan applicants | Controls that scale with risk |
| A policy with no evidence | Compliance is asserted and cannot be shown | Records that each control ran |
| A policy with no stop button | A system can be launched and cannot be halted quickly | A tested shutdown and override process |
| A policy written for projects | AI shows up as features inside software the organization already runs | Governance that covers features, services, and agents, not only dedicated AI projects |
What AI Governance Has to Cover
The first practical decision is what counts as an AI system for governance purposes. A definition limited to models the organization builds will miss most of the exposure.
| Category | Examples | Why it needs coverage |
|---|---|---|
| Built or fine-tuned models | Internal scoring, forecasting, and classification models | The organization is the producer and carries the lifecycle duties |
| Third-party AI services | Models accessed through an API, AI features inside business software | The organization is the user and still owns the consequences of its use |
| Embedded features | Summaries, drafting, and recommendations added to existing tools by an update | They arrive without a procurement decision |
| Agents | Systems that call tools and take actions | Their permissions and autonomy raise the stakes |
| Employee use of public tools | Staff using chat tools with work data | The usual source of shadow AI and data exposure |
ISO/IEC 42001 frames this through AI roles, which are useful here. An organization is an AI user for the services it consumes and becomes closer to a provider once AI output reaches its own customers or staff, and each role carries different duties.
The Implementation Path
Step 1: Set accountability and structure
Decide who owns AI governance and who decides. That usually means an executive owner, a cross-functional committee, and a defined role for each function that touches AI.
| Role | Responsibility in AI governance |
|---|---|
| Board or board committee | Approves the policy and risk appetite, and receives regular reporting |
| Executive owner | Accountable for the programme and for escalations |
| AI governance lead | Runs the register, the intake process, and the reporting |
| Product and engineering | Builds and operates systems within the controls |
| Security | Reviews and tests systems, and handles AI incidents |
| Legal and privacy | Assesses data protection, contract, and regulatory exposure |
| Procurement | Applies vendor due diligence and contract terms |
| Business owners | Own the use case and its outcomes |
| Internal audit | Provides independent assurance |
Step 2: Build the AI inventory
Governance starts with knowing what exists. An inventory entry should capture enough to support a risk decision.
| Inventory field | Why it matters |
|---|---|
| Purpose and business owner | Establishes accountability and intended use |
| Model and vendor | Supports supply chain and contract review |
| Data used, including personal data | Connects to privacy duties |
| People affected | Drives the risk tier |
| Level of autonomy and tool access | Determines how much damage a failure can do |
| Hosting location and data flows | Supports residency and security review |
| Approval status and date | Shows whether the system passed the gate |
| Risk tier and next review date | Drives control intensity and scheduling |
Self-reporting alone will under-count. Discovery should draw on several sources.
| Discovery source | What it finds |
|---|---|
| Procurement and expense records | Paid AI tools and subscriptions |
| Single sign-on and application grants | Tools employees authorized with work accounts |
| Network, browser, and endpoint telemetry | Unsanctioned tools in actual use |
| Cloud and API usage logs | Models called from internal systems |
| Owner surveys and architecture reviews | Embedded features and planned systems |
Step 3: Tier systems by risk
Controls that apply equally to everything either smother low-risk uses or under-protect high-risk ones. Three tiers are usually enough to begin.
| Tier | Typical characteristics | Examples |
|---|---|---|
| Lower | Internal productivity use, no personal or sensitive data, a person reviews output | Drafting assistance on public information |
| Medium | Customer-facing, or personal data involved, but a person makes the final decision | A support assistant that suggests answers to agents |
| Higher | Decisions about people, regulated use, autonomous actions, or safety and financial impact | Credit or hiring decisions, agents that move money or change records |
Tier criteria should also map to external categories where they apply. The EU AI Act's Annex III uses, such as employment, credit, and education, become high-risk obligations on 2 December 2027, and Article 50 transparency applies by function regardless of tier.
Step 4: Match controls to tiers
| Control | Lower tier | Medium tier | Higher tier |
|---|---|---|---|
| Registration in the inventory | Required | Required | Required |
| Approval authority | Business owner | Governance lead | Committee |
| Impact and risk assessment | Short checklist | Documented assessment | Full assessment, including effects on individuals |
| Privacy and data review | Confirm no personal data | Required | Required, with a data protection impact assessment where applicable |
| Security testing | Standard review | Review and testing | Adversarial testing, including red teaming for agents and exposed systems |
| Human oversight | Optional | Defined | Defined, with authority to override and a tested stop process |
| Transparency to users | As applicable | Required where people interact with the system | Required, with explanation of use |
| Logging and monitoring | Basic | Defined | Full, with review of outputs and drift |
| Review frequency | Annual | Every six months | Quarterly, and on any significant change |
Step 5: Put gates inside existing workflows
New workflows invite bypass. Governance works best when the gates sit inside processes that already exist.
| Existing workflow | Gate to add | Evidence produced |
|---|---|---|
| Procurement | AI question set and tier assignment before purchase | Completed questionnaire and register entry |
| Architecture and security review | AI design review for new systems and integrations | Review record and test results |
| Software release or model deployment | A release check that the system is registered, tested, and approved | Approval record linked to the release |
| Change management | Re-review when the model, prompt, data, or tools change | Change ticket with risk update |
| Identity and access | Single sign-on with an approved list of AI services and scoped credentials for agents | Access logs and allow lists |
| Onboarding and training | Acceptable use training and acknowledgement | Training records |
Step 6: Manage third-party AI
The DBIR reports third-party involvement in 48% of breaches, and most organizations consume more AI than they build. Vendor due diligence for AI should add questions to the usual security review.
| Question | Why it matters |
|---|---|
| Is customer data used to train or improve models, and can that be turned off? | Confidentiality and data protection |
| Where is data processed and how long is it retained? | Residency and retention duties |
| Which sub-processors and underlying models are involved? | Hidden dependencies |
| How are model changes communicated? | Behavior can shift without notice |
| What security assurance exists, and is adversarial testing performed? | Evidence of control |
| How are incidents notified, and within what time? | Supports reporting clocks |
| What audit rights and exit terms apply? | Control and portability |
Step 7: Operate, monitor, and be ready to stop
Operating governance means watching systems after launch. Monitoring should cover performance, drift, harmful or inaccurate output, misuse, and cost, with thresholds that trigger review.
Incident handling needs an AI-specific definition. Under CERT-In's Directions, attacks and incidents affecting AI and machine learning systems are among the listed incident types to be reported within six hours of noticing, and from May 2027 the DPDP Rules add a breach intimation duty where personal data is involved. The shutdown and override process deserves particular attention, given how few organizations in the ISACA poll had one that is tested. A drill that measures time to halt a system is the most direct way to turn the answer to the two-in-the-morning question into a number.
Step 8: Measure and improve
| Metric | What it shows |
|---|---|
| Inventory coverage, registered systems against discovered systems | Whether governance sees the real estate |
| Share of higher-tier systems with a completed assessment and test | Whether the controls ran where they matter |
| Time from request to decision | Whether the process is workable or being bypassed |
| Exceptions with expiry dates, and how many lapsed | Whether risk acceptance is controlled |
| Time to halt a system in a drill | Whether the stop button works |
| Training completion and policy acknowledgement | Whether staff know the rules |
| Incidents and near-misses, with closure time | Whether the system learns |
| Audit findings closed | Whether assurance feeds improvement |
Training deserves attention for a regulatory reason as well. Article 4 of the EU AI Act, as reworded by the Omnibus, requires providers and deployers to take measures to support AI literacy of their staff, without guaranteeing a specific level of literacy for any individual, so a record of measures taken is the evidence to keep.
What a Policy Line Looks Like When It Is Implemented
| Policy statement | Control that implements it | Evidence | Owner |
|---|---|---|---|
| All AI use must be approved | Intake gate in procurement and architecture review, with an approved services list | Register entry and approval record | Governance lead |
| Personal data may be used in AI only with a lawful basis | Privacy review before approval, and data flow mapping | Assessment record | Privacy lead |
| Higher-risk systems must have human oversight | Defined override authority and a tested stop process | Drill results and role assignments | Business owner |
| Systems must be tested before release | Security and adversarial testing as a release condition | Test report linked to release | Security lead |
| Vendors must meet minimum standards | AI due diligence questionnaire and contract clauses | Completed review and signed terms | Procurement |
| Staff must use AI responsibly | Acceptable use training and acknowledgement | Training records | HR and governance lead |
| Incidents must be reported promptly | AI incident definition, triage steps, and reporting templates | Incident records and filing times | Security lead |
| Policy must be reviewed regularly | Scheduled reviews and change triggers | Review minutes | Committee |
Where Regulation and Standards Land
| Instrument | Status as of October 2026 | What it means for implementation |
|---|---|---|
| EU AI Act, Article 50 transparency | Applies since 2 August 2026, with a grace period to 2 December 2026 for marking content from systems already on the market | Disclose AI interaction and label synthetic content |
| EU AI Act, Article 4 AI literacy | Applies, reworded to require measures that support literacy | Keep records of training and awareness measures |
| EU AI Act, Annex III high-risk | Applies from 2 December 2027 | Prepare risk management, data governance, oversight, and logging |
| India AI Governance Guidelines | Released 5 November 2025, voluntary | Seven principles, existing laws apply, sector regulators lead |
| RBI FREE-AI report | Published 13 August 2025, recommendations | Board-approved AI policy and human judgment for regulated entities |
| DPDP Act and Rules 2025 | Core obligations take effect in May 2027 | Safeguards under Rule 6 and breach intimation under Rule 7 for AI that handles personal data |
| CERT-In guidance CISG-2026-02 | Published 25 May 2026, timelines indicative | Secure AI deployments, AI bills of materials, and adversarial testing |
| ISO/IEC 42001:2023 | Voluntary, certifiable | An AI management system with roles, impact assessment, and controls |
| NIST AI RMF | Voluntary, version 1.0 being revised | Govern, Map, Measure, and Manage functions as a structure |
What Weak Implementation Costs
| Gap | Consequence |
|---|---|
| No inventory | Unknown systems with unknown data flows and no one accountable |
| No access controls on AI systems | IBM's 2026 research found 92% of organizations with an AI-related breach lacked proper access controls |
| No testing before release | Weaknesses found in production, where prompt injection incidents averaged $5.89 million in IBM's data |
| No tested stop process | Harm continues while the organization works out how to halt the system |
| Personal data in AI without safeguards | Exposure under the DPDP Act, where failure to implement reasonable security safeguards carries a penalty of up to ₹250 crore once the provision takes effect |
| No evidence of controls | Difficulty satisfying a customer, auditor, or regulator that the policy is followed |
A Maturity Model for AI Governance in Practice
Level 1: AI is adopted informally, and a policy either does not exist or sits unread ↓ Level 2: A policy is approved, with no inventory, gates, or evidence behind it ↓ Level 3: An inventory exists, systems are tiered, and approval gates sit inside procurement and release processes ↓ Level 4: Controls are matched to tier, vendors are assessed, systems are monitored, and a stop process is drilled ↓ Level 5: Governance runs as a continuous programme with metrics reported to the board, tied to ISO/IEC 42001 and applicable regulation, and improved from incidents and audits
The step from Level 2 to Level 3 matters most, since an inventory and a gate convert a statement of intent into something that can be checked.
A 90-Day Plan
| Window | Focus | Outputs |
|---|---|---|
| Days 1 to 30 | Accountability and discovery | A named owner, a committee, a first inventory built from several discovery sources, and a short list of the highest-risk systems |
| Days 31 to 60 | Tiering and gates | Tier criteria, control matrix, AI questions added to procurement and architecture review, and assessments for the highest-risk systems |
| Days 61 to 90 | Operation and measurement | Monitoring for higher-tier systems, a first stop-process drill, vendor questionnaire in use, and a first board report with metrics |
Common Mistakes and Edge Cases
Writing the policy first and the inventory never. Rules for systems nobody has found do not protect anything.
Applying one control set to everything. Uniform heavy controls drive staff to work around them, and uniform light controls leave the risky systems exposed.
Ignoring embedded features. Many AI capabilities arrive through updates to software already in use, with no purchase decision to trigger a review.
Treating the gate as a one-time event. Models, prompts, data, and tool access change, and the review has to change with them.
Never drilling the stop button. A shutdown process that has not been tested is an assumption.
Leaving vendors out. Most organizations consume more AI than they build, so third-party practices set much of the risk.
Reporting activity instead of outcomes. A count of policies written says little, while inventory coverage and time to halt say a lot.
When to Use What: A Few Decision Points
Central versus federated governance. A central team gives consistency and is the usual starting point. Larger organizations with many business units often move to a federated model, with local leads working to central standards.
A spreadsheet versus a governance platform. A spreadsheet is enough to begin with a small inventory. A platform becomes worthwhile when the number of systems, owners, and evidence items makes manual tracking unreliable, and it supports discovery and workflow rather than replacing decisions.
Certifying to ISO/IEC 42001 now or later. Certification suits organizations facing customer or regulatory pressure for independent assurance. Others can build the same management system first and certify when the case is clear.
How much to tier. Three tiers are usually enough to start. More tiers add precision and process, and are worth it only when the extra distinctions change the controls.
In-house versus external support. Internal teams hold the context. An external party adds benchmarks, independence, and the ability to run the first assessment and test quickly.
How SecNinjaz Fits Into This
AI governance work sits in SecNinjaz's GRC and DPDP practice, which covers AI Governance, ISO Certification and Compliance, Audit and Gap Assessment, Risk Management, and Regulatory Compliance, with vCISO support for organizations that need senior security leadership guiding the programme. The testing that tier-three controls call for comes from SecNinjaz's Cybersecurity practice, including AI and LLM Security Testing and AI Red Teaming, whose findings feed the risk assessment and the evidence file.
SecNinjaz holds ISO/IEC 42001:2023 for AI management systems, along with ISO/IEC 27001:2022 for information security and ISO/IEC 27701:2025 for privacy information management, which means the management system described in this guide is one the organization operates itself. For enterprises trying to move from an approved policy to governance that can be shown to a customer, an auditor, or a regulator, that pairing of governance practice and adversarial testing is the one worth looking for, whether the enterprise works with SecNinjaz or anyone else.
Frequently Asked Questions
What is enterprise AI governance?
Enterprise AI governance is the set of roles, processes, and controls that decide which AI systems an organization uses, how risky each one is, what safeguards apply, and who is accountable. It turns an AI policy into inventory, approval gates, testing, monitoring, and evidence.
What is the difference between an AI policy and AI governance?
A policy states intent and rules. Governance is the machinery that makes the rules operate: a register of systems, an approval process, risk tiers, controls, monitoring, and a way to stop a system. ISACA's 2026 poll found 38% of organizations with a comprehensive policy but only 12% with a tested shutdown process.
Does India have an AI law?
There is no standalone AI statute. MeitY's AI Governance Guidelines, released on 5 November 2025, are voluntary, set out seven guiding principles, and state that existing laws such as the IT Act and the DPDP Act already apply to AI. Sector regulators such as the RBI and SEBI also issue their own expectations.
What changed in the EU AI Act timeline in 2026?
Regulation (EU) 2026/1744, the Digital Omnibus, moved the Annex III high-risk obligations to 2 December 2027 and Annex I to 2 August 2028. Article 50 transparency duties have applied since 2 August 2026, and the AI literacy duty in Article 4 was reworded to require measures that support literacy.
What should an AI inventory contain?
For each system: its purpose and business owner, the model and vendor, the data used including personal data, the people affected, the level of autonomy and tool access, hosting and data flows, approval status, risk tier, and next review date. Discovery should combine procurement records, sign-on grants, telemetry, and owner surveys, since self-reporting alone under-counts.
How should AI systems be tiered by risk?
Three tiers are usually enough to start. Lower-tier systems are internal productivity uses without sensitive data and with human review. Medium-tier systems are customer-facing or involve personal data but keep a person in the decision. Higher-tier systems make or shape decisions about people, operate in regulated settings, or take autonomous actions.
Does AI governance need a dedicated platform?
Not at the start. A spreadsheet can hold a small inventory and approval log. A platform becomes useful as the number of systems, owners, and evidence items grows, mainly for discovery, workflow, and reporting, while decisions remain with accountable people.
Where should an organization start?
Name an executive owner and a committee, then build a first inventory from procurement records, sign-on grants, and telemetry. Tier the systems, put AI questions into procurement and architecture review, assess the highest-risk systems first, and run a drill to measure how quickly a system can be halted.
