Informe SOC 1

Cómo funciona

Lo que realmente ocurre primero: el auditor del usuario final recibe un PDF de 80 páginas, hojea la opinión del último apartado, comprueba que no hay salvedades y archiva el documento como evidencia de control externo. Eso pasa más veces de las que la profesión admite. La norma exige otra cosa.

ISAE 3402 párrafo 3 obliga al auditor del proveedor a obtener y evaluar evidencia sobre si los controles descritos en la declaración fueron diseñados adecuadamente y operaron efectivamente. Esto no es una auditoría de cumplimiento normativo ni una auditoría de estados financieros. Es una evaluación específica de los controles que afectan a usuarios.

El SOC 1 Type II es un contrato narrativo. El proveedor describe el control. El auditor prueba si el control hizo lo que decía. Cuando se acepta un Type I como Type II, lo que se acepta es la promesa, no la prueba.

Un informe Type I cubre solo el diseño de los controles en una fecha específica. Un Type II cubre el diseño y la operación efectiva durante un período (típicamente un año). Un usuario de la declaración que considera un Type I como suficiente para apoyarse en él toma una decisión de riesgo seria, porque el diseño no garantiza que los controles funcionaron durante los doce meses.

El auditor del proveedor describe los controles que la dirección ha asegurado que aplicó. Después prueba si esos controles existieron y funcionaron. Si encuentra que un control no operó como se describió, debe reportar una excepción (una deficiencia en el diseño o la operación del control).

Ejemplo práctico: Soluciones de Nómina Ibérica S.L.

Cliente: Proveedor de servicios de procesamiento de nóminas, con sede en Barcelona, que sirve a 340 empresas clientes en España y Portugal. Procesa aproximadamente 120.000 registros de nóminas mensuales. Mantiene una descripción de sus controles internos y los sistemas subyacentes.

Escenario: Se encarga un informe SOC 1 Type II por el período del 1 de enero al 31 de diciembre de 2024. El auditor debe determinar si los controles descritos estaban diseñados para prevenir o detectar errores y si cumplieron su propósito operativamente durante todo el año.

Paso 1: Identificar los procesos y riesgos principal El proveedor describe cinco procesos: ingesta de datos de nómina desde sistemas de RR.HH. del cliente, validación de tasas y conceptos contra tablas de impuestos del mes, procesamiento y cálculo, transferencia electrónica a bancos, generación de recibos de nómina.

Nota de documentación: Se documenta el alcance de los servicios, la arquitectura de sistemas y la lista de riesgos identificados por la dirección en el papel de trabajo PT-SOC-01.

Paso 2: Definir los controles a reportar La dirección describe doce controles concretos. El auditor negocia cuáles cumplen con ISAE 3402 párrafo 5 (controles relevantes para la probabilidad de que una aseveración pueda contener un error material y sobre los que el usuario de la declaración podría apoyarse). Los doce se incluyen.

Nota de documentación: Matriz de controles–riesgos completada en PT-SOC-02. Se separan claramente los controles operacionales (relevantes para SOC 1) de los administrativos (no incluidos).

Paso 3: Pruebas de diseño (aplicable a Type I y Type II) Para cada control, el auditor: - Inspecciona la documentación de configuración del sistema (pantallas de setup, reglas de validación programadas, registros de autorización) - Verifica que el control existe como se describió - Documenta el estado de diseño

Ejemplo de control descrito: "Se ejecuta validación automática cada noche para identificar importes de nómina fuera de rango esperado. Los importes que exceden los parámetros generan una excepción que requiere aprobación de autoridad designada antes del procesamiento."

Prueba de diseño: acceso al código fuente de la regla de validación, confirmación de que los parámetros de rango se ajustan mensualmente según las nóminas históricas, confirmación de que el sistema requiere aprobación manual para excepciones.

Resultado: diseño confirmado.

Nota de documentación: Pantalla de configuración capturada, parámetros de rango documentados, evidencia de aprobación manual para tres excepciones de muestra en PT-SOC-03.

