Declaración de Control

Puntos para el auditor

- Un Tipo I documenta el diseño en una fecha. Un Tipo II documenta el diseño y el funcionamiento durante un período. La distinción no es trivial: en mi caso, los problemas vienen cuando un Tipo I se trata como si fuera Tipo II porque el equipo ya cerró el presupuesto. - ISAE 3402 párrafo 14 obliga a describir con precisión qué servicios y qué objetivos de control quedan cubiertos. En la práctica, eso significa que descripciones genéricas tipo "controles de acceso" no sirven al auditor de la entidad usuaria. - En las firmas no Big 4, los papeles están flojos en la unión entre evaluación de riesgos y control probado. Lo señalan tanto la inspección del ICAC como las revisiones EQR internas.

Por qué el Tipo I se sobrevende (y nadie lo dice en voz alta)

La firma negocia el alcance por precio. Cuando llega la ejecución y el cliente abre el armario, no encuentra los registros de autorización del último febrero, y el auditor descubre que vendió un Tipo II y el responsable del servicio no tiene el rastro completo. Entonces se "reescala" a Tipo I sin renegociar honorarios, y el informe sale con la fecha de cierre como si fuera suficiente.

ISAE 3402 párrafo 18 es claro: el Tipo II requiere pruebas de funcionamiento durante el período; el Tipo I no. Lo que realmente ocurre es que la portada del informe Tipo I dice "el control está diseñado adecuadamente al 30 de septiembre", y el auditor de la entidad usuaria lo lee como "el control cubre el periodo". El estándar no fuerza esa distinción en la carta de cobertura. Esa ambigüedad es la razón por la que los Tipo I terminan en expedientes de auditoría como si bastaran. (Esta es la pieza que no se aprende leyendo solo el estándar.)

Hay un incentivo perverso de fondo. El responsable del servicio no quiere pagar un Tipo II porque le obliga a mantener evidencia operativa cara durante doce meses. El socio del proveedor necesita el cliente y acepta el Tipo I. El auditor de la entidad usuaria, por su parte, ya tiene presupuesto cerrado y cambiar de alcance a mitad de campaña le rompe el margen del encargo. Los tres aceptan lo que hay. Y así se convierte el Tipo I en un sustituto del Tipo II, no por mala fe, sino por compresión presupuestaria simultánea en tres partes a la vez.

Confesión: yo lo hice mal una vez

En mi primer encargo con un proveedor de nómina mediano, acepté un Tipo I a 30 de septiembre como cobertura suficiente para una auditoría con cierre 31 de diciembre. Hice una "walk-through complementaria" en diciembre y di por cubierto el periodo de octubre, noviembre y diciembre. El revisor del expediente, en la siguiente campaña, me preguntó cómo demostraba el funcionamiento entre enero y septiembre. No lo demostraba. Asumía. La walk-through bridging que hice no era evidencia del funcionamiento de los nueve meses anteriores; era evidencia del diseño en una segunda fecha.

El principio que extraje (y que aplico desde entonces): un Tipo I a una fecha más una walk-through a otra fecha siguen siendo dos puntos en el tiempo. No son un período. Si el periodo importa para la auditoría del cliente, el Tipo II es el camino. Si no hay Tipo II, hay que hacer pruebas de control directas sobre las transacciones del cliente, no inferir desde el diseño del proveedor.

Dónde discrepan los socios

Hay un debate honesto en la profesión sobre esto. Conozco socios que defienden que un Tipo I más una walk-through del auditor de la entidad usuaria, hecha al final del período, basta para cerrar el gap, porque la walk-through demuestra que el control sigue diseñado igual y que el responsable no lo cambió. Su lógica: si el diseño es el mismo en dos fechas separadas y no hay indicios de cambio, la asunción de continuidad operativa del control es razonable bajo NIA-ES 330.

