Auditoría informática: cómo evaluar riesgos, controles, ciberseguridad e inteligencia artificial

 

Conozca las etapas de una auditoría informática y los controles que deben evaluarse en ciberseguridad, nube e inteligencia artificial. Acceda al libro completo.

Una auditoría informática permite evaluar, con criterios y evidencia, si una organización gobierna sus tecnologías, controla sus riesgos y protege los servicios y datos de los que depende. Su trabajo abarca mucho más que revisar equipos o comprobar si existe una política de seguridad. Incluye procesos, personas, proveedores, aplicaciones, infraestructura, servicios en la nube y, cada vez con mayor frecuencia, sistemas de inteligencia artificial.

Una organización puede disponer de herramientas avanzadas y, aun así, mantener cuentas con privilegios excesivos, respaldos que nunca ha probado o modelos de IA cuyos resultados nadie supervisa. La auditoría ayuda a identificar estas diferencias entre lo previsto y lo que ocurre en la práctica. También proporciona información para priorizar mejoras y dar seguimiento a las decisiones tomadas.

¿Qué es la auditoría informática y para qué sirve?

La auditoría informática es una evaluación sistemática de los procesos, sistemas y controles relacionados con las tecnologías de información. Parte de un objetivo y un alcance definidos, compara la situación observada con criterios pertinentes y obtiene evidencia para sustentar sus conclusiones.

Su propósito puede variar. Una auditoría puede buscar determinar si los accesos a una aplicación están protegidos, si una plataforma puede recuperarse después de una interrupción, si los cambios de software se aprueban antes de ponerse en producción o si una solución de IA cuenta con supervisión adecuada.

En todos los casos conviene distinguir tres preguntas:

• ¿Qué debería ocurrir? Lo establecen los criterios aplicables: requisitos legales, políticas, contratos, procedimientos, normas o decisiones aprobadas.

• ¿Qué ocurre realmente? Se determina mediante entrevistas, documentos, registros, observación y pruebas.

• ¿Qué significa la diferencia? Se analiza su causa, el riesgo que genera y las acciones necesarias para atenderlo.

Por ejemplo, una política puede exigir la revisión trimestral de los permisos de usuarios. Si el auditor encuentra revisiones firmadas, todavía debe comprobar si detectaron accesos innecesarios y si estos fueron retirados. El documento acredita una actividad; la prueba permite valorar si el control funciona.

Control interno: responsabilidades que deben estar claras

Los controles de TI son medidas establecidas para prevenir problemas, detectarlos o responder cuando ocurren. Pueden ser técnicos, como la autenticación multifactor y el registro de eventos, o administrativos, como la aprobación de cambios y la asignación de responsabilidades.

La administración es responsable de diseñar, aplicar y supervisar esos controles. La auditoría evalúa su diseño y funcionamiento con independencia y comunica sus resultados. Esta diferencia importa: el auditor puede recomendar mejoras, pero no debe sustituir a quienes gestionan el proceso que después tendrá que evaluar.

Un control puede fallar de distintas maneras. Puede estar mal diseñado, existir únicamente en un procedimiento, aplicarse de forma irregular o funcionar sin producir el resultado esperado. Por ello, una evaluación completa examina tanto el diseño del control como su operación efectiva durante un período determinado.

La gestión de riesgos orienta la auditoría

No todos los sistemas ni todas las debilidades tienen la misma importancia. La valoración de riesgos permite concentrar recursos en los escenarios con mayor impacto potencial para los objetivos de la organización.

Para comprender un riesgo tecnológico, resulta útil identificar el activo o proceso afectado, el evento que podría ocurrir, las condiciones que lo facilitarían y sus posibles consecuencias. Después se examinan los controles existentes y se valora el riesgo que permanece.

Considérese una plataforma que contiene información confidencial. Si una cuenta administrativa no tiene autenticación multifactor, una contraseña comprometida podría permitir el acceso no autorizado, la modificación de datos o la interrupción del servicio. La auditoría podría revisar el inventario de cuentas privilegiadas, los mecanismos de autenticación, las autorizaciones, los registros de acceso y las alertas. Así, un riesgo expresado de forma general se transforma en un conjunto de pruebas verificables.

