AAIR ISACA Advanced in AI Risk Exam Topics and Questions

This is the largest single slice of the exam at 37%, and it sets the foundation everything else builds on. The domain covers how an organisation decides to govern AI: which frameworks it adopts, how accountability is assigned, and what the regulatory environment demands. Where candidates lose ground here is not on definitions but on application, specifically knowing when one governance approach fits better than another and why.

– Frameworks, strategies, and use-case fit

Subtopic 1A asks you to match AI models and frameworks to organisational context, not to recite what NIST AI RMF or ISO 42001 say in the abstract. The examinable question is always fit: which framework is appropriate given the organisation's risk appetite, sector, and AI maturity? You also need to understand how use cases shape governance choices. A predictive maintenance model in manufacturing carries different risk dimensions than a credit-scoring model in financial services, and the exam tests whether you can distinguish those demands. Strategies here means the governance posture an organisation adopts before a single model goes into production. Candidates who memorise framework names without thinking about selection criteria lose marks in this area consistently.

– Organisational structure, ownership, and accountability

Subtopics 1B and 1C sit together because they both deal with the human architecture of AI governance. Organisational alignment means ensuring AI risk activities connect to enterprise risk management rather than operating as a silo. In practice, the exam asks you to identify where AI risk responsibility should sit and what happens when it is misaligned. Ownership and accountability go a step further: who is ultimately answerable when an AI system causes harm, and how is that accountability formalised? The distinction between ownership (a defined role) and oversight (an ongoing activity) matters. Items in this area often present a scenario where accountability is diffuse or contested, and the strongest response clarifies the assignment rather than distributing it further.

– Policies, training, and regulatory compliance

Subtopics 1D and 1E cover the formal instruments that make governance real. Policies and procedures are only as effective as the training that supports them, and the exam tests whether you understand that gap. A policy exists; staff behaviour may not reflect it. Organisational training items often turn on who needs what level of AI literacy and how you verify it. Regulatory compliance brings in legal considerations that vary by jurisdiction and sector. You do not need to know every regulation by name, but you do need to understand how compliance obligations translate into governance requirements and what happens when they conflict with internal strategy.

– Ethics, trustworthiness, and societal considerations

Subtopic 1F is where the exam gets conceptually demanding. Trustworthiness in AI is not a feeling; it is a property with measurable dimensions: fairness, explainability, reliability, and privacy. ESG framing means the exam can ask about AI's environmental footprint or its societal impact on employment and equity. Ethical and societal implications items typically present a scenario where a technically sound AI system produces outcomes that create reputational, social, or regulatory exposure. The strongest responses in this area connect the ethical concern to a concrete governance action rather than stopping at identifying that a concern exists. Candidates who treat this subtopic as soft or peripheral tend to be surprised by how precisely it is tested.

How AI RISK GOVERNANCE AND FRAMEWORK INTEGRATION is tested

At 37%, this domain will dominate your sitting. Expect scenario-based items that describe an organisation's current governance state and ask what the most appropriate next step is, or which control or framework best fits the situation described. The items reward candidates who can apply a framework selection rationale, not those who can define the frameworks. Accountability and ownership scenarios are particularly common: the setup will show a gap or conflict, and items reward the response that resolves it structurally. Regulatory items tend to involve a tension between compliance obligations and business objectives, and the strongest option addresses both rather than sacrificing one entirely. Ethics items often have two plausible responses; the differentiator is usually whether the candidate connects the ethical issue to a specific governance mechanism. Candidates lose marks by choosing responses that are conceptually correct but operationally vague. Precision about who does what, under which authority, is what separates a passing response from a near-miss in this domain.

Where the previous domain established governance at the organisational level, this one drops you into the technical and operational stages of an AI system's existence. At 21%, it carries real weight, and the risk is underestimating how precisely each phase is tested. Candidates with a technical background can over-rely on their development instincts here; the exam wants risk thinking at every stage, not engineering best practice in isolation.

– Design, procurement, and documentation

Subtopic 2A opens the life cycle at the point where risk decisions are cheapest to make. Design choices, whether to build or procure, what problem the model is actually solving, and how requirements are documented, all carry risk implications that compound later. Procurement is particularly examinable because buying an AI system does not transfer the risk: the acquiring organisation remains accountable for outcomes. Documentation at this stage is not administrative housekeeping; it is the evidentiary foundation for every subsequent audit, incident review, and regulatory inquiry. Items in this subtopic often ask you to identify what should be captured in design artefacts and why its absence creates risk exposure.

– Training, testing, and validation

Subtopic 2B is where technical risk becomes most visible, and where the exam tests whether you understand the difference between a model that performs well in testing and one that is validated for production use. Training data quality, bias introduction, and overfitting are all risk concerns here, but the exam approaches them from a risk management angle rather than a data science one. Testing is not just accuracy measurement; it includes adversarial testing, fairness assessment, and boundary condition analysis. Validation asks whether the model does what it was designed to do in the context it will actually operate in. Candidates lose marks by conflating testing (does it work?) with validation (is it fit for this specific purpose?).

– Implementation, maintenance, decommissioning, and data management

