CPA ISC Quick Review: Information Systems and Controls

Last revised: June 25, 2026

High-yield quick review for U.S. CPA ISC candidates, with key systems, security, control, and practice focus areas.

Quick Review Purpose

This independent Quick Review is for candidates preparing for the AICPA U.S. CPA ISC - Information Systems and Controls exam, code CPA ISC. Use it to refresh high-yield concepts before moving into topic drills, mock exams, and detailed explanations.

The CPA ISC mindset is not “memorize IT vocabulary.” You are expected to connect technology risk, control objectives, system processes, evidence, and reporting implications. In exam-style scenarios, ask:

What risk is the question targeting?
Which control objective matters most?
Is the control preventive, detective, corrective, manual, automated, or IT-dependent?
Is the issue about design, implementation, or operating effectiveness?
What evidence would actually support the conclusion?

This page is independent review support and is not affiliated with the AICPA.

CPA ISC Core Mental Model

    flowchart LR
	    A[Business objective] --> B[Information system]
	    B --> C[Relevant data and processing risks]
	    C --> D[Control objectives]
	    D --> E[General IT controls]
	    D --> F[Application controls]
	    E --> G[Reliable processing and evidence]
	    F --> G
	    G --> H[Assurance, reporting, and decision-making]
	    H --> I[Monitor exceptions and improve controls]
	    I --> C

Think in layers:

Layer	What to Know	Common Exam Angle
Governance	Accountability, risk appetite, policies, monitoring	Who owns risk? Who provides independent assurance?
Risk assessment	Identify, assess, respond, monitor	Inherent vs. residual risk; likelihood vs. impact
General IT controls	Access, change management, operations	Whether automated controls and reports can be relied on
Application controls	Input, processing, output, master data, interfaces	Completeness, accuracy, validity, authorization
Security and privacy	Confidentiality, integrity, availability, privacy	Match risk to the best control
Data management	Data quality, classification, retention, lineage	Whether data is complete, accurate, protected, and usable
SOC reporting	SOC 1, SOC 2, Type 1, Type 2, CUECs	Which report fits the user’s assurance need

High-Yield Governance and Risk Concepts

Governance, Accountability, and Oversight

Concept	Quick Review	Candidate Trap
Governance	Structures and processes for directing and monitoring IT to support business objectives	Treating governance as only technical configuration
Risk appetite	Level of risk leadership is willing to accept	Confusing risk appetite with zero risk
Policy	High-level management expectation	Confusing policies with detailed procedures
Standard	Required rule or baseline	Assuming “guidance” is optional when the scenario says it is required
Procedure	Step-by-step activity	Selecting a procedure when the question asks for governance-level action
Monitoring	Ongoing review of control performance and exceptions	Thinking monitoring replaces control design
Independent assurance	Objective evaluation, often by internal or external auditors	Confusing management review with independent assurance

Risk Terms You Must Separate

Term	Meaning	Example
Inherent risk	Risk before considering controls	Payroll data could be altered by unauthorized users
Control risk	Risk that controls fail to prevent or detect/correct misstatement or issue	Access review is not performed
Residual risk	Risk remaining after controls operate	Some privileged access risk remains after MFA and monitoring
Risk response	Avoid, reduce/mitigate, transfer/share, or accept	Buy cyber insurance, implement MFA, or discontinue a risky system
Compensating control	Control that reduces risk when primary control is weak	Daily independent review of exception reports when automated approval control is limited

Control Categories

Category	Purpose	Examples
Preventive	Stop an error or unauthorized action before it occurs	MFA, input validation, approval workflow
Detective	Identify errors or unauthorized actions after occurrence	Log review, reconciliations, exception reports
Corrective	Fix issues and restore normal operations	Incident remediation, backup restoration, patch deployment
Manual	Performed by people	Manager review of access list
Automated	Performed by system logic	Three-way match, system-enforced credit limit
IT-dependent manual	Manual review relying on system-generated data	Supervisor reviews an exception report generated by the system
Entity-level	Organization-wide control	Security policy, risk management program
Process-level	Specific to process or application	Invoice approval control in accounts payable

