Cumplimiento SOC 2 para Equipos de Ingeniería

Visión General

El trato está cerrado en principio, el departamento de compras ya terminó, y entonces el equipo de seguridad del cliente envía un cuestionario de 300 líneas. Pregunta 12: “Adjunta tu informe SOC 2 Tipo II más reciente”. Si no tienes uno, el trato se congela durante meses, o muere en silencio. Ese es el momento en que la mayoría de los equipos de ingeniería conoce SOC 2 por primera vez, y es el peor momento para empezar a prepararse.

SOC 2 (Service Organization Control 2) es un informe de atestación emitido por una firma independiente de contadores públicos bajo los Trust Services Criteria del AICPA. Le dice a los clientes que un auditor verificó tus controles de seguridad, disponibilidad, integridad de procesamiento, confidencialidad y privacidad; no solo que escribiste políticas, sino que los controles realmente funcionaron durante varios meses. Para los equipos de ingeniería, SOC 2 es sobre todo un problema de construcción e instrumentación: los sistemas que publicas tienen que producir evidencia como subproducto de funcionar.

Lo que sigue: qué evalúa un auditor, cómo delimitar una primera auditoría, cómo construir controles que generen su propia evidencia, cuánto cuesta el proceso y dónde suelen perder tiempo los equipos.

Cuándo Usar

• Tu equipo de ventas necesita un informe SOC 2 para cerrar clientes empresariales o de sectores regulados.
• Procesas datos de clientes como encargado o subencargado del tratamiento y los contratos siguen pidiendo garantías de un tercero independiente.
• Estás diseñando sistemas que serán auditados más adelante y quieres controles integrados desde el diseño en lugar de añadidos a posteriori.
• Estás pasando de “somos seguros, confía en nosotros” a “aquí tienes un informe de un tercero”.

Probablemente todavía no necesitas SOC 2 si estás antes del ajuste producto-mercado, vendes a consumidores o tus clientes nunca lo piden. Un cuestionario de seguridad respondido con honestidad más una prueba de penetración cubre la mayoría de las objeciones en fase inicial, y pagar un SOC 2 antes de que exista la demanda es quemar presupuesto. Si lo que necesitas en realidad es encontrar brechas de control antes de comprometerte con una auditoría completa, empieza con un análisis de brechas; la plantilla de análisis de brechas de cumplimiento está pensada exactamente para ese paso.

Qué Evalúa Realmente SOC 2

Tipo I frente a Tipo II

	Tipo I	Tipo II
Qué demuestra	Que los controles están diseñados adecuadamente	Que los controles funcionaron eficazmente durante un período
Ventana de evidencia	Un único punto en el tiempo	Normalmente 3–12 meses
Coste y esfuerzo	Menor; semanas de preparación	Mayor; meses de evidencia operativa
Peso ante el cliente	Aceptado por algunos, a menudo como puente	El informe que piden las empresas

Un Tipo I sirve como paso intermedio: demuestra que terminaste de construir los controles. No es el estado final. Los clientes que dicen “SOC 2” casi siempre quieren decir Tipo II.

Los cinco Criterios de Servicios de Confianza

SOC 2 evalúa tu sistema frente a cinco categorías definidas en los Trust Services Criteria (TSC). Solo Seguridad es obligatoria: son los Criterios Comunes que incluye todo informe. Los otros cuatro se incluyen según lo que promete tu servicio.

Criterio	Enfoque	Qué significa para desarrolladores
Seguridad (CC)	Sistema protegido frente a acceso no autorizado	IAM, MFA, cifrado, registros, gestión de cambios
Disponibilidad (A1)	El sistema está operativo y accesible	Monitorización de uptime, planificación de capacidad, pruebas de recuperación ante desastres
Integridad de procesamiento (PI1)	El procesamiento es completo, válido y exacto	Validación de entradas, conciliación, manejo de errores, idempotencia
Confidencialidad (C1)	La información designada está protegida	Clasificación de datos, cifrado en reposo y en tránsito, límites de retención
Privacidad (P1–P8)	Datos personales tratados según tu aviso de privacidad	Consentimiento, límites de recolección, derechos de los titulares, eliminación

Una primera auditoría típica es Seguridad + Disponibilidad. La privacidad suele entrar en el alcance cuando las obligaciones de GDPR la hacen inevitable; si es tu caso, la guía de cumplimiento GDPR cubre los criterios de privacidad en profundidad.

