ICAB CL Management Information common mistakes
ICAB CL Management Information · Understand the traps and how to avoid them.
When asked to classify a control, the candidate labels it by the technology involved (e.g. 'it is an IT control because software enforces it') instead of by its purpose and timing, so preventive, detective and corrective controls are mixed up and application controls are confused with general IT controls.
Candidates memorise control names as a list and never build the two-axis model (purpose: preventive/detective/corrective; scope: general IT vs application). Under time pressure the surface feature (it is automated) dominates the classification decision.
What to do instead
Before answering, write the two axes on scratch paper and place every control on both. Drill with a fixed set of examples: segregation of duties and access restriction (preventive, general IT), exception report and reconciliation (detective, application), backup restore and incident recovery (corrective). Justify each placement in one sentence naming purpose and scope.
The candidate answers governance questions by describing what management does operationally, treating the IT director or CIO as the governing body, and omits the board's role in setting direction, appetite and assurance.
Day-to-day exposure is to IT operations, so the mental model of 'who runs IT' crowds out the distinction between direction-setting, execution and monitoring. Candidates also conflate governance structures with governance outcomes.
What to do instead
Anchor every governance answer on the three-tier split: board sets direction and risk appetite and monitors; executive management executes and reports; assurance functions (internal audit, independent review) provide independent verification. Practise phrasing answers as 'the board should approve and monitor X, management should implement Y, audit should independently assure Z'.
In questions about data quality or analytics, the candidate proposes 'clean the data' or 'buy a better tool' without naming the specific dimension of quality affected, the business process that generates the defect, or the decision the analysis is meant to support.
Textbook data-quality dimensions are recalled as vocabulary but not linked to root causes in source processes, and analytics questions are read as technology questions rather than decision-support questions.
What to do instead
Structure answers as dimension, cause, control, decision impact. Example: completeness failures in customer records arise at point of capture because fields are optional; fix with mandatory validation at entry plus periodic exception reporting; this matters because segmentation analysis understates market coverage. Always state the decision the information supports before recommending a remedy.
The candidate treats risk assessment as a single judgement ('this is high risk') and skips the components: asset and threat identification, likelihood and impact, existing control evaluation, residual risk, and the chosen risk response (avoid, reduce, transfer, accept).
Risk is discussed in ordinary language where 'high risk' feels sufficient, and candidates do not habitually separate inherent from residual risk or attach a named response to each risk.
What to do instead
Use a fixed five-line template for every risk item: asset/process at risk, threat and vulnerability, inherent likelihood and impact, existing controls and resulting residual rating, and the response with owner. If the question asks for treatment, always name one of the four responses explicitly and justify it against the organisation's risk appetite.
When asked about segregation of duties or access control, the candidate recommends 'strong passwords and training' and misses the structural controls: role-based access, least privilege, maker-checker separation, privileged access monitoring, and periodic access reviews.
Awareness-level security knowledge is more familiar than design-level control knowledge, so candidates default to user-behaviour controls when the question is about system design and authorisation architecture.
What to do instead
Classify each recommended control as administrative, technical or physical, and as preventive or detective. For any SoD question, first map the conflicting duties in the process (initiate, authorise, record, reconcile) and then state which system restriction enforces the separation and which review detects failures of that restriction.
On systems development questions, the candidate describes the waterfall stages in order but cannot say what each phase produces, who signs off, or how control gates and change control work after go-live, and mixes up validation, verification, user acceptance testing and post-implementation review.
Methodologies are learned as sequences of names rather than as sets of deliverables and decision points, and change management is studied separately from development so the link between them is not made.
What to do instead
For each phase, memorise the deliverable and the approval: requirements produces a signed-off specification, design produces a specification reviewed against requirements (verification), testing produces evidence of fitness for purpose (validation), and go-live is followed by a post-implementation review against the original business case. Add the change path: request, impact assessment, authorisation, testing in a controlled environment, controlled migration, and fallback plan.
The candidate answers emerging-technology questions with enthusiasm about benefits and omits the control, assurance and risk implications, or treats a new technology as exempt from the governance and control principles already studied.
Novelty creates a framing effect: the question seems to be about what the technology can do, so candidates write a capability summary instead of applying the same control lens used elsewhere on the paper.
What to do instead
Answer every emerging-technology question in three moves: what the technology changes in the process, which existing control principles still apply unchanged (authorisation, traceability, data integrity, independent assurance), and what new risk it introduces that needs a new control. For example, with AI-assisted decision support, state who remains accountable for the decision, how outputs are validated, and how bias and model drift are monitored.
The candidate describes a business process as a list of departments or job titles rather than as a sequence of activities with inputs, outputs, decision points and controls, so process-improvement questions get answered with organisational restructuring.
Candidates think about processes through the lens of the org chart they have seen, and have not practised separating the logical process from the people who currently perform it.
What to do instead
Draw the process as a horizontal flow with swimlanes for roles and mark each control point. Then answer improvement questions against that flow, identifying delays, handoffs, duplication and missing controls. State inputs, transformation steps, outputs and the customer of the process before proposing any change.
The candidate writes long descriptive answers that restate the scenario and never state a recommendation, or gives a recommendation without justification, so marks for application and evaluation are lost even when knowledge is sound.
Case-based questions reward structure but candidates answer in narrative prose under time pressure, and they confuse showing understanding with demonstrating judgement.
What to do instead
Adopt a fixed answer shape for scenario questions: identify the issue, state the principle that applies, apply it to the specific facts, then give a recommendation with a consequence. Keep the scenario restatement to one clause and spend the remaining words on application. Practise under timed conditions until the shape is automatic.
The candidate confuses the roles of internal audit, the audit committee, external audit and management in assurance questions, attributing control design and risk ownership to auditors or expecting internal audit to implement controls.
These roles are learned as a list of names without their distinct accountability relationships, and the independence principle that separates assurance from execution is not applied consistently.
What to do instead
Memorise the accountability line: management owns and designs controls and owns risk; internal audit provides independent assurance on control effectiveness and reports functionally to the audit committee; external audit opines on financial statements and may rely on internal audit work but does not substitute for it. For any assurance question, state who is accountable, who provides assurance, and to whom that assurance is reported.