CPA ISC Cheat Sheet: Information Systems and Controls Cheat Sheet

Last revised: September 28, 2026

Cheat sheet: independent reference for AICPA U.S. CPA ISC - Information Systems and Controls (CPA ISC): IT controls, SOC, cybersecurity, data, and audit evidence.

This independent Cheat Sheet supports candidates preparing for the AICPA U.S. CPA ISC - Information Systems and Controls (CPA ISC) exam. Use it to review high-yield IT control concepts, SOC reporting distinctions, cybersecurity risks, data management, system implementation, and evidence patterns likely to appear in applied CPA-style questions.

Use the tables for a quick pre-exam check. Expand a topic’s notes for explanations, examples, and additional distinctions.

Scope and study context

This independent Cheat Sheet 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.

High-Yield Exam Orientation

Area	What to recognize quickly	Exam trap
IT general controls	Access, change management, operations, security, backup, monitoring	Confusing ITGCs with application controls
Application controls	Input, processing, output, interface, master file controls	Assuming an automated control is effective without ITGC support
SOC reporting	SOC 1 vs SOC 2; Type 1 vs Type 2; CUECs; subservice organizations	Picking SOC 2 when the user auditor needs ICFR evidence
Trust Services Criteria	Security is common/foundational; other categories add specific commitments	Treating privacy and confidentiality as identical
Cybersecurity	Identify, protect, detect, respond, recover; layered defenses	Assuming prevention alone is sufficient
Data management	Classification, lineage, integrity, availability, retention, privacy	Ignoring data lifecycle risks after collection
System development	Requirements, design, testing, approval, migration, post-implementation review	Letting developers migrate code to production
Business continuity	BIA, RTO, RPO, backups, DR strategy, testing	Confusing RTO with RPO
Cloud/outsourcing	Shared responsibility, vendor risk, SLAs, SOC reports, data location	Assuming outsourcing transfers accountability
Audit evidence	Inquiry alone is weak; inspect, observe, test, reperform, analyze	Accepting screenshots without corroboration

Core Control Vocabulary

Term	Meaning	CPA ISC exam cue
IT general controls, or ITGCs	Entity/process-level IT controls supporting reliable systems	Access, program changes, operations, security
Application controls	Controls embedded in a specific application	Edit checks, limit checks, approvals, reconciliations
Automated control	System-executed control with little manual intervention	Depends on access/change controls over the system
Manual control	Performed by a person	More judgment, more variability, needs evidence of performance
IT-dependent manual control	Manual review using system-generated information	Need to test report completeness and accuracy
Preventive control	Stops error or unauthorized action before occurrence	MFA, input validation, approval workflow
Detective control	Finds an error or issue after occurrence	Log review, reconciliation, exception report
Corrective control	Fixes issue and reduces future impact	Incident remediation, patching, restore from backup
Compensating control	Alternative control reducing risk when primary control is weak	Must address the same risk sufficiently
Entity-level control	Broad control affecting multiple processes	Governance, risk assessment, security policy
Key control	Control important enough to prevent or detect material issue	Failure may require expanded testing or reliance reduction
Configuration control	Control based on system settings	Password parameters, workflow routing, segregation rules
Completeness	All valid transactions/data are captured	Sequence checks, reconciliations, interface totals
Accuracy	Data is recorded correctly	Validation, reasonableness checks, recalculation
Validity	Transactions are authorized and genuine	Approval, authentication, existence checks
Confidentiality	Information protected from unauthorized disclosure	Encryption, access restriction, NDA, classification
Integrity	Information is complete, accurate, and unaltered	Hashing, checksums, approvals, audit trails
Availability	Systems/data accessible when needed	Redundancy, DR, monitoring, capacity management

ITGC vs Application Control Decision Table