Qué prueban realmente los auditores

Los auditores no leen tus políticas y se quedan con tu palabra. Para cada control dentro del alcance:

1. Inspeccionan el diseño: el control, tal como está escrito, ¿responde al criterio?
2. Muestrean la evidencia operativa: elegirán, por ejemplo, 25 de tus 52 revisiones semanales de accesos y pedirán pruebas de que cada una ocurrió, quedó documentada y fue revisada.
3. Preguntan y reejecutan: entrevistan a los responsables del control y a veces repiten el control por su cuenta.

Por eso “hacemos revisiones de accesos” suspende auditorías mientras que “aquí está el ticket, la aprobación del revisor y la diferencia de lo que cambió” las aprueba. El control solo es real si deja rastro.

Cómo Delimitar tu Primera Auditoría

Tres decisiones condicionan todo lo que viene después:

¿Qué criterios? Empieza con Seguridad. Añade Disponibilidad si tienes un SLA o las operaciones de tus clientes dependen de tu uptime. Añade Confidencialidad si los contratos lo exigen. Añadir criterios que aún no puedes evidenciar solo genera hallazgos.

¿Qué sistemas? El límite del sistema es lo que describes en la descripción del sistema del informe: infraestructura, aplicaciones, personas y procesos que entregan el servicio. Manténlo ajustado: tu SaaS de producción, no tu web de marketing. Cada sistema dentro del límite ve probados sus controles.

¿Qué período? La ventana de observación es el tramo de tiempo que muestrea el auditor. La mayoría de los que empiezan usan 3–6 meses para el primer Tipo II y después pasan a ventanas de 12 meses en las renovaciones anuales. Una ventana más larga da evidencia con aspecto más maduro, pero más meses hasta recibir el informe.

Los Criterios Comunes en la Práctica

El criterio de Seguridad se descompone en nueve familias de Criterios Comunes. Aquí es donde la auditoría se traduce a trabajo de ingeniería:

Criterio	Cubre	Controles de ingeniería típicos
CC1 Entorno de control	Tono de la dirección, estructura, competencia	Política de seguridad escrita, código de conducta, verificación de antecedentes en contratación
CC2 Comunicación e información	Las políticas llegan a quien las necesita	Wiki interna, formación anual de seguridad con registro de asistencia, canal de reporte de incidentes
CC3 Evaluación de riesgos	Identificar y analizar riesgos	Registro de riesgos trimestral, threat modeling en nuevas funcionalidades, revisiones de riesgo de proveedores
CC4 Actividades de monitorización	Evaluar si los controles siguen funcionando	Registro de auditoría inmutable, alertas de seguridad, revisiones trimestrales de accesos
CC5 Actividades de control	Los controles en sí	RBAC con mínimo privilegio, MFA en todo, PR con aprobación en cada cambio
CC6 Acceso lógico y físico	Quién puede llegar a qué	SSO + MFA, proceso de altas/cambios/bajas, baja de accesos en 24 h
CC7 Operaciones del sistema	Detectar y responder a anomalías	SLA de parches, cadencia de análisis de vulnerabilidades, plan de respuesta a incidentes
CC8 Gestión de cambios	Cambios autorizados, probados y documentados	CI/CD con puertas de aprobación, segregación de funciones, planes de rollback
CC9 Mitigación de riesgos	Mitigar los riesgos identificados	Plan de recuperación ante desastres, copias de seguridad probadas, continuidad de negocio

Fíjate en el patrón: casi cada línea es algo que un equipo de ingeniería sano ya hace de manera informal. La auditoría añade dos exigencias: el control está escrito y produce evidencia que otra persona puede verificar.

Construir Sistemas Conformes

Los cuatro controles siguientes son los que más pesan en una auditoría típica de SaaS: solo el acceso y la gestión de cambios concentran la mayor parte del muestreo. Constrúyelos de modo que la evidencia se escriba sola.

Controles de acceso (CC6)

Mínimo privilegio más un rastro revisable. En la práctica eso significa comprobaciones de rol en operaciones sensibles, MFA en todo lo que toca producción y un registro de auditoría en cada acción privilegiada. Si necesitas los detalles de implementación, la receta de RBAC recorre un modelo funcional.