Paso 4: Pruebas de operación efectiva (Type II únicamente) Para un Type II, el auditor también verifica que cada control funcionó durante el período de 12 meses. Esto significa muestrear transacciones a través de cada mes y verificar que la lógica del control se aplicó. Para controles manuales, comprobar que la autoridad designada firmó o documentó de forma oportuna. Para controles automáticos, obtener registros de ejecución que demuestren que se ejecutaron, identificaron excepciones y se procesaron correctamente.

El auditor muestrea 25 ciclos mensuales de validación de nómina (aproximadamente dos por mes para un período de 12 meses). Para cada ciclo verifica que el trabajo de validación se ejecutó en la fecha esperada (registro de programa), cuántas excepciones fueron identificadas y registradas, para cada excepción quién la aprobó y cuándo, y que la nómina se procesó y pagó después de que se resolvieron todas las excepciones.

Resultado de muestra: de 25 ciclos, 23 operan según diseño. En dos ciclos (junio y octubre), se identificaron excepciones pero no hubo evidencia de aprobación antes del procesamiento. El sistema procesó las excepciones de todas formas, un incumplimiento de la descripción del control.

Nota de documentación: Resultados de prueba documentados en PT-SOC-04. Excepciones no aprobadas remitidas a la dirección como deficiencia potencial para descripción en el informe.

Paso 5: Evaluar deficiencias y excepción Las dos excepciones no aprobadas representan casos donde el control no operó como se describió. El auditor determina si esto es una "excepción" a reportar (una instancia en la cual el control no previno o detectó un error material) o una "deficiencia" (un problema subyacente en el diseño o la cultura de control).

En este caso, la causa raíz fue que un nuevo aprobador fue asignado en septiembre pero el sistema no fue actualizado para requerir su aprobación para excepciones en su área de responsabilidad. El control sobre el que pesa la opinión SOC 1 nunca es el más vistoso, es el más aburrido: la matriz de autorización del sistema cuando entra un nuevo aprobador. Eso es lo que falla en silencio durante meses sin que nadie lo note, hasta que el inspector lo busca.

Nota de documentación: Informe de deficiencias completado en PT-SOC-05 con recomendación: actualizar matriz de autorización en el sistema y capacitar a nuevos aprobadores en políticas de excepciones.

Complicación El informe SOC 1 entregado en marzo cubre el año natural 2024. El cliente de nómina tiene cierre en septiembre. ¿Vale el SOC 1 para los meses de octubre, noviembre, diciembre? El auditor del usuario final tiene tres meses sin cobertura, y nadie en la firma del proveedor le quiere extender el período de prueba sin honorarios adicionales. En la práctica, lo que se hace es pedir una "carta puente" del proveedor confirmando que no ha habido cambios materiales en los controles. Esa carta no es evidencia de auditoría, es una declaración de la dirección. Quien acepta esa carta como sustituto del SOC 1 está sacando adelante el encargo con lo que hay.

Paso 6: Opinar Aquí no hay una sola respuesta correcta. Dos socios experimentados pueden discrepar legítimamente.

Partner A: con 25 ciclos sobre 250-300 mensuales, dos excepciones es ruido aceptable. Sigo con opinión limpia, salvedad informativa, archivo.

Partner B: dos excepciones operacionales en una muestra de 25 es 8%. No es ruido. Eso son 24 fallos proyectados al año. Opinión calificada, ampliación de muestra, o las dos cosas.

En este ejemplo, ninguna nómina se procesó con importes incorrectos como resultado de las excepciones no aprobadas (todas fueron corregidas antes de la transferencia bancaria). El auditor opta por una opinión calificada: "En todos los aspectos materiales, los controles estuvieron diseñados efectivamente y operaron efectivamente durante el período, excepto que se identificaron dos instancias donde se procesaron cambios de nómina sin aprobación requerida, como se describe en la sección de excepciones."

Conclusión: Este enfoque demuestra que un auditor SOC 1 no reporta lo que la dirección afirma. Prueba el diseño, muestrea la operación durante 12 meses y documenta dónde la realidad se desvió de la descripción. Los usuarios de la declaración reciben una evaluación defensible de si pueden confiar en estos controles, no una promesa no verificada — el equivalente operativo, si se quiere, a la imagen fiel.

Lo que auditores y revisores obtienen mal

