CPA ISC Master Guide 2026

What the ISC section is

Information Systems and Controls (ISC) is one of the three Discipline sections in the Uniform CPA Examination. Candidates pass AUD, FAR and REG Core sections plus one Discipline: ISC, BAR or TCP. ISC focuses on the information systems, data, security and SOC knowledge a newly licensed CPA may use in assurance or advisory work.

The Discipline choice determines which specialized blueprint you study. It does not create a separate license or replace jurisdiction education and experience requirements. State boards set eligibility and licensing rules, while AICPA and NASBA administer the examination.

Exam format and timing

ISC lasts four hours and has five testlets. The 2026 structure is two MCQ testlets of 41 questions each, followed by three TBS testlets containing 1, 3 and 2 simulations. That is 82 multiple-choice questions and 6 task-based simulations. The number of questions does not indicate that every item contributes equally to the score.

The section tests recall and understanding as well as application. A candidate may need to identify a control objective, interpret a system description, analyze data handling or determine what a SOC report communicates. Practise both question formats and learn to apply concepts to a described organization.

What the ISC blueprint covers

The largest portion of ISC is split between information systems/data and security/confidentiality/privacy. SOC engagement considerations are a distinct third Area. The official blueprint organizes each Area into groups, topics and representative tasks; its task list is not an exhaustive promise of exam items.

Information systems and data management

This Area covers IT architecture and cloud service models, enterprise and accounting information systems, business processes, system availability, IT change management and processing integrity. Data topics include extraction, storage, usage across a lifecycle, SQL queries and combining information from different sources.

Candidates need to connect a system component to the risk it creates and the control that addresses it. For example, a change-management question may ask how unauthorized code could affect processing or availability. A data question may require considering whether source information is complete and accurate before relying on an analysis.

Security, confidentiality and privacy

This Area includes threats and attacks, security controls, confidentiality safeguards, privacy requirements and incident response. It expects candidates to recognize relevant standards, regulations and frameworks and apply them to a stated situation. Memorizing framework names is not enough when a task asks whether a control is designed appropriately or whether evidence supports its operation.

Separate the concepts. Security concerns protection against unauthorized access or disruption. Confidentiality concerns information designated for restricted access. Privacy concerns appropriate handling of personal information. In practice these topics overlap, but questions may focus on a particular objective, threat or requirement.

SOC engagement considerations

The SOC Area addresses report purpose, form, content, management assertions, intended users, criteria, engagement planning and reporting. The blueprint includes SOC 1, SOC 2, SOC 3 and SOC for Cybersecurity concepts, along with complementary user-entity and subservice-organization controls.

A key study task is distinguishing what a report is designed to communicate and who can use it. A SOC report is not a general certification that an organization has no risk. Understand the system description, criteria, period and intended use before drawing conclusions from the report.

Scoring and passing

AICPA reports CPA section scores on a 0-99 scaled scale, and 75 is the passing score. A 75 is not a raw percentage correct. ISC weights MCQ performance at 60 percent and TBS performance at 40 percent. This differs from BAR and TCP, which use a 50/50 split.

A practice-bank percentage does not convert directly to an official scaled score. Use provider results to monitor progress over time, then check whether performance transfers to fresh mixed questions and simulations. Candidates who fail may receive a performance report with relative content-area information; it does not disclose exact missed questions.

Eligibility, application and scheduling

Eligibility is jurisdiction-specific. Boards may differ in education evaluation, application sequencing and documentation. Check the board where you intend to apply and distinguish permission to sit for the exam from eventual licensure. Passing all required sections alone does not satisfy every state license requirement.

Core sections are offered year-round. Discipline sections such as ISC are scheduled in the first month of each calendar quarter: January, April, July and October. Build the study calendar around the target window, the Notice to Schedule validity and appointment availability. Fees vary with jurisdiction and testing route.

The usual process involves an initial application or evaluation, approval to test, section selection, payment and scheduling through the applicable systems. Review current NASBA and board instructions before paying. Allow time for transcripts and eligibility review; an application deadline is not the same as an appointment reservation.

How to prepare for ISC

Begin with the blueprint and a diagnostic across all three Areas. Build a glossary of systems, data, security and SOC concepts you cannot explain. Learn a concept, retrieve it without notes, then apply it to a short scenario. Track the difference between a knowledge gap and an analysis mistake.

Use cases to practise the chain from risk to objective to control to evidence. For a system scenario, identify the process, data involved, possible failure and control that would prevent or detect it. For SOC content, identify the report type and intended users before interpreting a finding.

ISC contains more MCQs than simulations, but simulations still require meaningful preparation and contribute 40 percent of the score. Practise reading requirements first, mapping evidence and completing all response fields. Keep a schedule that revisits earlier topics rather than completing a single pass through the material.

Choosing ISC over BAR or TCP

Compare the blueprints instead of choosing from a perceived difficulty ranking. ISC may suit candidates drawn to information systems, controls and assurance. BAR emphasizes business analysis and reporting; TCP emphasizes tax compliance and planning. Work background can help identify familiar topics, but no job title guarantees an easy section.

Pass rates are group statistics. In 2026, AICPA reported ISC rates of 66.79 percent in Q1 and 67.98 percent in Q2, with a cumulative 67.45 percent through Q2. These figures do not predict an individual result or establish that ISC is easiest for every candidate.

A practical study sequence

First, map the blueprint and choose a realistic sitting window. Next, learn foundational terms and system relationships, then practise applying them. Add mixed question sets after initial coverage and use simulations to work through exhibits. In the final phase, repair recurring gaps, complete timed practice and leave room for review.

Use a log with four fields: topic, what went wrong, corrected reasoning and next review date. A low score is useful only when it changes the next action. If you repeatedly confuse report purpose and intended user, practise comparisons. If you miss data-completeness issues, rehearse source validation before analysis.

