Informe SOC 2

Cómo funciona

La entidad de servicios (un proveedor de almacenamiento en la nube, un procesador de pagos, un BPO de nóminas) encarga a un auditor independiente que evalúe sus controles de TI contra el marco de Trust Services Criteria. Ese auditor examina si los controles están diseñados para alcanzar los objetivos declarados en cinco categorías: seguridad (protección frente a accesos no autorizados), disponibilidad (sistemas operativos cuando se necesitan), integridad de procesamiento (transacciones registradas de forma completa y precisa), confidencialidad (información sensible no divulgada) y privacidad (datos personales tratados conforme a las políticas declaradas).

El producto final es un informe dirigido a los usuarios del servicio, los clientes de esa entidad, donde se describe qué controles se evaluaron, durante qué período, y si funcionaron de forma efectiva. SSAE 18 §40 exige que el auditor del proveedor exprese una opinión sobre si los controles fueron diseñados y operaron de forma efectiva para alcanzar los objetivos descritos en la responsabilidad de la dirección. En la práctica, eso significa que la opinión cubre lo que la dirección de la entidad de servicios decidió describir, ni un control más, ni un día más allá del período declarado. Si el auditor de cuentas necesita evidencia sobre algo que no está en esa descripción, el SOC 2 no la da.

Hay una asimetría que conviene tener presente. El auditor del proveedor responde ante el proveedor que paga el encargo. Su opinión está restringida a un alcance que el proveedor ha definido en su propio interés comercial. Sobre el papel, los Trust Services Criteria parecen un marco común. En la mesa de revisión, dos informes SOC 2 de dos proveedores comparables pueden cubrir alcances muy distintos según lo que cada dirección haya querido someter a evaluació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 retail por valor de 180 millones de euros anuales en volumen de transacciones durante 2024. Datos gestionados: tarjetas de crédito, direcciones de facturación, números únicos de cliente.

Paso 1. Definir el alcance del informe SOC 2. El cliente principal de Secure (un minorista grande) requiere evaluación de 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 natural 2024. Nota de documentación: se documentó la definición de responsabilidad de la dirección. Este documento especifica qué controles entran dentro del alcance y cuál es el período de evaluación.