Scenario	Likely control type	Why it matters
New users require manager approval before account creation	ITGC - access	Governs who can use systems
Developers cannot migrate code to production	ITGC - change management	Protects production integrity
Batch jobs are monitored for failures	ITGC - operations	Ensures processing completes
System rejects invoice with invalid vendor ID	Application control - input validation	Specific to transaction processing
Three-way match before payment	Application control - processing/authorization	Prevents invalid disbursement
Exception report reviewed by AP supervisor	IT-dependent manual control	Need evidence of review and report reliability
Password complexity is enforced by system configuration	ITGC - security/access	Broad authentication safeguard
Interface totals between payroll and GL are reconciled	Application/interface control	Ensures transferred data is complete and accurate
Daily backup job completion is reviewed	ITGC - operations/continuity	Supports recovery capability
Customer credit limit blocks excess orders	Application control	Enforces business rule automatically

Access Control Cheat Sheet

Access Lifecycle

Stage	Control objective	Strong control examples	Weakness indicators
Request	Only appropriate access is requested	Ticket, manager approval, role justification	Email-only requests, vague approval
Provision	Access matches approved role	RBAC templates, least privilege, SoD check	Copying another user’s access without review
Authentication	User identity is verified	MFA, password policy, SSO controls	Shared accounts, default passwords
Authorization	User can perform only allowed actions	Role permissions, privileged access limits	Excess access, conflicting roles
Monitoring	Inappropriate activity is detected	Log review, alerts, UEBA, exception reports	Logs disabled or never reviewed
Recertification	Access remains appropriate	Periodic manager review, evidence retained	Review is rubber-stamped
Termination	Access removed promptly	HR-triggered deprovisioning, automated workflow	Active accounts for former employees

Notes and examples

Authentication and Authorization Distinctions

Concept	Answers the question	Examples	Common trap
Identification	Who do you claim to be?	Username, user ID	Not proof by itself
Authentication	Can you prove identity?	Password, MFA token, biometric	Password alone may be weak
Authorization	What are you allowed to do?	RBAC, ACLs, entitlements	Authenticated users can still be unauthorized
Accountability	Can actions be traced to a user?	Unique IDs, audit logs	Shared IDs destroy accountability

Access Control Models

Model	Best description	Common use	Exam note
RBAC	Access based on job role	Accounting clerk, AP manager, system admin	Good for scalable least privilege
ABAC	Access based on attributes	Location, device, clearance, data tag	Useful in dynamic/cloud environments
DAC	Owner controls access	File owner grants permissions	Flexible but can be less controlled
MAC	Central authority/classification controls access	Highly sensitive/classified environments	Users cannot override classification
PAM	Special controls for privileged accounts	Admin vaulting, session recording, just-in-time access	High-yield for administrator risk

Segregation of Duties in IT

Incompatible duties	Risk	Preferred control
Developer and production deployer	Unauthorized or untested code reaches production	Separate migration approval and deployment
System admin and security log reviewer	Admin can hide misuse	Independent monitoring/security function
User requester and access approver	Self-approved access	Manager or data owner approval
DBA and application developer without oversight	Unauthorized data changes	Restricted privileges, logging, independent review
AP clerk and vendor master maintainer	Fictitious vendor payments	Separate vendor maintenance and payment processing
Payroll processor and payroll master file maintainer	Unauthorized pay changes	Approval workflow and audit trail review
Incident responder and incident postmortem approver	Biased closure	Independent review of root cause/remediation

If segregation is not practical, look for compensating controls: independent review, exception reports, enhanced logging, supervisory approval, or periodic access recertification.

Change Management Reference

Step	Control objective	Strong evidence
Request	Change is documented and business need exists	Ticket/change request
Impact assessment	Risks, affected systems, and dependencies are evaluated	Impact analysis, security review
Approval	Authorized party approves before work begins or before migration	Approval workflow, CAB minutes
Development/configuration	Changes are built in nonproduction environment	Repository history, configuration records
Testing	Change works and does not break key controls	Test scripts, user acceptance testing, defect resolution
Security review	Vulnerabilities and access impacts considered	Code scan, peer review, permission review
Migration	Only approved changes move to production	Deployment log, release approval
Post-implementation review	Change outcome and issues assessed	PIR notes, incident linkage
Emergency change follow-up	Urgent changes are retrospectively approved and tested	Emergency ticket, after-the-fact review

Notes and examples

Change Management Traps

