Cómo funciona
Un informe SOC 2 responde a una pregunta concreta: ¿cuán confiables son los controles que una entidad de servicios ha implementado para proteger los datos o sistemas que gestiona para sus clientes?
La entidad de servicios (por ejemplo, un proveedor de almacenamiento en la nube, un procesador de pagos) encarga a un auditor independiente que evalúe sus controles de TI contra el marco de Trust Services Criteria (Criterios de Servicios de Confianza). El auditor examina si esos controles están diseñados para lograr los objetivos establecidos en cinco categorías: seguridad (protección contra acceso no autorizado), disponibilidad (asegurar que los sistemas funcionan cuando se necesitan), integridad de procesamiento (transacciones se registran de forma completa y precisa), confidencialidad (información sensible no se divulga) y privacidad (datos personales se manejan según políticas declaradas).
El resultado es un informe dirigido a los usuarios del servicio (los clientes de la entidad de servicios) que describe qué controles evaluó el auditor, en qué período, y si esos controles fueron efectivos. Según SSAE 18 párrafo 40, el auditor debe expresar una opinión sobre si los controles fueron diseñados y operaban de forma efectiva para lograr los objetivos especificados en la descripción de responsabilidad de la dirección.
Ejemplo práctico: Soluciones de Pago Secure S.L.
Cliente: Empresa española de procesamiento de pagos, con sede en Barcelona, que gestiona transacciones de clientes retail por valor de €180 millones anuales en volumen de transacciones. Datos gestionados: tarjetas de crédito, direcciones de facturación, números de cliente únicos.
Paso 1. Definir el alcance del informe SOC 2
El cliente de la empresa procesadora (un minorista grande) requiere que se evalúen los controles sobre confidencialidad de datos de tarjeta y disponibilidad del sistema de procesamiento. La dirección de Secure define el período de evaluación como el año calendario 2024.
Nota de documentación: Se documentó la definencia de responsabilidad de la dirección. Este documento especifica qué controles están dentro del alcance del informe y cuál es el período de evaluación.
Paso 2. Evaluar el diseño de controles (aplicable a Tipo I o Tipo II)
El auditor verifica que Secure ha implementado controles técnicos (encriptación de datos en reposo y en tránsito, autenticación multifactor para acceso administrativo) y controles operacionales (políticas de cambio de contraseñas, revisiones de acceso periódicas). Para cada control, el auditor determina si su diseño está vinculado lógicamente al objetivo declarado (por ejemplo, "encriptación de datos en tránsito está diseñada para proteger la confidencialidad durante la transmisión entre sistemas de Secure y bancos de los clientes").
Nota de documentación: Matriz de mapeo control-objetivo. Para cada control, documento que vincula el control al objetivo de confidencialidad o disponibilidad.
Paso 3. Evaluar la operatividad de los controles (solo Tipo II)
Si es un informe Tipo II, el auditor recopila evidencia durante un período mínimo de seis meses que demuestre que cada control funcionó de forma efectiva. Por ejemplo, para el control "revisión mensual de acceso administrativo," el auditor solicita y examina 12 registros de revisión, verifica que cada uno fue completado, y comprueba que se documentaron y resolvieron discrepancias de acceso.
Nota de documentación: Cartera de pruebas que demuestra testing de cada control durante el período completo. Incluye muestreo de transacciones, inspección de logs de sistema, entrevistas con personal responsable.
Paso 4. Formular la opinión del auditor
El auditor determina si la evidencia recopilada es suficiente para sustentar una conclusión sobre si los controles fueron efectivos. Si descubre que una revisión de acceso se omitió en uno de los 12 meses, esto no invalida automáticamente la opinión, pero la deficiencia se documenta como una "debilidad de control" en el informe.
Nota de documentación: Memorándum de conclusiones. El auditor sintetiza toda la evidencia y documenta el razonamiento que sustenta la opinión final.
Conclusión: El informe SOC 2 de Secure declara que los controles sobre confidencialidad y disponibilidad fueron diseñados de forma efectiva (Tipo I) o diseñados y operaron de forma efectiva durante el período de evaluación (Tipo II). Los clientes de Secure pueden usar este informe como evidencia de que sus datos están protegidos conforme a estándares establecidos.
Qué revisor y auditores entienden mal
- Confundir SOC 2 con SOC 1 (SSAE 18 párrafo 2): SOC 1 (anteriormente SAS 70) evalúa controles internos relevantes para la auditoría de estados financieros del cliente de la entidad de servicios. SOC 2 evalúa controles sobre seguridad, disponibilidad e integridad de datos, independientemente de si afectan a los estados financieros. Un auditor que requiera un informe SOC 2 cuando la entidad de servicios solo ha obtenido un SOC 1 habrá recopilado evidencia insuficiente sobre controles de seguridad de datos.
- Aceptar un informe SOC 2 sin evaluar su alcance y limitaciones (SSAE 18 párrafo 48): El informe SOC 2 solo proporciona evidencia sobre los controles que la entidad de servicios eligió incluir y durante el período que especificó. Si la matriz de riesgos del auditor requiere evidencia sobre "integridad de datos de transacciones enero a junio" pero el informe SOC 2 cubre "disponibilidad del sistema enero a diciembre," el informe no cubre el riesgo que el auditor identificó. El auditor debe leer cuidadosamente la definición de responsabilidad de la dirección (parte del informe SOC 2) para confirmar que el alcance coincide con los riesgos relevantes.
- No distinguir entre Tipo I y Tipo II en la evaluación del riesgo: Un informe Tipo I solo proporciona evidencia sobre el diseño de controles en un momento. No proporciona evidencia sobre la efectividad operativa. Si el riesgo identificado por el auditor requiere evidencia de "los controles han funcionado de forma consistente durante nuestro período de auditoría," un informe Tipo I es insuficiente; se requiere Tipo II.
SOC 2 vs. SOC 3
| Aspecto | SOC 2 | SOC 3 |
|---|---|---|
| Audiencia prevista | Clientes y socios de la entidad de servicios (restringido) | Público general (disponible libremente) |
| Criterios evaluados | Five Trust Services Categories (seguridad, disponibilidad, integridad, confidencialidad, privacidad) | Puede incluir una o más categorías según lo que la entidad de servicios elija publicar |
| Detalle de controles | Detallado; describe los controles específicos evaluados | Alto nivel; describe principios, no procedimientos específicos |
| Utilidad en auditoría | Alta. Los auditores examinan informes SOC 2 de proveedores de servicios para recopilar evidencia sobre controles de TI relevantes. | Limitada. El carácter general y de alto nivel hace que sea menos útil para auditoría de cuentas anuales, pero puede proporcionar contexto sobre la postura de seguridad general de un proveedor. |
Cuándo la distinción importa en un encargo
Cataluña Manufacturing Solutions S.A., fabricante de componentes de automoción con sede en Terrassa, contrató a una empresa de servicios en la nube para gestionar su sistema de gestión de inventario, que es crítico para la precisión de la declaración de existencias (un componente material de los estados financieros). Durante la planificación de la auditoría, el auditor identificó el riesgo: "Los datos de inventario procesados por el proveedor de la nube podrían ser modificados o eliminados sin que el cliente lo detecte, lo cual afectaría a la integridad de los saldos de existencias."
Para evaluar este riesgo, el auditor requería evidencia de que los controles sobre integridad de procesamiento del proveedor de la nube funcionaban de forma efectiva durante el período de auditoría (enero a septiembre 2024).
El proveedor entregó un informe SOC 2 Tipo I emitido el 30 de septiembre 2024, que evaluaba el diseño de controles (autenticación, registros de cambios, copias de seguridad) en esa fecha.
Problema: El informe Tipo I proporciona evidencia de que los controles estaban diseñados correctamente, pero no proporciona evidencia de que funcionaron de forma efectiva durante los nueve meses anteriores. El auditor de Cataluña Manufacturing no tenía forma de verificar si una modificación no autorizada de datos de inventario ocurrió en julio, por ejemplo, porque el informe Tipo I solo captura una instantánea del diseño.
Solución: El auditor solicitó un informe SOC 2 Tipo II que cubriera el período enero a septiembre 2024. Este informe contendría evidencia de que el control de "registro de cambios" fue probado mensualmente durante el período completo, que los registros se revisaron para detectar cambios no autorizados, y que se investigaron y documentaron discrepancias.
Con el informe Tipo II, el auditor tenía suficiente evidencia sobre la efectividad operativa de los controles para satisfacer el riesgo de integridad de datos de inventario y proporcionar una base razonable para la opinión sobre las existencias.
Si el auditor hubiera aceptado el informe Tipo I como suficiente, habría recopilado evidencia insuficiente sobre un riesgo material.
Términos relacionados
- Controles de TI relevantes para la auditoría: Cómo identificar qué sistemas de información requieren testing en una auditoría de estados financieros.
- Entidad de servicios: Definición y características de una organización que presta servicios a otras organizaciones.
- Riesgo de integridad de datos: Evaluación de si los datos pueden ser modificados sin detección.
- Confianza en la auditoría interna del cliente: Cómo se evalúa la suficiencia de las evidencias que proporciona la auditoría interna de un cliente.
- Procedimientos de respuesta al riesgo: Estrategias del auditor para obtener evidencia sobre riesgos importantes, incluyendo cómo usar informes de terceros como el SOC 2.
- Marco de criterios de servicios de confianza: Descripción detallada de los cinco criterios que evalúan los informes SOC 2.