AAISM has three domains. AI Governance and Program Management is 31 percent, AI Risk Management is 31 percent, and AI Technologies and Controls is 38 percent. On a 90-question paper that works out to roughly 28, 28 and 34 items. Those are the numbers, and they are the easy part.
The harder part is that domain titles describe territory rather than questions. Knowing Domain 1 is called AI Governance and Program Management tells you nothing about whether you can answer an item on it. So this post works one level down, at the sub-areas ISACA publishes under each domain, and says in ordinary words what each expects you to decide.
The blueprint in one table
| Domain | Weight | Sub-areas | What it is really about |
|---|---|---|---|
| 1. AI Governance and Program Management | 31% | 5 | Standing up and running an AI security program |
| 2. AI Risk Management, also published as AI Risk and Opportunity Management | 31% | 3 | Sizing AI risk, treating it, and governing the supply chain |
| 3. AI Technologies and Controls | 38% | 5 | Designing and operating controls for AI systems |
Thirteen sub-areas, with 22 supporting tasks across them. One thing holds throughout: the seat you answer from is the AI security manager's. Not the person training the model, not the auditor writing up findings afterward. The person who sets the requirement, approves or blocks the deployment, and owns the consequence. For the wider picture, the AAISM certification overview covers format, fees and eligibility.
Domain 1 asks whether you can build the program, not whether you know the frameworks
Five sub-areas sit under Domain 1: stakeholder considerations with industry frameworks and regulatory requirements; AI-related strategies, policies and procedures; AI asset and data life cycle management; AI security program development and management; and business continuity and incident response.
That list looks like a vocabulary test. It is not. The organizing idea under all five is that the AI security program inherits from the enterprise security program rather than replacing it, and questions reward the answer that extends what exists.
Take the frameworks. The NIST AI Risk Management Framework is voluntary and outcome-based, organized around governing, mapping, measuring and managing. ISO/IEC 42001 is a certifiable management system standard that pairs with ISO/IEC 27001. The testable part is not those definitions but which one a scenario asks you to apply. The EU AI Act appears conceptually, as risk-tiered legal obligation rather than a control checklist, and its timelines and article references move often enough to check at the source.
Asset management is where Domain 1 gets concrete and where most candidates find a gap. An inventory that lists models and stops there is incomplete. Training datasets, pipelines, system prompts, embedding stores and inference endpoints are assets too, and leaving any off the register quietly breaks classification, recovery scoping and incident scoping downstream. Shadow AI belongs there as well.
Business continuity reads familiar and behaves differently. Restoring a database restores the data. Restoring a model restores weights that may not match the current configuration, system prompt or embedding store, and one system can carry two recovery time objectives: one to get inference serving again, another to get the ability to retrain back. Whether fraud screening continues on rules or halts when the model is down is a business decision you frame rather than make.
Incident response closes the domain with categories your old playbook does not have: model compromise, data poisoning, prompt injection, harmful output, model extraction and availability attacks on inference. The recurring governance point is decision authority. Who can take a production model offline, and was that settled beforehand or argued about mid-incident.
Domain 2 asks whether you can size AI risk and then live with your answer
Three sub-areas carry the same weight as the five in Domain 1: AI risk assessment, thresholds and treatment; AI threat and vulnerability management; AI vendor and supply chain management.
The first is the heart of it. AI risk behaves differently because models are non-deterministic, they drift, they depend on data you often do not control, and they are opaque enough that you cannot always explain a single decision. Thresholds are how an appetite statement becomes testable, in four categories: performance, bias and fairness, drift, and safety or harm. Set them before deployment. Setting them afterward inverts the governance relationship, because whatever the model happens to be doing becomes the standard.
Real programs work in tolerance bands rather than pass-fail lines: a normal range, a warning zone that raises monitoring frequency and alerts the model owner, and a breach that triggers a defined response. Two failures recur: escalation that arrives weeks late, and a single engineer suspending a production model without telling anyone with authority.
Treatment is the classic four options applied to something new. Non-determinism in a generative model is usually accepted with compensating controls rather than mitigated, because mitigating it would defeat the system. Transfer through a vendor contract moves financial exposure and leaves regulatory and reputational exposure with you. Human-in-the-loop sits across all four, and the credited answer is rarely just "require human review": it turns on whether the reviewer has time, context and authority to override, or is rubber-stamping hundreds of recommendations an hour.
Threat and vulnerability management brings in threat modeling and the reference catalogs. STRIDE still works as a starting vocabulary: spoofing covers adversarial inputs that fool a classifier, tampering covers data poisoning and weight manipulation, elevation of privilege covers prompt injection that gets a model to call a tool it should not reach. What it covers poorly, model theft and supply-chain compromise, you take from the OWASP Top 10 for LLM Applications and MITRE ATLAS.
Vendor and supply chain is a program, not a questionnaire. Model and data bills of material are what tell you which deployed models were trained on a dataset that later turns out to be poisoned or unlicensed. Open-weight models from a public repository need hash verification, license review and the change control you apply to any dependency. If you are weighing this credential against the audit-side one, AAIA versus AAISM sets the two lenses side by side, and the AAIA domains show how differently the same material gets carved up.
One domain, two official titles
Domain 2 has a naming problem, and both names come from ISACA. The exam content outline page on isaca.org calls it AI Risk Management. The official AAISM Exam Candidate Guide calls it AI Risk and Opportunity Management, in two separate places.
We name both and pick neither, because ISACA has not picked either. Nothing underneath moves: same 31 percent, same three sub-areas in both sources, Domains 1 and 3 worded identically across the two documents. If a course outline uses one title and your candidate guide uses the other, that is not a version mismatch and not a sign the blueprint changed. Match study material to the sub-areas and ignore the heading.
Domain 3 asks whether you can specify a control for something that is not deterministic
At 38 percent this is the largest domain, and its five sub-areas are AI security architecture and design; the AI life cycle covering model selection, training and validation; data management controls; privacy, ethical, trust and safety controls; and security controls and monitoring.
Architecture comes first because it constrains everything after it. Four deployment patterns recur, each with its own control set. On-premises gives you full network and residency control and hands you the training cluster and artifact store to defend. Cloud-hosted puts you in a shared-responsibility split where misconfiguration dominates. A hosted third-party API means data leaves with every request, so contractual levers become the primary control. Retrieval-augmented generation adds a second attack surface in the retrieval index, where content someone injected into a document can steer the output.
Trust boundaries are the design idea worth drilling. Four matter: external input to inference endpoint, inference environment to model artifact store, training environment to the data stores feeding it, and the AI system out to the monitoring plane. The artifact store boundary is the one people miss. If an attacker can write to it, they can substitute a tampered model that your inference server loads without complaint, which is why integrity verification at load time is a design requirement.
Zero trust extends that thinking to identity, and the AAISM version is mostly about non-human principals. The training job, the deployment script, the inference service and the monitoring agent are each an identity that should authenticate, hold a minimally scoped role and log every call. A microservice that reaches a model endpoint without authentication because it is internal is a finding, not a design.
The life cycle sub-area covers model selection, training and validation from a security viewpoint, including the difference between validating a model's accuracy and validating that the artifact in production is the one the approved training run produced. How hard the AAISM exam is goes further into that pairing and into adversarial machine learning.
Data controls, then privacy, ethics, trust and safety, are where security managers are most often surprised to find themselves. Bias sits here as an integrity problem: a model systematically wrong for one population is producing wrong output. You are expected to recognize demographic parity, equal opportunity and calibration, and to know they cannot all hold at once, so the governed answer is that the organization chose one, documented why, and monitors it. Content safety works the same way. Output filtering, safety classifiers and guardrails are controls with owners, thresholds and test results, not features the product team handles. A safety classifier is itself a model, so it drifts and can be evaded, and a policy that says "avoid harmful content" is not a control specification.
Monitoring closes the domain, and the pattern worth remembering is the AI gateway: one proxy in front of the model enforcing authentication, input validation, rate limits, output filtering and logging for every caller, so no application can quietly opt out. Behind it sits a containment ladder in escalating order of pain: tighten rate limits, block identities, switch to a stricter guardrail profile, route outputs to human review, roll back a version, suspend the service.
Study Domain 3 first, and study it twice
Here is the opinion. Work the domains in reverse: Domain 3, then Domain 2, then Domain 1.
The usual advice is to start at Domain 1 because governance is the foundation. On this exam that is backwards. Everyone sitting AAISM already holds an active CISM or CISSP, the eligibility rule that shapes everything else, so Domains 1 and 2 are familiar structures with new objects inside them. Domain 3 is the biggest weight, the most technical, and the part your existing credential prepares you for least.
The second reason matters more. Domain 1 and Domain 2 questions are often unanswerable without Domain 3 knowledge. Choosing a risk treatment means knowing what the mitigating control does and fails to do. Setting a drift threshold means knowing what drift detection measures. Read the governance material first and you will understand the words, miss the items, and have to come back.
So give Domain 3 your first block and plan a second pass on it near the end, with Domains 2 and 1 in between, where they read as consolidation rather than new material. Our AAISM study guide is built at the published 31/31/38 proportions for that reason, with Domain 3 split across three chapters. For a week-by-week version, see the AAISM study plan, and to see how the supporting tasks read as actual items, the AAISM practice questions walkthrough.
One caution on the weights: they tell you where the questions are, not where the pass mark is. AAISM is scored on a scaled range of 200 to 800 with 450 to pass, and the domain lines on your result report are informational only, because the scoring model does not use domain percentages. Weight your hours by the blueprint because that is where the items live, not because one weak domain sinks you.
FAQ
What are the three AAISM domains and their weights?
AI Governance and Program Management at 31 percent, AI Risk Management at 31 percent, and AI Technologies and Controls at 38 percent. Those weights appear on both ISACA's exam content outline page and its AAISM candidate guide. On a 90-question exam they work out to roughly 28, 28 and 34 questions.
Why is the second AAISM domain called two different things?
Because ISACA publishes two titles for it. Its web outline page says AI Risk Management and its official AAISM Exam Candidate Guide says AI Risk and Opportunity Management. The weight and all three sub-areas are identical in both documents, so nothing about what is examined changes. Study the sub-areas rather than the title.
Which AAISM domain should you study first?
Domain 3, AI Technologies and Controls. It is the largest at 38 percent, the most technical, and the material your CISM or CISSP background covers least. Governance and risk questions also depend on knowing what the underlying controls do, so learning Domain 3 first makes the other two domains read as consolidation.
Do you have to pass each AAISM domain separately?
No. AAISM is reported as a single scaled score from 200 to 800, with 450 required to pass, and ISACA states that scoring does not use domain percentages. The domain-level lines on your result report are informational feedback rather than separate hurdles you can fail independently.
What frameworks do the AAISM domains draw on?
The material is standards-aware rather than vendor-specific. Expect the NIST AI Risk Management Framework and ISO/IEC 42001 paired with ISO/IEC 27001 in Domain 1, the OWASP Top 10 for LLM Applications and MITRE ATLAS in Domain 2, and AI-specific architecture, privacy and monitoring controls in Domain 3. Check current versions and regulatory dates at the source, since those move.
Working through all three domains? ISACA AAISM: Simply Certified Study Guide teaches every published sub-area at the 31/31/38 weighting, from the AI security manager's lens, with two full-length practice exams and every answer explained.
Simply Certified is an independent publisher. AAISM, AAIA, CISM and ISACA are trademarks of ISACA. Our books are independent study material and are not affiliated with, endorsed by, or sponsored by ISACA.