This independent Quick Reference 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.
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 Quick Reference
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 |
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 |
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 |
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 |
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 |
SOC Reporting Quick Reference
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 |
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 |
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 |
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 |
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 |
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 |
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 |
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.
Practical Next Step
Use this Quick Reference to build short mixed practice sets: one SOC scenario, one access-control scenario, one change-management scenario, one data-governance scenario, and one continuity/cybersecurity scenario. For each question, force yourself to identify the risk, the best control, the evidence needed, and the common trap before reviewing the answer.