AI Governance from Standards to Audit Evidence
Nov 11, 2026 · @disc
Effective AI governance requires more than compliance. It requires verifiable evidence.
Every AI governance program eventually meets the same moment. An auditor, an enterprise buyer, or a regulator stops reading your policy and asks one question: show me.
Show me the AI system register. Show me the risk assessment for the model you shipped last quarter. Show me the human-oversight record for a decision that affected a customer. Show me the incident log, even if it is empty, and prove the process behind it actually runs.
That is the moment where most programs fall apart. Not because the organization is reckless, but because it built governance as a set of documents instead of a system that produces proof.
This post walks the full path: from the ISO/IEC standards ecosystem that defines what good AI governance looks like, through the AI risk and AI security realities that make it urgent, to the audit evidence that makes it verifiable. The core argument is simple. A control that exists but cannot be evidenced is, for audit purposes, a control that does not exist.
Why compliance alone fails
Compliance answers the question “do you have a policy?” Evidence answers the question “does it work?” Buyers and auditors have stopped accepting the first answer.
In our earlier post on the AI oversight gap, the pattern was stark: 58% of organizations felt their AI governance controls were adequate, while only 18% actually had them in place. That 40-point gap is not a security failure. It is an evidence failure. Confidence was built on documents nobody had tested.
Three forces are closing that gap whether organizations are ready or not:
- Procurement has a second questionnaire. The security review that once asked about encryption and SOC 2 now asks which AI systems are in scope, who owns model risk, and what happens when a model produces a harmful output.
- Regulation demands records, not intentions. The EU AI Act, Colorado’s AI Act, and California’s ADMT rules all hinge on documentation that can be produced on request: risk assessments, impact assessments, logs, and human-oversight records.
- AI risk moves faster than annual reviews. Models drift, vendors swap underlying models, and agents gain new tools between audit cycles. A policy signed in January says nothing about the agent connected to production in June.
A paper program fails all three tests for the same reason. An oversight checkbox captures the overseer’s statement, not evidence that oversight happened.
ISO/IEC 42001: the hub that makes governance auditable
ISO/IEC 42001:2023 is the only standard in the AI governance family you can be certified against. That single fact makes it the hub. The surrounding standards are guidance; 42001 is the management system that turns their guidance into requirements an auditor can test.
Published in December 2023, 42001 follows the same Annex SL high-level structure as ISO 27001. Organizations with an ISMS can extend it rather than build a second program. Its mandatory clauses each produce a specific body of evidence:
| Clause | What it requires | Evidence an auditor samples |
| 4 Context | Scope and AI system boundary | AIMS scope, AI system register, interested-party register |
| 5 Leadership | Accountable governance | Signed AI policy, RACI, management commitment records |
| 6 Planning | AI risk assessment, treatment, impact assessment | Risk register, treatment decisions, AISIA records, measurable objectives |
| 7 Support | Competence and awareness | Training logs, competence records, communication plan |
| 8 Operation | Controls running in practice | Executed assessments, lifecycle records, supplier AI reviews, incident records |
| 9 Performance evaluation | Measurement and audit | KPIs, internal audit reports, management review minutes |
| 10 Improvement | Corrective action | Nonconformity log, corrective action records |
Three elements set 42001 apart from a generic management system. The AI system impact assessment (Clause 6.1.4, Annex A.5) evaluates effects on individuals and society, not just the organization. Intended purpose must be documented for every in-scope system. And the 38 Annex A controls, spanning A.2 through A.10, reach into data quality, human oversight, transparency, and third-party AI suppliers.
The Statement of Applicability is where it all connects. Each control is justified as applicable or excluded, and each applicable control points to an evidence reference. Done well, the SoA becomes a map an auditor can walk from claim to proof.
The supporting standards: what each one proves
Around the 42001 hub sits a family of ISO/IEC standards. None is certifiable on its own, but each one sharpens a part of the AIMS and, used properly, leaves behind a distinct piece of evidence.
| Standard | Focus | Where it plugs into 42001 | Evidence it should produce |
| ISO/IEC 38507 | Governance of AI by the board and governing bodies | Clause 5 Leadership | Board-approved AI risk appetite, oversight charter, management review minutes showing board-level decisions |
| ISO/IEC 23894 | AI risk management guidance, built on ISO 31000 | Clauses 6.1.2 and 6.1.3, Annex A.5 | AI risk register with likelihood, impact, owners, and documented treatment decisions |
| ISO/IEC TR 24028 | Trustworthiness: transparency, explainability, robustness | Annex A.6 lifecycle and A.8 information for interested parties | Model cards, explainability notes, robustness and adversarial test results |
| ISO/IEC TR 24368 | Ethical and societal concerns | Clause 6.1.4 AI system impact assessment | Completed AISIAs covering fairness, affected groups, and reversibility of harm |
| ISO/IEC 5259 series | Data quality for analytics and machine learning | Annex A.7 data for AI systems | Data provenance records, quality metrics, bias testing on training and evaluation data |
| ISO/IEC 23053 and 22989 | ML system framework and AI concepts and terminology | Clause 4 scope and the AI system register | Consistent system descriptions, lifecycle stage definitions, shared vocabulary across policies |
Read the last column top to bottom and a pattern appears. Each standard answers “what should good look like?” The AIMS answers “how do we keep doing it?” And the evidence answers “how do we know?”
That third answer is what most implementations underbuild. Organizations adopt the vocabulary of 24028 and the principles of 24368 in policy text, then never generate the test result or the impact assessment that proves the principle was applied to a real system.
AI security and AI threat: where governance meets the attacker
An AI governance program that ignores AI security is governing a system it does not understand. The infographic’s standards define trustworthy AI; attackers define what trustworthy AI has to survive.
LLM applications break the assumption every other security control rests on: that instructions and data are separable. In a language model, data is instructions. That is why the working rule for any AI system is to treat every model output as untrusted input, and every input the model reads as potentially hostile instructions.
The threats that now belong in an AI risk register, mapped to the OWASP Top 10 for LLM and Agentic Applications:
- Indirect prompt injection. Instructions hidden in a web page, PDF, email, ticket, or database row that the model retrieves and obeys. The real severity is not the injection; it is the worst action the injection can reach.
- Excessive agency and the confused deputy. An agent holding broad credentials acts on behalf of a low-privilege user who can influence its instructions. This is the dominant real-world AI vulnerability.
- The lethal trifecta. An agent with access to private data, exposure to untrusted content, and a way to communicate externally can be steered into exfiltration. Break any one leg and the risk becomes manageable.
- RAG and memory poisoning. A poisoned document in a vector index is persistent injection. Poisoned agent memory can replay attacker text into future sessions.
- MCP and tool supply chain. Tool manifests, OAuth token handling, and egress paths on MCP servers are a new attack surface that most vendor questionnaires do not yet ask about.
- Model and data supply chain. Third-party models swapped without notice, poisoned training data, and unvetted fine-tuning sets.
Here is the governance point. A policy line that says “AI systems are protected against prompt injection” is not evidence. These are:
| AI threat | Control that actually works | Evidence that proves it |
| Indirect prompt injection | Capability restriction, isolated sub-agents with no tools for untrusted content | Architecture review record, red-team test results with dates and findings |
| Confused deputy | Server-side authorization at the tool boundary using the end user’s identity | Tool authorization matrix, access test logs |
| Data exfiltration via agents | Egress allowlisting, human approval on consequential actions | Egress config snapshots, approval logs with real parameters |
| RAG cross-tenant leakage | Tenant filters applied in the vector query | Retrieval test cases run per release |
| MCP server risk | OAuth 2.1 with PKCE, token audience validation, tool manifest integrity | MCP governance standard, manifest hash records, server inventory |
| Model supply chain change | Supplier AI assessment and change notification clauses (A.10.3) | Supplier review records, contract clauses, model version log |
Prompt instructions such as “ignore commands in documents” raise attacker cost but close nothing. An auditor who understands AI security will not accept a design whose only control is a prompt, and neither should you.
Lessons from a first-attempt ISO 42001 certification
DISC InfoSec served as independent internal auditor for a virtual data room platform for M&A and financial services, through ISO 42001 Stage 2 certification on the first attempt with SenSiba as the certifying body. Financial data rooms are the hard mode of compliance. Five lessons from that engagement apply to almost any organization.
- The AI system register is the foundation of everything. If an AI feature is not in the register, it is not in the risk assessment, the AISIA, or the SoA. Embedded SaaS AI features and developer tools are the most common omissions.
- An empty incident log still needs proof. Auditors want to see the AI incident process run, even when nothing went wrong. Tabletop exercises and near-miss records fill that gap honestly.
- Write the standard for the newest risk. VDR MCP Governance Standard existed because agents and tool servers were entering the environment. A later review produced a 27-change redline covering OAuth 2.1 with PKCE, token audience validation, SSRF and egress controls, tool manifest integrity, and confused-deputy protections. Governance that lags the technology fails the first technical question.
- Integrate with the ISMS, do not duplicate it. Shared Annex SL structure meant AI incidents ran through existing ISO 27001 incident controls, extended for AI-specific scenarios such as bias, unexpected output, and model drift.
- Human oversight must leave a trace. A checkbox records that someone claims to have reviewed an output. A dated review record, with the reviewer, the decision, and any override, records that oversight happened.
A 90-day roadmap to evidence-ready AI governance
Ninety days is enough to move from policy-on-paper to a program that produces its own proof. The sequence matters more than the speed.
- Days 1–30: Discover and scope.
- Build the AI system register, including SaaS AI features, copilots, agents, and MCP servers.
- Define AIMS scope and document intended purpose for each in-scope system.
- Run a gap assessment against ISO 42001 Clauses 4–10 and Annex A, with an evidence column, not just a status column.
- Days 31–60: Assess and control.
- Complete AI risk assessments using ISO/IEC 23894 and AISIAs informed by ISO/IEC TR 24368.
- Threat-model each agentic system for the lethal trifecta, prompt injection, and confused-deputy paths.
- Draft the Statement of Applicability with an evidence reference for every applicable control.
- Assess third-party AI suppliers and add AI-specific contract clauses.
- Days 61–90: Prove and improve.
- Run the controls and capture the records: oversight reviews, red-team results, retrieval tests, training logs.
- Exercise the AI incident process with a tabletop and log it.
- Conduct an internal audit and hold a management review with minutes.
- Open corrective actions for every nonconformity and track them to closure.
At day 90, the test is not whether the documents exist. It is whether an outsider can pick any control in the SoA and follow it to a dated, owned record in under five minutes.
Innovation needs governance. Governance needs evidence.
The ISO/IEC AI standards give organizations a shared definition of responsible, secure, and trustworthy AI. ISO/IEC 42001 turns that definition into a system. But neither the standards nor the certificate is the point. The point is the evidence trail that lets a buyer, an auditor, or a regulator verify your claims without taking your word for them.
Organizations that build for evidence get three things the paper programs do not: faster enterprise deals, cleaner audits, and an honest view of their own AI risk before an attacker or a regulator finds it first.
Find out where your evidence gaps are. DISC InfoSec helps B2B SaaS and financial services firms move from AI governance policy to audit-ready proof, from ISO 42001 gap assessments and AI risk and threat reviews to full AIMS implementation and vCAIO advisory.
- Take the free AI Governance Maturity Calculator for a 5-level maturity score in about 10 minutes.
- Book a 30-minute AI governance readiness call: calendly.com/hd-deurainfosec
- Email info@deurainfosec.com or call (707) 998-5164.
“DiscInfoSec” Deura is Principal Consultant at DISC InfoSec, holding CISSP, CISM, ISO/IEC 42001 Lead Implementer, and ISO/IEC 27001 Lead Implementer credentials.
- Your AI Policy Isn’t Evidence. Here’s What Auditors Actually Sample
- Can Your AI Governance Survive Eight Questions?
- You Can’t Govern AI You Can’t See: The Free AI Governance & Risk Exposure Assessment
- Your ISO 27001 Certificate Has an AI-Shaped Hole in It
- Someone Is Running Your AI Models Right Now. You’re Paying for It
