ISACA AAISM: Study Plan: What to Practice

AAISM is designed for experienced security managers who need to govern and secure enterprise AI, not for candidates trying to become model developers. The AAISM exam has 90 questions across three domains: AI Governance and Program Management, AI Risk Management, and AI Technologies and Controls. The largest share belongs to technologies and controls, but the two management domains together make up most of the exam.

That weighting tells you how to study. You need enough technical depth to understand AI architecture, the model lifecycle, data controls, monitoring, privacy, and safety, while continually translating those details into governance, risk treatment, vendor oversight, incident response, and business decisions. The exam is strongest when you think like a security leader who can ask technical teams the right questions and turn their answers into accountable controls.

Anchor every technical topic to a governance decision

AI governance begins with ownership. Organizations need charters, roles, decision rights, policies, standards, escalation paths, and metrics that connect AI activity to business objectives. Study who is responsible for approving use cases, defining risk appetite, maintaining inventories, reviewing exceptions, and reporting material issues. An “AI committee” without defined authority is not a governance system.

The AAISM certification extends familiar security-management disciplines into AI-specific conditions. That means your existing governance knowledge remains useful, but you must apply it to model behavior, training and inference data, third-party AI services, human oversight, emergent capabilities, and rapidly changing regulatory expectations.

Build an AI inventory before you try to control AI risk

You cannot govern what the organization cannot identify. A practical AI inventory should record systems, models, vendors, business owners, data sources, deployment environments, user populations, integrations, autonomy level, and critical dependencies. Classification can then determine which systems require deeper testing, stronger approval, or more frequent monitoring. This is similar to asset management in traditional security, but the asset can change behavior as models, prompts, data, and tools evolve.

For study purposes, create sample inventories for a public chatbot, an internal coding assistant, a fraud model, a customer-service agent, and a third-party analytics service. Then decide which attributes would change the risk tier. This exercise connects governance, risk assessment, data management, vendor management, and monitoring—the same cross-domain thinking that appears throughout the exam.

Treat AI risk as a lifecycle problem

AI risk does not start at deployment. It appears during data collection, model selection, training or customization, evaluation, integration, release, operation, update, and retirement. Threats can include prompt manipulation, data leakage, poisoned or low-quality data, model abuse, insecure tools, weak access control, unreliable output, supply-chain compromise, and unsafe automated actions. Risk treatment therefore needs controls at several lifecycle stages.

The wider incident response lifecycle is useful background because AI incidents still require preparation, detection, containment, recovery, and lessons learned. What changes is the evidence and the system behavior. Security teams may need prompts, model versions, retrieved context, tool calls, agent actions, data lineage, and vendor logs in addition to conventional endpoint or network telemetry.

Vendor and supply-chain questions deserve deliberate practice

Many organizations consume AI through external platforms, APIs, embedded assistants, and software that quietly adds AI features. AAISM therefore includes vendor and supply-chain management as a dedicated risk area. Candidates should understand due diligence, contractual controls, data-use terms, sub-processors, model provenance, update practices, incident notification, assurance evidence, exit strategy, and the organization’s residual risk when visibility is limited.

A useful exercise is to review a fictional AI vendor that performs well technically but cannot explain how customer data is retained or used for model improvement. Decide what questions must be answered before approval, what contractual protections are required, what monitoring remains necessary after onboarding, and what conditions would trigger suspension. That is the kind of management judgment the exam is designed to validate.

Technical controls must match AI-specific failure modes

The technologies-and-controls domain includes security architecture, model lifecycle, data controls, privacy, ethics, trust and safety, and ongoing monitoring. Candidates should understand access control, segmentation, encryption, secure development, data minimization, validation, red teaming, content and action guardrails, output monitoring, logging, and human approval. The point is not to memorize a special “AI control list,” but to map controls to a defined failure mode.

AI systems make this mapping especially important because a single interface can combine data retrieval, model generation, plugins or tools, and downstream actions. A control that protects model access does not automatically protect every data source the model can reach, and safe text output does not guarantee safe agent behavior. Study architectures as end-to-end systems rather than treating the model as the whole application.

Use CISM and CISA knowledge strategically