# app/audit.py — registro de auditoría en acciones privilegiadas
from datetime import datetime, timezone
from functools import wraps
from flask import abort, g


def requires_role(role: str, action: str):
    def decorator(fn):
        @wraps(fn)
        def wrapper(*args, **kwargs):
            user = g.current_user
            if not user or not user.has_role(role):
                audit_log.record(
                    actor=getattr(user, "id", "anonymous"),
                    action=action,
                    result="denied",
                    timestamp=datetime.now(timezone.utc),
                )
                abort(403)
            result = fn(*args, **kwargs)
            audit_log.record(
                actor=user.id,
                action=action,
                result="success",
                timestamp=datetime.now(timezone.utc),
            )
            return result
        return wrapper
    return decorator


@requires_role("production_deployer", "deploy_production")
def deploy_to_production(artifact_id: str):
    return deploy(artifact_id)

Dos cosas que buscan los auditores aquí: que la denegación también quede registrada (no solo los aciertos) y que la marca de tiempo sea fiable: datetime.now(timezone.utc), no utcnow(), que está obsoleto desde Python 3.12 y devuelve fechas sin zona horaria que complican la correlación de registros después.

Monitorización y detección (CC7)

Las anomalías tienen que detectarse, alertarse y atenderse. Los cambios de privilegios son el caso de prueba clásico: un auditor preguntará cómo sabrías si alguien se otorgó admin a sí mismo.

# checks/privilege_escalation.py — se ejecuta cada hora sobre tu flujo de eventos de autenticación
from dataclasses import dataclass


@dataclass
class AuthEvent:
    user_id: str
    action: str
    old_role: str | None
    new_role: str | None


def detect_escalation(events: list[AuthEvent]) -> list[str]:
    alerts = []
    for e in events:
        if e.action == "role_change" and e.new_role == "admin" and e.old_role != "admin":
            alerts.append(f"Escalada de privilegios: {e.user_id} recibió admin")
    return alerts

La pregunta del auditor no es “¿existe esta función?”, sino “muéstrame una alerta del trimestre pasado y el ticket que la cerró”. Conecta las detecciones a lo que sea que genere tickets, no solo a mensajes de Slack que desaparecen.

Gestión de cambios (CC8)

Cada cambio en producción tiene que estar autorizado, probado y documentado. GitOps más un entorno protegido te da casi todo el control gratis:

# .github/workflows/deploy-production.yml
name: Deploy to Production
on:
  workflow_dispatch:

jobs:
  deploy:
    environment: production  # aprobación manual obligatoria vía configuración del repo
    steps:
      - uses: actions/checkout@v4
      - name: Verificar ticket de cambio
        run: ./scripts/verify-change-ticket.sh "${{ github.sha }}"
      - name: Desplegar
        run: ./scripts/deploy.sh production

La línea environment: production hace el trabajo pesado: las reglas de protección de entornos de GitHub exigen un aprobador identificado y la aprobación queda registrada; esa es tu evidencia de CC8. La segregación de funciones sale sola si el aprobador no puede ser el autor del commit.

Gestión de vulnerabilidades (CC9)

Los escáneres son baratos; el control es el SLA sobre los hallazgos. Una configuración defendible analiza dependencias y contenedores en cada build y manda los hallazgos críticos a tu gestor de tickets con fecha límite:

# scripts/vuln_triage.py — se ejecuta en CI tras los análisis de trivy/snyk
import json
import subprocess
from datetime import date, timedelta

SLA_DAYS = {"CRITICAL": 1, "HIGH": 7}


def trivy_findings(image: str) -> list[dict]:
    out = subprocess.run(
        ["trivy", "image", "--format", "json", "--severity", "CRITICAL,HIGH", image],
        capture_output=True, check=True, text=True,
    ).stdout
    report = json.loads(out)
    return [
        v
        for result in report.get("Results", [])
        for v in result.get("Vulnerabilities", [])
    ]


def ticket_for(vuln: dict) -> dict:
    severity = vuln.get("Severity", "HIGH")
    return {
        "summary": f"[{severity}] {vuln['VulnerabilityID']} en {vuln['PkgName']}",
        "due_date": str(date.today() + timedelta(days=SLA_DAYS.get(severity, 7))),
    }

Los SLA de parcheo como “críticas en 48–72 h, altas en 7 días” son lo que los auditores escriben en su plan de pruebas: elige cifras que puedas cumplir de verdad, porque un SLA incumplido es un hallazgo.

