Cumplimiento SOC 2 — Básicos para Equipos de Ingeniería

Visión General

SOC 2 (Service Organization Control 2) es un marco de auditoría desarrollado por el AICPA que evalúa cómo las organizaciones de servicios gestionan los datos de los clientes. A diferencia de las listas de verificación de cumplimiento, SOC 2 Tipo II requiere demostrar que tus controles operan efectivamente a lo largo del tiempo. Para equipos de ingeniería, esto significa construir sistemas con seguridad, disponibilidad, integridad del procesamiento, confidencialidad y privacidad — y probar que funcionan mediante evidencias.

Cuándo Usar

• Tu organización necesita un informe SOC 2 para vender a clientes empresariales
• Estás diseñando sistemas que serán auditados
• Necesitas implementar controles de seguridad que satisfagan a los auditores
• Quieres alinear las prácticas de ingeniería con criterios de confianza de la industria

Criterios de Servicios de Confianza

SOC 2 evalúa cinco categorías. La mayoría de las startups comienzan con Seguridad (Criterios Comunes).

Criterio	Enfoque	Acciones del Desarrollador
Seguridad (CC)	El sistema está protegido contra acceso no autorizado	IAM, cifrado, logging, pruebas de penetración
Disponibilidad	El sistema está operativo y accesible	Monitoreo de uptime, recuperación ante desastres, planificación de capacidad
Integridad del Procesamiento	El procesamiento de datos es completo, válido y preciso	Validación de entradas, reconciliación, manejo de errores
Confidencialidad	Los datos designados están protegidos	Cifrado, controles de acceso, clasificación de datos
Privacidad	La información personal se maneja según el aviso de privacidad	Gestión de consentimientos, retención de datos, derechos del sujeto

Construcción de Sistemas Conformes

Controles de Acceso (CC6)

Implementa control de acceso basado en roles con mínimo privilegio y revisiones regulares.

# Exigir MFA para acceso a producción
@mfa_required
def deploy_to_production(user, artifact):
    if not user.has_role("production_deployer"):
        raise Forbidden("Privilegios insuficientes")
    
    audit_log.record(
        actor=user.id,
        action="deploy",
        resource=artifact.id,
        timestamp=datetime.utcnow()
    )
    
    return deploy(artifact)

Operaciones del Sistema (CC7)

Monitorea, detecta y responde a eventos de seguridad.

# Detección automatizada de anomalías
def monitor_privilege_escalation():
    for event in auth_logs.recent(hours=24):
        if event.action == "role_change" and event.new_role == "admin":
            if event.old_role != "admin":
                alert_security_team(
                    f"Escalamiento de privilegios: {event.user_id} a admin"
                )

Gestión de Cambios (CC8)

Todos los cambios a producción deben estar autorizados, probados y documentados.

# GitHub Actions: requerir aprobación para producción
name: Deploy to Production
on:
  workflow_dispatch:
    inputs:
      approved_by:
        required: true
        description: "Aprobador del equipo de seguridad"

jobs:
  deploy:
    environment: production  # Requiere aprobación manual
    steps:
      - uses: actions/checkout@v4
      - run: ./scripts/verify-change-ticket.sh ${{ github.sha }}
      - run: ./scripts/deploy.sh production

Mitigación de Riesgos (CC9)

Identifica, evalúa y mitiga riesgos para el sistema.

# Pipeline de gestión de vulnerabilidades
def vulnerability_scan():
    results = {
        "dependency_check": run_snyk(),
        "container_scan": run_trivy(),
        "secrets_scan": run_trufflehog(),
    }
    
    for tool, findings in results.items():
        for finding in findings.critical:
            create_jira_ticket(
                summary=f"[CRITICAL] {finding.title}",
                assignee="security-team",
                due_date=now() + timedelta(days=1)
            )

Recolección de Evidencias

Los auditores necesitan prueba de que los controles están operando. Automatiza las evidencias donde sea posible.

Control	Tipo de Evidencia	Automatización
Revisiones de acceso	Informes trimestrales de acceso de usuarios	Exportar desde IAM; comparar con trimestre anterior
Pruebas de penetración	Informe de prueba de terceros	Programar anualmente; rastrear hallazgos hasta su cierre
Restauración de copias	Prueba mensual de restauración	Prueba automatizada con registro de éxito/fracaso
Revisión de código	Rastro de auditoría de aprobaciones de PR	Exportar de API de GitHub las aprobaciones y rechazos
Respuesta a incidentes	Documentos de postmortem	Basados en plantilla; rastrear tiempo de resolución

Monitoreo del Sistema

# Logging de auditoría centralizado
class AuditEvent(BaseModel):
    timestamp: datetime
    actor: str
    action: str
    resource: str
    result: str  # success / denied / error
    ip_address: str
    user_agent: str
    correlation_id: str

def log_audit_event(event: AuditEvent):
    # Escribir en almacenamiento de logs resistente a alteraciones
    audit_store.append(event.json())
    
    # Alertar sobre patrones sospechosos
    if event.result == "denied" and event.action == "admin_access":
        alert_security_team(f"Acceso admin denegado: {event.actor}")

Gestión de Proveedores

SOC 2 requiere diligencia debida en proveedores de terceros.

Lista de Verificación de Integración de Proveedor:
- [ ] Revisar informe SOC 2 del proveedor (preferiblemente Tipo II)
- [ ] Documentar datos compartidos con el proveedor
- [ ] Firmar DPA (Acuerdo de Procesamiento de Datos)
- [ ] Verificar cifrado en tránsito y en reposo
- [ ] Confirmar SLA de notificación de incidentes
- [ ] Programar revisión anual

Errores Comunes

• Tratar SOC 2 como un proyecto único — es continuo; los auditores revisan 3-12 meses de evidencias
• Depender de capturas de pantalla manuales para evidencias — automatiza la recolección donde sea posible
• No tener plan de respuesta a incidentes — los auditores preguntarán cómo manejaste incidentes pasados
• Ignorar la baja de empleados — ex empleados con acceso persistente es un hallazgo común
• Faltar gestión de cambios para infraestructura — los cambios de Terraform también necesitan aprobación y rastro de auditoría

FAQ

Cuánto tiempo toma SOC 2 Tipo II? Típicamente 3-6 meses de preparación, luego un período de observación de 3-12 meses antes de que se emita el informe de auditoría.

Cuál es la diferencia entre Tipo I y Tipo II? Tipo I evalúa los controles en un punto en el tiempo. Tipo II evalúa los controles a lo largo de un período (usualmente 3-12 meses) y requiere evidencia de operación continua.

Necesito una auditoría separada para cada cliente? No. Un único informe SOC 2 puede compartirse con todos los clientes, aunque algunos pueden solicitar cuestionarios suplementarios.