Otros socios, y aquí me incluyo, sostienen que esa walk-through bridging es ilusión. Demuestra el diseño, no el funcionamiento. Si en abril alguien con admin override autorizó pagos sin el segundo aprobador, ni el Tipo I de septiembre ni la walk-through de diciembre lo van a captar. Solo un Tipo II con muestreo del periodo lo detecta. Mi opinión está aquí porque, en los encargos que he llevado, las excepciones en periodos no cubiertos son justamente las que aparecen cuando hay rotación de personal o cambios de sistema sin documentar.

Las dos posturas son defendibles. Lo que no es defendible es no haber documentado cuál se aplicó y por qué.

Ejemplo práctico: Soluciones Digitales Ibéricas S.L.

Cliente: proveedor de servicios de procesamiento de nómina, con sede en Barcelona, atiende a 340 clientes de recursos humanos, ingresos anuales de 4,2 millones de euros.

Paso 1: Identificación de objetivos de control El responsable del servicio identifica que el control determinante es: "Todas las transacciones de nómina se procesan solo después de la autorización de dos personas independientes." El auditor documenta este objetivo de control en el memorando de planificación.

Nota de documentación: se registra en PT 1.2 (Descripción de objetivos de control).

Paso 2: Evaluación del diseño del control (Tipo I) El auditor entrevista al director de operaciones, revisa la configuración de permisos en el sistema de nómina y verifica que dos usuarios (no intercambiables) tienen acceso de autorización. Comprueba que el sistema rechaza cualquier pago sin ambas aprobaciones. Esto se documenta el 31 de octubre de 2024.

Nota de documentación: se adjunta evidencia (captura de pantalla del sistema, matriz de permisos, e-mail de confirmación) en PT 2.1 (Evaluación de diseño).

Paso 3: Pruebas de operación (Tipo II) Se emite un informe Tipo II cubriendo enero a octubre de 2024. El auditor selecciona una muestra de 40 transferencias de nómina del periodo (aproximadamente el 2,4% de las 1.680 transacciones procesadas). Para cada una, verifica en los registros del sistema que dos autorizaciones independientes aparecen antes del desembolso.

Nota de documentación: se prepara el resumen de pruebas en PT 3.2 (Resultados de las pruebas de funcionamiento), detallando el método de muestreo, el tamaño de la muestra y los resultados.

Paso 4: la complicación que cambia la conclusión Una de las 40 transacciones muestreadas (la número 27, fecha 14 de junio de 2024) presenta dos identificadores de aprobador, pero al revisar el log técnico el equipo ve que el segundo aprobador no es un usuario operativo: es un usuario con admin override que el responsable del servicio dejó activo "para emergencias". Técnicamente el sistema registró dos firmas. Funcionalmente fue una sola persona aprobando con dos sombreros.

Aquí el equipo se divide. Una postura: es una excepción aislada, ISAE 3402 párrafo 20 permite excepciones poco frecuentes y no sistémicas, una entre 1.680 no invalida la opinión Tipo II. Otra postura: el admin override no es una excepción aislada, es un agujero de diseño que estuvo activo todo el periodo, y por tanto la cuestión no es la frecuencia de uso sino la frecuencia de oportunidad. El primer ángulo trata el incidente como evento; el segundo lo trata como condición.

En mi caso, la opinión profesional pesa hacia el segundo ángulo, porque el admin override no es algo que ocurrió: es algo que pudo ocurrir cualquier día del periodo y nadie habría sabido. Eso son bombas de relojería, no excepciones. La conclusión razonable es opinión calificada en ese objetivo de control, con descripción explícita del admin override, no opinión limpia con nota al pie.

Nota de documentación: la deliberación entre las dos posturas se documenta en PT 3.5 (Evaluación de excepciones), con cita expresa a ISAE 3402 párrafo 20 y al juicio del socio responsable.

Tipo I vs. Tipo II: cuándo aplicar cada uno

Errores recurrentes (lo que vemos en revisión EQR)

- Tipo II vendido como Tipo I durante la ejecución: la firma firma un Tipo II en propuesta y luego, cuando los registros operativos no aparecen, "ajusta" a Tipo I sin documentar el cambio de alcance. Desde nuestra experiencia, eso pasa más cuando el responsable del servicio cambia de software a mitad de año. ISAE 3402 párrafo 18 obliga a probar el funcionamiento si el informe se titula Tipo II. Si no hay registros, no hay Tipo II, hay otra cosa.