Quick decision rule:
If a manual review depends on a system-generated report, you must also consider controls over the report’s completeness and accuracy.

General IT Controls: The Backbone of Reliance

General IT controls, often called GITCs, support the reliability of systems, applications, and automated controls. If GITCs are weak, reliance on automated calculations, reports, interfaces, and application controls may be limited.

Access Controls

Area	High-Yield Points	Common Mistake
Authentication	Verifies identity; passwords, MFA, biometrics, tokens	Confusing authentication with authorization
Authorization	Determines what the authenticated user may do	Assuming login approval means proper transaction access
Accounting/logging	Records user activity for monitoring and investigation	Treating logs as preventive rather than detective
Least privilege	Users receive only access needed for job duties	Granting broad access “for convenience”
Segregation of duties	Incompatible duties are separated	Allowing one user to create vendor, approve invoice, and release payment
Privileged access	Admin/root access requires special approval and monitoring	Treating admin accounts like ordinary user accounts
Provisioning	Access is approved before granted	Missing documented approval
Deprovisioning	Access is removed timely after transfer/termination	Focusing only on new hires and ignoring terminations
Periodic review	Management reviews access for appropriateness	Review is weak if reviewers lack knowledge or exceptions are not resolved
Generic/shared accounts	Reduce accountability	Acceptable only with strong compensating controls, if at all

Access Control Exam Traps

Authentication is not authorization. MFA proves identity; it does not prove the user should have access to approve payments.
Periodic access reviews are detective. They identify inappropriate access after it exists.
Privileged access is high risk. Admins can often bypass application controls.
Timely deprovisioning matters. Former employees and transferred users are frequent scenario risks.
Service accounts need governance. They require ownership, limited privileges, secure credential handling, and monitoring.

Change Management Controls

Control Step	Purpose	Strong Evidence
Change request	Documents business/technical need	Approved ticket with description and owner
Impact assessment	Evaluates risk to systems, data, controls, users	Documented analysis and affected components
Approval	Ensures authorized changes only	Approval by appropriate business/system owner
Development and testing	Confirms change works as intended	Test scripts, results, defect resolution
User acceptance testing	Confirms business requirements	UAT sign-off by knowledgeable user
Segregation of duties	Prevents developers from moving own code to production	Separate migration rights or monitored emergency process
Production migration	Controlled deployment	Deployment log, version control, approval trail
Backout plan	Enables rollback if change fails	Documented rollback plan and responsible personnel
Emergency change review	Allows urgent fixes while preserving control	Retrospective approval and testing evidence

Quick decision rule:
The best control over unauthorized production changes usually involves restricted migration access, independent approval, testing, and monitoring of emergency changes.

IT Operations Controls

Area	Review Focus	Typical Control
Job scheduling	Batch jobs run completely, accurately, and on time	Scheduler logs, job failure alerts
Backup	Data can be restored	Backup schedule, encryption, offsite/immutable storage, restore testing
Incident management	Events are identified, prioritized, resolved	Ticketing workflow, escalation, root-cause analysis
Problem management	Recurring issues are analyzed and fixed	Trend analysis and permanent corrective action
Patch management	Known vulnerabilities are remediated	Risk-based patch prioritization and deployment evidence
Vulnerability management	Weaknesses are identified and tracked	Scans, remediation plans, exception approvals
Capacity monitoring	Systems meet performance needs	Utilization thresholds and alerts
Logging and monitoring	Suspicious activity is detected	SIEM alerts, log retention, review evidence
End-user computing	Spreadsheets and user tools are controlled	Version control, access restriction, formula review

Application Controls and Business Process Reliability

Application controls operate within business applications and directly support transaction integrity.

Input, Processing, and Output Controls