Experienced ISACA candidates may already have strong governance foundations. The CISM exam is especially relevant for security governance, program management, risk, and incident-management thinking. AAISM builds on those instincts but shifts the subject to AI-specific assets, threats, vendors, controls, and lifecycle decisions.

Candidates with an audit background can also draw on CISA for assurance and control-evaluation discipline. The useful carryover is the habit of asking for evidence that a process or control works as intended; the new challenge is applying that discipline to AI data, model behavior, third-party services, and systems whose risk profile can change as they are updated.

The comparison in CISA, CISM, and CISSP career paths can help frame those base disciplines. For AAISM preparation, do not spend weeks relearning generic security management. Identify the concepts you already know, then focus on how AI changes evidence, accountability, threat models, data governance, and the pace at which risk assumptions can become outdated.

Practice with executive scenarios, not only definitions

For final preparation, write decision briefs for realistic situations: a business unit wants to deploy a public generative-AI service with confidential data; a supplier adds an AI feature without prior review; an agent can execute transactions; a model’s performance drifts; an incident suggests sensitive training data was exposed. For each case, identify stakeholders, risk, controls, evidence, escalation, monitoring, and business trade-offs.

AAISM rewards candidates who can keep security connected to enterprise objectives. The strongest answer is rarely “block AI” or “deploy more controls.” It is a reasoned decision that understands the business purpose, establishes accountable governance, reduces risk to an acceptable level, and preserves the evidence needed to know whether the controls actually work.

Create an AI security casebook for the final stage of preparation

Build a set of short cases drawn from different AI operating models: an internal assistant grounded in company documents, a third-party generative-AI SaaS tool, a predictive model supporting a regulated decision, an autonomous agent with tool access, and a model embedded in a supplier’s software. For each case, write the business owner, security owner, data classes, external dependencies, potential harms, and the evidence you would require before approving production use. Repeating the same structure makes differences in risk easier to see.

Then map each case to an enterprise risk process. Identify the threat or failure mode, estimate likelihood and impact, choose treatment, assign control owners, define monitoring, and state the residual risk. The enterprise security leadership is useful here because AAISM expects risk communication that executives can act on. A technically detailed risk statement is weak if it does not explain the business consequence and decision required.

Add a vendor challenge to at least two cases. Assume the supplier will not disclose every model detail, uses sub-processors, changes features frequently, and offers limited log retention. Decide what compensating controls and contractual terms reduce the uncertainty and what risk the organization must still accept. This prepares you for the reality that AI governance often operates with incomplete information. Strong management is not the absence of uncertainty; it is explicit ownership of uncertainty and a process for responding when assumptions change.

Finally, run a tabletop incident for one case. Decide who declares the incident, what data must be preserved, how the AI service is contained without creating larger business harm, when legal or privacy teams are involved, how the vendor participates, and what control changes follow recovery. If your response naturally connects governance, risk, technology, data, vendors, and incident management, you are integrating the three AAISM domains instead of studying them as separate chapters.

Metrics should appear throughout your casebook. Governance needs measures that show whether the program is operating; risk teams need indicators that show exposure is increasing or decreasing; technical teams need monitoring that reveals model or control behavior. Useful measures can include inventory coverage, review completion, policy exceptions, unresolved high-risk findings, model-evaluation failures, vendor issues, incident trends, or time to contain an AI-related event. The exact metric matters less than its connection to a decision and an accountable owner.

When you review laws, standards, and industry frameworks, resist the urge to memorize long lists without context. Instead, ask what requirement or control objective changes because of them: documentation, transparency, risk assessment, human oversight, data governance, testing, incident notification, or third-party accountability. AAISM is a management credential, so the practical skill is translating external expectations into internal governance and controls while recognizing that the applicable obligations depend on jurisdiction, sector, data, and use case.

A final useful habit is to separate control design from control assurance. Designing a review process, approval gate, monitoring rule, or technical safeguard does not prove it works. Decide what evidence would demonstrate effectiveness: completed reviews, test results, logs, incident trends, model evaluations, access records, vendor attestations, or independent assessment. Security managers must be able to ask whether a control is present, whether it operates, and whether it reduces the intended risk. That assurance mindset ties governance and technical controls together.

• Category: All Certifications Certifications