AAISM Domain 2 Summary: AI Risk Management

AAISM Domain 2 contributes 31% of your AAISM exam and covers objectives 2.0 through 2.14.2 — the same weight as Domain 1, and the domain most candidates find hardest. This summary is your quick reference to the concepts that actually earn marks, mapped section by section to the objective numbers so you can open ISACA's official AAISM Review Manual — referred to throughout this page as the review manual — at the right page. The Cybernous AAISM Success Toolkit book is a separate study companion and is always named in full.

Let me tell you why it feels hard, because naming it helps.

It is not that the ideas are deep. It is that the attacks have no familiar shape. You have twenty years of pattern recognition for malware, phishing and privilege escalation. You have none for poisoning, evasion, inversion or prompt injection — because those do not target the code. They target what the model learned. Your instincts, which are excellent, do not fire here, and that absence feels like not knowing the material when it is really just not recognizing it yet.

So hold the domain in one frame. Threats come in at the AI system across three surfaces — its data, its model, its supply chain — and your job is to name the surface and route it to one of exactly four responses: accept, avoid, mitigate, transfer. Every scenario the exam builds, however exotic the attack sounds, collapses back to that shape. When you meet an attack you have never heard of, don't panic about the attack. Identify the surface, then choose the response.

2.1 AI Trust and Risk Identification

Objectives 2.0–2.2 · Part A

The review manual opens the domain with trust rather than threats, and the reasoning is worth following. Because the goal of AI is to mimic human behavior in the context of numerous societal factors, risk here includes far more than technical considerations. So the first question is not who might attack the system. It is whether the system deserves to be relied on at all.

Then the sentence the whole domain answers to:

Revision statement. AI systems learn, adapt and evolve in unpredictable ways — which makes it problematic to accurately account for AI risk.

That is an unusually candid line for an official study text. The thing you are assessing changes behavior after you assess it, and nobody can fully predict how.

The seven NIST trust attributes are used in conjunction, never as a menu: valid and reliable · safe · secure and resilient · accountable and transparent · explainable and interpretable · privacy enhanced · fair with harmful bias managed. They recur throughout Domain 2 and again in Domain 3.

Identification itself is contextual — the same model carries different risk in different uses — and it starts where Domain 1 left you: with inventorying AI use. The OWASP Top 10 for LLM Applications applies here too, for the reason it always does: an AI system is still software.

2.2 Frameworks — NIST AI RMF and the EU AI Act

Objectives 2.3–2.3.3 · Part A

Two instruments, and the exam concentrates on the comparison rather than the contents.

Revision statement. The EU prescribes thresholds. NIST recognizes a spectrum.

The NIST AI RMF is voluntary, industry-agnostic, and organized into four functions: Govern establishes risk policies, accountability structures and risk culture · Map identifies system characteristics, risk areas and impact zones · Measure develops metrics and monitors across the life cycle · Manage implements responses and compliance checks, prioritized by potential impact.

The EU AI Act is a regulation. It classifies systems into four categories, requires conformity assessment for high-risk deployment, and applies extraterritorially by impact — a non-EU organization is in scope if its AI affects EU citizens.

Coach's insight. NIST sets no numerical thresholds, and candidates read that as a gap. It isn't — it's a design decision. NIST is written to be usable by a hospital and a hedge fund without either of them inheriting the other's tolerance. The two instruments are complementary, not alternatives: the Act tells you which box you are in, the framework tells you how to work the risk. An option presenting them as competing choices is the distractor.

2.3 Risk Classification and the Three Assessments

Objectives 2.4–2.4.2 · Part A

The Act's four categories give an organization a fast read on what is permissible and what needs rigor:

Revision statement. High risk is permitted with a conformity assessment. Unacceptable is off-limits. They are not neighbors.

Three assessments sit alongside the tiers, and the exam separates them carefully. A FRIA assesses the impact on individuals' fundamental rights against the EU Charter, required for high-risk systems, completed before first use, updated if conditions change, and submitted to the appropriate regulatory authority — it is not an internal document. A conformity assessment evaluates something completely different: the provider's quality management system and technical documentation, with evidence required for all high-risk systems under Article 43 and new assessments after substantial modification. A PIA or DPIA analyzes how personal information is collected, used, shared and maintained — and does not cover the scope of rights a FRIA requires.

2.4 Acceptable Risk Limits

Objectives 2.4.3–2.4.5 · Part A

One of the most heavily tested sections in the domain, and the one where your existing experience transfers most directly — with a single sentence that should give you pause.

Revision statement. An organization's AI risk tolerance may differ from its existing risk tolerance and appetite levels.

