ISO/IEC 42001 audit evidence¶
🔒 Enterprise edition. The ISO/IEC 42001 audit-evidence view is part of the Compliance Insights panel, which is Enterprise-only. On Community the panel shows a locked card instead. See Licensing & tiers.
Read this first: the one sentence that matters. The VIDAI Control Plane does not make you "ISO 42001 compliant," and nobody should present it that way. ISO/IEC 42001 is an AI Management System your organisation runs and gets certified against. For a specific, conservative subset of controls, the control plane is the operational evidence engine: it produces (or makes producible) the runtime evidence an assessor asks for. For everything else, it's your process. Claiming more than that to an auditor is a credibility failure, not a win.
This page explains the ISO/IEC 42001: audit evidence block on the Dashboard Compliance Insights panel: what it shows, the role the control plane plays for each control, and exactly how to describe it to an assessor honestly.
When you'd open this¶
- An auditor or your CISO asks "is the control plane producing the operational evidence an ISO/IEC 42001 assessment expects?"
- You're preparing for an ISO/IEC 42001 assessment and need to know which controls the control plane can speak to and which are your own AI-management-system process.
- Someone on the team said "VIDAI makes us ISO 42001 certified" and you need the accurate version before it reaches an assessor.
- You want to pull the underlying evidence for an audit window and need to know what's available today versus on the roadmap.
The page at a glance¶
The block sits inside the Compliance Insights panel, below the obligation rail. It has three parts:
- An Operational badge: present when request and audit logs are being recorded (the evidence trail is live and stored).
- A per-control table: Control · Role · Evidence in. It lists only the controls the control plane speaks to (9 of the 38).
- A footer: One-click tamper-evident assessor export · Coming soon: a roadmap line, not a readiness disclaimer (see Getting the evidence out today).
What ISO/IEC 42001 is¶
ISO/IEC 42001:2023 is the international standard for an AI Management System: think "ISO 27001, but for running AI responsibly." An organisation pursuing certification is audited against Annex A: 38 controls across 9 groups (A.2–A.10).
Most of the 38 are organisational process you own: AI policy, risk assessments, human oversight, supplier contracts. A minority are runtime / operational controls where an AI control plane is the natural place the evidence already lives. The control plane addresses that minority, and is explicit and conservative about which ones.
The three roles the control plane plays (not a coverage score)¶
Each control is tagged with the role the control plane plays. This is deliberately not a "% covered" scale: it's a precise statement of who owns the evidence. In the table you'll see two role labels; the third (the 29 process controls) is intentionally not listed:
| Role (as shown) | Plain meaning |
|---|---|
| Authoritative SoR | The control plane is the system of record. For this control's operational facet, the auditor's evidence is the control plane's data. (4 controls) |
| enables your evidence | The control plane supplies the evidence primitive that makes your process for this control achievable. You still operate the process; the control plane removes the "we have no data for this" blocker. A positive statement, not a deficiency. (5 controls) |
| (not listed) | The remaining 29 controls are pure organisational / AIMS process. The control plane plays no role and does not claim one, so they're deliberately left out of the table rather than shown as "0% covered." |
The honesty discipline, baked into the product: the control plane evidences 9 of 38, and is loud about the other 29 being yours. A dashboard or pitch that hides the 29, upgrades "enables" to "covered," or says "compliant," is the exact failure this design exists to prevent. The product literally cannot express "ISO 42001 compliant" by design.
📌 Worth knowing. Hovering a role label in the table shows the precise claim. Authoritative SoR: "VIDAI is the authoritative source of this control's evidence (system of record)." enables your evidence: "VIDAI supplies the evidence primitive that makes your process for this control achievable; you still operate the process."
The 9 controls: what they are, what you get¶
Authoritative (4): the control plane is the system of record¶
| Control | What the auditor asks | What the control plane is |
|---|---|---|
| A.6.2.8 AI system recording of event logs | "Do you keep event logs of AI activity across the lifecycle?" | The request / audit log: every model call (principal, time, requested-vs-served model, allow/deny, the rule that fired). The canonical fit. |
| A.6.2.6 AI system operation and monitoring | "Do you monitor the AI system in operation?" | The enforcement record + per-rule attribution + the live posture surface: continuous operational monitoring. |
| A.9.4 Intended use of the AI system | "Is the AI system used only within its intended purpose?" | Access-control / deny / allowlist rules enforce "only team X may use model M" and record every attempt and outcome. |
| A.8.4 Communication of incidents | "Do you have a plan for communicating incidents?" | Deny events, circuit-breaker trips, and guardrail blocks form a timestamped incident-signal stream that feeds your incident process. |
Enables your evidence (5): the control plane makes your process achievable¶
These are not weaker versions of the above. For each, the control plane supplies a runtime evidence slice you'd otherwise lack; you still operate the surrounding process. The boundary, per control:
| Control | What the control plane provides | What stays yours |
|---|---|---|
| A.4.3 Data resources | The operationally-active data path: which models / providers actually processed requests | The full data-resource inventory (datasets, stores, pipelines) |
| A.4.5 System and computing resources | The provider / model inventory actually in use (live / routed / blocked) | The broader compute footprint (training infra, hosts, serving not behind the control plane) |
| A.6.2.5 AI system deployment | The live as-deployed runtime state (which models are active via routing) | The deployment plan + pre-deployment approval gate (a process artifact, before traffic flows) |
| A.7.5 Data provenance | Inference-time lineage: which provider / model served each request. (If you train a new model on control plane request/response logs, the control plane becomes an authoritative provenance source for that model's training data.) | Training / source-data provenance generally: a control plane sits in front of already-trained models. The training-on-logs case is conditional |
| A.10.3 Suppliers | Which AI suppliers / providers are permitted / routed / blocked, with the enforcement record (strong on the enforcement half) | Supplier vetting, due diligence, contracts, risk assessment (the procurement / governance side) |
⚠️ Watch out. The 5 "enables your evidence" controls are not uniform. A.10.3 is enforcement-strong; A.7.5 is the narrowest and conditional. When an assessor asks, describe the specific boundary from the table above; don't present the 5 as equal "partial coverage."
Where each control's evidence lives¶
The table's Evidence in → column links to the in-product surface that holds the runtime data for that control:
- Request Logs →: per-request records (the model call, the principal, allow/deny, the rule that fired).
- Audit →: the routing-rule and provider/supplier configuration-change trail.
- Reports / usage →: the aggregated operational-monitoring surface.
These links are navigation aids to get you to the right surface quickly. The substantive, attestable trail for the supplier/deployment controls is the Audit log (routing and provider/supplier changes are recorded there); per-request residency and model decisions live in Request Logs.
Getting the evidence out today¶
This matters for what you tell an assessor, so read it carefully.
The evidence data exists and is retrievable today for all 9 controls. What does not exist yet is a single per-control, ISO-labelled, tamper-evident export. That's the "Coming soon" in the panel footer.
| Status today | |
|---|---|
| The control list (which controls, what role) | ✅ Available now, verified against the official standard |
| The underlying evidence data for all 9 (per-request records, routing / provider history, the routing & supplier audit trail) | ✅ Retrievable today via Request Logs, the Audit log, and the Reports / usage surfaces. The data is real, complete, and queryable. |
| A per-control, audit-window-scoped, ISO-labelled export | ❌ Not delivered yet. The data isn't pre-sliced per control; assembling "the A.6.2.8 evidence for Q3" is currently manual work over the surfaces above. |
| A tamper-evident export an assessor would treat as immutable | ❌ Not available yet. The per-control attested export is deliberately deferred until a tamper-evidence guarantee is in place. Handing an assessor an export that could have been edited is worse than handing them nothing. |
In plain terms: the evidence is there and you can get it out today; what doesn't exist yet is a one-click, per-control, tamper-evident assessor pack. An assessor will accept the underlying data: it's real and queryable. An assessor should not be told "the VIDAI Control Plane has an ISO audit export" or "it exports tamper-proof evidence". Neither is true yet.
What you can do today, as an interim: pull the records for the audit window from Request Logs, the Audit log, and Reports (each has a CSV download). Describe it to an assessor for exactly what it is: "the underlying records for this window, extracted manually; not yet a per-control attested export." That honesty is itself a good-practice signal to an auditor.
How to talk to an assessor¶
Do say:
- "For these 4 controls, the control plane is our system of record; here is the runtime data."
- "For these 5, the control plane gives us the evidence primitive that makes the control achievable; we operate the surrounding process."
- "These 29 controls are our AI-management-system process; the control plane isn't involved."
- "The control list is authoritative; the underlying evidence is retrievable now via our request and audit logs; a per-control attested, tamper-evident export is on the roadmap and we won't present a non-attested extract as one."
Don't say:
- "The VIDAI Control Plane makes us ISO 42001 compliant." (False: the product can't even express this, by design.)
- "The VIDAI Control Plane covers 9 of 38 controls." ("Covers" overclaims the 5 enablers; use the role language.)
- "Download the ISO audit pack." (Not delivered yet.)
- "The VIDAI Control Plane exports the evidence as a tamper-proof file." (The CSV downloads are working extracts of the underlying records, never an ISO/attested export.)
Limitations¶
- Not certification. This block evidences a subset of operational controls. It does not assess, score, or certify your AI Management System.
- 9 of 38, deliberately. The 29 process controls are yours; they're intentionally absent from the table, not hidden failures.
- No tamper-evident per-control export yet. Shown as "Coming soon." Interim evidence comes from the underlying surfaces.
- The 5 enablers are uneven. A.7.5 is the narrowest and conditional; A.10.3 is enforcement-strong. Describe the specific boundary, not a blanket "partial."
- Catalogue, not live per-control counts. The block states the role and evidence location per control; it does not (yet) show a per-control enforced-request count. Use the obligation rail and Request Logs for volumes.
Common questions¶
Does the "Operational" badge mean we're ISO 42001 compliant?
No. It means the control-plane-side evidence trail (request and audit logs) is live and being stored: the operational evidence an assessor relies on exists. Certification is your AI-management-system program; this is the evidence it draws on.
Why are only 9 controls listed? Where are the other 29?
The 29 are pure organisational / AIMS process: AI policy, risk assessment, human oversight, supplier contracts. The control plane plays no role in them, so claiming it does would be dishonest. They're deliberately left off rather than shown as "0% covered."
What's the difference between "Authoritative SoR" and "enables your evidence"?
Authoritative SoR means the auditor's evidence for that control's operational facet is the control plane's data: the control plane is the system of record. enables your evidence means the control plane supplies a runtime evidence slice you'd otherwise lack, but you still run the surrounding process. The second is a positive statement, not a weaker tier.
Can I download an ISO audit pack from here?
Not yet: that's the "Coming soon." Today, pull the underlying records from Request Logs, the Audit log, and Reports for your audit window and describe them as a manual extract, not an attested export.
The block isn't showing. Why?
It's Enterprise-only: on Community the whole Compliance Insights panel is a locked card. It also degrades to nothing if the evidence service is briefly unavailable; refresh, and check the deployment if it persists.
Where to go next¶
- Compliance & governance: the leading story this page is the proof half of: how the control plane enforces the obligations whose evidence these controls attest. Read this for the end-to-end arc.
- Compliance: the screen mechanics: obligation rail, VidaiGuard status, human/agent posture, rule tagging.
- Audit Log: the routing / provider / supplier configuration-change trail (the attestable half of A.6.2.5 / A.10.3).
- Request Logs: per-request evidence: principal, model, allow/deny, the rule that fired (A.6.2.8 / A.9.4).
- Reports: the aggregated operational-monitoring surface (A.6.2.6).
- Guardrails: the enforcement engine behind the incident-signal stream (A.8.4).
- Dashboard: the panel in the context of the whole dashboard.
- Licensing & tiers: why this is Enterprise, and what happens to the data on downgrade.