ITGC en auditoría de cuentas: controles generales de TI según la NIA-ES 315

Los ITGC (del inglés information technology general controls) son los controles generales de TI (tecnologías de la información): los que mantienen en pie el entorno informático del cliente —quién puede entrar, quién puede cambiar qué y cómo se explotan los sistemas— y por eso hacen que los controles automáticos y los datos del sistema sean fiables. En una auditoría de cuentas en España, la NIA-ES 315 (Revisada 2019) obliga a identificarlos, valorar su diseño y comprobar que están implementados siempre que el cliente tenga aplicaciones expuestas a riesgos por su uso (apartado 26). Probar además que han funcionado durante el ejercicio solo es obligatorio si el auditor se apoya en esos controles o si las pruebas sustantivas no bastan por sí solas (NIA-ES 330, apartado 8).

Esta guía recorre el proceso completo con el texto vigente de la norma, el de la Resolución del ICAC de 11/04/2024 (BOE-A-2024-8358), obligatorio para ejercicios iniciados desde 01/01/2024 y para todo encargo contratado desde 01/01/2025: qué son los ITGC, cuándo hay que tratarlos, cómo se prueban y se documentan, qué hacer con un ERP o un software como servicio (SaaS) y con un informe SOC 1, qué aporta un certificado ISO 27001 y cuándo conviene un especialista.

Lo esencial

• Los ITGC se reparten en tres procesos de TI: acceso, cambios (con el desarrollo, la adquisición y la implantación de sistemas dentro) y operaciones.
• Se identifican desde los controles de los que dependes: primero los controles automáticos y los informes del sistema que vas a usar, después las aplicaciones que los ejecutan y, por último, los ITGC que protegen esas aplicaciones.
• Valorar el diseño y comprobar la implementación es obligatorio, y preguntar, sin más, no basta (A177). Probar la eficacia operativa depende de tu estrategia de respuesta.
• Un ERP o un SaaS en la nube suele activar la NIA-ES 402: informe de tipo 2 (SOC 1 o ISAE 3402), pruebas propias o de otro auditor, y los controles que debe ejecutar el propio cliente.
• Un certificado ISO 27001 ayuda a entender el entorno, pero no sustituye las pruebas.
• Con entornos complejos, la norma espera la participación de especialistas en TI (A171).

Qué son los ITGC y en qué se diferencian de los controles de aplicación#

La norma llama ITGC a los controles que se aplican a los procesos informáticos de la entidad para que el entorno de TI siga funcionando con normalidad. Eso incluye que los controles de procesamiento sigan operando y que la información del sistema conserve su integridad: que esté completa, sea exacta y sea válida (apartado 12(d)).

El entorno de TI que protegen tiene tres piezas (apartado 12(g)):

• Las aplicaciones, incluidos los almacenes de datos y los generadores de informes.
• La infraestructura: las redes, las bases de datos, los sistemas operativos y el equipamiento y el software que los acompañan.
• Los procesos y el personal que gestionan todo lo anterior.

Lo que en la práctica se llama controles de aplicación, la norma lo llama controles de procesamiento (apartado 12(e)): los que, dentro de una aplicación o de un proceso manual, protegen directamente la integridad de las transacciones y de la demás información. La diferencia entre unos y otros es de nivel:

El bloqueo automático del ejemplo solo vale lo que valgan los ITGC que lo rodean. Si cualquiera con perfil de administrador puede modificar la tolerancia del cruce, o si un cambio de programa pasó a producción sin aprobación, el control puede haber dejado de funcionar sin que nadie lo note. Esa es la razón de ser de los ITGC.

Los ITGC se reparten en tres procesos de TI: acceso, cambios y operaciones#

La norma distingue tres procesos de TI: el que gobierna quién accede al entorno, el que gobierna cómo se modifican programas y entorno, y el que gestiona la explotación diaria (apartado 12(g)). El anexo 6 reúne ejemplos de controles dentro de cada uno.

En la práctica se habla a menudo de cuatro dominios, porque se separa el desarrollo o la adquisición de sistemas. La norma lo incluye dentro de los cambios, y conviene respetarlo al documentar: así el papel coincide con el texto que verá un inspector.

