CPA ISC — U.S. - Information Systems and Controls Exam Blueprint

Last revised: June 25, 2026

Practical exam blueprint for AICPA CPA ISC candidates reviewing information systems, controls, security, privacy, and SOC-related readiness.

How to Use This Exam Blueprint

This checklist is a practical study map for candidates preparing for the AICPA U.S. CPA ISC - Information Systems and Controls, exam code CPA ISC. It is not a substitute for the official AICPA blueprint, and it does not assign official weights or scoring rules. Use it to check whether you can apply information systems and controls concepts in exam-style scenarios.

For each area, ask:

Can I identify the relevant risk?
Can I choose the appropriate control or evidence?
Can I distinguish preventive, detective, and corrective responses?
Can I apply the concept to a CPA-facing scenario, not just define it?
Can I spot what management, the auditor, or the service auditor should do next?

Topic-Area Readiness Table

Readiness area	What to review	You are ready when you can…
Information systems environment	IT architecture, applications, databases, interfaces, cloud/service providers, business processes	Trace how data moves through a system and identify where errors, fraud, downtime, or unauthorized access could occur
IT governance and risk	Governance structures, policies, roles, risk assessment, third-party risk, oversight	Match business risks to IT controls and explain who owns, monitors, or tests them
Internal control concepts	Control objectives, control activities, evidence, segregation of duties, control deficiencies	Identify whether a control is preventive, detective, corrective, manual, automated, or IT-dependent
Access and identity management	Authentication, authorization, privileged access, access reviews, joiner-mover-leaver processes	Evaluate whether access is properly granted, reviewed, modified, and removed
Change management	Development, testing, approvals, migration, emergency changes, version control	Spot missing approvals, weak testing, developer access to production, and undocumented changes
IT operations	Job processing, backups, monitoring, incident logging, service management, capacity, batch controls	Determine whether operations controls support complete, accurate, authorized, and timely processing
Security	Threats, vulnerabilities, network security, malware, encryption, logging, monitoring	Recommend controls that reduce unauthorized access, data loss, and system compromise
Confidentiality and privacy	Data classification, retention, disposal, consent, privacy commitments, restricted information	Distinguish confidentiality from privacy and select controls for sensitive data handling
Availability and resilience	Backup, recovery, business continuity, disaster recovery, redundancy, incident response	Compare recovery strategies and recognize weak continuity planning
Processing integrity	Completeness, accuracy, validity, authorization, error handling, reconciliations	Identify controls that prevent or detect incomplete, inaccurate, duplicate, or unauthorized processing
Data management	Master data, transaction data, data quality, databases, interfaces, reports, analytics	Evaluate whether data is complete, accurate, protected, and reliable for decision-making or reporting
SOC-related concepts	Service organizations, user entities, complementary controls, system descriptions, control objectives or criteria	Interpret SOC-related scenarios and determine what report elements or responsibilities matter
CPA judgment and professional skepticism	Evidence quality, exceptions, management representations, documentation, ethics	Avoid accepting vague assurances when stronger evidence or follow-up is needed

Core “Can You Do This?” Checklist

Use this section as a self-test. If you cannot confidently check an item, add it to your final review list.

Systems, Data Flow, and Business Process Understanding

Explain the difference between an application, database, operating system, network, and interface.
Trace a transaction from initiation to processing, storage, reporting, and archival.
Identify where manual inputs, automated calculations, interfaces, and reports create control risk.
Distinguish source data, master data, transaction data, metadata, and report output.
Recognize how system configuration can affect financial reporting, operations, compliance, or service commitments.
Identify risks introduced by third-party platforms, outsourced processing, and cloud-hosted applications.
Explain why a system-generated report is only reliable if its source data, logic, and access controls are reliable.

IT Governance and Risk Management

Match common IT risks to governance responses such as policies, monitoring, risk assessments, and accountability.
Identify when board or senior management oversight is needed.
Distinguish risk acceptance, mitigation, transfer, and avoidance.
Recognize weak governance signals: outdated policies, unclear ownership, no risk ranking, no follow-up, or no exception reporting.
Explain why cybersecurity risk, privacy risk, vendor risk, and operational resilience risk are business risks, not only technical issues.
Identify how management should document risk assessment conclusions.
Determine whether control design addresses the stated risk.

Internal Control and Evidence

Skill	Can you apply it?
Control objective identification	Can you state what the control is intended to prevent or detect?
Control design evaluation	Can you tell whether the control, if performed as described, would address the risk?
Control implementation evidence	Can you identify evidence that the control was placed in operation?
Operating effectiveness evidence	Can you identify evidence that the control operated consistently over time?
Exception evaluation	Can you decide whether an exception is isolated, recurring, or indicates a broader deficiency?
Control dependency	Can you identify when a manual control depends on system-generated data or automated logic?

