SOC 2 Readiness Assessment

Assess readiness for a SOC 2 Type II audit. This skill walks through the Trust Services Criteria, identifies gaps, maps to NIST controls, and generates a prioritized remediation plan.

Security Model

• No scripts executed — markdown-only procedural guidance
• No secrets required — works with reference checklists
• IP-clean — AICPA Trust Services Criteria are publicly cited; descriptions are original writing
• Evidence stays local — all collection outputs go to local filesystem

When to Use

Activate this skill when:

1. First SOC 2 preparation — building controls from scratch for initial Type I or Type II
2. Pre-audit readiness check — 4-8 weeks before audit window opens
3. Gap analysis after scope change — new systems, services, or trust criteria added
4. Remediation planning — translating audit findings into actionable work items
5. Dual-framework mapping — already pursuing ISO 27001 and need SOC 2 overlap analysis

Do NOT use for:

• ISO 27001 internal audit — use iso-27001-internal-audit
• Evidence collection mechanics — use iso-27001-evidence-collection
• Contract review — use legal agreement skills

Core Concepts

Trust Services Criteria (TSC)

SOC 2 is organized around 5 Trust Services Categories. Security (CC) is always in scope; others are optional based on your service:

SOC 2 vs. ISO 27001

Decision Tree: Scope Selection

What service are you getting audited on?
├── SaaS product → Security + Availability (+ Confidentiality if you handle sensitive data)
├── Data processing → Security + Processing Integrity + Confidentiality
├── Infrastructure → Security + Availability
├── API service → Security (+ PI if you transform data)
│
Do you handle PII?
├── YES → Add Privacy category
├── NO → Skip Privacy
│
Do you have uptime SLAs?
├── YES → Include Availability
├── NO → Optional (but customers expect it for SaaS)

Step-by-Step Workflow

Step 1: Define Scope and Categories

1. Identify the service being audited (product name, description, boundaries)
2. Select Trust Services Categories using the decision tree above
3. Define system boundaries: infrastructure, software, people, procedures, data
4. Document sub-service organizations (cloud providers, payment processors, etc.)
5. Determine audit type: Type I (point-in-time) or Type II (period of time, usually 6-12 months)

Step 2: Assess Current State

For each applicable Common Criterion (CC), assess whether controls are:

• Designed — control exists on paper
• Implemented — control is operating
• Effective — control achieves its objective (evidence exists)

# If Internal ISO Audit MCP server is available (SOC 2 maps to ISO 27001 Annex A):
list_controls(domain="technological")                       # List tech controls (maps to CC 6-8)
get_control_guidance(control_id="A.5.15")                   # Get guidance for ISO control mapped from CC 6.1
get_nist_mapping(control_id="AC-2", direction="nist_to_iso")  # Find ISO controls from NIST reference
search_guidance(query="incident response")                  # Search for controls matching SOC 2 criteria

Step 3: Map Controls to Criteria

Each CC maps to specific NIST controls. Use this mapping to identify what you need:

CC 1 — Control Environment

CC 2 — Communication and Information

CC 3 — Risk Assessment

CC 4 — Monitoring Activities

CC 5 — Control Activities

CC 6 — Logical and Physical Access

CC 7 — System Operations

CC 8 — Change Management

CC 9 — Risk Mitigation

Step 4: Generate Gap Analysis

For each criterion, document:

## Gap: [CC x.x] — [Brief description]

**Current State**: [What exists today]
**Required State**: [What the auditor expects]
**Gap**: [What's missing]
**Remediation**:
1. [Specific action item]
2. [Specific action item]
**Priority**: Critical / High / Medium / Low
**Effort**: [Days/weeks to remediate]
**Owner**: [Person respon