General Exam Tips
- 1.Allocate time proportional to domain weight: spend ~46% of your study time on Domain 2 (AI Operations), ~33% on Domain 1, and ~21% on Domain 3 — most candidates who fail under-prepare for Domain 2.
- 2.Budget exactly 1.6 minutes per question. Flag hard questions immediately and move on — return to them in the last 15 minutes. Never agonize at question 12 and run out of time on question 85.
- 3.No penalty for wrong answers. Guess on every unanswered question before time expires — a blank is a guaranteed zero, a guess has positive expected value.
- 4.Every scenario question is asking one of four things: what is the risk, what control is missing, what audit procedure applies, or what evidence is needed. Frame your reading around those four lenses.
- 5.When two answers both sound correct, choose the one that focuses on the AUDIT perspective — the examiner wants to know what an auditor does, not what a developer, risk manager, or data scientist does.
- 6.Read all four options before committing. The exam is designed so that distractor answers describe the right action for the wrong role or the right framework in the wrong context.
- 7.ISACA exam language: 'MOST appropriate,' 'BEST course of action,' and 'PRIMARILY' mean pick the one answer that is most directly relevant — eliminate answers that are correct but secondary.
- 8.Target 65-70% on mock exams to build a safety margin over the 450/800 passing score. If you are consistently scoring below 60%, add one more week of Domain 2 focus before scheduling.
- 9.The exam is computer-based — you can mark questions for review. Use that feature aggressively on scenario questions that require multiple reads.
- 10.Candidates from traditional IT audit backgrounds consistently report that Domain 2 questions feel unfamiliar. If you encounter an AI operations scenario you cannot confidently answer, eliminate framework-based answers and choose the one that most closely mirrors traditional IT change management or incident response adapted for AI.
AI Governance and Risk
Must-Know Facts
- NIST AI RMF four core functions in order: Govern, Map, Measure, Manage. 'Govern' sets the organizational foundation; the others operate within that structure.
- EU AI Act four risk tiers: Unacceptable (banned outright), High (mandatory conformity assessment + Notified Body review for some), Limited (transparency obligations), Minimal (no obligations). High-risk AI is controlled, not banned.
- ISO/IEC 42001 is the ONLY AI framework that results in a formal organizational certification after third-party audit. NIST AI RMF and EU AI Act are not certification schemes.
- Data provenance = where data came from (origin, consent, ownership). Data lineage = how data was transformed (steps, modifications, processing history). The exam tests both in audit scenarios.
- AI RACI structure: Model Owner is accountable for model governance decisions. Data Scientist builds and maintains the model. Risk Management assesses and monitors AI risk. Internal Audit independently assesses all of the above. These cannot overlap without a separation of duties violation.
- AI Ethics Board advises on ethical acceptability of AI initiatives — it does NOT approve models for production. Model approval is a governance/risk function separate from ethics advisory.
- Sanctioned vs. unsanctioned AI: employees using unapproved AI tools (shadow AI) is a policy compliance risk that auditors must specifically test for — this is an AI governance control gap.
- Workforce impact assessment is required as part of AI governance — auditors must verify the organization assessed how AI affects job roles, training needs, and organizational change readiness.
- Third-party AI risk requires right-to-audit clauses in vendor contracts. Without them, the auditor cannot verify vendor AI controls. Absence of a right-to-audit clause is a reportable finding.
- Privacy Impact Assessments (PIAs) are required for AI systems that process personal data — especially relevant when AI makes automated decisions about individuals.
Common Traps
Confusing Pairs
Scenario Tips
When the question describes an organization deploying AI in Europe and asks which framework 'requires' or 'mandates' compliance...
Choose EU AI Act. It is the only legally binding framework. Any question with words like 'penalties,' 'mandatory,' 'legally required,' or 'enforce' in the EU context points to the EU AI Act.
ISO/IEC 42001 is a wrong answer here — it is voluntary. NIST AI RMF is also wrong — it is US-origin voluntary guidance. OECD Principles are non-binding international guidelines.
When the question asks an auditor to evaluate whether an organization's AI system development team and approval function are properly structured...
Look for separation of duties. The team that builds the model should NOT be the same team that approves it for production. If they are the same, the finding is a separation of duties control deficiency.
Candidates often select 'transparency' as the violated principle. Transparency concerns disclosure to external parties. Separation of duties is the internal control principle at stake.
When the question asks an auditor to verify the ethical and legal basis for an AI model's training data...
Focus on data provenance controls: consent documentation, data source agreements, data classification, and purpose limitation. The auditor should verify that data was collected under consent that covers AI training use.
Data lineage is a wrong focus here — lineage tracks transformations, not the ethical collection basis. Candidates often confuse 'can we trace where it went?' (lineage) with 'was it collected properly?' (provenance).
When a question describes an employee using a third-party AI chatbot not approved by IT or the AI governance team...
This is a shadow AI / unsanctioned AI use risk. The governance gap is the absence of an acceptable use policy covering third-party AI tools, or the absence of enforcement mechanisms for that policy.
Candidates sometimes choose 'data encryption' or 'access controls' as the primary issue. Those are valid secondary concerns, but the primary governance gap is the lack of AI usage policy and control over tool adoption.
Last-Minute Facts
AI Operations
Must-Know Facts
- AI/ML lifecycle audit control points: (1) Business case — strategic alignment, (2) Data collection — consent and quality controls, (3) Feature engineering — bias introduction risk, (4) Model development — reproducibility, (5) Training/validation — independent validation team, (6) Deployment — change approval, (7) Monitoring — drift and bias rechecks, (8) Maintenance/retraining — change management, (9) Decommissioning — data retention and access revocation.
- Three types of model drift: Data drift (input distributions change, model unchanged), Concept drift (relationship between inputs and outputs changes, real-world phenomenon evolves), Model drift (model performance degrades due to parameter decay or infrastructure changes). Each type requires different detection methods and remediation.
- Cross-validation is a DEVELOPMENT technique (k-fold, holdout) used to estimate model performance during training. It is NOT a production monitoring control. Candidates who recommend 'cross-validation' to detect production drift are wrong.
- Adversarial testing must occur BEFORE deployment as a proactive quality gate. It is not incident response. Testing covers prompt injection resistance, data poisoning detection, evasion attack tolerance, and adversarial example robustness.
- Fairness testing methodologies: Demographic Parity (equal positive outcome rate across groups), Equal Opportunity (equal true positive rate), Disparate Impact (checks if a protected group receives negative outcomes at a rate 80%+ above others — the '4/5 rule'). The 4/5 rule / 80% rule is the legal threshold for disparate impact.
- Model validation (pre-deployment) must be performed by a team INDEPENDENT of the model developers. Self-validation by the development team is a separation of duties deficiency.
- Change management for AI requires more than code review: model retraining with new data changes model behavior even without code changes. AI change management must explicitly cover data updates, hyperparameter changes, retraining cycles, and vendor model updates.
- AI incident response differs from traditional IT incident response: incidents include drift-triggered performance degradation, bias emergence, hallucination rate spikes, adversarial compromise, and vendor model changes. Root cause analysis must address AI-specific causes, not just system availability.
- Hallucination monitoring is an AI-specific control with no traditional IT equivalent. Auditors must verify that: hallucination rate is measured, acceptable thresholds are defined, and alerts fire when thresholds are exceeded.
- Human-in-the-loop (HITL) requirements: high-risk AI decisions (loan approvals, hiring, medical diagnosis support) require defined confidence score thresholds below which human review is mandatory. Auditors must verify HITL controls exist and operate effectively.
- Vendor/third-party AI risks include: SLA non-compliance, API versioning changes that alter model behavior, vendor data retention practices, and vendor model updates that change downstream system behavior without notice. Right-to-audit clauses in vendor contracts are the primary control.
- MLOps pipelines create audit trails through model registries, experiment tracking logs, pipeline run histories, and artifact versioning. Absence of these logs is a control deficiency in traceability.
Common Traps
Confusing Pairs
Scenario Tips
When the question describes a model with stable test accuracy but worsening real-world performance, and input data distributions have not changed...
Concept drift. The underlying relationship between inputs and outputs has changed in the real world. The model's learned patterns are obsolete even though inputs look statistically similar. The appropriate control is monitoring of outcome accuracy on labeled current production data, not statistical tests on input distributions.
Data drift is the most common wrong answer — it is tempting because drift was mentioned. But data drift requires changing input distributions, which the question explicitly rules out.
When the question asks what the auditor should do after finding that model retraining and deployment are fully automated with no human approval gate...
Report an inadequate change management control. AI change management requires human approval before production deployment, even when retraining is automated. The finding should describe the risk: automated deployment can silently change model behavior, fairness characteristics, and decision patterns without oversight.
Candidates often select 'missing adversarial testing' because automated deployment sounds risky. But the specific control gap described is the absence of an approval workflow — change management, not testing.
When the question asks which control verifies that an AI hiring model does not disadvantage a protected demographic group...
Disparate impact analysis (or fairness testing using demographic parity/equal opportunity). These specifically measure outcome differences across demographic groups. For hiring contexts, the 4/5 rule (disparate impact threshold of 80%) is the standard legal benchmark.
Adversarial testing is a common wrong answer. Adversarial testing checks robustness against malicious inputs — it does not measure demographic fairness in outcomes. Cross-validation is also wrong — it measures accuracy, not fairness.
When a question asks the most important audit procedure for an AI system that relies on a third-party API for its core inference capability...
Verify that right-to-audit clauses and SLA compliance monitoring are in place. Without right-to-audit provisions, the organization cannot independently assess vendor controls. SLA monitoring ensures service quality and availability obligations are being met.
Checking that the API documentation is publicly available sounds reasonable but is not a control. API redundancy (multiple vendors) is a continuity measure, not an audit control. The correct answer focuses on contractual audit rights and performance monitoring.
When a question describes an AI system where the model's training logs were deleted after the most recent retraining cycle...
This is a control deficiency in audit trail and evidence preservation. Training logs are essential for reproducibility — without them, an auditor cannot independently verify how the model was trained, what data was used, or whether the approved training procedure was followed. The finding category is audit trail management.
Candidates sometimes classify this as a storage optimization issue or acceptable trade-off. This is never acceptable in an auditable AI system — training logs must be retained for the entire model's operational life plus the required retention period.
When a question asks what control ensures that features used during model training and during production inference are identical...
A feature store with shared feature definitions. Training-serving skew (different feature computation during training vs. inference) is a major source of silent model performance degradation. The feature store ensures both training pipelines and inference pipelines consume identically defined features.
Model monitoring catches the symptom (performance degradation) but does not prevent training-serving skew from occurring. The preventive control is the feature store.
Last-Minute Facts
AI Auditing Tools and Techniques
Must-Know Facts
- AI audit scope definition must address: system boundary (what AI components are in scope), data flows (training data, inference data), third-party dependencies, regulatory jurisdiction, and risk-based prioritization of which AI controls to test.
- Control testing methodologies for AI systems: (1) Walkthrough — trace a transaction or decision through the AI lifecycle, (2) Configuration review — validate AI system settings against approved configurations, (3) Output sampling — inspect a sample of model decisions for accuracy and fairness, (4) Reperformance — independently run the model with test inputs and compare outputs, (5) Fairness analysis — apply disparate impact or demographic parity analysis to model outputs.
- AI audit evidence must meet four standards: Sufficiency (enough evidence to support the finding), Reliability (from a trustworthy source, preferably system-generated logs), Relevance (directly related to the control being tested), Reproducibility (can an independent auditor recreate the same finding). Reproducibility is particularly challenging for stochastic AI systems.
- When using AI tools within the audit process (Domain 3 focus): AI-generated findings must be treated as inputs to audit judgment, not final conclusions. Professional skepticism must be maintained. Over-reliance on AI-flagged anomalies without human evaluation is an independence and quality risk.
- Risk-based sampling is preferred over random sampling for AI audits because AI systems have non-uniform risk distributions — some model decisions or time periods carry materially higher risk and should be over-sampled.
- Full-population testing enabled by AI analytics: auditors can test 100% of transactions using automated tools. This does not eliminate the need for professional judgment on flagged items — anomaly detection identifies candidates for further investigation, not confirmed findings.
- AI audit reporting must communicate findings in terms that both technical and non-technical stakeholders can understand. Findings should include: risk rating of the AI control gap, business impact description (what decisions were affected), and specific remediation recommendation.
- Auditor independence when using AI tools: the auditor must not rely on analytics tools provided by the system under audit. Using the auditee's own AI monitoring dashboards as sole evidence creates an independence concern — additional independent evidence must be obtained.
- Workpaper documentation for AI audits must include: the AI tool or system version tested, the specific inputs used for testing, expected vs. actual outputs, fairness test methodology and results, and limitations of the evidence (e.g., stochastic behavior noted).
Common Traps
Confusing Pairs
Scenario Tips
When a question asks an auditor who is using AI analytics tools to review financial transactions about the most significant risk to maintain...
Independence and professional skepticism — specifically avoiding over-reliance on AI-generated findings. The auditor must evaluate AI-flagged anomalies with professional judgment, not accept them as confirmed deficiencies.
Cost and time savings are true benefits of AI analytics but are not risks. The risk is over-reliance, not efficiency.
When a question asks how an auditor should test whether an AI model is making equitable decisions across demographic groups...
Analyze model outputs stratified by demographic groups and apply fairness metrics (demographic parity, equal opportunity, disparate impact analysis). This directly tests the outcome — whether decisions differ by group — rather than testing inputs or intentions.
Reviewing source code is a wrong answer — bias emerges from data patterns, not typically from explicit code logic. Interviewing the data science team tests intent, not outcomes. Only outcome analysis directly tests for discriminatory impact.
When a question describes an auditor discovering that training logs for an AI model were deleted, and asks how to classify this finding...
This is a control deficiency in audit trail and evidence management — specifically, failure to maintain records necessary for reproducibility and independent verification. The severity is significant because it prevents the auditor from verifying training procedure compliance.
Classifying this as 'a minor documentation issue' is wrong. It eliminates the evidentiary basis for assessing training process controls. Never minimize the deletion of audit trail records.
When a question asks an auditor using AI tools to check the output of the AI monitoring dashboard provided by the auditee...
The dashboard is management evidence and lacks independence. The auditor must obtain additional independent corroborating evidence — running independent test cases, obtaining third-party attestation, or reviewing unmodifiable system logs — rather than relying solely on the auditee's own monitoring outputs.
Accepting the dashboard as sufficient evidence is the trap answer. It appears practical, but it violates auditor independence principles.