Be ready to classify controls:

Control type	Exam-style cue
Preventive	Stops an error or unauthorized action before it occurs
Detective	Finds an error, exception, or unauthorized action after it occurs
Corrective	Fixes the condition and helps prevent recurrence
Manual	Performed by a person using judgment or procedure
Automated	Performed by system logic or configuration
IT-dependent manual	Manual review that relies on system reports, alerts, or calculations
Entity-level	Operates at a broad governance or oversight level
Process-level	Operates within a specific transaction or business process

Information Systems and Data Management Checklist

System Components and Architecture

Review whether you can explain the role of each component in a business information system.

Component	Readiness prompt
Application	What business process does it support, and what key controls are embedded in it?
Database	Who can change data, schemas, tables, or stored procedures?
Interface	What ensures data passed between systems is complete, accurate, and timely?
Operating system	Who has administrative access, and how is it monitored?
Network	What controls protect connectivity, segmentation, and transmission?
Cloud or hosted service	What responsibilities remain with the user entity?
Reporting layer	How are report logic, parameters, and access controlled?

Data Quality and Reliability

Identify completeness risks: missing records, failed interfaces, incomplete batches, excluded populations.
Identify accuracy risks: incorrect fields, wrong calculations, stale master data, mapping errors.
Identify validity risks: unauthorized transactions, fake vendors, invalid customers, invalid users.
Identify timeliness risks: delayed processing, stale reports, late reconciliations.
Identify integrity risks: unauthorized edits, duplicate records, corrupted files, overwritten data.
Determine whether reconciliation, validation, exception reporting, or independent review is the best control.

Reports and Data Used as Evidence

For any system-generated report, ask:

Who can create, modify, or delete the report logic?
What data source feeds the report?
Are report parameters complete and appropriate?
Is the report reconciled to an independent source?
Is access to run or alter the report restricted?
Is there evidence that the reviewer actually reviewed the report?

Interfaces and Batch Processing

Risk	Control to recognize
Interface file not transmitted	Transmission logs, error alerts, job monitoring
File transmitted twice	Sequence numbers, duplicate checks, batch totals
File partially processed	Control totals, record counts, reconciliation
Data mapped incorrectly	Interface mapping review, change approval, testing
Errors ignored	Exception reports, escalation, resolution tracking
Unauthorized file alteration	Access restrictions, encryption, hash totals, audit logs

Security, Confidentiality, and Privacy Checklist

Security Foundations

Distinguish threat, vulnerability, likelihood, impact, and risk.
Identify common threats: phishing, malware, ransomware, credential theft, insider misuse, denial-of-service, data exfiltration.
Match security controls to risk: firewalls, endpoint protection, encryption, logging, monitoring, patching, network segmentation, security awareness.
Explain why security controls need monitoring and incident response, not just written policy.
Recognize weak security posture cues: shared accounts, unreviewed logs, unsupported systems, no patch process, no incident plan.

Access Management

Topic	Readiness check
Authentication	Can you identify how the user proves identity?
Authorization	Can you identify what the user is allowed to do?
Provisioning	Can you evaluate whether access approval is appropriate before access is granted?
Deprovisioning	Can you identify the risk when terminated users remain active?
Privileged access	Can you explain why admin accounts require tighter controls and monitoring?
Periodic review	Can you identify whether reviewers have enough information to detect inappropriate access?
Segregation of duties	Can you spot conflicting access combinations?
Service accounts	Can you identify why passwords, ownership, and monitoring matter?

Access Scenario Cues

Scenario cue	Likely issue
New employee receives access based only on a verbal request	Missing documented approval
Transferred employee keeps old department access	Weak mover process and excessive access
Terminated contractor account remains active	Failed deprovisioning
Developers can migrate code directly to production	Change management and segregation issue
Administrators use shared accounts	Accountability and logging issue
Access review lists only usernames, not roles or permissions	Ineffective review evidence
Privileged activity logs are collected but never reviewed	Control may not operate effectively

Confidentiality vs. Privacy

Concept	Focus	Exam cue
Confidentiality	Protecting information designated as confidential	Customer lists, pricing, trade secrets, restricted contracts, sensitive business information
Privacy	Collection, use, retention, disclosure, and disposal of personal information	Personal data, consent, notice, purpose limitation, individual rights, data retention

Be able to select controls for both:

Data classification.
Access restrictions.
Encryption in storage or transmission, when appropriate.
Retention and disposal procedures.
Monitoring for unauthorized access or disclosure.
Vendor and third-party data handling requirements.
Incident response and notification escalation procedures, without assuming specific legal deadlines unless provided in the question.

Availability, Continuity, and Incident Response

Term	What to know for readiness
Backup	Copy of data or systems for restoration
Disaster recovery	Technology recovery after a disruptive event
Business continuity	Broader continuation of critical business operations
Incident response	Identification, containment, eradication, recovery, and post-incident improvement
Redundancy	Duplicate components or services that reduce single points of failure
Recovery testing	Evidence that recovery procedures work, not just that they are documented

Common decision prompts:

If the issue is loss of data, what backup and restoration controls matter?
If the issue is prolonged outage, what recovery strategy matters?
If the issue is active compromise, what containment and escalation steps matter?
If the plan has never been tested, what evidence is missing?
If backups exist but cannot be restored, what control failed?

Change Management Checklist

Standard Change Process

Be ready to evaluate the full lifecycle:

Change request.
Business justification.
Risk assessment and prioritization.
Approval by appropriate owner.
Development in a nonproduction environment.
Testing, including user acceptance when relevant.
Approval to migrate.
Migration by an authorized person or controlled tool.
Post-implementation review.
Documentation and audit trail.

Change Management Red Flags

Developers have unrestricted production access.
Changes are moved to production without approval.
Testing is performed by the same person who developed the change, with no independent review.
Emergency changes are not reviewed after implementation.
Change logs do not identify who approved, tested, or migrated the change.
Configuration changes are treated as informal maintenance.
Report logic changes bypass change control.
Security patches are not tracked, prioritized, or monitored.
Rollback plans are missing for significant changes.

Change Scenario Judgment

If the question says…	Think about…
“Emergency fix was applied immediately”	Was there later approval, documentation, and review?
“Programmer corrected production data”	Was access authorized, logged, reviewed, and restricted?
“User requested a report change”	Was report logic tested and approved before use?
“Vendor updated the application”	Did management evaluate impact and evidence from the service provider?
“Patch was deferred”	Was the risk assessed, documented, and mitigated?

IT Operations Checklist

Operations Controls

Job scheduling and monitoring.
Batch processing controls.
Backup completion and restoration testing.
Error handling and exception resolution.
Capacity and performance monitoring.
Incident and problem management.
Physical and environmental controls, where relevant.
Media handling and secure disposal.
Logging and log review.
Service-level monitoring.

Batch and Processing Integrity Controls

Control	Purpose
Record counts	Detect missing or extra records
Control totals	Detect incomplete or inaccurate processing
Hash totals	Detect data alteration in nonfinancial fields
Sequence checks	Detect missing or duplicate items
Edit checks	Detect invalid, incomplete, or unreasonable data
Reasonableness checks	Detect unusual values requiring review
Exception reports	Identify transactions needing follow-up
Reconciliations	Compare processed data to independent records

Processing Integrity Readiness

Identify whether a control addresses completeness, accuracy, validity, authorization, or timeliness.
Determine whether an exception report is actually reviewed and resolved.
Recognize that generating an exception report is not enough if no one follows up.
Evaluate whether reconciliations are independent, timely, and documented.
Identify when automated calculations require change management and access controls.
Explain why interface controls matter when data moves between systems.

The CPA ISC exam may test your ability to reason through service organization and system controls concepts. Focus on responsibilities, report use, evidence, and control dependencies rather than memorizing isolated terms.

Service Organization Concepts

Identify the service organization, user entity, user auditor, and service auditor in a scenario.
Explain why user entities need to understand controls at service organizations.
Identify complementary user entity controls that the user entity must operate.
Identify complementary subservice organization controls when another provider supports the service.
Determine whether a report covers the relevant system, period, services, and control areas.
Recognize when a report does not address the user entity’s specific risk.
Distinguish management’s responsibilities from the service auditor’s responsibilities.

SOC Report Interpretation Prompts

Report element or cue	Readiness question
System description	Does it describe the relevant services, boundaries, components, and controls?
Control testing	Were controls tested for the relevant period or point in time described in the question?
Exceptions	Do exceptions affect the user entity’s reliance or require follow-up?
Complementary controls	Is the user entity doing its part?
Subservice organization	Is the subservice provider included, carved out, or otherwise addressed?
Criteria or control objectives	Do they align with the user’s risk and purpose?
Restricted use language	Who is an appropriate user of the report?

SOC Scenario Cues