Question wording	Best interpretation
“Emergency change was implemented immediately”	Acceptable only with logging, retrospective approval, testing, and review
“Developer has production access”	High risk unless tightly controlled, monitored, and justified
“User acceptance testing was performed by IT only”	Weak; business owner should validate functionality
“Code was approved after migration”	Approval timing problem unless emergency process applies
“No changes occurred during period”	Auditor still needs evidence supporting completeness of change population

System Development and Implementation

Phase	Candidate should know	Key controls
Feasibility/planning	Define business need, cost/benefit, risk	Steering committee approval, project charter
Requirements	Define functional, security, regulatory, reporting needs	User sign-off, traceability
Design	Translate requirements into system design	Architecture review, control design
Build/configure	Develop code or configure package	Version control, restricted dev access
Testing	Validate functionality, controls, interfaces, security	Unit, integration, UAT, regression, penetration testing
Data conversion	Move data from old to new system	Mapping, cleansing, record counts, reconciliations
Cutover	Move to production	Go/no-go approval, rollback plan
Post-implementation	Confirm objectives achieved and issues resolved	PIR, defect tracking, lessons learned

Notes and examples

Testing Types

Test type	Purpose	Exam cue
Unit testing	Individual component works	Developer-level test
Integration testing	Components/interfaces work together	Data flow between systems
System testing	Whole system meets specifications	End-to-end process
User acceptance testing	Business users confirm needs met	User sign-off is important
Regression testing	New change did not break existing functions	Especially after patches/releases
Parallel testing	Old and new systems run simultaneously	Useful for payroll, billing, high-risk conversion
Penetration testing	Simulated attack to identify exploitable weaknesses	Needs authorization and remediation tracking
Vulnerability scanning	Identifies known weaknesses	Broader but less exploit-focused than pen test

IT Operations Controls

Operations area	Risks	Controls to recognize
Job scheduling	Failed or duplicate processing	Automated scheduler, failure alerts, rerun procedures
Batch processing	Incomplete/inaccurate transactions	Control totals, hash totals, sequence checks
Incident management	Issues unresolved or recurring	Ticketing, severity levels, escalation, root cause analysis
Problem management	Root causes not fixed	Trend analysis, known error database, remediation tracking
Capacity management	System outages or poor performance	Monitoring, thresholds, forecasting
Backup operations	Data cannot be restored	Backup schedules, encryption, offsite/cloud storage, restore testing
Logging	Unauthorized actions not detected	Centralized logs, retention, review, tamper protection
Patch management	Known vulnerabilities remain exploitable	Inventory, prioritization, testing, deployment, exception tracking
Configuration management	Unauthorized or insecure settings	Baselines, hardening standards, drift detection
Physical security	Hardware or media compromise	Badges, cameras, visitor logs, environmental controls

Cybersecurity Control Matrix

Threat/risk	Preventive controls	Detective controls	Corrective/recovery controls
Phishing	Security awareness, email filtering, MFA	User reports, suspicious login alerts	Credential reset, incident response
Malware/ransomware	Endpoint protection, least privilege, patching	EDR alerts, abnormal file activity	Isolation, restore from clean backup
Unauthorized access	MFA, RBAC, PAM, network segmentation	Log review, SIEM alerts	Disable account, revoke tokens
Data exfiltration	DLP, encryption, access limits	DLP alerts, outbound traffic monitoring	Legal/incident process, key rotation
Web application attack	Secure coding, WAF, input validation	Web logs, IDS/IPS	Patch, code fix, block indicators
Insider misuse	Least privilege, SoD, monitoring	Audit trails, behavior analytics	Disciplinary process, access removal
Denial of service	Rate limiting, redundancy, DDoS protection	Traffic monitoring	Failover, provider response
Misconfiguration	Hardening standards, IaC review	Configuration scanning	Reconfigure, redeploy baseline
Lost device	Full-disk encryption, MDM, remote wipe	Asset tracking alerts	Wipe, replace, investigate exposure

Encryption, Hashing, and Keys