El anexo 6 (apartado 1) recuerda además que los ITGC se aplican en cada capa del entorno:

• Aplicación: habrá más controles cuanto más integrada y compleja sea.
• Base de datos: frente al riesgo de modificar datos financieros entrando directamente o lanzando instrucciones o programas ajenos a la aplicación.
• Sistema operativo: frente al acceso de administrador, que permite saltarse otros controles.
• Red: segmentación, acceso remoto y autenticación; pesan más con aplicaciones web o con terceros que intercambian datos.

Y el alcance se gradúa. Según el cuadro del anexo 6, con un programa comercial sencillo el esfuerzo se concentra en el acceso, probablemente a nivel de aplicación, y los controles de cambios de programa o de base de datos suelen no aplicar porque no hay nada que cambiar. Con aplicaciones de tamaño medio se añaden determinadas aplicaciones, bases de datos y niveles del entorno, y con sistemas grandes, como un ERP, se cubren todos.

Cuándo exige la NIA-ES 315 identificar y evaluar los ITGC#

Desde qué fecha es obligatoria#

La fecha que cuenta es la de la resolución del ICAC, no la de la norma internacional. Las NIA-ES son normas de auditoría de obligado cumplimiento: su fuerza viene de la Ley 22/2015 (artículo 2), que explicamos en nuestra guía de la ley que regula la auditoría de cuentas.

Con fecha 21/10/2026, el BOE no registra modificaciones posteriores de la 315, la 330, la 402 ni la 620. Las resoluciones de julio de 2025 y de enero de 2026 afectan a otras normas. La de julio de 2026 (BOE-A-2026-17276) solo somete a información pública el borrador de la futura NIA-ES 570 (Revisada 2024), con ajustes de concordancia en otras normas, entre ellas la 315; el plazo de alegaciones terminó en octubre de 2026 y no consta resolución definitiva. Mientras no se publique la resolución definitiva, rige el texto de 2024.

La cadena de apartados que activa los ITGC#

Los ITGC no se evalúan por defecto: aparecen al final de una cadena que empieza en los controles de los que piensas depender.

Dos matices que se olvidan. Valorar el diseño y comprobar la implementación no equivale a probar la eficacia operativa (A180). Y un control mal diseñado no merece que se compruebe su implementación (A176).

Cuándo puede no haber ITGC que evaluar#

La propia guía de aplicación lo admite (A170) y es la graduación más útil para firmas pequeñas:

• Software comercial sin acceso al código fuente. Es poco probable que haya un proceso de cambios de programa o ITGC formales, aunque sí puede haber gestión de accesos y de configuración (plan de cuentas, parámetros, perfiles).
• La gerencia no se apoya en controles automáticos ni en ITGC. Si tampoco los identificas tú, puedes planificar la prueba directa de los datos que genera el cliente y no identificar aplicaciones sujetas a riesgos por el uso de TI.
• Aplicación con gran volumen de datos y controles automáticos que sí identificas. Es probable que esté sujeta a riesgos por el uso de TI y que debas evaluar sus ITGC.

También hay que mirar los informes del sistema: si un control del que dependes se apoya en un informe, la aplicación que lo genera puede quedar sujeta a riesgos por el uso de TI. Si prefieres probar por tu cuenta lo que entra y sale del informe, quizá no la identifiques (A169).

Cuándo hay que probar los ITGC: la decisión de la NIA-ES 330#

La NIA-ES 330 manda diseñar y aplicar pruebas de controles cuando esperas que los controles funcionen y piensas apoyarte en ellos para reducir las pruebas sustantivas, o cuando estas, por sí solas, no pueden dar evidencia suficiente y adecuada (apartado 8). Los ITGC suelen entrar como controles indirectos de los controles automáticos (A32). La tabla resume las decisiones habituales:

Si pruebas en una fecha intermedia, obtén después evidencia sobre los cambios significativos hasta el cierre y decide qué más necesitas para el resto del periodo (apartado 12).

Cómo se prueban los ITGC: ejemplos de procedimiento#

