AAISM ISACA Advanced in AI Security Management Exam Topics and Questions

AI Governance and Program Management sets the strategic foundation for everything else in this exam. The domain asks you to operate at the advisory level: you are not configuring tools, you are telling stakeholders what policies, programs, and response plans they need and why. That distinction shapes every item you will see here. Candidates who study this as a compliance checklist and miss the judgment layer tend to stumble when scenarios force a choice between competing obligations.

– Stakeholder alignment, frameworks, and regulatory obligations

Regulatory requirements and industry frameworks are not interchangeable, and the exam will make you choose between them under realistic constraints. You need to know which frameworks are relevant to AI security specifically (NIST AI RMF, ISO 42001, and similar), what they require of governance structures, and where domestic or regional regulation overrides a framework preference. Stakeholder considerations go further than identifying who cares: you must be able to advise on how governance decisions are communicated and justified to audiences with different risk tolerances. The trap here is treating frameworks as authoritative rules rather than guidance. When a scenario pits a regulatory mandate against a framework recommendation, the regulation wins, and items in this area frequently construct exactly that tension to see whether you know the hierarchy.

– Policies, procedures, and the AI asset life cycle

AI-related strategies, policies, and procedures translate governance intent into operational reality. The exam tests whether you can distinguish a policy gap from a procedure gap and recommend the right fix for each. Policies set direction; procedures operationalize it. Confusing the two in a scenario leads you toward options that sound reasonable but solve the wrong problem.

AI asset and data life cycle management sits alongside this because data governance is where many AI security failures originate. You need to understand how data is classified, handled, and retired across the model life cycle, and what controls apply at each stage. Items here often describe a data handling situation and ask what governance action is most appropriate, rewarding candidates who can connect a specific life cycle stage to a specific control requirement rather than applying a generic data protection principle.

– Program development and resilience

Building and managing an AI security program means more than drafting a charter. The exam looks at how programs are structured, resourced, and measured, and how they stay aligned with enterprise risk appetite over time. You should be comfortable with program maturity concepts and with the practical question of how to prioritize program investments when resources are constrained.

Business continuity and incident response close out the domain, and they appear in scenarios that are deliberately time-pressured. The key distinction the exam draws is between response actions that contain an AI-specific incident and actions that would be correct for a conventional IT incident but are inadequate or even harmful in an AI context. Candidates who default to generic IR playbook thinking lose marks here. Know what makes an AI incident different in terms of evidence preservation, model integrity verification, and stakeholder notification, and you will be in a strong position.

How AI Governance and Program Management is tested

At 31% of the exam, this domain will appear in roughly a third of the items you sit. The weight means you cannot afford a systematic gap: one weak sub-area will show up multiple times.

Items are scenario-driven and advisory in tone. You are typically cast as a senior AI security professional giving a recommendation, which means the options are rarely between a right answer and obviously wrong ones. They are between a good answer and a better one, and the better one is usually the one that operates at the correct level: governance over implementation, enterprise context over technical detail.

Candidates lose marks most often in two places. First, they pick a technically sound action that bypasses the governance step the scenario actually calls for. Second, they treat regulatory requirements and framework guidance as equivalent and choose the framework option when a regulation applies. Items in the incident response section reward sequencing: the response action that preserves integrity and contains scope comes before the action that investigates cause.

Where the previous domain asked you to build and govern programs, AI Risk Management asks you to assess and act on what can go wrong inside them. The scope is enterprise-wide: you are evaluating risk across the full adoption of AI, not just a single system. That breadth is deliberate, and it is where candidates who think in system-level terms rather than enterprise-level terms tend to underperform. The domain also brings supply chain into scope, which introduces third-party risk logic that sits on top of the AI-specific layer.

How AI Risk Management is tested

With three sub-topics and a 31% weight shared with the governance domain, AI Risk Management generates a high density of items relative to its structural simplicity. Do not let the short sub-topic list suggest shallow coverage: each area is tested at depth.

Risk assessment items reward candidates who apply AI-specific risk criteria rather than generic enterprise risk methods. The threshold and treatment questions are where judgment is tested most sharply: scenarios describe a risk level and ask what treatment is appropriate, and the items distinguish between candidates who know the treatment options in the abstract and those who can match treatment to context.