Concept	Purpose	Key point
Encryption	Protect confidentiality by making data unreadable without key	Reversible with proper key
Symmetric encryption	Same key encrypts and decrypts	Fast; key distribution is challenge
Asymmetric encryption	Public/private key pair	Supports secure exchange and digital signatures
Hashing	One-way transformation to fixed-length digest	Used for integrity, not confidentiality
Salt	Random value added before hashing	Helps protect passwords from precomputed attacks
Digital signature	Authentication, integrity, nonrepudiation	Created with private key, verified with public key
Certificate	Binds public key to identity	Issued/validated through certificate authority
TLS	Protects data in transit	Misconfigured certificates weaken assurance
Key management	Secure generation, storage, rotation, revocation	Weak key management can defeat encryption

Business Continuity and Disaster Recovery

Term	Meaning	Exam distinction
BCP	Business continuity plan; keeps critical business functions operating	Broader than IT systems
DRP	Disaster recovery plan; restores IT systems and data	Component of continuity planning
BIA	Business impact analysis	Identifies critical processes and recovery priorities
RTO	Recovery time objective	Maximum tolerable time to restore service
RPO	Recovery point objective	Maximum tolerable data loss measured in time
MTD/MTO	Maximum tolerable downtime/outage	Upper limit before severe impact
Hot site	Fully equipped, fastest recovery	Higher cost, low downtime
Warm site	Partially equipped	Moderate cost/recovery time
Cold site	Facility available but minimal equipment	Lower cost, longer recovery
Backup restore test	Confirms data can actually be recovered	Backup success alone is insufficient
Tabletop test	Discussion-based walkthrough	Lower disruption, less assurance than live test
Parallel test	Recovery process tested without shutting production	More realistic than tabletop
Full interruption test	Production is stopped and recovery site used	Highest risk/disruption

Notes and examples

Availability calculation:

\[ \text{Availability} = \frac{\text{Total time} - \text{Downtime}}{\text{Total time}} \times 100 \]

RTO vs RPO Fast Check

If the question asks…	Think…
“How long can the system be unavailable?”	RTO
“How much data can be lost?”	RPO
“How frequently should backups occur?”	RPO
“How quickly must operations resume?”	RTO
“Which processes are most critical?”	BIA

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 Reporting Cheat Sheet

SOC 1 vs SOC 2 vs SOC 3

Report	Primary focus	Typical users	Use when question asks about…
SOC 1	Controls at service organization relevant to user entities’ internal control over financial reporting, or ICFR	User entities and their auditors	Payroll processor, claims processor, revenue/billing system affecting financial statements
SOC 2	Controls relevant to Trust Services Criteria	Management, customers, business partners, regulators with sufficient understanding	Security, availability, processing integrity, confidentiality, privacy
SOC 3	General-use summary SOC 2-style report	Public/general users	Public-facing assurance seal or marketing summary, less detail

Notes and examples

Type 1 vs Type 2

Type	Covers	Best for	Limitation
Type 1	Design and implementation at a point in time	New system/vendor, initial design understanding	Does not test operating effectiveness over a period
Type 2	Design, implementation, and operating effectiveness over a period	Reliance on controls over time	Period must align with user/audit needs

SOC Parties and Terms

Term	Meaning	Exam relevance
Service organization	Outsourced provider being reported on	Payroll, cloud hosting, SaaS vendor
User entity	Customer organization using service organization	Management still owns its controls
Service auditor	CPA firm issuing SOC report	Independent practitioner
User auditor	Auditor of user entity financial statements	Evaluates SOC report for audit reliance
Subservice organization	Provider used by the service organization	Data center, cloud platform, payment gateway
Carve-out method	Subservice controls excluded from report scope	User must consider separate evidence
Inclusive method	Subservice controls included in report scope	Provides more direct coverage
CUECs	Complementary user entity controls	Controls user entity must operate for SOC controls to be effective
CSOCs	Complementary subservice organization controls	Controls subservice provider must operate
Bridge letter	Management letter covering gap after SOC report period	Not equivalent to Type 2 testing
Test of controls	Procedures over operating effectiveness	Type 2 reports include tests and results

SOC Exam Decision Cues