Control Area	Objective	Examples
Input completeness	All valid transactions are captured	Prenumbered documents, batch totals, record counts
Input accuracy	Data entered correctly	Format checks, reasonableness checks, field validation
Input validity	Only legitimate transactions are accepted	Customer/vendor validation, approval workflow
Processing completeness	All accepted items are processed	Run-to-run totals, sequence checks
Processing accuracy	Calculations and updates are correct	Automated calculation logic, control totals
Processing authorization	System actions follow approved rules	Approval hierarchy, workflow limits
Output completeness	Reports include all required data	Reconciliation to source totals
Output accuracy	Reports reflect correct processing	Report validation, independent review
Output distribution	Reports go only to authorized users	Role-based report access

Common Application Control Examples

Control	Best Use	Trap
Limit check	Prevents values above/below threshold	Does not prove transaction is valid
Range check	Ensures value falls within acceptable range	Poorly set ranges allow bad data
Format check	Ensures structure is correct	Correct format does not mean correct data
Validity check	Compares input to authorized master file	Master file must itself be controlled
Check digit	Detects data entry error in identifier	Does not confirm authorization
Duplicate check	Prevents duplicate transaction or payment	Depends on matching criteria quality
Batch total	Supports completeness and accuracy	Must be reconciled and exceptions resolved
Hash total	Control total over nonfinancial fields	Useful for completeness, not financial amount accuracy
Exception report	Identifies unusual items	Only effective if reviewed and resolved

Master Data Controls

Master data includes relatively stable records such as vendors, customers, employees, products, pricing, and chart of accounts.

Risk	Strong Control
Fictitious vendor created	Independent approval of vendor additions
Unauthorized bank account change	Callback verification and approval workflow
Incorrect price table	Restricted access and change review
Duplicate customer/vendor	Duplicate detection and periodic cleanup
Inappropriate employee master change	HR/payroll segregation and audit trail review

Quick decision rule:
If the scenario involves unauthorized payments, look at vendor master access, bank account changes, invoice approval, payment release authority, and reconciliation controls.

Information Systems, Data, and Technology Concepts

Data Governance and Data Quality

Concept	What It Means	Exam Focus
Data owner	Business role accountable for data definition and use	Ownership is not just an IT function
Data steward	Supports data quality and standards	Operational responsibility for data quality
Data classification	Labels data by sensitivity/value	Drives access, encryption, retention
Data lineage	Tracks data origin, movement, transformation	Important for report reliability and analytics
Metadata	Data about data	Helps users understand source, meaning, and limitations
Retention	Data kept for required business/legal period	Over-retention increases privacy and security risk
Disposal	Secure destruction when no longer needed	Deleting a pointer may not securely erase data
Data quality	Complete, accurate, valid, timely, consistent	Poor data quality undermines analytics and controls

Database and Reporting Controls

Risk	Control
Unauthorized direct database changes	Restrict DBA access, log privileged activity, review changes
Incomplete report data	Reconcile report totals to source system or query criteria
Incorrect query logic	Independent review and testing of report parameters
Uncontrolled report changes	Report change management and version control
Sensitive data exposure	Role-based access, masking, encryption, monitoring

Candidate trap:
A beautifully formatted dashboard is not reliable unless the underlying data source, transformation logic, access, and report parameters are controlled.

Cloud and Third-Party Technology

Area	Key Review Point
Shared responsibility	Cloud provider and customer responsibilities differ by service model
SaaS	Customer often controls configuration, access, data governance, and monitoring
PaaS	Customer controls applications/data; provider controls more infrastructure
IaaS	Customer controls operating systems, applications, data, and many security configurations
Vendor risk	Due diligence, contract terms, monitoring, SOC reports, incident notification
Data location	May affect privacy, legal, and contractual considerations
Encryption	Must include key management, not just “encryption enabled”
Availability	SLAs, redundancy, backup, disaster recovery, exit planning

Quick decision rule:
Outsourcing technology does not outsource accountability for risk management, user access, data protection, and monitoring.

Interfaces, APIs, and Data Transfers