Scenario	What to decide
A company outsources payroll processing	What controls remain at the company, and what evidence is needed from the provider?
A vendor provides a SOC report covering a different system	Whether the report is relevant to the service being used
A report identifies repeated access control exceptions	Whether management needs additional procedures, remediation, or compensating controls
The user entity did not perform required complementary controls	Whether reliance on the provider’s controls is weakened
A subservice provider hosts critical infrastructure	Whether the subservice provider’s controls are included or require separate evaluation
The report period does not cover the period of reliance	Whether bridge letters or additional evidence may be needed, depending on the scenario

Trust Services and Control Criteria Readiness

Be prepared to reason through commonly tested trust-services-style categories and control objectives. Do not study them as mere vocabulary; connect each category to risks, controls, and evidence.

Area	Practical focus	Example control evidence
Security	Protection against unauthorized access, use, or modification	Access listings, firewall rules, monitoring logs, incident tickets
Availability	System operation and accessibility as committed or needed	Uptime reports, backup logs, recovery test results, incident reports
Processing integrity	Complete, valid, accurate, timely, and authorized processing	Reconciliations, edit checks, batch totals, exception resolution
Confidentiality	Protection of information designated as confidential	Data classification, encryption settings, access reviews, disposal logs
Privacy	Personal information collection, use, retention, disclosure, and disposal	Privacy notices, consent records, retention schedules, data subject request logs

Control Mapping Practice

For each scenario, practice mapping the risk to the control area:

Scenario cue	Likely focus
Customer data is visible to unauthorized employees	Security and confidentiality
System outage prevents customers from submitting transactions	Availability
Interface drops transactions without alerting operations	Processing integrity
Personal information is retained beyond policy	Privacy
Confidential contracts are stored in unrestricted folders	Confidentiality and security
Duplicate transactions are processed without detection	Processing integrity
Backup restoration has never been tested	Availability

Third-Party and Vendor Risk Checklist

Identify when a third party processes, stores, transmits, or can access sensitive data.
Determine whether vendor risk assessment should occur before onboarding.
Recognize the need for ongoing monitoring, not only initial due diligence.
Identify contract provisions or service commitments that may affect controls.
Evaluate whether incident reporting, right-to-audit, confidentiality, data retention, and subcontractor terms matter in the scenario.
Understand that outsourcing a process does not eliminate management’s responsibility for risk oversight.
Identify when a service provider’s SOC report, certifications, or other evidence may be relevant but insufficient by itself.

Common Weak Areas and Traps

Trap	Why candidates miss it	Better exam approach
Confusing confidentiality and privacy	Both involve sensitive information	Ask whether the issue is confidential business information or personal information lifecycle obligations
Treating policy as a control by itself	A policy may not be implemented or monitored	Look for evidence of performance, review, and follow-up
Accepting logs without review	Logs are data, not automatically a control	Ask who reviews logs, how often, and what happens to exceptions
Ignoring complementary user entity controls	The provider’s controls may assume the user entity performs certain controls	Identify what the user entity must do
Overlooking privileged access	Admins can bypass ordinary controls	Look for approval, restriction, logging, and monitoring
Assuming backups equal recoverability	Backups may fail or be incomplete	Look for restoration testing and recovery objectives
Missing IT-dependent manual controls	A human review may depend on system data	Test both the review and the report/data reliability
Focusing only on design	A well-designed control may not operate	Look for evidence of operation over the relevant period
Ignoring change management for reports	Report logic changes can affect evidence	Ask whether report changes are approved, tested, and restricted
Treating cloud vendors as fully responsible	Shared responsibility often remains	Identify management’s retained responsibilities
Failing to follow exception implications	One exception may signal a broader issue	Evaluate severity, frequency, cause, and remediation
Choosing the most technical answer	CPA scenarios often test governance and control judgment	Match the answer to the risk and responsibility in the scenario

Scenario Decision-Point Checks

Access Management Scenario

Ask these questions in order:

Was access requested by an authorized person?
Was access approved before being granted?
Was the access appropriate for the user’s job responsibilities?
Was privileged access separately controlled?
Was access removed or changed when the user’s role changed?
Was access periodically reviewed by someone with sufficient knowledge?
Were exceptions documented, resolved, and followed up?

Change Management Scenario

Was the change authorized?
Was it tested outside production?
Was testing evidence retained?
Was migration to production restricted?
Were emergency changes reviewed after implementation?
Were users, reports, interfaces, and downstream controls affected?
Was the change documented in a way that supports later review?

SOC Report Scenario

Is the report for the correct service and system?
Does the covered period or point in time fit the user’s need?
Are relevant control areas included?
Are subservice organizations addressed?
Are complementary user entity controls identified?
Did the user entity perform those complementary controls?
Do exceptions require additional procedures or remediation?