Your appetite statement was written for the risks the business knew about. AI may sit outside it. Assuming otherwise, without a decision from the governing body, is exactly the failure this section exists to prevent.

Two ownership facts the exam blurs on purpose. Leaders and/or the governing body are ultimately responsible for establishing risk appetite and tolerance criteria. Management determines acceptable risk levels, normally defined by the losses the organization is willing to accept in pursuit of its objectives. Appetite is what you aim for; tolerance is how far you let it drift before acting.

Then a four-part definition worth holding whole. Appropriate risk is risk taken in pursuit of objectives — necessary to deliver services, achieve goals and comply. Inappropriate risk is risk that does not align with goals, produces no corresponding benefit, exceeds defined appetite and tolerance, or can harm brand, reputation, stakeholder trust or legal responsibilities.

Coach's insight. Read that second bullet again. A risk can be inappropriate simply because it produces no corresponding benefit — it does not have to be large. That is the cleanest argument you will ever have against a pilot nobody can justify, and it is phrased as risk language rather than as obstruction.

CISO Decision Scenario 1 — The Appetite Nobody Checked.

The situation. Your organization is standing up an AI risk register for the first time. Twenty-two systems are in scope. The risk team proposes scoring all twenty-two against the enterprise risk appetite statement approved eighteen months ago, before any of these systems existed.

The room divides. The head of risk says the appetite statement is deliberately technology-neutral and applies to anything. The CTO wants scoring to start immediately so the register exists before the audit committee meets. A board member asks, mildly, whether the statement mentions AI at all. It does not.

The AAISM answer. Stop before scoring. Take one question to the governing body: does the existing appetite cover AI, or does it need a supplement? Get a decision, minuted. Then score.

Why. The review manual states three separate times that AI risk tolerance may differ from existing levels — repetition that signals what the exam wants. A register scored against a statement that was never meant to cover AI produces numbers nobody can defend, and the defect is invisible because every cell is filled in. Note also who answers the question: establishing appetite and tolerance sits with leaders and the governing body, not with the risk team and not with the CTO.

Carry this into the exam. When a stem describes AI being assessed against pre-existing criteria, check whether anyone confirmed the criteria apply. "It probably covers it" is never the keyed answer.

2.5 The Four Risk Responses

Objective 2.5 · Part A

Good news: you already know these. The review manual says so directly — in AI development and use, the risk response options remain the same. The additional considerations are the marks.

Read avoid carefully. It is not "the risk is too big." It is an economic judgment — controls would cost more than the value gained. Avoidance removes the risk entirely but carries opportunity loss, and is not to be chosen lightly or without detailed assessment.

Revision statement. Avoid when control costs exceed the value. Transfer when mitigation would destroy the value.

Acceptance in AI has a specific shape. The worked example: a bank runs AI fraud detection with a known 5% false positive rate and accepts it. The 5% is not a defect awaiting a fix — it is a documented, monitored consequence of a system working as designed. Acceptance requires monitoring and regular reviews; without a number and a reviewer, it is not acceptance.

Transfer runs through insurance, outsourcing or contractual agreements — and note that insurance models operate on delay, deny and defer, while AI liability remains jurisdictionally unsettled.

2.6 AI Threat Modeling

Objective 2.6 · Part A

Threat modeling identifies the variety of actors in a scenario. It produces three things: an abstraction of the system, a profile of attackers including goals, methods and skills, and a catalog of potential threats.

It answers seven questions: how often a threat actor will encounter the asset · what perceived value it holds for the adversary · what resources and materials they would need · what level of effort is required · what danger of discovery they face · what skills they need · how much time it takes.

Read those together and notice what they are doing. None asks is this possible. Every one asks what would it cost the attacker.

Answers are kept in a threat profile per threat community, and overlapping controls should be noted — one control frequently addresses several communities.

Then the part that matters most:

Revision statement. Six threat modeling methods exist, and not one of them adequately covers AI-specific threats.

2.7 The AI Threat Landscape — The Six Attack Categories

Objectives 2.7–2.7.1 · Part B

This section and the two that follow carry more exam weight than any other stretch of the domain. Slow down.

Revision statement. The attack target is what the model learned, not what the code says.

Threats arrive across three attack surfaces: development-time, runtime (which is largely not AI-specific), and threats through use. Four actor groups are named — insiders, nation states, cybercriminals, and AI developers. MITRE ATLAS is the knowledge base.

Then the attacks. The review manual groups them into six categories — note that the sixth pairs two related attacks under one heading, which is why the table below reads as seven rows for six categories:

Coach's insight. If you memorize one distinction from this section, make it evasion versus inversion. Evasion is an attack on a decision — the adversary wants a wrong answer. Inversion is an attack on knowledge — the adversary wants what the model absorbed. Different goals, different controls, and the exam knows most candidates hold them as one blurred idea. They share a category heading; they are not the same attack.

2.8 Nontechnical Threats and Vulnerabilities

Objectives 2.7.2–2.7.3 · Part B

The half of the landscape candidates skim, and it holds one of the most quotable lines in the syllabus.

Revision statement. Ethical concerns cannot be patched. There is no hot fix for biased decision making.

Nontechnical threats may not be covered by existing risk assessment procedures, though many existing controls transfer. The review manual catalogs nineteen categories, and scenarios are built from the groupings rather than the list — learn these five and you can place any category the exam offers:

On vulnerabilities, the structural change is the one to hold: interconnectedness of AI systems increases the attack surface, perimeters are no longer well-defined, and assets are decentralized. Beyond firewalls and IDS/IPS, the named responses are to monitor and restrict lateral movement and to enhance identity-based decision making.

AI-enabled threats are the mirror image — attacks enabled through the use of AI by threat agents. Adversarial models are built specifically to exploit LLM capabilities for crime, AI can optimize cyber kill chain steps, and — the finding worth taking to your awareness lead — traditional phishing and social engineering training can be circumvented, because generative AI removes the bad grammar, generic greeting and false urgency your program teaches people to spot.

2.9 Mitigation — The Seven Patterns

Objective 2.8 · Part B

Mitigations are set out threat by threat. They compress into seven patterns, and the patterns are what let you answer a question about an attack you have never met.

Specific pairings the bank tests: model stealing via API queries → throttling and rate limiting, not encryption · model inversion → strong cryptography, IAM and query parameterization · model poisoning → data validation, governance and provenance · data supply chain attacks → SBOM and provider assessments · overreliance → HITL and redundant decision pathways · unpredictability → fail-safe and kill-switch mechanisms · deepfake content → watermarking and digital signatures; deepfake identity → strong authentication and liveness detection.

Revision statement. Retraining appears as the answer for exactly one thing — drift.

Coach's insight. Most AI risk registers I see are entirely "detect and monitor," because that is where security instinct goes. The judgment-failure and authenticity patterns are usually empty. If your own register has nothing in those two, that is a real finding — and it is also why those two supply so many exam answers.

CISO Decision Scenario 2 — The Wrong Control for the Right Attack.

The situation. Your API logs show a pattern: a single client has issued several hundred thousand queries against your pricing model over three weeks, in small daily volumes, systematically sweeping the input space. Nothing has been breached. No credentials were misused. Every request was authenticated and within contract.

The room divides. The security architect proposes encrypting the model at rest and tightening TLS. The data science lead wants to retrain on obfuscated features. Legal wants to send a breach of contract notice and considers the matter closed.

The AAISM answer. API throttling and rate limiting, plus API access controls. Then the contract conversation, in parallel.

Why. This is model theft through use — reconstructing a model from its answers rather than stealing the artifact. Encryption protects the model at rest and in transit and does nothing here, because the attacker never touches the file; they are being handed the model one legitimate answer at a time. Retraining is the drift response, not this one. The pattern is constrain the interface, and the control that fits it is the one that changes what the interface will do — not the one that protects what sits behind it.

Carry this into the exam. Identify the surface before you choose the control. Encryption is the reflex answer to anything involving a model and an adversary, and it is very often the wrong lane.

Go deeper — the AAISM Success Toolkit. Domain 2 runs Days 18 to 28 of the AAISM Success Toolkit program. Days 22 to 27 alone carry a quarter of the entire question bank, and Day 24 — mitigation strategies — is the single heaviest teaching day anywhere in the fifty. This summary gives you the discriminators. The program gives you all nineteen nontechnical threat categories, the full mitigation table threat by threat, and the nine-step vendor process in sequence.

Explore the AAISM Success Toolkit program →

2.10 Your Role in the Supply Chain and Vendor Management

Objectives 2.9–2.10.1 · Part C

Part C opens with a determination, and everything downstream depends on it.

Revision statement. Your role is decided by how you use AI, not by who you are — and the determination comes before any obligation.

Provider obligations: compliance, especially for high-risk · conformity assessment · documentation · monitoring performance · incident reporting to relevant authorities · cooperation with authorities.
Deployer obligations: use as directed · oversight with qualified individuals · controlling what data is provided · monitoring responses and reporting issues to the provider · transparency — telling people they are interacting with AI · log retention for high-risk systems.

