Controles principales vs. no principales en ISAE 3402

Contenido

1. Qué hace que un control sea 2. Criterios para controles 3. Marco de decisión práctica 4. Ejemplo trabajado: TecnoNómina S.L. 5. Lista de verificación práctica 6. Errores frecuentes 7. Donde la profesión legítimamente discrepa 8. Contenido relacionado

Qué hace que un control sea

Empecemos por el fallo, no por la definición. El error más caro que veo en encargos ISAE 3402 es el control automatizado de bajo nivel clasificado como porque "el sistema lo hace solo". El control "el sistema requiere autenticación" aparece en el 95% de los reportes ISAE 3402 que he revisado. Como si el resto del trabajo dependiera de eso.

ISAE 3402.23 establece que el service auditor debe obtener evidencia suficiente y apropiada para respaldar su opinión sobre el diseño y la eficacia operativa. La distinción /no-no aparece como tal en el estándar. Surge del párrafo 3402.25, que obliga al auditor a identificar los controles que abordan los riesgos relacionados con los objetivos de control especificados (los TPA, en la jerga del encargo).

Lo que realmente ocurre es que el auditor llega al kick-off, recibe el inventario del cliente, y la conversación que debería tener no la tiene. La conversación es: "Para cada control que tú marcas como, voy a comprobar qué TPA cubre, y para cada TPA voy a comprobar qué pasaría si este control fallara. Si la respuesta es 'nada material', el control no es aunque tú lo digas". Esa conversación cuesta horas. Y las horas no están en el presupuesto.

Por qué la distinción importa de verdad

En un Tipo II, los controles requieren prueba de diseño y de eficacia operativa durante todo el periodo. Los no-solo prueba de diseño. La diferencia en horas es enorme. Por eso la clasificación es la decisión que más mueve el coste del encargo, y también la que más review comments genera.

ISAE 3402.A25 explica que algunos controles pueden ser redundantes o complementarios sin afectar directamente la probabilidad de incorrección material. Un sistema puede tener un control automatizado que opera de forma continua y un control manual que opera como respaldo. Si el automatizado mitiga el riesgo a un nivel aceptable por sí solo, el manual puede ser no-. Por lo que conozco, esta es la única forma legítima de reducir el inventario de claves: demostrar redundancia con evidencia, no asumirla.

Criterios para controles

Evaluación directa del riesgo

El fallo aquí es clasificar como todo control que "suene importante". El criterio real es más estrecho. Un control es si su fallo, asumiendo que el resto opera, causaría una incorrección material en los estados financieros del usuario.

ISAE 3402.A26 sugiere considerar la magnitud potencial y la probabilidad. En un servicio de procesamiento de nóminas, un control que previene pagos a empleados inexistentes es porque su fallo sobrevalora directamente el gasto de personal del usuario. Un control que valida el formato del código postal del empleado no lo es. La dirección no afecta a las aseveraciones financieras.

En la práctica, eso significa que la prueba del 1-en-1 (¿qué pasa si solo este control falla?) es la única que sobrevive a una EQR seria.

Ausencia de controles compensatorios

El fallo aquí es evaluar cada control en aislamiento. ISAE 3402.27 permite considerar el efecto de otros controles. Si varios cubren el mismo riesgo, solo los necesarios para mitigarlo a nivel aceptable son.

En mi caso, cuando un cliente tiene 65 controles marcados como de un total de 78, la primera pregunta es: ¿cuántos pares de controles cubren exactamente el mismo TPA? Casi siempre hay al menos 10 ó 15. Eso reduce el inventario de claves antes de hacer scoping serio.

Sin embargo, la documentación tiene que aguantar. El auditor debe demostrar que los controles compensatorios son suficientes y que su diseño y operación se han probado. Decir "hay otro control" sin probarlo es marcar la casilla.

Vínculo con aseveraciones financieras

Un control se vincula a una o más aseveraciones: existencia, completitud, exactitud, corte, clasificación, derechos y obligaciones. Si no puedes vincularlo, los papeles están flojos.

Para una entidad de custodia de valores, un control de confirmación independiente de transferencias es (existencia, derechos). Un control de pausas obligatorias del operador no lo es. No hay aseveración detrás.

Marco de decisión práctica

Ejemplo trabajado: TecnoNómina S.L.

Escenario: TecnoNómina S.L., procesador de nóminas para 200 empresas españolas, 45.000 empleados/mes. En el scoping del Tipo II, el cliente entrega un inventario de 78 controles, 65 marcados como por el equipo interno de SOX-equivalente del cliente. Yo soy la service auditor.

La primera lectura del inventario me dice tres cosas. Primera: están metiendo todos los controles automatizados como por defecto. Segunda: hay controles de seguridad lógica de bajo nivel ("el sistema bloquea tras tres intentos fallidos") clasificados como que no se vinculan a ninguna aseveración financiera. Tercera, y aquí está la complicación: hay un control marcado como no- que es el único que previene una clase de error específica.

Vamos al detalle.

Control A: Aprobación electrónica de pagos > 5.000 €

Descripción: El sistema requiere aprobación del gerente para pagos superiores a 5.000 €.