Hemos visto auditorías de usuario final apoyarse en Type I emitidos meses antes del cierre, sin extender el alcance ni pedir prueba operativa. La trampa nunca está en lo que el SOC 1 dice. Está en lo que el auditor del usuario final no le pide.

- Confundir el alcance SOC 1 con una auditoría de cumplimiento normativo. ISAE 3402 párrafo 1 es claro: el objetivo es formar una opinión sobre si los controles internos fueron diseñados y operaron efectivamente. Esto no es una auditoría de cumplimiento con regulaciones (NIA-ES 250); es una evaluación de diseño y operación de controles. Un auditor que asegura "el proveedor cumple con la ley" cuando debería asegurar "estos controles operaron como se describió" ha cambiado la aseveración central. La diferencia importa porque los usuarios finales necesitan saber si pueden confiar en los datos procesados, no si el proveedor siguió regulaciones.

- No probar la operación durante períodos suficientemente largos en Type II. Aquí los papeles están flojos en muchos encargos. Falta chicha. Muchos auditores prueban solo los últimos dos meses de un período de 12 porque "suficiente evidencia" no define el rango. ISAE 3402 párrafo 18 exige que el auditor obtenga evidencia de que los controles operaron efectivamente "durante el período". Los inspectores internacionales han documentado casos donde los auditores no probaron ciclos de revisión semanal (aproximadamente 48 ciclos en 12 meses) y en su lugar probaron 4. Eso infravalora el riesgo de que el control no operara consistentemente. ¿Por qué se hace? Porque el socio necesita el cliente y la propuesta económica no daba para más horas. No es una explicación cómoda, pero es la que se oye en los pasillos.

- Reportar la descripción del control como opción, no como contrato. Un usuario de la declaración lee "se ejecuta validación automática cada noche" e imagina que sucedió cada noche. Si sucedió algunas noches o fue deshabilitado durante "mantenimiento" sin reinicialización documentada, debe reportarse una excepción. El auditor que no documenta períodos cuando el control no se ejecutó está enviando un mensaje falso sobre confianza. No requiere que el control sea perfecto, pero sí transparencia total sobre cuándo y dónde no funcionó como se describió.

Cuando usar un informe Type I vs Type II

Type I: El proveedor de servicios es nuevo, está pilotando un control, o el usuario solo necesita confirmar el estado del control en una fecha concreta (por ejemplo, "¿existen los controles de acceso que aseguraron?"). El auditor examina documentación, entrevista al personal y verifica que los controles existen en la fecha de prueba. Sin ejecución futura verificada.

Type II: El proveedor ha operado y el usuario necesita confianza en que los controles funcionaron durante un período operacional real (normalmente 6 a 12 meses). El auditor prueba la operación mes a mes. Los usuarios finales se apoyan más en Type II porque la evidencia es más sustancia sobre la efectividad real.

Cuándo importa la distinción en la práctica: un auditor de usuario final que acepta un Type I de hace 18 meses para un proveedor de servicios crítico está confiando en que nada cambió en el control durante ese tiempo. Cuando la realidad es que el sistema se actualizó tres veces, el personal de control rotó y nadie documentó cómo los controles se restablecieron después de cada cambio. Un Type II mitigaría ese riesgo porque incluiría prueba de operación a través de esos cambios. Vaya por delante que la decisión de aceptar o no ese Type I de 18 meses es del auditor del usuario final, no del proveedor — y es una decisión de riesgo, no de comodidad.

Términos relacionados

- ISAE 3402: la norma que rige toda emisión de informes SOC 1 y SOC 2, define cómo el auditor prueba controles en proveedores de servicios - Controles relevantes: un término técnico de ISAE 3402 que significa controles cuya falla podría permitir un error material en los registros del usuario final - Informe SOC 2: reporte de seguridad, confiabilidad y confidencialidad emitido bajo ISAE 3402 para usuarios de servicios en la nube - Declaración de entidad de servicio: el documento que describe los controles que el proveedor de servicios afirma tener; el auditor prueba si son reales - Excepción SOC 1: una instancia individual donde un control no previno o detectó un error material; se reporta en el informe - Deficiencia de control: un problema subyacente en el diseño o la aplicación de un control; la causa raíz de una o más excepciones

---