CPA ISC common mistakes
CPA ISC · Understand the traps and how to avoid them.
Answering from the perspective of an IT administrator (what would fix the system) instead of the role named in the stem (external auditor, internal auditor, or management), and ignoring qualifier words like 'first,' 'next,' or 'most likely.'
ISC stems are written as short scenarios and the role/phase is often stated once at the start; candidates read for the technical problem and jump to the end-state remedy, so they pick an option that is correct in substance but wrong in sequence or assigned to the wrong party.
What to do instead
Before evaluating choices, write two words at the top of your scratch notes: the role (auditor vs. management) and the phase (planning/risk assessment, testing, reporting, remediation). Then eliminate any option the auditor would not perform (implementing controls, accepting risk) and any option that presumes a step not yet done.
Treating an ITGC deviation like a substantive-testing exception - concluding that the control 'partially operated' or that the fix is simply to expand the sample size.
Candidates carry over sampling intuition from financial statement audits, where exceptions can be projected and tolerated; ITGCs (change management, access, operations) are designed to operate uniformly, so a deviation raises a question about whether the control operated throughout the period.
What to do instead
For each ITGC exception, ask: did the control operate consistently for the whole period? If no, the control cannot be relied on. Then identify the response - test compensating controls, or fall back to a substantive approach with increased scope - rather than proposing a bigger sample of the same broken control.
Selecting the wrong service organization report: citing a SOC 2 Type 1 as evidence of operating effectiveness over a period, using a SOC 1 to evaluate security/availability, or treating a bridge letter as a substitute for testing controls.
The SOC family shares a name and vendors market them loosely; candidates memorize 'SOC = service organization controls' without anchoring each report to its subject matter and time coverage.
What to do instead
Build a two-axis recall grid and apply it in the stem: subject matter (SOC 1 = controls relevant to user entities' internal control over financial reporting; SOC 2 = trust services criteria; SOC 3 = general-use summary with no detailed tests) crossed with time (Type 1 = as of a point in time, design only; Type 2 = over a period, includes operating effectiveness). A bridge letter only covers the gap after the report period and is not evidence the auditor has tested.
Concluding that automated application controls can be relied on because the system logic is consistent, without first evaluating the general controls (change management, access, IT operations) that protect that logic.
Automation feels inherently reliable, so candidates treat 'the system enforces it' as sufficient evidence and skip the upstream question of whether the configuration could have been changed improperly during the period.
What to do instead
Use the chain: automated application control reliance depends on effective ITGCs over program changes, logical access, and operations. If those are deficient, either test the automated control directly (re-perform the calculation or inspect configuration at multiple points in the period) or treat reliance as unsupported.
Classifying a control by its label rather than its function, then picking a detective control when the stem asks for the best way to stop an error from entering the system (or vice versa), and overlooking that many real controls are a layered mix.
Candidates memorize control names as a flat list and match on keywords; the exam instead tests whether you can map a specific risk to the point in the process where it must be addressed.
What to do instead
For every option, state aloud: does this stop something before it happens (preventive), find it after (detective), or fix it after detection (corrective)? Then re-read the stem's objective - 'prevent unauthorized access,' 'detect errors before processing,' 'recover after an outage' - and keep only options matching that objective.
Using 'privacy' and 'confidentiality' interchangeably, and misassigning the data controller versus the data processor when the scenario involves an outsourced service provider.
Both concepts concern protecting information, so the distinction feels academic; the exam draws the line at the type of data (personal information) and at who determines purpose and means of processing.
What to do instead
Anchor on two tests: (1) Is personal information involved? If yes, privacy obligations attach regardless of whether the entity promised anything. (2) Who decides why and how the data is processed? The party deciding is the controller and bears the primary obligations; the party acting only on documented instructions is the processor. Also note that a published privacy notice is a commitment the entity can be held to, even if a law would not otherwise require it.
Collapsing authentication, authorization, and segregation of duties into a single idea of 'access control,' and answering 'require a stronger password' or 'encrypt the data' for scenarios that are actually about excessive privileges or incompatible duties.
All three live under the access control heading, and password policies are the most familiar example, so they become the default answer even when the scenario describes a user who can both create a vendor and approve payment to it.
What to do instead
Ask what the failure actually is: proving identity (authentication), deciding what an authenticated identity may do (authorization/least privilege), or preventing one person from completing a transaction end to end (segregation of duties). Match the remedy to that failure - role review and privilege restriction, or duty splitting and compensating monitoring, not credential hardening.
Mismatching data controls to the error they catch - offering a check digit for an out-of-range amount, a record count for a transposition error inside a record, or an input edit check for a file that was balanced but posted to the wrong period.
Control names are memorized as a vocabulary list rather than as detectors with specific coverage, and many of them sound interchangeable in a short stem.
What to do instead
For each option, state the exact error it would catch and where it operates: input (before acceptance - field format, range, validity, check digit, completeness of fields), processing (during - control totals, hash totals, record counts, reconciliation, exception reports), output (after - distribution logs, review of report totals). Choose the option whose detection scope matches the error described.
Swapping recovery time objective and recovery point objective, or choosing a hot site for a scenario where cost tolerance is the binding constraint, without noting that backup frequency determines how much data is lost.
Both metrics are measured in time and both appear in business continuity scenarios, so the definitions blur under time pressure; site classifications get treated as tiers of quality rather than trade-offs of cost versus recovery speed.
What to do instead
Fix the direction in memory: recovery time objective = how long the process may be down (drives site type and redundancy); recovery point objective = how much data the entity can afford to lose (drives backup and replication frequency). Then read the stem for which constraint is stated - maximum tolerable outage picks the site, tolerable data loss picks the backup design - and remember mirroring/hot sites cost the most.
Assigning user acceptance testing to the IT development team, allowing developers to promote their own code to production, or treating emergency changes as exempt from approval and documentation.
In practice small IT teams often do all of these, and candidates reason from what they have seen rather than from the control objective of segregating the people who build from the people who authorize and deploy.
What to do instead
Memorize three fixed assignments: users (not IT) own acceptance testing because they own the business requirement; developers never migrate their own code - a separate individual or automated pipeline with logged approval performs the promotion; emergency changes receive after-the-fact approval and documentation by someone independent of the change, and those records are tested like standard changes.