Definition
Pida a un proveedor de servicios en la nube un "informe de control" y le van a enviar un SOC 2. Usted lo abre esperando encontrar evidencia de que los controles sobre la autorización de facturas o la conciliación de ingresos fueron probados, y lo que encuentra son pruebas de penetración, encriptación en tránsito y gestión de acceso físico a centros de datos. Por lo que he visto en los encargos que he llevado, esto pasa en la mayoría de primeras solicitudes: el equipo de auditoría no especificó qué tipo de informe SOC necesitaba, y el proveedor envió el que tenía a mano.
Cómo funcionan estos tres estándares
Un proveedor de servicios (por ejemplo, una plataforma de nómina o un procesador de pagos) opera sistemas que afectan a múltiples clientes. Cada cliente necesita evaluar si los controles del proveedor son suficientes para que el auditor del cliente pueda colocar algo de confianza en ellos. El AICPA creó la familia SOC para describir esos controles de forma estandarizada.
SOC 1 se dirige a auditores de usuarios finales. El auditor de la empresa cliente necesita evaluar el riesgo de que los datos financieros que pasan por el proveedor de servicios contengan errores por debajo de la materialidad del cliente. Según NIA-ES 402, el auditor de la organización que usa el servicio debe obtener evidencia suficiente y apropiada sobre los controles en el proveedor de servicios. Un informe SOC 1 Tipo II (que cubre un período de operación, típicamente de 6 a 12 meses) proporciona esa evidencia. Un auditor externo que recibe un informe SOC 1 sin salvedades puede reducir el nivel de procedimientos sustantivos en ciertos ciclos de transacciones, siempre que haya validado la designación de auditor SOC 1 y verificado la integridad del informe.
SOC 2 se dirige a cualquier parte interesada que necesite garantías sobre controles que no son financieros por naturaleza. Los criterios de servicios de confianza del AICPA definen cinco dimensiones: seguridad (protección contra acceso no autorizado), disponibilidad (el sistema está disponible para su uso previsto), confidencialidad (la información protegida se divulga solo a partes autorizadas), integridad (la información es precisa, completa y autorizada) y privacidad (la información personal se recopila, usa y divulga de acuerdo con la política declarada). Un proveedor de servicios de salud en la nube obtendría un informe SOC 2 para demostrar que tiene controles de seguridad, disponibilidad e integridad. Un banco tecnológico obtendría un informe SOC 2 que cubre los cinco criterios.
SOC 3 es la versión resumida y sin restricciones de SOC 2. Donde SOC 2 es un informe de 30 a 50 páginas dirigido a usuarios que pueden actuar sobre los resultados (auditores internos, reguladores, auditores externos), SOC 3 es una declaración de una página que el proveedor de servicios puede publicar en su sitio web diciendo "hemos sido auditados bajo SOC 2 y no se identificaron deficiencias significativas." SOC 3 no proporciona ningún detalle sobre qué se probó o cómo; es una señal de confianza de marketing.
Tabla comparativa: SOC 1, SOC 2, SOC 3
No es posible elegir el informe SOC correcto si usted no tiene claro qué va a hacer con él. El error por defecto es pedir "el informe SOC" al proveedor y aceptar lo que le entreguen.
| Dimensión | SOC 1 | SOC 2 | SOC 3 |
|---|---|---|---|
| Audiencia objetivo | Auditores de clientes que usan el servicio | Usuarios internos, reguladores, auditores internos, auditores externos | Público general, sitio web del proveedor |
| Criterios de control | Controles relevantes para la auditoría financiera de la organización cliente | Seguridad, disponibilidad, integridad, confidencialidad y privacidad del proveedor de servicios | Idéntico a SOC 2 (resumen de 2-3 páginas) |
| Período cubierto | Tipo I (punto en el tiempo) o Tipo II (mínimo 6 meses de operación) | Tipo I o Tipo II (típicamente 12 meses) | Punto en el tiempo basado en SOC 2 más reciente |
| Distribución | Bajo acuerdo de confidencialidad; solo para usuarios autorizados del proveedor | Bajo acuerdo de confidencialidad; clientes específicos, reguladores | Sin restricción; publicado públicamente |
| Opinión del auditor | "Conforme" o "no conforme en aspectos especificados" | "Conforme" o "no conforme en aspectos especificados" | Resumen: presencia o ausencia de deficiencias significativas |
| Procedimientos de auditoría | Pruebas de controles diseñados para reducir el riesgo de auditoría en transacciones financieras | Pruebas de controles operacionales y técnicos; sin enfoque en el riesgo de auditoría financiera | Resumen narrativo sin detalle técnico |
Donde empieza el juicio profesional: decidir si el informe SOC que recibió del proveedor cubre los controles relevantes para el ciclo de transacciones que usted está auditando, o si necesita solicitar un tipo diferente.
Cuándo la distinción importa en un encargo de auditoría
Supongamos que está auditando Grupo Logístico Andaluz S.L., una empresa de distribución con ingresos de 18,5 millones de euros. Usan una plataforma de facturación en la nube alojada por CloudPayments Ibérica. Usted necesita evaluar si puede confiar en que los datos de facturación registrados en el módulo de ingresos de CloudPayments son precisos y están autorizados.
Solicita a CloudPayments un informe de control. Recibe un informe SOC 2. Lo abre y espera ver evidencia de que los controles de acceso, autorización e integridad de datos fueron probados. En cambio, ve principalmente controles de seguridad de la infraestructura: encriptación en tránsito, pruebas de penetración, gestión de acceso físico a centros de datos. Estos controles son valiosos para la seguridad general, pero no le dicen nada sobre si los registros de facturación fueron autorizados correctamente o si el cálculo del IVA es correcto.
Lo que necesita es un informe SOC 1. Un SOC 1 habría incluido procedimientos de auditoría específicos para los controles de autorización de facturas, las validaciones de impuestos y la conciliación del libro mayor de ingresos. El auditor de CloudPayments habría probado que los cambios no autorizados en las tarifas de facturación se rechazaban automáticamente, y que los reportes de ingresos se reconciliaban mensualmente con datos de facturación de origen. Con un SOC 1 Tipo II (que cubre 12 meses de operación), usted puede reducir el número de transacciones de ingresos que prueba manualmente, porque la evidencia del control del proveedor respalda el enfoque.
Si Grupo Logístico Andaluz también quisiera publicar en su memoria de sostenibilidad que su infraestructura de pagos es segura, podrían obtener un informe SOC 3 de CloudPayments. Esto les permitiría incluir una línea de confianza en su informe anual sin exponer los detalles técnicos de los controles. Pero el SOC 3 no ayudaría a su auditoría financiera.
Documentación: en el expediente de ingresos, usted registraría: "Recibido informe SOC 1 Tipo II de CloudPayments (período: 1/1/2024-31/12/2024). Auditor: [nombre]. Sin salvedades identificadas. Procedimientos de auditoría de [especificar ciclo] reducidos en línea con NIA-ES 402.25."
Socio A frente a Socio B
Dos socios del mismo despacho revisan si un informe SOC 2 de CloudPayments es suficiente para el encargo de Grupo Logístico Andaluz.
Socio A dice que sí. "El SOC 2 cubre seguridad e integridad. La integridad del procesamiento incluye que los datos son precisos y están autorizados. Eso es lo que necesitamos para el ciclo de ingresos. Solicitar un SOC 1 adicional va a retrasar el encargo dos meses y el cliente no va a pagar las horas extra." Su razonamiento: la NIA-ES 402 no prohíbe usar un SOC 2 si cubre los controles relevantes, y "integridad" es suficientemente amplia.
Socio B no está de acuerdo. "La integridad en SOC 2 se refiere a integridad del procesamiento del sistema, no a integridad de las transacciones financieras que pasan por ese sistema. NIA-ES 402.25 pide evidencia sobre controles relevantes para la auditoría financiera del cliente. El SOC 2 no probó si la conciliación de ingresos funciona ni si los cambios de tarifas están autorizados. Los papeles están flojos y en una inspección del ICAC nos van a pedir explicaciones."
Lo que los revisores y auditores internos confunden
Hay un incentivo perverso de conveniencia. Solicitar un SOC 1 al proveedor es un proceso que puede tardar semanas o meses. El proveedor ya tiene un SOC 2 preparado y listo para enviar. El equipo de auditoría está en campaña, las horas están computadas, y nadie quiere ser el que diga "necesitamos parar hasta que llegue el SOC 1." El resultado es que muchos equipos aceptan el SOC 2 porque es lo que hay, documentan "informe de control recibido", y fue un trámite.
Usar un SOC 2 como base para reducir procedimientos sustantivos de ingresos es un error de inspección frecuente. Los auditores confían en un informe SOC 2 de un procesador de pagos para reducir las pruebas de autorización de ingresos. El SOC 2 proporciona garantías sobre la seguridad de la infraestructura, pero no es suficiente para cumplir la NIA-ES 402.25, que requiere evidencia sobre controles relevantes para la auditoría financiera. Un SOC 1 Tipo II es el artefacto de evidencia correcto. La confusión surge porque los proveedores de servicios publican "tenemos un informe SOC 2" sin aclarar que también pueden obtener un SOC 1 si lo pide el cliente.
No solicitar un informe SOC 1 Tipo II con un período de cobertura adecuado es otro problema habitual. Cuando un cliente se integra con un proveedor de servicios antes del final de su año fiscal (por ejemplo, migrando a CloudPayments en octubre), algunos auditores aceptan un SOC 1 Tipo I (punto en el tiempo en septiembre) como evidencia para octubre a diciembre. La NIA-ES 402 requiere un período de operación suficiente para evaluar la eficacia del control (típicamente un mínimo de 6 meses, 12 meses es preferible). Un Tipo I captura un solo punto en el tiempo y no proporciona evidencia de que el control funcionara de forma consistente. El auditor debe documentar por qué el período reducido de cobertura es suficiente para su evaluación del riesgo de auditoría.
Aceptar un informe SOC 3 como sustituto de due diligence de controles también ocurre. Algunos auditores menos experimentados ven que un cliente es una entidad controladora de un grupo tecnológico y que ese grupo "tiene un informe SOC 3 publicado." Aceptan esto como garantía de control. Un SOC 3 es una declaración de una página sin detalles. No reemplaza el análisis de controles específicos de la entidad cliente bajo auditoría. Si la empresa cliente ejecuta sus propios servidores o aplica un software licenciado diferente, los controles de SOC 3 de su proveedor tecnológico padre no son relevantes.
Términos relacionados
- ISA 402: el estándar internacional que gobierna cómo un auditor obtiene evidencia sobre controles en proveedores de servicios. Requiere que el auditor de la organización cliente determine si puede confiar en los controles del proveedor y, en caso afirmativo, qué evidencia necesita para hacerlo - Informe ISAE 3402: en jurisdicciones que no usan SOC (principalmente fuera de Estados Unidos), ISAE 3402 proporciona el marco equivalente para que un auditor de servicios emita un informe sobre los controles en un proveedor de servicios - Carta de gestión de proveedores de servicios: una carta del auditor del proveedor de servicios al auditor del cliente, explicando el alcance, los criterios de control y cualquier salvedad o deficiencia identificada en el informe de control - Deficiencias en los controles: resultados documentados en un informe SOC 1 o SOC 2 donde un control no fue diseñado para ser efectivo, o funcionó de manera incompleta durante el período cubierto - Período de cobertura de un informe de control: el período de tiempo durante el cual el auditor del proveedor de servicios probó los controles. Un Tipo I es un punto en el tiempo; un Tipo II es un período mínimo de 6 a 12 meses - Riesgo de auditoría relacionado con el proveedor de servicios: el riesgo de que los controles insuficientes en un proveedor de servicios resulten en errores en los datos o transacciones que se registran en el cliente y que no sean detectados por los procedimientos de auditoría del cliente
---