aspectos central
Los controles generales de TI crean el cimiento sobre el que se basan todos los controles de aplicación; si fallan, ningún control específico puede ser confiable.
La mayoría de las deficiencias identificadas en auditorías se relacionan con acceso insuficiente a sistemas o cambios no documentados, no con fallos catastróficos de seguridad.
Documentar qué controles generales de TI existen requiere entrevistar a la persona responsable de TI y después verificar que funcionan (no solo que están diseñados).
Cómo funcionan
Los controles generales de TI forman la base del entorno de control de una entidad. La NIA-ES 315.29 requiere que el auditor comprenda cómo la tecnología afecta a la capacidad de la entidad para mantener la integridad de la información financiera.
En la práctica, esto significa tres categorías de control:
Controles de acceso. Quién puede hacer qué en qué sistema, cuándo, y desde dónde. Incluye autenticación (contraseñas, autenticación de dos factores), autorización (permisos específicos por usuario o rol), y segregación de funciones (la persona que autoriza un pago no puede procesarlo). La NIA-ES 315.A108 señala que la segregación de funciones es particularmente relevante cuando un sistema pequeño concentra funciones que en un entorno manual estarían separadas.
Controles sobre cambios. Cómo se modifican, prueban e implementan los cambios en los sistemas que procesan datos financieros. Incluye documentación del cambio, aprobación antes de la aplicación, prueba en un entorno de prueba, y registro del cambio implementado. Sin esto, nadie sabe qué hace el sistema hoy.
Controles operacionales. Cómo se mantiene la disponibilidad del sistema: copias de seguridad, recuperación ante desastres, monitoreo de acceso, revisión de logs. Estos controles detectan problemas y permiten la recuperación si algo falla.
Los auditores no son especialistas en TI, pero necesitan entender lo suficiente para evaluar el riesgo de error. La pregunta es: ¿si el sistema cambiara sin que nadie lo supiera, o si alguien accediera a datos que no debería, nos enteraríamos? Si la respuesta es no, entonces los controles generales de TI son deficientes.
Ejemplo práctico: Distribuidora Albacete S.L.
Cliente: Distribuidora mayorista de materiales de construcción, facturación anual 6,8 millones de euros, reporta bajo PGC, un empleado a tiempo parcial responsable de TI.
Paso 1: Entrevista inicial sobre el entorno de TI
El auditor pregunta qué sistemas procesa datos financieros. La respuesta: ERP de escritorio comprado en 2015, contabilidad en Excel, nóminas en software separado.
Nota de documentación: PT 3.1: Matriz de sistemas identificados y alcance de datos financieros.
Paso 2: Evaluación del acceso
El auditor pregunta cuántas personas pueden cambiar movimientos contables en el ERP. La respuesta es: el director, el contable, y el gerente de almacén (que "a veces" necesita ajustar inventario). El ERP no registra quién hizo qué cambio, ni cuándo.
Nota de documentación: PT 3.2: Matriz de usuarios y permisos; hallazgo: no hay segregación de funciones entre autorización y procesamiento.
Paso 3: Evaluación de cambios
El auditor pregunta cómo se actualiza el software. La respuesta: "Cuando salen actualizaciones, el proveedor nos las instala, o nosotros las instalamos." No hay documentación del cambio, no hay prueba en ambiente separado, no hay aprobación formal previa.
Nota de documentación: PT 3.3: Procedimiento de cambios; hallazgo: cambios no documentados ni probados.
Paso 4: Evaluación de copias de seguridad y recuperación
El auditor pregunta cómo se protege contra pérdida de datos. La respuesta: "La máquina está en el despacho del director. Hacemos copia de seguridad una vez a la semana en un USB externo."
Nota de documentación: PT 3.4: Procedimiento de copias de seguridad; hallazgo: copias almacenadas en la misma ubicación que los servidores; sin prueba de recuperación.
Conclusión: Distribuidora Albacete tiene controles generales de TI deficientes. El riesgo de que datos financieros se modifiquen sin registro, que cambios se implementen sin prueba, o que datos se pierdan sin recuperación es alto. El auditor elevaría el riesgo evaluado de error a nivel de aseveración, extendería las pruebas de controles, e implementaría procedimientos sustantivos más amplios sobre movimientos contables y completitud de registros.
Qué revisores y auditores entienden mal
- La creencia de que controles generales "fuertes" requieren inversión tecnológica grande. La NIA-ES 315.A108 pone el énfasis en la segregación de funciones y la documentación. Una pequeña distribuidora con un ERP antiguo que tiene roles definidos, registro de cambios, y copias de seguridad documentadas supera a una empresa moderna con software cloud pero sin idea de quién puede cambiar qué.
- Confundir la capacidad técnica con el control. Un sistema que registra quién accedió cuándo es mejor que un sistema que no lo hace, incluso si el sistema "moderno" parece más sofisticado. Muchos auditores descuidan revisar los logs de acceso porque asumir que un sistema "bueno" tiene controles automáticos.
- Asumir que las copias de seguridad existen. Un hallazgo recurrente: una entidad tiene un procedimiento de copia de seguridad documentado en el manual de TI, pero nadie ha comprobado jamás que la copia se ejecuta ni se puede recuperar. La documentación del control no es el control.
Términos relacionados
---
- Controles de aplicación: reglas específicas programadas en un sistema (validación de montos, restricción de cuentas). Dependen de que los controles generales de TI funcionen primero.
- Riesgo de error a nivel de aseveración: si los controles generales de TI son deficientes, el riesgo de que movimientos incorrectos se registren sin detección es alto, lo que afecta directamente las pruebas que el auditor ejecuta.
- Segregación de funciones: separación entre autorización, procesamiento, custodia y reconciliación. En entornos de TI, se implementa a través de acceso y permisos de usuario.
- Documentación de cambios: registro de qué se modificó en un sistema, cuándo, por quién, y si fue probado antes de implementarse.
- Ambiente de prueba: una copia separada del sistema donde se prueban cambios antes de llevarlos al entorno de producción.
- Segregación de funciones: asignación de permisos de forma que una persona no pueda autorizar, procesar, custodiar y reconciliar la misma transacción.