Risk Management and Policy
Risk management and policy
This domain tests how you identify, score, treat and document AI risk, and how you turn that into policy people can follow. Questions often ask which control addresses a named risk or what a policy must contain.
Core rules
- Risk = likelihood × impact, scored on a defined scale with explicit thresholds; undocumented scales are unenforceable.
- AI-specific risks include bias, hallucination, data leakage, prompt injection, model drift, over-reliance, and third-party/supply-chain exposure.
- Controls are preventive, detective or corrective; record residual risk and who accepted it.
- Policy content: scope, roles, acceptable and prohibited uses, data handling, model approval gates, monitoring duties, exceptions process.
- Threat modelling belongs here: apply STRIDE to AI components or map attacker behaviour to MITRE ATLAS tactics.
Worked example
A team proposes RAG over HR documents so staff can ask policy questions. Risks identified: sensitive-data exposure, retrieval access-control bypass, indirect prompt injection via uploaded documents, and hallucinated policy answers. Treatments: document-level ACLs enforced at retrieval rather than by prompt instruction, output filtering, citation-required answers, red-team test before launch, and monitoring for anomalous retrieval volume. Residual risk is rated medium - accepted by the CISO with a review date, because the alternative (no tool) pushes the same questions into unlogged email.
Traps
- Scoring only model accuracy and ignoring misuse, privacy and downstream decisions.
- Writing policy that names no owner, no approval gate and no exception route.
- Assuming a mitigation removes risk instead of reducing it, so residual risk is never recorded.
- Forgetting that a policy change or new data source is itself a risk event.