{ "version": "public-demo-v1.0-reduced-risk-subset-airum-v3.2-67-eu-ai-act-final-validation-closeout", "status": "reduced-source-backed-risk-demo", "boundary": "Reduced public demo data. The visible risks use source-backed text from selected AIRUM risks shown in this repository, while the complete AIRUM data core and selection methodology are not published.", "riskUniverse": { "label": "AIRUM Part 1", "documentedCount": 10, "omittedRiskNote": "The complete AIRUM v3.2 risk universe contains 67 source-backed AI Risks, 75 consolidated controls, 212 risk-control mappings, EU AI Act source grounding, ISACA AI Audit Toolkit 2024 control-library grounding, and structured risk/control audit procedure planning guidance; this repository intentionally publishes only this reduced source-backed subset.", "applicableControlCount": 25, "riskControlMappingCount": 30 }, "risks": [ { "id": "demo-risk-01", "originalRiskId": "risk-ai-ambition-feasibility-mismatch", "family": "AI Strategy and Value Mgmt.", "processName": "1. AI Strategy & Value Mgmt.", "subProcessName": "Strategic Planning", "name": "AI Ambition-Feasibility Mismatch", "detailLevel": "full", "description": "Pursuing disruptive AI ambitions without the requisite technology maturity, data readiness, or organizational buy-in, leading to project failure.", "expectedControlName": "AI strategy feasibility and readiness review", "expectedControlDescription": "Require each material AI ambition, roadmap item, or major use case to document business objective, feasibility assumptions, data/process readiness, capability gaps, funding, accountable owner, and decision gate before investment approval. Include AI project-management discipline, leadership/resourcing review, requirements clarity, feasibility assumptions, and documented problem-space/adverse-outcome analysis before commitment.", "expectedControlObjective": "Confirm AI ambitions are achievable, resourced, and aligned to realistic organizational readiness before commitments are made.", "controlSourceBasis": "Source-grounded: derived from the row references (Gartner: AI Roadmap; Gartner: AI Strategy; ISO/IEC 42001 (Context of Org); NIST AI RMF: MAP 1.1, MAP 1.2). Control wording is an Internal Audit interpretation of the cited source families, not verbatim source text. Also informed by ISACA AAIA Review Manual, Chapter 03 Part A - Audit Planning and Design, especially Figure 3.1 common AI control types and Chapter 3.1 AI asset identification guidance.", "sourcesAndReferences": "Gartner: AI Roadmap; Gartner: AI Strategy; ISO/IEC 42001 (Context of Org); NIST AI RMF: MAP 1.1, MAP 1.2; ISACA AAIA Review Manual, Chapter 03 Part A - Audit Planning and Design", "urlSourcesRaw": "Gartner - AI Roadmap Toolkit (public) | https://www.gartner.com/en/chief-information-officer/research/ai-maturity-model-toolkit || \nGartner - AI Strategy Reference Guide | public URL not available in reduced demo || \nGartner - AI Strategy for Business (public) | https://www.gartner.com/en/articles/ai-strategy-for-business || \nGartner - The Pillars of a Successful Artificial Intelligence Strategy | public URL not available in reduced demo || \nGartner - Reference Guide for AI Strategy | public URL not available in reduced demo || \nISO/IEC 42001:2023 - Information technology \u2014 Artificial intelligence \u2014 Management syste (public) | https://www.iso.org/standard/42001 || \nNIST - AI Risk Management Framework (public) | https://www.nist.gov/itl/ai-risk-management-framework || \nISACA AAIA Review Manual, Chapter 03 Part A - Audit Planning and Design | public URL not available in reduced demo", "sourceLinks": [ { "label": "Gartner", "url": "" }, { "label": "ISO/IEC 42001:2023 - Information technology - Artificial intelligence - Management syste (public)", "url": "https://www.iso.org/standard/42001" }, { "label": "NIST - AI Risk Management Framework (public)", "url": "https://www.nist.gov/itl/ai-risk-management-framework" } ], "nistLifecycleStage": "1. Plan & Design", "lifecycle": [ "plan" ], "contexts": [ "governance", "strategy", "business-audit", "dedicated-ai" ], "posture": "Direct candidate", "auditProcedureName": "Review controls for AI Ambition-Feasibility Mismatch", "auditProcedureDescription": "Trace AI Ambition-Feasibility Mismatch from the stated risk scenario through the mapped controls. The procedure links the risk scenario to control design, population definition, operating evidence, exception handling, and residual coverage across AI strategy feasibility and readiness review, AI use-case value and feasibility prioritization, and AI risk classification and registration register. The risk scenario is Pursuing disruptive AI ambitions without the requisite technology maturity, data readiness, or organizational buy-in, leading to project failure.", "testOfDesign": "Overall test objective/purpose:\nDetermine whether the controls mapped to AI Ambition-Feasibility Mismatch are deliberately designed to address the risk scenario - Pursuing disruptive AI ambitions without the requisite technology maturity, data readiness, or organizational buy-in, leading to project failure. - with explicit control criteria, ownership, evidence, escalation, and coverage across AI strategy feasibility and readiness review, AI use-case value and feasibility prioritization, and AI risk classification and registration register.\n\nDetailed Test Steps:\n1. Map the risk scenario for AI Ambition-Feasibility Mismatch to the in-scope AI systems, use cases, models, vendors, workflows, decisions, data flows, and governance forums before judging control design.\n2. Inspect the design of each mapped control (AI strategy feasibility and readiness review, AI use-case value and feasibility prioritization, and AI risk classification and registration register) and confirm which part of the risk scenario it prevents, detects, or corrects.\n3. Inspect policy/procedure and approval templates requiring feasibility/readiness evidence before AI strategy/portfolio funding decisions, verify defined criteria, owners, decision rights, required fields, approval authority, exception path and evidence retention.\n4. Inspect whether the use-case prioritization method defines value dimensions, feasibility dimensions, weighting, scorer roles, challenge process, approval thresholds and evidence retention.\n5. Inspect inventory/register procedure and required fields to verify material AI ambitions/use cases have owner, purpose, classification and status fields sufficient to trigger readiness review.\n6. Inspect whether the AI register schema can serve as the population source for material AI initiatives and contains enough fields to identify initiative owner, intended use, status, and risk classification for alignment testing.\n7. Confirm the AI register requires use-case purpose/intended use, owner, impact, data sensitivity, status, and risk classification fields that can feed prioritization.\n8. Inspect how the classification register links to the broader AI inventory and whether required classification fields are part of the inventory schema.\n9. Inspect AI classification policy/procedure, criteria/rubric, risk tolerance thresholds, inventory/register data model, approval workflow, high-risk/prohibited-use/registration applicability logic, human oversight/system-limit documentation requirements, owner/RACI, exception handling, and evidence-retention requirements.\n10. Inspect whether the intake/approval design requires inventory registration and risk classification before material use.\n11. Check whether the combined design leaves any material part of AI Ambition-Feasibility Mismatch uncovered, including initiation, approval, deployment, monitoring, exception handling, remediation, and evidence retention points relevant to the risk.\n12. Walk through one representative AI system, use case, model change, approval, monitoring event, vendor dependency, or incident and trace how the mapped controls would operate together from trigger to retained evidence.\n13. Record design deficiencies such as missing thresholds, duplicated-but-unowned controls, unclear handoffs, unsupported expert judgment, bypass routes, absent evidence repositories, or controls that address adjacent risks but not AI Ambition-Feasibility Mismatch.\n\nRecommended Artifacts:\n- AI strategy document.\n- AI roadmap.\n- AI maturity/readiness assessment.\n- data readiness assessment.\n- use-case/business case template.\n- capability gap analysis.\n- funding approval.\n- portfolio/steering committee minutes.\n- decision-rights matrix.\n- risk assessment.\n- impact assessment.\n- approval workflow records.", "testOfEffectiveness": "Overall test objective/purpose:\nConfirm that the mapped controls for AI Ambition-Feasibility Mismatch operated over the review period on the actual population of relevant AI systems, use cases, models, vendors, events, approvals, or decisions, and that exceptions were resolved in line with the control design.\n\nRecommended Sampling Strategy:\nUse Material AI ambitions, roadmap initiatives, major AI use cases or investment proposals in the period as the primary population and Approved AI initiative/use case/roadmap item as the sample unit. Reconcile the population to the source system, register, workflow, ticket queue, monitoring output, or log extract. Stratify by system, business unit, model tier, lifecycle stage, vendor, region, or risk rating where operation differs. Add judgmental selections for high-risk, changed, exception, override, incident, failed-check, or near-threshold items. Use full-population analytics when the data is complete and the test criterion is deterministic.\n\nRecommended Sample Size:\nMinimum suggestion is the annual execution plus interim changes, exceptions, approvals, and triggering events relevant to the control. Annual controls do not have a fixed standard sample size in the matrix.\n\nDetailed Test Steps:\n1. Define the population for AI Ambition-Feasibility Mismatch, depending on scope, this may be AI initiatives, use cases, model releases, approvals, monitoring events, incidents, exceptions, third-party AI services, access events, data changes, or governance decisions.\n2. Reconcile the population to source systems, registers, workflow queues, approval repositories, monitoring outputs, or issue logs and document the extraction parameters, dates, filters, exclusions, and completeness checks.\n3. Sample material AI roadmap items/use cases approved in the period and test whether each had complete readiness documentation, required stakeholder reviews, unresolved gap disposition, funding/owner approval and retained decision evidence before approval.\n4. Sample candidate/approved use cases and test whether scoring was complete, supported by evidence, challenged where needed, and used in prioritization/funding decisions.\n5. Sample AI initiatives from multiple discovery sources and test whether they appear in the register with complete owner/purpose/classification data and appropriate readiness-gate routing., When testing the primary portfolio alignment control, reconcile sampled portfolio entries to the AI register and check whether material initiatives have owner/status/intended-use/risk-classification fields completed., For sampled use-case intake records, reconcile to the AI register and verify classification fields are complete and approved before portfolio decisions.\n6. Sample AI inventory entries and verify classification register linkage, approvals, status, and high-risk/registration indicators.\n7. Sample AI systems/use cases from intake, inventory, procurement, architecture/security review, model registry, and change records, verify classification was completed, criteria were applied consistently, risk tolerance/risk level was documented, high-risk/registration indicators were assessed, responsible approval occurred, exceptions were escalated, and classification was updated after material changes.\n8. Sample approved AI intake/procurement/use records and verify corresponding inventory entry, classification, owner, status, and routing/approval evidence.\n9. Sample AI systems/features to verify cyber/misuse risk classification and routing to specialist review/restriction/monitoring controls.\n10. Sample high-risk/classified systems and verify register entries are accurate, current, and link to technical documentation and required authority/public database evidence where applicable.\n11. For each selected item, test the applicable mapped controls (AI strategy feasibility and readiness review, AI use-case value and feasibility prioritization, and AI risk classification and registration register) for evidence of performance, performer/reviewer authority, timeliness, completeness, accuracy, and direct linkage to the sampled AI system, use case, model, vendor, event, or decision.\n12. Trace exceptions, failed checks, overrides, incidents, unresolved actions, and risk acceptances to escalation, remediation, retesting, approval, closure, or compensating-control evidence.\n13. Conclude whether the operating evidence supports reliance on the control set for AI Ambition-Feasibility Mismatch, document exceptions, root-cause themes, coverage gaps, and any additional substantive or compliance testing needed.\n\nRecommended Artifacts:\n- AI strategy document.\n- AI roadmap.\n- AI maturity/readiness assessment.\n- data readiness assessment.\n- use-case/business case template.\n- capability gap analysis.\n- funding approval.\n- portfolio/steering committee minutes.\n- decision-rights matrix.\n- risk assessment.\n- impact assessment.\n- approval workflow records.", "applicableControlIds": [ "ctl-ai-strategy-feasibility-readiness-review", "ctl-ai-use-case-value-feasibility-prioritization", "ctl-ai-risk-classification-register" ] }, { "id": "demo-risk-02", "originalRiskId": "risk-lack-of-clear-accountability", "family": "AI Organization and Culture", "processName": "2. AI Organization & Culture", "subProcessName": "Roles & Responsibilities", "name": "Lack of Clear Accountability", "detailLevel": "full", "description": "Roles for AI development, oversight, and \"human-in-the-loop\" decision rights are not clearly defined, leading to responsibility gaps.", "expectedControlName": "AI accountability and RACI control", "expectedControlDescription": "Assign documented business, technical, risk, data, model, vendor, and control owners for each material AI system, including decision rights and escalation paths. Include executive-level AI accountability, accountable function or committee delegation, documented RACI/decision rights, and escalation/reporting responsibilities for AI oversight.", "expectedControlObjective": "Make AI ownership, decision accountability, and control responsibility explicit and testable.", "controlSourceBasis": "Source-grounded: derived from the row references (Gartner: AI Organization; MITRE: Org Structure; ISO/IEC 42001 (Roles A.3.2); NIST AI RMF: GOVERN 2.1, GOVERN 2.3). Control wording is an Internal Audit interpretation of the cited source families, not verbatim source text. Also informed by ISACA AAIA Review Manual, Chapter 03 Part A - Audit Planning and Design, especially Figure 3.1 common AI control types and Chapter 3.1 AI asset identification guidance.", "sourcesAndReferences": "Gartner: AI Organization; MITRE: Org Structure; ISO/IEC 42001 (Roles A.3.2); NIST AI RMF: GOVERN 2.1, GOVERN 2.3; ISACA AAIA Review Manual, Chapter 03 Part A - Audit Planning and Design", "urlSourcesRaw": "Gartner: AI Organization | https://www.gartner.com/en/documents/6570102 || \nMITRE: Org Structure | https://www.mitre.org/news-insights/publication/mitre-ai-maturity-model-and-organizational-assessment-tool-guide || \nISO/IEC 42001 (Roles A.3.2) | https://www.iso.org/standard/42001 || \nNIST AI RMF: GOVERN 2.1, GOVERN 2.3 | https://www.nist.gov/itl/ai-risk-management-framework || \nISACA AAIA Review Manual, Chapter 03 Part A - Audit Planning and Design | public URL not available in reduced demo", "sourceLinks": [ { "label": "Gartner", "url": "" }, { "label": "MITRE: Org Structure", "url": "https://www.mitre.org/news-insights/publication/mitre-ai-maturity-model-and-organizational-assessment-tool-guide" }, { "label": "ISO/IEC 42001 (Roles A.3.2)", "url": "https://www.iso.org/standard/42001" }, { "label": "NIST AI RMF: GOVERN 2.1, GOVERN 2.3", "url": "https://www.nist.gov/itl/ai-risk-management-framework" } ], "nistLifecycleStage": "1. Plan & Design", "lifecycle": [ "plan" ], "contexts": [ "governance", "business-audit", "dedicated-ai" ], "posture": "Direct candidate", "auditProcedureName": "Analyze AI accountability, RACI, and decision-rights control", "auditProcedureDescription": "Trace the control for AI accountability, RACI, and decision-rights control from the event, decision, or cadence that triggers it through execution, review, exception handling, and retained evidence. Use the control objective as the reference point. Make AI ownership, decision accountability, and control responsibility explicit, communicated, and testable for material AI systems. Confirm that the described control activity is performed through clear criteria, accountable ownership, defined timing, complete population coverage, reliable source records, and evidence that exceptions are escalated and resolved. Where the control relies on automated monitoring, workflow approval, or manual expert review, verify that handoffs and evidence repositories are clear enough for repeatable audit testing. The work should cover the activity defined for the control. Define, approve, communicate, and maintain accountable owners, responsible parties, consulted/informed stakeholders, escalation paths, and decision rights for material AI systems across business decisions, technical/model operation, AI risk management, data quality, human oversight, vendor management, control execution, monitoring, and issue remediation.", "testOfDesign": "Overall test objective/purpose:\nDetermine whether AI accountability, RACI, and decision-rights control is designed with criteria, ownership, timing, evidence, and exception handling precise enough to achieve the objective. Make AI ownership, decision accountability, and control responsibility explicit, communicated, and testable for material AI systems.\n\nDetailed Test Steps:\n1. Inspect the AI governance charter/operating model, RACI/decision-rights matrix, role descriptions, AI inventory owner fields, committee/function delegation, escalation paths, and policy/procedure language to verify coverage of material AI lifecycle domains and.\n2. Inspect the AI governance charter/operating model, RACI/decision-rights matrix, role descriptions, AI inventory owner fields, committee/function delegation, escalation paths, and policy/procedure language to verify that AI risk-management responsibilities, lifecycle owner roles, communication lines, executive accountability, decision authority, and escalation/reporting paths are assigned and communicated for material AI systems.\n3. Inspect the documented AI accountability, RACI, and decision-rights control policy, standard, workflow, configuration, checklist, approval template, or procedure and trace each required element to the stated control objective.\n4. Confirm that the AI accountability, RACI, and decision-rights control design names the accountable owner (AI governance lead or accountable executive/committee, with business system owner, technology/model owner, data owner, risk/compliance owner, vendor owner, and control owner participation.) and expected performance cadence (At AI system intake/approval and material lifecycle changes, periodic governance review at least annually or per AI policy cadence. Exact frequency not source-stated, mark as organization-defined if implemented.), including reviewer, delegate, and escalation responsibilities where applicable.\n5. Check that the design defines the in-scope population (Material AI systems/use cases in scope of the AI management system or AI governance framework.), sampling unit (AI system/use case, approval decision, governance committee item, escalation/issue record, or owner-field record in the AI inventory.), and process/system boundary (governance-and-accountability process boundary) so testing can be repeated by another auditor.\n6. Walk through one representative control occurrence, AI lifecycle event, approval, change, exception, or monitoring record covered by AI accountability, RACI, and decision-rights control. Trace it from trigger through decision, escalation, and evidence retention and identify where the control prevents, detects, or corrects the targeted risk.\n7. Challenge whether bypasses, undocumented judgment, missing thresholds, unclear reviewer authority, weak segregation, or absent retention rules could prevent AI accountability, RACI, and decision-rights control from operating consistently.\n\nRecommended Artifacts:\n- AI governance charter / operating model.\n- AI policy and standards.\n- RACI / decision-rights matrix.\n- AI system/use-case inventory with owner fields.\n- role descriptions / org chart / directory.\n- AI governance board or committee terms of reference and minutes.\n- approval workflows and sign-offs.\n- escalation/issue tickets.\n- risk assessment records with owners.\n- AI impact assessment ownership.", "testOfEffectiveness": "Overall test objective/purpose:\nConfirm that AI accountability, RACI, and decision-rights control operated during the review period in line with its documented criteria, ownership, frequency, evidence requirements, and exception path.\n\nRecommended Sampling Strategy:\nUse Material AI systems/use cases in scope of the AI management system or AI governance framework. as the primary population and AI system/use case, approval decision, governance committee item, escalation/issue record, or owner-field record in the AI inventory. as the sample unit. Reconcile the population to the source system, register, workflow, ticket queue, monitoring output, or log extract. Stratify by system, business unit, model tier, lifecycle stage, vendor, region, or risk rating where operation differs. Add judgmental selections for high-risk, changed, exception, override, incident, failed-check, or near-threshold items. Use full-population analytics when the data is complete and the test criterion is deterministic.\n\nRecommended Sample Size:\nMinimum suggestion is the annual execution plus interim changes, exceptions, approvals, and triggering events relevant to the control. Annual controls do not have a fixed standard sample size in the matrix.\n\nDetailed Test Steps:\n1. Build the population for AI accountability, RACI, and decision-rights control from the system, workflow, register, log, or approval repository that records control execution. Document extraction parameters, date range, filters, and completeness reconciliation.\n2. Verify the control design or operating evidence addresses the requirement in practical terms, For a sample of material AI systems/use cases, verify that named accountable owners and responsible parties exist, decision rights are documented and used in approvals, governance/escalation records show accountable review, owner fields are maintained in inventories or workflow tools, exceptions/issues are routed to defined owners, and evidence exists for business/model/data/vendor/control/human-oversight responsibilities.\n3. For each selected item, verify the control was performed by the expected owner or reviewer, at the required point in the process, against the defined criteria, and before the AI decision, release, approval, use, or event proceeded where the design requires prior control execution.\n4. Compare retained evidence to the control design and confirm completeness, accuracy, reviewer sign-off, timestamps, linkage to the AI system/use case/model/vendor/event, and consistency with the required cadence.\n5. Trace exceptions, overrides, failed checks, late reviews, unresolved actions, and risk acceptances to escalation, remediation, approval, retesting, or closure evidence.\n\nRecommended Artifacts:\n- AI governance charter / operating model.\n- AI policy and standards.\n- RACI / decision-rights matrix.\n- AI system/use-case inventory with owner fields.\n- role descriptions / org chart / directory.\n- AI governance board or committee terms of reference and minutes.\n- approval workflows and sign-offs.\n- escalation/issue tickets.\n- risk assessment records with owners.\n- AI impact assessment ownership.", "applicableControlIds": [ "ctl-ai-accountability-raci-decision-rights" ] }, { "id": "demo-risk-03", "originalRiskId": "risk-missing-ai-inventory", "family": "AI Governance and Risk", "processName": "3. AI Governance & Risk", "subProcessName": "Policy & Framework", "name": "Missing AI Inventory", "detailLevel": "full", "description": "Failure to maintain a complete, current inventory of AI systems, models, use cases, automations, and owners prevents risk classification, oversight, monitoring, and compliance.", "expectedControlName": "AI system inventory control", "expectedControlDescription": "Maintain a complete and periodically reconciled AI inventory capturing owner, purpose, process, data, vendor, classification, lifecycle stage, and control status for material AI use. Include minimum inventory fields such as AIS name, version, license, cost, deployment, purpose, frequency of use, stakeholders, accountable owner, vendor details, model/catalog linkage, and annual refresh supported by structured surveys/interviews and technical discovery evidence.", "expectedControlObjective": "Ensure AI use is visible, owned, classified, and available for risk management and audit scoping.", "controlSourceBasis": "Source-grounded: derived from the row references (Gartner: AI Governance model inventory/usage review; ISACA AAIA Ch.03 AI asset identification and inventory procedures; NIST AI RMF Playbook GOVERN 1.6, MAP 2.1, MANAGE 1.1; ISO/IEC 42001 A.4.2-A.4.6; ISO/IEC 5338 lifecycle/portfolio/stakeholder support). Control wording is an Internal Audit synthesis, not verbatim source text. ISO/IEC 5338 support is indirect lifecycle/resource/stakeholder context.", "sourcesAndReferences": "Gartner: AI Governance (model inventory / AI usage review); ISACA AAIA Review Manual, Chapter 03 Part A - Audit Planning and Design; NIST AI RMF Playbook: GOVERN 1.6, MAP 2.1, MANAGE 1.1; ISO/IEC 42001 (Resources A.4.2-A.4.6); ISO/IEC 5338", "urlSourcesRaw": "Gartner: AI Governance (model inventory / AI usage review) | public URL not available in reduced demo || \nISACA AAIA Review Manual, Chapter 03 Part A - Audit Planning and Design | public URL not available in reduced demo || \nNIST AI RMF Playbook: GOVERN 1.6, MAP 2.1, MANAGE 1.1 | https://airc.nist.gov/airmf-resources/playbook/ || \nISO/IEC 42001 (Resources A.4.2-A.4.6) | https://www.iso.org/standard/42001 || \nISO/IEC 5338 | https://www.iso.org/standard/81118.html", "sourceLinks": [ { "label": "Gartner", "url": "" }, { "label": "ISO/IEC 5338", "url": "https://www.iso.org/standard/81118.html" }, { "label": "ISO/IEC 42001 (Resources A.4.2)", "url": "https://www.iso.org/standard/42001" }, { "label": "NIST AI RMF: MAP 2.1, MANAGE 1.1", "url": "https://www.nist.gov/itl/ai-risk-management-framework" } ], "nistLifecycleStage": "1. Plan & Design", "lifecycle": [ "plan" ], "contexts": [ "governance", "third-party", "business-audit", "dedicated-ai" ], "posture": "Baseline governance", "auditProcedureName": "Evaluate controls for Missing AI Inventory", "auditProcedureDescription": "Review how the mapped controls address Missing AI Inventory. Follow the risk scenario into the relevant AI systems, use cases, models, vendors, workflows, decisions, monitoring events, and governance records, then test the control focus represented by AI system inventory and reconciliation control and AI risk classification and registration register. The risk scenario is Failure to maintain a complete, current inventory of AI systems, models, use cases, automations, and owners prevents risk classification, oversight, monitoring, and compliance.", "testOfDesign": "Overall test objective/purpose:\nDetermine whether the controls mapped to Missing AI Inventory are deliberately designed to address the risk scenario - Failure to maintain a complete, current inventory of AI systems, models, use cases, automations, and owners prevents risk classification, oversight, monitoring, and compliance. - with explicit control criteria, ownership, evidence, escalation, and coverage across AI system inventory and reconciliation control and AI risk classification and registration register.\n\nDetailed Test Steps:\n1. Map the risk scenario for Missing AI Inventory to the in-scope AI systems, use cases, models, vendors, workflows, decisions, data flows, and governance forums before judging control design.\n2. Inspect the design of each mapped control (AI system inventory and reconciliation control and AI risk classification and registration register) and confirm which part of the risk scenario it prevents, detects, or corrects.\n3. Inspect the AI inventory standard/procedure, data dictionary, governance ownership, refresh cadence, reconciliation sources, discovery methods, non-punitive survey/interview approach, classification linkage, and exception escalation design.\n4. Inspect inventory policy/standard, field dictionary, accountable owner/stewardship model, refresh cadence, intake/procurement/architecture/release reconciliation design, discovery methods, non-punitive communication, classification linkage, lifecycle/status fields, and evidence-retention requirements.\n5. Inspect whether the AI inventory/register schema links each inventory entry to risk classification, registration or high-risk applicability, owner/accountability, intended use, status, approval route, and evidence-retention requirements. Confirm the classification procedure defines criteria, refresh triggers, exception handling, and linkage back to the inventory population rather than operating as a separate unowned register.\n6. Check whether the combined design leaves any material part of Missing AI Inventory uncovered, including initiation, approval, deployment, monitoring, exception handling, remediation, and evidence retention points relevant to the risk.\n7. Walk through one representative AI system, use case, model change, approval, monitoring event, vendor dependency, or incident and trace how the mapped controls would operate together from trigger to retained evidence.\n8. Record design deficiencies such as missing thresholds, duplicated-but-unowned controls, unclear handoffs, unsupported expert judgment, bypass routes, absent evidence repositories, or controls that address adjacent risks but not Missing AI Inventory.\n\nRecommended Artifacts:\n- AI inventory/catalog/register export.\n- inventory data dictionary / minimum field list.\n- AI inventory policy/procedure.\n- AI governance committee or owner mandate.\n- AI intake and approval tickets.\n- procurement/vendor AI records.\n- architecture/security/cloud review records.\n- model registry/model cards.\n- system diagrams/dataflow diagrams.\n- tool usage / DLP / CASB / network discovery reports.\n- survey and interview instruments/responses.\n- annual refresh attestations.", "testOfEffectiveness": "Overall test objective/purpose:\nConfirm that the mapped controls for Missing AI Inventory operated over the review period on the actual population of relevant AI systems, use cases, models, vendors, events, approvals, or decisions, and that exceptions were resolved in line with the control design.\n\nRecommended Sampling Strategy:\nUse All known and discoverable AI systems, models, use cases, automations, embedded vendor AI features, third-party AI services, and material AI-enabled business processes within the defined risk universe scope. as the primary population and AI inventory entry / AI system / model-use-case pairing / vendor AI feature / newly discovered AI use item. as the sample unit. Reconcile the population to the source system, register, workflow, ticket queue, monitoring output, or log extract. Stratify by system, business unit, model tier, lifecycle stage, vendor, region, or risk rating where operation differs. Add judgmental selections for high-risk, changed, exception, override, incident, failed-check, or near-threshold items. Use full-population analytics when the data is complete and the test criterion is deterministic.\n\nRecommended Sample Size:\nMinimum suggestion is the annual execution plus interim changes, exceptions, approvals, and triggering events relevant to the control. Annual controls do not have a fixed standard sample size in the matrix.\n\nDetailed Test Steps:\n1. Define the population for Missing AI Inventory, depending on scope, this may be AI initiatives, use cases, model releases, approvals, monitoring events, incidents, exceptions, third-party AI services, access events, data changes, or governance decisions.\n2. Reconcile the population to source systems, registers, workflow queues, approval repositories, monitoring outputs, or issue logs and document the extraction parameters, dates, filters, exclusions, and completeness checks.\n3. Reconcile inventory entries to AI intake, procurement/vendor, architecture/security review, model registry, cloud/tool usage, release/project, survey/interview, and technical discovery populations, sample entries and newly discovered AI uses to verify required fields, ownership, classification, lifecycle/status, vendor/resource linkages, timely refresh, approval/control status, and exception escalation.\n4. Verify the control design or operating evidence addresses the requirement in practical terms, For the audit period, reconcile the AI inventory population to source populations such as AI intake tickets, procurement/vendor records, architecture review records, cloud/tool usage logs, model registries, project/release records, surveys/interviews, and technical discovery outputs, sample AI inventory entries to verify required fields, owner approval, classification, lifecycle stage, vendor/resource linkages, refresh evidence, and exception escalation, sample newly discovered/shadow AI items for timely registration and governance routing.\n5. Verify the control design or operating evidence addresses the requirement in practical terms, For the audit period, sample AI inventory entries and newly discovered AI uses to verify classification status, approval, owner, intended use, risk tier/registration indicators, and update history are complete, current, and consistent with the inventory. Trace missing, stale, or changed classifications to escalation, remediation, or risk acceptance evidence.\n6. For each selected item, test the applicable mapped controls (AI system inventory and reconciliation control and AI risk classification and registration register) for evidence of performance, performer/reviewer authority, timeliness, completeness, accuracy, and direct linkage to the sampled AI system, use case, model, vendor, event, or decision.\n7. Trace exceptions, failed checks, overrides, incidents, unresolved actions, and risk acceptances to escalation, remediation, retesting, approval, closure, or compensating-control evidence.\n8. Conclude whether the operating evidence supports reliance on the control set for Missing AI Inventory, document exceptions, root-cause themes, coverage gaps, and any additional substantive or compliance testing needed.\n\nRecommended Artifacts:\n- AI inventory/catalog/register export.\n- inventory data dictionary / minimum field list.\n- AI inventory policy/procedure.\n- AI governance committee or owner mandate.\n- AI intake and approval tickets.\n- procurement/vendor AI records.\n- architecture/security/cloud review records.\n- model registry/model cards.\n- system diagrams/dataflow diagrams.\n- tool usage / DLP / CASB / network discovery reports.\n- survey and interview instruments/responses.\n- annual refresh attestations.", "applicableControlIds": [ "ctl-ai-system-inventory-and-reconciliation", "ctl-ai-risk-classification-register" ] }, { "id": "demo-risk-04", "originalRiskId": "risk-sensitive-data-disclosure-and-inference", "family": "AI Data Management", "processName": "4. AI Data Management", "subProcessName": "Privacy & Security", "name": "Sensitive Data Disclosure & Inference", "detailLevel": "full", "description": "Exposure of PII/IP via Model Inversion, Membership Inference, or memorization of sensitive training data.", "expectedControlName": "Sensitive-data protection for AI control", "expectedControlDescription": "Apply data minimization, access control, masking, prompt/output safeguards, inference-risk review, logging, and privacy/security testing for AI systems handling sensitive or confidential data. Include privacy/DPIA trigger assessment, MFA, privileged and third-party access review, access certification/recertification, encryption/de-identification, retention, and AI data-use restrictions.", "expectedControlObjective": "Prevent unauthorized disclosure, leakage, or inference of sensitive information through AI systems.", "controlSourceBasis": "Source-grounded: derived from the row references (OWASP LLM Top 10: LLM06; OWASP ML Top 10: ML03, ML04; ISO/IEC 42001 (Privacy B.7.2); NIST AI RMF: MEASURE 2.7, MANAGE 2.4). Control wording is an Internal Audit interpretation of the cited source families, not verbatim source text. Also informed by ISACA AAIA Review Manual, Chapter 03 Part A - Audit Planning and Design, especially Figure 3.1 common AI control types and Chapter 3.1 AI asset identification guidance.", "sourcesAndReferences": "OWASP LLM Top 10: LLM06; OWASP ML Top 10: ML03, ML04; ISO/IEC 42001 (Privacy B.7.2); NIST AI RMF: MEASURE 2.7, MANAGE 2.4; ISACA AAIA Review Manual, Chapter 03 Part A - Audit Planning and Design", "urlSourcesRaw": "OWASP LLM Top 10: LLM06 | https://genai.owasp.org/llm-top-10/ || \nOWASP ML Top 10: ML03, ML04 | https://owasp.org/www-project-machine-learning-security-top-10/ || \nISO/IEC 42001 (Privacy B.7.2) | https://www.iso.org/standard/42001 || \nNIST AI RMF: MEASURE 2.7, MANAGE 2.4 | https://www.nist.gov/itl/ai-risk-management-framework || \nISACA AAIA Review Manual, Chapter 03 Part A - Audit Planning and Design | public URL not available in reduced demo", "sourceLinks": [ { "label": "OWASP LLM Top 10: LLM06", "url": "https://genai.owasp.org/llm-top-10/" }, { "label": "OWASP ML Top 10: ML03, ML04", "url": "https://owasp.org/www-project-machine-learning-security-top-10/" }, { "label": "ISO/IEC 42001 (Privacy B.7.2)", "url": "https://www.iso.org/standard/42001" }, { "label": "NIST AI RMF: MEASURE 2.7, MANAGE 2.4", "url": "https://www.nist.gov/itl/ai-risk-management-framework" } ], "nistLifecycleStage": "2. Collect & Process Data", "lifecycle": [ "data" ], "contexts": [ "data", "privacy", "security", "business-audit", "dedicated-ai" ], "posture": "Specialist overlay", "auditProcedureName": "Analyze controls for Sensitive Data Disclosure & Inference", "auditProcedureDescription": "Analyze whether Sensitive Data Disclosure & Inference is covered by a complete and auditable control pathway. The procedure compares the risk scenario with mapped control ownership, timing, evidence, monitoring, and exception resolution across AI sensitive-data protection and disclosure prevention, AI inference-attack and memorization privacy testing, and AI impact assessment and conformity trigger control. The risk scenario is Exposure of PII/IP via Model Inversion, Membership Inference, or memorization of sensitive training data.", "testOfDesign": "Overall test objective/purpose:\nDetermine whether the controls mapped to Sensitive Data Disclosure & Inference are deliberately designed to address the risk scenario - Exposure of PII/IP via Model Inversion, Membership Inference, or memorization of sensitive training data. - with explicit control criteria, ownership, evidence, escalation, and coverage across AI sensitive-data protection and disclosure prevention, AI inference-attack and memorization privacy testing, and AI impact assessment and conformity trigger control.\n\nDetailed Test Steps:\n1. Map the risk scenario for Sensitive Data Disclosure & Inference to the in-scope AI systems, use cases, models, vendors, workflows, decisions, data flows, and governance forums before judging control design.\n2. Inspect the design of each mapped control (AI sensitive-data protection and disclosure prevention, AI inference-attack and memorization privacy testing, and AI impact assessment and conformity trigger control) and confirm which part of the risk scenario it prevents, detects, or corrects.\n3. Inspect AI data-use policy/procedure, risk classification criteria, data classification mapping, allowed/prohibited data categories, minimization and masking/tokenization design, access-control model, output/prompt safeguard design, retention/deletion rules, exception/escalation path, and linkage to sensitive-data sources and AI system inventory.\n4. Inspect whether the control design defines risk-based triggers for model inversion, membership inference, memorization, and training-data leakage testing, required methods/tools, responsible specialists, thresholds/tolerances, remediation or risk acceptance workflow, and re-test triggers after data/model/prompt/retrieval changes.\n5. Inspect trigger criteria for sensitive data, PII, confidential/IP data, public-facing AI outputs, new technologies, automated decisioning, material data/model/prompt/retrieval changes, and elevated inference risk, verify privacy, legal/compliance, security, model-risk/validation, and data-owner routing, required approvals, documented applicability decisions, evidence retention, and linkage to AI inventory/classification records.\n6. Inspect whether impact/conformity trigger criteria explicitly apply to accelerated releases, material changes, and high-pressure deployments.\n7. Inspect trigger matrix/procedure, definitions of material/significant change, privacy/fundamental-rights/conformity applicability criteria, specialist routing rules, approval gates, evidence-retention requirements, and linkage to AI inventory/classification records.\n8. Inspect trigger logic for sensitive data, PII, new technologies, public-facing AI outputs, model/data/retrieval changes, and elevated inference risk, verify ownership, required approvers, documentation, and links to the AI inventory.\n9. Inspect trigger matrix/applicability rules for societal-impact assessment triggers and linkage to change/deployment approval.\n10. Inspect whether the impact-assessment trigger matrix explicitly includes environmental/resource-impact triggers and material AI lifecycle changes.\n11. Check whether the combined design leaves any material part of Sensitive Data Disclosure & Inference uncovered, including initiation, approval, deployment, monitoring, exception handling, remediation, and evidence retention points relevant to the risk.\n12. Walk through one representative AI system, use case, model change, approval, monitoring event, vendor dependency, or incident and trace how the mapped controls would operate together from trigger to retained evidence.\n13. Record design deficiencies such as missing thresholds, duplicated-but-unowned controls, unclear handoffs, unsupported expert judgment, bypass routes, absent evidence repositories, or controls that address adjacent risks but not Sensitive Data Disclosure & Inference.\n\nRecommended Artifacts:\n- AI system and data inventory.\n- data classification register.\n- data-use approvals.\n- DPIA/privacy review records where applicable.\n- access matrices and recertifications.\n- DLP/masking/tokenization/redaction rules.\n- prompt/output guardrail configuration.\n- retention/deletion schedule.\n- AI logs and monitoring outputs.\n- exception and incident tickets.\n- training/user guidance records.\n- privacy/security test plan.", "testOfEffectiveness": "Overall test objective/purpose:\nConfirm that the mapped controls for Sensitive Data Disclosure & Inference operated over the review period on the actual population of relevant AI systems, use cases, models, vendors, events, approvals, or decisions, and that exceptions were resolved in line with the control design.\n\nRecommended Sampling Strategy:\nUse AI systems and datasets that process, retrieve, train on, store, log, or output sensitive/confidential/personal data. as the primary population and AI system, dataset/source, access entitlement, prompt/output/log sample, exception ticket, DPIA/privacy review record. as the sample unit. Reconcile the population to the source system, register, workflow, ticket queue, monitoring output, or log extract. Stratify by system, business unit, model tier, lifecycle stage, vendor, region, or risk rating where operation differs. Add judgmental selections for high-risk, changed, exception, override, incident, failed-check, or near-threshold items. Use full-population analytics when the data is complete and the test criterion is deterministic.\n\nRecommended Sample Size:\nMinimum suggestion is 20 daily-or-more-frequent executions, alerts, log entries, or monitoring records after population completeness and control frequency are confirmed. Use full-population analytics where criteria are deterministic.\n\nDetailed Test Steps:\n1. Define the population for Sensitive Data Disclosure & Inference, depending on scope, this may be AI initiatives, use cases, model releases, approvals, monitoring events, incidents, exceptions, third-party AI services, access events, data changes, or governance decisions.\n2. Reconcile the population to source systems, registers, workflow queues, approval repositories, monitoring outputs, or issue logs and document the extraction parameters, dates, filters, exclusions, and completeness checks.\n3. Sample AI systems/datasets/prompts/retrieval sources/logs and verify sensitive data was classified, approved for use, minimized or masked, access was authorized and recertified, outputs/logs did not retain unapproved sensitive data, exceptions were approved, and remediation occurred for violations.\n4. Sample high-sensitivity AI systems or model releases and verify privacy attack testing occurred, results were reviewed, residual risk was accepted or remediated, anomaly monitoring operated, and repeated/high-risk queries or leakage findings triggered escalation.\n5. Sample AI deployments or material changes involving sensitive/personal/confidential data, public-facing outputs, new technologies, automated decisioning, or elevated inference risk and verify DPIA/privacy-impact, impact/conformity, legal/compliance, security, and specialist review trigger decisions occurred before approval or go-live, or that non-applicability decisions were documented and approved.\n6. Sample accelerated or competitive-pressure AI releases and test whether impact/conformity trigger determinations and required assessments occurred before approval or go-live.\n7. Sample AI deployments and material changes, verify trigger assessment was completed, specialist reviews occurred when criteria were met, FRIA/DPIA/conformity/registration decisions were documented, approvals preceded deployment/change, and exceptions or missed triggers were escalated/remediated.\n8. Sample AI systems or material changes involving sensitive data and verify DPIA/privacy review or impact assessment was completed before deployment/change approval and exceptions were documented.\n9. Sample material AI deployments/changes and verify trigger decisions and required societal assessments occurred before approval.\n10. Sample material AI deployments/changes and verify the trigger was applied and sustainability assessment or approval evidence exists.\n11. For each selected item, test the applicable mapped controls (AI sensitive-data protection and disclosure prevention, AI inference-attack and memorization privacy testing, and AI impact assessment and conformity trigger control) for evidence of performance, performer/reviewer authority, timeliness, completeness, accuracy, and direct linkage to the sampled AI system, use case, model, vendor, event, or decision.\n12. Trace exceptions, failed checks, overrides, incidents, unresolved actions, and risk acceptances to escalation, remediation, retesting, approval, closure, or compensating-control evidence.\n13. Conclude whether the operating evidence supports reliance on the control set for Sensitive Data Disclosure & Inference, document exceptions, root-cause themes, coverage gaps, and any additional substantive or compliance testing needed.\n\nRecommended Artifacts:\n- AI system and data inventory.\n- data classification register.\n- data-use approvals.\n- DPIA/privacy review records where applicable.\n- access matrices and recertifications.\n- DLP/masking/tokenization/redaction rules.\n- prompt/output guardrail configuration.\n- retention/deletion schedule.\n- AI logs and monitoring outputs.\n- exception and incident tickets.\n- training/user guidance records.\n- privacy/security test plan.", "applicableControlIds": [ "ctl-ai-sensitive-data-protection", "ctl-ai-inference-attack-privacy-testing", "ctl-ai-impact-conformity-trigger" ] }, { "id": "demo-risk-05", "originalRiskId": "risk-inadequate-verification-and-validation", "family": "AI Engineering and Lifecycle", "processName": "5. AI Engineering & Lifecycle", "subProcessName": "Development & Deployment", "name": "Inadequate Verification & Validation", "detailLevel": "full", "description": "Failure to rigorously test AI models for accuracy, robustness, bias, and security prior to deployment, leading to performance failures.", "expectedControlName": "AI verification and validation control", "expectedControlDescription": "Define and execute independent validation before release, including acceptance criteria, test data, performance, robustness, bias, security, limitations, and approval evidence. Include design-phase requirements, model-type documentation, data fitness/representativeness checks, acceptance criteria, end-to-end/scenario/bias/fairness testing protocols, and validation evidence.", "expectedControlObjective": "Confirm AI systems meet intended requirements and risk tolerances before operational reliance.", "controlSourceBasis": "Source-grounded: derived from the row references (ISO/IEC 5338 (Verification); ISO/IEC 42001 (Control A.6.2.4); MITRE: Test & Evaluation; NIST AI RMF: MEASURE 1.1, MEASURE 2.6). Control wording is an Internal Audit interpretation of the cited source families, not verbatim source text. Also informed by ISACA AAIA Review Manual, Chapter 03 Part A - Audit Planning and Design, especially Figure 3.1 common AI control types and Chapter 3.1 AI asset identification guidance.", "sourcesAndReferences": "ISO/IEC 5338 (Verification); ISO/IEC 42001 (Control A.6.2.4); MITRE: Test & Evaluation; NIST AI RMF: MEASURE 1.1, MEASURE 2.6; ISACA AAIA Review Manual, Chapter 03 Part A - Audit Planning and Design", "urlSourcesRaw": "ISO/IEC 5338 (Verification) | https://www.iso.org/standard/81118.html || \nISO/IEC 42001 (Control A.6.2.4) | https://www.iso.org/standard/42001 || \nMITRE: Test & Evaluation | https://www.mitre.org/news-insights/publication/mitre-ai-maturity-model-and-organizational-assessment-tool-guide || \nNIST AI RMF: MEASURE 1.1, MEASURE 2.6 | https://www.nist.gov/itl/ai-risk-management-framework || \nISACA AAIA Review Manual, Chapter 03 Part A - Audit Planning and Design | public URL not available in reduced demo", "sourceLinks": [ { "label": "ISO/IEC 5338 (Verification)", "url": "https://www.iso.org/standard/81118.html" }, { "label": "ISO/IEC 42001 (Control A.6.2.4)", "url": "https://www.iso.org/standard/42001" }, { "label": "MITRE: Test & Evaluation", "url": "https://www.mitre.org/news-insights/publication/mitre-ai-maturity-model-and-organizational-assessment-tool-guide" }, { "label": "NIST AI RMF: MEASURE 1.1, MEASURE 2.6", "url": "https://www.nist.gov/itl/ai-risk-management-framework" } ], "nistLifecycleStage": "4. Verify & Validate", "lifecycle": [ "validate" ], "contexts": [ "lifecycle", "technology", "dedicated-ai" ], "posture": "Lifecycle or future-stage item", "auditProcedureName": "Test controls for Inadequate Verification & Validation", "auditProcedureDescription": "Examine the end-to-end control response to Inadequate Verification & Validation. Start from the risk scenario, identify where each mapped control is expected to prevent, detect, or correct it, and test the evidence produced by AI verification, validation, and release acceptance control, AI technical documentation and audit traceability, and AI change impact assessment and approval. The risk scenario is Failure to rigorously test AI models for accuracy, robustness, bias, and security prior to deployment, leading to performance failures.", "testOfDesign": "Overall test objective/purpose:\nDetermine whether the controls mapped to Inadequate Verification & Validation are deliberately designed to address the risk scenario - Failure to rigorously test AI models for accuracy, robustness, bias, and security prior to deployment, leading to performance failures. - with explicit control criteria, ownership, evidence, escalation, and coverage across AI verification, validation, and release acceptance control, AI technical documentation and audit traceability, and AI change impact assessment and approval.\n\nDetailed Test Steps:\n1. Map the risk scenario for Inadequate Verification & Validation to the in-scope AI systems, use cases, models, vendors, workflows, decisions, data flows, and governance forums before judging control design.\n2. Inspect the design of each mapped control (AI verification, validation, and release acceptance control, AI technical documentation and audit traceability, and AI change impact assessment and approval) and confirm which part of the risk scenario it prevents, detects, or corrects.\n3. Inspect the V&V control design.\n4. Inspect the V&V/release gate design for documented scope, responsible owner, applicable AI lifecycle stages, test methods/tools, test data selection/representativeness requirements, performance/robustness/safety/bias/security criteria, residual-risk thresholds, deficiency handling, release criteria, approver roles, evidence retention, and links to system requirements and risk tolerance.\n5. Inspect documentation standards/templates for required V&V records, limitations, monitoring, change, approval, and traceability fields.\n6. Inspect technical documentation standards/templates for required V&V evidence fields, including intended use, requirements traceability, test methods, datasets/representativeness rationale, metrics/results, limitations, residual risks, release approvals, model/version references, change history, monitoring design, and audit evidence retention.\n7. Inspect change procedures for V&V triggers, impact criteria, approval authority, rollback planning, and post-change monitoring requirements.\n8. Inspect whether AI change-management procedures classify model/data/prompt/configuration/vendor/integration and release changes as material when they can affect V&V conclusions, require impact assessment, re-testing/re-validation, approval, rollback/fail-safe planning, post-change monitoring, exception handling, and retained evidence before production impact.\n9. Check whether the combined design leaves any material part of Inadequate Verification & Validation uncovered, including initiation, approval, deployment, monitoring, exception handling, remediation, and evidence retention points relevant to the risk.\n10. Walk through one representative AI system, use case, model change, approval, monitoring event, vendor dependency, or incident and trace how the mapped controls would operate together from trigger to retained evidence.\n11. Record design deficiencies such as missing thresholds, duplicated-but-unowned controls, unclear handoffs, unsupported expert judgment, bypass routes, absent evidence repositories, or controls that address adjacent risks but not Inadequate Verification & Validation.\n\nRecommended Artifacts:\n- V&V policy/procedure.\n- test strategy and test plan.\n- requirements traceability matrix.\n- test datasets and representativeness rationale.\n- model/system evaluation reports.\n- performance/robustness/safety/bias/fairness/security test results.\n- benchmark and uncertainty documentation.\n- defect/anomaly/remediation tickets.\n- limitation/residual-risk records.\n- release criteria checklist.\n- approval/sign-off records.\n- model card or technical documentation.", "testOfEffectiveness": "Overall test objective/purpose:\nConfirm that the mapped controls for Inadequate Verification & Validation operated over the review period on the actual population of relevant AI systems, use cases, models, vendors, events, approvals, or decisions, and that exceptions were resolved in line with the control design.\n\nRecommended Sampling Strategy:\nUse AI systems, models, material model versions, and material releases or deployments within the AI inventory. as the primary population and AI system release, model version, or material deployment/change package. as the sample unit. Reconcile the population to the source system, register, workflow, ticket queue, monitoring output, or log extract. Stratify by system, business unit, model tier, lifecycle stage, vendor, region, or risk rating where operation differs. Add judgmental selections for high-risk, changed, exception, override, incident, failed-check, or near-threshold items. Use full-population analytics when the data is complete and the test criterion is deterministic.\n\nRecommended Sample Size:\nMinimum suggestion is 20 daily-or-more-frequent executions, alerts, log entries, or monitoring records after population completeness and control frequency are confirmed. Use full-population analytics where criteria are deterministic.\n\nDetailed Test Steps:\n1. Define the population for Inadequate Verification & Validation, depending on scope, this may be AI initiatives, use cases, model releases, approvals, monitoring events, incidents, exceptions, third-party AI services, access events, data changes, or governance decisions.\n2. Reconcile the population to source systems, registers, workflow queues, approval repositories, monitoring outputs, or issue logs and document the extraction parameters, dates, filters, exclusions, and completeness checks.\n3. Sample AI releases/model versions and verify V&V evidence was completed before release, criteria and risk tolerances were met or exceptions approved, performance/robustness/safety/bias/security evidence was retained where applicable, deficiencies were resolved or accepted, and approval/sign-off evidence exists.\n4. Sample AI systems or material releases during the period and verify that V&V was completed before deployment, criteria were met or exceptions approved, test data and results were retained, deficiencies were tracked to disposition, responsible approvals were obtained, and the release decision aligned with documented risk tolerance.\n5. Sample releases and verify technical documentation includes retained V&V records, limitations, changes, approvals, and traceability to requirements.\n6. Sample AI release/model-version documentation packages and verify V&V records, test conditions, metric results, limitations, residual risks, approvals, changes, and traceability to requirements/intended use are current, complete, retrievable, and aligned to the deployed version.\n7. Sample material AI changes and verify impact assessment, retesting, approvals, rollback evidence, and post-change monitoring were completed.\n8. Sample material AI changes, model updates, vendor updates, and release/deployment records and verify impact assessment identified V&V implications, required testing/re-validation occurred, approval and rollback evidence exists, exceptions were accepted by authorized roles, and post-change monitoring was initiated where required.\n9. For each selected item, test the applicable mapped controls (AI verification, validation, and release acceptance control, AI technical documentation and audit traceability, and AI change impact assessment and approval) for evidence of performance, performer/reviewer authority, timeliness, completeness, accuracy, and direct linkage to the sampled AI system, use case, model, vendor, event, or decision.\n10. Trace exceptions, failed checks, overrides, incidents, unresolved actions, and risk acceptances to escalation, remediation, retesting, approval, closure, or compensating-control evidence.\n11. Conclude whether the operating evidence supports reliance on the control set for Inadequate Verification & Validation, document exceptions, root-cause themes, coverage gaps, and any additional substantive or compliance testing needed.\n\nRecommended Artifacts:\n- V&V policy/procedure.\n- test strategy and test plan.\n- requirements traceability matrix.\n- test datasets and representativeness rationale.\n- model/system evaluation reports.\n- performance/robustness/safety/bias/fairness/security test results.\n- benchmark and uncertainty documentation.\n- defect/anomaly/remediation tickets.\n- limitation/residual-risk records.\n- release criteria checklist.\n- approval/sign-off records.\n- model card or technical documentation.", "applicableControlIds": [ "ctl-ai-verification-validation-release-acceptance", "ctl-ai-technical-documentation", "ctl-ai-change-impact-assessment" ] }, { "id": "demo-risk-06", "originalRiskId": "risk-prompt-injection-and-input-manipulation", "family": "AI Security and Malicious Use", "processName": "6. AI Security & Malicious Use", "subProcessName": "Adversarial Threats", "name": "Prompt Injection & Input Manipulation", "detailLevel": "full", "description": "Crafting adversarial inputs to manipulate model behavior, bypass filters, or execute unauthorized actions.", "expectedControlName": "Prompt-injection and input-manipulation defense control", "expectedControlDescription": "Test and mitigate prompt injection and malicious input scenarios using input validation, instruction hierarchy, retrieval/tool isolation, output constraints, monitoring, and user education. Include guardrail/configuration hardening, monitoring, testing protocols, and response procedures for prompt/input manipulation attempts.", "expectedControlObjective": "Reduce the likelihood that hostile inputs override AI instructions, expose data, or trigger unauthorized actions.", "controlSourceBasis": "Source-grounded: derived from OWASP LLM Top 10 LLM01 prompt-injection guidance, OWASP ML Top 10 ML01 input-manipulation guidance, NIST AI RMF MEASURE 2.6, MEASURE 2.7, MANAGE 2.3, MANAGE 2.4 and MANAGE 4.1, Gartner AI governance security framing, and ISACA AAIA Review Manual Chapter 03 Part A control-type guidance. Control wording is an Internal Audit synthesis of the cited source families, not verbatim source text.", "sourcesAndReferences": "OWASP LLM Top 10: LLM01 Prompt Injection; OWASP ML Top 10: ML01 Input Manipulation Attack; NIST AI RMF: MEASURE 2.6, MEASURE 2.7, MANAGE 2.3, MANAGE 2.4, MANAGE 4.1; Gartner: AI Governance; ISACA AAIA Review Manual, Chapter 03 Part A - Audit Planning and Design", "urlSourcesRaw": "OWASP LLM Top 10: LLM01 Prompt Injection | https://genai.owasp.org/llmrisk/llm01-prompt-injection/ || \nOWASP ML Top 10: ML01 Input Manipulation Attack | https://owasp.org/www-project-machine-learning-security-top-10/docs/ML01_2023-Input_Manipulation_Attack.html || \nNIST AI RMF 1.0 | https://doi.org/10.6028/NIST.AI.100-1 || \nNIST AI RMF Playbook | https://airc.nist.gov/AI_RMF_Knowledge_Base/Playbook || \nGartner: AI Governance | https://www.gartner.com/en/documents/6885067 || \nISACA AAIA Review Manual, Chapter 03 Part A - Audit Planning and Design | public URL not available in reduced demo", "sourceLinks": [ { "label": "OWASP LLM Top 10: LLM01", "url": "https://genai.owasp.org/llm-top-10/" }, { "label": "OWASP ML Top 10: ML01", "url": "https://owasp.org/www-project-machine-learning-security-top-10/" }, { "label": "Gartner", "url": "" }, { "label": "NIST AI RMF: MANAGE 2.5, MEASURE 2.6", "url": "https://www.nist.gov/itl/ai-risk-management-framework" } ], "nistLifecycleStage": "5. Operate & Monitor", "lifecycle": [ "operate" ], "contexts": [ "security", "technology", "dedicated-ai" ], "posture": "Specialist overlay", "auditProcedureName": "Review controls for Prompt Injection & Input Manipulation", "auditProcedureDescription": "Trace Prompt Injection & Input Manipulation from the stated risk scenario through the mapped controls. The procedure links the risk scenario to control design, population definition, operating evidence, exception handling, and residual coverage across Adversarial input and prompt-injection defense control, Postdeployment AI model monitoring, AI incident, serious-event, and failure notification, AI user instructions, limitations, and explainability documentation, and AI model versioning and change-log traceability. The risk scenario is Crafting adversarial inputs to manipulate model behavior, bypass filters, or execute unauthorized actions.", "testOfDesign": "Overall test objective/purpose:\nDetermine whether the controls mapped to Prompt Injection & Input Manipulation are deliberately designed to address the risk scenario - Crafting adversarial inputs to manipulate model behavior, bypass filters, or execute unauthorized actions. - with explicit control criteria, ownership, evidence, escalation, and coverage across Adversarial input and prompt-injection defense control, Postdeployment AI model monitoring, AI incident, serious-event, and failure notification, AI user instructions, limitations, and explainability documentation, and AI model versioning and change-log traceability.\n\nDetailed Test Steps:\n1. Map the risk scenario for Prompt Injection & Input Manipulation to the in-scope AI systems, use cases, models, vendors, workflows, decisions, data flows, and governance forums before judging control design.\n2. Inspect the design of each mapped control (Adversarial input and prompt-injection defense control, Postdeployment AI model monitoring, AI incident, serious-event, and failure notification, AI user instructions, limitations, and explainability documentation, and AI model versioning and change-log traceability) and confirm which part of the risk scenario it prevents, detects, or corrects.\n3. Review the threat model, system/prompt design, guardrail configuration, input/output validation design, RAG/untrusted-content isolation, tool/API permission matrix, human approval gates, monitoring/incident procedures, owner/frequency/risk tolerance, and adversarial test protocol.\n4. Inspect whether the AI system design includes explicit direct, indirect, multimodal, RAG/external-content, jailbreak, tool-call, data-exfiltration, and unauthorized-action prompt/input manipulation scenarios, system prompt and instruction hierarchy controls, input/output validation, untrusted-content segregation, retrieval/tool isolation, least-privilege tool/API permission boundaries, human approval for privileged actions, monitoring/incident procedures, owner/frequency/risk tolerance, and adversarial test protocols.\n5. Review monitoring design, thresholds, alert routes, ownership, and response linkage.\n6. Inspect monitoring design for prompt/input manipulation indicators, anomalous tool/action attempts, guardrail bypasses, sensitive-data exposure attempts, unsafe outputs, threshold definitions, log sources, alert routing, ownership, review cadence, incident/change linkage, corrective-action triggers, and evidence retention.\n7. Review incident taxonomy, severity criteria, notification/escalation routes, root-cause/corrective-action procedure, and evidence retention requirements.\n8. Inspect AI incident taxonomy, severity thresholds, response runbooks, notification decision trees, containment/deactivation criteria, forensic evidence requirements, RCA/CAPA workflow, and postincident review requirements to confirm prompt injection, input manipulation, guardrail bypass, unauthorized tool action, data exfiltration, and connected-system damage scenarios are in scope.\n9. Review guidance, training, user instructions, and update process for prompt/input security content.\n10. Inspect user/admin instructions, model/system cards, secure-use guidance, limitation disclosures, warning text, training materials, and escalation routes to confirm they explain prompt-injection/input-manipulation risks, verification duties, prohibited uses, human approval expectations, and how to report suspected bypasses or unsafe behavior.\n11. Check whether the combined design leaves any material part of Prompt Injection & Input Manipulation uncovered, including initiation, approval, deployment, monitoring, exception handling, remediation, and evidence retention points relevant to the risk.\n12. Walk through one representative AI system, use case, model change, approval, monitoring event, vendor dependency, or incident and trace how the mapped controls would operate together from trigger to retained evidence.\n13. Record design deficiencies such as missing thresholds, duplicated-but-unowned controls, unclear handoffs, unsupported expert judgment, bypass routes, absent evidence repositories, or controls that address adjacent risks but not Prompt Injection & Input Manipulation.\n\nRecommended Artifacts:\n- AI threat model / misuse case register.\n- prompt-injection and input-manipulation test cases.\n- guardrail/prompt/security configuration records.\n- input/output validation rules.\n- RAG/untrusted-content segregation design.\n- tool/API permission matrix.\n- human approval workflow logs.\n- test execution reports and red-team results.\n- monitoring dashboards/logs.\n- incident/exception tickets.\n- remediation/retest evidence.\n- user/admin secure-use guidance.", "testOfEffectiveness": "Overall test objective/purpose:\nConfirm that the mapped controls for Prompt Injection & Input Manipulation operated over the review period on the actual population of relevant AI systems, use cases, models, vendors, events, approvals, or decisions, and that exceptions were resolved in line with the control design.\n\nRecommended Sampling Strategy:\nUse AI systems or components that accept user-controlled, third-party, retrieved, multimodal, or tool-triggering inputs. as the primary population and AI system/release, prompt/configuration version, RAG corpus update, tool integration, adversarial test case, monitoring alert, incident/exception ticket, high-risk tool-action approval, or prompt/guardrail/tool-permission change. as the sample unit. Reconcile the population to the source system, register, workflow, ticket queue, monitoring output, or log extract. Stratify by system, business unit, model tier, lifecycle stage, vendor, region, or risk rating where operation differs. Add judgmental selections for high-risk, changed, exception, override, incident, failed-check, or near-threshold items. Use full-population analytics when the data is complete and the test criterion is deterministic.\n\nRecommended Sample Size:\nMinimum suggestion is 20 daily-or-more-frequent executions, alerts, log entries, or monitoring records after population completeness and control frequency are confirmed. Use full-population analytics where criteria are deterministic.\n\nDetailed Test Steps:\n1. Define the population for Prompt Injection & Input Manipulation, depending on scope, this may be AI initiatives, use cases, model releases, approvals, monitoring events, incidents, exceptions, third-party AI services, access events, data changes, or governance decisions.\n2. Reconcile the population to source systems, registers, workflow queues, approval repositories, monitoring outputs, or issue logs and document the extraction parameters, dates, filters, exclusions, and completeness checks.\n3. Verify the control design or operating evidence addresses the requirement in practical terms, For a sample of systems/releases/prompts/RAG/tool integrations and adversarial test cases, verify tests executed, validation/guardrail/tool-call controls operated, high-risk actions were approved, alerts/incidents/exceptions were logged and escalated, remediation/retesting occurred, and retained evidence supports ongoing monitoring.\n4. Sample deployed AI systems or releases exposed to user/external/retrieved/multimodal/tool-triggering inputs, verify adversarial and prompt-injection tests executed, inspect validation/guardrail logs, RAG segregation evidence, tool-call approval records, monitoring alerts, incident/exception tickets, remediation actions, and retesting evidence, confirm failures or bypasses were escalated and corrected within defined thresholds.\n5. Sample alerts/incidents/exceptions for prompt/input manipulation indicators and verify triage, escalation, closure, and retesting.\n6. Sample monitoring periods, alerts, anomalies, incidents, and corrective actions for in-scope AI systems, verify monitoring ran at the defined cadence, prompt/input manipulation signals were reviewed, thresholds were applied, exceptions were triaged/escalated, corrective actions were completed, and remediation/retesting evidence was retained.\n7. Sample incidents/exceptions/simulations and verify timely classification, escalation, response, remediation, and closure evidence.\n8. Sample realized or simulated prompt/input manipulation events, incidents, near-misses, vulnerability reports, and tabletop exercises, verify classification, severity assessment, escalation, containment, notification assessment, evidence preservation, root cause, remediation, retesting, closure, and lessons-learned evidence.\n9. Sample relevant users/releases and verify distribution, acknowledgement/training where applicable, and evidence that guidance was used in operations or incident handling.\n10. Sample current user/admin guidance, training or acknowledgement records, deployed AI interfaces, and change history, verify instructions are available to relevant users, current for the deployed version, include prompt/input manipulation warnings and escalation routes, and were updated after material prompt, model, RAG, tool, or guardrail changes.\n11. For each selected item, test the applicable mapped controls (Adversarial input and prompt-injection defense control, Postdeployment AI model monitoring, AI incident, serious-event, and failure notification, AI user instructions, limitations, and explainability documentation, and AI model versioning and change-log traceability) for evidence of performance, performer/reviewer authority, timeliness, completeness, accuracy, and direct linkage to the sampled AI system, use case, model, vendor, event, or decision.\n12. Trace exceptions, failed checks, overrides, incidents, unresolved actions, and risk acceptances to escalation, remediation, retesting, approval, closure, or compensating-control evidence.\n13. Conclude whether the operating evidence supports reliance on the control set for Prompt Injection & Input Manipulation, document exceptions, root-cause themes, coverage gaps, and any additional substantive or compliance testing needed.\n\nRecommended Artifacts:\n- AI threat model / misuse case register.\n- prompt-injection and input-manipulation test cases.\n- guardrail/prompt/security configuration records.\n- input/output validation rules.\n- RAG/untrusted-content segregation design.\n- tool/API permission matrix.\n- human approval workflow logs.\n- test execution reports and red-team results.\n- monitoring dashboards/logs.\n- incident/exception tickets.\n- remediation/retest evidence.\n- user/admin secure-use guidance.", "applicableControlIds": [ "ctl-ai-adversarial-input-and-prompt-injection-defense", "ctl-ai-postdeployment-model-monitoring", "ctl-ai-incident-notification", "ctl-ai-user-instructions-explainability", "ctl-ai-version-change-log" ] }, { "id": "demo-risk-07", "originalRiskId": "risk-inadequate-or-missing-ai-governance-framework", "family": "AI Governance and Risk", "processName": "3. AI Governance & Risk", "subProcessName": "Policy & Framework", "name": "Inadequate or Missing AI Governance Framework", "detailLevel": "full", "description": "The organization lacks a formalized, approved, and operating AI governance framework or management system, or the existing framework is too incomplete to define accountable ownership, policies, risk appetite, AI inventory/classification, lifecycle gates, legal/regulatory obligation management, monitoring, incidents, exceptions, and management reporting. As a result, AI risks and obligations may be identified inconsistently, controls may lack ownership, and Internal Audit may lack stable criteria for assessing AI governance.", "expectedControlName": "AI governance framework control", "expectedControlDescription": "Establish and periodically review an AI governance framework covering policy, roles, risk appetite, lifecycle controls, inventory, classification, monitoring, incidents, and reporting. Include executive ownership, AI committee mandate, policy alignment, risk management process, asset management process, standards/framework adoption, and reporting cadence.", "expectedControlObjective": "Provide a coherent management system for governing AI risks across the organization.", "controlSourceBasis": "Source-grounded:\n\nGrounded in: Gartner: AI Governance; Gartner: Reference Guide for AI Governance; ISO/IEC 42001 (Clause 4.4, 5.2, 5.3, 6.1, 7.5, 8, 9, Annex A.2/A.3); NIST AI RMF GOVERN 1.1 and GOVERN 2.1; MITRE AI Maturity Model: Governance; EU AI Act Articles 9, 16, and 17.\n\nInformed by: ISACA AAIA Review Manual, Chapter 03 Part A - Audit Planning and Design. Control wording is an Internal Audit synthesis, not verbatim source text.", "sourcesAndReferences": "Gartner: AI Governance; Gartner: Reference Guide for AI Governance; ISO/IEC 42001 (Clause 4.4, 5.2, 5.3, 6.1, 7.5, 8, 9, Annex A.2/A.3); NIST AI RMF: GOVERN 1.1, GOVERN 2.1; MITRE AI Maturity Model: Governance; EU AI Act: Articles 9, 16, 17; ISACA AAIA Review Manual, Chapter 03 Part A - Audit Planning and Design", "urlSourcesRaw": "Gartner: AI Governance | https://www.gartner.com/en/documents/6885067 || \nGartner: Reference Guide for AI Governance | Gartner source label; public URL not available in reduced demo || \nISO/IEC 42001 (Clause 4.4, A.2, A.3) | https://www.iso.org/standard/42001 || \nNIST AI RMF: GOVERN 1.1, GOVERN 2.1 | https://www.nist.gov/itl/ai-risk-management-framework || \nMITRE AI Maturity Model: Governance | https://www.mitre.org/news-insights/publication/mitre-ai-maturity-model-and-organizational-assessment-tool-guide || \nEU AI Act: Articles 9, 16, 17 | https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng || \nISACA AAIA Review Manual, Chapter 03 Part A - Audit Planning and Design | public URL not available in reduced demo", "sourceLinks": [ { "label": "Gartner", "url": "" }, { "label": "MITRE: Governance", "url": "https://www.mitre.org/news-insights/publication/mitre-ai-maturity-model-and-organizational-assessment-tool-guide" }, { "label": "ISO/IEC 42001 (Clause 4.4, A.2)", "url": "https://www.iso.org/standard/42001" }, { "label": "NIST AI RMF: GOVERN 1.1, GOVERN 2.1", "url": "https://www.nist.gov/itl/ai-risk-management-framework" } ], "nistLifecycleStage": "1. Plan & Design", "lifecycle": [ "plan" ], "contexts": [ "governance", "third-party", "business-audit", "dedicated-ai" ], "posture": "Baseline governance", "auditProcedureName": "Evaluate AI governance framework and management system", "auditProcedureDescription": "Trace the control for AI governance framework and management system from the event, decision, or cadence that triggers it through execution, review, exception handling, and retained evidence. Use the control objective as the reference point. Provide a coherent, documented, accountable, risk-based management system for governing AI obligations, risks, controls, lifecycle activities, and reporting across the organization. Confirm that the described control activity is performed through clear criteria, accountable ownership, defined timing, complete population coverage, reliable source records, and evidence that exceptions are escalated and resolved. Where the control relies on automated monitoring, workflow approval, or manual expert review, verify that handoffs and evidence repositories are clear enough for repeatable audit testing. The work should cover the activity defined for the control. Establish, implement, maintain, periodically review, and continually improve an AI governance framework covering mandate and scope, AI policy, roles and decision rights, risk appetite/tolerance, AI inventory and classification, lifecycle controls, legal/regulatory obligation management, impact/risk assessment, third-party responsibilities, monitoring, incidents/concerns, exceptions, and management/governance reporting.", "testOfDesign": "Overall test objective/purpose:\nDetermine whether AI governance framework and management system is designed with criteria, ownership, timing, evidence, and exception handling precise enough to achieve the objective. Provide a coherent, documented, accountable, risk-based management system for governing AI obligations, risks, controls, lifecycle activities, and reporting across the organization.\n\nDetailed Test Steps:\n1. Inspect whether the AI governance framework is formally documented and approved, defines scope/mandate, policy, objectives, risk tolerance, RACI/decision rights, inventory/classification, lifecycle gates, risk/impact assessment, legal obligations, third-party responsibilities, monitoring, incident/concern reporting, exceptions, management review, frequency, evidence retention, and.\n2. Inspect the documented AI governance framework and management system policy, standard, workflow, configuration, checklist, approval template, or procedure and trace each required element to the stated control objective.\n3. Confirm that the AI governance framework and management system design names the accountable owner (Executive/top management accountable, operational owner likely AI governance lead, AI governance committee, enterprise risk/compliance, or CIO/CDO depending on operating model.) and expected performance cadence (Framework and policy reviewed at planned intervals and when material organizational, legal, technical, or AI-use changes occur, AI inventory at least annually with event-driven updates for material changes.), including reviewer, delegate, and escalation responsibilities where applicable.\n4. Check that the design defines the in-scope population (All AI systems/use cases within the AI governance framework scope, governance artifacts, assessments, exceptions, incidents, third-party AI services, and management-review cycles in the audit period.), sampling unit (AI use case/system record, governance decision, risk/impact assessment, lifecycle gate approval, exception/incident/concern, committee or management-review meeting.), and process/system boundary (governance-and-accountability process boundary) so testing can be repeated by another auditor.\n5. Walk through one representative control occurrence, AI lifecycle event, approval, change, exception, or monitoring record covered by AI governance framework and management system. Trace it from trigger through decision, escalation, and evidence retention and identify where the control prevents, detects, or corrects the targeted risk.\n6. Challenge whether bypasses, undocumented judgment, missing thresholds, unclear reviewer authority, weak segregation, or absent retention rules could prevent AI governance framework and management system from operating consistently.\n\nRecommended Artifacts:\n- AI governance charter/committee mandate.\n- AI policy and standards.\n- RACI/decision-rights matrix.\n- AI risk appetite/tolerance statement.\n- AI inventory/register/model catalog.\n- classification criteria and approvals.\n- risk assessment and treatment records.\n- impact assessment records.\n- lifecycle gate checklists and approvals.\n- legal/regulatory obligation map.", "testOfEffectiveness": "Overall test objective/purpose:\nConfirm that AI governance framework and management system operated during the review period in line with its documented criteria, ownership, frequency, evidence requirements, and exception path.\n\nRecommended Sampling Strategy:\nUse All AI systems/use cases within the AI governance framework scope as the primary population and AI use case/system record as the sample unit. Reconcile the population to the source system, register, workflow, ticket queue, monitoring output, or log extract. Stratify by system, business unit, model tier, lifecycle stage, vendor, region, or risk rating where operation differs. Add judgmental selections for high-risk, changed, exception, override, incident, failed-check, or near-threshold items. Use full-population analytics when the data is complete and the test criterion is deterministic.\n\nRecommended Sample Size:\nMinimum suggestion is the annual execution plus interim changes, exceptions, approvals, and triggering events relevant to the control. Annual controls do not have a fixed standard sample size in the matrix.\n\nDetailed Test Steps:\n1. Build the population for AI governance framework and management system from the system, workflow, register, log, or approval repository that records control execution. Document extraction parameters, date range, filters, and completeness reconciliation.\n2. Select a period and sample AI use cases/systems, governance meetings, risk assessments, impact assessments, policy exceptions, incidents/concerns, and management-review cycles, verify the framework was applied, records retained, exceptions escalated, actions tracked to closure, and periodic reviews completed according to defined cadence.\n3. For each selected item, verify the control was performed by the expected owner or reviewer, at the required point in the process, against the defined criteria, and before the AI decision, release, approval, use, or event proceeded where the design requires prior control execution.\n4. Compare retained evidence to the control design and confirm completeness, accuracy, reviewer sign-off, timestamps, linkage to the AI system/use case/model/vendor/event, and consistency with the required cadence.\n5. Trace exceptions, overrides, failed checks, late reviews, unresolved actions, and risk acceptances to escalation, remediation, approval, retesting, or closure evidence.\n\nRecommended Artifacts:\n- AI governance charter/committee mandate.\n- AI policy and standards.\n- RACI/decision-rights matrix.\n- AI risk appetite/tolerance statement.\n- AI inventory/register/model catalog.\n- classification criteria and approvals.\n- risk assessment and treatment records.\n- impact assessment records.\n- lifecycle gate checklists and approvals.\n- legal/regulatory obligation map.", "applicableControlIds": [ "ctl-ai-governance-framework-management-system" ] }, { "id": "demo-risk-08", "originalRiskId": "risk-ai-supply-chain-and-third-party-risk", "family": "AI Governance and Risk", "processName": "3. AI Governance & Risk", "subProcessName": "Legal & Compliance", "name": "AI Supply Chain & Third-Party Risk", "detailLevel": "full", "description": "Vulnerabilities in the AI supply chain, including compromised third-party models, training data, or ambiguity in vendor contracts.", "expectedControlName": "AI third-party risk management control", "expectedControlDescription": "Assess AI vendors, models, datasets, plugins, APIs, distributors, importers, notified bodies, and service providers for security, privacy, resilience, transparency, conformity, contractual, and monitoring requirements before and during use. Include AI-specific contract obligations covering permitted data/model use, consent, regulatory obligations, audit/evidence rights, transparency, incident notification, subcontractors, vendor model/service changes, third-party conformity evidence, and provider/deployer responsibility split.", "expectedControlObjective": "Control AI-related dependencies, external components, and supplier obligations across the lifecycle.", "controlSourceBasis": "Source-grounded: derived from the row references (OWASP LLM Top 10: LLM05; OWASP ML Top 10: ML06; ISO/IEC 42001 (Suppliers A.10.3); NIST AI RMF: MANAGE 1.3, MAP 2.3). Control wording is an Internal Audit interpretation of the cited source families, not verbatim source text. Also informed by ISACA AAIA Review Manual, Chapter 03 Part A - Audit Planning and Design, especially Figure 3.1 common AI control types and Chapter 3.1 AI asset identification guidance. Also informed by ISACA AI Audit Toolkit 2024, Artificial Intelligence Audit Toolkit Overview; workbook Aggregate AI Control Library tab (External Components & Supply Chain Governance controls).", "sourcesAndReferences": "OWASP LLM Top 10: LLM05; OWASP ML Top 10: ML06; ISO/IEC 42001 (Suppliers A.10.3); NIST AI RMF: MANAGE 1.3, MAP 2.3; ISACA AAIA Review Manual, Chapter 03 Part A - Audit Planning and Design; ISACA AI Audit Toolkit 2024, Artificial Intelligence Audit Toolkit Overview; workbook Aggregate AI Control Library tab (External Components & Supply Chain Governance controls)", "urlSourcesRaw": "OWASP LLM Top 10: LLM05 | https://genai.owasp.org/llm-top-10/ || \nOWASP ML Top 10: ML06 | https://owasp.org/www-project-machine-learning-security-top-10/ || \nISO/IEC 42001 (Suppliers A.10.3) | https://www.iso.org/standard/42001 || \nNIST AI RMF: MANAGE 1.3, MAP 2.3 | https://www.nist.gov/itl/ai-risk-management-framework || \nISACA AAIA Review Manual, Chapter 03 Part A - Audit Planning and Design | public URL not available in reduced demo || \nISACA - A Toolkit to Facilitate AI Governance (public) | https://www.isaca.org/resources/news-and-trends/isaca-now-blog/2024/a-toolkit-to-facilitate-ai-governance", "sourceLinks": [ { "label": "OWASP LLM Top 10: LLM05", "url": "https://genai.owasp.org/llm-top-10/" }, { "label": "OWASP ML Top 10: ML06", "url": "https://owasp.org/www-project-machine-learning-security-top-10/" }, { "label": "ISO/IEC 42001 (Suppliers A.10.3)", "url": "https://www.iso.org/standard/42001" }, { "label": "NIST AI RMF: MANAGE 1.3, MAP 2.3", "url": "https://www.nist.gov/itl/ai-risk-management-framework" } ], "nistLifecycleStage": "2. Collect & Process Data", "lifecycle": [ "data" ], "contexts": [ "governance", "third-party", "business-audit", "dedicated-ai" ], "posture": "Baseline governance", "auditProcedureName": "Test controls for AI Supply Chain & Third-Party Risk", "auditProcedureDescription": "Examine the end-to-end control response to AI Supply Chain & Third-Party Risk. Start from the risk scenario, identify where each mapped control is expected to prevent, detect, or correct it, and test the evidence produced by AI supplier and external-component due diligence, AI supply-chain integrity verification, and AI-specific contract and notification obligations. The risk scenario is Vulnerabilities in the AI supply chain, including compromised third-party models, training data, or ambiguity in vendor contracts.", "testOfDesign": "Overall test objective/purpose:\nDetermine whether the controls mapped to AI Supply Chain & Third-Party Risk are deliberately designed to address the risk scenario - Vulnerabilities in the AI supply chain, including compromised third-party models, training data, or ambiguity in vendor contracts. - with explicit control criteria, ownership, evidence, escalation, and coverage across AI supplier and external-component due diligence, AI supply-chain integrity verification, and AI-specific contract and notification obligations.\n\nDetailed Test Steps:\n1. Map the risk scenario for AI Supply Chain & Third-Party Risk to the in-scope AI systems, use cases, models, vendors, workflows, decisions, data flows, and governance forums before judging control design.\n2. Inspect the design of each mapped control (AI supplier and external-component due diligence, AI supply-chain integrity verification, and AI-specific contract and notification obligations) and confirm which part of the risk scenario it prevents, detects, or corrects.\n3. Inspect vendor AI due-diligence criteria and linkage from AI intake/procurement to supplier review.\n4. Inspect AI third-party management policy/procedure, intake/procurement gates, supplier/component classification criteria, approved supplier/component inventory, due-diligence checklist, responsibility matrix, monitoring frequency, exception/escalation criteria, conformity-evidence requirements, and evidence retention expectations.\n5. Inspect whether due-diligence procedures require provenance/transparency/terms review for external AI components where IP exposure may arise.\n6. Inspect third-party plugin/API onboarding standard, due diligence criteria, responsibility matrix, contractual/security evidence requirements, vulnerability reporting process, and periodic review cadence.\n7. Inspect vendor/model/dataset due diligence criteria and monitoring requirements for poisoning and provenance risk.\n8. Inspect supplier due-diligence criteria for model/API asset protection, vendor security evidence, shared responsibility, access limitations and monitoring expectations.\n9. Inspect supply-chain verification policy, model/data/software dependency inventory design, SBOM or equivalent requirements, provenance criteria, package/model authenticity/signature verification steps, repository/model-hub approval rules, vulnerability scanning cadence, MLOps access/exposure controls, and exception/remediation workflow.\n10. Inspect AI contract playbook/templates, procurement/legal review checklist, minimum required AI clauses, regulatory/conformity/evidence rights, notification/change/subcontractor/IP/data-use terms, responsibility matrix, and exception approval process.\n11. Check whether the combined design leaves any material part of AI Supply Chain & Third-Party Risk uncovered, including initiation, approval, deployment, monitoring, exception handling, remediation, and evidence retention points relevant to the risk.\n12. Walk through one representative AI system, use case, model change, approval, monitoring event, vendor dependency, or incident and trace how the mapped controls would operate together from trigger to retained evidence.\n13. Record design deficiencies such as missing thresholds, duplicated-but-unowned controls, unclear handoffs, unsupported expert judgment, bypass routes, absent evidence repositories, or controls that address adjacent risks but not AI Supply Chain & Third-Party Risk.\n\nRecommended Artifacts:\n- AI vendor assessments.\n- procurement/vendor onboarding records.\n- security/privacy review records.\n- contract/responsibility matrix.\n- periodic review evidence.\n- AI vendor assessment.\n- external component inventory.\n- approved supplier/model/dataset/API/plugin list.\n- supplier due diligence checklist.\n- security/privacy review.\n- model card or supplier documentation.\n- provider/deployer responsibility matrix.", "testOfEffectiveness": "Overall test objective/purpose:\nConfirm that the mapped controls for AI Supply Chain & Third-Party Risk operated over the review period on the actual population of relevant AI systems, use cases, models, vendors, events, approvals, or decisions, and that exceptions were resolved in line with the control design.\n\nRecommended Sampling Strategy:\nUse Third-party AI suppliers, external components, embedded vendor AI features, APIs, datasets, plugins, and AI services. as the primary population and AI vendor/component due-diligence record. as the sample unit. Reconcile the population to the source system, register, workflow, ticket queue, monitoring output, or log extract. Stratify by system, business unit, model tier, lifecycle stage, vendor, region, or risk rating where operation differs. Add judgmental selections for high-risk, changed, exception, override, incident, failed-check, or near-threshold items. Use full-population analytics when the data is complete and the test criterion is deterministic.\n\nRecommended Sample Size:\nMinimum suggestion is 20 daily-or-more-frequent executions, alerts, log entries, or monitoring records after population completeness and control frequency are confirmed. Use full-population analytics where criteria are deterministic.\n\nDetailed Test Steps:\n1. Define the population for AI Supply Chain & Third-Party Risk, depending on scope, this may be AI initiatives, use cases, model releases, approvals, monitoring events, incidents, exceptions, third-party AI services, access events, data changes, or governance decisions.\n2. Reconcile the population to source systems, registers, workflow queues, approval repositories, monitoring outputs, or issue logs and document the extraction parameters, dates, filters, exclusions, and completeness checks.\n3. Sample third-party AI acquisitions/use approvals and verify supplier due diligence was completed before approval/use and during periodic review if required.\n4. Sample AI vendors/external models/datasets/APIs/plugins approved or reviewed in the period and test whether due diligence was completed before use, responsibilities and supplier requirements were documented, risk/conformity/security/privacy evidence was reviewed, issues were escalated, and periodic reviews occurred.\n5. Sample external model/dataset/API onboarding and review records to verify provenance and usage-limit review occurred.\n6. Sample third-party plugins/APIs and verify due diligence, approvals, documentation, monitoring, vulnerability notifications, exceptions, and decommissioning decisions occurred as required.\n7. Sample external datasets/models/adapters and verify due diligence, approval and ongoing monitoring evidence.\n8. Sample third-party AI suppliers/components to verify security due diligence, attestations, access constraints, monitoring and exceptions were completed before/while in use.\n9. Sample integrated external models/datasets/packages/plugins/platform dependencies and test whether provenance/authenticity checks, vulnerability scans, approval records, secure-source checks, MLOps access/exposure controls, and remediation/exception records exist and operated before use or at required intervals.\n10. Sample AI supplier contracts/amendments and test whether required AI clauses are present or exceptions approved, supplier changes/incidents were notified per terms, evidence/audit rights were used when needed, and permitted data/model-use restrictions align with policy.\n11. For each selected item, test the applicable mapped controls (AI supplier and external-component due diligence, AI supply-chain integrity verification, and AI-specific contract and notification obligations) for evidence of performance, performer/reviewer authority, timeliness, completeness, accuracy, and direct linkage to the sampled AI system, use case, model, vendor, event, or decision.\n12. Trace exceptions, failed checks, overrides, incidents, unresolved actions, and risk acceptances to escalation, remediation, retesting, approval, closure, or compensating-control evidence.\n13. Conclude whether the operating evidence supports reliance on the control set for AI Supply Chain & Third-Party Risk, document exceptions, root-cause themes, coverage gaps, and any additional substantive or compliance testing needed.\n\nRecommended Artifacts:\n- AI vendor assessments.\n- procurement/vendor onboarding records.\n- security/privacy review records.\n- contract/responsibility matrix.\n- periodic review evidence.\n- AI vendor assessment.\n- external component inventory.\n- approved supplier/model/dataset/API/plugin list.\n- supplier due diligence checklist.\n- security/privacy review.\n- model card or supplier documentation.\n- provider/deployer responsibility matrix.", "applicableControlIds": [ "ctl-ai-supplier-due-diligence", "ctl-ai-supply-chain-integrity-verification", "ctl-ai-contract-obligations" ] }, { "id": "demo-risk-09", "originalRiskId": "risk-metadata-and-lineage-management-failure", "family": "AI Data Management", "processName": "4. AI Data Management", "subProcessName": "Data Quality", "name": "Metadata & Lineage Management Failure", "detailLevel": "full", "description": "Failure to manage technical metadata, lineage, and data/model documentation as operational infrastructure, weakening traceability, reproducibility, explainability, and internal governance over data and model dependencies.", "expectedControlName": "Data lineage and provenance control", "expectedControlDescription": "Capture and maintain data origin, transformations, ownership, quality checks, access history, and lineage for datasets used in material AI systems. Include logical, physical, and context dataflow diagrams; process-flow documentation; data sourcing, consent, enrichment, transformation, and decision traceability.", "expectedControlObjective": "Make AI data traceable, explainable, and auditable across collection, preparation, use, and change.", "controlSourceBasis": "Source-grounded: derived from the row references (Gartner: AI Data Guide; ISO/IEC 5338; ISO/IEC 42001 (Provenance A.7.5); NIST AI RMF: MAP 2.3). Control wording is an Internal Audit interpretation of the cited source families, not verbatim source text. Also informed by ISACA AAIA Review Manual, Chapter 03 Part A - Audit Planning and Design, especially Figure 3.1 common AI control types and Chapter 3.1 AI asset identification guidance.", "sourcesAndReferences": "Gartner: AI Data Guide; ISO/IEC 5338; ISO/IEC 42001 (Provenance A.7.5); NIST AI RMF: MAP 2.3; ISACA AAIA Review Manual, Chapter 03 Part A - Audit Planning and Design", "urlSourcesRaw": "Gartner: AI Data Guide | https://www.gartner.com/en/documents/6486471 || \nISO/IEC 5338 | https://www.iso.org/standard/81118.html || \nISO/IEC 42001 (Provenance A.7.5) | https://www.iso.org/standard/42001 || \nNIST AI RMF: MAP 2.3 | https://www.nist.gov/itl/ai-risk-management-framework || \nISACA AAIA Review Manual, Chapter 03 Part A - Audit Planning and Design | public URL not available in reduced demo", "sourceLinks": [ { "label": "Gartner", "url": "" }, { "label": "ISO/IEC 5338", "url": "https://www.iso.org/standard/81118.html" }, { "label": "ISO/IEC 42001 (Provenance A.7.5)", "url": "https://www.iso.org/standard/42001" }, { "label": "NIST AI RMF: MAP 2.3", "url": "https://www.nist.gov/itl/ai-risk-management-framework" } ], "nistLifecycleStage": "2. Collect & Process Data", "lifecycle": [ "data" ], "contexts": [ "data", "privacy", "security", "business-audit", "dedicated-ai" ], "posture": "Specialist overlay", "auditProcedureName": "Examine controls for Metadata & Lineage Management Failure", "auditProcedureDescription": "Test the audit trail for Metadata & Lineage Management Failure by selecting relevant AI systems, use cases, models, vendors, events, or approvals and verifying that AI data lineage, provenance, and metadata control, AI technical documentation and audit traceability, and Data quality, drift, and validation issue remediation operated together to address the risk scenario. The risk scenario is Failure to manage technical metadata, lineage, and data/model documentation as operational infrastructure, weakening traceability, reproducibility, explainability, and internal governance over data and model dependencies.", "testOfDesign": "Overall test objective/purpose:\nDetermine whether the controls mapped to Metadata & Lineage Management Failure are deliberately designed to address the risk scenario - Failure to manage technical metadata, lineage, and data/model documentation as operational infrastructure, weakening traceability, reproducibility, explainability, and internal governance over data and model dependencies. - with explicit control criteria, ownership, evidence, escalation, and coverage across AI data lineage, provenance, and metadata control, AI technical documentation and audit traceability, and Data quality, drift, and validation issue remediation.\n\nDetailed Test Steps:\n1. Map the risk scenario for Metadata & Lineage Management Failure to the in-scope AI systems, use cases, models, vendors, workflows, decisions, data flows, and governance forums before judging control design.\n2. Inspect the design of each mapped control (AI data lineage, provenance, and metadata control, AI technical documentation and audit traceability, and Data quality, drift, and validation issue remediation) and confirm which part of the risk scenario it prevents, detects, or corrects.\n3. Inspect policies, procedures, metadata standards, lineage templates/tooling, required fields, ownership, frequency/triggers, exception handling, and retention requirements, verify.\n4. Inspect data governance/AI lifecycle procedures, metadata standards, lineage/provenance requirements, required fields, ownership, lifecycle trigger points, exception rules, retention expectations, and tool/process integration.\n5. Inspect documentation standards, templates, role assignments, update triggers, event logging requirements, and traceability expectations, verify they include data/model/architecture/lineage references.\n6. Inspect technical documentation requirements for scientific rationale, validation, limitations, and traceability fields.\n7. Inspect technical documentation standards/templates and required AI documentation fields, including data/model/architecture/lineage references, roles, event logs, change updates, and audit traceability expectations.\n8. Inspect required documentation fields for production promotion and confirm they include architecture, data, models, versions, ownership, controls, monitoring and traceability.\n9. Verify documentation captures downstream output sinks, trust boundaries, validation/encoding rules, owners, limitations, monitoring, and change triggers.\n10. Inspect whether technical documentation standards include AI tool/plugin components, data/control flows, permission boundaries, validations, owners, limitations, monitoring, incident handling, and change traceability.\n11. Check whether the combined design leaves any material part of Metadata & Lineage Management Failure uncovered, including initiation, approval, deployment, monitoring, exception handling, remediation, and evidence retention points relevant to the risk.\n12. Walk through one representative AI system, use case, model change, approval, monitoring event, vendor dependency, or incident and trace how the mapped controls would operate together from trigger to retained evidence.\n13. Record design deficiencies such as missing thresholds, duplicated-but-unowned controls, unclear handoffs, unsupported expert judgment, bypass routes, absent evidence repositories, or controls that address adjacent risks but not Metadata & Lineage Management Failure.\n\nRecommended Artifacts:\n- AI dataset/source inventory.\n- data catalog entries.\n- data lineage diagrams.\n- dataflow diagrams.\n- process-flow documentation.\n- metadata standard/data dictionary.\n- dataset datasheets/model cards.\n- provenance records.\n- data acquisition/selection records.\n- transformation pipeline logs.\n- label/enrichment records.\n- quality check results.", "testOfEffectiveness": "Overall test objective/purpose:\nConfirm that the mapped controls for Metadata & Lineage Management Failure operated over the review period on the actual population of relevant AI systems, use cases, models, vendors, events, approvals, or decisions, and that exceptions were resolved in line with the control design.\n\nRecommended Sampling Strategy:\nUse Datasets, data sources, feature/retrieval stores, data pipelines, and model/system versions used by material AI systems as the primary population and AI system-to-dataset mapping, dataset record, pipeline/transformation run, lineage artifact, or data change ticket as the sample unit. Reconcile the population to the source system, register, workflow, ticket queue, monitoring output, or log extract. Stratify by system, business unit, model tier, lifecycle stage, vendor, region, or risk rating where operation differs. Add judgmental selections for high-risk, changed, exception, override, incident, failed-check, or near-threshold items. Use full-population analytics when the data is complete and the test criterion is deterministic.\n\nRecommended Sample Size:\nMinimum suggestion is 20 daily-or-more-frequent executions, alerts, log entries, or monitoring records after population completeness and control frequency are confirmed. Use full-population analytics where criteria are deterministic.\n\nDetailed Test Steps:\n1. Define the population for Metadata & Lineage Management Failure, depending on scope, this may be AI initiatives, use cases, model releases, approvals, monitoring events, incidents, exceptions, third-party AI services, access events, data changes, or governance decisions.\n2. Reconcile the population to source systems, registers, workflow queues, approval repositories, monitoring outputs, or issue logs and document the extraction parameters, dates, filters, exclusions, and completeness checks.\n3. Select in-scope AI systems/datasets and test whether source, transformation, owner, intended use, update status, quality checks, lineage/dependency mapping, change history, approvals, exceptions, and retained evidence are complete and current.\n4. Sample material AI systems/datasets and verify lineage/provenance records show source, owner, intended use, acquisition/selection rationale, transformations, labels/enrichment, quality checks, version/model dependencies, update dates, change history, issue traceability, approvals, and retained evidence.\n5. Sample AI systems and verify technical documentation packages include data/model/design/change/monitoring details, current links to provenance/lineage records, retained event logs, and evidence of updates after material change.\n6. Sample documentation packages and verify current, complete, retrievable validation and limitation evidence.\n7. Sample AI systems and verify technical documentation is current, complete for data/model/architecture/change/monitoring elements, linked to lineage/provenance records, and retained for audit review.\n8. Sample promoted AI pilots and verify required technical documentation was complete/current at approval and updated after production release.\n9. Sample features/releases and verify documentation matches implemented output controls and retained validation/monitoring evidence.\n10. Sample deployed AI tools/plugins and verify technical documentation is current, complete, approved, and traceable to tests, logs, changes, and incidents.\n11. For each selected item, test the applicable mapped controls (AI data lineage, provenance, and metadata control, AI technical documentation and audit traceability, and Data quality, drift, and validation issue remediation) for evidence of performance, performer/reviewer authority, timeliness, completeness, accuracy, and direct linkage to the sampled AI system, use case, model, vendor, event, or decision.\n12. Trace exceptions, failed checks, overrides, incidents, unresolved actions, and risk acceptances to escalation, remediation, retesting, approval, closure, or compensating-control evidence.\n13. Conclude whether the operating evidence supports reliance on the control set for Metadata & Lineage Management Failure, document exceptions, root-cause themes, coverage gaps, and any additional substantive or compliance testing needed.\n\nRecommended Artifacts:\n- AI dataset/source inventory.\n- data catalog entries.\n- data lineage diagrams.\n- dataflow diagrams.\n- process-flow documentation.\n- metadata standard/data dictionary.\n- dataset datasheets/model cards.\n- provenance records.\n- data acquisition/selection records.\n- transformation pipeline logs.\n- label/enrichment records.\n- quality check results.", "applicableControlIds": [ "ctl-ai-data-lineage-provenance-metadata", "ctl-ai-technical-documentation", "ctl-ai-data-drift-validation" ] }, { "id": "demo-risk-10", "originalRiskId": "risk-hallucinations-confabulation", "family": "Societal and Ethical Impact", "processName": "7. Societal & Ethical Impact", "subProcessName": "Reliability & Trust", "name": "Hallucinations (Confabulation)", "detailLevel": "full", "description": "The AI system generates or spreads incorrect, deceptive, or unsupported information that users accept as true, causing inaccurate beliefs, flawed decisions, harm, and loss of trust.", "expectedControlName": "AI output accuracy and grounding control", "expectedControlDescription": "Require deployment-like accuracy/assurance testing, grounding in approved sources where feasible, limitation and reliance-boundary disclosure, human or expert review for material outputs, postdeployment monitoring of output-quality issues, and correction/escalation of unsupported or fabricated outputs.", "expectedControlObjective": "Reduce reliance on fabricated, inaccurate, or unsupported AI outputs.", "controlSourceBasis": "Source-grounded: derived from row references (MIT AI Risk Repository 3.1; NIST AI RMF MEASURE 2.3 with adjacent 2.4, 2.5, 2.9, 3.1; Gartner AI Governance controls for accuracy/performance; MITRE Robust & Reliable/Solution Monitoring/User Trust). Control wording is an Internal Audit synthesis, not verbatim source text.", "sourcesAndReferences": "MIT AI Risk Repository: 3.1 False or misleading information; NIST AI RMF: MEASURE 2.3, 2.4, 2.5, 2.9, 3.1; Gartner: AI Governance; MITRE: Robust & Reliable / Solution Monitoring / User Trust; ISACA AI Audit Toolkit 2024 control catalog synthesis", "urlSourcesRaw": "MIT AI Risk Repository: 3.1 False or misleading information | https://airisk.mit.edu/ || \nNIST AI RMF: MEASURE 2.3, 2.4, 2.5, 2.9, 3.1 | https://www.nist.gov/itl/ai-risk-management-framework || \nGartner: AI Governance | https://www.gartner.com/en/documents/6885067 || \nMITRE: Robust & Reliable / Solution Monitoring / User Trust | https://www.mitre.org/news-insights/publication/mitre-ai-maturity-model-and-organizational-assessment-tool-guide || \nISACA AI Audit Toolkit 2024 | https://www.isaca.org/resources/news-and-trends/isaca-now-blog/2024/a-toolkit-to-facilitate-ai-governance", "sourceLinks": [ { "label": "Gartner", "url": "" }, { "label": "MITRE: Robust & Reliable", "url": "https://www.mitre.org/news-insights/publication/mitre-ai-maturity-model-and-organizational-assessment-tool-guide" }, { "label": "MIT AI Risk Rep: 3.1", "url": "https://airisk.mit.edu/" }, { "label": "NIST AI RMF: MEASURE 2.3", "url": "https://www.nist.gov/itl/ai-risk-management-framework" } ], "nistLifecycleStage": "6. Use", "lifecycle": [ "operate" ], "contexts": [ "governance", "business-audit", "dedicated-ai" ], "posture": "Direct candidate", "auditProcedureName": "Evaluate controls for Hallucinations (Confabulation)", "auditProcedureDescription": "Review how the mapped controls address Hallucinations (Confabulation). Follow the risk scenario into the relevant AI systems, use cases, models, vendors, workflows, decisions, monitoring events, and governance records, then test the control focus represented by AI output accuracy, grounding, and validation control, Meaningful human oversight gates, Automation-bias and overreliance awareness, Postdeployment AI model monitoring, AI user instructions, limitations, and explainability documentation, and AI technical documentation and audit traceability. The risk scenario is The AI system generates or spreads incorrect, deceptive, or unsupported information that users accept as true, causing inaccurate beliefs, flawed decisions, harm, and loss of trust.", "testOfDesign": "Overall test objective/purpose:\nDetermine whether the controls mapped to Hallucinations (Confabulation) are deliberately designed to address the risk scenario - The AI system generates or spreads incorrect, deceptive, or unsupported information that users accept as true, causing inaccurate beliefs, flawed decisions, harm, and loss of trust. - with explicit control criteria, ownership, evidence, escalation, and coverage across AI output accuracy, grounding, and validation control, Meaningful human oversight gates, Automation-bias and overreliance awareness, Postdeployment AI model monitoring, AI user instructions, limitations, and explainability documentation, and AI technical documentation and audit traceability.\n\nDetailed Test Steps:\n1. Map the risk scenario for Hallucinations (Confabulation) to the in-scope AI systems, use cases, models, vendors, workflows, decisions, data flows, and governance forums before judging control design.\n2. Inspect the design of each mapped control (AI output accuracy, grounding, and validation control, Meaningful human oversight gates, Automation-bias and overreliance awareness, Postdeployment AI model monitoring, AI user instructions, limitations, and explainability documentation, and AI technical documentation and audit traceability) and confirm which part of the risk scenario it prevents, detects, or corrects.\n3. Inspect accuracy/assurance criteria, deployment-like test design, ground-truth or expert-review method, RAG/approved-source grounding expectations, limitation disclosure, human-review triggers, monitoring thresholds, owner, cadence, escalation, and evidence retention.\n4. Inspect accuracy/assurance criteria, validation method, approved-source/RAG expectations, limitation disclosures, material-output review triggers, reviewer competence, monitoring thresholds, owner, cadence, escalation, and evidence-retention requirements for hallucination-prone workflows.\n5. Inspect materiality triggers, reviewer role/competence, independent evidence-check expectations, challenge/override authority, escalation paths, and retained review evidence.\n6. Inspect human/expert review triggers for hallucination-prone outputs, reviewer competence and authority, independent source/evidence-check requirements, override/escalation design, and evidence-retention requirements.\n7. Inspect training and operating guidance for hallucination risk, knowledge limits, automation/confirmation bias, independent verification, source-check expectations, target populations, frequency, knowledge checks, and escalation instructions.\n8. Inspect role-based training/guidance for AI limitations, hallucination examples, automation and confirmation bias, independent verification duties, source-check expectations, escalation routes, target populations, frequency, and evidence retention.\n9. Inspect hallucination/output-quality metrics, source/provenance failure indicators, user feedback channels, alert thresholds, ownership, review cadence, incident criteria, remediation/retest workflow, and rollback/decommission criteria.\n10. Inspect monitoring design for hallucination/error reports, factuality or output-quality metrics, RAG/source/provenance failures, feedback channels, thresholds, owner, cadence, escalation, remediation/retest, rollback/decommission, and retention.\n11. Check whether the combined design leaves any material part of Hallucinations (Confabulation) uncovered, including initiation, approval, deployment, monitoring, exception handling, remediation, and evidence retention points relevant to the risk.\n12. Walk through one representative AI system, use case, model change, approval, monitoring event, vendor dependency, or incident and trace how the mapped controls would operate together from trigger to retained evidence.\n13. Record design deficiencies such as missing thresholds, duplicated-but-unowned controls, unclear handoffs, unsupported expert judgment, bypass routes, absent evidence repositories, or controls that address adjacent risks but not Hallucinations (Confabulation).\n\nRecommended Artifacts:\n- AI use-case inventory and materiality classification.\n- accuracy/performance criteria and test plans.\n- golden datasets/ground-truth benchmarks or expert-review rubrics.\n- RAG/source configuration records where applicable.\n- model/output validation reports.\n- human/expert review logs.\n- user instructions and limitation disclosures.\n- monitoring dashboards/thresholds.\n- exception/incident/corrective-action tickets.\n- policy/training records.\n- human review matrix.\n- review checklists.", "testOfEffectiveness": "Overall test objective/purpose:\nConfirm that the mapped controls for Hallucinations (Confabulation) operated over the review period on the actual population of relevant AI systems, use cases, models, vendors, events, approvals, or decisions, and that exceptions were resolved in line with the control design.\n\nRecommended Sampling Strategy:\nUse Material AI outputs or workflows where users may rely on factual claims for decisions as the primary population and AI output, prompt-response transaction, validation scenario, review record, monitoring alert, or corrective-action ticket as the sample unit. Reconcile the population to the source system, register, workflow, ticket queue, monitoring output, or log extract. Stratify by system, business unit, model tier, lifecycle stage, vendor, region, or risk rating where operation differs. Add judgmental selections for high-risk, changed, exception, override, incident, failed-check, or near-threshold items. Use full-population analytics when the data is complete and the test criterion is deterministic.\n\nRecommended Sample Size:\nMinimum suggestion is 20 daily-or-more-frequent executions, alerts, log entries, or monitoring records after population completeness and control frequency are confirmed. Use full-population analytics where criteria are deterministic.\n\nDetailed Test Steps:\n1. Define the population for Hallucinations (Confabulation), depending on scope, this may be AI initiatives, use cases, model releases, approvals, monitoring events, incidents, exceptions, third-party AI services, access events, data changes, or governance decisions.\n2. Reconcile the population to source systems, registers, workflow queues, approval repositories, monitoring outputs, or issue logs and document the extraction parameters, dates, filters, exclusions, and completeness checks.\n3. Sample material outputs, validation scenarios, expert-review records, RAG/source configurations, monitoring alerts, user feedback, exceptions, and corrective-action tickets to verify unsupported or fabricated outputs were prevented, challenged, corrected, or escalated before reliance where required.\n4. Sample material outputs, validation runs, source/grounding configurations, human/expert reviews, monitoring alerts, feedback/error reports, exceptions, and corrective actions to verify unsupported or fabricated outputs were detected, challenged, corrected, escalated, and retained as designed.\n5. Sample material AI outputs and review records to verify required human/expert review occurred, unsupported claims were challenged, overrides/escalations were documented, and reliance decisions retained evidence.\n6. Sample material outputs/review records and verify competent reviewers performed substantive evidence checks, challenged unsupported claims, documented approvals/overrides/escalations, and retained review evidence before reliance.\n7. Sample users/reviewers and training records to verify assignment, completion, understanding checks, guidance acknowledgement, and evidence that questionable outputs were verified or escalated.\n8. Sample AI users/reviewers and verify completion, acknowledgement, knowledge-check results, recency, and evidence from quality reviews, incidents, or sampled decisions that verification/escalation behavior occurred where required.\n9. Sample monitoring periods, dashboards, alerts, user feedback, hallucination/error reports, incidents, and corrective-action tickets to verify timely review, escalation, remediation, retesting, and closure.\n10. Sample monitoring periods, alerts, feedback reports, hallucination/error tickets, source/provenance failures, incidents, and corrective actions to verify monitoring operated, exceptions were triaged, remediated/retested, escalated, closed, or risk-accepted as designed.\n11. For each selected item, test the applicable mapped controls (AI output accuracy, grounding, and validation control, Meaningful human oversight gates, Automation-bias and overreliance awareness, Postdeployment AI model monitoring, AI user instructions, limitations, and explainability documentation, and AI technical documentation and audit traceability) for evidence of performance, performer/reviewer authority, timeliness, completeness, accuracy, and direct linkage to the sampled AI system, use case, model, vendor, event, or decision.\n12. Trace exceptions, failed checks, overrides, incidents, unresolved actions, and risk acceptances to escalation, remediation, retesting, approval, closure, or compensating-control evidence.\n13. Conclude whether the operating evidence supports reliance on the control set for Hallucinations (Confabulation), document exceptions, root-cause themes, coverage gaps, and any additional substantive or compliance testing needed.\n\nRecommended Artifacts:\n- AI use-case inventory and materiality classification.\n- accuracy/performance criteria and test plans.\n- golden datasets/ground-truth benchmarks or expert-review rubrics.\n- RAG/source configuration records where applicable.\n- model/output validation reports.\n- human/expert review logs.\n- user instructions and limitation disclosures.\n- monitoring dashboards/thresholds.\n- exception/incident/corrective-action tickets.\n- policy/training records.\n- human review matrix.\n- review checklists.", "applicableControlIds": [ "ctl-ai-output-accuracy-grounding-validation", "ctl-ai-human-oversight-gates", "ctl-ai-overreliance-awareness", "ctl-ai-postdeployment-model-monitoring", "ctl-ai-user-instructions-explainability", "ctl-ai-technical-documentation" ] } ], "controls": [ { "controlId": "ctl-ai-accountability-raci-decision-rights", "title": "AI accountability, RACI, and decision-rights control", "objective": "Make AI ownership, decision accountability, and control responsibility explicit, communicated, and testable for material AI systems.", "description": "Define, approve, communicate, and maintain accountable owners, responsible parties, consulted/informed stakeholders, escalation paths, and decision rights for material AI systems across business decisions, technical/model operation, AI risk management, data quality, human oversight, vendor management, control execution, monitoring, and issue remediation.", "controlFamily": "governance-and-accountability", "sourceLabels": [ "ISACA AAIA Review Manual: Chapter 3.1 AI asset identification guidance per workbook row; Chapter 03 Part A - Audit Planning and Design", "ISO/IEC 42001: A.3.2; 5.3; B.3.2; A.3", "NIST AI RMF 1.0: GOVERN 2.1; GOVERN 2.3; GOVERN 2", "Gartner: AI Governance; Risk Management; AI Decision Rights; AI Organization", "MITRE: AI Maturity Model; Org Structure / Governance Structure; definitions of Governance, Governance Structure, Strategy & Resources, Structure" ], "auditProcedure": { "auditProcedureName": "Analyze AI accountability, RACI, and decision-rights control", "auditProcedureDescription": "Trace the control for AI accountability, RACI, and decision-rights control from the event, decision, or cadence that triggers it through execution, review, exception handling, and retained evidence. Use the control objective as the reference point. Make AI ownership, decision accountability, and control responsibility explicit, communicated, and testable for material AI systems. Confirm that the described control activity is performed through clear criteria, accountable ownership, defined timing, complete population coverage, reliable source records, and evidence that exceptions are escalated and resolved. Where the control relies on automated monitoring, workflow approval, or manual expert review, verify that handoffs and evidence repositories are clear enough for repeatable audit testing. The work should cover the activity defined for the control. Define, approve, communicate, and maintain accountable owners, responsible parties, consulted/informed stakeholders, escalation paths, and decision rights for material AI systems across business decisions, technical/model operation, AI risk management, data quality, human oversight, vendor management, control execution, monitoring, and issue remediation.", "testOfDesign": { "overallTestObjectivePurpose": "Determine whether AI accountability, RACI, and decision-rights control is designed with criteria, ownership, timing, evidence, and exception handling precise enough to achieve the objective. Make AI ownership, decision accountability, and control responsibility explicit, communicated, and testable for material AI systems.", "detailedTestSteps": [ "Inspect the AI governance charter/operating model, RACI/decision-rights matrix, role descriptions, AI inventory owner fields, committee/function delegation, escalation paths, and policy/procedure language to verify coverage of material AI lifecycle domains and.", "Inspect the AI governance charter/operating model, RACI/decision-rights matrix, role descriptions, AI inventory owner fields, committee/function delegation, escalation paths, and policy/procedure language to verify that AI risk-management responsibilities, lifecycle owner roles, communication lines, executive accountability, decision authority, and escalation/reporting paths are assigned and communicated for material AI systems.", "Inspect the documented AI accountability, RACI, and decision-rights control policy, standard, workflow, configuration, checklist, approval template, or procedure and trace each required element to the stated control objective.", "Confirm that the AI accountability, RACI, and decision-rights control design names the accountable owner (AI governance lead or accountable executive/committee, with business system owner, technology/model owner, data owner, risk/compliance owner, vendor owner, and control owner participation.) and expected performance cadence (At AI system intake/approval and material lifecycle changes, periodic governance review at least annually or per AI policy cadence. Exact frequency not source-stated, mark as organization-defined if implemented.), including reviewer, delegate, and escalation responsibilities where applicable.", "Check that the design defines the in-scope population (Material AI systems/use cases in scope of the AI management system or AI governance framework.), sampling unit (AI system/use case, approval decision, governance committee item, escalation/issue record, or owner-field record in the AI inventory.), and process/system boundary (governance-and-accountability process boundary) so testing can be repeated by another auditor.", "Walk through one representative control occurrence, AI lifecycle event, approval, change, exception, or monitoring record covered by AI accountability, RACI, and decision-rights control. Trace it from trigger through decision, escalation, and evidence retention and identify where the control prevents, detects, or corrects the targeted risk.", "Challenge whether bypasses, undocumented judgment, missing thresholds, unclear reviewer authority, weak segregation, or absent retention rules could prevent AI accountability, RACI, and decision-rights control from operating consistently." ], "recommendedArtifacts": [ "AI governance charter / operating model.", "AI policy and standards.", "RACI / decision-rights matrix.", "AI system/use-case inventory with owner fields.", "role descriptions / org chart / directory.", "AI governance board or committee terms of reference and minutes.", "approval workflows and sign-offs.", "escalation/issue tickets.", "risk assessment records with owners.", "AI impact assessment ownership." ] }, "testOfEffectiveness": { "overallTestObjectivePurpose": "Confirm that AI accountability, RACI, and decision-rights control operated during the review period in line with its documented criteria, ownership, frequency, evidence requirements, and exception path.", "recommendedSamplingStrategy": "Use Material AI systems/use cases in scope of the AI management system or AI governance framework. as the primary population and AI system/use case, approval decision, governance committee item, escalation/issue record, or owner-field record in the AI inventory. as the sample unit. Reconcile the population to the source system, register, workflow, ticket queue, monitoring output, or log extract. Stratify by system, business unit, model tier, lifecycle stage, vendor, region, or risk rating where operation differs. Add judgmental selections for high-risk, changed, exception, override, incident, failed-check, or near-threshold items. Use full-population analytics when the data is complete and the test criterion is deterministic.", "recommendedSampleSize": "Minimum suggestion is the annual execution plus interim changes, exceptions, approvals, and triggering events relevant to the control. Annual controls do not have a fixed standard sample size in the matrix.", "detailedTestSteps": [ "Build the population for AI accountability, RACI, and decision-rights control from the system, workflow, register, log, or approval repository that records control execution. Document extraction parameters, date range, filters, and completeness reconciliation.", "Verify the control design or operating evidence addresses the requirement in practical terms, For a sample of material AI systems/use cases, verify that named accountable owners and responsible parties exist, decision rights are documented and used in approvals, governance/escalation records show accountable review, owner fields are maintained in inventories or workflow tools, exceptions/issues are routed to defined owners, and evidence exists for business/model/data/vendor/control/human-oversight responsibilities.", "For each selected item, verify the control was performed by the expected owner or reviewer, at the required point in the process, against the defined criteria, and before the AI decision, release, approval, use, or event proceeded where the design requires prior control execution.", "Compare retained evidence to the control design and confirm completeness, accuracy, reviewer sign-off, timestamps, linkage to the AI system/use case/model/vendor/event, and consistency with the required cadence.", "Trace exceptions, overrides, failed checks, late reviews, unresolved actions, and risk acceptances to escalation, remediation, approval, retesting, or closure evidence." ], "recommendedArtifacts": [ "AI governance charter / operating model.", "AI policy and standards.", "RACI / decision-rights matrix.", "AI system/use-case inventory with owner fields.", "role descriptions / org chart / directory.", "AI governance board or committee terms of reference and minutes.", "approval workflows and sign-offs.", "escalation/issue tickets.", "risk assessment records with owners.", "AI impact assessment ownership." ] } }, "expectedEvidenceArtifacts": [ "AI governance charter / operating model", "AI policy and standards", "RACI / decision-rights matrix", "AI system/use-case inventory with owner fields", "role descriptions / org chart / directory", "AI governance board or committee terms of reference and minutes", "approval workflows and sign-offs", "escalation/issue tickets", "risk assessment records with owners", "AI impact assessment ownership", "vendor due-diligence/accountability records", "human-oversight procedures and reviewer assignment records", "training/communication evidence for assigned roles", "periodic review records" ] }, { "controlId": "ctl-ai-adversarial-input-and-prompt-injection-defense", "title": "Adversarial input and prompt-injection defense control", "objective": "Reduce the likelihood and impact of hostile or manipulated inputs overriding AI instructions, bypassing safeguards, exposing data, misclassifying content, or triggering unauthorized actions.", "description": "Design, test, monitor, and improve defenses against prompt injection and input manipulation, including input/output validation, instruction hierarchy hardening, untrusted-content segregation, retrieval/tool isolation, least-privilege tool execution, human approval for high-risk actions, adversarial/stress testing, monitoring, and response procedures.", "controlFamily": "ai-security-and-adversarial-robustness", "sourceLabels": [ "ISACA AAIA Review Manual: Chapter 03 Part A, Figure 3.1 common AI control types", "ISO/IEC 5338: 6.4.3", "NIST AI RMF Playbook: MEASURE 2.6", "NIST AI RMF 1.0: MEASURE 2.6; MEASURE 2.7; MANAGE 2.3; MANAGE 2.4; MANAGE 4.1", "Gartner: AI Governance", "OWASP: LLM01; Machine Learning Security Top Ten; ML01", "ISO/IEC AI lifecycle standard", "NIST AI Risk Management Framework" ], "auditProcedure": { "auditProcedureName": "Validate Adversarial input and prompt-injection defense control", "auditProcedureDescription": "Trace the control for Adversarial input and prompt-injection defense control from the event, decision, or cadence that triggers it through execution, review, exception handling, and retained evidence. Use the control objective as the reference point. Reduce the likelihood and impact of hostile or manipulated inputs overriding AI instructions, bypassing safeguards, exposing data, misclassifying content, or triggering unauthorized actions. Confirm that the described control activity is performed through clear criteria, accountable ownership, defined timing, complete population coverage, reliable source records, and evidence that exceptions are escalated and resolved. Where the control relies on automated monitoring, workflow approval, or manual expert review, verify that handoffs and evidence repositories are clear enough for repeatable audit testing. The work should cover the activity defined for the control. Design, test, monitor, and improve defenses against prompt injection and input manipulation, including input/output validation, instruction hierarchy hardening, untrusted-content segregation, retrieval/tool isolation, least-privilege tool execution, human approval for high-risk actions, adversarial/stress testing, monitoring, and response procedures.", "testOfDesign": { "overallTestObjectivePurpose": "Determine whether Adversarial input and prompt-injection defense control is designed with criteria, ownership, timing, evidence, and exception handling precise enough to achieve the objective. Reduce the likelihood and impact of hostile or manipulated inputs overriding AI instructions, bypassing safeguards, exposing data, misclassifying content, or triggering unauthorized actions.", "detailedTestSteps": [ "Inspect whether the AI system\u2019s design includes explicit prompt-injection/input-manipulation threat scenarios, input/output validation, system prompt and instruction hierarchy controls, external/RAG content segregation, tool/API permission boundaries, human approval for privileged actions, monitoring/incident procedures, owner/frequency/risk tolerance, and test protocols.", "Inspect the documented Adversarial input and prompt-injection defense control policy, standard, workflow, configuration, checklist, approval template, or procedure and trace each required element to the stated control objective.", "Confirm that the Adversarial input and prompt-injection defense control design names the accountable owner (AI product/system owner with application security, MLOps/platform engineering, data science/model owner, security operations, and AI governance oversight.) and expected performance cadence (At design/release/change gates and periodically postdeployment, monitoring continuous where tooling supports it, adversarial retesting after material model/prompt/RAG/tool/configuration changes.), including reviewer, delegate, and escalation responsibilities where applicable.", "Check that the design defines the in-scope population (AI systems or components that accept user-controlled, third-party, retrieved, multimodal, or tool-triggering inputs, releases/configurations/prompts/RAG indexes/tool integrations exposed to such inputs.), sampling unit (AI system/release, prompt/configuration version, RAG corpus update, tool integration, adversarial test case, monitoring alert, incident/exception ticket, high-risk tool-action approval.), and process/system boundary (ai-security-and-adversarial-robustness process boundary) so testing can be repeated by another auditor.", "Walk through one representative control occurrence, AI lifecycle event, approval, change, exception, or monitoring record covered by Adversarial input and prompt-injection defense control. Trace it from trigger through decision, escalation, and evidence retention and identify where the control prevents, detects, or corrects the targeted risk.", "Challenge whether bypasses, undocumented judgment, missing thresholds, unclear reviewer authority, weak segregation, or absent retention rules could prevent Adversarial input and prompt-injection defense control from operating consistently." ], "recommendedArtifacts": [ "AI threat model / misuse case register.", "prompt-injection and input-manipulation test cases.", "guardrail/prompt/security configuration records.", "input/output validation rules.", "RAG/untrusted-content segregation design.", "tool/API permission matrix.", "human approval workflow logs.", "test execution reports and red-team results.", "monitoring dashboards/logs.", "incident/exception tickets." ] }, "testOfEffectiveness": { "overallTestObjectivePurpose": "Confirm that Adversarial input and prompt-injection defense control operated during the review period in line with its documented criteria, ownership, frequency, evidence requirements, and exception path.", "recommendedSamplingStrategy": "Use AI systems or components that accept user-controlled, third-party, retrieved, multimodal, or tool-triggering inputs as the primary population and AI system/release, prompt/configuration version, RAG corpus update, tool integration, adversarial test case, monitoring alert, incident/exception ticket, high-risk tool-action approval. as the sample unit. Reconcile the population to the source system, register, workflow, ticket queue, monitoring output, or log extract. Stratify by system, business unit, model tier, lifecycle stage, vendor, region, or risk rating where operation differs. Add judgmental selections for high-risk, changed, exception, override, incident, failed-check, or near-threshold items. Use full-population analytics when the data is complete and the test criterion is deterministic.", "recommendedSampleSize": "Minimum suggestion is 20 daily-or-more-frequent executions, alerts, log entries, or monitoring records after population completeness and control frequency are confirmed. Use full-population analytics where criteria are deterministic.", "detailedTestSteps": [ "Build the population for Adversarial input and prompt-injection defense control from the system, workflow, register, log, or approval repository that records control execution. Document extraction parameters, date range, filters, and completeness reconciliation.", "Sample deployed AI systems or releases exposed to user/external inputs, verify adversarial and prompt-injection tests were executed, inspect validation/guardrail logs, tool-call approval records, monitoring alerts, incident/exception tickets, remediation actions, and retesting evidence, confirm failures or bypasses were escalated and corrected within defined thresholds.", "For each selected item, verify the control was performed by the expected owner or reviewer, at the required point in the process, against the defined criteria, and before the AI decision, release, approval, use, or event proceeded where the design requires prior control execution.", "Compare retained evidence to the control design and confirm completeness, accuracy, reviewer sign-off, timestamps, linkage to the AI system/use case/model/vendor/event, and consistency with the required cadence.", "Trace exceptions, overrides, failed checks, late reviews, unresolved actions, and risk acceptances to escalation, remediation, approval, retesting, or closure evidence." ], "recommendedArtifacts": [ "AI threat model / misuse case register.", "prompt-injection and input-manipulation test cases.", "guardrail/prompt/security configuration records.", "input/output validation rules.", "RAG/untrusted-content segregation design.", "tool/API permission matrix.", "human approval workflow logs.", "test execution reports and red-team results.", "monitoring dashboards/logs.", "incident/exception tickets." ] } }, "expectedEvidenceArtifacts": [ "AI threat model / misuse case register", "prompt-injection and input-manipulation test cases", "guardrail/prompt/security configuration records", "input/output validation rules", "RAG/untrusted-content segregation design", "tool/API permission matrix", "human approval workflow logs", "test execution reports and red-team results", "monitoring dashboards/logs", "incident/exception tickets", "remediation/retest evidence", "user/admin secure-use guidance", "training/awareness records where applicable" ] }, { "controlId": "ctl-ai-change-impact-assessment", "title": "AI change impact assessment and approval", "objective": "Ensure AI changes are assessed, authorized, tested, and reassessed before production impact.", "description": "Route model, data, prompt, configuration, vendor, integration, documentation, and control changes through impact assessment, approval, testing, rollback planning, and post-change monitoring.", "controlFamily": "change-and-configuration-management", "sourceLabels": [ "ISACA AI Audit Toolkit 2024: (AI Model Management; Change-Driven Conformity Assessment); AL-MV-09; MG-MM-04", "ISACA AAIA Review Manual: Figure 3.1 common AI controls; Types of AI Controls; Ch.03 Part A", "ISO/IEC 42001: 6.3; 8.1; 8.2; 8.4; A.6.2", "ISO/IEC 5338: 6.4.12; 6.4.14; 6.4.15; 6.4.16; AI life-cycle transition, operation, maintenance, continuous validation", "NIST AI RMF Playbook: MANAGE 2.4; MANAGE 4.1; MANAGE 4.2", "NIST AI RMF 1.0: MANAGE 4.1; MANAGE 4.2; MANAGE 3.1", "Gartner: Deployment Strategy; AI Engineering; ModelOps; AI Engineering / ModelOps", "OWASP: LLM Top 10 2023-24; LLM07", "EU AI Act: Article 20; Article 25; Article 6" ], "auditProcedure": { "auditProcedureName": "Test AI change impact assessment and approval", "auditProcedureDescription": "Trace the control for AI change impact assessment and approval from the event, decision, or cadence that triggers it through execution, review, exception handling, and retained evidence. Use the control objective as the reference point. Ensure AI changes are assessed, authorized, tested, and reassessed before production impact. Confirm that the described control activity is performed through clear criteria, accountable ownership, defined timing, complete population coverage, reliable source records, and evidence that exceptions are escalated and resolved. Where the control relies on automated monitoring, workflow approval, or manual expert review, verify that handoffs and evidence repositories are clear enough for repeatable audit testing. The work should cover the activity defined for the control. Route model, data, prompt, configuration, vendor, integration, documentation, and control changes through impact assessment, approval, testing, rollback planning, and post-change monitoring.", "testOfDesign": { "overallTestObjectivePurpose": "Determine whether AI change impact assessment and approval is designed with criteria, ownership, timing, evidence, and exception handling precise enough to achieve the objective. Ensure AI changes are assessed, authorized, tested, and reassessed before production impact.", "detailedTestSteps": [ "Inspect whether AI change-impact procedures include user/workflow impact and adoption-readiness considerations or explicitly link to the new adoption-feedback control.", "Inspect whether AI change procedures require workforce-impact triggers to route to the primary workforce impact and transition planning control.", "Inspect whether AI change governance includes a trigger or addendum for cultural/human-contribution impacts when the change alters creative/professional work or human-AI role allocation.", "Inspect whether promotion-to-production is classified as a material AI change/release requiring impact assessment, testing, rollback and approval.", "Inspect whether AI tool/plugin enablement and permission changes are in the AI change standard with required impact assessment, security testing, rollback, monitoring, and approval criteria.", "Inspect the documented AI change impact assessment and approval policy, standard, workflow, configuration, checklist, approval template, or procedure and trace each required element to the stated control objective.", "Confirm that the AI change impact assessment and approval design names the accountable owner (AI system owner / change manager / business process owner.) and expected performance cadence (Per material AI change.), including reviewer, delegate, and escalation responsibilities where applicable.", "Check that the design defines the in-scope population (AI material changes and AI-enabled workflow changes.), sampling unit (AI change record.), and process/system boundary (change-and-configuration-management process boundary) so testing can be repeated by another auditor.", "Walk through one representative control occurrence, AI lifecycle event, approval, change, exception, or monitoring record covered by AI change impact assessment and approval. Trace it from trigger through decision, escalation, and evidence retention and identify where the control prevents, detects, or corrects the targeted risk.", "Challenge whether bypasses, undocumented judgment, missing thresholds, unclear reviewer authority, weak segregation, or absent retention rules could prevent AI change impact assessment and approval from operating consistently." ], "recommendedArtifacts": [ "change impact assessment.", "approval record.", "test plan/results.", "rollback plan.", "post-change monitoring record.", "AI change impact assessment.", "approval records.", "testing/rollback evidence.", "post-change monitoring.", "linkage to workforce impact assessment where applicable." ] }, "testOfEffectiveness": { "overallTestObjectivePurpose": "Confirm that AI change impact assessment and approval operated during the review period in line with its documented criteria, ownership, frequency, evidence requirements, and exception path.", "recommendedSamplingStrategy": "Use AI material changes and AI-enabled workflow changes. as the primary population and AI change record. as the sample unit. Reconcile the population to the source system, register, workflow, ticket queue, monitoring output, or log extract. Stratify by system, business unit, model tier, lifecycle stage, vendor, region, or risk rating where operation differs. Add judgmental selections for high-risk, changed, exception, override, incident, failed-check, or near-threshold items. Use full-population analytics when the data is complete and the test criterion is deterministic.", "recommendedSampleSize": "Minimum suggestion is 20 event records where the event population supports sampling. If fewer events exist, test the full population and include high-risk approvals, overrides, incidents, material model changes, and exceptions.", "detailedTestSteps": [ "Build the population for AI change impact assessment and approval from the system, workflow, register, log, or approval repository that records control execution. Document extraction parameters, date range, filters, and completeness reconciliation.", "Sample AI change records affecting users and test whether impact assessment, approval, testing/rollback, and post-change monitoring evidence exists., For sampled AI changes with workforce impact, verify the change record linked to a workforce impact assessment and mitigation plan before approval.", "Sample material AI changes and verify change-impact assessment and approval evidence, where cultural-devaluation triggers exist, verify linkage to the primary human contribution/dignity safeguard.", "Sample pilot-to-production releases and verify change impact assessment, approval, test evidence, rollback plan and post-change monitoring occurred.", "Sample recent AI tool/plugin integration changes and verify impact assessment, approval, security testing, permission review, rollback plan, and post-change monitoring evidence.", "Sample drift-triggered changes/retraining/recalibration events and verify impact assessment, approval, test evidence, rollback/retirement decision, and post-change monitoring.", "For each selected item, verify the control was performed by the expected owner or reviewer, at the required point in the process, against the defined criteria, and before the AI decision, release, approval, use, or event proceeded where the design requires prior control execution.", "Compare retained evidence to the control design and confirm completeness, accuracy, reviewer sign-off, timestamps, linkage to the AI system/use case/model/vendor/event, and consistency with the required cadence.", "Trace exceptions, overrides, failed checks, late reviews, unresolved actions, and risk acceptances to escalation, remediation, approval, retesting, or closure evidence." ], "recommendedArtifacts": [ "change impact assessment.", "approval record.", "test plan/results.", "rollback plan.", "post-change monitoring record.", "AI change impact assessment.", "approval records.", "testing/rollback evidence.", "post-change monitoring.", "linkage to workforce impact assessment where applicable." ] } }, "expectedEvidenceArtifacts": [ "change impact assessment", "approval record", "test plan/results", "rollback plan", "post-change monitoring record", "AI change impact assessment", "approval records", "testing/rollback evidence", "post-change monitoring", "linkage to workforce impact assessment where applicable", "AI change request", "testing and rollback evidence", "human contribution/dignity review addendum", "change tickets", "impact assessments", "release approvals", "test results", "rollback plans", "post-change review records", "approvals", "security test evidence", "post-change monitoring evidence", "change impact assessments", "test/revalidation evidence", "post-change monitoring outputs", "model version history", "AI change management policy/procedure/standard", "AI configuration item taxonomy", "change requests and tickets", "impact/risk/conformity assessment checklists", "approval/rejection records", "test/validation results", "release records", "rollback plans and rollback execution records", "post-change monitoring reports", "emergency-change logs", "exception/risk acceptance records", "test reports" ] }, { "controlId": "ctl-ai-contract-obligations", "title": "AI-specific contract and notification obligations", "objective": "Ensure AI supplier contracts preserve permitted-use, audit/evidence, transparency, incident, change, subcontractor, conformity, and regulatory obligation rights.", "description": "Include and monitor AI-specific contractual terms covering permitted data/model use, opt-out or prohibition of customer data training where required, IP/licensing/warranty/indemnity expectations, audit/evidence rights, transparency documentation, incident and infringement notification, subcontractors, supplier model/service changes, and applicable provider/deployer responsibility splits.", "controlFamily": "third-party-and-supply-chain", "sourceLabels": [ "ISACA AI Audit Toolkit 2024: (External Components & Supply Chain Governance; related ES-TC controls where high-risk conformity applies; AI Licensing Compliance)", "ISACA AAIA Review Manual: Data Licensing; Collection, Use, and Disclosure; Data Consent / Data Licensing; Figure 3.1", "ISO/IEC 42001: B.10; B.10.2; B.10.3; B.10.4", "NIST AI RMF Playbook: GOVERN 6.1; GOVERN 6; MAP 4.1; MAP 4", "Gartner: Define decision rights for AI; AI Governance", "OWASP: LLM Top 10 2023/2024; LLM05", "EU AI Act: Article 25; Article 26; Article 53", "AI Security Overview: AI supplier IP/licensing mitigations", "AI Security Overview: AI supplier IP/licensing mitigations; Mitigating Risk" ], "auditProcedure": { "auditProcedureName": "Review AI-specific contract and notification obligations", "auditProcedureDescription": "Trace the control for AI-specific contract and notification obligations from the event, decision, or cadence that triggers it through execution, review, exception handling, and retained evidence. Use the control objective as the reference point. Ensure AI supplier contracts preserve permitted-use, audit/evidence, transparency, incident, change, subcontractor, conformity, and regulatory obligation rights. Confirm that the described control activity is performed through clear criteria, accountable ownership, defined timing, complete population coverage, reliable source records, and evidence that exceptions are escalated and resolved. Where the control relies on automated monitoring, workflow approval, or manual expert review, verify that handoffs and evidence repositories are clear enough for repeatable audit testing. The work should cover the activity defined for the control. Include and monitor AI-specific contractual terms covering permitted data/model use, opt-out or prohibition of customer data training where required, IP/licensing/warranty/indemnity expectations, audit/evidence rights, transparency documentation, incident and infringement notification, subcontractors, supplier model/service changes, and applicable provider/deployer responsibility splits.", "testOfDesign": { "overallTestObjectivePurpose": "Determine whether AI-specific contract and notification obligations is designed with criteria, ownership, timing, evidence, and exception handling precise enough to achieve the objective. Ensure AI supplier contracts preserve permitted-use, audit/evidence, transparency, incident, change, subcontractor, conformity, and regulatory obligation rights.", "detailedTestSteps": [ "Inspect AI contract playbook/templates, procurement/legal review checklist, minimum required AI clauses, regulatory/conformity/evidence rights, notification/change/subcontractor/IP/data-use terms, responsibility matrix, and exception approval process.", "Inspect standard AI contract clauses/templates and procurement/legal review procedures to verify IP/licensing, permitted-use, output-rights, change-notification and audit-right requirements are built into third-party AI onboarding.", "Inspect contract standards/templates for AI model/data/IP use restrictions, audit/evidence rights, incident/change notification and subcontractor requirements.", "Inspect AI vendor/DPA/data-use clause templates for permitted AI use, training/fine-tuning/product-improvement restrictions, consent dependency, retention/deletion, audit/evidence rights, and change/incident notice obligations.", "Inspect the documented AI-specific contract and notification obligations policy, standard, workflow, configuration, checklist, approval template, or procedure and trace each required element to the stated control objective.", "Confirm that the AI-specific contract and notification obligations design names the accountable owner (Legal/Procurement/Third-Party Risk with AI governance, Security, Privacy, and business/system owner input) and expected performance cadence (At procurement/renewal/amendment, event-driven on supplier policy/model/service/material change, periodic contract compliance review for high-risk suppliers), including reviewer, delegate, and escalation responsibilities where applicable.", "Check that the design defines the in-scope population (All contracts, amendments, terms-of-service approvals, DPAs, licensing agreements, and supplier attestations for AI vendors/components/data/models/APIs/plugins.), sampling unit (AI supplier contract or contract amendment/terms acceptance record.), and process/system boundary (third-party-and-supply-chain process boundary) so testing can be repeated by another auditor.", "Walk through one representative control occurrence, AI lifecycle event, approval, change, exception, or monitoring record covered by AI-specific contract and notification obligations. Trace it from trigger through decision, escalation, and evidence retention and identify where the control prevents, detects, or corrects the targeted risk.", "Challenge whether bypasses, undocumented judgment, missing thresholds, unclear reviewer authority, weak segregation, or absent retention rules could prevent AI-specific contract and notification obligations from operating consistently." ], "recommendedArtifacts": [ "AI contract clause library.", "supplier contract/amendment.", "legal/procurement review checklist.", "data-use/training-use terms.", "IP/licensing/warranty/indemnity terms.", "audit/evidence rights clause.", "incident/infringement notification clause.", "subcontractor approval clause.", "supplier change notice records.", "contract exception approvals." ] }, "testOfEffectiveness": { "overallTestObjectivePurpose": "Confirm that AI-specific contract and notification obligations operated during the review period in line with its documented criteria, ownership, frequency, evidence requirements, and exception path.", "recommendedSamplingStrategy": "Use All contracts, amendments, terms-of-service approvals, DPAs, licensing agreements, and supplier attestations for AI vendors/components/data/models/APIs/plugins. as the primary population and AI supplier contract or contract amendment/terms acceptance record. as the sample unit. Reconcile the population to the source system, register, workflow, ticket queue, monitoring output, or log extract. Stratify by system, business unit, model tier, lifecycle stage, vendor, region, or risk rating where operation differs. Add judgmental selections for high-risk, changed, exception, override, incident, failed-check, or near-threshold items. Use full-population analytics when the data is complete and the test criterion is deterministic.", "recommendedSampleSize": "Minimum suggestion is 20 daily-or-more-frequent executions, alerts, log entries, or monitoring records after population completeness and control frequency are confirmed. Use full-population analytics where criteria are deterministic.", "detailedTestSteps": [ "Build the population for AI-specific contract and notification obligations from the system, workflow, register, log, or approval repository that records control execution. Document extraction parameters, date range, filters, and completeness reconciliation.", "Sample AI supplier contracts/amendments and test whether required AI clauses are present or exceptions approved, supplier changes/incidents were notified per terms, evidence/audit rights were used when needed, and permitted data/model-use restrictions align with policy.", "Sample third-party AI supplier/model/API contracts and terms reviews to verify required clauses or documented compensating approvals exist before use.", "Sample AI vendor/co-development contracts and verify clauses exist and exceptions/change notices/incidents were tracked.", "Sample AI vendors and data-sharing arrangements to verify contract terms existed before data transfer/use, vendor settings matched permitted-use terms, and retention/deletion or no-training commitments were evidenced.", "For each selected item, verify the control was performed by the expected owner or reviewer, at the required point in the process, against the defined criteria, and before the AI decision, release, approval, use, or event proceeded where the design requires prior control execution.", "Compare retained evidence to the control design and confirm completeness, accuracy, reviewer sign-off, timestamps, linkage to the AI system/use case/model/vendor/event, and consistency with the required cadence.", "Trace exceptions, overrides, failed checks, late reviews, unresolved actions, and risk acceptances to escalation, remediation, approval, retesting, or closure evidence." ], "recommendedArtifacts": [ "AI contract clause library.", "supplier contract/amendment.", "legal/procurement review checklist.", "data-use/training-use terms.", "IP/licensing/warranty/indemnity terms.", "audit/evidence rights clause.", "incident/infringement notification clause.", "subcontractor approval clause.", "supplier change notice records.", "contract exception approvals." ] } }, "expectedEvidenceArtifacts": [ "AI contract clause library", "supplier contract/amendment", "legal/procurement review checklist", "data-use/training-use terms", "IP/licensing/warranty/indemnity terms", "audit/evidence rights clause", "incident/infringement notification clause", "subcontractor approval clause", "supplier change notice records", "contract exception approvals", "AI contract addendum", "supplier terms/EULA assessment", "procurement approval package", "legal review sign-off", "supplier model/service change notice", "exception/risk acceptance record", "contract templates", "executed vendor contracts", "DPA/security addenda", "IP/confidentiality clauses", "change/incident notices", "contracts", "DPAs", "AI addenda", "vendor settings/screenshots", "data-sharing approvals", "supplier attestations", "deletion certificates", "contract review checklist" ] }, { "controlId": "ctl-ai-data-drift-validation", "title": "Data quality, drift, and validation issue remediation", "objective": "Detect and remediate data, model, and configuration drift that could invalidate AI outputs or controls.", "description": "Operate input validation, completeness and consistency checks, data-quality remediation, model/data drift monitoring, configuration drift monitoring, and change-triggered retesting.", "controlFamily": "monitoring-and-validation", "sourceLabels": [ "ISACA AI Audit Toolkit 2024: AL-MT-19; OP-PM-04; OP-PM-05; Input Validation controls", "ISACA AAIA Review Manual: Chapter 03 Part A; AI risk monitoring; Audit Planning and Design; Chapter 01 AI Governance and", "ISO/IEC 42001: A.7.4; A.7.6", "ISO/IEC 5338: 5.1; 5.3; 6.4.14; 6.4.8", "NIST AI RMF Playbook: MAP 2.3; MEASURE 2.2; MEASURE 2.11; MEASURE 3.1", "NIST AI RMF 1.0: MANAGE 4.1; MANAGE 4.2", "Gartner: AI Data Guide; Data Delivery and Insights for AI; ModelOps; End-to-End Management", "MITRE: AI Maturity Model; Solution Monitoring", "MIT AI Risk Repository: risk repository method; Causal and domain taxonomy", "OWASP: ML Top 10; ML02; ML08", "EU AI Act: Article 15; Article 26; Article 72" ], "auditProcedure": { "auditProcedureName": "Review Data quality, drift, and validation issue remediation", "auditProcedureDescription": "Trace the control for Data quality, drift, and validation issue remediation from the event, decision, or cadence that triggers it through execution, review, exception handling, and retained evidence. Use the control objective as the reference point. Detect and remediate data, model, and configuration drift that could invalidate AI outputs or controls. Confirm that the described control activity is performed through clear criteria, accountable ownership, defined timing, complete population coverage, reliable source records, and evidence that exceptions are escalated and resolved. Where the control relies on automated monitoring, workflow approval, or manual expert review, verify that handoffs and evidence repositories are clear enough for repeatable audit testing. The work should cover the activity defined for the control. Operate input validation, completeness and consistency checks, data-quality remediation, model/data drift monitoring, configuration drift monitoring, and change-triggered retesting.", "testOfDesign": { "overallTestObjectivePurpose": "Determine whether Data quality, drift, and validation issue remediation is designed with criteria, ownership, timing, evidence, and exception handling precise enough to achieve the objective. Detect and remediate data, model, and configuration drift that could invalidate AI outputs or controls.", "detailedTestSteps": [ "Inspect monitoring design for data quality/drift thresholds, data issue ownership, escalation/remediation workflow, and retesting triggers tied to contextual data fitness assumptions.", "Inspect whether lineage/provenance control design defines monitoring triggers, data-quality checks, drift/configuration-change triggers, remediation ownership, and update obligations for metadata/lineage records.", "Inspect whether AI data/model monitoring design defines in-scope systems/datasets, owner, refresh cadence/triggers, data quality rules, drift/degradation indicators, synthetic-data provenance/limits, thresholds, review cadence, remediation workflow, retesting triggers, and retention expectations.", "Inspect the model/data drift monitoring standard, deployed-model inventory, metric catalogue, thresholds/tolerances, owner/RACI, monitoring frequency, alert-to-triage workflow, investigation criteria, retraining/recalibration/rollback/decommissioning triggers, and evidence retention requirements.", "Inspect data/model/configuration validation standards, metric/threshold definitions, dataset monitoring/update procedures, input-validation requirements, retraining/retesting criteria, ownership, and linkage to change/incident/corrective-action workflows.", "Inspect the documented Data quality, drift, and validation issue remediation policy, standard, workflow, configuration, checklist, approval template, or procedure and trace each required element to the stated control objective.", "Confirm that the Data quality, drift, and validation issue remediation design names the accountable owner (AI/ML Operations, Data Governance, model owner, data steward) and expected performance cadence (Ongoing or batch cadence based on model criticality/data volatility, reassessment after material change), including reviewer, delegate, and escalation responsibilities where applicable.", "Check that the design defines the in-scope population (Monitoring runs, data-quality alerts, drift events, and AI data-source changes), sampling unit (Alert/event/ticket or monitoring period), and process/system boundary (monitoring-and-validation process boundary) so testing can be repeated by another auditor.", "Walk through one representative control occurrence, AI lifecycle event, approval, change, exception, or monitoring record covered by Data quality, drift, and validation issue remediation. Trace it from trigger through decision, escalation, and evidence retention and identify where the control prevents, detects, or corrects the targeted risk.", "Challenge whether bypasses, undocumented judgment, missing thresholds, unclear reviewer authority, weak segregation, or absent retention rules could prevent Data quality, drift, and validation issue remediation from operating consistently." ], "recommendedArtifacts": [ "data-quality monitoring dashboard.", "drift monitoring output.", "threshold/alert configuration.", "data issue tickets.", "remediation records.", "change-triggered retest evidence.", "exception approvals.", "data-quality rule definitions.", "drift monitoring outputs.", "data validation logs." ] }, "testOfEffectiveness": { "overallTestObjectivePurpose": "Confirm that Data quality, drift, and validation issue remediation operated during the review period in line with its documented criteria, ownership, frequency, evidence requirements, and exception path.", "recommendedSamplingStrategy": "Use Monitoring runs, data-quality alerts, drift events, and AI data-source changes as the primary population and Alert/event/ticket or monitoring period as the sample unit. Reconcile the population to the source system, register, workflow, ticket queue, monitoring output, or log extract. Stratify by system, business unit, model tier, lifecycle stage, vendor, region, or risk rating where operation differs. Add judgmental selections for high-risk, changed, exception, override, incident, failed-check, or near-threshold items. Use full-population analytics when the data is complete and the test criterion is deterministic.", "recommendedSampleSize": "Minimum suggestion is 20 daily-or-more-frequent executions, alerts, log entries, or monitoring records after population completeness and control frequency are confirmed. Use full-population analytics where criteria are deterministic.", "detailedTestSteps": [ "Build the population for Data quality, drift, and validation issue remediation from the system, workflow, register, log, or approval repository that records control execution. Document extraction parameters, date range, filters, and completeness reconciliation.", "Sample monitoring periods, alerts, data quality failures, drift events, and change-triggered retests to verify issues were detected, triaged, remediated, approved, and retained.", "Sample data-quality/drift/configuration events and verify lineage/provenance records were updated, root-cause/impact analysis used lineage, remediation tickets were closed or risk accepted, and retesting evidence was retained.", "Sample in-scope AI systems/datasets and test whether refresh reviews, data-quality checks, drift/degradation monitoring outputs, synthetic-data validation checks, source degradation reviews, alerts/exceptions, retesting evidence, and remediation tickets occurred as designed during the audit period., For sampled deployed AI models or monitoring periods, verify dashboards/logs captured input, output, data-distribution and performance metrics, alerts were generated when thresholds were breached, anomalies were triaged, corrective action/retesting/retraining/rollback/decommissioning evidence exists, and unresolved exceptions were escalated.", "Sample monitoring periods, data-quality checks, drift alerts, input-validation failures, retraining or dataset-update events, and change-triggered retests to verify controls operated and exceptions were resolved or risk-accepted.", "Sample anomaly/data-quality alerts and verify triage, remediation, retesting and closure evidence.", "For each selected item, verify the control was performed by the expected owner or reviewer, at the required point in the process, against the defined criteria, and before the AI decision, release, approval, use, or event proceeded where the design requires prior control execution.", "Compare retained evidence to the control design and confirm completeness, accuracy, reviewer sign-off, timestamps, linkage to the AI system/use case/model/vendor/event, and consistency with the required cadence.", "Trace exceptions, overrides, failed checks, late reviews, unresolved actions, and risk acceptances to escalation, remediation, approval, retesting, or closure evidence." ], "recommendedArtifacts": [ "data-quality monitoring dashboard.", "drift monitoring output.", "threshold/alert configuration.", "data issue tickets.", "remediation records.", "change-triggered retest evidence.", "exception approvals.", "data-quality rule definitions.", "drift monitoring outputs.", "data validation logs." ] } }, "expectedEvidenceArtifacts": [ "data-quality monitoring dashboard", "drift monitoring output", "threshold/alert configuration", "data issue tickets", "remediation records", "change-triggered retest evidence", "exception approvals", "data-quality rule definitions", "drift monitoring outputs", "data validation logs", "configuration drift alerts", "pipeline quality checks", "lineage impact analysis", "remediation tickets", "change-triggered retesting evidence", "exception/risk acceptance records", "AI system/dataset inventory", "data-readiness plan", "data refresh schedule/criteria", "data quality framework/rules", "data observability dashboards", "drift/degradation monitoring dashboards", "synthetic data provenance and validation records", "model/data compatibility monitoring outputs", "alert logs", "threshold definitions", "retesting records", "decommissioning or rollback records where tolerance exceeded", "deployed AI/model inventory", "drift/performance metric catalogue", "threshold/tolerance definitions", "monitoring dashboards and logs", "alert records", "incident/anomaly tickets", "root-cause analyses", "retesting and validation reports", "retraining/recalibration records", "rollback/decommissioning approvals", "feedback records", "change records", "model cards or technical documentation", "data validation protocols", "data-quality rules and reports", "input validation procedures", "training/inference dataset lineage and update logs", "drift dashboards and monitoring outputs", "validation logs", "retraining schedules and trigger analyses", "retesting reports", "data/model/config remediation tickets", "anomaly reports", "security testing reports for input validation", "data-quality reports", "anomaly dashboards", "validation reports", "data quality rules", "dataset documentation", "representativeness analysis", "proxy-feature review", "drift dashboards" ] }, { "controlId": "ctl-ai-data-lineage-provenance-metadata", "title": "AI data lineage, provenance, and metadata control", "objective": "Make data used by material AI systems traceable, explainable, reproducible, and auditable across collection, preparation, use, change, and retirement.", "description": "Define and operate a lifecycle process to record data origin, acquisition/selection rationale, transformations, ownership, data quality checks, labels/enrichment, update/retirement status, lineage flows, dependencies, and metadata for datasets used to develop, test, validate, deploy, or operate material AI systems.", "controlFamily": "data-governance-and-lineage", "sourceLabels": [ "ISACA AAIA Review Manual: Ch. 03 Part A; Documentation; Types of AI Controls; Inventory/Data Gathering", "ISO/IEC 42001: A.7.5; A.7; B.4.3", "ISO/IEC 5338: 6.4.8", "NIST AI RMF Playbook: MAP 2.3", "Gartner: AI Data Guide", "EU AI Act: Article 10" ], "auditProcedure": { "auditProcedureName": "Analyze AI data lineage, provenance, and metadata control", "auditProcedureDescription": "Trace the control for AI data lineage, provenance, and metadata control from the event, decision, or cadence that triggers it through execution, review, exception handling, and retained evidence. Use the control objective as the reference point. Make data used by material AI systems traceable, explainable, reproducible, and auditable across collection, preparation, use, change, and retirement. Confirm that the described control activity is performed through clear criteria, accountable ownership, defined timing, complete population coverage, reliable source records, and evidence that exceptions are escalated and resolved. Where the control relies on automated monitoring, workflow approval, or manual expert review, verify that handoffs and evidence repositories are clear enough for repeatable audit testing. The work should cover the activity defined for the control. Define and operate a lifecycle process to record data origin, acquisition/selection rationale, transformations, ownership, data quality checks, labels/enrichment, update/retirement status, lineage flows, dependencies, and metadata for datasets used to develop, test, validate, deploy, or operate material AI systems.", "testOfDesign": { "overallTestObjectivePurpose": "Determine whether AI data lineage, provenance, and metadata control is designed with criteria, ownership, timing, evidence, and exception handling precise enough to achieve the objective. Make data used by material AI systems traceable, explainable, reproducible, and auditable across collection, preparation, use, change, and retirement.", "detailedTestSteps": [ "Inspect data governance/AI lifecycle procedures, metadata standards, lineage/provenance requirements, required fields, ownership, lifecycle trigger points, exception rules, retention expectations, and tool/process integration.", "Inspect the documented AI data lineage, provenance, and metadata control policy, standard, workflow, configuration, checklist, approval template, or procedure and trace each required element to the stated control objective.", "Confirm that the AI data lineage, provenance, and metadata control design names the accountable owner (Data Governance/Data Steward with AI system owner, ML/MLOps owner, Model Risk/AI Governance, Privacy/Compliance contributors) and expected performance cadence (At onboarding/approval, before deployment, after material data/model/pipeline changes, and periodic review for material AI systems), including reviewer, delegate, and escalation responsibilities where applicable.", "Check that the design defines the in-scope population (Datasets, data sources, feature/retrieval stores, data pipelines, and model/system versions used by material AI systems), sampling unit (AI system-to-dataset mapping, dataset record, pipeline/transformation run, lineage artifact, or data change ticket), and process/system boundary (data-governance-and-lineage process boundary) so testing can be repeated by another auditor.", "Walk through one representative control occurrence, AI lifecycle event, approval, change, exception, or monitoring record covered by AI data lineage, provenance, and metadata control. Trace it from trigger through decision, escalation, and evidence retention and identify where the control prevents, detects, or corrects the targeted risk.", "Challenge whether bypasses, undocumented judgment, missing thresholds, unclear reviewer authority, weak segregation, or absent retention rules could prevent AI data lineage, provenance, and metadata control from operating consistently." ], "recommendedArtifacts": [ "AI dataset/source inventory.", "data catalog entries.", "data lineage diagrams.", "dataflow diagrams.", "process-flow documentation.", "metadata standard/data dictionary.", "dataset datasheets/model cards.", "provenance records.", "data acquisition/selection records.", "transformation pipeline logs." ] }, "testOfEffectiveness": { "overallTestObjectivePurpose": "Confirm that AI data lineage, provenance, and metadata control operated during the review period in line with its documented criteria, ownership, frequency, evidence requirements, and exception path.", "recommendedSamplingStrategy": "Use Datasets, data sources, feature/retrieval stores, data pipelines, and model/system versions used by material AI systems as the primary population and AI system-to-dataset mapping, dataset record, pipeline/transformation run, lineage artifact, or data change ticket as the sample unit. Reconcile the population to the source system, register, workflow, ticket queue, monitoring output, or log extract. Stratify by system, business unit, model tier, lifecycle stage, vendor, region, or risk rating where operation differs. Add judgmental selections for high-risk, changed, exception, override, incident, failed-check, or near-threshold items. Use full-population analytics when the data is complete and the test criterion is deterministic.", "recommendedSampleSize": "Minimum suggestion is 20 daily-or-more-frequent executions, alerts, log entries, or monitoring records after population completeness and control frequency are confirmed. Use full-population analytics where criteria are deterministic.", "detailedTestSteps": [ "Build the population for AI data lineage, provenance, and metadata control from the system, workflow, register, log, or approval repository that records control execution. Document extraction parameters, date range, filters, and completeness reconciliation.", "Sample material AI systems/datasets and verify lineage/provenance records show source, owner, intended use, acquisition/selection rationale, transformations, labels/enrichment, quality checks, version/model dependencies, update dates, change history, issue traceability, approvals, and retained evidence.", "For each selected item, verify the control was performed by the expected owner or reviewer, at the required point in the process, against the defined criteria, and before the AI decision, release, approval, use, or event proceeded where the design requires prior control execution.", "Compare retained evidence to the control design and confirm completeness, accuracy, reviewer sign-off, timestamps, linkage to the AI system/use case/model/vendor/event, and consistency with the required cadence.", "Trace exceptions, overrides, failed checks, late reviews, unresolved actions, and risk acceptances to escalation, remediation, approval, retesting, or closure evidence." ], "recommendedArtifacts": [ "AI dataset/source inventory.", "data catalog entries.", "data lineage diagrams.", "dataflow diagrams.", "process-flow documentation.", "metadata standard/data dictionary.", "dataset datasheets/model cards.", "provenance records.", "data acquisition/selection records.", "transformation pipeline logs." ] } }, "expectedEvidenceArtifacts": [ "AI dataset/source inventory", "data catalog entries", "data lineage diagrams", "dataflow diagrams", "process-flow documentation", "metadata standard/data dictionary", "dataset datasheets/model cards", "provenance records", "data acquisition/selection records", "transformation pipeline logs", "label/enrichment records", "quality check results", "issue/remediation tickets", "owner/steward approvals", "change records", "retention/retirement evidence" ] }, { "controlId": "ctl-ai-governance-framework-management-system", "title": "AI governance framework and management system", "objective": "Provide a coherent, documented, accountable, risk-based management system for governing AI obligations, risks, controls, lifecycle activities, and reporting across the organization.", "description": "Establish, implement, maintain, periodically review, and continually improve an AI governance framework covering mandate and scope, AI policy, roles and decision rights, risk appetite/tolerance, AI inventory and classification, lifecycle controls, legal/regulatory obligation management, impact/risk assessment, third-party responsibilities, monitoring, incidents/concerns, exceptions, and management/governance reporting.", "controlFamily": "governance-and-accountability", "sourceLabels": [ "ISACA AAIA Review Manual: Chapter 03 Part A; Documentation; Types of AI Controls; Inventory Objectives and Procedures", "ISO/IEC 42001: 4.4; A.2; A.3; 5.2; 5.3; 6.1.2; 6.1.3; 6.1.4", "NIST AI RMF 1.0: GOVERN 1.1; GOVERN 2.1", "Gartner: AI literacy; Gain buy-in; Set up board; Oversight Systems", "MITRE: AI Maturity Model; Structure; Governance; Governance Structure", "EU AI Act: Article 16; Article 17; Article 9" ], "auditProcedure": { "auditProcedureName": "Evaluate AI governance framework and management system", "auditProcedureDescription": "Trace the control for AI governance framework and management system from the event, decision, or cadence that triggers it through execution, review, exception handling, and retained evidence. Use the control objective as the reference point. Provide a coherent, documented, accountable, risk-based management system for governing AI obligations, risks, controls, lifecycle activities, and reporting across the organization. Confirm that the described control activity is performed through clear criteria, accountable ownership, defined timing, complete population coverage, reliable source records, and evidence that exceptions are escalated and resolved. Where the control relies on automated monitoring, workflow approval, or manual expert review, verify that handoffs and evidence repositories are clear enough for repeatable audit testing. The work should cover the activity defined for the control. Establish, implement, maintain, periodically review, and continually improve an AI governance framework covering mandate and scope, AI policy, roles and decision rights, risk appetite/tolerance, AI inventory and classification, lifecycle controls, legal/regulatory obligation management, impact/risk assessment, third-party responsibilities, monitoring, incidents/concerns, exceptions, and management/governance reporting.", "testOfDesign": { "overallTestObjectivePurpose": "Determine whether AI governance framework and management system is designed with criteria, ownership, timing, evidence, and exception handling precise enough to achieve the objective. Provide a coherent, documented, accountable, risk-based management system for governing AI obligations, risks, controls, lifecycle activities, and reporting across the organization.", "detailedTestSteps": [ "Inspect whether the AI governance framework is formally documented and approved, defines scope/mandate, policy, objectives, risk tolerance, RACI/decision rights, inventory/classification, lifecycle gates, risk/impact assessment, legal obligations, third-party responsibilities, monitoring, incident/concern reporting, exceptions, management review, frequency, evidence retention, and.", "Inspect the documented AI governance framework and management system policy, standard, workflow, configuration, checklist, approval template, or procedure and trace each required element to the stated control objective.", "Confirm that the AI governance framework and management system design names the accountable owner (Executive/top management accountable, operational owner likely AI governance lead, AI governance committee, enterprise risk/compliance, or CIO/CDO depending on operating model.) and expected performance cadence (Framework and policy reviewed at planned intervals and when material organizational, legal, technical, or AI-use changes occur, AI inventory at least annually with event-driven updates for material changes.), including reviewer, delegate, and escalation responsibilities where applicable.", "Check that the design defines the in-scope population (All AI systems/use cases within the AI governance framework scope, governance artifacts, assessments, exceptions, incidents, third-party AI services, and management-review cycles in the audit period.), sampling unit (AI use case/system record, governance decision, risk/impact assessment, lifecycle gate approval, exception/incident/concern, committee or management-review meeting.), and process/system boundary (governance-and-accountability process boundary) so testing can be repeated by another auditor.", "Walk through one representative control occurrence, AI lifecycle event, approval, change, exception, or monitoring record covered by AI governance framework and management system. Trace it from trigger through decision, escalation, and evidence retention and identify where the control prevents, detects, or corrects the targeted risk.", "Challenge whether bypasses, undocumented judgment, missing thresholds, unclear reviewer authority, weak segregation, or absent retention rules could prevent AI governance framework and management system from operating consistently." ], "recommendedArtifacts": [ "AI governance charter/committee mandate.", "AI policy and standards.", "RACI/decision-rights matrix.", "AI risk appetite/tolerance statement.", "AI inventory/register/model catalog.", "classification criteria and approvals.", "risk assessment and treatment records.", "impact assessment records.", "lifecycle gate checklists and approvals.", "legal/regulatory obligation map." ] }, "testOfEffectiveness": { "overallTestObjectivePurpose": "Confirm that AI governance framework and management system operated during the review period in line with its documented criteria, ownership, frequency, evidence requirements, and exception path.", "recommendedSamplingStrategy": "Use All AI systems/use cases within the AI governance framework scope as the primary population and AI use case/system record as the sample unit. Reconcile the population to the source system, register, workflow, ticket queue, monitoring output, or log extract. Stratify by system, business unit, model tier, lifecycle stage, vendor, region, or risk rating where operation differs. Add judgmental selections for high-risk, changed, exception, override, incident, failed-check, or near-threshold items. Use full-population analytics when the data is complete and the test criterion is deterministic.", "recommendedSampleSize": "Minimum suggestion is the annual execution plus interim changes, exceptions, approvals, and triggering events relevant to the control. Annual controls do not have a fixed standard sample size in the matrix.", "detailedTestSteps": [ "Build the population for AI governance framework and management system from the system, workflow, register, log, or approval repository that records control execution. Document extraction parameters, date range, filters, and completeness reconciliation.", "Select a period and sample AI use cases/systems, governance meetings, risk assessments, impact assessments, policy exceptions, incidents/concerns, and management-review cycles, verify the framework was applied, records retained, exceptions escalated, actions tracked to closure, and periodic reviews completed according to defined cadence.", "For each selected item, verify the control was performed by the expected owner or reviewer, at the required point in the process, against the defined criteria, and before the AI decision, release, approval, use, or event proceeded where the design requires prior control execution.", "Compare retained evidence to the control design and confirm completeness, accuracy, reviewer sign-off, timestamps, linkage to the AI system/use case/model/vendor/event, and consistency with the required cadence.", "Trace exceptions, overrides, failed checks, late reviews, unresolved actions, and risk acceptances to escalation, remediation, approval, retesting, or closure evidence." ], "recommendedArtifacts": [ "AI governance charter/committee mandate.", "AI policy and standards.", "RACI/decision-rights matrix.", "AI risk appetite/tolerance statement.", "AI inventory/register/model catalog.", "classification criteria and approvals.", "risk assessment and treatment records.", "impact assessment records.", "lifecycle gate checklists and approvals.", "legal/regulatory obligation map." ] } }, "expectedEvidenceArtifacts": [ "AI governance charter/committee mandate", "AI policy and standards", "RACI/decision-rights matrix", "AI risk appetite/tolerance statement", "AI inventory/register/model catalog", "classification criteria and approvals", "risk assessment and treatment records", "impact assessment records", "lifecycle gate checklists and approvals", "legal/regulatory obligation map", "third-party responsibility matrix", "monitoring/compliance dashboards", "incident/concern/exception logs", "governance meeting minutes", "management review records", "corrective-action tracker", "training/awareness records" ] }, { "controlId": "ctl-ai-human-oversight-gates", "title": "Meaningful human oversight gates", "objective": "Preserve competent human review, challenge, override, and escalation before AI-supported decisions materially affect people, processes, or obligations.", "description": "Define risk-tiered human review gates with competent and authorized reviewers, independent evidence checks, challenge/override authority, escalation paths, and retained evidence showing that human oversight is substantive rather than a rubber-stamp approval.", "controlFamily": "human-ai-interaction", "sourceLabels": [ "ISACA AI Audit Toolkit 2024: (Human Oversight Mechanism HI-HM-05); Human-AI Interaction & Experience controls; Human-AI Interaction controls", "ISACA AAIA Review Manual: Human in the Loop", "NIST AI RMF 1.0: MAP 2.2; MAP 3.5; MEASURE 2.8; MANAGE 4.1", "Gartner: AI Governance / Risk Essentials; KRIs; stakeholder questions; AI Governance Risk Essentials", "MIT AI Risk Repository: 5.1; 5.2; 5.1, 5.2; Domain Taxonomy", "OWASP: Agentic AI; Agentic Security Initiative", "EU AI Act: Article 14; Article 26(2), Recital 73", "Berkeley Agentic AI Risk Profile: Risk-Management Levers; Agentic AI Risk Profile - human control and accountability", "AIGP: AIGP Episode 5 extension; AIGP Episode 34 extension; derived governance principle: Meaningful Human Oversight; source knowledge base / AIGP-derived governance principle", "Berkeley CLTC / Agentic AI Profile" ], "auditProcedure": { "auditProcedureName": "Test Meaningful human oversight gates", "auditProcedureDescription": "Trace the control for Meaningful human oversight gates from the event, decision, or cadence that triggers it through execution, review, exception handling, and retained evidence. Use the control objective as the reference point. Preserve competent human review, challenge, override, and escalation before AI-supported decisions materially affect people, processes, or obligations. Confirm that the described control activity is performed through clear criteria, accountable ownership, defined timing, complete population coverage, reliable source records, and evidence that exceptions are escalated and resolved. Where the control relies on automated monitoring, workflow approval, or manual expert review, verify that handoffs and evidence repositories are clear enough for repeatable audit testing. The work should cover the activity defined for the control. Define risk-tiered human review gates with competent and authorized reviewers, independent evidence checks, challenge/override authority, escalation paths, and retained evidence showing that human oversight is substantive rather than a rubber-stamp approval.", "testOfDesign": { "overallTestObjectivePurpose": "Determine whether Meaningful human oversight gates is designed with criteria, ownership, timing, evidence, and exception handling precise enough to achieve the objective. Preserve competent human review, challenge, override, and escalation before AI-supported decisions materially affect people, processes, or obligations.", "detailedTestSteps": [ "Inspect whether human oversight gates require competent domain/scientific reviewers and substantive independent evidence checks for this risk class.", "Inspect oversight policy/procedure, risk-tier criteria for when human review is required, reviewer role/authority/competency requirements, required evidence checks, override/escalation design, logging/evidence-retention requirements, and.", "Inspect human-review criteria, challenge authority, escalation paths, reviewer competency, and evidence requirements for AI outputs susceptible to sycophancy.", "Inspect oversight gate criteria, role authority, competence, escalation/override design, and evidence requirements.", "Inspect review threshold criteria, reviewer roles/competence, approval authority, escalation path, and evidence retention.", "Inspect the documented Meaningful human oversight gates policy, standard, workflow, configuration, checklist, approval template, or procedure and trace each required element to the stated control objective.", "Confirm that the Meaningful human oversight gates design names the accountable owner (AI governance owner / domain SME / model risk owner) and expected performance cadence (At approval gates and material changes), including reviewer, delegate, and escalation responsibilities where applicable.", "Check that the design defines the in-scope population (AI decisions/use cases requiring human challenge), sampling unit (Review gate or approval record), and process/system boundary (human-ai-interaction process boundary) so testing can be repeated by another auditor.", "Walk through one representative control occurrence, AI lifecycle event, approval, change, exception, or monitoring record covered by Meaningful human oversight gates. Trace it from trigger through decision, escalation, and evidence retention and identify where the control prevents, detects, or corrects the targeted risk.", "Challenge whether bypasses, undocumented judgment, missing thresholds, unclear reviewer authority, weak segregation, or absent retention rules could prevent Meaningful human oversight gates from operating consistently." ], "recommendedArtifacts": [ "human review matrix.", "review checklists.", "expert sign-offs.", "override/escalation records.", "reviewer competence evidence.", "human oversight policy/procedure.", "risk-tiered human review matrix.", "reviewer RACI/authorization record.", "reviewer training/competency records.", "decision review checklist." ] }, "testOfEffectiveness": { "overallTestObjectivePurpose": "Confirm that Meaningful human oversight gates operated during the review period in line with its documented criteria, ownership, frequency, evidence requirements, and exception path.", "recommendedSamplingStrategy": "Use AI decisions/use cases requiring human challenge as the primary population and Review gate or approval record as the sample unit. Reconcile the population to the source system, register, workflow, ticket queue, monitoring output, or log extract. Stratify by system, business unit, model tier, lifecycle stage, vendor, region, or risk rating where operation differs. Add judgmental selections for high-risk, changed, exception, override, incident, failed-check, or near-threshold items. Use full-population analytics when the data is complete and the test criterion is deterministic.", "recommendedSampleSize": "Minimum suggestion is 20 event records where the event population supports sampling. If fewer events exist, test the full population and include high-risk approvals, overrides, incidents, material model changes, and exceptions.", "detailedTestSteps": [ "Build the population for Meaningful human oversight gates from the system, workflow, register, log, or approval repository that records control execution. Document extraction parameters, date range, filters, and completeness reconciliation.", "Sample scientific-validity approvals and verify reviewers performed substantive challenge rather than rubber-stamp sign-off.", "Sample AI-supported decisions in scope and test whether required human review occurred, reviewers had required competence/authority, independent evidence was checked, overrides/escalations were recorded where applicable, and challenge activity was substantive rather than perfunctory.", "Sample reviewed AI interactions and exception records to verify reviewers challenged unsupported agreement and escalated/remediated issues.", "Sample AI-supported decisions and verify reviewers had explanation/context, challenged outputs where needed, and retained review/override evidence.", "Sample AI-assisted content requiring review and test whether review was substantive, evidenced, and timely.", "For each selected item, verify the control was performed by the expected owner or reviewer, at the required point in the process, against the defined criteria, and before the AI decision, release, approval, use, or event proceeded where the design requires prior control execution.", "Compare retained evidence to the control design and confirm completeness, accuracy, reviewer sign-off, timestamps, linkage to the AI system/use case/model/vendor/event, and consistency with the required cadence.", "Trace exceptions, overrides, failed checks, late reviews, unresolved actions, and risk acceptances to escalation, remediation, approval, retesting, or closure evidence." ], "recommendedArtifacts": [ "human review matrix.", "review checklists.", "expert sign-offs.", "override/escalation records.", "reviewer competence evidence.", "human oversight policy/procedure.", "risk-tiered human review matrix.", "reviewer RACI/authorization record.", "reviewer training/competency records.", "decision review checklist." ] } }, "expectedEvidenceArtifacts": [ "human review matrix", "review checklists", "expert sign-offs", "override/escalation records", "reviewer competence evidence", "human oversight policy/procedure", "risk-tiered human review matrix", "reviewer RACI/authorization record", "reviewer training/competency records", "decision review checklist", "independent evidence reviewed", "override/escalation logs", "oversight mechanism design document", "system oversight logs", "exception and remediation records", "review records", "reviewer training/competence evidence", "review/approval records", "override logs", "escalation tickets", "competence/training records", "review matrix", "approval tickets", "review comments/checklists", "escalation records", "reviewer training evidence", "training records", "override records", "decision review workpapers", "approval matrix", "workflow approvals", "approval workflows", "human oversight matrix", "approval workflow logs", "reviewer competence records", "exception tickets", "approval workflow rules", "reviewer matrix", "high-risk action tickets", "privileged execution approvals", "exception records" ] }, { "controlId": "ctl-ai-impact-conformity-trigger", "title": "AI impact assessment and conformity trigger control", "objective": "Trigger required impact, conformity, and reassessment activities before deployment or material change.", "description": "Apply a standalone trigger control so AI deployments, accelerations, or material changes cannot bypass required impact, privacy/fundamental-rights, conformity, registration, reassessment, specialist-routing, and approval decisions.", "controlFamily": "risk-management", "sourceLabels": [ "ISACA AI Audit Toolkit 2024: AL-MV-09; Business Impact and Risk / AI Model Governance; Business Impact and Risk; Aggregate AI Control Library", "ISACA AAIA Review Manual: DPIA/privacy regulation considerations; Figure 3.1; AI Risk and Impact Assessments / DPIA; Fundamental Rights Impact Assessment (FRIA)", "ISO/IEC 42001: 8.2; 8.4; A.5.2; A.5.5; B.5.2; B.5.5; AI system impact assessment", "NIST AI RMF Playbook: MAP 1.1; GOVERN 1.3; MEASURE 2.10", "NIST AI RMF 1.0: GOVERN 1.2; MAP 1.5; MAP 2.2", "EU AI Act: Annex III; Article 16; Article 6" ], "auditProcedure": { "auditProcedureName": "Analyze AI impact assessment and conformity trigger control", "auditProcedureDescription": "Trace the control for AI impact assessment and conformity trigger control from the event, decision, or cadence that triggers it through execution, review, exception handling, and retained evidence. Use the control objective as the reference point. Trigger required impact, conformity, and reassessment activities before deployment or material change. Confirm that the described control activity is performed through clear criteria, accountable ownership, defined timing, complete population coverage, reliable source records, and evidence that exceptions are escalated and resolved. Where the control relies on automated monitoring, workflow approval, or manual expert review, verify that handoffs and evidence repositories are clear enough for repeatable audit testing. The work should cover the activity defined for the control. Apply a standalone trigger control so AI deployments, accelerations, or material changes cannot bypass required impact, privacy/fundamental-rights, conformity, registration, reassessment, specialist-routing, and approval decisions.", "testOfDesign": { "overallTestObjectivePurpose": "Determine whether AI impact assessment and conformity trigger control is designed with criteria, ownership, timing, evidence, and exception handling precise enough to achieve the objective. Trigger required impact, conformity, and reassessment activities before deployment or material change.", "detailedTestSteps": [ "Inspect whether impact/conformity trigger criteria explicitly apply to accelerated releases, material changes, and high-pressure deployments.", "Inspect trigger matrix/procedure, definitions of material/significant change, privacy/fundamental-rights/conformity applicability criteria, specialist routing rules, approval gates, evidence-retention requirements, and linkage to AI inventory/classification records.", "Inspect trigger logic for sensitive data, PII, new technologies, public-facing AI outputs, model/data/retrieval changes, and elevated inference risk, verify ownership, required approvers, documentation, and links to the AI inventory.", "Inspect trigger matrix/applicability rules for societal-impact assessment triggers and linkage to change/deployment approval.", "Inspect whether the impact-assessment trigger matrix explicitly includes environmental/resource-impact triggers and material AI lifecycle changes.", "Inspect the documented AI impact assessment and conformity trigger control policy, standard, workflow, configuration, checklist, approval template, or procedure and trace each required element to the stated control objective.", "Confirm that the AI impact assessment and conformity trigger control design names the accountable owner (AI governance/risk owner, legal/compliance, privacy, business use-case owner) and expected performance cadence (Per deployment, material change, or risk-triggering acceleration), including reviewer, delegate, and escalation responsibilities where applicable.", "Check that the design defines the in-scope population (AI deployments/material changes/accelerations during the audit period), sampling unit (AI deployment or material-change record), and process/system boundary (risk-management process boundary) so testing can be repeated by another auditor.", "Walk through one representative control occurrence, AI lifecycle event, approval, change, exception, or monitoring record covered by AI impact assessment and conformity trigger control. Trace it from trigger through decision, escalation, and evidence retention and identify where the control prevents, detects, or corrects the targeted risk.", "Challenge whether bypasses, undocumented judgment, missing thresholds, unclear reviewer authority, weak segregation, or absent retention rules could prevent AI impact assessment and conformity trigger control from operating consistently." ], "recommendedArtifacts": [ "impact assessment trigger matrix.", "risk classification record.", "DPIA/FRIA/conformity assessment.", "reassessment log.", "approval workflow record.", "exception register.", "trigger matrix.", "completed impact assessments.", "FRIA/DPIA assessments or applicability decisions.", "conformity/significant-change assessment records." ] }, "testOfEffectiveness": { "overallTestObjectivePurpose": "Confirm that AI impact assessment and conformity trigger control operated during the review period in line with its documented criteria, ownership, frequency, evidence requirements, and exception path.", "recommendedSamplingStrategy": "Use AI deployments/material changes/accelerations during the audit period as the primary population and AI deployment or material-change record as the sample unit. Reconcile the population to the source system, register, workflow, ticket queue, monitoring output, or log extract. Stratify by system, business unit, model tier, lifecycle stage, vendor, region, or risk rating where operation differs. Add judgmental selections for high-risk, changed, exception, override, incident, failed-check, or near-threshold items. Use full-population analytics when the data is complete and the test criterion is deterministic.", "recommendedSampleSize": "Minimum suggestion is 20 event records where the event population supports sampling. If fewer events exist, test the full population and include high-risk approvals, overrides, incidents, material model changes, and exceptions.", "detailedTestSteps": [ "Build the population for AI impact assessment and conformity trigger control from the system, workflow, register, log, or approval repository that records control execution. Document extraction parameters, date range, filters, and completeness reconciliation.", "Sample accelerated or competitive-pressure AI releases and test whether impact/conformity trigger determinations and required assessments occurred before approval or go-live.", "Sample AI deployments and material changes, verify trigger assessment was completed, specialist reviews occurred when criteria were met, FRIA/DPIA/conformity/registration decisions were documented, approvals preceded deployment/change, and exceptions or missed triggers were escalated/remediated.", "Sample AI systems or material changes involving sensitive data and verify DPIA/privacy review or impact assessment was completed before deployment/change approval and exceptions were documented.", "Sample material AI deployments/changes and verify trigger decisions and required societal assessments occurred before approval.", "Sample material AI deployments/changes and verify the trigger was applied and sustainability assessment or approval evidence exists.", "For each selected item, verify the control was performed by the expected owner or reviewer, at the required point in the process, against the defined criteria, and before the AI decision, release, approval, use, or event proceeded where the design requires prior control execution.", "Compare retained evidence to the control design and confirm completeness, accuracy, reviewer sign-off, timestamps, linkage to the AI system/use case/model/vendor/event, and consistency with the required cadence.", "Trace exceptions, overrides, failed checks, late reviews, unresolved actions, and risk acceptances to escalation, remediation, approval, retesting, or closure evidence." ], "recommendedArtifacts": [ "impact assessment trigger matrix.", "risk classification record.", "DPIA/FRIA/conformity assessment.", "reassessment log.", "approval workflow record.", "exception register.", "trigger matrix.", "completed impact assessments.", "FRIA/DPIA assessments or applicability decisions.", "conformity/significant-change assessment records." ] } }, "expectedEvidenceArtifacts": [ "impact assessment trigger matrix", "risk classification record", "DPIA/FRIA/conformity assessment", "reassessment log", "approval workflow record", "exception register", "trigger matrix", "completed impact assessments", "FRIA/DPIA assessments or applicability decisions", "conformity/significant-change assessment records", "legal/privacy/compliance review sign-offs", "deployment gate approvals", "change tickets", "registration/public-database applicability records", "reassessment logs", "exception/escalation records", "DPIA/privacy impact assessment", "AI impact assessment", "approval records", "risk acceptance records", "reassessment evidence", "applicability assessment", "impact assessments", "approval/reassessment records", "DPIA records", "FRIA applicability assessment", "legal/privacy approval", "reassessment history" ] }, { "controlId": "ctl-ai-incident-notification", "title": "AI incident, serious-event, and failure notification", "objective": "Escalate and report AI incidents, serious events, material failures, and required notifications to appropriate stakeholders.", "description": "Define AI incident classification, escalation, regulator/customer/internal notification requirements, serious-event reporting, root-cause review, corrective action, and evidence retention.", "controlFamily": "incident-and-disclosure-management", "sourceLabels": [ "ISACA AI Audit Toolkit 2024: AI incident notification", "ISACA AAIA Review Manual: AI Incident Response Management; Ch.01; Figure 3.1 AI incident management", "ISO/IEC 42001: A.8.3; A.8.4; A.8.5; A.6.2; A.8", "NIST AI RMF Playbook: GOVERN 4.3; MANAGE 2.3; MANAGE 2.4; MANAGE 4.1; MANAGE 3.1", "NIST AI 600-1 / GenAI Profile: GV-1.5-001; GV-2.1-001; GOVERN 1.5; GOVERN 2.1; incident response and deactivation escalation; Information Integrity", "NIST AI RMF 1.0: MANAGE 4.1; MANAGE 4.3", "Gartner: AI governance / Risk Essentials; AI Governance / Risk Essentials; Risk Essentials - AI Governance", "OWASP: GenAI Security Project; LLM01; LLM10", "EU AI Act: Article 20; Article 55; Article 73 paragraphs 1-6", "OECD: AI incidents/risk governance; common reporting framework; AI and Incidents / OECD AI Incidents Monitor: Key Messages", "AI Incident Database: AIID / incident evidence base; homepage/current incident listings; incident-learning source", "AI incident evidence database" ], "auditProcedure": { "auditProcedureName": "Review AI incident, serious-event, and failure notification", "auditProcedureDescription": "Trace the control for AI incident, serious-event, and failure notification from the event, decision, or cadence that triggers it through execution, review, exception handling, and retained evidence. Use the control objective as the reference point. Escalate and report AI incidents, serious events, material failures, and required notifications to appropriate stakeholders. Confirm that the described control activity is performed through clear criteria, accountable ownership, defined timing, complete population coverage, reliable source records, and evidence that exceptions are escalated and resolved. Where the control relies on automated monitoring, workflow approval, or manual expert review, verify that handoffs and evidence repositories are clear enough for repeatable audit testing. The work should cover the activity defined for the control. Define AI incident classification, escalation, regulator/customer/internal notification requirements, serious-event reporting, root-cause review, corrective action, and evidence retention.", "testOfDesign": { "overallTestObjectivePurpose": "Determine whether AI incident, serious-event, and failure notification is designed with criteria, ownership, timing, evidence, and exception handling precise enough to achieve the objective. Escalate and report AI incidents, serious events, material failures, and required notifications to appropriate stakeholders.", "detailedTestSteps": [ "Inspect AI incident/vulnerability taxonomy and escalation design to confirm tool/plugin misuse, unauthorized action, data exfiltration, privilege escalation, and third-party vulnerability events are in scope.", "Inspect the AI incident response standard/runbook for AI incident definitions, severity thresholds, detection/observability sources, reporting channels, response-team composition, RACI/authority, containment/eradication/recovery steps, communication/notification matrix, forensic evidence requirements, tabletop/testing cadence, RCA/CAPA workflow, and integration with enterprise incident/problem management.", "Inspect whether incident procedures explicitly require preservation and retrieval of AI logs/model/data evidence for investigation and RCA.", "Inspect whether prompt-injection/input manipulation events are included in AI incident taxonomy and response playbooks.", "Inspect incident thresholds and response runbooks for data/model poisoning scenarios.", "Inspect the documented AI incident, serious-event, and failure notification policy, standard, workflow, configuration, checklist, approval template, or procedure and trace each required element to the stated control objective.", "Confirm that the AI incident, serious-event, and failure notification design names the accountable owner (Security incident response/SOC with AI product owner, legal/privacy/compliance, and third-party risk as needed.) and expected performance cadence (Event-driven, periodic incident trend review.), including reviewer, delegate, and escalation responsibilities where applicable.", "Check that the design defines the in-scope population (AI tool/plugin incidents, suspected misuse, vulnerabilities, unauthorized actions, data exfiltration or privilege events.), sampling unit (Incident, alert, vulnerability report, corrective action ticket.), and process/system boundary (incident-and-disclosure-management process boundary) so testing can be repeated by another auditor.", "Walk through one representative control occurrence, AI lifecycle event, approval, change, exception, or monitoring record covered by AI incident, serious-event, and failure notification. Trace it from trigger through decision, escalation, and evidence retention and identify where the control prevents, detects, or corrects the targeted risk.", "Challenge whether bypasses, undocumented judgment, missing thresholds, unclear reviewer authority, weak segregation, or absent retention rules could prevent AI incident, serious-event, and failure notification from operating consistently." ], "recommendedArtifacts": [ "incident taxonomy.", "incident tickets.", "vulnerability reports.", "root-cause analyses.", "notification records.", "corrective action plans.", "closure validation.", "AI incident response policy/procedure/runbook.", "AI incident taxonomy/severity matrix.", "AI observability metrics and thresholds." ] }, "testOfEffectiveness": { "overallTestObjectivePurpose": "Confirm that AI incident, serious-event, and failure notification operated during the review period in line with its documented criteria, ownership, frequency, evidence requirements, and exception path.", "recommendedSamplingStrategy": "Use AI tool/plugin incidents, suspected misuse, vulnerabilities, unauthorized actions, data exfiltration or privilege events. as the primary population and Incident, alert, vulnerability report, corrective action ticket. as the sample unit. Reconcile the population to the source system, register, workflow, ticket queue, monitoring output, or log extract. Stratify by system, business unit, model tier, lifecycle stage, vendor, region, or risk rating where operation differs. Add judgmental selections for high-risk, changed, exception, override, incident, failed-check, or near-threshold items. Use full-population analytics when the data is complete and the test criterion is deterministic.", "recommendedSampleSize": "Minimum suggestion is 20 daily-or-more-frequent executions, alerts, log entries, or monitoring records after population completeness and control frequency are confirmed. Use full-population analytics where criteria are deterministic.", "detailedTestSteps": [ "Build the population for AI incident, serious-event, and failure notification from the system, workflow, register, log, or approval repository that records control execution. Document extraction parameters, date range, filters, and completeness reconciliation.", "Sample tool/plugin security incidents or vulnerability reports and verify classification, escalation, notification, root cause, corrective action, and closure evidence.", "Sample AI incident/near-miss/anomaly tickets and verify timely identification, severity assessment, escalation, containment, recovery, evidence preservation, notification decision, RCA, corrective action closure, lessons learned, and postincident validation, if no incidents exist, test tabletop exercise records and simulated incident walkthroughs.", "Sample AI incident/near-miss/anomaly records and verify the evidence pack contained relevant logs, model/version/data artifacts, investigation notes, RCA, and corrective actions.", "Sample realized or simulated prompt/input events and verify classification, notification/escalation, containment, corrective action, and closure.", "Sample poisoning/security incidents or tabletop exercises and verify escalation, evidence preservation, root-cause analysis and remediation.", "For each selected item, verify the control was performed by the expected owner or reviewer, at the required point in the process, against the defined criteria, and before the AI decision, release, approval, use, or event proceeded where the design requires prior control execution.", "Compare retained evidence to the control design and confirm completeness, accuracy, reviewer sign-off, timestamps, linkage to the AI system/use case/model/vendor/event, and consistency with the required cadence.", "Trace exceptions, overrides, failed checks, late reviews, unresolved actions, and risk acceptances to escalation, remediation, approval, retesting, or closure evidence." ], "recommendedArtifacts": [ "incident taxonomy.", "incident tickets.", "vulnerability reports.", "root-cause analyses.", "notification records.", "corrective action plans.", "closure validation.", "AI incident response policy/procedure/runbook.", "AI incident taxonomy/severity matrix.", "AI observability metrics and thresholds." ] } }, "expectedEvidenceArtifacts": [ "incident taxonomy", "incident tickets", "vulnerability reports", "root-cause analyses", "notification records", "corrective action plans", "closure validation", "AI incident response policy/procedure/runbook", "AI incident taxonomy/severity matrix", "AI observability metrics and thresholds", "incident/problem tickets", "communications and notification decision logs", "model cards and system documentation", "event logs, prompt logs, model/version metadata, data lineage records", "containment/recovery approvals", "RCA/postmortem records", "CAPA/remediation closure evidence", "tabletop exercise records", "training records", "incident response runbook", "AI incident tickets", "forensic log extracts", "model cards", "data lineage/data lake access records", "RCA reports", "CAPA records", "notification decisions", "playbook", "incident records", "root cause reviews", "corrective action evidence", "forensic preservation logs", "communications", "lessons learned", "severity classification", "notification assessments", "SOC/legal/compliance tickets", "deactivation/bypass records", "forensic/evidence-preservation records", "notification/correction records", "after-action review reports", "corrective action records", "AI incident taxonomy", "notification playbook", "incident report", "RCA", "corrective action record", "stakeholder/regulator/customer notification assessment", "lessons-learned update", "AI incident response and notification playbook", "serious-incident criteria/taxonomy", "incident intake tickets", "incident timeline and impact assessment", "regulatory notification records", "customer/internal notification records", "initial and final incident reports", "root-cause analysis", "risk assessment and corrective-action records", "authority/notified-body/vendor correspondence", "postincident review minutes", "training/tabletop records", "evidence-retention records", "AI incident playbook", "tabletop or simulation records", "containment action logs", "linked case/incident records", "RCA documents", "CAPA tickets", "regulator/customer/internal notification evidence" ] }, { "controlId": "ctl-ai-inference-attack-privacy-testing", "title": "AI inference-attack and memorization privacy testing", "objective": "Detect and reduce model inversion, membership inference, memorization, and training-data reconstruction risks before deployment and during material model/data changes.", "description": "Perform risk-based privacy/security testing for AI systems that use sensitive data, including model inversion and membership inference assessment, memorization/training-data leakage checks, overfitting review, input/output anomaly monitoring, differential privacy or prediction obfuscation where appropriate, and documented risk response when residual inference risk exceeds tolerance.", "controlFamily": "security-testing-and-validation", "sourceLabels": [ "ISACA AAIA Review Manual: AI Data Privacy; Model Inversion; Training Data Leakage; AI Operations - Threats and Vulnerabilities", "NIST AI RMF 1.0: MEASURE 2.7; MEASURE 2.10; MEASURE 3.1; MANAGE 2.4; 3.2", "OWASP: ML Top 10; ML03; ML04" ], "auditProcedure": { "auditProcedureName": "Review AI inference-attack and memorization privacy testing", "auditProcedureDescription": "Trace the control for AI inference-attack and memorization privacy testing from the event, decision, or cadence that triggers it through execution, review, exception handling, and retained evidence. Use the control objective as the reference point. Detect and reduce model inversion, membership inference, memorization, and training-data reconstruction risks before deployment and during material model/data changes. Confirm that the described control activity is performed through clear criteria, accountable ownership, defined timing, complete population coverage, reliable source records, and evidence that exceptions are escalated and resolved. Where the control relies on automated monitoring, workflow approval, or manual expert review, verify that handoffs and evidence repositories are clear enough for repeatable audit testing. The work should cover the activity defined for the control. Perform risk-based privacy/security testing for AI systems that use sensitive data, including model inversion and membership inference assessment, memorization/training-data leakage checks, overfitting review, input/output anomaly monitoring, differential privacy or prediction obfuscation where appropriate, and documented risk response when residual inference risk exceeds tolerance.", "testOfDesign": { "overallTestObjectivePurpose": "Determine whether AI inference-attack and memorization privacy testing is designed with criteria, ownership, timing, evidence, and exception handling precise enough to achieve the objective. Detect and reduce model inversion, membership inference, memorization, and training-data reconstruction risks before deployment and during material model/data changes.", "detailedTestSteps": [ "Inspect whether the control design defines risk-based triggers for model inversion, membership inference, memorization, and training-data leakage testing, required methods/tools, responsible specialists, thresholds/tolerances, remediation or risk acceptance workflow, and re-test triggers after data/model/prompt/retrieval changes.", "Inspect the documented AI inference-attack and memorization privacy testing policy, standard, workflow, configuration, checklist, approval template, or procedure and trace each required element to the stated control objective.", "Confirm that the AI inference-attack and memorization privacy testing design names the accountable owner (AI Security/ML Security specialist with Privacy/DPO, Model Risk/Validation, AI system owner, ML/MLOps owner) and expected performance cadence (Before deployment, after material model/data/retrieval/prompt changes, and periodically for high-sensitivity systems.), including reviewer, delegate, and escalation responsibilities where applicable.", "Check that the design defines the in-scope population (AI models/apps trained on, fine-tuned with, retrieving, or exposing sensitive/confidential/personal data.), sampling unit (Model release, test run, high-risk dataset, monitored query/output interval, leakage alert, remediation ticket.), and process/system boundary (security-testing-and-validation process boundary) so testing can be repeated by another auditor.", "Walk through one representative control occurrence, AI lifecycle event, approval, change, exception, or monitoring record covered by AI inference-attack and memorization privacy testing. Trace it from trigger through decision, escalation, and evidence retention and identify where the control prevents, detects, or corrects the targeted risk.", "Challenge whether bypasses, undocumented judgment, missing thresholds, unclear reviewer authority, weak segregation, or absent retention rules could prevent AI inference-attack and memorization privacy testing from operating consistently." ], "recommendedArtifacts": [ "privacy/security test plan.", "model inversion test report.", "membership inference test report.", "memorization/leakage evaluation.", "model validation report.", "query/output monitoring logs.", "DLP or sensitive-output alerts.", "risk acceptance records.", "remediation tickets.", "post-remediation retest evidence." ] }, "testOfEffectiveness": { "overallTestObjectivePurpose": "Confirm that AI inference-attack and memorization privacy testing operated during the review period in line with its documented criteria, ownership, frequency, evidence requirements, and exception path.", "recommendedSamplingStrategy": "Use AI models/apps trained on, fine-tuned with, retrieving, or exposing sensitive/confidential/personal data. as the primary population and Model release, test run, high-risk dataset, monitored query/output interval, leakage alert, remediation ticket. as the sample unit. Reconcile the population to the source system, register, workflow, ticket queue, monitoring output, or log extract. Stratify by system, business unit, model tier, lifecycle stage, vendor, region, or risk rating where operation differs. Add judgmental selections for high-risk, changed, exception, override, incident, failed-check, or near-threshold items. Use full-population analytics when the data is complete and the test criterion is deterministic.", "recommendedSampleSize": "Minimum suggestion is 20 daily-or-more-frequent executions, alerts, log entries, or monitoring records after population completeness and control frequency are confirmed. Use full-population analytics where criteria are deterministic.", "detailedTestSteps": [ "Build the population for AI inference-attack and memorization privacy testing from the system, workflow, register, log, or approval repository that records control execution. Document extraction parameters, date range, filters, and completeness reconciliation.", "Sample high-sensitivity AI systems or model releases and verify privacy attack testing occurred, results were reviewed, residual risk was accepted or remediated, anomaly monitoring operated, and repeated/high-risk queries or leakage findings triggered escalation.", "For each selected item, verify the control was performed by the expected owner or reviewer, at the required point in the process, against the defined criteria, and before the AI decision, release, approval, use, or event proceeded where the design requires prior control execution.", "Compare retained evidence to the control design and confirm completeness, accuracy, reviewer sign-off, timestamps, linkage to the AI system/use case/model/vendor/event, and consistency with the required cadence.", "Trace exceptions, overrides, failed checks, late reviews, unresolved actions, and risk acceptances to escalation, remediation, approval, retesting, or closure evidence." ], "recommendedArtifacts": [ "privacy/security test plan.", "model inversion test report.", "membership inference test report.", "memorization/leakage evaluation.", "model validation report.", "query/output monitoring logs.", "DLP or sensitive-output alerts.", "risk acceptance records.", "remediation tickets.", "post-remediation retest evidence." ] } }, "expectedEvidenceArtifacts": [ "privacy/security test plan", "model inversion test report", "membership inference test report", "memorization/leakage evaluation", "model validation report", "query/output monitoring logs", "DLP or sensitive-output alerts", "risk acceptance records", "remediation tickets", "post-remediation retest evidence" ] }, { "controlId": "ctl-ai-output-accuracy-grounding-validation", "title": "AI output accuracy, grounding, and validation control", "objective": "Reduce reliance on fabricated, inaccurate, or unsupported AI outputs in material workflows.", "description": "For hallucination-prone or material AI outputs, define expected accuracy/assurance criteria, ground outputs in approved sources where feasible, disclose known limitations, require human or expert review for material decisions, test outputs under deployment-like conditions, and monitor accuracy/performance issues after deployment.", "controlFamily": "monitoring-and-validation", "sourceLabels": [ "NIST AI RMF Playbook: MEASURE 2.3", "NIST AI RMF 1.0: MEASURE 2.3; MEASURE 2.4; 2.5; 2.9; 3.1", "Gartner: AI Governance", "MITRE: AI Maturity Model; Robust & Reliable: Performance & pillar dimensions", "MIT AI Risk Repository: 3.1" ], "auditProcedure": { "auditProcedureName": "Evaluate AI output accuracy, grounding, and validation control", "auditProcedureDescription": "Trace the control for AI output accuracy, grounding, and validation control from the event, decision, or cadence that triggers it through execution, review, exception handling, and retained evidence. Use the control objective as the reference point. Reduce reliance on fabricated, inaccurate, or unsupported AI outputs in material workflows. Confirm that the described control activity is performed through clear criteria, accountable ownership, defined timing, complete population coverage, reliable source records, and evidence that exceptions are escalated and resolved. Where the control relies on automated monitoring, workflow approval, or manual expert review, verify that handoffs and evidence repositories are clear enough for repeatable audit testing. The work should cover the activity defined for the control. For hallucination-prone or material AI outputs, define expected accuracy/assurance criteria, ground outputs in approved sources where feasible, disclose known limitations, require human or expert review for material decisions, test outputs under deployment-like conditions, and monitor accuracy/performance issues after deployment.", "testOfDesign": { "overallTestObjectivePurpose": "Determine whether AI output accuracy, grounding, and validation control is designed with criteria, ownership, timing, evidence, and exception handling precise enough to achieve the objective. Reduce reliance on fabricated, inaccurate, or unsupported AI outputs in material workflows.", "detailedTestSteps": [ "Inspect whether policies/procedures define in-scope hallucination-prone outputs, accuracy/assurance criteria, grounding/RAG requirements where applicable, limitation disclosure, materiality triggers for human/expert review, deployment-like validation requirements, monitoring thresholds, exception handling, owners, cadence, and retained evidence expectations.", "Inspect the documented AI output accuracy, grounding, and validation control policy, standard, workflow, configuration, checklist, approval template, or procedure and trace each required element to the stated control objective.", "Confirm that the AI output accuracy, grounding, and validation control design names the accountable owner (AI product/model owner with business process owner, data/ML engineering, risk/compliance, and domain expert support) and expected performance cadence (Predeployment and material change, periodic postdeployment monitoring cadence based on risk, event-driven after accuracy incidents or drift), including reviewer, delegate, and escalation responsibilities where applicable.", "Check that the design defines the in-scope population (Material AI outputs or workflows where users may rely on factual claims for decisions), sampling unit (AI output, prompt-response transaction, validation scenario, review record, monitoring alert, or corrective-action ticket), and process/system boundary (monitoring-and-validation process boundary) so testing can be repeated by another auditor.", "Walk through one representative control occurrence, AI lifecycle event, approval, change, exception, or monitoring record covered by AI output accuracy, grounding, and validation control. Trace it from trigger through decision, escalation, and evidence retention and identify where the control prevents, detects, or corrects the targeted risk.", "Challenge whether bypasses, undocumented judgment, missing thresholds, unclear reviewer authority, weak segregation, or absent retention rules could prevent AI output accuracy, grounding, and validation control from operating consistently." ], "recommendedArtifacts": [ "AI use-case inventory and materiality classification.", "accuracy/performance criteria and test plans.", "golden datasets/ground-truth benchmarks or expert-review rubrics.", "RAG/source configuration records where applicable.", "model/output validation reports.", "human/expert review logs.", "user instructions and limitation disclosures.", "monitoring dashboards/thresholds.", "exception/incident/corrective-action tickets.", "policy/training records." ] }, "testOfEffectiveness": { "overallTestObjectivePurpose": "Confirm that AI output accuracy, grounding, and validation control operated during the review period in line with its documented criteria, ownership, frequency, evidence requirements, and exception path.", "recommendedSamplingStrategy": "Use Material AI outputs or workflows where users may rely on factual claims for decisions as the primary population and AI output, prompt-response transaction, validation scenario, review record, monitoring alert, or corrective-action ticket as the sample unit. Reconcile the population to the source system, register, workflow, ticket queue, monitoring output, or log extract. Stratify by system, business unit, model tier, lifecycle stage, vendor, region, or risk rating where operation differs. Add judgmental selections for high-risk, changed, exception, override, incident, failed-check, or near-threshold items. Use full-population analytics when the data is complete and the test criterion is deterministic.", "recommendedSampleSize": "Minimum suggestion is 20 daily-or-more-frequent executions, alerts, log entries, or monitoring records after population completeness and control frequency are confirmed. Use full-population analytics where criteria are deterministic.", "detailedTestSteps": [ "Build the population for AI output accuracy, grounding, and validation control from the system, workflow, register, log, or approval repository that records control execution. Document extraction parameters, date range, filters, and completeness reconciliation.", "Sample material AI outputs/use cases, validation runs, expert-review records, RAG/grounding configurations, monitoring alerts, issue tickets, correction records, and user-facing limitations to verify the control operated before reliance and after deployment.", "For each selected item, verify the control was performed by the expected owner or reviewer, at the required point in the process, against the defined criteria, and before the AI decision, release, approval, use, or event proceeded where the design requires prior control execution.", "Compare retained evidence to the control design and confirm completeness, accuracy, reviewer sign-off, timestamps, linkage to the AI system/use case/model/vendor/event, and consistency with the required cadence.", "Trace exceptions, overrides, failed checks, late reviews, unresolved actions, and risk acceptances to escalation, remediation, approval, retesting, or closure evidence." ], "recommendedArtifacts": [ "AI use-case inventory and materiality classification.", "accuracy/performance criteria and test plans.", "golden datasets/ground-truth benchmarks or expert-review rubrics.", "RAG/source configuration records where applicable.", "model/output validation reports.", "human/expert review logs.", "user instructions and limitation disclosures.", "monitoring dashboards/thresholds.", "exception/incident/corrective-action tickets.", "policy/training records." ] } }, "expectedEvidenceArtifacts": [ "AI use-case inventory and materiality classification", "accuracy/performance criteria and test plans", "golden datasets/ground-truth benchmarks or expert-review rubrics", "RAG/source configuration records where applicable", "model/output validation reports", "human/expert review logs", "user instructions and limitation disclosures", "monitoring dashboards/thresholds", "exception/incident/corrective-action tickets", "policy/training records" ] }, { "controlId": "ctl-ai-overreliance-awareness", "title": "Automation-bias and overreliance awareness", "objective": "Reduce inappropriate reliance on AI outputs by users, reviewers, and decision owners.", "description": "Provide targeted training and operating guidance on AI limitations, confirmation bias, automation bias, independent verification, and escalation of questionable AI outputs.", "controlFamily": "training-and-awareness", "sourceLabels": [ "ISACA AI Audit Toolkit 2024: (AI Risk Awareness Training TA-AR-01); AI People & Culture; ISACA AI Audit Toolkit 2024; ISO/IEC 42001 (Competence/Awareness)", "ISACA AAIA Review Manual: AI training and ethical awareness", "ISO/IEC 42001: B.8.2", "NIST AI RMF 1.0: Bias categories", "Gartner: AI Agents; AI Workforce Augmentation; AI People & Culture; AI Governance", "MIT AI Risk Repository: 5.1; 5.1 Overreliance and unsafe use", "OWASP: LLM09; Top 10 for LLM Applications", "AIGP: source knowledge base / AIGP-derived governance concept", "risk universe source knowledge base: AI Overreliance" ], "auditProcedure": { "auditProcedureName": "Validate Automation-bias and overreliance awareness", "auditProcedureDescription": "Trace the control for Automation-bias and overreliance awareness from the event, decision, or cadence that triggers it through execution, review, exception handling, and retained evidence. Use the control objective as the reference point. Reduce inappropriate reliance on AI outputs by users, reviewers, and decision owners. Confirm that the described control activity is performed through clear criteria, accountable ownership, defined timing, complete population coverage, reliable source records, and evidence that exceptions are escalated and resolved. Where the control relies on automated monitoring, workflow approval, or manual expert review, verify that handoffs and evidence repositories are clear enough for repeatable audit testing. The work should cover the activity defined for the control. Provide targeted training and operating guidance on AI limitations, confirmation bias, automation bias, independent verification, and escalation of questionable AI outputs.", "testOfDesign": { "overallTestObjectivePurpose": "Determine whether Automation-bias and overreliance awareness is designed with criteria, ownership, timing, evidence, and exception handling precise enough to achieve the objective. Reduce inappropriate reliance on AI outputs by users, reviewers, and decision owners.", "detailedTestSteps": [ "Inspect whether existing overreliance training content is linked as a supporting module in the broader AI literacy curriculum and mapped to roles that rely on AI outputs.", "Inspect training standard, curriculum, target population, role mapping, frequency, knowledge-check/effectiveness design, operating guidance for independent verification, and escalation instructions.", "Inspect adoption-related training content for AI limitations, trust calibration, safe use, escalation, and role-specific examples.", "Inspect training/guidance for sycophancy, confirmation bias, false-premise challenge, and verification expectations.", "Inspect training/guidance content for AI limitations, explanation limits, independent verification, and escalation routes.", "Inspect the documented Automation-bias and overreliance awareness policy, standard, workflow, configuration, checklist, approval template, or procedure and trace each required element to the stated control objective.", "Confirm that the Automation-bias and overreliance awareness design names the accountable owner (AI governance / L&D / business process owner) and expected performance cadence (Aligned to the primary AI literacy program refresh cadence or when AI-use instructions materially change.), including reviewer, delegate, and escalation responsibilities where applicable.", "Check that the design defines the in-scope population (AI users, reviewers, decision owners, and roles using AI outputs for business decisions.), sampling unit (Individual training assignment or AI-enabled decision/review record.), and process/system boundary (training-and-awareness process boundary) so testing can be repeated by another auditor.", "Walk through one representative control occurrence, AI lifecycle event, approval, change, exception, or monitoring record covered by Automation-bias and overreliance awareness. Trace it from trigger through decision, escalation, and evidence retention and identify where the control prevents, detects, or corrects the targeted risk.", "Challenge whether bypasses, undocumented judgment, missing thresholds, unclear reviewer authority, weak segregation, or absent retention rules could prevent Automation-bias and overreliance awareness from operating consistently." ], "recommendedArtifacts": [ "overreliance training module.", "AI-use instructions.", "completion logs.", "quality review findings.", "escalation records.", "AI risk awareness curriculum.", "automation-bias and confirmation-bias module.", "AI limitations and verification guidance.", "training assignment matrix.", "completion records." ] }, "testOfEffectiveness": { "overallTestObjectivePurpose": "Confirm that Automation-bias and overreliance awareness operated during the review period in line with its documented criteria, ownership, frequency, evidence requirements, and exception path.", "recommendedSamplingStrategy": "Use AI users, reviewers, decision owners, and roles using AI outputs for business decisions. as the primary population and Individual training assignment or AI-enabled decision/review record. as the sample unit. Use representative random sampling where the population is homogeneous. Stratify where ownership, geography, business process, AI use case, model type, third party, or risk tier changes control operation. Reserve judgmental selections for documented high-risk, unusual, changed, exception, or override items.", "recommendedSampleSize": "Minimum suggestion is 20 event records where the event population supports sampling. If fewer events exist, test the full population and include high-risk approvals, overrides, incidents, material model changes, and exceptions.", "detailedTestSteps": [ "Build the population for Automation-bias and overreliance awareness from the system, workflow, register, log, or approval repository that records control execution. Document extraction parameters, date range, filters, and completeness reconciliation.", "Sample AI users/reviewers to verify completion of overreliance/limitations training and evidence of escalation or independent verification behavior where required.", "Sample users/reviewers/decision owners in scope and test training assignment/completion, knowledge-check results, recency, and whether quality reviews or decision samples show verification/escalation behavior after training.", "Sample affected user groups and verify training completion, awareness attestations, and evidence of escalation/use guidance adoption.", "Sample completion logs, user acknowledgements, and quality-review findings for evidence that training operates and feeds issue escalation.", "Sample target users/reviewers and verify training completion and evidence that guidance is used/updated from incidents or quality findings.", "For each selected item, verify the control was performed by the expected owner or reviewer, at the required point in the process, against the defined criteria, and before the AI decision, release, approval, use, or event proceeded where the design requires prior control execution.", "Compare retained evidence to the control design and confirm completeness, accuracy, reviewer sign-off, timestamps, linkage to the AI system/use case/model/vendor/event, and consistency with the required cadence.", "Trace exceptions, overrides, failed checks, late reviews, unresolved actions, and risk acceptances to escalation, remediation, approval, retesting, or closure evidence." ], "recommendedArtifacts": [ "overreliance training module.", "AI-use instructions.", "completion logs.", "quality review findings.", "escalation records.", "AI risk awareness curriculum.", "automation-bias and confirmation-bias module.", "AI limitations and verification guidance.", "training assignment matrix.", "completion records." ] } }, "expectedEvidenceArtifacts": [ "overreliance training module", "AI-use instructions", "completion logs", "quality review findings", "escalation records", "AI risk awareness curriculum", "automation-bias and confirmation-bias module", "AI limitations and verification guidance", "training assignment matrix", "completion records", "knowledge assessments", "training feedback/effectiveness reports", "escalation records for questionable AI outputs", "training deck/content", "attendance/completion logs", "user guidance", "knowledge checks", "escalation instructions", "AI-use guidance", "reported issue records", "training materials", "quick-reference guides", "quality review/remediation records", "operating guidance", "review checklists" ] }, { "controlId": "ctl-ai-postdeployment-model-monitoring", "title": "Postdeployment AI model monitoring", "objective": "Maintain assurance that deployed AI remains fit for purpose, safe, compliant, and controlled after release.", "description": "Monitor postdeployment performance, fairness, robustness, security, incidents, anomalies, residual risk, and corrective actions using defined metrics, thresholds, review cadence, and ownership.", "controlFamily": "monitoring-and-validation", "sourceLabels": [ "ISACA AI Audit Toolkit 2024: AI Model Health Monitoring / Postdeployment Model Monitoring; AI Model Health Monitoring and Postdeployment Model Monitoring controls; MG-MH-01; MG-MH-06", "ISACA AAIA Review Manual: AI asset identification; Ch. 03 Part A, Figure 3.1; Recovery; Postincident Review", "ISO/IEC 42001: A.6.2; B.6.2", "ISO/IEC 5338: 6.4.14; 6.4.16; 6.4.15", "NIST AI RMF Playbook: MANAGE 3.1; MAP 1.1; MEASURE 2.5", "NIST AI 600-1 / GenAI Profile: GV-1.5-001; MS-1.1-001; GOVERN 1.5; MEASURE 1.1; Information Integrity; MS-2.6; MS-2.7; MS-4.2; MG-4.1", "NIST AI RMF 1.0: MANAGE 2.2", "Gartner: AI governance / Risk Essentials; AI Governance / Risk Essentials; Risk Essentials; Anatomy of an AI Risk Management Program", "MITRE: AI Maturity Model: Solution Monitoring; Robust and Reliable; Solution Monitoring", "OWASP: Agentic Security Initiative; LLM Top 10 2025; LLM06", "EU AI Act: Article 20; Article 26 deployer monitoring and logs; Article 72", "Berkeley Agentic AI Risk Profile: Agentic AI Risk Profile", "OECD: AI in the Workplace; workplace AI policy/risk guidance" ], "auditProcedure": { "auditProcedureName": "Review Postdeployment AI model monitoring", "auditProcedureDescription": "Trace the control for Postdeployment AI model monitoring from the event, decision, or cadence that triggers it through execution, review, exception handling, and retained evidence. Use the control objective as the reference point. Maintain assurance that deployed AI remains fit for purpose, safe, compliant, and controlled after release. Confirm that the described control activity is performed through clear criteria, accountable ownership, defined timing, complete population coverage, reliable source records, and evidence that exceptions are escalated and resolved. Where the control relies on automated monitoring, workflow approval, or manual expert review, verify that handoffs and evidence repositories are clear enough for repeatable audit testing. The work should cover the activity defined for the control. Monitor postdeployment performance, fairness, robustness, security, incidents, anomalies, residual risk, and corrective actions using defined metrics, thresholds, review cadence, and ownership.", "testOfDesign": { "overallTestObjectivePurpose": "Determine whether Postdeployment AI model monitoring is designed with criteria, ownership, timing, evidence, and exception handling precise enough to achieve the objective. Maintain assurance that deployed AI remains fit for purpose, safe, compliant, and controlled after release.", "detailedTestSteps": [ "Inspect postdeployment monitoring design, metrics, thresholds, ownership, review cadence, escalation paths and correction/decommission criteria.", "Inspect monitoring design, metrics, thresholds, review cadence, accountable owner and escalation path as required before scale approval.", "Verify monitoring design includes output-related security/anomaly metrics and escalation paths for output-handling failures.", "Inspect whether monitoring/logging design covers tool/plugin calls, sensitive actions, authorization failures, anomalous usage, abuse scenarios, and incident/escalation thresholds.", "Inspect postdeployment monitoring plan coverage for performance, fairness, robustness, security, incidents, anomalies, residual risk, corrective actions, owner, cadence, and escalation.", "Inspect the documented Postdeployment AI model monitoring policy, standard, workflow, configuration, checklist, approval template, or procedure and trace each required element to the stated control objective.", "Confirm that the Postdeployment AI model monitoring design names the accountable owner (AI system owner with ML/MLOps/Model Risk/AI Governance) and expected performance cadence (Periodic and event-driven, exact cadence should be risk-tier based.), including reviewer, delegate, and escalation responsibilities where applicable.", "Check that the design defines the in-scope population (Deployed AI systems in production or pilot use.), sampling unit (AI system monitoring period, alert, incident, or corrective action.), and process/system boundary (monitoring-and-validation process boundary) so testing can be repeated by another auditor.", "Walk through one representative control occurrence, AI lifecycle event, approval, change, exception, or monitoring record covered by Postdeployment AI model monitoring. Trace it from trigger through decision, escalation, and evidence retention and identify where the control prevents, detects, or corrects the targeted risk.", "Challenge whether bypasses, undocumented judgment, missing thresholds, unclear reviewer authority, weak segregation, or absent retention rules could prevent Postdeployment AI model monitoring from operating consistently." ], "recommendedArtifacts": [ "monitoring dashboards.", "metric definitions.", "threshold definitions.", "anomaly/incident logs.", "corrective action tickets.", "performance review minutes.", "decommissioning/rollback records.", "threshold catalogue.", "review logs.", "incident/anomaly tickets." ] }, "testOfEffectiveness": { "overallTestObjectivePurpose": "Confirm that Postdeployment AI model monitoring operated during the review period in line with its documented criteria, ownership, frequency, evidence requirements, and exception path.", "recommendedSamplingStrategy": "Use Deployed AI systems in production or pilot use. as the primary population and AI system monitoring period, alert, incident, or corrective action. as the sample unit. Reconcile the population to the source system, register, workflow, ticket queue, monitoring output, or log extract. Stratify by system, business unit, model tier, lifecycle stage, vendor, region, or risk rating where operation differs. Add judgmental selections for high-risk, changed, exception, override, incident, failed-check, or near-threshold items. Use full-population analytics when the data is complete and the test criterion is deterministic.", "recommendedSampleSize": "Minimum suggestion is 20 daily-or-more-frequent executions, alerts, log entries, or monitoring records after population completeness and control frequency are confirmed. Use full-population analytics where criteria are deterministic.", "detailedTestSteps": [ "Build the population for Postdeployment AI model monitoring from the system, workflow, register, log, or approval repository that records control execution. Document extraction parameters, date range, filters, and completeness reconciliation.", "Sample monitoring outputs, alerts/incidents and corrective actions to verify monitoring operated and exceptions were resolved/escalated.", "Sample deployed/scaled AI systems and verify monitoring ran as designed, exceptions were reviewed, and corrective actions were recorded.", "Sample monitoring periods/alerts/tickets for unsafe output patterns, output integrity issues, and remediation follow-through.", "Sample monitoring periods/tool-call events/alerts and verify review, triage, escalation, corrective action, and evidence retention.", "Sample monitoring periods and incident/anomaly tickets to verify review, escalation, corrective action, and closure.", "For each selected item, verify the control was performed by the expected owner or reviewer, at the required point in the process, against the defined criteria, and before the AI decision, release, approval, use, or event proceeded where the design requires prior control execution.", "Compare retained evidence to the control design and confirm completeness, accuracy, reviewer sign-off, timestamps, linkage to the AI system/use case/model/vendor/event, and consistency with the required cadence.", "Trace exceptions, overrides, failed checks, late reviews, unresolved actions, and risk acceptances to escalation, remediation, approval, retesting, or closure evidence." ], "recommendedArtifacts": [ "monitoring dashboards.", "metric definitions.", "threshold definitions.", "anomaly/incident logs.", "corrective action tickets.", "performance review minutes.", "decommissioning/rollback records.", "threshold catalogue.", "review logs.", "incident/anomaly tickets." ] } }, "expectedEvidenceArtifacts": [ "monitoring dashboards", "metric definitions", "threshold definitions", "anomaly/incident logs", "corrective action tickets", "performance review minutes", "decommissioning/rollback records", "threshold catalogue", "review logs", "incident/anomaly tickets", "corrective-action records", "output anomaly alerts", "corrective action records", "tool-call logs", "SIEM/monitoring dashboards", "alert records", "triage notes", "incident records", "postdeployment monitoring plan", "periodic review minutes", "corrective action log", "decommissioning or rollback records", "AI/model inventory and risk classification", "postdeployment monitoring policy/procedure/standard", "monitoring plan and metric/threshold catalogue", "model health/performance/fairness/robustness/security dashboards", "monitoring logs and alert records", "usage logs and deployer/user feedback", "incident, near-miss, anomaly, attack-pattern and issue tickets", "root-cause analyses", "corrective action and remediation plans", "retesting/TEVV and validation reports", "retraining/recalibration/rollback/decommissioning approvals", "change records and post-change monitoring evidence", "monitoring review meeting minutes", "risk acceptance records", "technical documentation/model cards", "monitoring dashboard exports", "alert rules", "threshold approvals", "anomaly tickets", "incident links", "alert logs", "review minutes", "monitoring plans", "usage analytics", "dashboards", "thresholds", "feedback logs", "incident/anomaly reviews", "remediation tickets", "threshold configs", "incident tickets", "threshold configuration", "log extracts", "alert tickets", "corrective actions", "usage logs", "abuse tickets", "red-team reports", "incident response metrics", "alert definitions", "issue logs", "corrective-action tickets", "retest evidence", "monitoring dashboard", "KRI definitions", "hallucination/error reports", "provenance failure reports", "review meeting records", "incident linkage", "appeal trend reports", "negative-impact logs", "incident/corrective-action tickets", "fairness metrics", "incident/complaint logs", "logs", "monitoring reviews", "remediation records", "SIEM/log queries", "tool execution logs", "resource utilization alerts", "role-change alerts" ] }, { "controlId": "ctl-ai-risk-classification-register", "title": "AI risk classification and registration register", "objective": "Apply proportionate governance based on AI system risk characteristics and applicable high-risk or registration obligations.", "description": "Maintain AI system/use-case register with intended use, owner, impact, autonomy, data sensitivity, exposure, status, and risk classification so readiness gates have a complete population and accountability baseline.", "controlFamily": "risk-management", "sourceLabels": [ "ISACA AI Audit Toolkit 2024: AI Life Cycle Management / Risk Management controls; AI risk classification register; high-risk AI registration/documentation controls", "ISACA AAIA Review Manual: AI asset identification; Inventory objectives and procedures; AI Risk Assessment; Risk Response and Prioritization", "ISO/IEC 42001: 6.1.2; A.5.2; 6.1.4; A.5.3; B.5.2; B.5.3", "NIST AI RMF Playbook: MAP 1.1", "NIST AI RMF 1.0: GOVERN 1.6; MAP 1.1; MAP 1.5; MAP 2.2", "Gartner: AI governance / Risk Essentials; AI Strategy; Risk Essentials", "MITRE: Ethical Use / AI Maturity Model", "EU AI Act: Annex III; Article 49; Article 6" ], "auditProcedure": { "auditProcedureName": "Analyze AI risk classification and registration register", "auditProcedureDescription": "Trace the control for AI risk classification and registration register from the event, decision, or cadence that triggers it through execution, review, exception handling, and retained evidence. Use the control objective as the reference point. Apply proportionate governance based on AI system risk characteristics and applicable high-risk or registration obligations. Confirm that the described control activity is performed through clear criteria, accountable ownership, defined timing, complete population coverage, reliable source records, and evidence that exceptions are escalated and resolved. Where the control relies on automated monitoring, workflow approval, or manual expert review, verify that handoffs and evidence repositories are clear enough for repeatable audit testing. The work should cover the activity defined for the control. Maintain AI system/use-case register with intended use, owner, impact, autonomy, data sensitivity, exposure, status, and risk classification so readiness gates have a complete population and accountability baseline.", "testOfDesign": { "overallTestObjectivePurpose": "Determine whether AI risk classification and registration register is designed with criteria, ownership, timing, evidence, and exception handling precise enough to achieve the objective. Apply proportionate governance based on AI system risk characteristics and applicable high-risk or registration obligations.", "detailedTestSteps": [ "Inspect inventory/register procedure and required fields to verify material AI ambitions/use cases have owner, purpose, classification and status fields sufficient to trigger readiness review.", "Inspect whether the AI register schema can serve as the population source for material AI initiatives and contains enough fields to identify initiative owner, intended use, status, and risk classification for alignment testing.", "Confirm the AI register requires use-case purpose/intended use, owner, impact, data sensitivity, status, and risk classification fields that can feed prioritization.", "Inspect how the classification register links to the broader AI inventory and whether required classification fields are part of the inventory schema.", "Inspect AI classification policy/procedure, criteria/rubric, risk tolerance thresholds, inventory/register data model, approval workflow, high-risk/prohibited-use/registration applicability logic, human oversight/system-limit documentation requirements, owner/RACI, exception handling, and evidence-retention requirements.", "Inspect the documented AI risk classification and registration register policy, standard, workflow, configuration, checklist, approval template, or procedure and trace each required element to the stated control objective.", "Confirm that the AI risk classification and registration register design names the accountable owner (AI governance office, IT asset management, CDO/CAIO or risk management) and expected performance cadence (Continuously on intake, formally refreshed at least annually and on material changes), including reviewer, delegate, and escalation responsibilities where applicable.", "Check that the design defines the in-scope population (AI systems, AI use cases, models, tools and externally sourced AI services in use or proposed), sampling unit (AI inventory record / AI initiative record), and process/system boundary (risk-management process boundary) so testing can be repeated by another auditor.", "Walk through one representative control occurrence, AI lifecycle event, approval, change, exception, or monitoring record covered by AI risk classification and registration register. Trace it from trigger through decision, escalation, and evidence retention and identify where the control prevents, detects, or corrects the targeted risk.", "Challenge whether bypasses, undocumented judgment, missing thresholds, unclear reviewer authority, weak segregation, or absent retention rules could prevent AI risk classification and registration register from operating consistently." ], "recommendedArtifacts": [ "AI inventory/register.", "classification criteria.", "asset intake records.", "owner attestations.", "survey/interview results.", "discovery reports.", "classification approvals.", "risk classification criteria.", "owner/status fields.", "register reconciliation to portfolio." ] }, "testOfEffectiveness": { "overallTestObjectivePurpose": "Confirm that AI risk classification and registration register operated during the review period in line with its documented criteria, ownership, frequency, evidence requirements, and exception path.", "recommendedSamplingStrategy": "Use AI systems, AI use cases, models, tools and externally sourced AI services in use or proposed as the primary population and AI inventory record / AI initiative record as the sample unit. Reconcile the population to the source system, register, workflow, ticket queue, monitoring output, or log extract. Stratify by system, business unit, model tier, lifecycle stage, vendor, region, or risk rating where operation differs. Add judgmental selections for high-risk, changed, exception, override, incident, failed-check, or near-threshold items. Use full-population analytics when the data is complete and the test criterion is deterministic.", "recommendedSampleSize": "Minimum suggestion is the annual execution plus interim changes, exceptions, approvals, and triggering events relevant to the control. Annual controls do not have a fixed standard sample size in the matrix.", "detailedTestSteps": [ "Build the population for AI risk classification and registration register from the system, workflow, register, log, or approval repository that records control execution. Document extraction parameters, date range, filters, and completeness reconciliation.", "Sample AI initiatives from multiple discovery sources and test whether they appear in the register with complete owner/purpose/classification data and appropriate readiness-gate routing., When testing the primary portfolio alignment control, reconcile sampled portfolio entries to the AI register and check whether material initiatives have owner/status/intended-use/risk-classification fields completed., For sampled use-case intake records, reconcile to the AI register and verify classification fields are complete and approved before portfolio decisions.", "Sample AI inventory entries and verify classification register linkage, approvals, status, and high-risk/registration indicators.", "Sample AI systems/use cases from intake, inventory, procurement, architecture/security review, model registry, and change records, verify classification was completed, criteria were applied consistently, risk tolerance/risk level was documented, high-risk/registration indicators were assessed, responsible approval occurred, exceptions were escalated, and classification was updated after material changes.", "Sample approved AI intake/procurement/use records and verify corresponding inventory entry, classification, owner, status, and routing/approval evidence.", "Sample AI systems/features to verify cyber/misuse risk classification and routing to specialist review/restriction/monitoring controls.", "For each selected item, verify the control was performed by the expected owner or reviewer, at the required point in the process, against the defined criteria, and before the AI decision, release, approval, use, or event proceeded where the design requires prior control execution.", "Compare retained evidence to the control design and confirm completeness, accuracy, reviewer sign-off, timestamps, linkage to the AI system/use case/model/vendor/event, and consistency with the required cadence.", "Trace exceptions, overrides, failed checks, late reviews, unresolved actions, and risk acceptances to escalation, remediation, approval, retesting, or closure evidence." ], "recommendedArtifacts": [ "AI inventory/register.", "classification criteria.", "asset intake records.", "owner attestations.", "survey/interview results.", "discovery reports.", "classification approvals.", "risk classification criteria.", "owner/status fields.", "register reconciliation to portfolio." ] } }, "expectedEvidenceArtifacts": [ "AI inventory/register", "classification criteria", "asset intake records", "owner attestations", "survey/interview results", "discovery reports", "classification approvals", "risk classification criteria", "owner/status fields", "register reconciliation to portfolio", "classification approval records", "classification records", "approval evidence", "registration applicability assessments", "AI inventory/register extract", "classification rubric/standard", "completed intake/classification forms", "risk tolerance/risk appetite matrix", "approval records", "governance board minutes", "exception/deviation logs", "system limitation and human-oversight documentation", "high-risk/prohibited-use/registration applicability records", "change/reclassification history", "retention records", "classification rubric", "intake-to-register linkage", "approval/routing records", "AI register", "classification questionnaire", "risk assessment", "risk-tier approval", "control applicability mapping", "AI system register", "classification assessment", "registration applicability record", "registration/public database evidence", "conformity documentation links", "AI inventory", "owner assignments", "scope/impact flags", "inventory attestations", "deployment architecture", "capability-tier assessment", "risk owner approval", "evaluation trigger records" ] }, { "controlId": "ctl-ai-sensitive-data-protection", "title": "AI sensitive-data protection and disclosure prevention", "objective": "Prevent unauthorized disclosure, retention, reproduction, or exposure of sensitive, confidential, or personal data through AI training, tuning, retrieval, prompts, outputs, logs, and connected data sources.", "description": "Define and operate AI data-use rules covering data classification, approved data purposes, minimization, masking/tokenization/redaction, least-privilege access to training/retrieval/runtime data, restrictions on sensitive prompt/output content, retention/deletion expectations, logging without sensitive-data sprawl, and exception handling for systems that process PII, IP, trade secrets, credentials, health/financial records, or other confidential data.", "controlFamily": "privacy-and-data-protection", "sourceLabels": [ "ISACA AAIA Review Manual: Data Governance; Data Classification; Privacy Considerations; Privacy and Data Governance Programs", "ISO/IEC 42001: A.7.2; B.7.2; A.7; B.7", "NIST AI RMF 1.0: MEASURE 2.7; MEASURE 2.10; MANAGE 2.4", "OWASP: LLM Top 10; LLM06; LLM02", "EU AI Act: Article 5" ], "auditProcedure": { "auditProcedureName": "Examine AI sensitive-data protection and disclosure prevention", "auditProcedureDescription": "Trace the control for AI sensitive-data protection and disclosure prevention from the event, decision, or cadence that triggers it through execution, review, exception handling, and retained evidence. Use the control objective as the reference point. Prevent unauthorized disclosure, retention, reproduction, or exposure of sensitive, confidential, or personal data through AI training, tuning, retrieval, prompts, outputs, logs, and connected data sources. Confirm that the described control activity is performed through clear criteria, accountable ownership, defined timing, complete population coverage, reliable source records, and evidence that exceptions are escalated and resolved. Where the control relies on automated monitoring, workflow approval, or manual expert review, verify that handoffs and evidence repositories are clear enough for repeatable audit testing. The work should cover the activity defined for the control. Define and operate AI data-use rules covering data classification, approved data purposes, minimization, masking/tokenization/redaction, least-privilege access to training/retrieval/runtime data, restrictions on sensitive prompt/output content, retention/deletion expectations, logging without sensitive-data sprawl, and exception handling for systems that process PII, IP, trade secrets, credentials, health/financial records, or other confidential data.", "testOfDesign": { "overallTestObjectivePurpose": "Determine whether AI sensitive-data protection and disclosure prevention is designed with criteria, ownership, timing, evidence, and exception handling precise enough to achieve the objective. Prevent unauthorized disclosure, retention, reproduction, or exposure of sensitive, confidential, or personal data through AI training, tuning, retrieval, prompts, outputs, logs, and connected data sources.", "detailedTestSteps": [ "Inspect AI data-use policy/procedure, risk classification criteria, data classification mapping, allowed/prohibited data categories, minimization and masking/tokenization design, access-control model, output/prompt safeguard design, retention/deletion rules, exception/escalation path, and linkage to sensitive-data sources and AI system inventory.", "Inspect the documented AI sensitive-data protection and disclosure prevention policy, standard, workflow, configuration, checklist, approval template, or procedure and trace each required element to the stated control objective.", "Confirm that the AI sensitive-data protection and disclosure prevention design names the accountable owner (Data Governance/Data Owner with Privacy/DPO, CISO/Security, AI system owner, ML/MLOps owner) and expected performance cadence (Per new or materially changed AI use case, access and classification recertification periodically, monitoring continuous or per release cycle), including reviewer, delegate, and escalation responsibilities where applicable.", "Check that the design defines the in-scope population (AI systems and datasets that process, retrieve, train on, store, log, or output sensitive/confidential/personal data.), sampling unit (AI system, dataset/source, access entitlement, prompt/output/log sample, exception ticket, DPIA/privacy review record.), and process/system boundary (privacy-and-data-protection process boundary) so testing can be repeated by another auditor.", "Walk through one representative control occurrence, AI lifecycle event, approval, change, exception, or monitoring record covered by AI sensitive-data protection and disclosure prevention. Trace it from trigger through decision, escalation, and evidence retention and identify where the control prevents, detects, or corrects the targeted risk.", "Challenge whether bypasses, undocumented judgment, missing thresholds, unclear reviewer authority, weak segregation, or absent retention rules could prevent AI sensitive-data protection and disclosure prevention from operating consistently." ], "recommendedArtifacts": [ "AI system and data inventory.", "data classification register.", "data-use approvals.", "DPIA/privacy review records where applicable.", "access matrices and recertifications.", "DLP/masking/tokenization/redaction rules.", "prompt/output guardrail configuration.", "retention/deletion schedule.", "AI logs and monitoring outputs.", "exception and incident tickets." ] }, "testOfEffectiveness": { "overallTestObjectivePurpose": "Confirm that AI sensitive-data protection and disclosure prevention operated during the review period in line with its documented criteria, ownership, frequency, evidence requirements, and exception path.", "recommendedSamplingStrategy": "Use AI systems and datasets that process, retrieve, train on, store, log, or output sensitive/confidential/personal data. as the primary population and AI system, dataset/source, access entitlement, prompt/output/log sample, exception ticket, DPIA/privacy review record. as the sample unit. Reconcile the population to the source system, register, workflow, ticket queue, monitoring output, or log extract. Stratify by system, business unit, model tier, lifecycle stage, vendor, region, or risk rating where operation differs. Add judgmental selections for high-risk, changed, exception, override, incident, failed-check, or near-threshold items. Use full-population analytics when the data is complete and the test criterion is deterministic.", "recommendedSampleSize": "Minimum suggestion is 20 daily-or-more-frequent executions, alerts, log entries, or monitoring records after population completeness and control frequency are confirmed. Use full-population analytics where criteria are deterministic.", "detailedTestSteps": [ "Build the population for AI sensitive-data protection and disclosure prevention from the system, workflow, register, log, or approval repository that records control execution. Document extraction parameters, date range, filters, and completeness reconciliation.", "Sample AI systems/datasets/prompts/retrieval sources/logs and verify sensitive data was classified, approved for use, minimized or masked, access was authorized and recertified, outputs/logs did not retain unapproved sensitive data, exceptions were approved, and remediation occurred for violations.", "For each selected item, verify the control was performed by the expected owner or reviewer, at the required point in the process, against the defined criteria, and before the AI decision, release, approval, use, or event proceeded where the design requires prior control execution.", "Compare retained evidence to the control design and confirm completeness, accuracy, reviewer sign-off, timestamps, linkage to the AI system/use case/model/vendor/event, and consistency with the required cadence.", "Trace exceptions, overrides, failed checks, late reviews, unresolved actions, and risk acceptances to escalation, remediation, approval, retesting, or closure evidence." ], "recommendedArtifacts": [ "AI system and data inventory.", "data classification register.", "data-use approvals.", "DPIA/privacy review records where applicable.", "access matrices and recertifications.", "DLP/masking/tokenization/redaction rules.", "prompt/output guardrail configuration.", "retention/deletion schedule.", "AI logs and monitoring outputs.", "exception and incident tickets." ] } }, "expectedEvidenceArtifacts": [ "AI system and data inventory", "data classification register", "data-use approvals", "DPIA/privacy review records where applicable", "access matrices and recertifications", "DLP/masking/tokenization/redaction rules", "prompt/output guardrail configuration", "retention/deletion schedule", "AI logs and monitoring outputs", "exception and incident tickets", "training/user guidance records" ] }, { "controlId": "ctl-ai-strategy-feasibility-readiness-review", "title": "AI strategy feasibility and readiness review", "objective": "Confirm material AI ambitions, roadmap items, and major use cases are achievable, resourced, and aligned to organizational readiness before funding or commitment.", "description": "Require each material AI ambition or major AI initiative to document business objective, intended purpose, feasibility assumptions, technology and data readiness, organizational buy-in, capability/resourcing gaps, accountable owner, funding model, risk assumptions, decision rights, and approval gate before investment approval.", "controlFamily": "strategy-and-value-governance", "sourceLabels": [ "ISACA AAIA Review Manual: Types of AI Controls; AI asset identification; Inventory objectives and procedures", "ISO/IEC 42001: 4.1; 5.1; 6.1.1; 6.1.3; 6.2; 7.1; 7.2", "NIST AI RMF 1.0: MAP 1.1; MAP 1.2", "Gartner: AI Data; AI Roadmap; AI Strategy; Set adoption goals", "risk workbook: Sheet 1 - risk_matrix v3" ], "auditProcedure": { "auditProcedureName": "Evaluate AI strategy feasibility and readiness review", "auditProcedureDescription": "Trace the control for AI strategy feasibility and readiness review from the event, decision, or cadence that triggers it through execution, review, exception handling, and retained evidence. Use the control objective as the reference point. Confirm material AI ambitions, roadmap items, and major use cases are achievable, resourced, and aligned to organizational readiness before funding or commitment. Confirm that the described control activity is performed through clear criteria, accountable ownership, defined timing, complete population coverage, reliable source records, and evidence that exceptions are escalated and resolved. Where the control relies on automated monitoring, workflow approval, or manual expert review, verify that handoffs and evidence repositories are clear enough for repeatable audit testing. The work should cover the activity defined for the control. Require each material AI ambition or major AI initiative to document business objective, intended purpose, feasibility assumptions, technology and data readiness, organizational buy-in, capability/resourcing gaps, accountable owner, funding model, risk assumptions, decision rights, and approval gate before investment approval.", "testOfDesign": { "overallTestObjectivePurpose": "Determine whether AI strategy feasibility and readiness review is designed with criteria, ownership, timing, evidence, and exception handling precise enough to achieve the objective. Confirm material AI ambitions, roadmap items, and major use cases are achievable, resourced, and aligned to organizational readiness before funding or commitment.", "detailedTestSteps": [ "Inspect policy/procedure and approval templates requiring feasibility/readiness evidence before AI strategy/portfolio funding decisions, verify defined criteria, owners, decision rights, required fields, approval authority, exception path and evidence retention.", "Inspect the documented AI strategy feasibility and readiness review policy, standard, workflow, configuration, checklist, approval template, or procedure and trace each required element to the stated control objective.", "Confirm that the AI strategy feasibility and readiness review design names the accountable owner (AI strategy owner, CIO/CDO/CAIO, AI governance board or portfolio steering committee) and expected performance cadence (Per material AI strategy/roadmap/use-case approval, annual or event-triggered strategy refresh), including reviewer, delegate, and escalation responsibilities where applicable.", "Check that the design defines the in-scope population (Material AI ambitions, roadmap initiatives, major AI use cases or investment proposals in the period), sampling unit (Approved AI initiative/use case/roadmap item), and process/system boundary (strategy-and-value-governance process boundary) so testing can be repeated by another auditor.", "Walk through one representative control occurrence, AI lifecycle event, approval, change, exception, or monitoring record covered by AI strategy feasibility and readiness review. Trace it from trigger through decision, escalation, and evidence retention and identify where the control prevents, detects, or corrects the targeted risk.", "Challenge whether bypasses, undocumented judgment, missing thresholds, unclear reviewer authority, weak segregation, or absent retention rules could prevent AI strategy feasibility and readiness review from operating consistently." ], "recommendedArtifacts": [ "AI strategy document.", "AI roadmap.", "AI maturity/readiness assessment.", "data readiness assessment.", "use-case/business case template.", "capability gap analysis.", "funding approval.", "portfolio/steering committee minutes.", "decision-rights matrix.", "risk assessment." ] }, "testOfEffectiveness": { "overallTestObjectivePurpose": "Confirm that AI strategy feasibility and readiness review operated during the review period in line with its documented criteria, ownership, frequency, evidence requirements, and exception path.", "recommendedSamplingStrategy": "Use Material AI ambitions, roadmap initiatives, major AI use cases or investment proposals in the period as the primary population and Approved AI initiative/use case/roadmap item as the sample unit. Reconcile the population to the source system, register, workflow, ticket queue, monitoring output, or log extract. Stratify by system, business unit, model tier, lifecycle stage, vendor, region, or risk rating where operation differs. Add judgmental selections for high-risk, changed, exception, override, incident, failed-check, or near-threshold items. Use full-population analytics when the data is complete and the test criterion is deterministic.", "recommendedSampleSize": "Minimum suggestion is the annual execution plus interim changes, exceptions, approvals, and triggering events relevant to the control. Annual controls do not have a fixed standard sample size in the matrix.", "detailedTestSteps": [ "Build the population for AI strategy feasibility and readiness review from the system, workflow, register, log, or approval repository that records control execution. Document extraction parameters, date range, filters, and completeness reconciliation.", "Sample material AI roadmap items/use cases approved in the period and test whether each had complete readiness documentation, required stakeholder reviews, unresolved gap disposition, funding/owner approval and retained decision evidence before approval.", "For each selected item, verify the control was performed by the expected owner or reviewer, at the required point in the process, against the defined criteria, and before the AI decision, release, approval, use, or event proceeded where the design requires prior control execution.", "Compare retained evidence to the control design and confirm completeness, accuracy, reviewer sign-off, timestamps, linkage to the AI system/use case/model/vendor/event, and consistency with the required cadence.", "Trace exceptions, overrides, failed checks, late reviews, unresolved actions, and risk acceptances to escalation, remediation, approval, retesting, or closure evidence." ], "recommendedArtifacts": [ "AI strategy document.", "AI roadmap.", "AI maturity/readiness assessment.", "data readiness assessment.", "use-case/business case template.", "capability gap analysis.", "funding approval.", "portfolio/steering committee minutes.", "decision-rights matrix.", "risk assessment." ] } }, "expectedEvidenceArtifacts": [ "AI strategy document", "AI roadmap", "AI maturity/readiness assessment", "data readiness assessment", "use-case/business case template", "capability gap analysis", "funding approval", "portfolio/steering committee minutes", "decision-rights matrix", "risk assessment", "impact assessment", "approval workflow records", "strategy KPI dashboard", "strategy refresh log" ] }, { "controlId": "ctl-ai-supplier-due-diligence", "title": "AI supplier and external-component due diligence", "objective": "Assess AI vendors, external models, datasets, APIs, plugins, and service providers before and during use.", "description": "Apply risk-based due diligence and ongoing monitoring for AI vendors, external models, datasets, APIs, plugins, embedded vendor AI capabilities, and service providers. The control should assess security, privacy, resilience, transparency/provenance, contractual terms, lifecycle responsibilities, conformity/attestation evidence where applicable, and issue/exception handling before approval and during use.", "controlFamily": "third-party-and-supply-chain", "sourceLabels": [ "ISACA AI Audit Toolkit 2024: AI supplier due diligence; External Components & Supply Chain Governance", "ISACA AAIA Review Manual: Ch.03 Part A", "ISO/IEC 42001: 8.1; A.10.2; A.10.4; B.9.2; A.10.3; B.10.2; B.10.3", "NIST AI RMF Playbook: GOVERN 6.1; MAP 4.1; MANAGE 3.1; MANAGE 3.2; MEASURE 2.7", "NIST AI RMF 1.0: GOVERN 6; MAP 2.3; MANAGE 1.3; GOVERN 6.1; GOVERN 6.2", "EU AI Act: Article 25; Article 51; Article 53" ], "auditProcedure": { "auditProcedureName": "Analyze AI supplier and external-component due diligence", "auditProcedureDescription": "Trace the control for AI supplier and external-component due diligence from the event, decision, or cadence that triggers it through execution, review, exception handling, and retained evidence. Use the control objective as the reference point. Assess AI vendors, external models, datasets, APIs, plugins, and service providers before and during use. Confirm that the described control activity is performed through clear criteria, accountable ownership, defined timing, complete population coverage, reliable source records, and evidence that exceptions are escalated and resolved. Where the control relies on automated monitoring, workflow approval, or manual expert review, verify that handoffs and evidence repositories are clear enough for repeatable audit testing. The work should cover the activity defined for the control. Apply risk-based due diligence and ongoing monitoring for AI vendors, external models, datasets, APIs, plugins, embedded vendor AI capabilities, and service providers. The control should assess security, privacy, resilience, transparency/provenance, contractual terms, lifecycle responsibilities, conformity/attestation evidence where applicable, and issue/exception handling before approval and during use.", "testOfDesign": { "overallTestObjectivePurpose": "Determine whether AI supplier and external-component due diligence is designed with criteria, ownership, timing, evidence, and exception handling precise enough to achieve the objective. Assess AI vendors, external models, datasets, APIs, plugins, and service providers before and during use.", "detailedTestSteps": [ "Inspect vendor AI due-diligence criteria and linkage from AI intake/procurement to supplier review.", "Inspect AI third-party management policy/procedure, intake/procurement gates, supplier/component classification criteria, approved supplier/component inventory, due-diligence checklist, responsibility matrix, monitoring frequency, exception/escalation criteria, conformity-evidence requirements, and evidence retention expectations.", "Inspect whether due-diligence procedures require provenance/transparency/terms review for external AI components where IP exposure may arise.", "Inspect third-party plugin/API onboarding standard, due diligence criteria, responsibility matrix, contractual/security evidence requirements, vulnerability reporting process, and periodic review cadence.", "Inspect vendor/model/dataset due diligence criteria and monitoring requirements for poisoning and provenance risk.", "Inspect the documented AI supplier and external-component due diligence policy, standard, workflow, configuration, checklist, approval template, or procedure and trace each required element to the stated control objective.", "Confirm that the AI supplier and external-component due diligence design names the accountable owner (Procurement/vendor management with AI governance, InfoSec, Privacy/Legal, and business owner.) and expected performance cadence (At onboarding/acquisition, material vendor/model/service change, contract renewal, and periodic review as defined by risk tier.), including reviewer, delegate, and escalation responsibilities where applicable.", "Check that the design defines the in-scope population (Third-party AI suppliers, external components, embedded vendor AI features, APIs, datasets, plugins, and AI services.), sampling unit (AI vendor/component due-diligence record.), and process/system boundary (third-party-and-supply-chain process boundary) so testing can be repeated by another auditor.", "Walk through one representative control occurrence, AI lifecycle event, approval, change, exception, or monitoring record covered by AI supplier and external-component due diligence. Trace it from trigger through decision, escalation, and evidence retention and identify where the control prevents, detects, or corrects the targeted risk.", "Challenge whether bypasses, undocumented judgment, missing thresholds, unclear reviewer authority, weak segregation, or absent retention rules could prevent AI supplier and external-component due diligence from operating consistently." ], "recommendedArtifacts": [ "AI vendor assessments.", "procurement/vendor onboarding records.", "security/privacy review records.", "contract/responsibility matrix.", "periodic review evidence.", "AI vendor assessment.", "external component inventory.", "approved supplier/model/dataset/API/plugin list.", "supplier due diligence checklist.", "security/privacy review." ] }, "testOfEffectiveness": { "overallTestObjectivePurpose": "Confirm that AI supplier and external-component due diligence operated during the review period in line with its documented criteria, ownership, frequency, evidence requirements, and exception path.", "recommendedSamplingStrategy": "Use Third-party AI suppliers, external components, embedded vendor AI features, APIs, datasets, plugins, and AI services. as the primary population and AI vendor/component due-diligence record. as the sample unit. Reconcile the population to the source system, register, workflow, ticket queue, monitoring output, or log extract. Stratify by system, business unit, model tier, lifecycle stage, vendor, region, or risk rating where operation differs. Add judgmental selections for high-risk, changed, exception, override, incident, failed-check, or near-threshold items. Use full-population analytics when the data is complete and the test criterion is deterministic.", "recommendedSampleSize": "Minimum suggestion is 20 event records where the event population supports sampling. If fewer events exist, test the full population and include high-risk approvals, overrides, incidents, material model changes, and exceptions.", "detailedTestSteps": [ "Build the population for AI supplier and external-component due diligence from the system, workflow, register, log, or approval repository that records control execution. Document extraction parameters, date range, filters, and completeness reconciliation.", "Sample third-party AI acquisitions/use approvals and verify supplier due diligence was completed before approval/use and during periodic review if required.", "Sample AI vendors/external models/datasets/APIs/plugins approved or reviewed in the period and test whether due diligence was completed before use, responsibilities and supplier requirements were documented, risk/conformity/security/privacy evidence was reviewed, issues were escalated, and periodic reviews occurred.", "Sample external model/dataset/API onboarding and review records to verify provenance and usage-limit review occurred.", "Sample third-party plugins/APIs and verify due diligence, approvals, documentation, monitoring, vulnerability notifications, exceptions, and decommissioning decisions occurred as required.", "Sample external datasets/models/adapters and verify due diligence, approval and ongoing monitoring evidence.", "For each selected item, verify the control was performed by the expected owner or reviewer, at the required point in the process, against the defined criteria, and before the AI decision, release, approval, use, or event proceeded where the design requires prior control execution.", "Compare retained evidence to the control design and confirm completeness, accuracy, reviewer sign-off, timestamps, linkage to the AI system/use case/model/vendor/event, and consistency with the required cadence.", "Trace exceptions, overrides, failed checks, late reviews, unresolved actions, and risk acceptances to escalation, remediation, approval, retesting, or closure evidence." ], "recommendedArtifacts": [ "AI vendor assessments.", "procurement/vendor onboarding records.", "security/privacy review records.", "contract/responsibility matrix.", "periodic review evidence.", "AI vendor assessment.", "external component inventory.", "approved supplier/model/dataset/API/plugin list.", "supplier due diligence checklist.", "security/privacy review." ] } }, "expectedEvidenceArtifacts": [ "AI vendor assessments", "procurement/vendor onboarding records", "security/privacy review records", "contract/responsibility matrix", "periodic review evidence", "AI vendor assessment", "external component inventory", "approved supplier/model/dataset/API/plugin list", "supplier due diligence checklist", "security/privacy review", "model card or supplier documentation", "provider/deployer responsibility matrix", "third-party conformity/attestation evidence", "periodic review record", "exception/corrective action record", "supplier due-diligence checklist", "model card/supplier documentation", "terms/EULA review", "approval/exception record", "vendor due diligence records", "security/privacy assessments", "contract clauses/responsibility matrix", "vulnerability reports", "monitoring reviews", "decommission/exception records", "vendor assessment", "model/dataset cards", "supplier monitoring records", "vendor due-diligence questionnaire", "security attestations", "responsibility matrix", "access logs", "supplier review/renewal records" ] }, { "controlId": "ctl-ai-supply-chain-integrity-verification", "title": "AI supply-chain integrity verification", "objective": "Verify the integrity, provenance, security, and vulnerability posture of AI model, dataset, package, platform, and dependency supply chains.", "description": "Maintain and test controls for external AI component provenance, dependency inventories, package/model/dataset authenticity, vulnerability monitoring, secure repositories, signed or tamper-resistant component records, and model/data/software supply-chain verification before integration and during operation.", "controlFamily": "third-party-and-supply-chain", "sourceLabels": [ "ISACA AI Audit Toolkit 2024: (Aggregate AI Control Library: ES-SC-01 Supply Chain Verification)", "ISACA AAIA Review Manual: Chapter 02 Part F AI supply-chain threats", "OWASP: LLM05; ML Top 10; ML06" ], "auditProcedure": { "auditProcedureName": "Validate AI supply-chain integrity verification", "auditProcedureDescription": "Trace the control for AI supply-chain integrity verification from the event, decision, or cadence that triggers it through execution, review, exception handling, and retained evidence. Use the control objective as the reference point. Verify the integrity, provenance, security, and vulnerability posture of AI model, dataset, package, platform, and dependency supply chains. Confirm that the described control activity is performed through clear criteria, accountable ownership, defined timing, complete population coverage, reliable source records, and evidence that exceptions are escalated and resolved. Where the control relies on automated monitoring, workflow approval, or manual expert review, verify that handoffs and evidence repositories are clear enough for repeatable audit testing. The work should cover the activity defined for the control. Maintain and test controls for external AI component provenance, dependency inventories, package/model/dataset authenticity, vulnerability monitoring, secure repositories, signed or tamper-resistant component records, and model/data/software supply-chain verification before integration and during operation.", "testOfDesign": { "overallTestObjectivePurpose": "Determine whether AI supply-chain integrity verification is designed with criteria, ownership, timing, evidence, and exception handling precise enough to achieve the objective. Verify the integrity, provenance, security, and vulnerability posture of AI model, dataset, package, platform, and dependency supply chains.", "detailedTestSteps": [ "Inspect supply-chain verification policy, model/data/software dependency inventory design, SBOM or equivalent requirements, provenance criteria, package/model authenticity/signature verification steps, repository/model-hub approval rules, vulnerability scanning cadence, MLOps access/exposure controls, and exception/remediation workflow.", "Inspect the documented AI supply-chain integrity verification policy, standard, workflow, configuration, checklist, approval template, or procedure and trace each required element to the stated control objective.", "Confirm that the AI supply-chain integrity verification design names the accountable owner (AI Security / MLOps / Engineering with Third-Party Risk and Procurement oversight) and expected performance cadence (Before integration/release, continuous or periodic vulnerability monitoring, event-driven on dependency/model/dataset/vendor update), including reviewer, delegate, and escalation responsibilities where applicable.", "Check that the design defines the in-scope population (All externally sourced AI models, datasets, code packages, plugins, MLOps tools, deployment platforms, APIs, and software/hardware dependencies used by AI systems.), sampling unit (External component or dependency used by an AI system/release.), and process/system boundary (third-party-and-supply-chain process boundary) so testing can be repeated by another auditor.", "Walk through one representative control occurrence, AI lifecycle event, approval, change, exception, or monitoring record covered by AI supply-chain integrity verification. Trace it from trigger through decision, escalation, and evidence retention and identify where the control prevents, detects, or corrects the targeted risk.", "Challenge whether bypasses, undocumented judgment, missing thresholds, unclear reviewer authority, weak segregation, or absent retention rules could prevent AI supply-chain integrity verification from operating consistently." ], "recommendedArtifacts": [ "supply-chain verification guideline.", "AI/ML dependency inventory.", "SBOM or equivalent component list.", "model/data provenance records.", "package signature or hash verification logs.", "dependency/vulnerability scan results.", "trusted repository/model-hub approval records.", "MLOps platform access review.", "verification report.", "remediation ticket/exception record." ] }, "testOfEffectiveness": { "overallTestObjectivePurpose": "Confirm that AI supply-chain integrity verification operated during the review period in line with its documented criteria, ownership, frequency, evidence requirements, and exception path.", "recommendedSamplingStrategy": "Use All externally sourced AI models, datasets, code packages, plugins, MLOps tools, deployment platforms, APIs, and software/hardware dependencies used by AI systems. as the primary population and External component or dependency used by an AI system/release. as the sample unit. Reconcile the population to the source system, register, workflow, ticket queue, monitoring output, or log extract. Stratify by system, business unit, model tier, lifecycle stage, vendor, region, or risk rating where operation differs. Add judgmental selections for high-risk, changed, exception, override, incident, failed-check, or near-threshold items. Use full-population analytics when the data is complete and the test criterion is deterministic.", "recommendedSampleSize": "Minimum suggestion is 20 daily-or-more-frequent executions, alerts, log entries, or monitoring records after population completeness and control frequency are confirmed. Use full-population analytics where criteria are deterministic.", "detailedTestSteps": [ "Build the population for AI supply-chain integrity verification from the system, workflow, register, log, or approval repository that records control execution. Document extraction parameters, date range, filters, and completeness reconciliation.", "Sample integrated external models/datasets/packages/plugins/platform dependencies and test whether provenance/authenticity checks, vulnerability scans, approval records, secure-source checks, MLOps access/exposure controls, and remediation/exception records exist and operated before use or at required intervals.", "For each selected item, verify the control was performed by the expected owner or reviewer, at the required point in the process, against the defined criteria, and before the AI decision, release, approval, use, or event proceeded where the design requires prior control execution.", "Compare retained evidence to the control design and confirm completeness, accuracy, reviewer sign-off, timestamps, linkage to the AI system/use case/model/vendor/event, and consistency with the required cadence.", "Trace exceptions, overrides, failed checks, late reviews, unresolved actions, and risk acceptances to escalation, remediation, approval, retesting, or closure evidence." ], "recommendedArtifacts": [ "supply-chain verification guideline.", "AI/ML dependency inventory.", "SBOM or equivalent component list.", "model/data provenance records.", "package signature or hash verification logs.", "dependency/vulnerability scan results.", "trusted repository/model-hub approval records.", "MLOps platform access review.", "verification report.", "remediation ticket/exception record." ] } }, "expectedEvidenceArtifacts": [ "supply-chain verification guideline", "AI/ML dependency inventory", "SBOM or equivalent component list", "model/data provenance records", "package signature or hash verification logs", "dependency/vulnerability scan results", "trusted repository/model-hub approval records", "MLOps platform access review", "verification report", "remediation ticket/exception record" ] }, { "controlId": "ctl-ai-system-inventory-and-reconciliation", "title": "AI system inventory and reconciliation control", "objective": "Ensure AI systems, models, use cases, automations, owners, lifecycle stages, vendors, data/resource dependencies, classifications, and governance/control status are visible, current, and available for risk management, oversight, and audit scoping.", "description": "Maintain a complete, current, periodically reconciled AI inventory/catalog covering material AI use, including AIS name, version, license/cost where relevant, deployment/access method, purpose/intended use, frequency of use, stakeholders, accountable owner, business/process owner, model/use-case linkage, data/tooling/system/human resources, vendor/third-party details, classification/risk status, lifecycle stage, approval/control status, monitoring status, and decommissioning status. Refresh at least annually and when intake, procurement, architecture, project, release, technical-discovery, survey, or interview evidence indicates new or changed AI use.", "controlFamily": "governance-and-accountability", "sourceLabels": [ "ISACA AAIA Review Manual: Ch.03 Part A (AI asset identification and inventory procedures); Documentation; Inventory Objectives and Procedures; Inventory and Data Gathering Methods", "ISO/IEC 42001: A.4.2; A.4.6; A.4", "ISO/IEC 5338: (portfolio, knowledge management, stakeholder requirements); 6.2.3; 6.2.6; 6.4.2", "NIST AI RMF Playbook: GOVERN 1.6; MAP 2.1; MANAGE 1.1", "NIST AI RMF 1.0", "Gartner: AI Governance (model inventory / AI usage review): Audit Activities; AI Governance / Internal Audit risk process guidance" ], "auditProcedure": { "auditProcedureName": "Review AI system inventory and reconciliation control", "auditProcedureDescription": "Trace the control for AI system inventory and reconciliation control from the event, decision, or cadence that triggers it through execution, review, exception handling, and retained evidence. Use the control objective as the reference point. Ensure AI systems, models, use cases, automations, owners, lifecycle stages, vendors, data/resource dependencies, classifications, and governance/control status are visible, current, and available for risk management, oversight, and audit scoping. Confirm that the described control activity is performed through clear criteria, accountable ownership, defined timing, complete population coverage, reliable source records, and evidence that exceptions are escalated and resolved. Where the control relies on automated monitoring, workflow approval, or manual expert review, verify that handoffs and evidence repositories are clear enough for repeatable audit testing. The work should cover the activity defined for the control. Maintain a complete, current, periodically reconciled AI inventory/catalog covering material AI use, including AIS name, version, license/cost where relevant, deployment/access method, purpose/intended use, frequency of use, stakeholders, accountable owner, business/process owner, model/use-case linkage, data/tooling/system/human resources, vendor/third-party details, classification/risk status, lifecycle stage, approval/control status, monitoring status, and decommissioning status. Refresh at least annually and when intake, procurement, architecture, project, release, technical-discovery, survey, or interview evidence indicates new or changed AI use.", "testOfDesign": { "overallTestObjectivePurpose": "Determine whether AI system inventory and reconciliation control is designed with criteria, ownership, timing, evidence, and exception handling precise enough to achieve the objective. Ensure AI systems, models, use cases, automations, owners, lifecycle stages, vendors, data/resource dependencies, classifications, and governance/control status are visible, current, and available for risk management, oversight, and audit scoping.", "detailedTestSteps": [ "Inspect inventory policy/standard, field dictionary, accountable owner/stewardship model, refresh cadence, intake/procurement/architecture/release reconciliation design, discovery methods, non-punitive communication, classification linkage, lifecycle/status fields, and evidence-retention requirements.", "Inspect the documented AI system inventory and reconciliation control policy, standard, workflow, configuration, checklist, approval template, or procedure and trace each required element to the stated control objective.", "Confirm that the AI system inventory and reconciliation control design names the accountable owner (AI governance lead, AI inventory steward, CDO/CIO/AI governance committee, business unit owners accountable for individual entries.) and expected performance cadence (At least annually and event-driven on new AI intake, procurement, deployment, material change, retirement, or discovery of shadow/embedded AI.), including reviewer, delegate, and escalation responsibilities where applicable.", "Check that the design defines the in-scope population (All known and discoverable AI systems, models, use cases, automations, embedded vendor AI features, third-party AI services, and material AI-enabled business processes within the defined risk universe scope.), sampling unit (AI inventory entry / AI system / model-use-case pairing / vendor AI feature / newly discovered AI use item.), and process/system boundary (governance-and-accountability process boundary) so testing can be repeated by another auditor.", "Walk through one representative control occurrence, AI lifecycle event, approval, change, exception, or monitoring record covered by AI system inventory and reconciliation control. Trace it from trigger through decision, escalation, and evidence retention and identify where the control prevents, detects, or corrects the targeted risk.", "Challenge whether bypasses, undocumented judgment, missing thresholds, unclear reviewer authority, weak segregation, or absent retention rules could prevent AI system inventory and reconciliation control from operating consistently." ], "recommendedArtifacts": [ "AI inventory/catalog/register export.", "inventory data dictionary / minimum field list.", "AI inventory policy/procedure.", "AI governance committee or owner mandate.", "AI intake and approval tickets.", "procurement/vendor AI records.", "architecture/security/cloud review records.", "model registry/model cards.", "system diagrams/dataflow diagrams.", "tool usage / DLP / CASB / network discovery reports." ] }, "testOfEffectiveness": { "overallTestObjectivePurpose": "Confirm that AI system inventory and reconciliation control operated during the review period in line with its documented criteria, ownership, frequency, evidence requirements, and exception path.", "recommendedSamplingStrategy": "Use All known and discoverable AI systems, models, use cases, automations, embedded vendor AI features, third-party AI services, and material AI-enabled business processes within the defined risk universe scope. as the primary population and AI inventory entry / AI system / model-use-case pairing / vendor AI feature / newly discovered AI use item. as the sample unit. Reconcile the population to the source system, register, workflow, ticket queue, monitoring output, or log extract. Stratify by system, business unit, model tier, lifecycle stage, vendor, region, or risk rating where operation differs. Add judgmental selections for high-risk, changed, exception, override, incident, failed-check, or near-threshold items. Use full-population analytics when the data is complete and the test criterion is deterministic.", "recommendedSampleSize": "Minimum suggestion is the annual execution plus interim changes, exceptions, approvals, and triggering events relevant to the control. Annual controls do not have a fixed standard sample size in the matrix.", "detailedTestSteps": [ "Build the population for AI system inventory and reconciliation control from the system, workflow, register, log, or approval repository that records control execution. Document extraction parameters, date range, filters, and completeness reconciliation.", "Verify the control design or operating evidence addresses the requirement in practical terms, For the audit period, reconcile the AI inventory population to source populations such as AI intake tickets, procurement/vendor records, architecture review records, cloud/tool usage logs, model registries, project/release records, surveys/interviews, and technical discovery outputs, sample AI inventory entries to verify required fields, owner approval, classification, lifecycle stage, vendor/resource linkages, refresh evidence, and exception escalation, sample newly discovered/shadow AI items for timely registration and governance routing.", "For each selected item, verify the control was performed by the expected owner or reviewer, at the required point in the process, against the defined criteria, and before the AI decision, release, approval, use, or event proceeded where the design requires prior control execution.", "Compare retained evidence to the control design and confirm completeness, accuracy, reviewer sign-off, timestamps, linkage to the AI system/use case/model/vendor/event, and consistency with the required cadence.", "Trace exceptions, overrides, failed checks, late reviews, unresolved actions, and risk acceptances to escalation, remediation, approval, retesting, or closure evidence." ], "recommendedArtifacts": [ "AI inventory/catalog/register export.", "inventory data dictionary / minimum field list.", "AI inventory policy/procedure.", "AI governance committee or owner mandate.", "AI intake and approval tickets.", "procurement/vendor AI records.", "architecture/security/cloud review records.", "model registry/model cards.", "system diagrams/dataflow diagrams.", "tool usage / DLP / CASB / network discovery reports." ] } }, "expectedEvidenceArtifacts": [ "AI inventory/catalog/register export", "inventory data dictionary / minimum field list", "AI inventory policy/procedure", "AI governance committee or owner mandate", "AI intake and approval tickets", "procurement/vendor AI records", "architecture/security/cloud review records", "model registry/model cards", "system diagrams/dataflow diagrams", "tool usage / DLP / CASB / network discovery reports", "survey and interview instruments/responses", "annual refresh attestations", "change/release/project records", "classification/risk assessment records", "exception/unregistered AI issue logs", "committee minutes/status reports" ] }, { "controlId": "ctl-ai-technical-documentation", "title": "AI technical documentation and audit traceability", "objective": "Provide sufficient technical evidence for safe operation, oversight, assurance, and regulatory or audit review.", "description": "Maintain current AI technical documentation covering purpose, design/architecture, data/model/version references, limitations, validation evidence, controls, ownership, changes, monitoring, incidents where applicable, and audit traceability.", "controlFamily": "documentation-and-transparency", "sourceLabels": [ "ISACA AI Audit Toolkit 2024: Aggregate AI Control Library; AI Life Cycle Management / AI Model Governance controls; AI Life Cycle Management; Explainability Integration", "ISACA AAIA Review Manual: AI decision-making documentation and control types; Ch.03 Part A; Chapter 03 Part A", "ISO/IEC 42001: A.4.4; A.6.2; A.8.5; B.8.5; B.6.2", "ISO/IEC 5338: 6.3.6", "NIST AI RMF Playbook: MANAGE 4.3; MAP 1.1; MEASURE 2.1; MEASURE 2.6", "NIST AI RMF 1.0: GOVERN 4.2; MAP 2.2; MEASURE 2.9; MEASURE 2.1; 2.3; 2.5; 2.9", "EU AI Act: Article 11; Article 18; Article 53" ], "auditProcedure": { "auditProcedureName": "Review AI technical documentation and audit traceability", "auditProcedureDescription": "Trace the control for AI technical documentation and audit traceability from the event, decision, or cadence that triggers it through execution, review, exception handling, and retained evidence. Use the control objective as the reference point. Provide sufficient technical evidence for safe operation, oversight, assurance, and regulatory or audit review. Confirm that the described control activity is performed through clear criteria, accountable ownership, defined timing, complete population coverage, reliable source records, and evidence that exceptions are escalated and resolved. Where the control relies on automated monitoring, workflow approval, or manual expert review, verify that handoffs and evidence repositories are clear enough for repeatable audit testing. The work should cover the activity defined for the control. Maintain current AI technical documentation covering purpose, design/architecture, data/model/version references, limitations, validation evidence, controls, ownership, changes, monitoring, incidents where applicable, and audit traceability.", "testOfDesign": { "overallTestObjectivePurpose": "Determine whether AI technical documentation and audit traceability is designed with criteria, ownership, timing, evidence, and exception handling precise enough to achieve the objective. Provide sufficient technical evidence for safe operation, oversight, assurance, and regulatory or audit review.", "detailedTestSteps": [ "Inspect technical documentation requirements for scientific rationale, validation, limitations, and traceability fields.", "Inspect technical documentation standards/templates and required AI documentation fields, including data/model/architecture/lineage references, roles, event logs, change updates, and audit traceability expectations.", "Inspect required documentation fields for production promotion and confirm they include architecture, data, models, versions, ownership, controls, monitoring and traceability.", "Verify documentation captures downstream output sinks, trust boundaries, validation/encoding rules, owners, limitations, monitoring, and change triggers.", "Inspect whether technical documentation standards include AI tool/plugin components, data/control flows, permission boundaries, validations, owners, limitations, monitoring, incident handling, and change traceability.", "Inspect the documented AI technical documentation and audit traceability policy, standard, workflow, configuration, checklist, approval template, or procedure and trace each required element to the stated control objective.", "Confirm that the AI technical documentation and audit traceability design names the accountable owner (Model owner / AI governance / validation owner) and expected performance cadence (At development/approval and after material change), including reviewer, delegate, and escalation responsibilities where applicable.", "Check that the design defines the in-scope population (AI systems/use cases with technical documentation obligations), sampling unit (Documentation package or AI system record), and process/system boundary (documentation-and-transparency process boundary) so testing can be repeated by another auditor.", "Walk through one representative control occurrence, AI lifecycle event, approval, change, exception, or monitoring record covered by AI technical documentation and audit traceability. Trace it from trigger through decision, escalation, and evidence retention and identify where the control prevents, detects, or corrects the targeted risk.", "Challenge whether bypasses, undocumented judgment, missing thresholds, unclear reviewer authority, weak segregation, or absent retention rules could prevent AI technical documentation and audit traceability from operating consistently." ], "recommendedArtifacts": [ "technical documentation.", "validation records.", "model cards.", "system cards.", "traceability matrix.", "architecture diagrams.", "DFDs/process flows.", "system design records.", "validation reports.", "event logs." ] }, "testOfEffectiveness": { "overallTestObjectivePurpose": "Confirm that AI technical documentation and audit traceability operated during the review period in line with its documented criteria, ownership, frequency, evidence requirements, and exception path.", "recommendedSamplingStrategy": "Use AI systems/use cases with technical documentation obligations as the primary population and Documentation package or AI system record as the sample unit. Reconcile the population to the source system, register, workflow, ticket queue, monitoring output, or log extract. Stratify by system, business unit, model tier, lifecycle stage, vendor, region, or risk rating where operation differs. Add judgmental selections for high-risk, changed, exception, override, incident, failed-check, or near-threshold items. Use full-population analytics when the data is complete and the test criterion is deterministic.", "recommendedSampleSize": "Minimum suggestion is 20 event records where the event population supports sampling. If fewer events exist, test the full population and include high-risk approvals, overrides, incidents, material model changes, and exceptions.", "detailedTestSteps": [ "Build the population for AI technical documentation and audit traceability from the system, workflow, register, log, or approval repository that records control execution. Document extraction parameters, date range, filters, and completeness reconciliation.", "Sample documentation packages and verify current, complete, retrievable validation and limitation evidence.", "Sample AI systems and verify technical documentation is current, complete for data/model/architecture/change/monitoring elements, linked to lineage/provenance records, and retained for audit review.", "Sample promoted AI pilots and verify required technical documentation was complete/current at approval and updated after production release.", "Sample features/releases and verify documentation matches implemented output controls and retained validation/monitoring evidence.", "Sample deployed AI tools/plugins and verify technical documentation is current, complete, approved, and traceable to tests, logs, changes, and incidents.", "For each selected item, verify the control was performed by the expected owner or reviewer, at the required point in the process, against the defined criteria, and before the AI decision, release, approval, use, or event proceeded where the design requires prior control execution.", "Compare retained evidence to the control design and confirm completeness, accuracy, reviewer sign-off, timestamps, linkage to the AI system/use case/model/vendor/event, and consistency with the required cadence.", "Trace exceptions, overrides, failed checks, late reviews, unresolved actions, and risk acceptances to escalation, remediation, approval, retesting, or closure evidence." ], "recommendedArtifacts": [ "technical documentation.", "validation records.", "model cards.", "system cards.", "traceability matrix.", "architecture diagrams.", "DFDs/process flows.", "system design records.", "validation reports.", "event logs." ] } }, "expectedEvidenceArtifacts": [ "technical documentation", "validation records", "model cards", "system cards", "traceability matrix", "architecture diagrams", "DFDs/process flows", "system design records", "validation reports", "event logs", "change records", "monitoring records", "audit traceability matrix", "technical design document", "model/version register", "dataflow diagrams", "control evidence pack", "monitoring/runbook documentation", "output sink inventory", "validation rules", "test evidence", "audit traceability records", "architecture/DFDs", "component inventory", "ownership records", "monitoring/incident/change links", "architecture/data-flow diagrams", "event/prompt/model logs", "version history", "data lineage", "incident records", "log data dictionary", "event taxonomy", "monitoring SOP", "incident investigation runbook", "model card/system card", "data/model lineage records", "explanation evaluation records", "audit logs", "AI system register/model catalog", "technical documentation pack", "data-flow diagrams/process flows", "model cards/system cards", "data documentation/datasheets", "validation/TEVV reports", "risk/impact assessment records", "monitoring plans and outputs", "change logs/release approvals", "incident/problem records", "stakeholder disclosure records", "high-risk registration/conformity documentation where applicable", "TEVV reports", "requirements traceability", "model/system card", "capability eval report", "red-team report", "test logs", "risk acceptance approval", "monitoring design", "incident/change records", "model/system cards", "resource inventories", "impact assessments", "supplier/cloud sustainability reports" ] }, { "controlId": "ctl-ai-use-case-value-feasibility-prioritization", "title": "AI use-case value and feasibility prioritization", "objective": "Ensure AI opportunities are prioritized using explicit business-value and feasibility criteria before they enter the funded portfolio.", "description": "Maintain a repeatable scoring and challenge process for candidate AI use cases that captures business value dimensions, feasibility dimensions, weighting, stakeholder review, refinement/challenge, and approval rationale before inclusion in the AI portfolio or roadmap.", "controlFamily": "portfolio-and-value-management", "sourceLabels": [ "Gartner: AI Data; AI Engineering; AI Roadmap; AI Value / AI Strategy" ], "auditProcedure": { "auditProcedureName": "Test AI use-case value and feasibility prioritization", "auditProcedureDescription": "Trace the control for AI use-case value and feasibility prioritization from the event, decision, or cadence that triggers it through execution, review, exception handling, and retained evidence. Use the control objective as the reference point. Ensure AI opportunities are prioritized using explicit business-value and feasibility criteria before they enter the funded portfolio. Confirm that the described control activity is performed through clear criteria, accountable ownership, defined timing, complete population coverage, reliable source records, and evidence that exceptions are escalated and resolved. Where the control relies on automated monitoring, workflow approval, or manual expert review, verify that handoffs and evidence repositories are clear enough for repeatable audit testing. The work should cover the activity defined for the control. Maintain a repeatable scoring and challenge process for candidate AI use cases that captures business value dimensions, feasibility dimensions, weighting, stakeholder review, refinement/challenge, and approval rationale before inclusion in the AI portfolio or roadmap.", "testOfDesign": { "overallTestObjectivePurpose": "Determine whether AI use-case value and feasibility prioritization is designed with criteria, ownership, timing, evidence, and exception handling precise enough to achieve the objective. Ensure AI opportunities are prioritized using explicit business-value and feasibility criteria before they enter the funded portfolio.", "detailedTestSteps": [ "Inspect whether the use-case prioritization method defines value dimensions, feasibility dimensions, weighting, scorer roles, challenge process, approval thresholds and evidence retention.", "Inspect the documented AI use-case value and feasibility prioritization policy, standard, workflow, configuration, checklist, approval template, or procedure and trace each required element to the stated control objective.", "Confirm that the AI use-case value and feasibility prioritization design names the accountable owner (AI portfolio manager, AI strategy lead, business sponsor or AI governance board) and expected performance cadence (Per intake/prioritization cycle, refreshed for material strategy or market/readiness changes), including reviewer, delegate, and escalation responsibilities where applicable.", "Check that the design defines the in-scope population (Candidate AI use cases evaluated for portfolio inclusion), sampling unit (AI use-case candidate or portfolio decision record), and process/system boundary (portfolio-and-value-management process boundary) so testing can be repeated by another auditor.", "Walk through one representative control occurrence, AI lifecycle event, approval, change, exception, or monitoring record covered by AI use-case value and feasibility prioritization. Trace it from trigger through decision, escalation, and evidence retention and identify where the control prevents, detects, or corrects the targeted risk.", "Challenge whether bypasses, undocumented judgment, missing thresholds, unclear reviewer authority, weak segregation, or absent retention rules could prevent AI use-case value and feasibility prioritization from operating consistently." ], "recommendedArtifacts": [ "use-case register.", "intake forms.", "value/feasibility scorecards.", "scoring guidance.", "stakeholder workshop outputs.", "portfolio board minutes.", "approval/rejection rationale.", "pipeline visualization." ] }, "testOfEffectiveness": { "overallTestObjectivePurpose": "Confirm that AI use-case value and feasibility prioritization operated during the review period in line with its documented criteria, ownership, frequency, evidence requirements, and exception path.", "recommendedSamplingStrategy": "Use Candidate AI use cases evaluated for portfolio inclusion as the primary population and AI use-case candidate or portfolio decision record as the sample unit. Use representative random sampling where the population is homogeneous. Stratify where ownership, geography, business process, AI use case, model type, third party, or risk tier changes control operation. Reserve judgmental selections for documented high-risk, unusual, changed, exception, or override items.", "recommendedSampleSize": "Minimum suggestion is 20 event records where the event population supports sampling. If fewer events exist, test the full population and include high-risk approvals, overrides, incidents, material model changes, and exceptions.", "detailedTestSteps": [ "Build the population for AI use-case value and feasibility prioritization from the system, workflow, register, log, or approval repository that records control execution. Document extraction parameters, date range, filters, and completeness reconciliation.", "Sample candidate/approved use cases and test whether scoring was complete, supported by evidence, challenged where needed, and used in prioritization/funding decisions.", "For each selected item, verify the control was performed by the expected owner or reviewer, at the required point in the process, against the defined criteria, and before the AI decision, release, approval, use, or event proceeded where the design requires prior control execution.", "Compare retained evidence to the control design and confirm completeness, accuracy, reviewer sign-off, timestamps, linkage to the AI system/use case/model/vendor/event, and consistency with the required cadence.", "Trace exceptions, overrides, failed checks, late reviews, unresolved actions, and risk acceptances to escalation, remediation, approval, retesting, or closure evidence." ], "recommendedArtifacts": [ "use-case register.", "intake forms.", "value/feasibility scorecards.", "scoring guidance.", "stakeholder workshop outputs.", "portfolio board minutes.", "approval/rejection rationale.", "pipeline visualization." ] } }, "expectedEvidenceArtifacts": [ "use-case register", "intake forms", "value/feasibility scorecards", "scoring guidance", "stakeholder workshop outputs", "portfolio board minutes", "approval/rejection rationale", "pipeline visualization" ] }, { "controlId": "ctl-ai-user-instructions-explainability", "title": "AI user instructions, limitations, and explainability documentation", "objective": "Ensure users and oversight functions understand AI capabilities, limitations, instructions, and decision support boundaries.", "description": "Provide current, role-appropriate instructions, capability and limitation disclosures, intended/prohibited use guidance, explanation or interpretation support, human oversight and override expectations, and update evidence so users and reviewers understand how to rely on AI outputs safely.", "controlFamily": "documentation-and-transparency", "sourceLabels": [ "ISACA AI Audit Toolkit 2024: Aggregate AI Control Library; AI Model Governance controls; ISO/IEC 42001 (Information for Users)", "ISACA AAIA Review Manual: AI Risk Management / trustworthy characteristics", "ISO/IEC 42001: A.8.2; A.8.5; A.8; B.8; B.8.2; A.9.4; A.9", "NIST AI RMF Playbook: documentation and transparency actions; MAP 2.2; MEASURE 2.9", "NIST AI RMF 1.0: MAP 1.1; MAP 2.2; MEASURE 2.9", "Gartner: AI Engineering / Governance; Trustworthiness; AI Engineering / Observability & Explainability", "MIT AI Risk Repository: 7.4; 7.4 Lack of transparency or interpretability", "OWASP: Gen AI Security Project; LLM01; LLM09", "EU AI Act: Article 13; Article 26; Article 53" ], "auditProcedure": { "auditProcedureName": "Validate AI user instructions, limitations, and explainability documentation", "auditProcedureDescription": "Trace the control for AI user instructions, limitations, and explainability documentation from the event, decision, or cadence that triggers it through execution, review, exception handling, and retained evidence. Use the control objective as the reference point. Ensure users and oversight functions understand AI capabilities, limitations, instructions, and decision support boundaries. Confirm that the described control activity is performed through clear criteria, accountable ownership, defined timing, complete population coverage, reliable source records, and evidence that exceptions are escalated and resolved. Where the control relies on automated monitoring, workflow approval, or manual expert review, verify that handoffs and evidence repositories are clear enough for repeatable audit testing. The work should cover the activity defined for the control. Provide current, role-appropriate instructions, capability and limitation disclosures, intended/prohibited use guidance, explanation or interpretation support, human oversight and override expectations, and update evidence so users and reviewers understand how to rely on AI outputs safely.", "testOfDesign": { "overallTestObjectivePurpose": "Determine whether AI user instructions, limitations, and explainability documentation is designed with criteria, ownership, timing, evidence, and exception handling precise enough to achieve the objective. Ensure users and oversight functions understand AI capabilities, limitations, instructions, and decision support boundaries.", "detailedTestSteps": [ "Inspect whether instructions/limitation standards require clear prohibition of unsupported scientific/predictive claims.", "Inspect user instructions, capability/limitation disclosures, warning/labeling design, user education documentation requirements, and update controls after material AI changes.", "Inspect user documentation design for purpose, intended use, limitations, interaction/override instructions, support/contact channels, updates, and accessibility., For relevant use cases, inspect whether user instructions define permitted/prohibited AI-generated content use, attribution expectations, human review boundaries, and limitations.", "Inspect whether user documentation states intended use, prohibited/off-label use, capabilities, limitations and explanation/oversight expectations.", "Inspect guidance content for prompt-injection/input-manipulation warnings, verification duties, prohibited uses, and escalation routes.", "Inspect the documented AI user instructions, limitations, and explainability documentation policy, standard, workflow, configuration, checklist, approval template, or procedure and trace each required element to the stated control objective.", "Confirm that the AI user instructions, limitations, and explainability documentation design names the accountable owner (AI product owner / governance owner / documentation owner) and expected performance cadence (Before deployment/reliance and after material change), including reviewer, delegate, and escalation responsibilities where applicable.", "Check that the design defines the in-scope population (AI systems used by business users or oversight functions), sampling unit (User instruction artifact or limitation disclosure), and process/system boundary (documentation-and-transparency process boundary) so testing can be repeated by another auditor.", "Walk through one representative control occurrence, AI lifecycle event, approval, change, exception, or monitoring record covered by AI user instructions, limitations, and explainability documentation. Trace it from trigger through decision, escalation, and evidence retention and identify where the control prevents, detects, or corrects the targeted risk.", "Challenge whether bypasses, undocumented judgment, missing thresholds, unclear reviewer authority, weak segregation, or absent retention rules could prevent AI user instructions, limitations, and explainability documentation from operating consistently." ], "recommendedArtifacts": [ "user instructions.", "capability/limitation disclosures.", "prohibited-use guidance.", "document update history.", "AI use policy or operating guidance.", "capability/limitation documentation.", "AI-generated content labels/warnings.", "user education records.", "user acknowledgement records.", "document update/change log." ] }, "testOfEffectiveness": { "overallTestObjectivePurpose": "Confirm that AI user instructions, limitations, and explainability documentation operated during the review period in line with its documented criteria, ownership, frequency, evidence requirements, and exception path.", "recommendedSamplingStrategy": "Use AI systems used by business users or oversight functions as the primary population and User instruction artifact or limitation disclosure as the sample unit. Reconcile the population to the source system, register, workflow, ticket queue, monitoring output, or log extract. Stratify by system, business unit, model tier, lifecycle stage, vendor, region, or risk rating where operation differs. Add judgmental selections for high-risk, changed, exception, override, incident, failed-check, or near-threshold items. Use full-population analytics when the data is complete and the test criterion is deterministic.", "recommendedSampleSize": "Minimum suggestion is 20 event records where the event population supports sampling. If fewer events exist, test the full population and include high-risk approvals, overrides, incidents, material model changes, and exceptions.", "detailedTestSteps": [ "Build the population for AI user instructions, limitations, and explainability documentation from the system, workflow, register, log, or approval repository that records control execution. Document extraction parameters, date range, filters, and completeness reconciliation.", "Sample user instructions/model cards and verify limitations/prohibited claims align to validity assessment outcomes.", "Sample deployed AI tools/use cases and test whether users received current instructions/limitations/education before use and whether interfaces/documents present required warnings and reliance boundaries.", "Sample deployed AI tools and verify users received/currently access instructions and limitation documentation, test update evidence after material change.", "Sample AI user-facing documentation and verify current instructions disclose limitations and appropriate-use/attribution boundaries, test whether sampled users received or acknowledged instructions where required.", "Sample users/systems to verify current guidance was issued, acknowledged where required, and updated after material changes.", "For each selected item, verify the control was performed by the expected owner or reviewer, at the required point in the process, against the defined criteria, and before the AI decision, release, approval, use, or event proceeded where the design requires prior control execution.", "Compare retained evidence to the control design and confirm completeness, accuracy, reviewer sign-off, timestamps, linkage to the AI system/use case/model/vendor/event, and consistency with the required cadence.", "Trace exceptions, overrides, failed checks, late reviews, unresolved actions, and risk acceptances to escalation, remediation, approval, retesting, or closure evidence." ], "recommendedArtifacts": [ "user instructions.", "capability/limitation disclosures.", "prohibited-use guidance.", "document update history.", "AI use policy or operating guidance.", "capability/limitation documentation.", "AI-generated content labels/warnings.", "user education records.", "user acknowledgement records.", "document update/change log." ] } }, "expectedEvidenceArtifacts": [ "user instructions", "capability/limitation disclosures", "prohibited-use guidance", "document update history", "AI use policy or operating guidance", "capability/limitation documentation", "AI-generated content labels/warnings", "user education records", "user acknowledgement records", "document update/change log", "feedback/understanding assessments", "user guide", "limitations disclosure", "FAQ/help page", "release/update notices", "training materials", "document review/update history", "acceptable-use guidance", "AI-generated content disclosure/attribution standard", "training/acknowledgement logs", "user guides", "model cards/system cards", "limitation disclosures", "document change history", "user guidance", "admin runbooks", "training/acknowledgement records", "version history", "limitation disclosure", "model card/system card", "documentation change history", "user acknowledgement", "AI user instructions", "technical documentation", "explanation-method validation reports", "AI-use notices/disclosures", "human oversight and override guidance", "impact assessment extracts shared with users where appropriate", "accessibility/usability validation evidence", "change/update history", "training or communication records", "issue/adverse-impact reports", "user guide or operating instructions", "model/system card", "capability/limitation disclosure", "intended/prohibited use statement", "human oversight/override procedure", "training/communication evidence", "versioned instruction update history", "usage monitoring logs against instructions" ] }, { "controlId": "ctl-ai-verification-validation-release-acceptance", "title": "AI verification, validation, and release acceptance control", "objective": "Confirm AI systems meet documented requirements, trustworthiness criteria, risk tolerance, and intended-use expectations before operational reliance or release.", "description": "Define, document, and execute AI verification and validation measures before release, including acceptance criteria, test data selection and representativeness, model/system performance, robustness, safety, bias/fairness, security/resilience where applicable, limitation handling, anomaly resolution, release criteria, and approval evidence.", "controlFamily": "monitoring-and-validation", "sourceLabels": [ "ISACA AAIA Review Manual: Types of AI Controls; Chapter 03 Part A", "ISO/IEC 42001: A.6.2; B.6.2", "ISO/IEC 5338: 6.4.11; 6.4.13; 6.4.14; Verification and Validation processes", "NIST AI RMF 1.0: MEASURE 1.1; MEASURE 2.6; MEASURE 2.1-2", "MITRE: AI Maturity Model; Test & Evaluation: MITRE dimension", "EU AI Act: Article 15; Article 17; Article 9" ], "auditProcedure": { "auditProcedureName": "Validate AI verification, validation, and release acceptance control", "auditProcedureDescription": "Trace the control for AI verification, validation, and release acceptance control from the event, decision, or cadence that triggers it through execution, review, exception handling, and retained evidence. Use the control objective as the reference point. Confirm AI systems meet documented requirements, trustworthiness criteria, risk tolerance, and intended-use expectations before operational reliance or release. Confirm that the described control activity is performed through clear criteria, accountable ownership, defined timing, complete population coverage, reliable source records, and evidence that exceptions are escalated and resolved. Where the control relies on automated monitoring, workflow approval, or manual expert review, verify that handoffs and evidence repositories are clear enough for repeatable audit testing. The work should cover the activity defined for the control. Define, document, and execute AI verification and validation measures before release, including acceptance criteria, test data selection and representativeness, model/system performance, robustness, safety, bias/fairness, security/resilience where applicable, limitation handling, anomaly resolution, release criteria, and approval evidence.", "testOfDesign": { "overallTestObjectivePurpose": "Determine whether AI verification, validation, and release acceptance control is designed with criteria, ownership, timing, evidence, and exception handling precise enough to achieve the objective. Confirm AI systems meet documented requirements, trustworthiness criteria, risk tolerance, and intended-use expectations before operational reliance or release.", "detailedTestSteps": [ "Inspect the V&V/release gate design for documented scope, responsible owner, applicable AI lifecycle stages, test methods/tools, test data selection/representativeness requirements, performance/robustness/safety/bias/security criteria, residual-risk thresholds, deficiency handling, release criteria, approver roles, evidence retention, and links to system requirements and risk tolerance.", "Inspect the documented AI verification, validation, and release acceptance control policy, standard, workflow, configuration, checklist, approval template, or procedure and trace each required element to the stated control objective.", "Confirm that the AI verification, validation, and release acceptance control design names the accountable owner (AI product owner or model owner with AI engineering/MLOps, risk/compliance, security/privacy, data owner, domain expert, and independent validation/specialist input where risk warrants.) and expected performance cadence (Before initial deployment and before material model/data/prompt/configuration/vendor/integration changes, periodic reassessment should map to continuous validation/postdeployment monitoring controls.), including reviewer, delegate, and escalation responsibilities where applicable.", "Check that the design defines the in-scope population (AI systems, models, material model versions, and material releases or deployments within the AI inventory.), sampling unit (AI system release, model version, or material deployment/change package.), and process/system boundary (monitoring-and-validation process boundary) so testing can be repeated by another auditor.", "Walk through one representative control occurrence, AI lifecycle event, approval, change, exception, or monitoring record covered by AI verification, validation, and release acceptance control. Trace it from trigger through decision, escalation, and evidence retention and identify where the control prevents, detects, or corrects the targeted risk.", "Challenge whether bypasses, undocumented judgment, missing thresholds, unclear reviewer authority, weak segregation, or absent retention rules could prevent AI verification, validation, and release acceptance control from operating consistently." ], "recommendedArtifacts": [ "V&V policy/procedure.", "test strategy and test plan.", "requirements traceability matrix.", "test datasets and representativeness rationale.", "model/system evaluation reports.", "performance/robustness/safety/bias/fairness/security test results.", "benchmark and uncertainty documentation.", "defect/anomaly/remediation tickets.", "limitation/residual-risk records.", "release criteria checklist." ] }, "testOfEffectiveness": { "overallTestObjectivePurpose": "Confirm that AI verification, validation, and release acceptance control operated during the review period in line with its documented criteria, ownership, frequency, evidence requirements, and exception path.", "recommendedSamplingStrategy": "Use AI systems, models, material model versions, and material releases or deployments within the AI inventory. as the primary population and AI system release, model version, or material deployment/change package. as the sample unit. Reconcile the population to the source system, register, workflow, ticket queue, monitoring output, or log extract. Stratify by system, business unit, model tier, lifecycle stage, vendor, region, or risk rating where operation differs. Add judgmental selections for high-risk, changed, exception, override, incident, failed-check, or near-threshold items. Use full-population analytics when the data is complete and the test criterion is deterministic.", "recommendedSampleSize": "Minimum suggestion is 20 daily-or-more-frequent executions, alerts, log entries, or monitoring records after population completeness and control frequency are confirmed. Use full-population analytics where criteria are deterministic.", "detailedTestSteps": [ "Build the population for AI verification, validation, and release acceptance control from the system, workflow, register, log, or approval repository that records control execution. Document extraction parameters, date range, filters, and completeness reconciliation.", "Sample AI systems or material releases during the period and verify that V&V was completed before deployment, criteria were met or exceptions approved, test data and results were retained, deficiencies were tracked to disposition, responsible approvals were obtained, and the release decision aligned with documented risk tolerance.", "For each selected item, verify the control was performed by the expected owner or reviewer, at the required point in the process, against the defined criteria, and before the AI decision, release, approval, use, or event proceeded where the design requires prior control execution.", "Compare retained evidence to the control design and confirm completeness, accuracy, reviewer sign-off, timestamps, linkage to the AI system/use case/model/vendor/event, and consistency with the required cadence.", "Trace exceptions, overrides, failed checks, late reviews, unresolved actions, and risk acceptances to escalation, remediation, approval, retesting, or closure evidence." ], "recommendedArtifacts": [ "V&V policy/procedure.", "test strategy and test plan.", "requirements traceability matrix.", "test datasets and representativeness rationale.", "model/system evaluation reports.", "performance/robustness/safety/bias/fairness/security test results.", "benchmark and uncertainty documentation.", "defect/anomaly/remediation tickets.", "limitation/residual-risk records.", "release criteria checklist." ] } }, "expectedEvidenceArtifacts": [ "V&V policy/procedure", "test strategy and test plan", "requirements traceability matrix", "test datasets and representativeness rationale", "model/system evaluation reports", "performance/robustness/safety/bias/fairness/security test results", "benchmark and uncertainty documentation", "defect/anomaly/remediation tickets", "limitation/residual-risk records", "release criteria checklist", "approval/sign-off records", "model card or technical documentation", "independent review evidence" ] }, { "controlId": "ctl-ai-version-change-log", "title": "AI model versioning and change-log traceability", "objective": "Maintain traceability over AI model, prompt, data, configuration, integration, and control changes.", "description": "Maintain version history and change logs for AI configuration items, including model parameters, prompts/system prompts, retrieval indexes, guardrails, tool permissions, patches, emergency changes, and release records.", "controlFamily": "change-and-configuration-management", "sourceLabels": [ "ISACA AI Audit Toolkit 2024: AL-MV-09; MG-MM-03; MG-MM-04", "ISACA AAIA Review Manual: Figure 3.1 common AI controls; Figure 3.1 configuration/change/monitoring controls; Figure 3.1, Version control / Change management / Continuous monitoring", "ISO/IEC 42001: 7.5.3; 8.1; A.4.4; A.4.6; A.6.2; A.4.5", "ISO/IEC 5338: 6.4.12; 6.4.16; model configuration/parameters and maintenance rollback", "NIST AI RMF Playbook: MANAGE 1.3; MANAGE 3.2; MANAGE 4.1", "OWASP: LLM Top 10; LLM04; LLM08" ], "auditProcedure": { "auditProcedureName": "Test AI model versioning and change-log traceability", "auditProcedureDescription": "Trace the control for AI model versioning and change-log traceability from the event, decision, or cadence that triggers it through execution, review, exception handling, and retained evidence. Use the control objective as the reference point. Maintain traceability over AI model, prompt, data, configuration, integration, and control changes. Confirm that the described control activity is performed through clear criteria, accountable ownership, defined timing, complete population coverage, reliable source records, and evidence that exceptions are escalated and resolved. Where the control relies on automated monitoring, workflow approval, or manual expert review, verify that handoffs and evidence repositories are clear enough for repeatable audit testing. The work should cover the activity defined for the control. Maintain version history and change logs for AI configuration items, including model parameters, prompts/system prompts, retrieval indexes, guardrails, tool permissions, patches, emergency changes, and release records.", "testOfDesign": { "overallTestObjectivePurpose": "Determine whether AI model versioning and change-log traceability is designed with criteria, ownership, timing, evidence, and exception handling precise enough to achieve the objective. Maintain traceability over AI model, prompt, data, configuration, integration, and control changes.", "detailedTestSteps": [ "Inspect required configuration/version fields for tools/plugins/functions, permission changes, guardrails, emergency patches, and release records.", "Inspect whether the versioning/change-log design defines AI configuration items, required metadata, linkage between change logs and approvals/tests/releases, emergency-change treatment, retention, access control and audit-trail expectations.", "Inspect whether prompt/guardrail/RAG/tool-permission changes are configuration items with version/change history and retest triggers.", "Inspect required version/change-log fields for datasets, model artifacts, retrieval indexes and adapters.", "Inspect whether change-management scope includes agent tools, permission scopes, system prompts, guardrails, approval gates, and emergency changes.", "Inspect the documented AI model versioning and change-log traceability policy, standard, workflow, configuration, checklist, approval template, or procedure and trace each required element to the stated control objective.", "Confirm that the AI model versioning and change-log traceability design names the accountable owner (Platform/MLOps/LLMOps owner with change manager.) and expected performance cadence (Every change, periodic reconciliation to inventory.), including reviewer, delegate, and escalation responsibilities where applicable.", "Check that the design defines the in-scope population (Tool/plugin/function configuration and permission changes.), sampling unit (Configuration/version log entry.), and process/system boundary (change-and-configuration-management process boundary) so testing can be repeated by another auditor.", "Walk through one representative control occurrence, AI lifecycle event, approval, change, exception, or monitoring record covered by AI model versioning and change-log traceability. Trace it from trigger through decision, escalation, and evidence retention and identify where the control prevents, detects, or corrects the targeted risk.", "Challenge whether bypasses, undocumented judgment, missing thresholds, unclear reviewer authority, weak segregation, or absent retention rules could prevent AI model versioning and change-log traceability from operating consistently." ], "recommendedArtifacts": [ "configuration/version register.", "permission change logs.", "release notes.", "emergency change records.", "repository audit trail.", "model/version register.", "AI configuration item inventory.", "change logs.", "version-control history.", "prompt/system-prompt history." ] }, "testOfEffectiveness": { "overallTestObjectivePurpose": "Confirm that AI model versioning and change-log traceability operated during the review period in line with its documented criteria, ownership, frequency, evidence requirements, and exception path.", "recommendedSamplingStrategy": "Use Tool/plugin/function configuration and permission changes. as the primary population and Configuration/version log entry. as the sample unit. Reconcile the population to the source system, register, workflow, ticket queue, monitoring output, or log extract. Stratify by system, business unit, model tier, lifecycle stage, vendor, region, or risk rating where operation differs. Add judgmental selections for high-risk, changed, exception, override, incident, failed-check, or near-threshold items. Use full-population analytics when the data is complete and the test criterion is deterministic.", "recommendedSampleSize": "Minimum suggestion is 20 daily-or-more-frequent executions, alerts, log entries, or monitoring records after population completeness and control frequency are confirmed. Use full-population analytics where criteria are deterministic.", "detailedTestSteps": [ "Build the population for AI model versioning and change-log traceability from the system, workflow, register, log, or approval repository that records control execution. Document extraction parameters, date range, filters, and completeness reconciliation.", "Sample tool/plugin configuration and permission changes and verify history, approver, implementation date, evidence, and linkage to release/change tickets.", "Sample deployed AI systems and recent releases/changes, reconcile change tickets to version registry, prompt/data/model/config logs, release records, approvals, test evidence and rollback records.", "Sample changes to prompts/guardrails/RAG/tool permissions and verify approval, testing, deployment record, and post-change monitoring.", "Sample changes and verify versions, approvals, integrity checks and rollback links are retained.", "Sample tool/permission/guardrail changes for agentic systems and verify approval, testing, release traceability, and post-change monitoring.", "For each selected item, verify the control was performed by the expected owner or reviewer, at the required point in the process, against the defined criteria, and before the AI decision, release, approval, use, or event proceeded where the design requires prior control execution.", "Compare retained evidence to the control design and confirm completeness, accuracy, reviewer sign-off, timestamps, linkage to the AI system/use case/model/vendor/event, and consistency with the required cadence.", "Trace exceptions, overrides, failed checks, late reviews, unresolved actions, and risk acceptances to escalation, remediation, approval, retesting, or closure evidence." ], "recommendedArtifacts": [ "configuration/version register.", "permission change logs.", "release notes.", "emergency change records.", "repository audit trail.", "model/version register.", "AI configuration item inventory.", "change logs.", "version-control history.", "prompt/system-prompt history." ] } }, "expectedEvidenceArtifacts": [ "configuration/version register", "permission change logs", "release notes", "emergency change records", "repository audit trail", "model/version register", "AI configuration item inventory", "change logs", "version-control history", "prompt/system-prompt history", "data/retrieval index change records", "release records", "emergency-change records", "approval and test evidence cross-references", "audit logs", "version register", "prompt/configuration change log", "release tickets", "test/retest records", "DVC/model registry records", "rollback records", "change tickets", "tool permission manifests", "guardrail configuration history", "approval logs", "prompt/script repository history", "agent/tool definition versions", "AIBOM/Agent SBOM" ] } ], "riskControlMappings": [ { "riskId": "risk-ai-ambition-feasibility-mismatch", "controlId": "ctl-ai-strategy-feasibility-readiness-review" }, { "riskId": "risk-ai-ambition-feasibility-mismatch", "controlId": "ctl-ai-use-case-value-feasibility-prioritization" }, { "riskId": "risk-ai-ambition-feasibility-mismatch", "controlId": "ctl-ai-risk-classification-register" }, { "riskId": "risk-ai-supply-chain-and-third-party-risk", "controlId": "ctl-ai-supplier-due-diligence" }, { "riskId": "risk-ai-supply-chain-and-third-party-risk", "controlId": "ctl-ai-supply-chain-integrity-verification" }, { "riskId": "risk-ai-supply-chain-and-third-party-risk", "controlId": "ctl-ai-contract-obligations" }, { "riskId": "risk-hallucinations-confabulation", "controlId": "ctl-ai-output-accuracy-grounding-validation" }, { "riskId": "risk-hallucinations-confabulation", "controlId": "ctl-ai-human-oversight-gates" }, { "riskId": "risk-hallucinations-confabulation", "controlId": "ctl-ai-overreliance-awareness" }, { "riskId": "risk-hallucinations-confabulation", "controlId": "ctl-ai-postdeployment-model-monitoring" }, { "riskId": "risk-hallucinations-confabulation", "controlId": "ctl-ai-user-instructions-explainability" }, { "riskId": "risk-hallucinations-confabulation", "controlId": "ctl-ai-technical-documentation" }, { "riskId": "risk-inadequate-or-missing-ai-governance-framework", "controlId": "ctl-ai-governance-framework-management-system" }, { "riskId": "risk-inadequate-verification-and-validation", "controlId": "ctl-ai-verification-validation-release-acceptance" }, { "riskId": "risk-inadequate-verification-and-validation", "controlId": "ctl-ai-technical-documentation" }, { "riskId": "risk-inadequate-verification-and-validation", "controlId": "ctl-ai-change-impact-assessment" }, { "riskId": "risk-lack-of-clear-accountability", "controlId": "ctl-ai-accountability-raci-decision-rights" }, { "riskId": "risk-metadata-and-lineage-management-failure", "controlId": "ctl-ai-data-lineage-provenance-metadata" }, { "riskId": "risk-metadata-and-lineage-management-failure", "controlId": "ctl-ai-technical-documentation" }, { "riskId": "risk-metadata-and-lineage-management-failure", "controlId": "ctl-ai-data-drift-validation" }, { "riskId": "risk-missing-ai-inventory", "controlId": "ctl-ai-system-inventory-and-reconciliation" }, { "riskId": "risk-missing-ai-inventory", "controlId": "ctl-ai-risk-classification-register" }, { "riskId": "risk-prompt-injection-and-input-manipulation", "controlId": "ctl-ai-adversarial-input-and-prompt-injection-defense" }, { "riskId": "risk-prompt-injection-and-input-manipulation", "controlId": "ctl-ai-postdeployment-model-monitoring" }, { "riskId": "risk-prompt-injection-and-input-manipulation", "controlId": "ctl-ai-incident-notification" }, { "riskId": "risk-prompt-injection-and-input-manipulation", "controlId": "ctl-ai-user-instructions-explainability" }, { "riskId": "risk-prompt-injection-and-input-manipulation", "controlId": "ctl-ai-version-change-log" }, { "riskId": "risk-sensitive-data-disclosure-and-inference", "controlId": "ctl-ai-sensitive-data-protection" }, { "riskId": "risk-sensitive-data-disclosure-and-inference", "controlId": "ctl-ai-inference-attack-privacy-testing" }, { "riskId": "risk-sensitive-data-disclosure-and-inference", "controlId": "ctl-ai-impact-conformity-trigger" } ] }