Una matriz de riesgos ayuda a ordenar prioridades, pero sus números no reemplazan el juicio profesional. La probabilidad y el impacto deben interpretarse junto con el contexto: la exposición del sistema, la sensibilidad de los datos, la dependencia operativa y la eficacia de los controles.

Las cuatro etapas del proceso de auditoría informática

1. Planificación: definir qué se evaluará

Una auditoría comienza antes de ejecutar pruebas. Durante la planificación se establece qué se quiere determinar, cuáles sistemas y períodos estarán incluidos, qué criterios se aplicarán y qué recursos se necesitan.

El auditor obtiene un conocimiento preliminar del proceso, identifica a sus responsables y revisa los riesgos principales. Con esa información prepara el plan y el programa de trabajo. Un objetivo como «evaluar la seguridad informática» es demasiado amplio para guiar una revisión eficaz. En cambio, «determinar si los accesos privilegiados a la plataforma de matrícula fueron autorizados, revisados y retirados oportunamente durante 2026» permite delimitar las pruebas y la evidencia necesaria.

Planificar también implica reconocer restricciones. Una prueba sobre un sistema en producción puede afectar su disponibilidad; una revisión de datos personales exige medidas de protección; y una auditoría de IA puede requerir especialistas en datos, modelos o el proceso de negocio donde se utiliza.

2. Ejecución: reunir y analizar evidencia

En esta etapa se realizan entrevistas, inspecciones, observaciones, consultas de registros, análisis de datos y pruebas de controles. Cuando no es viable revisar toda una población, se seleccionan muestras apropiadas y se documenta cómo fueron escogidas.

La evidencia debe ser pertinente para el objetivo, suficientemente confiable y estar identificada de modo que otra persona pueda comprender cómo se obtuvo y qué demuestra. Una captura aislada puede indicar la configuración de un sistema en un momento preciso, pero quizá no permita concluir que esa configuración se mantuvo durante todo el período evaluado. Para ello podrían necesitarse historiales de cambios, registros adicionales u otras pruebas.

Los papeles de trabajo relacionan criterios, procedimientos, resultados y conclusiones. Su función no es acumular archivos: permiten reconstruir el razonamiento del auditor y sustentar lo que posteriormente se comunicará.

3. Informe y cierre: comunicar hallazgos útiles

Un hallazgo debe explicar con claridad la diferencia entre el criterio aplicable y la situación observada. También debe exponer el riesgo o efecto, analizar la causa cuando sea posible y orientar una acción correctiva viable.

Comparemos dos formas de comunicar un resultado:

«La gestión de accesos es deficiente».

«Se identificaron cuentas administrativas activas de personas que ya no desempeñan funciones en la plataforma. El procedimiento institucional exige retirar esos accesos al finalizar la relación funcional. Esta situación aumenta la posibilidad de uso no autorizado; se recomienda corregir las cuentas identificadas y establecer una verificación entre las bajas de personal y los permisos vigentes».

La segunda formulación permite comprender qué se encontró, por qué importa y cómo podría abordarse. El informe también debe dar espacio a la respuesta de la administración, precisar responsables y facilitar la priorización de las acciones.

4. Seguimiento: verificar la eficacia de las mejoras

La auditoría no termina cuando se entrega el informe. El seguimiento comprueba si las acciones comprometidas se implementaron y si redujeron el riesgo identificado.

Cerrar un hallazgo únicamente porque se adquirió una herramienta puede ser prematuro. Si la recomendación buscaba detectar accesos indebidos, corresponde comprobar que la herramienta fue configurada, que genera alertas pertinentes y que alguien las atiende. La evidencia de implementación y la evidencia de eficacia responden a preguntas diferentes.

¿Qué áreas puede cubrir una auditoría de TI?

El alcance depende de la organización y de sus riesgos, pero algunas áreas aparecen con frecuencia:

Área	Pregunta que orienta la evaluación
Accesos e identidades	¿Cada persona conserva únicamente los permisos necesarios y autorizados?
Cambios tecnológicos	¿Las modificaciones se evalúan, aprueban, prueban y documentan antes de su implementación?
Datos y aplicaciones	¿La información es íntegra, está protegida y se procesa según su propósito?
Ciberseguridad	¿La organización identifica, atiende y supervisa sus exposiciones y eventos de seguridad?
Continuidad	¿Los servicios críticos pueden recuperarse dentro de los tiempos previstos?
Proveedores y nube	¿Están definidas y supervisadas las responsabilidades de cada parte?
Gobierno de TI	¿Las decisiones tecnológicas responden a objetivos y responsabilidades claros?
Inteligencia artificial	¿Los sistemas de IA se autorizan, evalúan y supervisan de acuerdo con sus riesgos e impactos?

Una auditoría no necesita abarcar todas estas áreas al mismo tiempo. Delimitar bien el alcance favorece pruebas más profundas y conclusiones más útiles.

Ciberseguridad: evaluar procesos, no solo herramientas

En una auditoría de ciberseguridad, comprobar la presencia de antivirus, cortafuegos o sistemas de monitoreo es apenas el inicio. Debe examinarse cómo la organización conoce sus activos, configura sus sistemas, administra vulnerabilidades, gestiona incidentes y aprende de ellos.

La gestión de vulnerabilidades ofrece un buen ejemplo. Un informe de escaneo puede mostrar debilidades detectadas, pero la auditoría también debe preguntar si el inventario de activos está completo, quién clasifica los resultados, cómo se priorizan las correcciones, cuáles son los plazos y qué sucede cuando una vulnerabilidad no puede resolverse de inmediato.

La revisión de incidentes puede seguir una muestra desde su detección hasta su cierre: cuándo se identificó, cómo se clasificó, a quién se notificó, qué evidencia se preservó, cómo se recuperó el servicio y qué mejoras se acordaron. Esto permite evaluar la respuesta real de la organización, más allá de la existencia de un procedimiento.

Las pruebas técnicas activas, como escaneos o simulaciones, requieren objetivos y autorizaciones precisos. Deben definirse los sistemas incluidos, los horarios, las técnicas permitidas, los contactos responsables y las condiciones para detener una prueba si afecta la operación.

Servicios en la nube: comprender las responsabilidades compartidas

Trasladar una aplicación a la nube cambia la forma de administrar algunos controles, pero no elimina la responsabilidad de la organización sobre sus datos y servicios. Antes de auditar, es necesario comprender qué gestiona el proveedor y qué conserva bajo su control la entidad usuaria.

La revisión puede incluir configuraciones de acceso, cifrado, ubicación y conservación de datos, respaldos, monitoreo, contratos, niveles de servicio y mecanismos de salida o recuperación. También conviene comprobar si las funciones activadas corresponden a lo contratado y si los cambios del proveedor son conocidos y evaluados.

Una certificación del proveedor puede aportar información valiosa, pero no demuestra por sí sola que la configuración particular de cada cliente sea adecuada. La auditoría debe relacionar la evidencia del proveedor con los controles que corresponde implementar y supervisar a la organización.

Inteligencia artificial y auditoría: dos perspectivas complementarias

La IA introduce oportunidades para mejorar el trabajo del auditor y nuevos objetos de evaluación. Son perspectivas relacionadas, pero tienen objetivos diferentes.

Usar IA para auditar puede facilitar la búsqueda en documentos extensos, la clasificación inicial de información o el análisis de grandes conjuntos de datos. En estos casos, el auditor debe proteger la información utilizada, comprender las limitaciones de la herramienta y validar los resultados antes de incorporarlos como evidencia o conclusión.

Auditar un sistema de IA consiste en examinar si su desarrollo, adquisición y uso están gobernados y controlados. Una evaluación puede considerar:

• El inventario de sistemas y casos de uso, incluidas funciones de IA integradas en plataformas contratadas.

• La aprobación de los usos y la asignación de responsables.

• La procedencia, calidad, representatividad y protección de los datos.

• Las evaluaciones de impacto y las pruebas realizadas antes del despliegue.

• El desempeño del sistema para el propósito previsto.

• Los sesgos, errores, resultados inventados y otros efectos adversos pertinentes.

• La supervisión humana, el tratamiento de reclamaciones y la respuesta a incidentes.

• La vigilancia de proveedores, versiones y cambios posteriores.

