Most security professionals have a risk management process they trust. Identify the threat. Assess the likelihood and impact. Select a treatment. Monitor. Repeat. That process works well for the threats it was built around: data breaches, system compromises, insider threats, and regulatory non-compliance.
Now imagine applying that same process to a risk you cannot fully observe. A training dataset that was manipulated months before your AI model was deployed, producing outputs that look correct but are systematically biased toward an outcome that an attacker chose. A vendor-supplied AI component that carries a backdoor invisible to standard security review. An adversarial input crafted specifically to cause your fraud detection model to misclassify a transaction in a way that bypasses your controls entirely.
These are not hypothetical threats. IBM X-Force's 2026 Threat Intelligence Index confirms that large supply chain incidents have increased nearly four times over the last five years, with AI systems representing a growing share of the attack surface. HBR's cybersecurity predictions for 2026 identify data poisoning as one of the defining AI attack vectors of the coming year, corrupting training data at the source in ways that traditional threat intelligence programs are not positioned to detect.
Domain 2 is where AAISM tests whether your risk framework accounts for these threats or whether it was built for a different class of problem entirely. At 31 percent of the exam, approximately 28 questions out of 90, it is the second most heavily weighted domain alongside Domain 1. Getting it right requires understanding not just what AI-specific risks are but how to assess, treat, and monitor them differently from the risks your existing CISM or CISSP preparation addressed.
For a full picture of how Domain 2 connects to the other two AAISM domains, the AAISM exam domains guide maps the complete structure before you go deep into any single domain.
How Domain 2 Connects to Domains 1 and 3
Domain 2 sits between the governance framework Domain 1 establishes and the technical controls Domain 3 implements. Every risk assessment in Domain 2 is conducted within the risk appetite and stakeholder accountability structures Domain 1 defined. Every treatment decision in Domain 2 produces a control requirement that Domain 3 is responsible for implementing.
The practical exam implication is that Domain 2 scenario questions often carry governance context from Domain 1 and control context from Domain 3. A question might describe an organization's AI governance policy from Domain 1, present an AI-specific threat scenario, and ask which risk treatment option from Domain 2 is most appropriate given those constraints. Treating Domain 2 as isolated risk methodology content rather than as the middle layer of a connected governance sequence is one of the most common Domain 2 preparation mistakes.
2.A AI Risk Assessment, Thresholds, and Treatment
Risk assessment methodology is the area where AAISM Domain 2 preparation most directly builds on CISM and CISSP foundations, and also where it most directly extends beyond them.
What transfers from traditional risk assessment
The foundational concepts transfer cleanly. Identifying threat sources, assessing likelihood and impact, prioritizing risks by severity, and selecting treatment options based on cost-benefit analysis are all applicable in AI risk contexts. If you hold CISM or CISSP, this content is not unfamiliar territory.
What AI risk assessment adds
The extension begins when the risk being assessed is embedded in the model's training rather than in a system's configuration. Traditional risk assessment assumes the system under assessment behaves consistently within defined parameters. AI systems do not always meet that assumption. A model that assesses creditworthiness introduces risk not just through access control gaps or configuration errors but through the statistical properties of its outputs: who it approves, who it denies, and whether those patterns are fair, defensible, and aligned with the organization's stated governance standards.
AI risk assessment must therefore extend into two areas that traditional methodology does not fully address:
- Output risk assessment: Evaluating not just whether the AI system could be compromised but whether its outputs, even when operating as designed, create organizational risk through bias, regulatory non-compliance, or reputational exposure.
- Behavioral risk assessment: Evaluating whether the model's behavior under edge cases, adversarial inputs, or distribution shift creates risks that were not present at deployment and are not detectable through traditional security monitoring.
Risk thresholds for AI systems
Establishing meaningful risk thresholds for AI behavior is one of the most practically challenging aspects of Domain 2 and one of the exam tests with specific scenario questions.
Traditional risk thresholds are defined against known parameters: a critical vulnerability requires patching within 24 hours, an access control gap above a defined severity requires remediation before the next release.
AI risk thresholds must be defined against behavioral parameters that are inherently probabilistic: at what level of output bias does a model require intervention? At what degree of performance degradation is retraining required? What confidence score threshold triggers human review rather than an automated decision?
The exam tests whether you understand that these thresholds must be defined before deployment, documented as part of the AI governance framework Domain 1 establishes, and monitored continuously through the mechanisms Domain 3 implements. A threshold defined only after a problem emerges is not a governance control. It is a retrospective justification.
Risk treatment for AI-specific risks
The four traditional risk treatment options, accept, avoid, mitigate, and transfer, all apply in AI risk contexts. What changes is how each option is evaluated and implemented:
Treatment option | Traditional application | AI-specific consideration |
|---|---|---|
Accept | Risk falls within defined tolerance. No additional control required. | tolerance. No additional control required. Acceptance of AI behavioral risk requires a documented threshold definition and ongoing monitoring. Silent acceptance is a governance failure |
Avoid | Eliminate the activity or system creating the risk. | Discontinuing a high-risk AI application or restricting its use to lower-risk contexts where the risk falls within tolerance |
Mitigate | Implement controls to reduce the likelihood or impact. | Retraining on cleaner data, adding human oversight for high-stakes decisions, implementing output filtering or adversarial input detection |
Transfer | Shift financial consequences through insurance or contract | Contractual liability allocation with AI vendors for model failures. Regulatory accountability cannot be transferred even when financial liability is |
Looking for some exam prep guidance and mentoring?
Learn about our personal mentoring
2.B AI Threat and Vulnerability Management
This is the sub-section where professionals with strong traditional security backgrounds find the most genuinely unfamiliar content, and where the preparation gap between content review and exam performance is widest.
AI-specific threat categories
The threat categories Domain 2 tests go beyond the threat landscape your existing frameworks were built to address. Each one requires a different assessment approach and a different control response:
Threat Category | What it is | Why traditional controls miss it |
|---|---|---|
Data poisoning | Malicious manipulation of training data to cause the model to produce attacker-chosen outputs | The attack occurs at the data collection or ingestion stage before the model exists. Standard monitoring does not observe training pipelines at this level |
Adversarial inputs | Carefully crafted inputs that cause the model to produce incorrect or harmful outputs while appearing legitimate | Inputs pass validation because they are syntactically valid. The attack exploits the model's decision boundary, not a system vulnerability |
Model inversion | Reconstruction of training data from model outputs through systematic querying | The model is functioning correctly. No unauthorized access has occurred. The risk is in what the outputs reveal about the training dataset |
Prompt injection | User inputs to an LLM that cause it to override its system instructions or safety constraints | Traditional input validation looks for malicious code patterns. Prompt injection uses natural language that is syntactically valid but semantically manipulative |
Model manipulation | Unauthorized modification of model weights or parameters after deployment | Requires infrastructure access that traditional controls address, but the manipulation itself may not be detectable through standard integrity monitoring |
How these threats appear in exam scenarios
Domain 2 threat questions consistently follow the same pattern: a scenario describes an observable condition in an AI deployment and asks you to identify the threat category it most likely represents, the governance response it requires, or the control that would have prevented or detected it.
The most reliable exam principle for threat identification questions is the timing of the threat relative to the model lifecycle. Data poisoning occurs before the model exists. Adversarial inputs and prompt injection occur during inference against a deployed model. Model inversion occurs through repeated querying of a deployed model over time. Model manipulation requires access to the model infrastructure itself. Identifying where in the lifecycle the threat acts usually identifies the correct threat category and points to the appropriate control layer.
AI vulnerability management
Vulnerability management for AI systems shares the name with traditional vulnerability management but addresses a substantially different problem. Beyond traditional CVE tracking and patch management, AI vulnerability management must address:
- Training data vulnerabilities: Gaps in data provenance, validation, and bias assessment that create risks in the model before deployment
- Model architecture vulnerabilities: Design choices that make the model susceptible to adversarial manipulation or output unpredictability
- Inference endpoint vulnerabilities: Gaps in input validation, rate limiting, and output filtering at the point where the model interacts with users
- Operational vulnerabilities: Gaps in monitoring, drift detection, and incident response readiness that create risks after deployment
A practical exam anchor for this sub-section: when a scenario describes a vulnerability in an AI system, identify which lifecycle layer it exists at before selecting a treatment. A vulnerability in the training pipeline requires a different control than a vulnerability at the inference endpoint.
2.C AI Vendor and Supply Chain Management
Vendor and supply chain risk is the Domain 2 sub-section where the threat intelligence is most current and most alarming. The IBM X-Force data cited in the introduction confirms that supply chain incidents have nearly quadrupled over five years. AI systems extend the supply chain attack surface in ways that traditional third-party risk management frameworks were not designed to assess.
Why AI vendor risk is different
Traditional vendor risk management evaluates whether a vendor's security controls meet your organization's requirements: penetration testing results, SOC 2 reports, patch management SLAs, and incident notification procedures. These assessments remain relevant for AI vendors. What they do not capture is the AI-specific risk dimension.
When you procure a pre-trained AI model from a vendor, you are not just procuring software. You are procuring the model's embedded behavior, including any biases, vulnerabilities, or backdoors introduced during training, before the model ever reaches your environment. A SOC 2 Type II report does not tell you whether the training data was poisoned. A penetration test does not tell you whether the model produces discriminatory outputs. An incident notification SLA does not address who bears accountability when the model's outputs cause harm to your customers.
AI-specific vendor risk assessment dimensions
Domain 2 expects you to extend your vendor risk assessment framework to cover four AI-specific dimensions:
- Training data governance: What data was used to train the model? How was it sourced, validated, and assessed for bias? Can the vendor provide documentation of training data provenance and quality controls?
- Model behavior documentation: What performance benchmarks and fairness assessments has the vendor conducted? Are the results independently verified or self-reported?
- Contractual accountability: Who bears accountability if the model produces outputs that harm your customers or violate regulatory requirements? Does the contract address model failure scenarios, not just service availability?
- Ongoing monitoring obligations: What obligations does the vendor have to notify you of model updates, performance changes, or identified vulnerabilities after deployment? What rights do you have to audit model behavior?
Supply chain risk for AI components
Beyond procured models, AI systems are built from supply chains of components: open-source model libraries, training frameworks, data preprocessing tools, and inference infrastructure. Each component represents a supply chain risk that may not be visible in a traditional vendor assessment.
The governance principle Domain 2 tests in supply chain scenarios is accountability without gaps. Every component in the AI supply chain must have a documented owner, a defined security assessment process, and a clear accountability chain for vulnerabilities or failures that originate in that component. A gap in the supply chain accountability map is a governance failure, regardless of whether the gap has been exploited.
For a broader look at how AAISM vendor and supply chain risk connect to the broader AI security governance lifecycle, the AAISM certification guide addresses the full credential context, including how Domain 2 competencies apply in organizational AI governance roles.
Certification in 3 Days
Study everything you need to know for the AAISM exam in a 3-day bootcamp!
How Domain 2 Appears in Exam Questions
Domain 2 scenario questions test applied risk judgment in AI contexts. The consistent pattern across all three sub-sections is that the exam credits governance-first reasoning over technically correct but premature action.
When a scenario presents an AI-specific threat and asks what to do, the governance-aligned answer almost always involves assessing the full scope of the risk before selecting a treatment, connecting the treatment decision to the governance framework Domain 1 established, and documenting the decision with enough specificity to be defensible to regulators and auditors.
The most common exam error in Domain 2 is selecting an answer that addresses the technical symptom rather than the governance root cause. An AI model producing biased outputs is a technical observation. The governance root cause may be inadequate training data assessment, insufficient impact threshold definition, absent bias monitoring, or unclear accountability for model behavior. The exam tests whether you can identify and address the governance root cause rather than just the observable symptom.
For a deeper look at how the AAISM exam's scenario reasoning patterns apply across all three domains, including Domain 2, the how to pass AAISM exam guide provides the full reasoning framework.
Frequently Asked Questions
Domain 2 carries 31 percent of the 90-question exam, which translates to approximately 28 questions. It shares that weighting equally with Domain 1. Together, Domains 1 and 2 account for 62 percent of the exam, with Domain 3 carrying the remaining 38 percent.
Data poisoning occurs during the training phase before the model is deployed. An attacker manipulates the training dataset to cause the model to produce attacker-chosen outputs after deployment. Adversarial inputs occur during inference against an already-deployed model. An attacker crafts inputs that appear legitimate but cause the model to produce incorrect or harmful outputs by exploiting the model's decision boundary rather than compromising the system itself.
Traditional vendor risk management evaluates security controls through SOC 2 reports, penetration test results, and patch management SLAs. AI vendor risk extends that assessment to cover training data provenance, model behavior documentation, contractual accountability for model failures, and ongoing monitoring obligations after deployment. A vendor that passes every traditional security assessment may still introduce significant AI-specific risk through biased or poisoned training data that no standard security control was designed to detect.
Sub-section 2.B, AI Threat and Vulnerability Management, demands the most genuinely new learning. Threat categories, including data poisoning, adversarial inputs, and model inversion, have no direct equivalents in traditional security threat taxonomies. Sub-sections 2.A and 2.C build more directly on existing risk assessment and vendor management expertise, but both require careful extension beyond what CISM or CISSP preparation addresses.
Domain 2 sits between the governance framework Domain 1 establishes and the technical controls Domain 3 implements. Every risk assessment in Domain 2 is conducted within the risk appetite and accountability structures defined in Domain 1. Every treatment decision Domain 2 produces generates a control requirement that Domain 3 implements. Studying all three domains in sequence rather than in isolation is the most efficient preparation approach because each domain provides context that makes the adjacent domains easier to absorb.
How Domain 2 Fits Into Your AAISM Preparation
Domain 2 is where most AAISM preparation plans quietly go wrong. Professionals with CISM or CISSP backgrounds spend their time on the sub-sections that feel familiar and underinvest in 2.B, where data poisoning, adversarial inputs, and model inversion have no equivalents in anything they have studied before.
That gap does not show up until exam day. Sub-sections 2.A and 2.C will feel more accessible, but both require more extension than they appear to on first read. If you are not sure whether your preparation has closed those gaps, that uncertainty is worth taking seriously before you schedule your exam date.
The Destination Certification AAISM Bootcamp delivers three days of live scenario-based instruction across all three domains. The Domain 2 content is taught through AI-specific threat and risk scenarios that build the applied judgment the exam tests, rather than the content familiarity that self-study produces. For professionals who prefer flexibility, the AAISM MasterClass delivers the same instruction in a self-paced format with an adaptive system that identifies your specific Domain 2 knowledge gaps.
Start with the free DestCert App for immediate access to expert-written AAISM practice questions across all three domains at no cost. Testing yourself on Domain 2 scenarios now will show you exactly where your risk framework extends cleanly into AI contexts and where it needs deliberate development before exam day.
The AI systems your organization depends on carry risks that traditional frameworks were not designed to find. AAISM trains you to find them. Destination Certification gets you there.