Question fact pattern	Likely answer
User auditor needs evidence over outsourced payroll controls affecting payroll expense	SOC 1 Type 2
Customer wants assurance over cloud provider security and availability	SOC 2 Type 2
Vendor wants a public report for general distribution	SOC 3
Report describes controls as of a date only	Type 1
Report includes tests of operating effectiveness for a period	Type 2
Relevant subservice provider is excluded	Carve-out; obtain additional evidence if needed
SOC report says user must review exception reports	CUEC; user entity must perform that control
Report period ends before fiscal year-end	Consider gap procedures or bridge letter plus other evidence

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.

Trust Services Criteria Distinctions

Category	Focus	Examples of controls
Security	System protected against unauthorized access, use, or modification	MFA, firewall, vulnerability management, incident response
Availability	System available for operation and use as committed	Redundancy, monitoring, capacity planning, DR testing
Processing integrity	System processing is complete, valid, accurate, timely, and authorized	Input validation, reconciliation, error handling, job monitoring
Confidentiality	Information designated confidential is protected	Classification, encryption, restricted access, retention/disposal
Privacy	Personal information is collected, used, retained, disclosed, and disposed consistent with commitments	Notice, consent, data subject rights process, privacy policy compliance

Notes and examples

Confidentiality vs Privacy

Confidentiality	Privacy
Applies to information designated confidential	Applies to personal information
Focuses on protection from unauthorized disclosure	Focuses on lifecycle of personal data according to commitments
Can include trade secrets, contracts, financial data	Includes collection, use, retention, disclosure, disposal
Key controls: classification, encryption, access	Key controls: notice, consent, purpose limitation, retention

Data Governance and Data Management

Area	Candidate should recognize	Controls/evidence
Data classification	Data labeled by sensitivity/criticality	Classification policy, data inventory
Data ownership	Business owner accountable for data	Owner approval for access/changes
Data lineage	Origin, movement, and transformation of data	Lineage diagrams, ETL logs
Data quality	Accuracy, completeness, validity, timeliness	Validation rules, exception reports, cleansing
Master data management	Consistent key data across systems	Master file approvals, duplicate checks
Metadata	Data about data	Data dictionary, schema documentation
Retention	Data kept as long as required/needed	Retention schedule, legal hold process
Disposal	Data securely destroyed when no longer needed	Wipe certificates, destruction logs
Data loss prevention	Prevent unauthorized movement/disclosure	DLP rules, alerts, investigation logs
Data masking/tokenization	Protect sensitive data in nonproduction/use cases	Masking rules, token vault controls

Notes and examples

Database and File Concepts

Concept	Meaning	Exam cue
Table	Structured data set with rows and columns	Relational database
Primary key	Unique identifier for a record	Prevents duplicate identity
Foreign key	Links to primary key in another table	Enforces referential integrity
Referential integrity	Related records remain valid/consistent	Cannot post order to nonexistent customer
Normalization	Reduces redundancy and update anomalies	More structured, less duplication
Denormalization	Adds redundancy for speed/reporting	May increase consistency risk
Data warehouse	Central repository for reporting/analytics	Often uses ETL/ELT
Data lake	Stores raw/semi-structured/unstructured data	Requires governance to avoid “data swamp”
ETL	Extract, transform, load	Transformation before loading target
ELT	Extract, load, transform	Common in scalable cloud platforms

Analytics Evidence Cautions

Analytics result	What to validate
Exception report	Completeness and accuracy of source data and logic
Duplicate payment analysis	Vendor matching logic, thresholds, false positives
Benford-style anomaly	Investigative lead, not proof of fraud
Dashboard metric	Data refresh, calculation logic, access controls
Full-population test	Data extraction completeness and criteria accuracy
AI/model output	Model governance, training data, bias, explainability, monitoring

Application Control Reference

Control type	Purpose	Examples
Input control	Ensure entered data is complete, valid, accurate	Required fields, format checks, reasonableness checks
Edit check	Detect invalid data	Date format, valid customer number
Limit check	Reject values beyond threshold	Expense over policy limit
Range check	Ensure value within accepted range	Hours worked between 0 and 80
Check digit	Validate identifier accuracy	Account/customer number validation
Completeness check	Ensure all required data is present	Required invoice fields
Sequence check	Identify missing/duplicate transactions	Invoice number sequence
Processing control	Ensure processing is complete and accurate	Run-to-run totals, automated calculations
Interface control	Ensure data transfer between systems is complete/accurate	Control totals, reconciliations
Output control	Ensure reports/output are accurate and distributed properly	Report review, restricted distribution
Master file control	Protect standing data	Vendor/customer change approvals, audit trail
Exception control	Identify and resolve processing exceptions	Exception report with documented follow-up