Recolección de Evidencias que Sobrevive a una Auditoría

La diferencia entre “hacemos esto” y “podemos demostrarlo” es una tabla como esta: cada control mapeado al artefacto que deja:

Control	Evidencia que muestrea el auditor	Cómo automatizarla
Revisiones de accesos	Tickets de revisión trimestral + diff de exportación del IAM	Exportar usuarios del IAM por API; diff contra el trimestre anterior
Aprobaciones de PR	Rastro de aprobación en PRs fusionados	Exportación de revisiones por PR vía API de GitHub
Restauración de copias	Registros de pruebas de restauración con resultado	Job programado de restauración que escribe resultados en el registro de auditoría
Prueba de penetración	Informe de terceros + tickets de remediación	Prueba anual con proveedor; seguimiento de cada hallazgo hasta su cierre
Respuesta a incidentes	Postmortems + cronología + tiempo de resolución	Plantilla de postmortem con campos obligatorios
Bajas de personal	Ticket que muestra acceso revocado dentro del SLA	Disparo por evento de baja de RRHH; registrar marcas de tiempo de revocación

La revisión de accesos es el control que los equipos más a menudo simulan sin querer. Una revisión trimestral defendible tiene esta pinta: exportar el estado actual del IAM (usuarios, roles, último acceso), hacer diff contra la exportación anterior, que un revisor identificado marque cada entrada como “sigue necesaria / revocar”, archivar el resultado como ticket, y revocar de verdad lo marcado. El ticket más el diff es la evidencia; la exportación es reproducible, así que el auditor puede reejecutarla.

Dos reglas prácticas: las capturas de pantalla y las hojas de cálculo sirven para un Tipo I pero se pudren durante una ventana de Tipo II de 12 meses, así que automatiza exportaciones donde puedas. Y el propio registro de auditoría tiene que ser a prueba de manipulaciones; almacenamiento de solo adición (object lock, un bucket dedicado de logs o un SIEM) le gana a una tabla que tus propios administradores pueden editar.

# app/audit_log.py — la forma de evento que los auditores esperan ver
from datetime import datetime
from pydantic import BaseModel


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  # une el evento de auditoría con la traza de la petición

Los campos que importan en una auditoría son actor, action, result y correlation_id; con esos cuatro puedes reconstruir quién hizo qué, cuándo, y qué más pasó en la misma petición.

Un kit de evidencia funcional (script de diff de revisiones de acceso, exportador de aprobaciones de PR, mapa de evidencias y lista de proveedores) está en el repositorio compañero.

La Cronología de la Auditoría

La mayoría de las primeras auditorías Tipo II duran alrededor de un año de extremo a extremo. Lo que los equipos subestiman es que los meses 3–5 son tiempo puro de ingeniería: construir controles, no papeleo.

El análisis de brechas es una autoevaluación (o revisión de un consultor) frente a los TSC: qué criterios aplican, qué controles existen y cuáles no. Construir controles es donde vive el trabajo real: las secciones anteriores de esta guía. La verificación de preparación es un ensayo general: alguien comprueba que realmente existe evidencia para cada control antes de que arranque el reloj. La ventana de observación es el tramo de 3–12 meses que muestrea el auditor: los controles deben funcionar todo el tiempo, y los huecos dentro de la ventana se convierten en excepciones del informe. El trabajo de campo es cuando el auditor pide evidencia, entrevista a los responsables y redacta el informe.

Algo que sorprende a los equipos: el reloj no se pausa por ti. Si tu revisión trimestral de accesos se saltó en el mes 7, aparece como excepción en el informe. Los controles incumplidos no se esconden: se documentan.

Cómo Leer el Informe

Cuando llegue el informe, léelo como lo harán tus clientes: de arriba abajo y con un bolígrafo. La estructura es fija:

La opinión del auditor va primero y es lo único que la mayoría de lectores mira. Una opinión sin salvedades (unqualified) significa que los controles funcionaron eficazmente. Una opinión con salvedades (qualified) significa que funcionaron salvo en criterios concretos, y cada salvedad nombra el control que falló. Las opiniones desfavorables y las de abstención son raras y en la práctica significan empezar de cero. Una opinión con salvedades no es el fin del mundo, pero cuenta con que cada cliente preguntará por lo que salió mal.

