AI Audit & Assurance Readiness
Two tools for assuring an AI management system. Section A is an ISO 19011-style audit-program builder for an ISO/IEC 42001 AIMS: work through audit objectives, scope & criteria, auditor competence & independence, risk-based planning, evidence & workpapers, findings classification and reporting & follow-up, and get a banded 0–100 readiness score with the gaps ranked so you fix what matters most before a certification audit. Section B is a structured AI incident register whose fields are aligned to the serious-incident reporting duty in EU AI Act Article 73, exportable to CSV or Markdown. It is an educational self-assessment and template — not an audit, certification or legal advice — nothing is uploaded, and the state is shareable by permalink.
The audit programme is improvised. Without defined criteria, competent independent auditors and verifiable evidence, any "clean" result is not credible — a certification body would not recognise this as an audit. Fix scope/criteria and competence first.
Readiness per audit-programme area (0–100)
Prioritised gaps
Highest-weight, lowest-scoring items first — fix these before a certification audit.
- Audit objectives & programme · unanswered
Write audit-programme objectives that trace to the AI policy, the AI risk assessment and the AIMS objectives — not generic "pass the audit".
Reference: ISO 19011 Cl.5.2
- Audit objectives & programme · unanswered
Set a risk-based schedule: assign more frequent, deeper audits to higher-impact AI systems and name who owns each audit.
Reference: ISO 19011 Cl.5.3
- Scope & criteria · unanswered
State scope precisely — the AI systems, functions, locations and lifecycle stages covered, with documented exclusions and rationale.
Reference: ISO 19011 Cl.6.2
- Scope & criteria · unanswered
List the exact 42001 clauses and Annex A control objectives each audit activity tests, so conformity is assessable item by item.
Reference: ISO/IEC 42001 Annex A
- Auditor competence & independence · unanswered
Build or buy auditor competence that spans both management-system auditing and the AI lifecycle; a pure ISO auditor cannot evaluate a model-evaluation record.
Reference: ISO 19011 Cl.7
- Auditor competence & independence · unanswered
Assign auditors who are independent of the audited activity; separate the "do" from the "check" so findings are credible.
Reference: ISO 19011 Cl.4 (independence)
- Risk-based audit planning · unanswered
Produce a per-audit plan before fieldwork — objectives, scope, criteria, timing, who audits what — and agree it with the auditee.
Reference: ISO 19011 Cl.6.3.2
- Risk-based audit planning · unanswered
Allocate depth by risk: give high-impact AI systems larger samples and more rigorous evidence tests than low-risk ones.
Reference: ISO 19011 Cl.4 (risk-based)
+ 20 more gaps in the full export.
Audit objectives & programme · weight 16
ISO 19011 Clause 5: a managed audit programme with objectives tied to the AI policy and AIMS objectives, a risk-based frequency and method, named responsibilities and resources — not a one-off scramble before certification.
Audit-programme objectives are documented and aligned to the organisation's AI policy, AI risks and ISO/IEC 42001 management-system objectives.
The programme defines audit frequency, methods and responsibilities, and is risk-based (higher-risk AI systems are audited more often / in more depth).
Programme resources are identified — auditor time, tools, and access to AI systems, datasets, model documentation and third-party components.
The programme is monitored and improved — results feed management review and the next cycle, not filed and forgotten.
Scope & criteria · weight 16
ISO 19011 Cl.6.2: an audit is only as good as what it is measured against. Define which AI systems and lifecycle stages are in scope, and the exact criteria — which ISO/IEC 42001 clauses and Annex A control objectives, plus the organisation's own policies and applicable law.
Audit scope is explicit: which AI systems, processes, sites and lifecycle stages are in scope, and what is excluded and why.
Audit criteria name the specific ISO/IEC 42001 clauses (4–10) and Annex A control objectives being assessed, not just "the standard".
Criteria also include the organisation's own AI policies/procedures and applicable legal and regulatory requirements (e.g. EU AI Act obligations).
Scope covers third-party and vendor AI components and data pipelines, not only models built in-house.
Auditor competence & independence · weight 15
ISO 19011 Clause 7 plus the independence principle: auditors need general auditing competence AND AI-specific knowledge (ML lifecycle, data governance, AI risk and impact), and must be independent of the activity they audit.
Auditors hold generic management-system auditing competence together with AI-specific knowledge — ML lifecycle, data governance, model evaluation, AI risk and impact assessment.
Auditors are independent of the activity being audited — they do not audit their own work or a function they report into.
Auditor competence is evaluated and maintained over time (initial evaluation plus continuing development).
The team understands what an accredited certification-body auditor will expect — the impartiality and competence requirements that bodies certifying an AIMS work to.
Risk-based audit planning · weight 15
ISO 19011 Cl.6.3 and the risk-based-approach principle: each audit has a plan, and effort and sampling are concentrated where AI risk is highest. Risks to the audit itself (access, evidence availability, confidentiality) are considered too.
Each audit has a documented plan: objectives, scope, criteria, schedule, auditors, locations and the activities/areas to be sampled.
Sampling and audit effort are prioritised by AI risk and impact — high-risk / high-impact systems get deeper, more rigorous coverage.
Risks to the audit itself are considered — access to systems and data, availability and reliability of evidence, and confidentiality of training/personal data.
Logistics are arranged — opening and closing meetings, points of contact, and the method mix (interview, observation, document/record review).
Evidence & workpapers · weight 14
ISO 19011 Cl.6.4 and the evidence-based principle: conclusions rest on verifiable evidence, captured in workpapers that record the criterion, the evidence seen, its source and the auditor's conclusion — across the whole AI lifecycle.
Evidence is gathered by appropriate methods (interview, observation, document and record review) and is verifiable — traceable to a source, not assertion.
A workpaper or audit checklist captures, per criterion: the evidence examined, its source, and the auditor's conclusion (conform / not).
Evidence spans the AI lifecycle: data sourcing/quality, model development, evaluation and testing, deployment, monitoring and decommissioning.
Records are retained and their confidentiality is protected, especially personal or sensitive training data reviewed during the audit.
Findings classification · weight 12
Findings are classified consistently — conformity, opportunity for improvement, minor nonconformity, major nonconformity — against a specific criterion, stated factually, and agreed with the auditee before the closing meeting.
A defined classification scheme is used: conformity, opportunity for improvement (OFI), minor nonconformity, major nonconformity.
Major vs minor is defined and applied consistently — e.g. a major NC is an absent or systemically broken required control; a minor NC is an isolated lapse.
Every nonconformity is stated factually and tied to the specific criterion it breaches, with the supporting evidence referenced.
Findings are reviewed with the auditee for factual agreement before the closing meeting, so disputes are about facts, not surprises.
Reporting & follow-up · weight 12
ISO 19011 Cl.6.5–6.7: a written report with scope, criteria, findings and conclusions; nonconformities driving root-cause analysis and corrective action with owners and dates; and verified closure that feeds the next cycle.
A written audit report is produced and distributed, stating scope, criteria, findings and audit conclusions.
Nonconformities drive documented corrections, root-cause analysis and corrective actions with named owners and due dates.
Corrective-action effectiveness is verified and the nonconformity formally closed (follow-up audit or evidence review).
Audit results feed management review and the next audit-programme cycle, closing the loop.
Educational self-assessment and template, not an audit, a certification, or legal advice — and the incident register is not a substitute for the statutory serious-incident report. This tool names ISO/IEC 19011, ISO/IEC 42001, ISO/IEC 42006 and EU AI Act Article 73 for orientation only; it quotes no standard or legal text, performs no scan, and runs entirely in your browser — nothing is uploaded. Your answers and the register are stored only in the shareable link you choose to copy and in any file you export yourself.
What this tool is
- A free, 100% in-browser tool in two parts: an ISO 19011-style AUDIT-PROGRAM BUILDER for an AI management system (ISO/IEC 42001 AIMS), and a structured AI INCIDENT REGISTER.
- Section A scores your audit programme across seven weighted areas — objectives & programme, scope & criteria, auditor competence & independence, risk-based planning, evidence & workpapers, findings classification, and reporting & follow-up — to a banded 0–100 readiness score with prioritised gaps.
- Section B is a client-side incident log whose fields are aligned to the serious-incident reporting duty on providers of high-risk AI systems in EU AI Act Article 73: date, system, category, severity, description, affected parties, root cause, corrective action, reporting status and deadline — exportable to CSV or Markdown.
- It names ISO/IEC 19011, ISO/IEC 42001, ISO/IEC 42006 and EU AI Act Art. 73 for orientation only. ISO/IEC 42006 sets requirements for the bodies that CERTIFY an AIMS — i.e. what a certification auditor expects; this tool does not certify.
- Educational self-assessment & template, not an audit, certification, or legal advice — and the register is not a substitute for the statutory report. Nothing is uploaded; share the exact state by base64url permalink and export files yourself.
Auditing an AI management system, not just building one
Standing up an AI management system is one thing; being able to prove it works is another. ISO/IEC 19011 — the guidelines for auditing management systems — is the discipline that turns a pile of policies into defensible assurance: a managed audit programme, explicit criteria, competent and independent auditors, verifiable evidence captured in workpapers, consistently classified findings, and corrective action that is actually closed out. Section A applies that lifecycle to an ISO/IEC 42001 AI management system so an internal audit holds up — and so you can anticipate what an accredited certification auditor, working to the body-level requirements in ISO/IEC 42006, will expect. The weighting across the seven areas is a transparent heuristic, shown openly so you can adjust it to your own context.
Section B covers the other half of assurance: what happens when something goes wrong. The AI incident register is a structured, in-browser log with fields aligned to EU AI Act Article 73, which obliges providers of high-risk AI systems to report serious incidents — malfunctions, harm to health, safety or fundamental rights, data breaches, discriminatory outputs and security compromises — to the relevant market-surveillance authority within defined windows. The register helps you log, triage and track those incidents and their corrective actions. It is a template, not the statutory report, and nothing here is legal advice; assess each entry against the Article 73 definition and timelines, and file the real report where it is required.
Frequently asked questions
What does the AI Audit & Assurance Readiness tool do?
It has two parts. Section A is an ISO 19011-style audit-program builder for an AI management system (ISO/IEC 42001): you answer a weighted checklist across seven areas of the audit-programme lifecycle — objectives, scope and criteria, auditor competence and independence, risk-based planning, evidence and workpapers, findings classification, and reporting and follow-up — and get a banded 0–100 readiness score with prioritised gaps. Section B is a structured AI incident register: a client-side log whose fields are aligned to the serious-incident reporting duty in EU AI Act Article 73, exportable to CSV or Markdown.
Is this an audit, a certification, or legal advice?
No. It is an educational self-assessment and a set of templates for structured self-reflection. It does not audit anything, it cannot certify an AI management system, and it is not legal advice. The readiness score is a transparent heuristic, and the incident register is a template, not a substitute for the statutory serious-incident report to a market-surveillance authority. For a real audit or certification you need a competent, independent assessor or an accredited certification body; for legal obligations, qualified counsel.
Which standards does Section A draw on?
It is organised around ISO/IEC 19011 "Guidelines for auditing management systems" — the audit principles (including independence, evidence-based and risk-based approaches), managing an audit programme, conducting an audit, and auditor competence — applied to an ISO/IEC 42001 AI management system and its Annex A control objectives. It names ISO/IEC 42006, the requirements for bodies that audit and certify an AIMS, so you can anticipate what an accredited certification auditor will expect. It references these standards by name only and does not reproduce their text.
What is ISO/IEC 42006 and why is it mentioned?
ISO/IEC 42006 sets requirements for bodies providing audit and certification of AI management systems — the accreditation-level expectations an external certification body works to (impartiality, competence, and process). It is mentioned as context so your internal audit programme can anticipate what a certification auditor will look for. This tool is not a certification body and does not certify anything; naming 42006 is orientation, not a claim of conformity.
How does the AI incident register relate to the EU AI Act?
The register's fields are aligned to EU AI Act Article 73, which requires providers of high-risk AI systems to report serious incidents to the relevant market-surveillance authority. Article 73 sets outer reporting windows once a causal link (or its reasonable likelihood) is established: in general no later than 15 days after becoming aware, no later than 10 days where a person has died, and no later than 2 days for a widespread infringement or a serious and irreversible disruption of critical infrastructure; an initial incomplete report may be filed and completed later. The tool surfaces these windows as orientation. It is a template to help you log and triage incidents, not the statutory report itself and not legal advice.
Does it upload or store my data anywhere?
No. Everything runs in your browser. Your audit answers and the incident register are never uploaded — they live only in the base64url permalink you choose to copy (encoded in the URL) and in any CSV or Markdown file you export yourself. The tool performs no scan and makes no network calls with your data.
This tool is free and always will be. Would a Pro workspace — saved designs, team sharing and exports — be worth paying for?
Show me Pro →No account needed to use this tool — this just tells us whether Pro is worth building out.