CA ANZ Core 2: Risk, Technology and AI common mistakes
CA ANZ Core 2: Risk, Technology and AI · Understand the traps and how to avoid them.
Cites a framework by name (for example 'apply ISO 31000' or 'use COSO ERM') and then lists generic risk categories, without mapping the framework's components or process steps to the facts in the scenario.
Frameworks are memorised as labels during study, and under time pressure candidates reproduce the label instead of performing the analysis the question asks for.
What to do instead
Use the framework as a structure: name the step (establish context, identify, analyse, evaluate, treat, monitor), apply it to the specific entity and objective, and state what the entity should do at that step using the scenario facts.
Gives a risk rating without saying whether it is inherent, residual or target risk, and without stating the likelihood and consequence basis for the rating.
Heat-map labels are easy to recall; candidates conflate the three ratings and skip the criteria that make a rating defensible.
What to do instead
Before rating, state the objective at risk and the entity's risk criteria; rate inherent risk (before controls), identify and assess the controls, then rate residual risk; label each rating and justify likelihood and consequence separately.
Recommends using a new tool or dataset without addressing confidentiality, privacy, objectivity or professional competence - for example, proposing to upload client data to a public AI service.
Candidates focus on the technical or efficiency benefit and treat ethics as a separate topic rather than a constraint on the recommendation.
What to do instead
For every technology recommendation, run through the professional obligations: legal/regulatory and client confidentiality, data minimisation and cross-border transfer, conflicts and objectivity, competence to use and explain the tool; state the safeguards and escalation.
Classifies a user access review, change management approval or data backup as an application control.
Both categories are 'IT controls', and candidates learn the labels without learning the layer at which each operates.
What to do instead
Ask where the control sits: IT general controls operate across the IT environment (access, change, operations, program development) and support many applications; application controls operate on a specific process or application (input, processing, output, interface). State the layer and why.
Answers a cybersecurity scenario with a list of technical controls (firewalls, MFA, patching) and omits governance, people, third-party and incident response elements.
Technical controls are concrete and easy to list; governance and response are harder to articulate under time pressure.
What to do instead
Structure the answer across people, process and technology: governance and risk ownership, policies and training, identity and access, third-party/supply-chain risk, monitoring and detection, incident response and recovery, and testing (for example penetration testing and disaster recovery exercises).
Draws a conclusion from an analytics dataset without reconciling it to a control total or testing completeness, accuracy and validity of the data.
Attention goes to the analysis technique or visualisation; data quality is assumed rather than tested.
What to do instead
Before analysis, document the source and extraction logic, reconcile record counts and totals to an independent control, test for duplicate, missing or invalid values, and state exclusions; only then interpret results.
Treats a correlation shown in a dashboard or analysis as proof of causation and recommends a causal intervention.
Patterns are visually compelling and candidates want to give a decisive recommendation; confounders and selection effects are overlooked.
What to do instead
State that correlation alone does not establish causation, identify plausible confounders and alternative explanations, check sample size and selection, and recommend further testing or a controlled comparison before acting.
Proposes implementing an AI model in a process without validation, bias testing, performance monitoring, human oversight or an accountable owner.
The benefits and capabilities of AI dominate the discussion; model risk management is a separate body of knowledge that candidates under-rehearse.
What to do instead
Apply model risk management: define purpose, scope and limitations; validate data and model; test for bias and fairness; set performance thresholds and monitor drift; establish human-in-the-loop review, fallback and clear accountability.
States that an audit or assurance engagement 'guarantees' the system is secure or 'will detect' fraud, or otherwise describes assurance as absolute.
Colloquial use of 'assurance' and 'audit' implies certainty; the inherent limitations of assurance are easy to forget.
What to do instead
Use the correct language: reasonable, not absolute, assurance; explain inherent limitations (judgement, sampling, collusion, management override, cost), management's responsibility for controls, and the nature and extent of procedures performed.
Recommends a control without linking it to the specific risk and control objective, or recommends only preventive controls for every risk.
Control types are recited as a list; candidates do not design controls against the risk or consider detection and correction.
What to do instead
For each risk, state the control objective, then the control activity and evidence, and classify it (preventive/detective/corrective; manual/automated); consider cost versus benefit, ownership, frequency and the resulting residual risk.