La descripción del sistema es texto tuyo: límites, arquitectura, personas y los controles a los que te comprometiste. Los auditores prueban contra esta descripción, así que escríbela ajustada: todo lo que afirmes ahí entra en juego.

La sección de controles y resultados de pruebas es el grueso: cada criterio dentro del alcance, el control que declaraste, la prueba que hizo el auditor y el resultado. Lee las descripciones de las pruebas, no solo aprobado/suspendido: te dicen exactamente qué evidencia se muestreó y qué se volverá a muestrear el año que viene.

Las excepciones listan cada control que no funcionó durante la ventana. Para cada una, la dirección escribe una respuesta. Esta es la sección de la que citarán los clientes más exigentes con seguridad.

Dos conceptos confunden a los que leen por primera vez. Los Controles Complementarios de la Entidad Usuaria (CUEC) son cosas que el informe asume que hacen tus clientes, como mantener seguras sus propias cuentas de administrador. El informe no los cubre; si un cliente no puede cumplir sus CUEC, tu informe no le aplica del todo. Y las organizaciones de subservicio son tus proveedores: con el método carve-out (el habitual), los controles que aportan AWS, Stripe o tu base de datos gestionada quedan excluidos de tu informe, y el auditor solo anota qué informes de proveedores revisaste. Con el método inclusive, menos común, los controles del proveedor se auditan como parte de los tuyos. El carve-out es la razón por la que “eso lo gestiona AWS” es una respuesta válida en auditoría, siempre que hayas revisado su SOC 2 y lo hayas documentado.

Hay un artefacto más que conviene conocer: la bridge letter. Un Tipo II cubre una ventana fija, así que en marzo tu informe de enero–diciembre ya parece viejo. Para el hueco entre el final de la ventana y el siguiente informe, tu auditor puede emitir una carta breve afirmando que nada material cambió en los controles; los clientes la aceptan como parche temporal. Pídela cuando el trato no pueda esperar al informe del año que viene.

Costes, Herramientas y Presupuestos Realistas

Los rangos publicados por proveedores de automatización de cumplimiento y firmas de auditoría se agrupan en torno a:

Partida	Rango típico
Auditoría Tipo I	15 000–30 000 $
Auditoría Tipo II (primer año)	30 000–60 000 $
Renovación Tipo II	20 000–40 000 $ / año
Automatización de cumplimiento (Vanta, Drata, SecureFrame, Thoropass, Sprinto)	5 000–20 000 $ / año
Consultor de preparación	10 000–25 000 $
Tiempo de ingeniería	200–400 horas

Un presupuesto realista del primer año es 50 000–80 000 $ en total. La plataforma de automatización suele merecer la pena a partir de unos 15–20 controles: estas herramientas se conectan a tu AWS/GCP, GitHub, HRIS e IAM, y verifican controles y recogen evidencia de forma continua; la alternativa es un trimestre de arqueología de hojas de cálculo antes de cada auditoría. El auditor es aparte: elige una firma de CPA con experiencia en SaaS, porque las firmas que auditan sobre todo entornos on-premise pedirán artefactos que no existen en tu arquitectura. La mayoría de las firmas también descuentan un encargo combinado de Tipo I + Tipo II; conviene negociarlo antes de firmar cualquiera de los dos contratos, porque casi seguro querrás ambos.

SOC 2 e ISO 27001

Se solapan mucho (ambos cubren control de accesos, operaciones y gestión de riesgos), pero son artefactos distintos:

• SOC 2 es un informe de atestación: un auditor describe tu sistema y la eficacia operativa de tus controles frente a los Trust Services Criteria. Centrado en EE. UU. y es lo que piden por defecto los clientes empresariales americanos.
• ISO 27001 es una certificación de tu sistema de gestión de seguridad de la información (SGSI) frente a un estándar internacional. Señal más fuerte en Europa y Asia, más lenta de obtener, y certifica tu sistema de gestión en lugar de describir controles individuales.

Si los clientes piden SOC 2, haz primero SOC 2; el trabajo de controles se traslada limpiamente si después persigues ISO. Si procesas datos personales europeos a escala, acompaña el que elijas con un programa de privacidad: los criterios de privacidad de SOC 2 y GDPR se solapan, pero no son intercambiables.

Gestión de Proveedores