La norma dice qué evidencia hace falta, no un programa de trabajo. Estos ejemplos son criterio práctico, no texto de la norma:

Dos advertencias. Preguntar, como único procedimiento, no basta para valorar diseño e implementación (A177). Y los listados que extrae el cliente son datos que genera la entidad: asegúrate de que están completos y son exactos, por ejemplo ejecutando tú la consulta o presenciándola (NIA-ES 500, apartado 9).

Cómo documentar los ITGC en los papeles de trabajo#

La documentación debe permitir que un auditor con experiencia, sin contacto previo con el encargo, entienda qué pruebas se hicieron, qué resultados y qué evidencia se obtuvieron y qué cuestiones importantes surgieron. Hay que dejar constancia de qué partidas se probaron, de quién hizo el trabajo y cuándo, y de quién lo revisó (NIA-ES 230, apartados 8 y 9). La NIA-ES 315 añade su propio contenido: los puntos esenciales de lo que has entendido del sistema de información, la valoración de cómo están diseñados los controles que hayas identificado, si están implementados y los riesgos valorados (apartado 38). Los papeles de trabajo de ITGC son, en la práctica, una cadena de siete eslabones:

1. Mapa de sistemas. Aplicaciones relevantes para los flujos de información, quién las aloja y administra, versión y cambios del ejercicio (migraciones, nuevos módulos).
2. Decisión de alcance, con motivo. Qué aplicaciones se consideran sujetas a riesgos por el uso de TI y cuáles no, y por qué (A169-A170). Documenta también lo que descartas.
3. Riesgos y ITGC por aplicación. Para cada una, los riesgos por el uso de TI y los ITGC que los cubren, por proceso (apartado 26(c)).
4. Diseño e implementación. El procedimiento aplicado más allá de preguntar, con fecha y persona.
5. Eficacia operativa, si se prueba. Objetivo, población, muestra, periodo, desviaciones y conclusión (NIA-ES 330).
6. Conexión con la respuesta. Qué control automático, qué informe del sistema o qué riesgo del encargo depende de cada ITGC, y qué cambia en tus pruebas sustantivas según el resultado.
7. Deficiencias y comunicación. Las significativas se comunican por escrito a los responsables del gobierno de la entidad y a la dirección (NIA-ES 265, apartados 9 y 10).

Una matriz como esta, con dos filas de ejemplo ilustrativo (no es un encargo real), resume el conjunto:

Lo que no es un papel de trabajo: el certificado ISO, el informe SOC o el listado de usuarios archivados sin más. Sin la conclusión del auditor sobre qué cubren, para qué periodo y qué riesgo cierran, solo son anexos. Y documenta cuando haces el trabajo, no al cerrar: lo que se redacta después suele ser menos exacto (NIA-ES 230, A1).

Qué hacer si el cliente usa un ERP o un SaaS: NIA-ES 402 y los informes SOC 1#

Cuando una parte del procesamiento de la información financiera está en manos de un proveedor, la NIA-ES 402 lo trata como una organización de servicios: un tercero que presta a la entidad servicios que se integran en su sistema de información financiera (apartado 8(e)). La guía cita expresamente a los proveedores de aplicaciones informáticas estandarizadas con su entorno tecnológico (A3) y a quienes llevan los registros contables (A4). Un ERP en la nube, un alojamiento externo o un programa contable en la nube entran aquí.

Los pasos#

1. Entiende el servicio y cómo afecta al control interno del cliente: qué se procesa, cuánto interactúa el cliente con el proveedor y qué dice el contrato (apartado 9).
2. Identifica los controles del propio cliente sobre los servicios del proveedor, valora su diseño y comprueba su implementación (apartado 10).
3. Si no basta con lo que sabe el cliente, obtén conocimiento por una o varias vías: un informe de tipo 1 o de tipo 2, contacto con el proveedor a través del cliente, visita al proveedor o recurso a otro auditor (apartado 12).
4. Si esperas que los controles del proveedor funcionen y piensas apoyarte en ellos, necesitas evidencia de su eficacia operativa: un informe de tipo 2, pruebas propias en el proveedor o pruebas de otro auditor (apartado 16).
5. Si no consigues evidencia suficiente y adecuada sobre servicios relevantes, la opinión se modifica (apartado 20; véase el informe de auditoría).

