Nov 10 2026

Your AI Policy Isn’t Evidence. Here’s What Auditors Actually Sample

Category: AI,AI Governance,AI Risk,Information Security — disc7 @ 8:58 am

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:

ClauseWhat it requiresEvidence an auditor samples
4 ContextScope and AI system boundaryAIMS scope, AI system register, interested-party register
5 LeadershipAccountable governanceSigned AI policy, RACI, management commitment records
6 PlanningAI risk assessment, treatment, impact assessmentRisk register, treatment decisions, AISIA records, measurable objectives
7 SupportCompetence and awarenessTraining logs, competence records, communication plan
8 OperationControls running in practiceExecuted assessments, lifecycle records, supplier AI reviews, incident records
9 Performance evaluationMeasurement and auditKPIs, internal audit reports, management review minutes
10 ImprovementCorrective actionNonconformity 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.

StandardFocusWhere it plugs into 42001Evidence it should produce
ISO/IEC 38507Governance of AI by the board and governing bodiesClause 5 LeadershipBoard-approved AI risk appetite, oversight charter, management review minutes showing board-level decisions
ISO/IEC 23894AI risk management guidance, built on ISO 31000Clauses 6.1.2 and 6.1.3, Annex A.5AI risk register with likelihood, impact, owners, and documented treatment decisions
ISO/IEC TR 24028Trustworthiness: transparency, explainability, robustnessAnnex A.6 lifecycle and A.8 information for interested partiesModel cards, explainability notes, robustness and adversarial test results
ISO/IEC TR 24368Ethical and societal concernsClause 6.1.4 AI system impact assessmentCompleted AISIAs covering fairness, affected groups, and reversibility of harm
ISO/IEC 5259 seriesData quality for analytics and machine learningAnnex A.7 data for AI systemsData provenance records, quality metrics, bias testing on training and evaluation data
ISO/IEC 23053 and 22989ML system framework and AI concepts and terminologyClause 4 scope and the AI system registerConsistent 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 threatControl that actually worksEvidence that proves it
Indirect prompt injectionCapability restriction, isolated sub-agents with no tools for untrusted contentArchitecture review record, red-team test results with dates and findings
Confused deputyServer-side authorization at the tool boundary using the end user’s identityTool authorization matrix, access test logs
Data exfiltration via agentsEgress allowlisting, human approval on consequential actionsEgress config snapshots, approval logs with real parameters
RAG cross-tenant leakageTenant filters applied in the vector queryRetrieval test cases run per release
MCP server riskOAuth 2.1 with PKCE, token audience validation, tool manifest integrityMCP governance standard, manifest hash records, server inventory
Model supply chain changeSupplier 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.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.

  1. Days 1–30: Discover and scope.
    1. Build the AI system register, including SaaS AI features, copilots, agents, and MCP servers.
    1. Define AIMS scope and document intended purpose for each in-scope system.
    1. Run a gap assessment against ISO 42001 Clauses 4–10 and Annex A, with an evidence column, not just a status column.
  2. Days 31–60: Assess and control.
    1. Complete AI risk assessments using ISO/IEC 23894 and AISIAs informed by ISO/IEC TR 24368.
    1. Threat-model each agentic system for the lethal trifecta, prompt injection, and confused-deputy paths.
    1. Draft the Statement of Applicability with an evidence reference for every applicable control.
    1. Assess third-party AI suppliers and add AI-specific contract clauses.
  3. Days 61–90: Prove and improve.
    1. Run the controls and capture the records: oversight reviews, red-team results, retrieval tests, training logs.
    1. Exercise the AI incident process with a tabletop and log it.
    1. Conduct an internal audit and hold a management review with minutes.
    1. 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.

“DiscInfoSec” Deura is Principal Consultant at DISC InfoSec, holding CISSP, CISM, ISO/IEC 42001 Lead Implementer, and ISO/IEC 27001 Lead Implementer credentials.

Tags: AI Audit Evidence, AI policy