CISA common mistakes
CISA · Understand the traps and how to avoid them.
On a stem phrased 'What should the IS auditor do FIRST/NEXT?', selects a management action (e.g., 'implement multifactor authentication', 'revise the security policy') instead of an audit action (gather evidence, corroborate the finding with the auditee, report to the audit committee, follow up on remediation).
Many candidates come from operations, security, or consulting roles where the rewarded behaviour is to fix the problem; the reflex to solve rather than to assure carries over into the exam.
What to do instead
For every 'auditor should' stem, first classify each option as audit action vs management action, and eliminate all management actions. The ISACA-consistent answer is almost always: obtain sufficient evidence, validate/communicate the finding, then follow up - never the auditor executing the fix.
Treats a management statement or a verbal assurance ('the CIO confirmed the policy is enforced') as adequate evidence to close an audit issue, rather than seeking independent corroboration such as configuration exports, sample testing, or system-generated logs.
Deference to seniority and the desire to avoid conflict with the auditee; also a misreading of 'efficiency' as 'accept the quickest answer.'
What to do instead
Apply the evidence test to each option: sufficient, competent, relevant, and from a source independent of the control owner. An unverified management assertion is weak evidence on its own; the defensible answer combines it with independent corroboration.
Assigns strategic/oversight decisions to the wrong body - e.g., selecting 'the IT steering committee defines the enterprise IT strategy', 'the CIO approves the IT risk appetite', or 'the IT department sets IT policy' for questions about governance.
Strategy, policy, steering committees, and the CIO all appear in the same chapter of the review material, so candidates pick whichever authority sounds most IT-specific instead of the correct level of accountability.
What to do instead
Build a decision-to-body map before the exam: board/audit committee = oversight, risk appetite, IT strategy alignment with business; IT steering committee = prioritisation and resource allocation across competing initiatives; CIO/IT management = execution and standards. Test each option against 'who is accountable at this level?'
On outsourcing and third-party questions, selects answers that say the organisation has 'transferred the risk to the service provider' or can 'rely on the vendor's certification', instead of answers about retained accountability, right-to-audit clauses, and ongoing vendor monitoring.
Commercial contract intuition says signing an SLA moves the problem to the vendor; it feels like a complete, business-like answer.
What to do instead
Memorise the principle that accountability and risk ownership are never outsourced. Prefer options containing contract clauses plus independent monitoring/right to audit over options containing transfer, certification-only, or vendor self-reporting.
Selects 'the project manager conducts the post-implementation review' or 'the project team performs the benefits realisation assessment' as the correct answer for post-implementation review questions.
The project manager visibly owns go-live and closeout, so continuity of ownership feels natural, and independence is not at the front of mind under time pressure.
What to do instead
Apply an independence screen to any review/assurance option: if the reviewer was responsible for designing, building, or running the system, eliminate it. The correct answer assigns the review to internal audit, an independent QA function, or business management outside the project team.
Accepts user acceptance testing sign-off as proof that the new system is adequately controlled, rather than requiring separate security/control testing and audit or QA involvement; likewise confuses UAT scope (business functionality) with integration, stress, or control testing.
Go-live narratives emphasise UAT as the final gate, so it is remembered as the universal approval step.
What to do instead
Attach a scope label to every test type in the material: UAT = business fitness for purpose by users; integration, stress/volume, and security testing = technical; control testing and audit review = assurance on controls. Rule out any option that uses UAT to answer a control or security objective.
Reverses RTO and RPO, e.g., answering 'RPO of four hours' for a stem describing how long a business process may be unavailable, or designing recovery plans against the wrong metric.
The two acronyms differ by one letter and the definitions are read once and never contrasted.
What to do instead
Fix the distinction verbally: RTO = how long the business can survive the outage (time to restore service); RPO = how much data the business can afford to lose (age of last recoverable copy, drives backup frequency). Rewrite the stem's number into one of those two sentences before choosing.
Treats backup restoration as the answer to business continuity questions, selecting 'restore from the most recent backup' when the stem asks how critical business functions will be maintained during an extended outage.
Backup and recovery are the most familiar part of resilience, so they get used as a generic answer for any disruption scenario.
What to do instead
Separate the layers explicitly: backup/restore = data recoverability; disaster recovery = restoring IT infrastructure and services; business continuity = keeping or resuming business processes (manual workarounds, alternate sites, staff, suppliers). Match the answer's layer to the object in the stem.
Confuses the cryptographic primitives - proposing encryption to prove integrity or nonrepudiation, hashing to provide confidentiality, or a hash alone as a nonrepudiation mechanism - when matching a control to a stated security objective.
Encryption, hashing, and digital signatures are learned as one 'cryptography' block; their distinct guarantees blur under exam pressure.
What to do instead
Memorise a one-line property map: symmetric encryption = confidentiality; hashing = integrity (detects change, no secrecy, no identity); asymmetric encryption = key exchange/confidentiality; digital signature (hash + sender's private key) = integrity + authentication + nonrepudiation. Match the objective in the stem to the property, not to the technology name.
Selects a detective or corrective control (IDS alerts, log review, exception reporting, antivirus quarantine) when the stem asks how to prevent an event, or labels a preventive control as detective.
Real-world answers are often layered ('we would detect it and then respond'), and candidates reward any control that addresses the described scenario.
What to do instead
Before reading options, write P/D/C next to the stem's requirement: prevent = stop before occurrence (access restrictions, encryption, firewalls, segregation of duties, input validation); detect = identify after occurrence (IDS, log review, reconciliation); correct = restore after occurrence (backups, patches, incident response). Then eliminate any option whose class does not match the requirement.