Monitoring and reporting appear on both sides, which is why they generate so many two-option questions. Sort them by direction: the provider monitors performance and reports to authorities; the deployer monitors responses and reports to the provider. An enterprise can be both.

Vendor management runs to nine steps, and the review manual states their purpose plainly: to preserve the ability to exit before the enterprise becomes too reliant on the service. Define internal diligence and need · build an AI vendor inventory · define scope · evaluate reputation and financial stability · assess practices and alignment · define risk appetite for instrumentation · define risk appetite for use, abuse and misuse · establish compliance and incident notification criteria · monitor with triggers for renewed assessment.

2.11 Deployer Considerations and Shared Responsibility

Objectives 2.11–2.12.2 · Part C

A deployer takes an AI system provided by someone else and integrates it into its own processes, products or services. Then the sentence the whole section defends:

Revision statement. Third-party provision does not remove or alleviate deployer responsibility or liability.

The worked illustration is an airline whose customer-facing chatbot made a commitment the airline's own policy did not support. Because the system was acting as an authorized agent, the commitment was binding. The question about a customer-facing AI is therefore not only is it accurate but what can its wrong answers obligate us to.

The AI shared responsibility model is analogous to cloud's and spans six domains: identity and access management · data governance · supply chain risk management · incident response · audits and testing · transparency and explainability. It is made real contractually, through SLAs, defined incident response activities, and incident notification requirements.

Both sides carry transparency, and they mean different things. The provider supplies notifications, tools and documentation so customers understand how the system works. The deployer ensures users know they are interacting with AI and chooses models offering explainability. The provider explains the system; the deployer discloses the interaction.

CISO Decision Scenario 3 — Whose Problem Is a Wrong Answer?

The situation. You license a customer service assistant from a well-regarded vendor. The contract is thorough. The vendor is EU AI Act compliant and has supplied a conformity assessment and full technical documentation. Six months in, a customer complains that the assistant told them they were entitled to a refund they were not — and they acted on it.

The room divides. Procurement's instinct is that this is the vendor's problem: the model produced the wrong answer, and the vendor built the model. The contract has an indemnity clause, which legal is already reading.

The AAISM answer. Work the obligations rather than the instinct. The provider's duties were compliance, conformity assessment, documentation, performance monitoring, incident reporting and cooperation — all discharged. The deployer's duties were use as directed, oversight with qualified individuals, controlling input data, monitoring responses, and transparency. Oversight and response monitoring are yours, and the system was speaking to your customer as your authorized agent.

Why. Third-party provision does not remove or alleviate deployer liability, and an indemnity moves money, not obligations. The finding is not that the vendor failed; it is that nobody was monitoring responses and no human sat in the path of a commitment-bearing answer.

Carry this into the exam. When a scenario splits provider and deployer, sort by who had the visibility. The party that could see the thing is the party that owed the duty.

2.12 Integration Risk and the AI Software Supply Chain

Objectives 2.13–2.14.2 · Part C

Two things arrive uninvited when you adopt someone else's AI: the systems you already have, and the chain of suppliers behind the one you signed with.

Legacy systems are difficult to integrate and frequently not well-suited for AI, which can create or exacerbate technical issues. The named considerations include deciding whether AI makes sense at all, whether a complete overhaul is needed, whether data quality and governance must improve first, the effect on everyone in existing processes and information flows, and a flexible methodology — because modernizing uncovers a lot of unknowns. Legacy modification is not usually of short duration.

Intellectual property runs both ways and neither direction has a technical fix. On the input side, training data drawn from the public web not uncommonly includes copyrighted, patented or proprietary material, which makes output not truly original. On the output side, ownership is uncertain where the model draws on the provider's dataset. Both are resolved with ownership provisions in contracts and legal counsel consulted before agreement.

Then the supply chain, and a reframe worth carrying into your day job:

Revision statement. Traditional supply chain risk management addresses individual components. AI supply chain risk addresses entire systems.

Five dimensions: people · processes · technology · data · model. The data dimension explicitly includes pipelines, datasets, logs, RAG data sources, raw data and training data. An assessment that covers software components but misses the dataset and the weights has covered two of five.

Coach's insight. The parties run first, third, fourth, fifth and N-th — you, who you contract with, who they rely on, who those rely on, and underneath everything, power utilities and data center facilities management. Most enterprise registers stop at third. You will never assess a fifth-party vendor, and that is not the point. The point is that the same fourth-party names appear behind several of your third parties, and concentration risk lives further out than anyone looks.

The Domain in One Breath

