Receber por email
← Voltar para o catálogo

soc2-readiness

Assess SOC 2 Type II readiness. Map Trust Services Criteria to controls, identify gaps, and build a remediation plan. Uses NIST SP 800-53 (public domain) as canonical reference with SOC 2 criterion cross-mapping. Use when user says "SOC 2 readiness," "SOC 2 preparation," "SOC 2 gap analysis," or "prepare for SOC 2 audit."

37estrelas
Atualizado há 4 meses

Ver no GitHub ↗ Licença: MIT

Como adicionar

/plugin marketplace add open-agreements/open-agreements

O comando exato pode variar conforme o repositório. Confira o README no GitHub.

Para o autor da skill

Cole no README do seu repo

Mostra que sua skill está catalogada na Skillteca, gera backlink e tráfego rastreável.

[![Skillteca](https://www.skillteca.com.br/api/badge/soc2-readiness/svg)](https://www.skillteca.com.br/skills/soc2-readiness)

Skills relacionadas

Ver todas de Documentos →

Alerta por categoria

Receba novas skills de Documentos toda segunda

1 email curto, só com as skills novas de Documentos. 4 minutos de leitura, sem spam, cancela com 1 clique.

Você confirma o email no primeiro envio. Sem spam. Cancela com 1 clique.

Ler descrição completa

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:

| Category | Criteria | When Required | |----------|----------|---------------| | Security (CC) | CC 1-9 (33 criteria) | Always required | | Availability (A) | A 1.1-1.3 (3 criteria) | SaaS with uptime SLAs | | Processing Integrity (PI) | PI 1.1-1.5 (4 criteria) | Data processing services | | Confidentiality (C) | C 1.1-1.2 (2 criteria) | Handling confidential data | | Privacy (P) | P 4-8 (7 criteria) | PII processing |

SOC 2 vs. ISO 27001

| Dimension | SOC 2 | ISO 27001 | |-----------|-------|-----------| | Governing body | AICPA | ISO/IEC | | Geography | Primarily US/Canada | Global | | Type | Attestation report by CPA | Certification by audit body | | Scope | Service-specific | Organization-wide ISMS | | Controls | Flexible (you define) | 93 Annex A controls | | Output | SOC 2 report (restricted/general use) | Certificate | | Overlap | ~70% overlap with ISO 27001 Annex A | ~70% overlap with SOC 2 CC |

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

| Criterion | Focus | NIST Controls | ISO Cross-Reference | |-----------|-------|---------------|---------------------| | CC 1.1 | Integrity and ethics | PS-1, PS-3, PS-6 | A.6.1, A.6.2, A.6.4 | | CC 1.2 | Board oversight | PM-1, PM-2 | C.5.1, C.5.3 | | CC 1.3 | Organizational structure | PM-2 | C.5.3 | | CC 1.4 | Competence commitment | AT-2, PS-3 | A.6.1, A.6.3 | | CC 1.5 | Accountability | PS-3, PS-4 | A.6.4, A.6.5 |

CC 2 — Communication and Information

| Criterion | Focus | NIST Controls | ISO Cross-Reference | |-----------|-------|---------------|---------------------| | CC 2.1 | Internal information | AU-2, SI-5 | C.7.5.1 | | CC 2.2 | Internal communication | PM-2, AT-2 | C.7.4, A.6.3 | | CC 2.3 | External communication | PM-1 | A.5.14 |

CC 3 — Risk Assessment

| Criterion | Focus | NIST Controls | ISO Cross-Reference | |-----------|-------|---------------|---------------------| | CC 3.1 | Risk objectives | PM-9, RA-1 | C.6.1.1 | | CC 3.2 | Risk identification | RA-3 | C.6.1.2, C.8.2 | | CC 3.3 | Fraud risk | RA-3 | C.6.1.2 | | CC 3.4 | Change impact | RA-3, CM-4 | C.6.1.2, A.8.9 |

CC 4 — Monitoring Activities

| Criterion | Focus | NIST Controls | ISO Cross-Reference | |-----------|-------|---------------|---------------------| | CC 4.1 | Ongoing monitoring | CA-7, PM-6 | C.9.1 | | CC 4.2 | Deficiency evaluation | CA-2 | C.9.2.1 |

CC 5 — Control Activities

| Criterion | Focus | NIST Controls | ISO Cross-Reference | |-----------|-------|---------------|---------------------| | CC 5.1 | Risk mitigation | AC-5 | A.5.3 | | CC 5.2 | Technology controls | AC-1, IA-2 | A.5.15, A.8.5 | | CC 5.3 | Policy deployment | PM-1, PL-1 | A.5.1, C.5.2 |

CC 6 — Logical and Physical Access

| Criterion | Focus | NIST Controls | ISO Cross-Reference | |-----------|-------|---------------|---------------------| | CC 6.1 | Access control | AC-2, AC-3, IA-2, SC-28 | A.5.15, A.8.5, A.8.24 | | CC 6.2 | Access provisioning | AC-2, PS-4, PS-5 | A.5.18, A.6.5 | | CC 6.3 | Access modification | AC-2, AC-6 | A.5.15, A.5.18 | | CC 6.4 | Physical access | PE-2, PE-3, PE-6 | A.7.2, A.7.4 | | CC 6.5 | Asset disposal | MP-6 | A.7.10, A.7.14 | | CC 6.6 | Threat detection | RA-5, SI-4 | A.8.8, A.8.16 | | CC 6.7 | Transmission security | SC-8 | A.5.14, A.8.24 | | CC 6.8 | Malware prevention | SI-2, SI-3 | A.8.7, A.8.19 |

CC 7 — System Operations

| Criterion | Focus | NIST Controls | ISO Cross-Reference | |-----------|-------|---------------|---------------------| | CC 7.1 | Operational monitoring | CM-6, RA-5 | A.8.9, A.8.8 | | CC 7.2 | Anomaly detection | AU-6, SI-4 | A.8.15, A.8.16 | | CC 7.3 | Incident response | IR-4 | A.5.24, A.5.25 | | CC 7.4 | Incident management | IR-5, IR-6 | A.5.25, A.5.26 | | CC 7.5 | Recovery | CP-4, CP-9, CP-10 | A.5.30, A.8.13 |

CC 8 — Change Management

| Criterion | Focus | NIST Controls | ISO Cross-Reference | |-----------|-------|---------------|---------------------| | CC 8.1 | Change control | CM-3, CM-5, SA-3 | A.8.9, A.8.25, A.8.32 |

CC 9 — Risk Mitigation

| Criterion | Focus | NIST Controls | ISO Cross-Reference | |-----------|-------|---------------|---------------------| | CC 9.1 | Risk mitigation | CP-2, RA-7 | A.5.30, C.6.1.3 | | CC 9.2 | Vendor management | AC-20, SA-9 | A.5.19, A.5.22 |

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
Compartilhar X LinkedIn