AI Risk Treatment Plans and Action Tracking
AI Risk Treatment Plans and Action Tracking form the execution backbone of an AI Risk Program, translating identified and assessed risks into concrete, accountable mitigation work. A Risk Treatment Plan documents how each prioritized AI risk will be addressed. For every risk (e.g., model bias, data poisoning, hallucination in high-stakes outputs, regulatory non-compliance under the EU AI Act, or unsafe autonomous behavior), the plan specifies a treatment option: mitigate (add controls such as bias testing, red-teaming, human-in-the-loop review, guardrails, or monitoring), transfer (insurance, vendor contractual terms), avoid (decline or constrain the use case), or accept (with documented rationale and sign-off at the appropriate authority level). Each treatment defines target residual risk, success criteria, cost/effort estimates, dependencies, an owner, and a due date. Mature programs align treatments to frameworks such as NIST AI RMF (Govern, Map, Measure, Manage) and ISO/IEC 42001 and 23894, ensuring controls are traceable to recognized obligations. Action Tracking is the operational discipline that ensures treatments actually happen. Actions are logged in a risk register or GRC tool with status (open, in progress, blocked, completed, verified), evidence requirements, and escalation paths. Key practices include: assigning single accountable owners; setting SLA-based deadlines proportional to risk severity; requiring independent verification that a control works (not just that a task closed); re-assessing residual risk after completion; and tracking overdue or recurring issues as indicators of systemic weakness. Metrics such as percentage of high-risk actions overdue, mean time to remediate, and treatment effectiveness rates feed governance dashboards and board reporting. Advanced considerations include lifecycle integration (treatments tied to model release gates and post-deployment monitoring), dynamic re-planning when drift or incidents change the risk profile, and linking actions to audit trails for regulators. Done well, treatment plans and action tracking convert risk awareness into demonstrable, continuously improving control over AI systems.
AI Risk Treatment Plans and Action Tracking: A Complete Guide for the ISACA AAIR Exam
Identifying and assessing AI risk is only half the job. A risk that is analysed, scored and documented but never acted upon delivers no protection to the enterprise. Treatment planning and action tracking are the mechanisms that convert a risk register from a static inventory into a living management tool. ISACA emphasises this because the credibility of an AI risk program is judged not by how many risks it lists, but by whether exposure actually moves toward the organisation's risk appetite over time.
For AI systems specifically, treatment and tracking are harder than for traditional IT. Models drift, training data changes, regulatory expectations (EU AI Act, NIST AI RMF, ISO/IEC 42001) evolve, and third-party foundation models are updated without notice. A treatment that was effective at deployment may become ineffective six months later. This is why the AAIR body of knowledge treats tracking and re-validation as inseparable from treatment planning.
2. What an AI Risk Treatment Plan Is
A risk treatment plan is a documented, approved set of actions designed to bring a specific AI risk from its current (inherent or current residual) level to a target residual level that is within the organisation's risk appetite and tolerance. It answers five questions:
- What will be done (the chosen treatment option and specific controls or actions)
- Who is accountable (the risk owner) and who is responsible for execution (the action owner)
- When it will be completed (milestones and target dates)
- With what resources (budget, people, tooling)
- How success is measured (acceptance criteria, key risk indicators, target residual risk)
The four classic treatment options (ISO 31000 / COBIT / ISACA Risk IT):
- Mitigate (Reduce): Implement controls to lower likelihood or impact. AI examples: bias testing and re-weighting of training data, adversarial robustness testing, human-in-the-loop review for high-stakes decisions, output guardrails and content filters, model monitoring for drift, explainability tooling, data lineage controls, access controls on model weights and prompts.
- Avoid (Terminate): Stop or do not start the activity. AI examples: decide not to deploy a model for a prohibited or unacceptable-risk use case; remove a feature that relies on sensitive attributes; decline a vendor whose model cannot be audited.
- Transfer (Share): Shift part of the financial or operational consequence to another party. AI examples: cyber or AI liability insurance, contractual indemnities and SLAs with model providers, shared responsibility clauses. Note: accountability for the risk and for regulatory compliance cannot be transferred, only the financial consequence.
- Accept (Tolerate): Formally acknowledge the risk and take no further action, usually because the cost of treatment exceeds the benefit or the risk is already within appetite. Acceptance must be explicit, documented, approved by the appropriate authority (the business risk owner, not the risk practitioner), and periodically re-reviewed.
Some frameworks add a fifth option, Exploit or Enhance, for positive risk (opportunity), which can appear in AI contexts where a model's capability creates upside that the organisation wants to capture.
Core components of a well-formed treatment plan:
- Risk ID and linkage to the risk register and the AI system inventory
- Risk owner (accountable, typically a business or product leader)
- Treatment option selected and rationale (cost-benefit justification)
- Specific actions, each with an action owner and due date
- Dependencies and resource requirements
- Expected residual risk after treatment and comparison to risk tolerance
- Key risk indicators and key control indicators to confirm effectiveness
- Evidence required to demonstrate completion
- Approval signatures and date
- Review frequency and triggers for re-assessment (e.g., model retraining, new data source, regulatory change)
3. How Treatment Planning Works in Practice
Step 1 - Start from the assessment. The treatment plan is derived from the risk assessment output: the risk scenario, inherent likelihood and impact, existing controls, and current residual risk. If the current residual risk is already within tolerance, the correct treatment is usually formal acceptance with ongoing monitoring, not more controls.
Step 2 - Select the treatment option. Evaluate options against cost, feasibility, time to implement, alignment with business objectives, regulatory obligations and risk appetite. ISACA consistently expects the practitioner to recommend the option that is cost-effective and aligned with appetite, not simply the one that reduces risk the most.
Step 3 - Design the actions. For mitigation, define controls across the AI lifecycle: data (quality, provenance, consent), model (validation, fairness testing, red-teaming), deployment (access control, rate limiting, logging), and operations (monitoring, incident response, retraining triggers). Controls should be mapped to a framework such as NIST AI RMF (Manage function), ISO/IEC 42001 Annex A controls, or COBIT objectives.
Step 4 - Assign ownership. The risk owner is accountable for the risk and for approving the plan and the residual risk. Action owners are responsible for delivering individual tasks. The risk function facilitates, challenges and tracks; it does not own business risk.
Step 5 - Obtain approval and funding. The plan is approved at a level commensurate with the risk rating; high or critical AI risks typically require executive or AI governance committee sign-off.
Step 6 - Record in the risk register. The register becomes the single source of truth linking risk, treatment, actions, status and evidence.
4. How Action Tracking Works
Action tracking is the continuous process of monitoring the execution of treatment plans, verifying that completed actions actually reduce risk, and escalating when progress stalls.
Key elements:
- Status taxonomy: Not started, In progress, Completed pending validation, Closed (validated), Overdue, Deferred, Cancelled. Closure should require evidence and independent validation, not just the action owner's declaration.
- Milestone and due-date monitoring: Track aging of open actions and days past due.
- Escalation paths: Overdue or slipping actions on high-rated risks are escalated to the risk owner, then to the AI governance committee or risk committee. Escalation is based on the risk rating and the degree of slippage, not on who the action owner is.
- Effectiveness validation: After implementation, re-assess residual risk using KRIs, control testing, model performance metrics (fairness metrics, drift indicators, error rates) or internal audit review. If residual risk is still above tolerance, the plan is revised, not closed.
- Change triggers: Model retraining, new use cases, vendor model version changes, data source changes, incidents and regulatory updates should automatically trigger review of related treatment plans.
- Reporting metrics: Percentage of actions completed on time, number and aging of overdue actions, trend of residual risk versus appetite, number of risks accepted above tolerance (exceptions), KRI breaches, and re-opened actions.
- Tooling: GRC platforms, AI model inventories and model registries, ticketing systems integrated with MLOps pipelines so that control evidence (test results, monitoring alerts) is captured automatically.
- Governance cadence: Regular reporting to the AI governance committee, risk committee and board, with dashboards that show status by risk rating and business unit.
5. Common Weaknesses Examiners Expect You to Recognise
- Treatment plans without a named accountable owner
- Actions marked complete without evidence or validation of effectiveness
- Risk acceptance done informally or by the wrong person (e.g., the data scientist accepts a business risk)
- Treating control implementation as the end state rather than re-measuring residual risk
- No linkage between model changes and treatment plan review
- Over-treating low risks while high risks remain open
- Relying on vendor assurances without contractual rights to audit or monitor
- Metrics that measure activity (number of actions closed) rather than outcome (residual risk reduction)
6. Exam Tips: Answering Questions on AI Risk Treatment Plans and Action Tracking
Tip 1 - Anchor every answer to risk appetite and tolerance. When asked which treatment to recommend or whether to close a risk, the deciding factor is whether residual risk is within the approved appetite. Options that mention alignment with appetite or tolerance are usually correct over options that simply maximise risk reduction.
Tip 2 - Know who does what. The risk owner (business) is accountable, approves the treatment plan and accepts residual risk. The action owner executes. The risk practitioner facilitates, advises, tracks and reports. Senior management or the board sets appetite. If an answer has the risk manager accepting business risk, it is wrong.
Tip 3 - Cost-benefit beats maximum control. ISACA favours the treatment whose cost is proportionate to the risk reduction. If a control costs more than the potential loss, acceptance or a cheaper alternative is the better answer.
Tip 4 - Completion is not closure. When a question describes an action marked complete, the BEST next step is almost always to validate effectiveness and re-assess residual risk, not to update the register or inform management first.
Tip 5 - Watch for the words FIRST, BEST, MOST important, PRIMARY. FIRST questions usually want you to confirm facts, re-assess or consult the risk owner before acting. BEST questions want the most complete, governance-aligned response. PRIMARY often points to the fundamental purpose (e.g., the primary purpose of action tracking is to ensure risk is reduced to an acceptable level, not to produce reports).
Tip 6 - Escalation is driven by risk rating and slippage. An overdue action on a high-rated AI risk should be escalated to the risk owner and governance committee; it should not simply be given a new date. Deferral requires documented approval and interim compensating measures.
Tip 7 - Transfer never removes accountability. If a question involves outsourcing an AI model or buying insurance, remember the organisation remains accountable for outcomes and regulatory compliance; only financial impact is shared. Correct answers will mention contractual controls, right to audit, monitoring and ongoing oversight.
Tip 8 - AI-specific triggers matter. Expect scenarios where a model is retrained, a vendor pushes a new model version, or input data changes. The correct response is to re-evaluate the related risks and treatment plans because prior control effectiveness can no longer be assumed.
Tip 9 - Prefer outcome metrics. If asked for the best indicator of a treatment program's success, choose residual risk trending toward appetite or KRI performance, not the count of closed actions or the number of policies issued.
Tip 10 - Documentation and approval are not optional. Any answer involving acceptance, deferral or exception must include formal documentation and approval by the appropriate authority with a defined review date. Informal or verbal acceptance is a distractor.
Tip 11 - Eliminate distractors that are tactical when the question is strategic (and vice versa). If the stem is about program governance, choices describing a single technical fix (e.g., add a content filter) are usually wrong. If the stem is about a specific model bias finding, choices about rewriting the enterprise risk policy are usually wrong.
Tip 12 - Think in the lifecycle sequence. Assess, select treatment, plan actions, obtain approval, implement, validate, monitor, report, review. Many questions test whether you know what comes next; keep this sequence in mind and avoid skipping steps.
7. Quick Revision Summary
- Treatment options: Mitigate, Avoid, Transfer/Share, Accept (plus Exploit for opportunity).
- A treatment plan links a specific risk to owned, dated, resourced actions with a target residual risk and success criteria.
- The risk owner accepts residual risk; the practitioner tracks and challenges.
- Tracking requires evidence-based closure, effectiveness validation, escalation of overdue items and review triggers tied to model and data changes.
- Success is measured by residual risk moving within appetite, not by activity counts.
- Frameworks to reference: NIST AI RMF (Manage), ISO/IEC 42001, ISO 31000, COBIT, ISACA Risk IT, EU AI Act risk tiers.