Tus controles heredan las debilidades de tus proveedores. SOC 2 espera diligencia debida sobre cada tercero que toca datos dentro del alcance; el auditor pedirá la lista y las revisiones. Aquí es también donde aterriza la decisión del carve-out: por cada organización de subservicio de la que dependas, necesitas su SOC 2 archivado y una nota sobre qué controles suyos estás utilizando.

Una lista de comprobación viable para dar de alta proveedores:

• Obtener el informe SOC 2 del propio proveedor (preferiblemente Tipo II) y leer la sección de excepciones
• Documentar exactamente qué categorías de datos recibe el proveedor
• Firmar un DPA antes de que fluya cualquier dato de producción
• Verificar cifrado en tránsito y en reposo; anotar los subencargados del proveedor
• Confirmar un SLA de notificación de incidentes (24–72 h es lo habitual)
• Registrar la revisión y programar una reevaluación anual

La plantilla de evaluación de riesgo de proveedores convierte esto en un documento repetible; a los auditores les gusta ver el mismo formato aplicado de forma consistente entre proveedores.

Buenas Prácticas

• Escribe los controles como “hacemos X, probado con Y”. Si un control no tiene artefacto, no existe a efectos de auditoría. Cada control debe nombrar su evidencia.
• Arranca la ventana de observación solo cuando los controles estén estables. Un control que cambia a mitad de ventana obliga al auditor a probar las dos versiones.
• Automatiza primero la evidencia aburrida. Los diffs de revisiones de accesos, las exportaciones de aprobaciones de PR y los registros de pruebas de restauración son baratos de programar y dolorosos de reconstruir a mano.
• Asigna un responsable por familia de controles. “Seguridad es dueña de CC6” le gana a “el equipo es dueño de todo” cuando el auditor pregunta quién ejecuta el control.
• Lee tu propia sección de excepciones primero. Antes de que salga el informe recibes una carta de respuesta de la dirección; las excepciones que no puedes explicar son las que los clientes te citarán después.
• Trata el informe como renovable, no como terminado. El Tipo II es anual. Los controles que se degradan entre auditorías producen los hallazgos del año siguiente.

Errores Comunes

• Tratar SOC 2 como un proyecto de documentación. Las políticas llevan una semana; la evidencia, un año. Los equipos que escriben políticas en el mes 1 y arrancan el reloj tienen que producir 3–12 meses de pruebas de todos modos.
• Capturas de pantalla como estrategia de evidencia. La evidencia manual se pudre y los auditores desconfían de ella. Si no se puede exportar del sistema de origen, asume que no sobrevivirá al muestreo.
• Bajas de personal que llegan tarde. Exempleados con cuentas activas están entre las excepciones de auditoría más comunes. El control no es “quitamos el acceso”, sino “el acceso se revoca en N horas desde el evento de RRHH, registrado”.
• Cambios de infraestructura fuera de la gestión de cambios. Los despliegues de aplicación pasan por revisión de PR; los applies de Terraform a menudo no. Los auditores también prueban cambios de infraestructura: pon los applies detrás de la misma puerta de aprobación.
• Incluir criterios que no puedes evidenciar. Cada criterio opcional que añades crea su propio plan de pruebas. Seguridad + Disponibilidad primero; amplía en el siguiente ciclo.
• Ignorar la carta de excepciones. Los auditores emiten un borrador con hallazgos antes del informe final. Los equipos que no responden por escrito publican un informe donde su silencio parece conformidad.
• Confundir SOC 2 con SOC 1. SOC 1 cubre controles relevantes para la información financiera. A menos que tu sistema afecte a los estados financieros de los clientes, es el informe equivocado.
• Sprintar al final de la ventana. Los equipos tratan el mes 11 como una fecha límite y lo arreglan todo justo antes del trabajo de campo. Los auditores muestrean toda la ventana: un control que solo funcionó los dos últimos meses figura como excepción de período parcial.

Véase También

• AICPA — informes SOC 2: descripción oficial de los encargos SOC 2 y tipos de informe.
• Vanta — centro de recursos SOC 2: guías publicadas por el proveedor sobre criterios, preparación y referencias de costes.
• NIST SP 800-53 Rev. 5: el catálogo de controles sobre el que se mapean los Criterios Comunes; útil cuando un control necesita una definición formal.
• ISO/IEC 27001: la alternativa de certificación cuando los clientes son internacionales en lugar de centrados en EE. UU.