Tipo 1, tipo 2, SOC 1 e ISAE 3402#

La NIA-ES 402 admite que estos informes se emitan según la norma internacional ISAE 3402 o según las de otro organismo emisor reconocido (A16). Una nota del texto español aclara que la ISAE 3402 no ha sido adaptada en España. El SOC 1 es el informe del AICPA, el organismo de los contables estadounidenses, sobre los controles de un prestador de servicios que pueden influir en el control interno de sus clientes sobre su información financiera. Un SOC 1 de tipo 2 se trata en la práctica como un informe de tipo 2. Un SOC 2, en cambio, evalúa controles de seguridad, disponibilidad, integridad del procesamiento, confidencialidad o privacidad: puede informar sobre el entorno, pero no se centra en la información financiera del usuario.

Qué comprobar antes de apoyarte en un informe de tipo 2#

• Quién lo firma: competencia profesional e independencia del auditor del proveedor, y adecuación de la norma con la que se emitió (apartado 13).
• Periodo: que la descripción y las pruebas se refieran a un momento o a un periodo apropiados para tu trabajo, y cuánto tiempo ha pasado desde las pruebas (apartado 17(a) y (c)). Si el periodo del informe no cubre todo el tuyo, necesitas evidencia complementaria del tramo que falta. El programa europeo de inspección de TI que se resume en «Errores frecuentes» menciona expresamente la carta puente que algunos proveedores emiten para ese tramo.
• Alcance: que incluya los servicios, los sistemas y las ubicaciones que usa tu cliente. Si el proveedor subcontrata servicios relevantes y el informe los excluye, los requisitos de la norma se aplican a esa subcontratada (apartado 18).
• Excepciones y pruebas: que las pruebas del auditor del proveedor sean relevantes para tus afirmaciones y den evidencia suficiente (apartado 17(d)).
• Controles complementarios del cliente. Son los que el proveedor da por supuesto que ejecuta el usuario, como revisar sus propios accesos o aprobar los pagos. Hay que decidir si son relevantes y, si lo son, comprobar su diseño y su implementación y, si te apoyas en ellos, probarlos (apartados 14(c) y 17(b)). El programa europeo de inspección revisa expresamente que se hayan cubierto.

Un proveedor pequeño puede no tener informe: depende de lo pactado en el contrato (A17). Entonces cuentan las otras vías, como la visita (A18), y el trabajo sustantivo sobre los registros del cliente (apartado 15). Y si expresas una opinión no modificada, tu informe no menciona el trabajo del auditor del proveedor salvo que lo exija una disposición legal (apartado 21).

Qué aporta un SGSI ISO 27001 como evidencia y qué no#

ISO/IEC 27001 es una norma para montar un sistema que gestione la seguridad de la información (SGSI): exige a la organización analizar sus riesgos, aplicar controles, medirlos y mejorarlos. La edición de 2022 lista 93 controles en su anexo A. La certificación la concede un organismo de certificación, que conviene que esté acreditado, tras una auditoría sobre un alcance que fija la propia organización.

Para un auditor de cuentas, el certificado es útil pero limitado.

Lo que sí aporta

• Una señal sobre cómo gestiona la entidad el riesgo tecnológico, relevante para el entorno de control.
• Documentación con la que empezar: políticas de acceso, procedimiento de cambios, copias de seguridad, registros de revisiones, hallazgos de las auditorías internas y no conformidades.
• Un punto de partida para decidir qué ITGC conviene probar y con qué alcance.
• En el caso de un proveedor, información sobre su control de la seguridad.

Lo que no aporta

• Una evaluación de los controles de procesamiento: su objeto es la seguridad de la información, no la integridad de las cifras.
• Una prueba de que los controles funcionaron durante tu ejercicio: la certificación acredita conformidad en un momento y sobre una muestra del organismo.
• La garantía de que el ERP o los procesos del ciclo financiero estén dentro del alcance: el perímetro del certificado puede dejarlos fuera.
• Un informe de tipo 1 o de tipo 2 en el sentido de la NIA-ES 402: no recoge los controles que afectan a la información financiera de los usuarios ni una opinión de un auditor sobre su diseño o su eficacia.