Risk	Control
Incomplete transfer	Record counts, control totals, acknowledgments
Unauthorized API access	Strong authentication, authorization scopes, token management
Data altered in transit	Encryption, integrity checks, secure protocols
Failed interface not detected	Error logs, alerts, retry procedures
Duplicate processing	Unique transaction IDs and duplicate checks
Excessive data exposure	Data minimization and field-level controls

Security, Confidentiality, Privacy, and Cybersecurity

Trust-Service Style Concepts to Distinguish

Category	Core Idea	Example Control
Security	Protection against unauthorized access, use, or modification	MFA, firewalls, access reviews
Availability	System is available for operation and use as committed	Redundancy, monitoring, DR testing
Processing integrity	Processing is complete, valid, accurate, timely, and authorized	Input validation, reconciliations, workflow approvals
Confidentiality	Information designated confidential is protected	Encryption, access restrictions, NDAs
Privacy	Personal information is collected, used, retained, disclosed, and disposed of appropriately	Notice, consent, retention limits, privacy access controls

Common trap:
Confidentiality and privacy overlap, but they are not identical. Privacy is specifically about personal information and commitments regarding its collection, use, retention, disclosure, and disposal.

Cybersecurity Threats and Controls

Threat	What It Targets	Likely Controls
Phishing	Users and credentials	Awareness training, MFA, email filtering
Malware/ransomware	Systems and data availability	Endpoint protection, patching, backups, least privilege
SQL injection	Application input and database	Input validation, parameterized queries, secure coding
Cross-site scripting	Web users and sessions	Output encoding, input validation, secure headers
DDoS	Availability	Traffic filtering, redundancy, provider mitigation
Insider threat	Authorized access misuse	Least privilege, monitoring, segregation of duties
Credential stuffing	Reused passwords	MFA, rate limiting, compromised credential monitoring
Misconfiguration	Cloud/network/system exposure	Baselines, configuration monitoring, reviews
Unpatched vulnerability	Known technical weakness	Patch management and vulnerability scanning

Encryption, Hashing, and Tokenization

Technique	Purpose	Key Point
Symmetric encryption	Same key encrypts/decrypts	Fast; key sharing must be protected
Asymmetric encryption	Public/private key pair	Supports secure exchange and digital signatures
Hashing	One-way transformation	Used for integrity checks and password storage with salt
Digital signature	Authentication, integrity, nonrepudiation	Created with private key and verified with public key
Tokenization	Replaces sensitive value with token	Reduces exposure of original data
TLS	Protects data in transit	Requires proper certificate and configuration
Key management	Protects cryptographic keys	Weak key management can defeat encryption

Quick decision rule:
Encryption protects confidentiality, but it does not automatically prove data is complete, accurate, authorized, or properly retained.

Defense in Depth

A single control rarely solves the full risk. Strong security uses layered controls:

Governance and policies
Asset inventory and data classification
Secure configuration baselines
Network segmentation
Identity and access management
Vulnerability and patch management
Logging, SIEM, and monitoring
Incident response
Backup and recovery
User awareness and training
Third-party monitoring

Business Continuity, Disaster Recovery, and Incident Response

BCP vs. DR vs. Incident Response

Concept	Primary Question	Examples
Business continuity plan	How does the business continue critical operations?	Alternate processes, crisis communication, manual workarounds
Disaster recovery plan	How are IT systems restored?	Restore sequence, backup recovery, alternate site
Incident response plan	How is a security event handled?	Containment, eradication, evidence preservation
Business impact analysis	Which processes are critical and what is the impact of disruption?	Prioritization of systems and recovery needs

Recovery Terms

Term	Meaning	Trap
RTO	Maximum acceptable time to restore service	Not the same as backup frequency
RPO	Maximum acceptable data loss measured in time	Drives backup/replication frequency
Hot site	Fast recovery, higher cost	Not always necessary for low-criticality systems
Warm site	Partial readiness	Requires setup before full operation
Cold site	Basic facility/infrastructure	Slowest recovery
Full backup	Complete copy	Longer backup time, simpler restore
Incremental backup	Changes since last backup	Faster backup, more complex restore
Differential backup	Changes since last full backup	Balance between full and incremental

