AAISM AI risk management explained

Updated September 20, 2026

AI Risk Management is worth 31% of AAISM — around 28 questions. ISACA describes it as assessing and managing risks, threats, vulnerabilities and supply chain issues related to enterprise-wide AI adoption.

The methodology here is the one you already use. What changes is the catalogue: new sources of risk, new threats that target stages traditional systems do not have, and a supply chain that includes things you cannot inspect.

Risk assessment, thresholds and treatment

Standard discipline applied to a non-standard asset. Three AI-specific wrinkles are worth holding:

AI risk is probabilistic, not binary. A model is not secure or insecure; it is accurate to a degree, grounded to a degree, fair to a degree. Thresholds therefore have to be expressed as measurements — acceptable error rates, minimum groundedness, maximum disparity between groups — rather than as pass or fail.

Risk changes without anyone changing anything. Drift means the risk profile moves as the world diverges from the training data. A risk assessment done at deployment is a snapshot, and this is one of the few asset classes where periodic reassessment is genuinely mandatory rather than good practice.

Treatment is the familiar four. Mitigate, transfer, accept, avoid. Accepting a risk remains a legitimate answer when it is documented, owned and within threshold — ISACA exams reward that recognition, and candidates who reflexively pick “mitigate” lose marks.

The other constant: risk has a named owner in the business, not “the AI team”.

Threat and vulnerability management

Know the AI threat catalogue and, crucially, which lifecycle stage each one targets:

ThreatTargetsEffect
Data poisoningTraining dataModel learns attacker-chosen behaviour
BackdoorTrainingHidden trigger the attacker controls
Model extractionThe deployed modelFunctional copy stolen via queries
Model inversionThe deployed modelTraining data inferred from behaviour
EvasionInferenceCrafted input is misclassified
Prompt injectionInferenceUntrusted input treated as instruction
Oversharing exposureRetrievalModel surfaces data the user should not see

The stage matters because the control differs. A threat against training data is not mitigated by anything you do at the endpoint, and vice versa. Exam scenarios reward identifying the stage before choosing the control.

Vendor and supply chain management

The part with the least precedent in traditional practice, and a named knowledge area in ISACA’s outline.

Your AI supply chain includes pretrained models, third-party datasets, model APIs, embedding services, fine-tuning providers and the library ecosystem. Most of it you cannot inspect the way you would inspect software.

Due diligence questions worth knowing:

  • Provenance — where did the model and its training data come from?
  • Integrity — can you verify the artefact has not been tampered with?
  • Licensing and data rights — was the training data lawfully obtained, and what does that mean for your output?
  • Transparency — will the provider tell you about limitations, known failure modes and evaluation results?
  • Change management — what happens when the provider updates the model underneath you? Silent version changes alter behaviour in production.
  • Continuity — what if the provider withdraws the model or fails?

That change-management point is the one most often missed. With a SaaS vendor, an update changes features. With a model provider, an update changes behaviour, and your validation evidence may no longer hold.

Sample questions

Question 1. A model provider updates its hosted model without notice, and your production outputs change measurably. Which is the MOST effective control to have had in place?

  • A. An availability service level agreement with the provider
  • B. Switching to a different model provider
  • C. Contractual change notification plus revalidation before adopting a new model version
  • D. Increased log retention for model interactions
Show answer

Answer: C

A contractual change management and notification requirement combined with revalidation before adopting a new version addresses the actual failure, which is behaviour changing underneath you without evidence. Monitoring detects the change after the fact, moving providers repeats the exposure, and an SLA on availability does not cover behavioural change.

Question 2. A risk assessment finds that an internal AI assistant carries a low-likelihood, low-impact risk of minor inaccuracy, within the enterprise's documented threshold. Which is the BEST response?

  • A. Formally accept the risk, record the owner and set a review date
  • B. Mitigate the risk regardless, as all AI risk should be reduced
  • C. Avoid the risk by withdrawing the assistant
  • D. Transfer the risk through insurance
Show answer

Answer: A

Accepting a risk that falls within a documented threshold, with a named owner and a review date, is a legitimate and expected treatment decision. Mitigating regardless of threshold wastes resources, avoiding removes value disproportionately, and transferring through insurance does not address an operational accuracy concern of this size.

Question 3. An enterprise plans to fine-tune a pretrained open-weights model on internal data. Which risk is MOST specific to this decision, as opposed to building a model in-house?

  • A. Insufficient compute capacity for fine-tuning
  • B. Staff lacking the skills to fine-tune effectively
  • C. Storage costs for the resulting model artefacts
  • D. Inheriting unknown properties of the pretrained weights, including backdoors or bias you cannot inspect
Show answer

Answer: D

Adopting third-party weights inherits whatever is embedded in them, including backdoors and biases you cannot inspect, which is the risk unique to using someone else’s pretrained model. Insufficient compute, staff skills and storage costs are real project concerns but they apply to any model work and are not security risks specific to inheriting weights.

What to practise

Draw the threat table from memory and, for each row, write the control that addresses it and the lifecycle stage it sits at. Then write your model-provider due diligence questionnaire in six questions. Those two artefacts cover most of what this domain can ask, and both are useful at work regardless of the exam.