ISC cheat sheet & quick reference
ISC is light on math and heavy on frameworks, so this sheet gathers the comparison tables that keep coming up: SOC reports, trust services criteria, access and encryption models, controls, recovery objectives, and the incident response lifecycle. Memorize the distinctions and most questions resolve themselves.
1. SOC report types: SOC 1 vs SOC 2 vs SOC 3 (Topic I11)
| Feature | SOC 1 | SOC 2 | SOC 3 |
|---|---|---|---|
| Subject matter | Controls relevant to user ICFR | Controls meeting trust services criteria | Controls meeting trust services criteria |
| Standard | AT-C 320 (SSAE 18) | AT-C 105 and 205 + TSC | AT-C 105 and 205 + TSC |
| Intended users | User entities and their auditors | Management, regulators, knowledgeable partners | General public / anyone |
| Use restriction | Restricted | Generally restricted | General use (no restriction) |
| Type 1 / Type 2 | Both available | Both available | Type 2 nature only |
SOC 1 is about financial reporting; SOC 2 and SOC 3 are about the trust services criteria. SOC 3 is the only general-use report of the three, so it is the one you can post publicly on a website.
2. Type 1 vs Type 2, carve-out vs inclusive, CUECs (Topic I11)
| Dimension | Type 1 | Type 2 |
|---|---|---|
| Period covered | A point in time (single date) | A period of time (e.g., 6 to 12 months) |
| Design of controls | Evaluated | Evaluated |
| Operating effectiveness | Not evaluated | Evaluated |
| Tests of controls and results | Not included | Included |
- Carve-out method: the subservice organization’s controls are excluded from the description and the service auditor’s testing, but its existence and the controls it is expected to provide are still disclosed. This is the more common method.
- Inclusive method: the subservice organization’s relevant controls ARE included in the description, management’s assertion, and the service auditor’s testing and opinion.
Complementary user entity controls (CUECs) are controls the service organization assumes the user entity performs. They are described in the report but NOT tested by the service auditor; the user entity and its auditor must confirm they exist.
3. Trust services criteria & SOC 2 report components (Topic I12)
| Category | Core question it answers | Required? |
|---|---|---|
| Security (common criteria) | Is the system protected against unauthorized access, disclosure, and damage? | Always required |
| Availability | Is the system available for operation and use as committed? | Optional |
| Processing Integrity | Is processing complete, valid, accurate, timely, and authorized? | Optional |
| Confidentiality | Is information designated confidential protected as committed? | Optional |
| Privacy | Is personal information handled per the privacy notice and criteria? | Optional |
Security is the only mandatory category, you cannot issue a SOC 2 without it. Confidentiality covers any data designated confidential; Privacy deals exclusively with personal information.
| SOC 2 component | Responsible party | In Type 1? | In Type 2? |
|---|---|---|---|
| Description of the system | Management | Yes | Yes |
| Written assertion | Management | Yes | Yes |
| Service auditor’s report (opinion) | Service auditor | Yes | Yes |
| Tests of controls and results | Service auditor | No | Yes |
4. SOC opinion types & triggers (Topic I13)
| Opinion | When issued | Severity |
|---|---|---|
| Unqualified (unmodified) | Description fair, controls suitably designed and (Type 2) operating effectively; no material exceptions | Clean |
| Qualified | A material but not pervasive problem (e.g., one control or objective fails) | Material, isolated |
| Adverse | Problems are material AND pervasive (broad control failure or materially misstated description) | Material, pervasive |
| Disclaimer | Auditor cannot obtain sufficient evidence; possible effects material and pervasive | Cannot conclude |
A disclaimer stems from a scope limitation (the auditor cannot get evidence), NOT from a control that simply failed. A failed control points to qualified (isolated) or adverse (pervasive). Management owns the description and assertion; the service auditor owns the opinion and the tests and results.
5. CIA triad & defense in depth (Topic I6)
| Goal | Threat to it | Example control |
|---|---|---|
| Confidentiality | Unauthorized disclosure | Encryption, access controls |
| Integrity | Unauthorized or accidental alteration | Hashing, file-integrity monitoring |
| Availability | Outage, denial of service | Backups, redundancy, failover |
- Defense in depth: layer independent, overlapping controls (physical, network, host, application, data) so the failure of any one does not expose the asset. It is not one very strong control.
- Least privilege: grant each user or process only the minimum access needed, which limits the blast radius of a compromised or misused account.
6. NIST CSF functions in order (Topic I6)
| Function | Purpose | Example activity |
|---|---|---|
| 1. Identify | Understand assets and risk | Asset inventory, risk assessment |
| 2. Protect | Implement safeguards | Access controls, encryption, training |
| 3. Detect | Spot security events | SIEM, intrusion detection, log review |
| 4. Respond | Act on incidents | Containment, communication |
| 5. Recover | Restore operations | Backups, recovery planning |
Memorize the order: Identify → Protect → Detect → Respond → Recover. Protect comes before Detect, and Detect comes before Respond.
7. Access control models & authentication (Topic I7)
| Factor category | Description | Example |
|---|---|---|
| Something you know | Knowledge held by the user | Password, PIN |
| Something you have | A physical or digital token | Smart card, phone authenticator |
| Something you are | A biometric trait | Fingerprint, facial recognition |
MFA requires two or more factors from DIFFERENT categories. A password plus a security question is still single-factor (both are something you know). Authentication (who you are) always comes before authorization (what you may do).
- RBAC (Role-Based): permissions are assigned to roles, and users inherit access by job role. Scales well in business.
- MAC (Mandatory): access is enforced by system-wide security labels that users cannot change. Fits classified, clearance-driven environments.
- DAC (Discretionary): the resource owner decides who may access it. Flexible but relies on owner judgment.
8. Encryption: symmetric, asymmetric, hashing, PKI (Topic I7)
| Technique | Keys | Primary use |
|---|---|---|
| Symmetric | One shared key | Fast bulk encryption |
| Asymmetric | Public/private key pair | Key exchange, digital signatures |
| Hashing | No key (one-way) | Integrity verification, password storage |
Hashing is not encryption, it is one-way and cannot be reversed to reveal the original, so never pick it as a way to keep data confidential and recoverable. PKI issues digital certificates that bind a public key to a verified identity, enabling trusted asymmetric encryption.
9. ITGCs vs application controls (Topic I3)
IT general controls (ITGCs) are pervasive controls over the whole environment, in four categories: access security, change management, IT operations (job scheduling, monitoring, backup), and systems development. Application controls sit inside one application and split into input, processing, and output.
| Category | Purpose | Examples |
|---|---|---|
| Input controls | Validate data entering the system | Field, limit, range, validity, completeness checks; check digit |
| Processing controls | Ensure complete and accurate processing | Batch totals, hash totals, run-to-run totals, record counts |
| Output controls | Ensure accurate, complete, authorized output | Output-to-input reconciliation, distribution controls, exception reports |
Automated application controls can be relied upon ONLY when the underlying ITGCs, especially change management and access, are effective. Weak general controls mean the application control could be altered or bypassed without detection.
10. SDLC & system conversion approaches (Topic I2)
SDLC phases:
Planning → analysis (requirements) → design → development (coding) → testing → implementation (conversion and go-live) → maintenance
| Approach | How it works | Risk | Cost |
|---|---|---|---|
| Parallel | Old and new run together; results compared | Lowest | Highest |
| Pilot | Deploy to one site or group first, then roll out | Lower | Moderate |
| Phased | Implement in stages or modules over time | Lower | Moderate |
| Direct (big-bang) | Switch off old, turn on new at once | Highest | Lowest |
Parallel is safest but priciest; direct cutover is cheapest but riskiest with no fallback. Every change must be tested off production and deployed by someone OTHER than the developer.
11. Business resilience: RTO, RPO & recovery sites (Topic I5)
RTO (recovery time objective): the maximum acceptable downtime, that is, how long the business can be down. A short RTO points to a hot site.
RPO (recovery point objective): the maximum acceptable data loss measured in time. It drives backup frequency, a short RPO needs frequent backups or continuous replication.
| Site type | Readiness | Recovery time | Cost |
|---|---|---|---|
| Hot site | Fully equipped, near-real-time data | Shortest | Highest |
| Warm site | Hardware and connectivity; data must be loaded | Moderate | Moderate |
| Cold site | Space and utilities only | Longest | Lowest |
- Full backup: copies all data. Simplest to restore.
- Incremental backup: copies changes since the last backup of any kind. Restore needs the full plus ALL incrementals.
- Differential backup: copies changes since the last full backup. Restore needs only the full plus the LATEST differential.
- BCP vs DRP: the business continuity plan keeps the whole business operating; the disaster recovery plan is the IT-focused subset that restores systems and data.
12. Incident response lifecycle & monitoring (Topic I10)
| Phase | Goal | Example action |
|---|---|---|
| 1. Preparation | Be ready before incidents | Plans, tools, training |
| 2. Detection and Analysis | Identify and scope the incident | Investigate alerts |
| 3. Containment | Limit spread and damage | Isolate affected systems |
| 4. Eradication | Remove the root cause | Delete malware, patch entry point |
| 5. Recovery | Restore normal operations | Rebuild and restore from backup |
| 6. Lessons Learned | Improve for the future | Post-incident review |
Containment must precede eradication and recovery. Restoring systems before removing the cause invites reinfection.
| Attribute | IDS | IPS |
|---|---|---|
| Action | Alerts only (passive) | Blocks traffic (active) |
| Placement | Out of band, monitors a copy | Inline, in the traffic path |
| Risk if it fails | Missed alert | Can disrupt legitimate traffic |
13. Threats quick reference (Topic I8)
Threat: a potential cause of harm (a hacker, a flood).
Vulnerability: a weakness a threat can exploit (an unpatched server).
Risk: likelihood that a threat exploits a vulnerability, times the resulting impact.
| Malware | Defining trait | Primary harm |
|---|---|---|
| Virus | Attaches to a file; needs a user to run it | Corruption, spread |
| Worm | Self-replicates across networks | Rapid spread, congestion |
| Ransomware | Encrypts data, demands payment | Loss of availability, extortion |
| Trojan | Disguised as legitimate software | Hidden backdoor, theft |
| Spyware | Secretly collects information | Loss of confidentiality |
| Attribute | Vulnerability scanning | Penetration testing |
|---|---|---|
| Approach | Automated, broad | Often manual, deep |
| Exploitation | Identifies but does not exploit | Actually attempts exploitation |
| Frequency | Frequent (e.g., weekly) | Periodic (e.g., quarterly or annual) |
A threat is the attacker; a vulnerability is the weakness, do not swap them. Scanning finds known weaknesses; penetration testing proves whether they can actually be exploited.
Keep studying
This cheat sheet pairs best with active practice. Jump into the ISC study guide, and grab the sibling cheat sheets for the other sections below.