Qué pedir si el cliente o su proveedor están certificados: el certificado, la declaración de aplicabilidad, el alcance (¿incluye el ERP y los procesos del ciclo financiero?), las fechas de las auditorías de certificación y de seguimiento, y las no conformidades abiertas. Con eso puedes decidir si te ahorra trabajo de comprensión. Nunca sustituye los pasos 26(c) y 26(d) de la NIA-ES 315 ni las pruebas de la NIA-ES 330.

El anexo A de la edición de 2022 incluye controles de acceso, de gestión de cambios, de copias de seguridad y de uso de servicios en la nube, que producen documentación reconocible para cada proceso de TI. Sirven para saber qué pedir, no para dar por probado nada: la norma ISO no está pensada para la información financiera, y una auditoría de cuentas no puede apoyarse en ella como si lo estuviera.

Cuándo recurrir a un experto en TI: NIA-ES 620 y NIA-ES 220 (Revisada)#

La NIA-ES 315 espera que el auditor valore si necesita competencias especializadas. Cuando el entorno es complejo, identificar aplicaciones, riesgos e ITGC probablemente exija miembros del equipo con cualificación en TI, y su participación puede ser esencial y amplia (A171).

Señales de que hay que llamar a un especialista:

• Un ERP de gran tamaño, muy integrado o con desarrollos a medida.
• Una implantación, una migración o un cambio de sistema crítico en el ejercicio.
• Varios sistemas conectados por interfaces, o una consolidación que integra datos de ERP distintos.
• Alojamiento externo o centros de servicios compartidos en el grupo (A174).
• Un incidente grave de ciberseguridad.
• Un volumen de operaciones tan automatizado que las pruebas sustantivas no bastan por sí solas.

La regla que se cita menos: no todo especialista en TI cuenta como experto del auditor a efectos de la 620. La NIA-ES 620 trata del trabajo de alguien, persona u organización, con una especialidad ajena a la contabilidad y a la auditoría (apartado 1). Si el equipo incluye a alguien, o consulta a alguien, con especialidad en un área concreta de la auditoría —como la auditoría de sistemas—, eso se rige por la NIA-ES 220 (Revisada) (NIA-ES 620, apartado 2(a)). La frontera entre ambos casos es de juicio profesional, sobre todo en áreas emergentes (NIA-ES 620, A2).

Si lo tratas como experto del auditor, la 620 pide:

1. Decidir si hace falta para llegar a evidencia suficiente y adecuada (apartado 7), con el motivo y la fecha en el papel.
2. Evaluar su competencia, capacidad y objetividad (apartado 9), con averiguaciones sobre intereses y relaciones si es externo.
3. Entender lo bastante su campo para definir y evaluar su trabajo (apartado 10).
4. Acordar con él, por escrito cuando proceda, el alcance, los objetivos, las funciones de cada uno, la comunicación y la confidencialidad (apartado 11).
5. Evaluar su trabajo: si los hallazgos son pertinentes y razonables, y si lo son las hipótesis, los métodos y los datos de origen que use (apartado 12).
6. No citarlo en un informe con opinión no modificada, salvo exigencia legal (apartado 14): la responsabilidad de la opinión sigue siendo solo tuya (apartado 3).

Para firmas pequeñas: no hace falta un especialista en cada encargo. Un programa comercial sencillo, sin acceso al código y con pocos usuarios, se resuelve con el equipo (A170). Lo que no se sostiene es ignorar el entorno de TI por no tener a quién preguntar. Una firma sin esa competencia puede contratarla de forma externa para los encargos que la necesiten.

Errores frecuentes al evaluar los ITGC#

