Informe SOC 1

Cómo funciona

Un informe SOC 1 se emite cuando una entidad proporciona servicios que afectan los registros contables, el procesamiento financiero o la generación de datos de otro usuario (el "usuario de la declaración"). El proveedor de servicios encarga al auditor que evalúe si sus controles internos fueron diseñados y operaron efectivamente durante el período de auditoría.
Bajo ISAE 3402 párrafo 3, el auditor debe obtener y evaluar evidencia sobre si los controles descriptos en la declaración de la entidad 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.
La distinción práctica entre Type I y Type II es crítica. Un informe Type I cubre solo el diseño de los controles en una fecha específica. Un informe Type II cubre el diseño y la operación efectiva durante un período de tiempo (típicamente un año). Un usuario de la declaración considerando un Type I como suficiente para reliance está tomando una decisión de riesgo significativa, porque el diseño no garantiza que los controles funcionaron durante los doce meses.
El auditor describe los controles que el proveedor de servicios ha asegurado que implementó. El auditor luego 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 encargó 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 descriptos estaban diseñados para prevenir o detectar errores y cumplieron su propósito operativamente durante todo el año.
Paso 1: Identificar los procesos y riesgos principal
El proveedor describe cinco procesos principales: (1) ingesta de datos de nómina desde sistemas de RR.HH. del cliente, (2) validación de tasas y conceptos contra tablas de impuestos del mes, (3) procesamiento y cálculo, (4) transferencia electrónica a bancos, (5) generación de recibos de nómina.
Nota de documentación: Se documentó 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 específicos. El auditor negocia cuáles cumplen con ISAE 3402 párrafo 5 (son relevantes para la probabilidad de que una aseveración pueda contener un error material y son controles sobre los que el usuario de la declaración podría reliar). Los doce se incluyen.
Nota de documentación: Matriz de controles–riesgos completada en PT-SOC-02. Se separaron claramente los controles operacionales (relevantes para SOC 1) de los controles administrativos (no incluidos).
Paso 3: Pruebas de diseño (aplicable a Type I y Type II)
Para cada control, el auditor:
Ejemplo: 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:
Ejemplo: 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:
Resultado de muestra: De 25 ciclos, 23 operaron 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 SOC 1.
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. Esto es tanto una deficiencia de control como un incumplimiento operacional documentado.
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.
Paso 6: Opinar
El auditor concluye si los controles descriptos fueron diseñados efectivamente y, para Type II, si operaron efectivamente durante el período. Con dos excepciones operacionales detectadas, el auditor puede emitir una opinión afirmativa con excepciones informadas, o una opinión calificada dependiendo de la materialidad de los errores que podrían haberse pasado por alto.
En este ejemplo, ninguna nómina se procesó con importes incorrectos como resultado de las excepciones no aprobadas (todas fueron corregidas antes de transferencia bancaria). El auditor emite 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 reliar en estos controles, no una promesa no verificada.

• 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
• Muestrear transacciones a través de cada mes y verificar que la lógica del control se aplicó
• Para controles manuales, verificar 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
• 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ó, cuándo y qué cambio se realizó
• Que la nómina se procesó y pagó después de que se resolvieron todas las excepciones

Lo que auditores y revisores obtienen mal

• 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. Muchos auditores prueban solo los últimos dos meses de un período de 12 meses porque "suficiente evidencia" no define el rango. ISAE 3402 párrafo 18 requiere que el auditor obtenga evidencia de que los controles operaron efectivamente "durante el período." Los inspectores internacionales han documentado casos donde auditores no reencontraron ciclos de revisión semanal (aproximadamente 48 ciclos en 12 meses) y en su lugar probaron 4. Esto infravalúa el riesgo de que el control no operara consistentemente.
• 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, una excepción debe reportarse. El auditor que no documenta períodos cuando el control no se ejecutó está enviando un mensaje falso sobre confianza. Esto no requiere que el control sea perfecto, pero requiere 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 específica (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–12 meses). El auditor prueba la operación mes a mes. Los usuarios finales confían 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 se cambió y nadie documentó cómo los controles se restablecieron después de cada cambio. A Type II mitigaría ese riesgo porque incluiría prueba de operación a través de esos cambios.

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