Paso 2. Evaluar el diseño de los controles (aplicable a Tipo I y Tipo II). El auditor verifica que Secure ha implantado controles técnicos (cifrado de datos en reposo y en tránsito, autenticación multifactor para acceso administrativo) y controles operativos (políticas de cambio de contraseñas, revisiones periódicas de acceso). Para cada control determina si su diseño está vinculado lógicamente al objetivo declarado (por ejemplo, "el cifrado en tránsito está diseñado para proteger la confidencialidad durante la transmisión entre los sistemas de Secure y los 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 Tipo II, el auditor reúne evidencia durante un período mínimo de seis meses que demuestre que cada control funcionó de forma efectiva. Para el control "revisión mensual de acceso administrativo," el auditor solicita y examina los doce registros de revisión, comprueba que cada uno fue completado, y verifica que se documentaron y resolvieron las discrepancias de acceso. Nota de documentación: cartera de pruebas que demuestra el testing de cada control durante el período completo. Incluye muestreo de transacciones, inspección de logs de sistema y entrevistas con personal responsable.

Paso 4. Formular la opinión del auditor del proveedor. El auditor determina si la evidencia reunida sustenta una conclusión sobre la efectividad de los controles. Si descubre que la revisión de acceso se omitió en uno de los doce meses, eso no invalida automáticamente la opinión, pero la deficiencia se documenta como debilidad de control en el informe. Nota de documentación: memorándum de conclusiones. El auditor sintetiza la evidencia y documenta el razonamiento que sustenta la opinión final.

Aquí viene la complicación que el caso limpio no contaba. Supongamos que la opinión del auditor de Secure es modificada con salvedad sobre el objetivo "revisión mensual de acceso administrativo" porque dos de los doce meses fallaron, y que ese objetivo es precisamente el que el auditor de cuentas del minorista había mapeado contra su propio riesgo de acceso indebido a datos de cobros. La salvedad no invalida el informe completo, pero deja sin cobertura el riesgo concreto que motivó pedir el SOC 2. En los expedientes que hemos visto, ese matiz se pasa por alto porque la portada dice "opinión emitida" y nadie baja al detalle de qué objetivos quedan tocados. El auditor de cuentas, en ese caso, no puede usar el SOC 2 para mitigar ese riesgo y debe diseñar procedimientos sustantivos adicionales sobre los datos de acceso del período afectado.

Qué pasan por alto los auditores

Confundir SOC 2 con SOC 1 (SSAE 18 §2). El SOC 1 (antes SAS 70) cubre controles internos relevantes para la auditoría de cuentas anuales del usuario del servicio. El SOC 2 cubre seguridad, disponibilidad e integridad de datos, con independencia de si afectan a las cuentas anuales. Un auditor que necesita evidencia sobre integridad de procesamiento de transacciones contables y se conforma con un SOC 1 (o al revés) ha pedido el documento equivocado. La diferencia parece elemental, y aun así sigue apareciendo en revisiones de calidad porque el solicitante entiende que "report del proveedor" y el solicitado lo entiende como "el que tenemos firmado".

Aceptar el informe SOC 2 sin leer la sección de alcance ni la matriz de objetivos (SSAE 18 §48). El SOC 2 solo da evidencia sobre los controles que la entidad de servicios eligió incluir y sobre el período que declaró. Si la matriz de riesgos del auditor de cuentas requiere evidencia sobre integridad de transacciones de enero a junio y el SOC 2 cubre disponibilidad de enero a diciembre, el informe no cubre el riesgo identificado por mucho que pese cien páginas. El auditor debe leer con cuidado la definición de responsabilidad de la dirección para confirmar que el alcance encaja con los riesgos relevantes del encargo.

No distinguir Tipo I de Tipo II en la evaluación del riesgo. El Tipo I solo da evidencia sobre el diseño de los controles en una fecha, no sobre su funcionamiento sostenido. Si el riesgo identificado pide evidencia de que los controles han funcionado de forma consistente durante el período auditado, el Tipo I es insuficiente y hay que ir al Tipo II.

Tratar el SOC 2 como un trámite. Esta es la falla cultural, no técnica. En equipos que vienen de cierres ajustados de busy season y donde el socio necesita el cliente, la tentación de marcar la casilla con un informe en mano es real. Lo que ocurre en la práctica es que los papeles están flojos: el informe está en el expediente, pero no hay un papel de trabajo donde el auditor haya mapeado los objetivos del SOC 2 contra los riesgos del encargo, ni una nota que justifique por qué el alcance es suficiente. Cuando un EQR lo lee meses después, no encuentra el razonamiento, solo el resultado.

SOC 2 vs SOC 3

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 cloud para gestionar su sistema de gestión de inventario, que es crítico para la precisión de la declaración de existencias (componente material de los estados financieros). En la planificación, el auditor identificó el riesgo: los datos de inventario procesados por el proveedor de la nube podrían modificarse o borrarse sin que el cliente lo detecte, lo que afectaría a la integridad de los saldos de existencias.

Para evaluar ese riesgo, el auditor necesitaba evidencia de que los controles del proveedor sobre integridad de procesamiento operaron de forma efectiva durante el período de auditoría (enero a septiembre de 2024). El proveedor entregó un informe SOC 2 Tipo I con fecha 30 de septiembre de 2024, que evaluaba el diseño de los controles (autenticación, registros de cambios, copias de seguridad) en esa fecha.

El problema. El Tipo I da evidencia de que los controles estaban diseñados correctamente, pero no 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 Tipo I solo captura una instantánea del diseño.

La solución. El auditor pidió un SOC 2 Tipo II que cubriera el período enero a septiembre de 2024. Ese 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 las discrepancias. Con ese Tipo II, el auditor tenía evidencia suficiente sobre la efectividad operativa para satisfacer el riesgo de integridad de inventario y dar base razonable a la opinión sobre las existencias.

Si el auditor hubiera aceptado el Tipo I como suficiente, habría reunido evidencia insuficiente sobre un riesgo material.

La zona gris: dos posiciones razonables

En esto los socios discrepan, y conviene explicitar el debate en lugar de pretender que hay una respuesta única. Posición A: cuando el SOC 2 Tipo II del proveedor cubre solo parte del período auditado (acaba en septiembre y el cierre es en diciembre, por ejemplo), basta con completar el sub-período pendiente con representaciones de la dirección del proveedor y una indagación sobre cambios de control. Esta postura sostiene que el coste de pedir un nuevo Tipo II o un bridge letter es desproporcionado para un período corto en un proveedor maduro. Posición B: las representaciones no son evidencia suficiente sobre la operatividad de los controles cuando el riesgo es material, porque proceden precisamente de la parte cuyos controles se quieren evaluar; hay que pedir un bridge letter del auditor del proveedor o realizar procedimientos directos sobre el sub-período. En mi caso, la posición B gana porque la representación sustituye evidencia por una declaración interesada, y eso es exactamente lo que SSAE 18 §48 trata de evitar al exigir suficiencia y adecuación. La posición A es defendible cuando el sub-período es de pocas semanas y el riesgo no es focalizado, no cuando son tres meses sobre un control que toca un saldo material.

Por qué se acepta superficialmente

Hay una razón estructural por la que el SOC 2 acaba aceptándose con poca lectura, y conviene nombrarla. La metodología de la mayoría de firmas codifica un atajo: si hay informe de tercero, se documenta su recepción y se marca el riesgo como mitigado. Ese atajo nació para encargos donde el riesgo del proveedor era marginal y el coste de revisión era alto. Cuando el atajo se generaliza, se traslada a encargos donde el proveedor opera el motor de las existencias o de los cobros, y entonces la mitigación es nominal. Lo que sostiene el atajo no es la falta de competencia técnica, es la presión de fees combinada con la presión de horas de revisión: leer un SOC 2 con cuidado, mapear sus objetivos contra los riesgos del encargo y documentar la conclusión cuesta entre cuatro y ocho horas de un manager, y esas horas no están en el presupuesto del encargo medio. Mientras eso no cambie, el SOC 2 seguirá aceptándose superficialmente, no por descuido individual sino por diseño del sistema.

Mi opinión, dicho con todas las letras: aceptar un SOC 2 Tipo I cuando el riesgo del encargo exige evidencia operativa es un error técnico que se mantiene porque la metodología premia el cierre del riesgo sobre la calidad de la evidencia, y porque sacar adelante el encargo con lo que hay es lo que la cuenta de resultados de la oficina pide. El segundo motivo no es excusa del primero.

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 modificarse sin detección. - Confianza en la auditoría interna del cliente: cómo se evalúa la suficiencia de la evidencia que aporta la auditoría interna de un cliente. - Procedimientos de respuesta al riesgo: estrategias del auditor para obtener evidencia sobre riesgos importantes, incluyendo el uso de 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.