--- name: cumplimiento-soc2-ed92 description: Guía completa para alcanzar la certificación SOC 2 Type II en productos SaaS B2B: criterios de confianza, controles requeridos, recogida de evidencias y herramientas de automatización como Vanta o Drata. Incluye plantillas de políticas, código de ejemplo y cronograma de auditoría. license: Apache-2.0 metadata: id: ed922864 slug: cumplimiento-soc2-ed92 titulo: "Cumplimiento SOC 2 para SaaS" servicio: Consultoria-Estrategia categoria_recurso: Legal-Licencias tipo: referencia nivel: intermedio idioma: es idioma_original: en acceso: gratis precio_eur: 0 plataformas: [AWS, GCP, Azure, GitHub, Vanta, Drata, Secureframe] dependencias: [Python, Node.js, boto3] licencia: { spdx: Apache-2.0, redistribuible: true, uso_comercial: true } fuente: repo: TerminalSkills/skills url: https://github.com/TerminalSkills/skills/tree/main/skills/soc2-compliance commit: 77fa015 autor: TerminalSkills nombre_original: soc2-compliance duplicados_en: [] seguridad: { veredicto: seguro, riesgo: bajo, escaneado: "2026-06-14", motor: "grep-estatico+auditor-llm" } ficha: que_hace: "Proporciona un marco de referencia estructurado para implementar y auditar los controles SOC 2 Type II en una empresa SaaS." como_lo_hace: "Documenta los nueve criterios de control comunes (CC1-CC9), ejemplos de código para MFA y revisiones de acceso, tablas de evidencias requeridas y checklist de cumplimiento." content_hash: "ed922864ff0017b5b18a811c9b635908b289ff87d9f66f79c8d6730ed7bbe759" version: 1.0.0 --- # SOC 2 Compliance ## Overview SOC 2 (System and Organization Controls 2) is an auditing standard developed by the AICPA for service organizations. A SOC 2 Type II report covers a period of 6-12 months, demonstrating controls are operating effectively — not just designed. Enterprise buyers almost universally require SOC 2 before signing contracts. ## Trust Service Criteria (TSC) | Criteria | Abbrev | Required? | Description | |----------|--------|-----------|-------------| | Security | CC | ✅ Always | Protection against unauthorized access | | Availability | A | Optional | System available for operation and use | | Confidentiality | C | Optional | Information designated as confidential is protected | | Processing Integrity | PI | Optional | Processing is complete, valid, accurate, timely | | Privacy | P | Optional | Personal information collected, used, retained, disclosed properly | Most SaaS companies start with **Security + Availability**. Add Confidentiality if handling sensitive data; add Privacy if handling personal data covered by GDPR/CCPA. ## Common Controls Framework (CC) ### CC1 — Control Environment - Written security policies reviewed annually - Code of conduct acknowledged by all staff - Org chart with clear security accountability ### CC2 — Communication and Information - Security policies communicated to all personnel - Vendor risk assessments documented - Security awareness training records ### CC3 — Risk Assessment ```markdown Risk Register entry: - Risk ID: RISK-001 - Title: Unauthorized database access - Likelihood: Medium - Impact: High - Inherent Risk: High - Controls: MFA, network segmentation, IAM least-privilege - Residual Risk: Low - Owner: CTO - Review Date: 2025-01-15 ``` ### CC4 — Monitoring Activities - Automated vulnerability scanning (weekly minimum) - Quarterly access reviews - Intrusion detection alerts reviewed daily ### CC5 — Control Activities - Change management process with peer review - Incident response plan tested annually - Penetration testing annually ### CC6 — Logical and Physical Access Controls **MFA enforcement (Node.js example):** ```javascript // Enforce MFA for all admin users const requireMFA = async (req, res, next) => { const user = req.user; if (user.role === 'admin' && !user.mfaVerified) { return res.status(403).json({ error: 'MFA required for admin access', code: 'MFA_REQUIRED' }); } next(); }; // Log all authentication events for CC6 evidence const logAuthEvent = async (userId, event, success, ipAddress) => { await db.auditLog.create({ userId, event, // 'login' | 'logout' | 'mfa_verify' | 'password_reset' success, ipAddress, userAgent: req.headers['user-agent'], timestamp: new Date().toISOString() }); }; ``` **Access review automation:** ```python import boto3 from datetime import datetime, timedelta def generate_access_review_report(): """Generate quarterly access review evidence for CC6.""" iam = boto3.client('iam') report = [] users = iam.list_users()['Users'] for user in users: # Check last activity login_profile = None try: login_profile = iam.get_login_profile(UserName=user['UserName']) except iam.exceptions.NoSuchEntityException: pass groups = iam.list_groups_for_user(UserName=user['UserName']) policies = iam.list_attached_user_policies(UserName=user['UserName']) report.append({ "user": user['UserName'], "created": user['CreateDate'].isoformat(), "groups": [g['GroupName'] for g in groups['Groups']], "policies": [p['PolicyName'] for p in policies['AttachedPolicies']], "has_console_access": login_profile is not None, "review_date": datetime.utcnow().isoformat(), "reviewed_by": "security-team" }) return report ``` ### CC7 — System Operations - Infrastructure monitoring with alerts - Log aggregation and anomaly detection - Capacity planning reviews ### CC8 — Change Management **Git-based change management:** ```bash # All changes via PR (enforced in GitHub branch protection) # - Required reviewers: 2 # - Required CI checks: tests, security scan, lint # - No direct pushes to main # Deployment approval record (for audit evidence) cat deployment-log.json # { # "deploy_id": "deploy-2024-0115-001", # "author": "alice@company.com", # "reviewer": "bob@company.com", # "approved_at": "2024-01-15T14:30:00Z", # "deployed_at": "2024-01-15T14:45:00Z", # "changes": "JIRA-123: Add MFA to admin panel", # "rollback_plan": "Revert commit abc123" # } ``` ### CC9 — Risk Mitigation - Vendor management program - Business continuity plan - Cyber insurance ## Evidence Collection SOC 2 auditors need **evidence** that controls operated continuously during the audit period. | Control | Evidence Type | Frequency | Storage | |---------|--------------|-----------|---------| | MFA enabled | Screenshot + IAM export | Quarterly | Vanta/Drata | | Access reviews | Signed review records | Quarterly | Google Drive | | Vulnerability scans | Scan reports | Weekly | S3/Drive | | Pen test | Report + remediation | Annual | Drive | | Security training | Completion certificates | Annual | HRIS | | Incident response test | Tabletop exercise notes | Annual | Drive | | Encryption at rest | Config screenshot | Change-based | Drive | | Backup tested | Restore test log | Quarterly | Drive | ## Automation Tools ### Vanta (recommended for startups) ```bash # Vanta connects to your cloud accounts and auto-collects evidence # Integrations: AWS, GCP, Azure, GitHub, Okta, Google Workspace, Slack # After connecting, Vanta auto-monitors: # - MFA enforcement (CC6.1) # - Encryption at rest (CC6.7) # - Vulnerability scanning (CC7.1) # - Background checks (CC1.1) # - Access reviews (CC6.2) ``` ### Drata / Secureframe Both offer similar automation: continuous control monitoring + auditor portal for evidence sharing. Drata is strong on integrations; Secureframe has a good self-service audit experience. ## Key Policies to Write Create these written policies (stored in a policy management system): ```markdown Required Policies: 1. Information Security Policy 2. Access Control Policy 3. Encryption Policy 4. Incident Response Plan 5. Business Continuity / Disaster Recovery Plan 6. Vulnerability Management Policy 7. Change Management Policy 8. Vendor Management Policy 9. Acceptable Use Policy 10. Data Classification Policy ``` **Encryption Policy example snippet:** ```markdown ## Encryption Policy **Effective Date:** 2024-01-01 **Owner:** CTO **Review Cycle:** Annual ### Requirements - All data at rest classified as Confidential or Restricted MUST be encrypted using AES-256 or equivalent. - All data in transit MUST use TLS 1.2 or higher. - Encryption keys MUST be stored separately from encrypted data, in an approved key management system (AWS KMS, GCP KMS, or HashiCorp Vault). - Keys MUST be rotated annually or upon suspected compromise. ``` ## SOC 2 Timeline | Phase | Duration | Activities | |-------|----------|-----------| | Readiness assessment | 4-6 weeks | Gap analysis, policy writing | | Remediation | 2-4 months | Implement controls, fix gaps | | Evidence collection period (Type II) | 6-12 months | Run controls, collect evidence | | Auditor fieldwork | 4-8 weeks | Auditor reviews evidence | | Report issuance | 2-4 weeks | Final report, management response | **Total Type II timeline: ~12-18 months from start to report.** ## Compliance Checklist - [ ] Scope defined (which systems handle customer data) - [ ] Auditor selected (AICPA-licensed CPA firm) - [ ] Security policies written and approved - [ ] MFA enforced for all users - [ ] Encryption at rest and in transit enabled - [ ] Vulnerability scanning automated - [ ] Access review process established - [ ] Change management process documented - [ ] Incident response plan written and tested - [ ] Vendor risk assessments completed - [ ] Background checks for employees - [ ] Security awareness training completed - [ ] Evidence collection tool in place (Vanta/Drata/Secureframe)