Evaluación: 1. TPA: Prevenir pagos no autorizados (existencia) 2. Riesgo residual: Pagos no autorizados, gasto sobrevalorado en los EE.FF. del usuario 3. Compensatorios: Hay revisión mensual posterior. Posterior, no preventiva. 4. Materialidad: Pagos no autorizados pueden exceder fácilmente la materialidad agregada

Conclusión:.

Documentación: "Clasificado : cubre directamente el riesgo de pagos no autorizados con impacto material en gasto. La revisión mensual no previene el procesamiento."

Control B: Validación de formato de código postal de proveedor

Descripción: El sistema valida el formato del código postal en los datos maestros.

Evaluación: 1. TPA: Exactitud de datos maestros 2. Riesgo residual: Códigos postales mal formateados no afectan aseveraciones financieras 3. Compensatorios: El proveedor confirma su dirección al alta 4. Materialidad: Ninguna identificada

Conclusión: No-.

Control C: Conciliación diaria de pagos procesados vs registros

Descripción: Un empleado independiente concilia diariamente.

Aquí está la complicación. El cliente lo había marcado como no-. Su lógica: el Control A previene pagos no autorizados. Razonamiento incompleto.

Evaluación reclasificada: 1. TPA: Detectar errores de procesamiento (completitud y exactitud) 2. Riesgo residual: Sin esta conciliación, errores de procesamiento (no autorización; procesamiento) pasan desapercibidos. El Control A no los cubre. 3. Compensatorios: Ninguno detectivo a este nivel 4. Materialidad: Errores acumulados pueden exceder materialidad

Conclusión del auditor:. Reclasificado.

Documentación: "Reclasificado a por el service auditor. El cliente lo había clasificado como no-bajo la asunción de que el Control A cubría el riesgo. El Control A cubre autorización, no procesamiento. Este es el único control detectivo sobre completitud diaria. Su fallo permitiría acumulación de errores materiales no detectados."

Esa reclasificación es la entrega real del trabajo. No el inventario del cliente. La revisión independiente.

Lista de verificación práctica

1. Vincule cada control a un TPA y el TPA a una aseveración: sin vínculo, no es.

2. Evalúe el riesgo residual 1-en-1: asuma que solo ese control falla. Si nada material ocurre, no es.

3. Considere materialidad agregada: la suma de fallos potenciales en todos los usuarios.

4. Documente compensatorios con evidencia: decir "hay otro control" sin probar su diseño y operación es marcar la casilla.

5. Reclasifique cuando proceda: si el cliente marcó algo como no-y tu análisis dice, reclasifica y documenta el porqué. Esa es la entrega.

6. El test de la oración: si no puedes explicar en una oración por qué este control es, probablemente no lo sea.

Errores frecuentes

Donde la profesión legítimamente discrepa

Cuando un control está totalmente automatizado, hay dos escuelas. La primera dice que todo control automatizado vinculado a un TPA es por defecto, porque opera siempre que el sistema opera y por tanto su fallo es sistémico. La segunda dice que los controles automatizados requieren su propio análisis de riesgo de fallo, condicionado a la fortaleza de los controles generales de TI (cambios, accesos, operaciones). Si los ITGCs son débiles, el control automatizado pierde fiabilidad y su clasificación como puede no aportar más evidencia que un control manual bien probado.

Yo me inclino por la segunda. La automatización sin ITGCs sólidos es menos de lo que parece. Pero entiendo el argumento contrario y lo respeto: la consistencia de operación es real cuando los ITGCs aguantan.

La razón por la que esto se acumula en EQR

La razón por la que esta clasificación es donde se acumulan los review comments es que el coste de hacerla bien (mapear cada control contra los TPA y cada TPA contra el riesgo de materialidad) excede en horas la mayoría de los presupuestos ISAE 3402, entonces se acepta el inventario del cliente y la deuda técnica aparece en el EQR.

Estimado lector, si su encargo ISAE 3402 sale a presupuesto sin haber reclasificado ningún control del inventario del cliente, conviene preguntarse si el ejercicio se ha hecho. Por lo que conozco, no se ha hecho.

Veredicto

Tesis: la clasificación /no-debe ser un análisis del service auditor, no una aceptación del inventario del cliente.

Contraargumento del cliente: "Yo conozco mis controles mejor que tú; el inventario es mi responsabilidad". Es verdad parcial. El inventario es responsabilidad del cliente. La clasificación para fines del ISAE 3402 no lo es. ISAE 3402.25 y A26 colocan en el auditor la obligación de evaluar si los controles identificados abordan los riesgos relevantes a los TPA. Si el auditor delega esa evaluación, el encargo no se sostiene.

Veredicto: clasificar contra el mapeo de TPA y materialidad, no contra las etiquetas del cliente. Reclasificar cuando proceda. Documentar el porqué.

Contenido relacionado

- Glosario: Control interno - Definición de control interno y sus componentes según ISAE 3402 - Herramienta: Evaluador de riesgos ISAE 3402 - Calculadora interactiva para evaluar la clasificación de controles basada en riesgo y materialidad - Blog: Documentación de pruebas de controles ISAE 3402 - Guía sobre cómo documentar pruebas de diseño y eficacia operativa