Incident Response Sequence

Phase	Objective
Preparation	Policies, tools, roles, training, playbooks
Detection and analysis	Identify event, severity, scope, affected assets
Containment	Limit damage and prevent spread
Eradication	Remove root cause, malware, unauthorized access
Recovery	Restore systems and monitor for recurrence
Lessons learned	Improve controls and update procedures

Candidate trap:
Backups are not enough. The organization must test restoration and ensure backups are protected from the same event, especially ransomware.

SOC and Assurance Reporting Concepts

SOC concepts are high-yield for CPA ISC because they connect systems, controls, service organizations, and user assurance needs.

SOC Report Comparison

Report	Primary Subject	Typical User Need	Use Restriction
SOC 1	Controls at a service organization relevant to user entities’ internal control over financial reporting	User auditor needs evidence for financial statement audit	Restricted use
SOC 2	Controls relevant to selected trust services criteria	Customers and stakeholders need detailed control assurance	Restricted use
SOC 3	Similar subject matter to SOC 2 but summarized	General-use report for broad distribution	General use

Type 1 vs. Type 2

Report Type	Covers	Best For
Type 1	Design and implementation of controls at a point in time	Understanding whether controls are suitably designed as of a date
Type 2	Design, implementation, and operating effectiveness over a period	Assessing whether controls operated effectively over time

Quick decision rule:
If the question asks whether controls operated effectively over a period, Type 2 is generally more relevant than Type 1.

SOC 1 vs. SOC 2 Decision Rule

Scenario Need	More Likely Report
Payroll processor affects user entity financial reporting	SOC 1
Cloud hosting provider wants assurance over security and availability	SOC 2
Vendor wants a public marketing-style assurance report	SOC 3
User auditor needs tests of controls and results over the audit period	Type 2 report
User wants detailed exceptions, control descriptions, and testing	SOC 1 Type 2 or SOC 2 Type 2, depending on subject

SOC Report Elements to Review

Element	Why It Matters
Management assertion	Management’s responsibility for description and control criteria
Service auditor’s opinion	Conclusion on description, design, and, for Type 2, operating effectiveness
System description	Boundaries, services, components, controls, subservice organizations
Control tests and results	Critical in Type 2 reports
Exceptions/deviations	Must be evaluated for severity and relevance
Complementary user entity controls	Controls the user entity must operate for service organization controls to be effective
Complementary subservice organization controls	Controls expected at subservice organizations
Period covered	Must align with the period of reliance
Carve-out method	Subservice organization controls excluded from scope
Inclusive method	Subservice organization controls included in scope

CUECs: Common Exam Trap

Complementary user entity controls, or CUECs, are not optional footnotes. If the service organization’s control assumes the user entity performs a control, the user entity or user auditor must evaluate whether that control is designed and operating effectively.

Example:
A payroll service organization may require user entities to review payroll change reports. If the user entity does not perform that review, the SOC report alone may not provide sufficient assurance for that risk.

Evidence, Testing, and Evaluation

Design vs. Implementation vs. Operating Effectiveness

Evaluation	Question Answered	Evidence Example
Design effectiveness	Would the control address the risk if performed as designed?	Review control description and evaluate logic
Implementation	Has the control been placed in operation?	Walkthrough, inspection of configuration
Operating effectiveness	Did the control operate consistently and effectively over time?	Sample testing, log review, reperformance

Quick decision rule:
A control can be well designed but fail in operation. A control can operate exactly as designed but still be ineffective if the design does not address the risk.

Evidence Strength

