Systems Auditor Examination common mistakes
Systems Auditor Examination · Understand the traps and how to avoid them.
Answering control-design questions with the control an engineer would implement (firewall, encryption, patch) instead of the auditor's activity (obtain evidence, test the control, report the exception).
Candidates with hands-on IT or security backgrounds read the stem as 'what should be done about this risk' rather than 'what is the IS auditor's next step', so they pick the technically strongest remedy instead of the assurance action.
What to do instead
Before reading the options, restate the stem as 'As the IS auditor, my next action is...'. Eliminate any option that is a management action (implementing, configuring, approving, accepting risk) unless the question explicitly asks who owns the response. Practise classifying each option as audit activity, management activity, or technical activity.
Treating 'audit risk' as the risk that the organisation suffers a loss, or confusing it with business risk, inherent risk, or the risk that the auditor will be sued.
The word 'risk' is overloaded; candidates carry over enterprise risk management usage into audit terminology and then misapply the detection-risk/inherent-risk/control-risk formula.
What to do instead
Memorise the audit risk model as a definition, not a formula to compute: audit risk is the risk that the auditor gives an inappropriate opinion on materially misstated information. Drill the three components with one-line definitions and one example each, and note that the auditor controls detection risk by the nature, timing, and extent of testing.
Choosing 'report the finding to the audit committee immediately' as the default escalation for every issue, skipping the normal sequence of discussing with the auditee and obtaining a management response first.
Candidates learn that independence requires reporting to the board and over-apply it, ignoring that escalation is a last resort triggered by materiality, fraud, or management refusal to act.
What to do instead
Learn the escalation ladder explicitly: discuss with the auditee, agree facts, obtain a written management response with an action plan and date, follow up, and escalate only when the issue is material, involves senior management, or the response is inadequate. Match the option to the stage described in the stem.
Picking the option that says the auditor should 'ensure', 'guarantee', 'be responsible for', or 'approve' an IT outcome when the auditor can only provide reasonable assurance and advise.
Absolute-sounding verbs look like strong, decisive answers, and non-native speakers may not register that 'ensure' and 'guarantee' exceed the auditor's role.
What to do instead
Flag absolute verbs as red flags. The auditor provides reasonable, not absolute, assurance; recommends rather than mandates; and reviews rather than approves. When two options are otherwise similar, choose the one with the more limited, evidence-based verb.
Assuming that because the IT function reports to the CIO, IT governance is adequate, and selecting 'the CIO should approve the IT strategy' style answers.
Candidates conflate IT management with IT governance and forget that governance sits with the board and executive management, with oversight separated from execution.
What to do instead
Anchor on the split: the board governs and sets direction, executive management executes, and the IS auditor provides independent assurance on both. Any answer that places strategy approval, risk appetite setting, or policy ownership solely inside IT management should be treated as a control weakness, not a solution.
Treating a documented policy as evidence that the control operates, and concluding the control is effective because a procedure exists.
Design and operating effectiveness are taught together, and candidates collapse them; documents are easy to obtain, so they become the whole test.
What to do instead
For every control, ask two separate questions: is it designed appropriately (documented, owned, addresses the risk), and did it operate throughout the period (evidence of execution, samples, exception logs)? If the question asks about effectiveness, choose the option that involves testing operation, not reading the policy.
Answering SDLC questions with the phase where a control is most convenient rather than the phase where the activity belongs, for example placing user acceptance testing after go-live or security requirements at the coding stage.
Real projects overlap phases and candidates remember their own organisation's sequence rather than the control objective attached to each phase.
What to do instead
Build a phase-to-control map: feasibility and business case (benefit, risk), requirements (security and control requirements, acceptance criteria), design, build, test (including UAT and security testing), implementation (conversion, cutover, sign-off), and post-implementation review. For each control, ask which phase produces the evidence it depends on.
Endorsing parallel running or a phased cutover as the universally safest approach without weighing cost, duration, and reconciliation effort, or conversely recommending big-bang conversion because it is fastest.
Candidates memorise 'parallel run is safest' as a slogan and ignore that the question is about the best option given the risk profile and constraints stated in the stem.
What to do instead
Compare the three conversion approaches on risk, cost, and duration, then select based on the stem's stated criticality and constraints. Note that parallel running requires dual data entry and reconciliation, and that its main benefit is a fallback, not speed.
Answering business continuity questions with backup and disaster recovery answers, such as 'restore from tape' or 'switch to the hot site', when the question concerns continuity of business processes.
BCP and DRP are studied together and both involve recovery, so candidates substitute the IT recovery action for the business-level plan.
What to do instead
Separate the artefacts: BIA identifies critical processes and recovery objectives (RTO/RPO); BCP keeps the business operating; DRP restores IT infrastructure. If the stem mentions a business function, customers, or manual workarounds, the answer belongs to BCP. Check that any proposed recovery capability actually meets the stated RTO/RPO.
Choosing the strongest preventive control (encryption, MFA, least privilege) when the scenario asks for a detective control, or vice versa, and misclassifying monitoring as prevention.
Candidates rank controls by perceived strength rather than by category, and many controls (logging, IDS, review of access rights) are described in language that sounds protective.
What to do instead
Classify every option by type before choosing: preventive, detective, corrective, deterrent, compensating. Then read what the stem asks for. Remember that log review, IDS alerts, and reconciliation are detective; access restriction and encryption are preventive; restoration and patching after an incident are corrective.