AI risk cannot be fully accounted for because the system keeps changing, the frameworks tell you which box you are in rather than whether you should be there, the attacks target what the model learned rather than what the code says — and most of your AI belongs to somebody else.

Quick Recap

• AI learns, adapts and evolves unpredictably — accounting for its risk is inherently problematic
• Seven NIST trust attributes, used in conjunction; risk is contextual; identification starts with inventorying use
• EU prescribes thresholds; NIST recognizes a spectrum — complementary, not alternatives. Map identifies, Measure monitors
• High risk is permitted with conformity assessment; unacceptable is prohibited
• FRIA — fundamental rights, high-risk, submitted to a regulator · conformity assessment — the provider's QMS and documentation · DPIA — narrower than a FRIA
• Existing appetite may not cover AI; governing body establishes appetite, management determines acceptable levels by losses accepted
• Inappropriate risk includes risk producing no corresponding benefit
• Avoid = control costs exceed value · transfer = mitigation would destroy value · responses combine
• Acceptance means knowing the number, monitoring it, reviewing it
• Threat modeling: abstraction, attacker profile, threat catalog, seven cost questions. Six methods, none sufficient for AI
• Three surfaces: development-time, runtime, through use. MITRE ATLAS is the knowledge base
• Six attack categories: leakage · poisoning, five entry points including RAG · model poisoning, three methods · theft through use · prompt injection, no privileges needed · evasion and inversion, where evasion fools and inversion interrogates
• No hot fix for biased decision making; nineteen nontechnical categories across five groupings
• Seven mitigation patterns; throttling answers API model theft; retraining answers only drift
• Role is decided by use; third-party provision does not remove deployer liability
• Nine vendor steps exist to preserve exit; appetite defined twice; high risk ≠ rejection
• Six shared domains, made real through SLAs, IR activities and notification requirements
• Supply chain: five dimensions, entire systems, parties to N-th

The Five Domain 2 Facts the Bank Tests Hardest

1. The provider-versus-deployer determination comes first — every obligation follows it, and third-party provision does not remove deployer liability.
2. Existing risk appetite may not cover AI. The review manual repeats it three times; the exam rewards the answer that checks rather than assumes.
3. Avoid when control costs exceed the value; transfer when mitigation would destroy it — and responses combine rather than compete.
4. Evasion fools the model; inversion interrogates it — and data poisoning is one route into model poisoning, not a synonym for it.
5. No threat modeling method adequately covers AI. An option naming one as sufficient is wrong regardless of which it names.

"Two Correct Answers" Elimination Playbook — Domain 2

Stuck between two options that both look right? Work down this list in order.

1. Determine before you act. If provider-versus-deployer status is unresolved, determining it precedes every control, contract and notification.
2. Match the obligation to the visibility. Between two parties, the duty belongs to the one who could actually see the thing.
3. Match the control to the surface. Name the surface first — data, model, supply chain — then choose. Encryption is the reflex answer and frequently the wrong lane.
4. Check the criteria before applying them. If AI is being scored against pre-existing appetite or tolerance, confirming those apply comes first.
5. Economic, not emotional. Avoidance means control costs exceed the value gained — not that the risk feels large.
6. Value-preserving beats risk-eliminating. If mitigation would destroy the benefit, transfer. If it wouldn't, mitigate.
7. Nontechnical threat, nontechnical answer. Bias, overreliance, hype adoption and reputational harm have no hot fix.
8. Combination over purity. For threat modeling and for risk response alike, the answer that combines beats the answer that picks one.

Closing

Domain 2 is 31% of your exam and the one candidates tell me felt shapeless. It stops being shapeless the moment you stop trying to recognize the attacks and start routing them.

If you take three things from this page, take these. The determination comes first — provider or deployer decides everything after it. Match the control to the surface, not to the vocabulary in the stem. And check whether anyone actually confirmed your appetite covers AI.

One thought for the road. Every attack in this domain works by the same trick: it goes after what the system learned rather than what it was built from. Once you feel that, poisoning and inversion and prompt injection stop being four unfamiliar words and become four doors into the same room. Find the door, and the answer is usually already in your hands.

Continue your AAISM study: AAISM Domain 1 — AI Governance and Program Management · AAISM Domain 3 — AI Technologies and Controls · AAISM coaching program.

AAISM™ is a trademark of ISACA. Cybernous Infosec Consulting LLP is an independent training provider and is not affiliated with, accredited by, or endorsed by ISACA. Domain weights and exam details are per ISACA's published AAISM exam content outline; objective numbering follows the ISACA AAISM review manual.