Frequently asked decisions

Before committing to ISC, check your jurisdiction’s eligibility steps, compare the official blueprint with your interests and confirm you can prepare before a quarterly window. Choose preparation material that covers the current blueprint, teaches both MCQs and simulations, and provides explanations you can use to correct mistakes.

How the content areas connect

The blueprint Areas are not isolated silos. A business process depends on applications and data. Security, confidentiality and privacy controls protect that process and its information. SOC engagements can examine how a service organization describes the system and whether relevant controls address specified criteria. A case may therefore require candidates to draw on more than one vocabulary group.

When studying an integrated scenario, begin with the entity and the service or process being examined. Identify where information originates, how it moves, who can access it and what can fail. Then ask which control objective addresses the risk and what evidence would support a conclusion. This sequence helps connect abstract technology terms to assurance decisions.

Data quality is one example of the connection. A report can be accurately calculated yet misleading if the source extract omits records or duplicates transactions. Before relying on an analysis, consider completeness, accuracy, transformation and reconciliation to the source. The blueprint includes data extraction, storage and use, so preparation should include the full chain rather than only database definitions.

SOC report interpretation also depends on context. A report has a defined purpose, criteria, system description and intended users. A user entity may have its own complementary controls. Understanding that boundary prevents an overbroad conclusion that a service provider report guarantees every customer process is effective.

Build a system-to-evidence mental model

For unfamiliar technology scenarios, do not start by guessing which product or framework is intended. Describe the business process in ordinary language. Identify the information it creates, the system that stores it, the people or services that can change it, and the output the organization uses. Then identify what could fail and what control evidence would address the risk.

This approach helps with cloud-based systems. Infrastructure, platform and software services describe different layers of responsibility. The exam can ask candidates to understand how a service model affects control boundaries, but the facts in the question determine the responsibility being evaluated. Do not assume that outsourcing removes the entity’s responsibility to understand user access, configuration or data use.

For data-management tasks, trace information from source through extraction and transformation to storage and reporting. Ask whether records are complete, accurate, authorized and reconciled. If data from two systems is combined, consider identifiers, time periods, duplicate records and incompatible definitions. A calculation does not compensate for poor source quality.

For a control case, state the control objective before evaluating the activity. A daily review might detect exceptions; an approval before a change might prevent unauthorized modification. Evidence should show what the control did, when it operated and how exceptions were handled. If evidence is absent, report the limitation rather than infer that an event definitely occurred or did not occur.

A closer application

ISC preparation calls for both conceptual knowledge and careful reading of control scenarios. When a prompt describes a system, identify the asset or process at risk, the control objective, the control activity, and the evidence that the activity operated. A control that exists on paper may not have been performed; a control that was performed may not address the risk described. Keep design and operating effectiveness distinct in your notes. For example, a company requires approval before a vendor is added. The relevant evidence may include the approved vendor request, user permissions, and a change log. A monthly review can detect unauthorized changes after the fact but does not necessarily prevent an initial unauthorized setup. The right answer depends on the objective the question asks you to evaluate. Distractors often name a valid control that addresses a different stage of the process. Build a glossary around relationships, not isolated acronyms: confidentiality, integrity, availability; preventive and detective controls; access provisioning and review; backup and recovery; and risk response. For each term, create a short case and explain what evidence would support the conclusion. Then use mixed questions to practice identifying the relevant concept without seeing the topic heading. A practical readiness check includes explaining why a control fails, choosing evidence that would test it, and distinguishing a policy from proof of operation. Keep your explanations tied to the facts in the scenario. Broad statements such as “more monitoring is needed” do not answer which risk is present or how the proposed procedure addresses it.

Additional decision example

Use a simple risk-to-control chain for unfamiliar case studies. First state the risk, such as unauthorized changes to a financial application. Next identify the control intended to address it, such as restricted access and an approval process for changes. Then determine what evidence would show the control operated: access listings, approval tickets, or change logs. Finally ask whether the evidence covers the relevant period and population. A control description alone does not prove it worked. This chain helps separate preventive from detective activity. An approval before access is granted can prevent an unauthorized account; a periodic access review can detect an account that should have been removed. Both may be useful, but the question may ask which one directly addresses a specific risk. Avoid selecting a control just because its name sounds comprehensive. Tie the choice to the point in the process where the risk occurs.

Applying the guidance

For each new practice case, try to state a concise conclusion in this form: “The control addresses [risk] by [action], and evidence of operation would be [record].” If you cannot fill all three parts, identify which link is missing. A policy may explain the action but not prove it occurred. An access log may show activity but not whether an approval was appropriate. This structure gives a practical check on whether you understand the scenario rather than recognizing a familiar control label.

Worked decision and review

A candidate can practice the risk-control-evidence chain on a simple payroll system. The risk may be that an unauthorized person changes an employee’s bank details. A control could require a second approval for account changes. Evidence might include the change request, approval record, user identity, and system log. The test is not complete if the policy exists but the evidence does not show the review occurred for the sampled changes. Nor does a log alone establish that the reviewer had appropriate authority. Change one fact and explain how the conclusion changes. If the second approval occurs after payroll runs, it may detect a problem but cannot prevent that payment. If the system logs changes but no one reviews the log, the monitoring control may not operate as intended. These variants help distinguish control design from operation and prevention from detection. When you read a case, mark the process stage, risk, control owner, frequency, and evidence. If one is absent, that may be the point of the question. Use a concise explanation that ties each answer to the case instead of naming a general best practice.

Quick review

This chain also provides a useful final review prompt: name the risk, control activity, and evidence for each case you study. If one element cannot be identified, revisit the relevant concept before moving on.