Subtopics 2C and 2D cover the operational span of an AI system's life. Implementation risk includes deployment configuration, integration with existing systems, and the human processes that interact with model outputs. Maintenance is not passive; models drift as the data environment changes, and the exam tests whether you understand when revalidation is required rather than just monitoring. Decommissioning is frequently overlooked in candidate preparation: retiring a model carries its own risks, particularly around data retention, residual bias in downstream systems, and contractual obligations. Data and asset management in 2D asks you to think about data provenance, lineage, and classification throughout the life cycle, not just at the training stage. Assets here include the model itself, training data, and associated intellectual property.

How AI LIFE CYCLE RISK MANAGEMENT is tested

Items in this domain are almost always anchored to a specific life cycle stage. The setup will tell you where in the process an organisation is, and the item will ask what risk action is most appropriate at that point. A common trap is selecting a response that is correct in principle but wrong for the stage described. Validation controls applied at the design phase, or decommissioning considerations raised only at deployment, are the kind of mismatch the exam is designed to expose. Data management items reward candidates who think about data as a risk asset across the full life cycle rather than treating it as a development-phase concern only. The procurement angle in 2A catches candidates who assume that buying rather than building reduces risk accountability. Items reward the response that keeps risk ownership with the acquiring organisation. Maintenance and drift items are answered best by candidates who can identify the trigger for intervention, not just the fact that monitoring should happen.

This is the heaviest domain on the exam at 42%, and it is where the governance and life cycle knowledge from the first two domains gets operationalised. The shift here is from setting up structures to running them. Day-to-day risk identification, treatment decisions, control management, metrics, supply chain exposure, and incident response all live here. Candidates who are strong on frameworks but weak on operational risk tradecraft will feel the pressure in this domain.

– Risk identification, assessment, and treatment

Subtopics 3A and 3B form the analytical core of the domain. Risk scenario identification in the context of AI means thinking about threats and vulnerabilities that are specific to machine learning systems: adversarial attacks, model inversion, data poisoning, and prompt injection are examples of AI-specific threat vectors the exam expects you to recognise. Assessment asks you to evaluate likelihood and impact in scenarios where traditional risk frameworks need adaptation. Treatment strategies in 3B require you to distinguish among acceptance, mitigation, transfer, and avoidance in AI-specific contexts. The exam tests whether you can select the appropriate treatment given the risk profile described, not whether you can list the four options. Candidates who apply generic risk treatment logic without accounting for AI-specific factors tend to select responses that are directionally right but insufficiently precise.

– Controls management and risk metrics

Subtopics 3C and 3D cover the machinery of a running AI risk programme. Controls management means evaluating whether a control is appropriate for the AI risk it addresses, selecting from the available options, and validating that it works as intended. The evaluation and validation steps are distinct, and items will test whether you know the difference. Metrics and monitoring in 3D are not about collecting data for its own sake; the exam asks what a given metric actually tells you about AI risk posture and when a metric result should trigger an escalation. Reporting asks how risk information is communicated to different audiences, including the board, operational teams, and regulators. Items reward candidates who match the reporting format and content to the audience's decision-making needs rather than producing a one-size output.

– Supply chain risk and third-party dependencies

Subtopic 3E addresses one of the most practically complex areas of AI risk: the fact that most AI systems depend on components, data, or services that the organisation does not control. Third-party models, cloud-based inference services, open-source libraries, and external training datasets all create supply chain exposure. The exam tests whether you understand where that exposure sits in the risk programme and what due diligence and contractual mechanisms are appropriate. A common error is treating third-party AI risk as equivalent to general vendor risk; the exam distinguishes them because AI-specific dependencies, such as model provenance and dataset licensing, require additional scrutiny. Items in this area often turn on who is responsible when a third-party component contributes to an AI failure.

– Incident response, business continuity, and recovery

Subtopic 3F closes the domain with the operational response to AI risk materialising. Incident response for AI systems has specific characteristics: identifying that a model is behaving anomalously is harder than detecting a network intrusion, and containment may involve suspending automated decision-making rather than isolating a server. Business impact analysis in an AI context asks you to assess the downstream effects of a model failure on business processes that depend on its outputs. Business continuity planning must account for AI system dependencies in ways that traditional BCP often does not. Disaster recovery for AI adds the complexity of model and data restoration alongside infrastructure recovery. Items reward candidates who apply standard IR and BCP concepts with AI-specific adjustments rather than those who apply the frameworks without modification.

How AI RISK PROGRAM MANAGEMENT is tested

At 42%, this domain will decide whether you pass. Items are predominantly scenario-based and operational: you will be placed inside a running risk programme and asked to make a decision. The scenarios are detailed enough that two or three options will appear defensible, and the differentiator is usually specificity. Items in the risk identification and treatment subtopics reward responses that account for AI-specific threat characteristics rather than generic risk logic. Controls items reward the candidate who distinguishes between evaluating a control design and validating its operating effectiveness. Supply chain items consistently catch candidates who stop at identifying third-party risk without addressing the accountability question. Incident response items reward sequencing: what happens first, and why, matters more than whether all the right activities are eventually listed. Metrics items reward candidates who connect a measurement to a decision, not those who advocate for measurement in general. Preparation that covers every subtopic in this domain is worth the time investment given the domain's weight.