ICAB CL Information Technology common mistakes
ICAB CL Information Technology · Understand the traps and how to avoid them.
When asked to classify a control (preventive, detective, corrective), the candidate labels it by when it happens in a process flow rather than by what the control actually achieves.
Candidates conflate the timeline of an activity with its control objective, so a reconciliation performed after posting gets called 'preventive' because it precedes the next period, or a password policy gets called 'detective' because logs exist.
What to do instead
Before answering, state the control's objective in one sentence ('this stops an error entering the system' / 'this finds an error already present' / 'this fixes an error already found'). Then map to preventive/detective/corrective. Practise with 20 controls and write the objective first, classification second.
Treats general IT controls and application controls as interchangeable, applying an application-level answer (e.g., input validation) where the scenario describes an organisation-wide control (e.g., change management, access provisioning).
Both categories appear in the same scenario narratives and candidates answer the visible symptom rather than the control layer the question targets; exam wording often buries the layer in a subordinate clause.
What to do instead
Build a two-column mental checklist: general controls (access, change, operations, backup, segregation of IT duties) versus application controls (input, processing, output). Underline the noun the question attaches the control to - 'the payroll system' vs 'the IT department' - and answer at that layer.
Answers a risk question by naming a threat ('hacking', 'fire') when the question asks for the risk, or names a risk when asked for a control.
The threat/risk/control chain is not held distinctly in mind under time pressure, and everyday usage blurs the terms, so candidates substitute whichever word comes first.
What to do instead
Use a fixed chain when drafting each answer: asset → threat → vulnerability → likelihood/impact → risk statement → control → residual risk. Write the chain in the margin for the first three risk questions in any practice set until it becomes automatic.
Confuses confidentiality, integrity and availability when identifying which property a given incident or control protects, for example labelling encryption of data at rest as an availability control or labelling backups as an integrity control.
Controls often touch more than one property, so candidates pick the property they associate with the technology rather than the property the scenario says was harmed.
What to do instead
Read the scenario and ask 'what went wrong or what would go wrong?' - unauthorised disclosure (confidentiality), unauthorised or accidental alteration (integrity), or loss of timely access (availability). Answer the property the scenario names, not the one the tool usually supports.
Gives a database or data-management answer that ignores normalisation and referential integrity, e.g., accepting a design that stores a customer's address on every order line, or approving deletion of a parent record with dependent children.
Candidates focus on whether the design 'works' for a sample query and overlook update anomalies and orphan records, which the exam tests through small scenario details.
What to do instead
Test any proposed schema against three questions: will the same fact be stored more than once (update anomaly), can a fact be recorded without its parent (insert anomaly), and what happens on delete (referential integrity). State the anomaly explicitly in the answer to earn the mark.
Describes the steps of a structured methodology (such as a system development life cycle or a risk assessment process) in the wrong order, or omits a stage entirely, when asked to outline the process.
Candidates recall the labels but not the sequence, and under exam pressure they list activities in the order they think of them rather than the order the methodology prescribes.
What to do instead
Memorise one canonical sequence per methodology as a numbered list and rehearse writing it from memory in under a minute. When answering, present the stages as numbered steps so a missing or misplaced stage is visible to both you and the marker.
Writes long narrative answers to 'list' or 'identify' questions and short, unexpanded answers to 'explain' or 'discuss' questions, misallocating marks against the command word.
Candidates answer the content they know rather than the verb asked, and time pressure pushes them toward whichever format feels faster, so they neither gain the easy list marks nor the depth marks.
What to do instead
Circle the command word before writing. For list/identify, give terse bullet points with no explanation. For explain/discuss, use a point-plus-consequence structure ('because X, Y results, which means Z') for each mark available. Check the mark allocation to decide how many points to make.
When asked about assurance or audit evidence, asserts that a control is effective because management says so, or because a policy document exists, without identifying independent testing or corroborating evidence.
Candidates conflate the existence of a control with its operating effectiveness, and accept management representations as sufficient evidence because that is how workplace conversations usually run.
What to do instead
Apply the evidence hierarchy explicitly: inquiry alone is weakest; observation, inspection of records, and re-performance are stronger; independent source evidence beats internally generated evidence. In any assurance answer, name the specific test of operating effectiveness you would perform and over what period.
Ignores segregation of duties when recommending a fix, proposing that a single administrator both create users and review access logs, or that the same team develop and deploy changes to production.
Candidates optimise for simplicity and cost in the proposed solution and do not re-check the recommendation against the conflict-of-interest principle they have just described.
What to do instead
After drafting any process recommendation, run a two-line check: who initiates, who authorises, who records, who custody-holds, who reviews. If one person or team appears twice in incompatible roles, split the duty or add a compensating detective control and say so.
Describes a business continuity or backup arrangement as adequate without specifying recovery objectives, testing frequency, or off-site/immutable copies, treating 'we take backups' as a complete answer.
Backups are familiar and feel like a finished control, so candidates stop at the mechanism and never address recovery time, recovery point, restoration testing, or the difference between backup and continuity planning.
What to do instead
Answer continuity questions against four fixed headings: recovery point objective, recovery time objective, storage location and immutability, and restoration testing frequency with results reviewed. Mention the difference between restoring data (backup) and continuing operations (business continuity plan) whenever the scenario involves prolonged outage.