1. Tratar el certificado ISO o el informe SOC como la prueba. Son insumos; la conclusión es del auditor.
2. Empezar por la lista de sistemas en lugar de por los controles. La norma va de los controles de los que dependes hacia las aplicaciones y de ahí a los ITGC. Evaluar todo el entorno por defecto es trabajo que no se pide.
3. Dar el diseño por bueno tras preguntar. Hace falta inspeccionar, observar o reejecutar algo (A177).
4. Cubrir solo la capa de aplicación. Entrar directamente en la base de datos, o ser administrador del sistema operativo, permite alterar datos sin tocar la aplicación (A173; anexo 6). Para la elusión de controles por la dirección, véase el artículo sobre fraude y compliance penal.
5. Olvidar los sistemas gestionados por terceros. El alcance debe incluir los sistemas alojados o administrados por el proveedor y los controles del cliente que el proveedor da por supuestos.
6. Usar un informe de tipo 2 que no cubre el ejercicio, sin evidencia complementaria del tramo que falta.
7. Fiarse de un solo ITGC. Un único control rara vez responde a un riesgo (A150): la revisión trimestral de accesos no sustituye el control de cambios.
8. No tener en cuenta los ITGC al reutilizar pruebas de años anteriores (NIA-ES 330, apartado 13(c) y A39).
9. Usar informes del sistema sin evaluar su fiabilidad (NIA-ES 500, apartado 9).
10. No documentar lo que descartas. Si no identificas aplicaciones sujetas a riesgos por el uso de TI, el papel debe decir por qué.
11. Dejar las deficiencias sin clasificar ni comunicar (NIA-ES 315, apartado 27; NIA-ES 265).

La inspección de auditoría europea trabaja en esta línea. El programa de inspección de TI del CEAOB (el comité europeo de supervisores de auditoría), de septiembre de 2023 y cuya traducción al español publica el ICJCE, revisa si el auditor decidió bien sus necesidades de competencia en TI, si cubrió todos los sistemas críticos y todas sus capas, incluidos los de organizaciones de servicios, y si evaluó el tipo de informe del proveedor, su periodo, las deficiencias y los controles complementarios del cliente.

Lista de comprobación de ITGC antes de cerrar el papel#

• Entiendo qué entorno de TI procesa los flujos de los tipos de transacciones y saldos significativos, y está documentado.
• Los controles automáticos y los informes del sistema de los que dependo están identificados (26(a)).
• La decisión de qué aplicaciones están sujetas a riesgos por el uso de TI está motivada, también las descartadas.
• Para cada aplicación identificada, constan los riesgos por el uso de TI y los ITGC de acceso, cambios y operaciones que los cubren.
• He cubierto las capas relevantes: aplicación, base de datos, sistema operativo y red.
• El diseño y la implementación se apoyan en algo más que en preguntar, con fecha y persona.
• Si me apoyo en los ITGC, hay pruebas de eficacia operativa con población, muestra, periodo y conclusión.
• Si hay un proveedor, consta si la NIA-ES 402 aplica, qué informe hay, su periodo, su alcance y sus excepciones, y los controles complementarios del cliente están tratados.
• Los listados y extracciones usados están comprobados en integridad y exactitud.
• El efecto de los ITGC deficientes en los controles dependientes y en mis pruebas sustantivas está documentado.
• Las deficiencias significativas están clasificadas y comunicadas por escrito.
• La decisión sobre especialistas consta con su motivo, y su trabajo está evaluado.
• El papel lo firma quien lo hizo y lo revisa otra persona, con fecha.

Fuentes oficiales#

Las NIA-ES se citan por apartado y se resumen: su texto solo puede reproducirse sin fines comerciales.

• Resolución del ICAC de 11/04/2024, con el texto vigente de NIA-ES 315 (Revisada 2019), 330, 402, 620, 230, 265 y 500 (BOE-A-2024-8358)
• Resolución del ICAC de 14/10/2021, que incorporó NIA-ES 315 (Revisada) (BOE-A-2021-17162)
• Análisis y referencias posteriores de la resolución de 2024 en el BOE
• Resoluciones posteriores que modifican otras normas, no las de esta guía: 17/07/2025 (BOE-A-2025-15417) y 22/01/2026 (BOE-A-2026-2234)
• Normativa técnica de auditoría en la web del ICAC
• Programa de inspección de TI del CEAOB (septiembre de 2023, traducción del ICJCE)
• SOC 1 en el AICPA
• ISO/IEC 27001 en ISO