Cloud and Third-Party Risk

Topic	Candidate should know	Exam cue
Shared responsibility	Customer and provider each retain security duties	Cloud use does not eliminate management responsibility
IaaS	Customer manages more: OS, apps, data, configurations	More control, more responsibility
PaaS	Provider manages platform; customer manages apps/data	Configuration and code still matter
SaaS	Provider manages application; customer manages users, settings, data use	Access/configuration controls remain important
Vendor due diligence	Evaluate risk before onboarding	SOC reports, security questionnaires, financial stability
SLA	Documents service commitments	Availability, response time, support, remedies
Right to audit	Allows review of vendor controls	Important for critical vendors
Data location	Where data is stored/processed	Privacy, contractual, operational implications
Exit strategy	Ability to transition away	Data portability, deletion, continuity
Vendor monitoring	Ongoing review of performance/risk	SOC review, SLA metrics, issue tracking

Notes and examples

Cloud Control Traps

Trap	Better answer
“Cloud provider handles all security.”	Security is shared; customer still controls users, data, configuration, monitoring.
“SaaS means no IT controls are needed.”	SaaS still needs access, configuration, vendor, and data controls.
“SOC report automatically proves all controls are effective.”	Evaluate scope, period, exceptions, CUECs, subservice treatment.
“Encryption solves privacy risk.”	Encryption helps confidentiality; privacy also covers collection, use, notice, retention, disposal.

Audit Evidence and Testing Patterns

Procedure	Strength/use	Limitation
Inquiry	Understand process, identify controls	Weak alone; needs corroboration
Observation	See control performed	Only proves performance at observed time
Inspection	Examine documents, logs, tickets, configurations	Evidence quality depends on source reliability
Reperformance	Independently execute control/calculation	Strong evidence for operating effectiveness
Walkthrough	Trace transaction/process end to end	Useful for design/implementation understanding
Test of one	Often used for automated control if ITGCs effective	Not enough if ITGCs are weak or control changed
CAATs/data analytics	Analyze large populations	Requires reliable data extraction and logic
Confirmation	Obtain evidence from external party	More common in financial audit contexts
SOC report review	Evidence about service organization controls	Must assess report type, period, scope, exceptions

Notes and examples

Evidence Reliability Ranking

More reliable	Less reliable
Independent external evidence	Internally generated evidence without controls
Direct auditor access to system/logs	Screenshot provided by control owner only
Automated logs with restricted admin access	Editable spreadsheets
Reperformance	Inquiry alone
Evidence generated close to control performance	Evidence recreated after the fact

Mapping Risks to Controls

Risk	Poor answer	Better answer
Unauthorized users access financial system	Annual password change only	MFA, approved provisioning, least privilege, periodic access review
Terminated employee remains active	Manager should remember to notify IT	Automated HR termination feed and prompt deprovisioning
Unauthorized code change affects reports	Developer says change was tested	Formal change approval, testing evidence, restricted migration
Batch job fails silently	User notices missing report	Job monitoring with alerts and documented resolution
Incomplete interface transfer	Assume API works	Control totals, error logs, reconciliation
Backup cannot restore data	Backup job says “success”	Periodic restore testing
Sensitive data used in testing	Trust developers	Mask/tokenize production data in nonproduction
Vendor outage disrupts operations	Vendor is reputable	SLA, DR review, monitoring, exit plan
Admin deletes logs	Logs stored locally only	Centralized, access-restricted, tamper-resistant logging
AI output drives business decision	Rely on model result	Model governance, validation, monitoring, human review

Common CPA ISC Question Traps