Threat and vulnerability management items focus on what is distinctive about AI threats: adversarial inputs, model poisoning, inference attacks, and similar. Generic threat management answers score poorly. Supply chain items reward a layered view: the exam expects you to think about vendor risk, model provenance, and data sourcing as interconnected, not as separate checklists. Candidates lose marks by treating third-party AI risk as equivalent to conventional IT vendor risk and missing the model-integrity dimension.

At 38%, this is the largest domain on the exam, and it is the most technically detailed. After two domains spent on governance and risk strategy, AI TECHNOLOGIES AND CONTROLS puts you inside the systems themselves: architecture decisions, model life cycle stages, data controls, privacy and ethics, and the monitoring layer that ties it all together. The breadth is real. Candidates who are strong on governance but thin on technical controls will feel the weight of this domain in their final score.

– Architecture, design, and the model life cycle

Security architecture for AI systems shares some principles with conventional system design but adds requirements specific to model behavior, data flow, and inference exposure. The exam tests whether you can identify design decisions that introduce AI-specific risk: where a model is deployed, how inputs reach it, and how outputs are consumed all affect the attack surface in ways that standard network segmentation thinking does not fully address.

The model life cycle sub-topic covers selection, training, and validation, and each stage has distinct security implications. Model selection involves provenance and supply chain considerations. Training involves data integrity and poisoning risk. Validation involves ensuring the model behaves as expected under adversarial conditions, not just normal ones. Items here reward candidates who can connect a life cycle stage to the specific control that applies at that stage, rather than applying a single model-security concept across all stages indiscriminately.

– Data management and privacy controls

Data management controls in an AI context go beyond access control and retention schedules. The exam expects you to reason about data quality, lineage, and integrity as security properties, because a model trained on manipulated or mislabeled data is a security problem even if no unauthorized access occurred. That framing is the non-obvious angle that items in this area exploit.

Privacy, ethical, trust, and safety controls form a cluster that the exam treats as interconnected. Privacy controls in AI systems must account for inference risk: a model can leak information about its training data even when the data itself is protected. Ethical and trust controls address bias, explainability, and the conditions under which AI outputs can be relied upon for decisions. Safety controls address what happens when a model produces outputs that cause harm. Candidates who treat these as separate compliance boxes rather than as overlapping design requirements tend to pick options that solve one dimension while ignoring another.

– Security controls and monitoring

Security controls and monitoring close the domain and tie the technical content back to the operational reality of running AI systems in production. The exam tests your ability to select controls that are proportionate and appropriate to AI-specific threats, not just to map generic security controls onto an AI environment and call it done.

Monitoring for AI systems includes behavioral monitoring of model outputs over time, not just infrastructure monitoring. A model that begins producing anomalous outputs may be under an adversarial attack or may have drifted from its validated behavior: the exam draws on both possibilities and asks you to distinguish the appropriate response for each. Items here reward candidates who understand detection logic in AI terms, including what signals indicate model integrity issues versus conventional security incidents. The strongest responses connect a monitoring finding to a specific remediation path, not to a generic incident response step.

How AI TECHNOLOGIES AND CONTROLS is tested

The 38% weight means this domain alone could determine whether you pass. Items are scenario-based and technically grounded: you will be given a system description, a threat or failure condition, and asked to identify the most appropriate control, design choice, or response.

The consistent trap is applying conventional security thinking to an AI-specific problem. Many options in this domain are defensible from a general security perspective but miss the AI-specific requirement. Items reward candidates who recognize what is different about securing a model versus securing an application, what is different about data integrity in a training pipeline versus a transactional database, and what is different about monitoring model behavior versus monitoring network traffic.

Candidates lose marks most often in the privacy and ethics cluster, where the temptation is to pick the option that addresses the most visible risk and overlook inference risk or downstream safety implications. In the architecture and life cycle items, the loss typically comes from applying a control at the wrong life cycle stage. Precision about where in the process a control belongs is what separates the strongest responses from the merely adequate ones.