Los criterios pueden provenir de políticas, contratos, requisitos legales y marcos reconocidos. ISO/IEC 42001 aporta requisitos para un sistema de gestión de IA; el NIST AI Risk Management Framework ofrece una estructura para gobernar, mapear, medir y gestionar riesgos. La selección de criterios y pruebas debe adaptarse al uso concreto del sistema. No plantea las mismas exigencias una herramienta de apoyo a la redacción que un sistema que influye en decisiones crediticias.

Un punto decisivo es distinguir entre controles de seguridad y controles sobre los resultados. Un sistema de IA puede contar con buenas protecciones de acceso y, aun así, generar decisiones inexactas o injustas. La auditoría necesita examinar ambas dimensiones.

Normas y marcos: seleccionar criterios según el objetivo

Las normas y buenas prácticas ayudan a estructurar la evaluación, pero no todas cumplen la misma función. ISO 19011 orienta sobre la realización de auditorías de sistemas de gestión; ISO/IEC 27001 se relaciona con la gestión de la seguridad de la información; COBIT ayuda a examinar el gobierno y la gestión de TI; y otros referentes aportan criterios para riesgos, servicios, continuidad o IA.

El primer paso no es reunir tantas siglas como sea posible. Es formular con precisión el objetivo de auditoría y determinar qué criterios son aplicables, verificables y pertinentes. Combinar referentes puede ser útil cuando cada uno aporta una dimensión necesaria, siempre que se eviten duplicidades y se explique la base de evaluación.

De la revisión al aprendizaje organizacional

Una auditoría informática bien ejecutada identifica debilidades, reconoce controles que funcionan y ayuda a tomar mejores decisiones. Su aporte depende de la calidad de la evidencia, la claridad del informe y la disposición de la organización para atender las causas de los problemas.

También depende de las competencias y la ética de quienes auditan. Las tecnologías cambian, por lo que el equipo necesita actualizar conocimientos y recurrir a especialistas cuando el alcance lo requiera. La objetividad, el cuidado de la información y la capacidad de explicar hallazgos complejos siguen siendo esenciales.

Preguntas frecuentes sobre auditoría informática

¿Auditoría informática y prueba de penetración son lo mismo?
No. Una prueba de penetración busca identificar y demostrar determinadas debilidades explotables dentro de un alcance autorizado. Puede aportar evidencia a una auditoría, cuyo análisis también comprende riesgos, criterios, procesos, responsabilidades y controles.

¿Una auditoría informática se limita a comprobar cumplimiento?
No. El cumplimiento puede formar parte del objetivo, pero una auditoría también puede evaluar si los controles están bien diseñados, funcionan y contribuyen a gestionar los riesgos.

¿Cada cuánto debe realizarse una auditoría de TI?
La frecuencia debe responder al riesgo, los cambios tecnológicos, los requisitos aplicables y los resultados de evaluaciones anteriores. Los procesos críticos o que cambian con rapidez pueden requerir revisiones más frecuentes.

¿Qué evidencia puede utilizar un auditor informático?
Entre otras fuentes, políticas, contratos, configuraciones, registros de eventos, tickets, autorizaciones, resultados de pruebas, entrevistas y observaciones. Su valor depende de su relación con el objetivo y de su confiabilidad.

¿Se puede auditar un sistema de IA adquirido a un proveedor?
Sí. Aunque algunas pruebas dependan de la información disponible en el contrato y del acceso concedido, la organización puede evaluar el caso de uso, sus datos, responsabilidades, resultados, supervisión, incidentes y controles del proveedor.

Profundice en el libro completo gratis en pdf

Los temas de este artículo se desarrollan con ejemplos, casos e instrumentos de trabajo en Fundamentos de auditoría informática: Manual del proceso de auditoría: riesgos, control interno, ciberseguridad e inteligencia artificial. ISBN: 978-9930-01-318-2. La obra recorre el proceso desde la planificación hasta el seguimiento y dedica capítulos específicos al gobierno de TI, la ciberseguridad, las tecnologías emergentes y la inteligencia artificial.

Acceder y descargar el libro completo en Zenodo
Consultar también la publicación en ResearchGate

Referencias

 Solano Segura, J. A. (2026). Fundamentos de auditoría informática: Manual del proceso de auditoría: riesgos, control interno, ciberseguridad e inteligencia artificial. https://doi.org/10.5281/zenodo.23022847