Controles generales de TI

Lo esencial

> - Los controles generales de TI son el cimiento sobre el que descansan los controles de aplicación. Si fallan, ningún control específico puede considerarse fiable, por mucha sofisticación que tenga el software. > - La mayoría de las deficiencias identificadas en inspección no son fallos catastróficos de seguridad. Son cosas mucho más mundanas: gente con acceso que no debería tener, cambios en producción sin documentar, copias de seguridad que nunca se han probado. > - Documentar qué controles existen requiere entrevistar a la persona responsable de TI y luego verificar que el control funciona, no solo que está diseñado. La documentación del control no es el control.

Cómo funcionan

Los controles generales de TI forman la base del entorno de control. La NIA-ES 315.29 obliga al auditor a comprender 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 eso significa tres categorías.

Controles de acceso. Quién puede hacer qué, cuándo y desde dónde. Incluye autenticación (contraseñas, doble factor), autorización (permisos 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. Esto último es la realidad de la mayoría de las pymes españolas.

Controles sobre cambios. Cómo se modifican, prueban e implementan los cambios en sistemas que procesan datos financieros. Incluye documentación del cambio, aprobación previa, prueba en entorno separado y registro del cambio implementado. Sin esto, nadie sabe qué hace el sistema hoy. Y si nadie sabe qué hace el sistema hoy, el auditor tampoco.

Controles operacionales. Cómo se mantiene la disponibilidad: copias de seguridad, recuperación ante desastres, supervisión de acceso, revisión de logs. Estos controles detectan problemas y permiten recuperar la operación si algo se rompe. Una copia de seguridad que nadie ha probado a recuperar no es una copia de seguridad, es un fichero.

Los auditores no son especialistas en TI, pero sí necesitan entender lo suficiente como para evaluar el riesgo de error. La pregunta operativa es sencilla: 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, los controles generales de TI son deficientes.

Lo que realmente ocurre

La norma describe un entorno de control idealizado. La realidad de la mayoría de los encargos de pymes que he llevado es otra. El "responsable de TI" es el contable que aprendió Excel hace veinte años, o un proveedor externo que viene cuando se rompe algo. Los logs de acceso existen pero nadie los mira. Las copias de seguridad se hacen "cuando alguien se acuerda". El permiso de modificación de movimientos contables lo tienen tres personas porque alguna vez hubo que ajustar inventario un domingo.

En estos entornos, marcar la casilla del programa de auditoría con "controles generales de TI revisados, deficiencias menores" es la forma rápida de cerrar el área. Y es la forma rápida de tener un problema cuando el ICAC pida ver cómo se concluyó eso. Los papeles están flojos, falta chicha. La conclusión documentada no se sostiene si el papel se limita a citar lo que dijo el responsable de TI.

Ejemplo práctico: Distribuidora Albacete S.L.

Cliente: Distribuidora mayorista de materiales de construcción, facturación anual de 6,8 millones de euros, reporta bajo PGC, un empleado a tiempo parcial responsable de TI.

Paso 1: Entrevista inicial sobre el entorno El auditor pregunta qué sistemas procesan datos financieros. Respuesta: ERP de escritorio comprado en 2015, contabilidad auxiliar en Excel, nóminas en software separado. El responsable de TI sabe instalar parches, no sabe qué hace exactamente cada módulo del ERP.

Nota de documentación: PT 3.1: matriz de sistemas identificados y alcance de datos financieros.

Paso 2: Evaluación del acceso ¿Cuántas personas pueden cambiar movimientos contables en el ERP? Tres: el director, el contable y el gerente de almacén ("a veces" necesita ajustar inventario). El ERP no registra quién hizo qué cambio ni cuándo. No hay log de acceso.

Nota de documentación: PT 3.2: matriz de usuarios y permisos. Hallazgo: no hay segregación de funciones entre autorización y procesamiento; ausencia de log de auditoría.

Paso 3: Evaluación de cambios (donde aparece la complicación) El auditor pregunta cómo se actualiza el software. Respuesta: "Cuando el proveedor saca una actualización, nos la instala él mismo en remoto, o nosotros la instalamos directamente." No hay documentación del cambio, ni prueba en ambiente separado, ni aprobación formal previa. El auditor pide ver los últimos cinco cambios. El responsable de TI tarda dos días en localizar correos del proveedor que confirman las fechas. De los cinco, uno corresponde a una actualización en julio que coincide temporalmente con un repunte inexplicado de regularizaciones de inventario en el módulo afectado.

Aquí el juicio del auditor entra. Hay una correlación temporal entre un cambio sin documentar y un patrón anómalo en los datos contables. No prueba causalidad, pero abre una pregunta que un programa de procedimientos sustantivos rutinarios no iba a responder. El equipo decide ampliar pruebas sustantivas sobre regularizaciones de inventario del segundo semestre y solicitar al proveedor del ERP detalle técnico del cambio implementado.

Nota de documentación: PT 3.3: procedimiento de cambios. Hallazgo: cambios no documentados ni probados; correlación temporal con anomalía en regularizaciones; ampliación del alcance sustantivo sobre el módulo afectado.

Paso 4: Evaluación de copias de seguridad y recuperación ¿Cómo se protege la entidad contra pérdida de datos? "La máquina está en el despacho del director. Hacemos copia de seguridad una vez a la semana en un USB externo." Nadie ha probado nunca a restaurar desde el USB. El USB se guarda,, en el mismo despacho que el servidor.

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 documentada.

Conclusión: Distribuidora Albacete tiene controles generales de TI deficientes. El riesgo de modificación de datos financieros sin trazabilidad, de cambios implementados sin prueba, y de pérdida de datos sin recuperación posible es elevado. El auditor eleva el riesgo evaluado a nivel de aseveración, extiende las pruebas de controles e implementa procedimientos sustantivos más amplios sobre movimientos contables y completitud de registros. El archivo aguanta porque la conclusión documenta tanto el hallazgo como la respuesta de auditoría.

Donde discrepan dos socios experimentados

Tomemos el caso de una pyme con controles generales de TI claramente deficientes pero sin indicios de errores materiales. El Socio A concluye que basta con elevar el riesgo evaluado y ampliar pruebas sustantivas: la NIA-ES 315 no exige reportar deficiencias menores en pymes a las personas encargadas del gobierno corporativo si los procedimientos sustantivos resuelven el riesgo. El Socio B no está de acuerdo: para él, la deficiencia entra en NIA-ES 265 y debe comunicarse por escrito a la dirección, aunque el riesgo residual quede mitigado por sustantivo, porque la entidad necesita saber lo que tiene roto. Ambos tienen base normativa. La posición del Socio A es la que en la práctica adoptan la mayoría de los despachos en encargos de pymes pequeñas, por economía de la comunicación. La del Socio B es más coherente con el espíritu de NIA-ES 265, y la que un revisor del ICAC tendería a apoyar si revisara el archivo.

Mi opinión: en pymes con un solo responsable de TI a tiempo parcial, conviene comunicar las deficiencias incluso aunque no sean materiales, por dos razones. Una, porque la propia comunicación sirve de evidencia de que el auditor identificó la cuestión. Dos, porque al año siguiente, si la deficiencia persiste, el archivo demuestra que ya se advirtió. Vaya por delante que esto es preferencia personal, no obligación normativa estricta.

Por qué la práctica diverge de la norma

La presión estructural sobre los controles generales de TI en pymes viene del coste. Implementar segregación de funciones real, log de auditoría activo, gestión de cambios documentada y prueba periódica de recuperación cuesta dinero que la entidad no está dispuesta a gastar mientras "el sistema funciona". El auditor que insiste, pierde el cliente. El auditor que firma sin profundizar, gana el año pero asume el riesgo de inspección. El socio necesita el cliente, y la deficiencia no es lo bastante grave para que la entidad note el problema antes de que llegue una inspección, así que el equilibrio se desplaza.

La consecuencia que pocos están viendo: en cuanto el ICAC empiece a revisar de forma sistemática los papeles de trabajo del área de TI en pymes (cosa que ya está ocurriendo en encargos de tamaño medio bajo el plan de control de calidad), las firmas que han firmado durante años con dos líneas en el papel van a verse en serios apuros. La NIA-ES 315 revisada, aplicable desde 2022, ha hecho explícito lo que antes se daba por implícito: el auditor tiene que entender la tecnología que sustenta los registros contables. No basta con citar la norma en el programa.

Qué revisores y auditores entienden mal

Confundir inversión tecnológica con calidad de control. No hace falta software caro para tener controles generales de TI razonables. Una pyme con un ERP antiguo, roles definidos, registro de cambios y copias de seguridad probadas supera con creces a una empresa moderna con software cloud sin idea de quién puede modificar qué. Lo que importa es la trazabilidad y la segregación, no la marca del software.

Asumir que un sistema "moderno" tiene controles automáticos. Un sistema que registra accesos es mejor que uno que no los registra, sin discusión. Pero muchos auditores descuidan revisar los logs de acceso porque asumen que el sistema "bueno" se autocontrola. Lo que se autocontrola no necesita auditor; lo que necesita auditor es lo que hay que mirar.

Documentación tomada como si fuera el control. Un hallazgo recurrente: la entidad tiene un manual de TI que documenta el procedimiento de copia de seguridad, pero nadie ha comprobado nunca que la copia se ejecuta ni que se puede recuperar. La documentación del control no es el control. El auditor que se conforma con el manual ha hecho la mitad del trabajo. La otra mitad es pedir prueba reciente de ejecución y, en encargos de riesgo elevado, pedir al responsable de TI que demuestre la recuperación delante del equipo.

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 elevado, lo que afecta directamente a 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: copia separada del sistema donde se prueban cambios antes de llevarlos al entorno de producción.

---