Incident Scenario

What happened: outage, data breach, malware, unauthorized access, or processing error?
Was the incident detected promptly?
Was it escalated to the correct personnel?
Was containment performed?
Was evidence preserved?
Were affected systems restored securely?
Was root cause analyzed?
Were controls improved after the incident?

Artifact and Evidence Checklist

Be ready to evaluate whether evidence is relevant, reliable, and sufficient for the scenario.

Artifact	What it can support	What to question
Access listing	Users and roles at a point in time	Is it complete, current, and from the authoritative system?
Access approval ticket	Authorization before access was granted	Was approval appropriate and timely?
Termination report	Users who should be removed	Was it reconciled to active accounts?
Change ticket	Approval, testing, migration, documentation	Does it show who did what and when?
Test results	Evidence that change functioned as intended	Were tests complete and reviewed?
System log	Activity or events	Was the log protected and reviewed?
Exception report	Items requiring follow-up	Were exceptions resolved?
Reconciliation	Agreement between sources	Was it independent, timely, and documented?
Backup log	Backup completion	Was restoration tested?
Incident ticket	Response activities	Was root cause and remediation documented?
Vendor report	Third-party control evidence	Does it cover the relevant service, period, and risks?
Policy	Expected procedure or requirement	Is there evidence the policy was implemented?

Applied Mini-Scenarios

Use these to test whether you can move from facts to conclusion.

Scenario 1: Access Review

A manager reviews a quarterly access listing but the listing contains only employee names, not roles or permissions.

Can you identify the issue?

The review may not be effective because the manager cannot determine whether access is appropriate.
The evidence may show review occurred but not that it was meaningful.
Better evidence would include roles, permissions, changes, privileged access, and reviewer sign-off.

Scenario 2: Emergency Change

A critical production issue is fixed immediately by a developer. The change is not documented until several weeks later.

Can you identify the control concern?

Emergency changes may be permitted in urgent situations, but they still need timely documentation and retrospective approval.
Developer production access increases risk and should be restricted, logged, and reviewed.
Delayed documentation weakens evidence of control operation.

Scenario 3: Vendor SOC Report

A vendor provides a SOC report, but it covers a different product than the one used by the company.

Can you identify the problem?

The report may not provide relevant evidence for the service used.
Management may need a report for the correct system or alternative procedures.
The user entity still needs to evaluate complementary controls and exceptions.

Scenario 4: Backup Program

Daily backups are configured, but the company has never performed a restoration test.

Can you identify the weakness?

Backup completion does not prove recoverability.
Availability and continuity depend on tested restoration procedures.
Management lacks evidence that recovery would work during an incident.

Scenario 5: Interface Processing

A nightly interface sends sales transactions to the general ledger. Failed transmissions are logged, but no one reviews the log.

Can you identify the control gap?

Logging alone is not sufficient if exceptions are not reviewed and resolved.
Completeness and timeliness of processing may be at risk.
Evidence should show monitoring, escalation, and correction.

Final-Week Review Checklist

High-Priority Review

Re-read your notes on access management, privileged access, and segregation of duties.
Review change management scenarios, especially emergency changes and production access.
Practice identifying control objectives from short fact patterns.
Review SOC report parties, responsibilities, complementary controls, exceptions, and report relevance.
Review confidentiality, privacy, availability, security, and processing integrity distinctions.
Practice data flow questions involving interfaces, reports, reconciliations, and exception handling.
Review vendor risk and outsourced service scenarios.
Revisit weak questions where you chose a technically plausible answer that did not address the control risk.

Evidence and Judgment Drill

For each practice question you miss, write one sentence for each:

Prompt	Your correction
What was the risk?	Identify the specific threat, error, or failure.
What control addressed it?	Name the control and its purpose.
What evidence proves operation?	Identify the document, log, ticket, review, or report.
What was the trap?	State why the wrong answer was tempting.

Last Two Days

Do not try to memorize every technical term in isolation.
Focus on scenario recognition and control reasoning.
Review definitions only where they affect decision-making.
Practice explaining why an answer is wrong, not only why the right answer is right.
Refresh SOC-related vocabulary and user entity responsibilities.
Review common red flags: shared accounts, no review, no documentation, no testing, wrong report period, missing complementary controls.
Sleep and pace yourself; ISC questions reward careful reading.

Practical Next Step

Use this checklist to mark each topic as ready, needs review, or needs practice. Then work targeted CPA ISC practice questions for the areas you marked weakest, especially access management, change management, SOC-related judgment, evidence quality, and processing integrity scenarios.

Study Plan

Scenario Guide