SOC 2 Type II: qué es, qué evalúa y cómo preparar tu empresa para la auditoría
¿Qué es SOC 2 Type II y por qué cada vez más clientes internacionales lo solicitan? Conocé qué controles evalúa, la diferencia entre Type I y Type II y cómo preparar tu empresa para una auditoría SOC 2.
Por InfoSecura · Actualizado 07/10/2026

Una empresa de software comienza a venderle a un cliente de Estados Unidos. Todo avanza correctamente hasta que el equipo de compras o seguridad del cliente hace una pregunta:
“¿Tienen SOC 2 Type II?”
Para muchas empresas tecnológicas de Uruguay y Latinoamérica, ese puede ser el primer contacto con SOC 2.
La organización puede tener buenos controles de seguridad, utilizar MFA, realizar backups, contar con EDR, gestionar vulnerabilidades y tener políticas documentadas. Sin embargo, el cliente no quiere solamente una declaración de que la empresa es segura: quiere evidencia independiente de que existen controles y que funcionan de manera consistente.
Ahí aparece SOC 2.
Aunque habitualmente se habla de “certificación SOC 2”, técnicamente SOC 2 no funciona exactamente como una certificación ISO. El resultado del proceso es un informe de atestiguamiento elaborado por un auditor independiente habilitado para realizar este tipo de examen.
En esta guía explicamos qué es SOC 2, qué diferencia existe entre Type I y Type II, qué controles suelen evaluarse, qué evidencias necesita una organización y cómo prepararse antes de iniciar formalmente una auditoría.
¿Qué es SOC 2?
SOC 2 forma parte del conjunto de servicios System and Organization Controls desarrollado por la American Institute of Certified Public Accountants (AICPA).
Está orientado especialmente a organizaciones que prestan servicios y procesan, almacenan o administran información de sus clientes.
Es particularmente frecuente en:
- empresas SaaS;
- desarrolladores de software;
- proveedores cloud;
- FinTech;
- empresas de tecnología;
- proveedores de servicios gestionados;
- plataformas que procesan información de terceros;
- empresas que trabajan con clientes de Estados Unidos;
- organizaciones que forman parte de cadenas de suministro internacionales.
El objetivo es proporcionar a clientes y otras partes interesadas información sobre los controles implementados por la organización para proteger sus sistemas y la información que procesa.
Los criterios utilizados se conocen como Trust Services Criteria (TSC).
¿Qué evalúa SOC 2?
Los Trust Services Criteria contemplan cinco grandes categorías:
- Security: protección frente a accesos no autorizados, uso indebido o alteración de sistemas e información.
- Availability: capacidad de los sistemas para encontrarse disponibles de acuerdo con los compromisos asumidos.
- Processing Integrity: procesamiento completo, válido, exacto, oportuno y autorizado.
- Confidentiality: protección de información identificada como confidencial.
- Privacy: tratamiento de información personal de acuerdo con los compromisos y criterios aplicables.
La categoría de Security constituye la base habitual de una evaluación SOC 2. Dependiendo del servicio, los riesgos y los compromisos asumidos con los clientes pueden incorporarse además Availability, Confidentiality, Processing Integrity y Privacy.
Esto significa que SOC 2 no consiste simplemente en completar una lista estándar de controles.
La empresa debe definir adecuadamente qué sistema está siendo evaluado, qué servicios forman parte del alcance, qué riesgos existen y qué controles permiten gestionar esos riesgos.
SOC 2 Type I vs SOC 2 Type II: ¿cuál es la diferencia?
Esta es una de las confusiones más frecuentes.
SOC 2 Type I
Un informe SOC 2 Type I evalúa el diseño de los controles en una fecha determinada.
En términos simplificados, busca responder:
¿Los controles necesarios existen y están adecuadamente diseñados en este momento?
Por ejemplo, una empresa puede afirmar que:
- los accesos administrativos utilizan MFA;
- existe un proceso de alta y baja de usuarios;
- se realizan análisis de vulnerabilidades;
- existe un procedimiento de respuesta a incidentes;
- los backups son monitoreados;
- se revisan los privilegios periódicamente.
El examen Type I analiza el diseño de los controles aplicables en la fecha definida para el informe.
SOC 2 Type II
SOC 2 Type II va un paso más allá.
No solamente analiza si los controles están definidos y adecuadamente diseñados, sino también su efectividad operativa durante un período de tiempo.
La pregunta deja de ser únicamente:
“¿Existe este control?”
y pasa a ser también:
“¿Podemos demostrar que este control funcionó consistentemente durante el período evaluado?”
Por ejemplo, tener un procedimiento que indique que los accesos deben revisarse trimestralmente no es suficiente.
La organización deberá poder demostrar que las revisiones efectivamente fueron realizadas, quién las realizó, cuándo ocurrieron, qué se revisó y qué acciones surgieron de ellas.
Esta diferencia hace que la preparación para Type II requiera especialmente disciplina operativa y generación continua de evidencia.
SOC 2 no es solamente documentación
Uno de los errores más comunes al prepararse para SOC 2 consiste en pensar que el proyecto se resuelve creando políticas.
Las políticas son importantes, pero un auditor también necesitará observar evidencia de que los procesos realmente funcionan.
Una empresa puede tener una excelente Política de Gestión de Accesos y, al mismo tiempo:
- mantener cuentas de exempleados activas;
- utilizar cuentas administrativas compartidas;
- no revisar privilegios;
- no exigir MFA;
- otorgar permisos sin aprobación formal.
En ese escenario existe documentación, pero el control puede no encontrarse efectivamente implementado.
También puede ocurrir lo contrario: una empresa puede tener técnicamente buenos controles, pero ser incapaz de demostrar cómo funcionan porque no conserva registros, aprobaciones, tickets o evidencia.
Para SOC 2 ambas dimensiones son importantes:
control implementado + evidencia verificable.
¿Qué controles suelen aparecer en una preparación SOC 2?
El alcance concreto debe determinarse para cada organización, pero existen áreas que aparecen frecuentemente en programas de preparación SOC 2.
1. Gestión de accesos
La empresa debería poder controlar quién accede a sus sistemas y por qué.
Esto puede incluir:
- altas, modificaciones y bajas de usuarios;
- principio de mínimo privilegio;
- autenticación multifactor;
- revisión periódica de permisos;
- gestión de cuentas privilegiadas;
- políticas de autenticación;
- registro y aprobación de accesos.
2. Gestión de cambios
Los cambios realizados sobre sistemas y aplicaciones deberían encontrarse controlados.
Dependiendo de la organización pueden requerirse mecanismos como:
- solicitud y registro de cambios;
- revisión de código;
- aprobación antes de producción;
- separación entre ambientes;
- control de repositorios;
- registro de despliegues.
3. Gestión de vulnerabilidades
Detectar vulnerabilidades no es suficiente.
Debe existir un proceso para:
- identificarlas;
- evaluar su criticidad;
- asignar responsables;
- establecer plazos de remediación;
- gestionar excepciones;
- verificar posteriormente la corrección.
Dependiendo del alcance, también pueden resultar relevantes los análisis automatizados y las pruebas de penetración.
Si necesitás evaluar técnicamente la exposición de sistemas o aplicaciones, podés consultar nuestro servicio de Ethical Hacking y Pentesting.
4. Gestión de incidentes
La organización debería encontrarse preparada para detectar, escalar, contener y gestionar incidentes de seguridad.
Normalmente esto requiere:
- responsables definidos;
- procedimiento de respuesta;
- clasificación de incidentes;
- mecanismos de escalamiento;
- registro de incidentes;
- análisis posterior;
- acciones correctivas.
5. Gestión de riesgos
SOC 2 no debería gestionarse como una colección aislada de controles.
La organización necesita comprender:
- qué activos protege;
- qué amenazas enfrenta;
- qué riesgos son relevantes;
- qué controles existen;
- qué riesgos permanecen abiertos;
- quién acepta esos riesgos.
Un análisis de riesgos adecuadamente mantenido ayuda a justificar por qué existen determinados controles y cómo se priorizan las acciones de seguridad.
6. Gestión de proveedores
Una parte importante de la infraestructura moderna depende de terceros.
AWS, Azure, Microsoft 365, proveedores de desarrollo, datacenters, herramientas SaaS y servicios gestionados pueden intervenir directamente en la prestación del servicio.
Por eso resulta necesario determinar:
- qué proveedores son críticos;
- qué información procesan;
- qué accesos poseen;
- cómo se evalúa su seguridad;
- qué requisitos contractuales existen;
- cómo se revisan periódicamente.
7. Continuidad, disponibilidad y backups
Cuando la disponibilidad forma parte de los compromisos del servicio, la organización debe demostrar que entiende cómo mantendrá o recuperará la operación ante una interrupción.
Pueden analizarse aspectos como:
- backups;
- pruebas de restauración;
- redundancia;
- monitoreo;
- planes de continuidad;
- recuperación ante desastres;
- gestión de capacidad.
8. Recursos humanos y concientización
Las personas también forman parte del sistema de controles.
Por eso pueden resultar relevantes:
- acuerdos de confidencialidad;
- procesos de incorporación y desvinculación;
- aceptación de políticas;
- capacitación periódica;
- concientización en seguridad;
- registro de las actividades realizadas.
La evidencia: uno de los puntos más importantes de SOC 2 Type II
Una empresa puede implementar correctamente un control y aun así tener dificultades durante una auditoría si no puede demostrarlo.
Por eso la preparación debería determinar desde el principio qué evidencia producirá cada control.
Algunos ejemplos pueden ser:
- tickets de altas y bajas;
- aprobaciones de acceso;
- capturas o exportaciones de configuraciones;
- reportes de vulnerabilidades;
- tickets de remediación;
- resultados de pentesting;
- registros de capacitación;
- revisiones periódicas de permisos;
- actas de reuniones;
- evaluaciones de proveedores;
- resultados de pruebas de recuperación;
- registros de incidentes;
- evidencia de revisión de logs y alertas;
- aprobaciones de cambios;
- registros provenientes de herramientas de seguridad.
Esto es especialmente importante para Type II porque el auditor necesita evaluar la operación de los controles durante el período cubierto por el examen.
¿Cuánto tiempo lleva prepararse para SOC 2?
No existe un plazo universal.
Depende principalmente de:
- tamaño de la organización;
- cantidad de sistemas incluidos;
- complejidad de la infraestructura;
- cantidad de empleados;
- madurez actual de seguridad;
- documentación existente;
- controles técnicos ya implementados;
- cantidad de brechas detectadas;
- alcance elegido para el examen.
Una empresa que ya posee procesos maduros puede encontrarse mucho más cerca de estar preparada de lo que imagina.
Otra organización puede descubrir durante el análisis inicial que existen controles importantes que nunca fueron formalizados o que no generan evidencia suficiente.
Por eso resulta conveniente realizar un gap assessment o análisis de brecha antes de contratar directamente la auditoría formal.
¿Qué es un SOC 2 Readiness Assessment?
Un readiness assessment es una evaluación previa destinada a determinar qué tan preparada se encuentra la organización para afrontar el examen SOC 2.
No sustituye a la auditoría independiente ni produce un informe SOC 2.
Su objetivo es detectar anticipadamente:
- controles faltantes;
- controles mal diseñados;
- procesos que existen pero no están documentados;
- documentación que no refleja la operación real;
- falta de evidencia;
- riesgos sin tratamiento;
- problemas de gestión de accesos;
- brechas de seguridad técnica;
- proveedores sin evaluar;
- responsabilidades que no están claramente asignadas.
El resultado debería convertirse en un plan de adecuación priorizado, indicando qué debe corregirse, quién será responsable y qué evidencia deberá conservarse.
Un error costoso: contratar al auditor antes de estar preparado
Cuando SOC 2 aparece como requisito de un cliente importante existe una tendencia natural a querer comenzar la auditoría inmediatamente.
Pero iniciar el proceso formal con controles todavía inmaduros puede generar problemas.
Por ejemplo:
- controles que comienzan a ejecutarse demasiado tarde;
- evidencias incompletas;
- políticas que no coinciden con la práctica;
- revisiones periódicas que nunca fueron realizadas;
- vulnerabilidades antiguas sin tratamiento;
- usuarios que deberían haber sido eliminados;
- procesos críticos sin responsables.
Prepararse previamente permite llegar al período de evaluación con los controles ya funcionando, en lugar de intentar construirlos mientras están siendo examinados.
¿SOC 2 reemplaza a ISO 27001?
No.
SOC 2 e ISO/IEC 27001 tienen puntos de contacto importantes, pero son mecanismos diferentes.
ISO/IEC 27001 establece requisitos para implementar y mantener un Sistema de Gestión de Seguridad de la Información y permite obtener una certificación a través de un organismo certificador.
SOC 2, en cambio, evalúa controles relacionados con los Trust Services Criteria y produce un informe de atestiguamiento.
Una organización que ya trabaja seriamente con ISO 27001 probablemente disponga de numerosos procesos, controles y evidencias reutilizables para SOC 2.
Sin embargo, no debería asumirse que contar con ISO 27001 significa automáticamente estar preparado para SOC 2.
Debe realizarse un análisis específico del alcance y de los criterios correspondientes.
¿Qué empresas uruguayas deberían considerar SOC 2?
SOC 2 puede resultar especialmente relevante para una empresa uruguaya cuando:
- vende servicios tecnológicos en Estados Unidos;
- opera una plataforma SaaS;
- procesa información sensible de clientes;
- participa en procesos de due diligence de grandes empresas;
- sus clientes solicitan evidencia independiente de sus controles;
- recibe regularmente cuestionarios de seguridad extensos;
- busca ingresar a mercados empresariales internacionales;
- un potencial cliente estableció SOC 2 como requisito contractual.
En estos casos, SOC 2 deja de ser solamente una iniciativa de ciberseguridad.
Puede transformarse en un requisito comercial.
Una empresa puede perder una oportunidad de negocio no porque su producto sea inferior, sino porque no logra demostrar el nivel de control que exige el cliente.
Cómo prepararse para SOC 2 paso a paso
Una estrategia de preparación puede estructurarse de la siguiente manera:
- Definir el objetivo comercial. Determinar por qué la organización necesita SOC 2 y qué solicitan concretamente sus clientes.
- Definir el alcance. Identificar servicios, infraestructura, personas, procesos y proveedores involucrados.
- Seleccionar los Trust Services Criteria aplicables.
- Realizar un análisis de brecha.
- Identificar y evaluar riesgos.
- Definir formalmente los controles necesarios.
- Desarrollar o actualizar políticas y procedimientos.
- Implementar las mejoras técnicas requeridas.
- Asignar responsables para cada control.
- Definir qué evidencia debe conservarse.
- Comenzar a operar los controles regularmente.
- Revisar internamente la evidencia generada.
- Corregir las brechas restantes.
- Coordinar posteriormente el examen con el auditor independiente correspondiente.
¿Quién puede emitir un informe SOC 2?
Este punto es fundamental.
INFOSECURA no emite informes SOC 2 ni actúa como la firma independiente encargada de emitir la opinión de atestiguamiento.
El examen formal debe ser realizado por profesionales habilitados para desarrollar este tipo de encargos conforme a los estándares correspondientes.
Lo que sí puede realizar una consultora de ciberseguridad es trabajar del lado de la organización que necesita prepararse.
Son dos roles diferentes:
- Preparación: identificar brechas, desarrollar controles, organizar evidencias, gestionar riesgos y acompañar a la empresa.
- Examen independiente: evaluar posteriormente esos controles y emitir el informe correspondiente.
Mantener esa diferencia claramente definida es importante para preservar la independencia del proceso.
Preparación para SOC 2 con INFOSECURA
En INFOSECURA podemos acompañar a empresas que necesitan preparar su organización antes de afrontar un examen SOC 2.
El trabajo puede incluir, dependiendo del alcance:
- evaluación inicial de madurez;
- gap assessment contra los Trust Services Criteria aplicables;
- definición del alcance del programa;
- inventario de controles existentes;
- análisis y gestión de riesgos;
- desarrollo y adecuación de políticas y procedimientos;
- gestión de accesos y privilegios;
- gestión de vulnerabilidades;
- gestión de proveedores;
- respuesta a incidentes;
- continuidad y recuperación;
- definición de evidencias para cada control;
- seguimiento del plan de remediación;
- coordinación entre dirección, IT y los responsables de seguridad;
- preparación de la organización para la revisión del auditor independiente.
Nuestro servicio de vCISO puede asumir la coordinación del programa de preparación, ayudando a transformar los requerimientos de SOC 2 en controles, responsables, evidencias y un plan de trabajo concreto.
Cuando se detectan brechas técnicas, el proceso puede complementarse con capacidades de vSecOps, gestión de vulnerabilidades y Ethical Hacking / Pentesting.
El objetivo no es simplemente generar documentos para una auditoría.
Es llegar al examen con controles que realmente funcionan y evidencia que permite demostrarlo.
Si un cliente te está solicitando SOC 2 o querés saber qué tan lejos está tu empresa de estar preparada, podemos realizar una evaluación inicial y definir un roadmap de adecuación.
Conocé nuestro servicio de vCISO →
Preguntas frecuentes sobre SOC 2
¿SOC 2 es una certificación?
Técnicamente no. Aunque comercialmente se utiliza con frecuencia la expresión “certificación SOC 2”, el resultado es un informe de atestiguamiento emitido luego de un examen independiente.
¿Qué diferencia existe entre SOC 2 Type I y Type II?
Type I evalúa el diseño de los controles en una fecha determinada. Type II evalúa además la efectividad operativa de esos controles durante un período definido.
¿SOC 2 Type II es mejor que Type I?
Type II proporciona mayor información sobre el funcionamiento sostenido de los controles, ya que no se limita a observar su diseño en un momento determinado. Por este motivo es frecuente que clientes con mayores requisitos de seguridad soliciten específicamente un informe Type II.
¿Una empresa uruguaya puede obtener un informe SOC 2?
Sí. SOC 2 no está limitado a empresas ubicadas físicamente en Estados Unidos. Una organización uruguaya que presta servicios a clientes internacionales puede preparar sus controles y posteriormente contratar una firma habilitada para realizar el examen correspondiente.
¿Tengo que implementar los cinco Trust Services Criteria?
No necesariamente. El alcance debe definirse según las características del servicio, los riesgos de la organización y los compromisos asumidos con los clientes. Security constituye el núcleo habitual, mientras que otras categorías pueden incorporarse cuando corresponda.
¿Necesito un pentest para SOC 2?
Las actividades concretas necesarias dependen del alcance, los riesgos y los controles definidos. Las pruebas de seguridad y la gestión de vulnerabilidades pueden formar parte de las evidencias utilizadas para demostrar que la organización evalúa y trata adecuadamente sus exposiciones técnicas.
¿INFOSECURA emite el informe SOC 2?
No. INFOSECURA trabaja en la preparación de la organización, identificación de brechas, implementación y seguimiento de controles y organización de evidencias. La evaluación formal y emisión del informe SOC 2 corresponde al auditor independiente habilitado para realizar el encargo.
¿Por dónde debería empezar una empresa que recibió un pedido de SOC 2?
Antes de iniciar directamente la auditoría, normalmente conviene confirmar exactamente qué solicita el cliente, definir el alcance y realizar una evaluación de preparación. Esto permite conocer las brechas existentes y construir un plan de remediación antes del período que será evaluado.
Fuentes oficiales
Contenido informativo general. El alcance, los controles aplicables y las características de un examen SOC 2 dependen de cada organización y deben definirse con los profesionales responsables del proceso. INFOSECURA brinda servicios de preparación y acompañamiento, pero no emite informes SOC 2.