- Brecha entre evaluación de riesgos y control probado: muchos equipos saltan al test sin documentar qué riesgo de negocio mitiga cada control. ISAE 3402 párrafo 15(a) exige evaluar si los controles están diseñados apropiadamente, y eso requiere evaluación del riesgo primero. Lo que realmente ocurre es que el papel de trabajo enseña el control y la prueba, pero no el "por qué" del control. El revisor lo ve y pone non-conformidad.

- Descripciones de control demasiado anchas: ISAE 3402 párrafo 14 pide descripciones precisas. Cuando el informe dice "controles de acceso a sistemas" y nada más, el auditor de la entidad usuaria no puede vincularlo a su riesgo de aseveración sin trabajo extra. Falta chicha en la descripción y eso debilita la utilidad del informe entero.

- Cambios de control no documentados durante el período Tipo II: ISAE 3402 párrafo 19 obliga a documentar los cambios y su efecto. Si el responsable del servicio migró de Sage a otra plataforma en mayo, eso se reporta. En la práctica, se reporta cuando se acuerda; no se reporta si nadie del equipo de auditoría preguntó.

- Excepciones tratadas como binarias: una excepción no invalida automáticamente el Tipo II (ISAE 3402 párrafo 20), pero tampoco se ignora. Se cuenta, se clasifica (aislada vs. sistémica) y se documenta su materialidad. Marcar la casilla de "una excepción, sin más" no cumple el estándar.

Cuándo la distinción importa en un encargo real

Suponga un auditor externo evaluando los controles de un proveedor de servicios compartidos de tesorería. El cliente del proveedor ejecuta miles de transacciones de tesorería al mes a través del proveedor. El auditor del cliente debe evaluar si la segregación de funciones en la autorización de transferencias opera efectivamente durante todo el ejercicio.

Si solo hay Tipo I a 30 de septiembre, ese informe cubre una fecha. La auditoría cubre enero a diciembre. Quedan once meses sin evidencia directa del funcionamiento del control. Hay que sacar adelante el encargo con lo que hay, y eso significa pruebas de control directas sobre las transacciones del cliente, no descansar sobre el ISAE 3402.

Un Tipo II cubriendo enero a diciembre cierra esa brecha. El auditor puede reducir sustancialmente sus propias pruebas de segregación de funciones porque el informe ya proporciona evidencia del funcionamiento del control durante el período relevante para la auditoría del cliente.

Aviso. La reducción no es automática. Hay que leer la descripción de excepciones del Tipo II antes de descansar sobre él.

Términos relacionados

Informe de control Tipo II - Declaración de control que cubre un período y proporciona evidencia de que los controles funcionaron efectivamente durante ese período.

ISAE 3402 - Norma Internacional de Encargos de Aseguramiento que establece los requisitos para que los auditores emitan informes de control sobre servicios.

Segregación de funciones - Control que separa responsabilidades para autorizar, registrar y custodiar transacciones, mitigando el riesgo de fraude o error.

Evaluación de riesgo de control - Proceso mediante el cual los auditores determinan el nivel de riesgo asociado con el funcionamiento deficiente de un control identificado.

Informe de control Tipo I - Declaración de control que describe solo el diseño de controles en una fecha específica, sin pruebas de funcionamiento.

Procedimientos analíticos en encargos de control - Técnicas que los auditores usan para validar la consistencia de datos o patrones de transacciones bajo los controles descritos.

Glosario interno: términos usados en este texto

- Responsable del servicio: la entidad que proporciona servicios y mantiene los controles descritos en el informe. - Objetivos de control: los objetivos específicos de negocio que cada control está diseñado para lograr. - Pruebas de funcionamiento: las transacciones, registros o interacciones que el auditor examina para verificar que un control operó durante el período cubierto. - Admin override: permiso técnico que permite a un usuario saltarse controles aplicativos. Suele ser legítimo en producción, pero invalida la segregación de funciones si está activo en cuentas operativas.

---