Procedure	Strengths	Limitations
Inquiry	Useful for understanding process	Weak alone; needs corroboration
Observation	Shows control being performed at a point in time	Limited to moment observed
Inspection	Supports existence of documentation/configuration	Documentation may not prove consistent operation
Reperformance	Strong evidence of control operation	May be time-consuming
Recalculation	Confirms mathematical accuracy	Does not prove authorization or completeness
Data analytics	Tests large populations and patterns	Depends on data reliability and logic
Walkthrough	Understands process from initiation to reporting	Usually not enough alone for operating effectiveness

Automated Controls and Reports

Before relying on automated controls or system-generated reports, consider:

Who can change the application logic?
Were changes approved, tested, and migrated properly?
Who can access or modify underlying data?
Is the report complete and accurate?
Are report parameters appropriate?
Are exceptions reviewed and resolved?
Are relevant GITCs effective?

Evaluating Control Exceptions

When a test identifies exceptions, evaluate:

Nature: What failed?
Cause: Is it isolated, systematic, or due to design weakness?
Frequency: How often did it occur?
Magnitude: What is the potential impact?
Timing: Did it affect the period being tested?
Compensating controls: Did another control reduce the risk?
Pervasiveness: Could the issue affect multiple systems or processes?
Reporting implication: Does it affect reliance, opinion, or required communication?

Fast Decision Tables for Exam Scenarios

Match the Risk to the Best Control

If the Risk Is…	Look First For…
Unauthorized system access	MFA, least privilege, provisioning approval, deprovisioning
Excessive privileged access	PAM, admin approval, session logging, periodic review
Unauthorized production changes	Change approval, testing, migration restrictions
Incomplete transaction processing	Batch totals, record counts, reconciliations
Incorrect master data	Restricted access, independent approval, audit trail review
Duplicate payments	Duplicate invoice checks, vendor controls, AP review
Inaccurate report used in review	Report logic testing, source reconciliation, parameter review
Data breach	Encryption, access controls, monitoring, incident response
System outage	Redundancy, DR plan, backups, capacity monitoring
Cloud vendor risk	Due diligence, SOC report review, contract controls, monitoring
Privacy noncompliance	Data minimization, notice/consent, retention/disposal controls
Ransomware	Least privilege, patching, EDR, offline/immutable backups

Best Evidence by Question Type

Question Asks For…	Strong Evidence
Whether access was approved	Access request ticket with approval
Whether terminated users were removed	Termination listing matched to access removal logs
Whether changes were tested	Test plans, results, defect resolution, sign-off
Whether production changes were authorized	Change tickets tied to production migration logs
Whether backup works	Successful restore test evidence
Whether report is complete	Reconciliation to source data or validated query
Whether exception report is effective	Evidence of review and documented resolution
Whether control operated over time	Sample of occurrences across the period

Common CPA ISC Candidate Mistakes

Mistake 1: Picking the Most Technical Answer Instead of the Best Control

The best answer is often the control that most directly addresses the risk, not the most advanced technology.

Example:
For unauthorized payroll master file changes, “blockchain” is less relevant than restricted access, independent approval, audit trails, and review of changes.

Mistake 2: Confusing Preventive and Detective Controls

MFA: preventive
Access review: detective
Reconciliation: detective
Exception report: detective
Input validation: preventive
Backup restoration: corrective/recovery

Mistake 3: Ignoring Segregation of Duties

Watch for users who can perform incompatible duties:

Create vendor and approve vendor
Enter invoice and approve payment
Develop code and migrate to production
Grant access and review own access
Administer database and approve business transactions

Mistake 4: Assuming a SOC Report Solves Everything

Before relying on a SOC report, check:

Is it SOC 1 or SOC 2?
Is it Type 1 or Type 2?
Does the period align?
Are relevant controls included?
Are subservice organizations carved out?
Are CUECs identified and performed?
Are exceptions relevant and significant?

Mistake 5: Treating Inquiry as Sufficient Evidence

Inquiry helps you understand the process, but exam questions often require stronger evidence such as inspection, reperformance, configuration review, logs, or testing across the period.

Mistake 6: Forgetting Completeness and Accuracy of Reports