Trap	How to avoid it
Equating design effectiveness with operating effectiveness	Design asks “would it work?” Operating asks “did it work consistently?”
Choosing SOC 2 for financial statement reliance	If ICFR at service organization matters, think SOC 1.
Ignoring CUECs	SOC controls may rely on user entity controls being performed.
Treating a Type 1 report as period evidence	Type 1 is point-in-time only.
Assuming outsourcing transfers responsibility	Management remains accountable for outsourced processes.
Accepting inquiry as sufficient evidence	Corroborate with logs, tickets, configs, observation, or reperformance.
Confusing RTO and RPO	RTO = time to restore; RPO = acceptable data loss.
Believing encryption proves integrity	Encryption protects confidentiality; hashing/signatures support integrity.
Overlooking privileged users	Admin access is high risk even if ordinary user access is controlled.
Assuming automated controls need no testing	Automated controls rely on ITGCs and configuration integrity.
Ignoring report period gaps	SOC report period must cover the reliance period or need gap procedures.
Treating privacy as only security	Privacy includes collection, use, disclosure, retention, and disposal commitments.

Mini Scenario Decision Table

Scenario	Most likely focus	Best response pattern
External payroll provider processes payroll and sends journal entries	SOC 1, CUECs, user auditor reliance	Obtain SOC 1 Type 2; evaluate period, scope, exceptions, CUECs
SaaS CRM stores customer personal information	SOC 2/privacy/confidentiality, access, vendor risk	Review SOC 2, privacy commitments, access controls, data retention
New ERP implementation converts vendor master data	Data conversion and master file controls	Reconcile record counts, validate mapping, approve exceptions
Developer applies production fix during outage	Emergency change management	Ensure logging, testing, retrospective approval, monitoring
Management uses system report to review revenue exceptions	IT-dependent manual control	Test review evidence plus report completeness/accuracy
Disaster recovery plan exists but has never been tested	DR operating effectiveness gap	Perform tabletop/parallel/restore tests and remediate issues
Admin accounts are shared	Accountability failure	Unique privileged IDs, PAM, MFA, session logging
Vendor SOC report excludes cloud data center provider	Subservice carve-out	Obtain additional evidence or assess complementary controls
Dashboard shows KPI used in board reporting	Data governance and integrity	Validate source data, transformation logic, access, refresh timing
Former employee account remains active for 30 days	Deprovisioning weakness	HR-triggered termination workflow and access monitoring

Notes and examples

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

Last-Minute Review Checklist

Before exam day, be able to answer these without hesitation:

SOC 1 vs SOC 2 vs SOC 3.
Type 1 vs Type 2 SOC reports.
CUECs, CSOCs, carve-out, and inclusive method.
ITGC vs application control classification.
Preventive vs detective vs corrective controls.
Access provisioning, deprovisioning, privileged access, and periodic review.
Change management evidence from request through migration.
Emergency change control requirements.
RTO vs RPO vs BIA.
Backup success vs restore testing.
Confidentiality vs privacy vs processing integrity.
Encryption vs hashing vs digital signatures.
Input, processing, output, interface, and master file controls.
Data lineage, classification, retention, and secure disposal.
Cloud shared responsibility and vendor monitoring.
Why inquiry alone is insufficient evidence.
How weak ITGCs affect reliance on automated controls.

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

Notes and examples

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	Cheat Sheet	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

Notes and examples

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

Notes and examples

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

Notes and examples

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

Notes and examples

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

Notes and examples

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

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

Notes and examples

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?

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

Notes and examples

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 Cheat Sheet 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?

Put the review into practice

Finance Prep

Start CPA ISC Cheat Sheet: Information Systems and Controls on Web

Use the web app to preview question style, then practise the topics you need to revisit.

Original Finance Prep practice: not official exam-owner questions, copied live-exam content, or exam dumps.

Current alignment Aligned to the relevant syllabus, exam elements, competency areas, and topic weights where they are available.

Practice modes Use topic drills, timed mocks, scenario questions, and focused review before deeper mixed practice.

Teaching explanations Explanations show the client, product, compliance, or calculation rule that makes the best answer defensible.

Stable bank Questions are prebuilt and reviewed before publication, so practice is stable and inspectable, not improvised during a quiz.

Study Plan