If a manager reviews a report, the review control is only useful if:

The report includes the right population.
The report logic is correct.
Parameters are appropriate.
The reviewer investigates exceptions.
Follow-up is documented.

Mistake 7: Mixing Up Confidentiality, Availability, Processing Integrity, and Privacy

Scenario	Most Direct Category
Unauthorized user accesses confidential contract	Security/confidentiality
System unavailable during peak processing	Availability
Valid transactions omitted from processing	Processing integrity
Customer personal data retained longer than policy	Privacy
File altered during transmission	Security/integrity and processing integrity, depending on context

Mini Workflows to Remember

Control Evaluation Workflow

    flowchart TD
	    A[Identify objective] --> B[Identify risk]
	    B --> C[Map control to risk]
	    C --> D{Is design suitable?}
	    D -- No --> E[Design deficiency]
	    D -- Yes --> F{Implemented?}
	    F -- No --> G[Implementation deficiency]
	    F -- Yes --> H[Test operating effectiveness]
	    H --> I{Exceptions found?}
	    I -- No --> J[May support reliance]
	    I -- Yes --> K[Evaluate cause, frequency, impact, compensating controls]

SOC Report Selection Workflow

    flowchart TD
	    A[Need assurance over service organization?] --> B{Relevant to user entity ICFR?}
	    B -- Yes --> C[SOC 1]
	    B -- No --> D{Need detailed trust services control report?}
	    D -- Yes --> E[SOC 2]
	    D -- No --> F{Need general-use summary?}
	    F -- Yes --> G[SOC 3]
	    C --> H{Need operating effectiveness over time?}
	    E --> H
	    H -- Yes --> I[Type 2]
	    H -- No --> J[Type 1]

Topic Drill Priorities

Use original practice questions and topic drills to test whether you can apply these distinctions under time pressure.

Start With These High-Yield Drill Sets

SOC report selection
- SOC 1 vs. SOC 2 vs. SOC 3
- Type 1 vs. Type 2
- CUECs, subservice organizations, carve-out vs. inclusive method
Access controls
- Provisioning, deprovisioning, privileged access
- Authentication vs. authorization
- Periodic reviews and segregation of duties
Change management
- Unauthorized production changes
- Emergency changes
- Testing, approval, migration, rollback
Application controls
- Completeness, accuracy, validity, authorization
- Input, processing, output, master data, interfaces
Cybersecurity and privacy
- Threat-control matching
- Encryption vs. hashing vs. tokenization
- Confidentiality vs. privacy
Evidence and testing
- Inquiry vs. inspection vs. reperformance
- Design vs. operating effectiveness
- Report completeness and accuracy
Business continuity and incident response
- RTO vs. RPO
- Backup vs. restore testing
- Incident response sequence

Final Quick Review Checklist

Before moving to a mock exam, confirm that you can answer these quickly:

Can I explain why GITCs matter for automated controls?
Can I distinguish application controls from general IT controls?
Can I identify the best control for unauthorized access, unauthorized change, incomplete processing, and inaccurate reporting?
Can I tell whether a control is preventive, detective, or corrective?
Can I separate authentication, authorization, and logging?
Can I evaluate whether a user access review is strong or weak?
Can I identify incompatible IT and business process duties?
Can I distinguish data confidentiality from data privacy?
Can I apply RTO and RPO correctly?
Can I choose between SOC 1, SOC 2, and SOC 3?
Can I choose between Type 1 and Type 2?
Can I explain why CUECs matter?
Can I identify evidence that supports operating effectiveness over time?
Can I evaluate control exceptions for severity and relevance?

Practical Next Step

Use this Quick Review as a final concept pass, then move into independent companion practice: complete targeted topic drills, answer original practice questions, and read the detailed explanations for every missed or guessed item. Focus especially on SOC reporting, access controls, change management, application controls, cybersecurity, and evidence evaluation for the AICPA U.S. CPA ISC - Information Systems and Controls (CPA ISC) exam.

Study Plan