ISACA Journal Volume 2, 2017

Translated Articles
COMMENTS

Auditoría agil English

Spiros Alexiou, Ph.D., CISA

Las restricciones son una parte integral del trabajo de todo auditor. Las auditorías deben terminar a tiempo. Usar efectivamente
el tiempo definido es una preocupación mayor. La auditoría ágil es primordialmente acerca de aumentar principalmente la eficiencia de
auditorías complejas paralelizando tareas., eliminando o mitigando los cuellos de botella, y asignando tiempo a variadas tareas que es
proporcional a su importancia.

El término “Ágil” usualmente se refiere al desarrollo de software y da énfasis a individuos e interacciones sobre procesos y herramientas,
software en funcionamiento sobre documentación comprensiva, colaboración con el cliente sobre negociación de contratos, y
respondiendo al cambio sobre el seguimiento de un plan.1

Su carácter de apropiado para sistemas complejos también se destaca en el manual de referencia de Auditor de Sistemas de Información
Certificado (CISA): “El término desarrollo ágil” se refiere a una familia de sistemas de desarrollo similares que respaldan una forma no
tradicional de desarrollar sistemas complejos”.2 Como ejemplo, un proyecto para desarrollar servicios personalizados basados en la red
que ha estado en operación por tres años tuvo una revisión negativa un mes antes de la fecha de término, ya que nada había sido
desarrollado. Un nuevo equipo de cuatro personas, incluyendo un nuevo líder, fue encargado de tomar el control y fueron capaces de
cumplir con la fecha de término con resultados impresionantes. El nuevo equipo se enfocó inmediatamente en desarrollar un sistema de
trabajo sin molestarse en largas reuniones, documentación y revisiones formales. Ellos condujeron pruebas internas en forma transversal
para identificar e inmediatamente corregir cualquier problema y crearon documentación después que el sistema estuvo operando y
estable.

La auditoría, por otra parte, ha utilizado estándares y marcos de trabajo estrictos, resultando en restricciones rígidas en los acuerdos de
auditoría que, esencialmente, representaron proyectos. Los proyectos de TI tienen similarmente modelos inflexibles. Sin embargo, han
evolucionado desde el modelo formal de cascada, que tiene pasos estrictos, a modelos menos formales, pero a menudo más eficientes.
Estos modelos más eficientes son usualmente conocidos como Ágiles. En modelos Ágiles, la documentación de diseño y especificación
se mantiene al mínimo requerido, y la mayor parte de la documentación es creada en las operaciones y niveles de soporte, por ejemplo,
manuales de usuario, que ocurren en forma mucho posterior en el ciclo de vida del sistema.

El esfuerzo de documentación de la cascada y los métodos Ágiles está ilustrado

en la figura 1. La pendiente precipitada al comienzo del proyecto del método
cascada es debida a un consumo de recursos sobre lo esperado, como la
planificación del proyecto y las especificaciones (ambas, de alto nivel y
detalladas) y diseño. Después que se completa el diseño, relativamente poca
documentación se requiere hasta acercarse al final, donde se requiere producir
los documentos de soporte, como los manuales de usuario.

En contraste, para Agilidad, los requerimientos de documentación son mucho

más bajos que los requerimientos de documentación de cascada —
prácticamente cero hasta cerca del final del proyecto, donde otra vez, los
documentos de soporte como los manuales de usuario deben ser producidos. La
Agilidad es mucho más eficiente en eso durante el estado final, la
documentación es capturada formal y transversalmente, no en las etapas
intermedia o inicial del entregable final. La documentación es solamente creada
cuando se necesita e, idealmente, en la forma en que se necesita, como
comentarios en el código actual.

En los modelos Ágiles, para el desarrollo de software y otras tareas, el equipo de proyectos tiene más libertad e iniciativa para hacer
ajustes a medida que progresa el proyecto. Esto es especialmente pertinente para auditoría, debido a que el objetivo de la auditoría es no
servir su propia metodología, sino que agregar valor al negocio. Esto, en su momento, si es bien ejecutado, puede resultar en mayor
eficiencia y mejores resultados. Por ejemplo, en un proyecto convencional (cascada) para crear un nuevo sistema TI, uno típicamente
lidiaría primero con las especificaciones, luego el diseño, luego desarrollo/implementación. Las pruebas y aceptación sería lo último. Un
acercamiento Ágil sería bastante diferente—una distinción que puede ser vista incluso en un proyecto muy diferente, como una auditoría.
En una auditoría Ágil, uno se enfocaría en identificar y rápidamente comenzar probando los asuntos que acarrean el mayor riesgo, al igual
que el desarrollo Ágil de software se enfocaría en crear un prototipo funcional que sería subsecuentemente mejorado. Este principio es a
menudo designado como la regla de Thompson para fabricantes primerizos de telescopios, que declara que “Es más fácil hacer un espejo
de cuatro pulgadas y luego uno de seis pulgadas, que hacer un espejo de seis pulgadas”.3

El término “auditoría Ágil” ha sido usado antes que este artículo, y con significados más o menos diferentes.4, 5, 6, 7, 8 Es necesario revisar
brevemente estos significados para distinguirlos del significado “auditoría Ágil” usado en este artículo.

En un caso, la siguiente reflexión es expresada: “Sin embargo, nuestros tiempos de ciclo de auditoría pueden ser mayores de lo deseado.
Nuestro producto de salida puede ser diferente de lo que esperaban nuestros interesados (stakeholders). Nuestros procesos de
aseguramiento de calidad pueden introducir restricciones para la eficiencia que fallan en producir más hallazgos que agreguen valor”. Esto
llevo a una búsqueda para “mejorar los tiempos de respuesta y la adaptabilidad de la auditoría interna” y “una forma para estandarizar
nuestro acercamiento para la observar de proyectos estratégicos y ganar la aceptación de nuestro rol por parte de nuestros interesados
(stakeholders)”.9 Mientras que el punto inicial es el mismo, el concepto de agilidad, como se utiliza aquí, es muy diferente. En el segundo
caso, la agilidad es también usada en un contexto diferente, como aquel de mantener mejor la pista del impacto en el negocio.10

El siguiente ejemplo es mucho más cercano a la definición utilizada aquí, pero también considera otros conceptos como autoevaluación y
asociación con la administración que puede incluso ser aplicada a auditorías no Ágiles.11 Otro ejemplo comparte muchas de las
preocupaciones de este artículo, pero se detiene antes de definir exactamente las características distintivas principales de una auditoría
Ágil.12 El último ejemplo reconoce las cuatro fases de la auditoría (planificación, trabajo en terreno, respuesta y final) y la separación
lógica y temporal que producen (son llamadas “pórticos” en ese artículo), y se esfuerza por ser ágil dentro de estas restricciones, mientras
este artículo llama a difuminar o eliminar estos pórticos formales.13

En este artículo, a la auditoría Ágil se le otorga un significado muy concreto que es distinto de las referencias previas. Específicamente, se
refiere a difuminar o incluso abolir la separación temporal sagrada entre planificación y trabajo en terreno. Esto significa que el fin de la
planificación no es necesariamente para que el trabajo en terreno se inicie o para la solicitud de información, y las tareas pueden
ejecutarse en paralelo. Adicionalmente, la producción de un documento de planificación formal ya no es requerida. Esto está motivado por
las mismas consideraciones respecto a la documentación (que es lo que la planificación es en esencia) así como los comentarios previos
sobre proyectos Ágiles y su gestión. Por ejemplo, la documentación puede consistir de un correo electrónico hacia el auditado solicitando
información específica, además del procesamiento de esa información y resultados de las pruebas ejecutadas, que normalmente son
realizadas en la fase de trabajo en terreno. En vez de documentar lo que será solicitado y cómo será utilizado, la auditoría Ágil documenta
lo que fue solicitado y cómo fue utilizado. Similarmente, los hallazgos pueden ser compartidos con los auditados antes del reporte final,14
pero esto no es una preocupación del presente artículo porque esto generalmente no representa un gran cuello de botella.

¿Qué hay de malo con las auditorías no ágiles?

Aunque los auditores de SI, proyectos de auditoría y sistemas entran en contacto con modelos Ágiles, sus propias reglas son a menudo
obsoletas. Por ejemplo, muchos departamentos de auditoría especifican que absolutamente ningún dato será solicitado hasta que el
programa de auditoría haya sido finalizado. Aunque esto está bien intencionado—para solicitar sólo datos relevantes y para limitar la
perturbación de los auditados que necesitan proveer los datos—es a menudo contraproducente.

Los acuerdos de auditoría típicos comienzan con una fase exploratoria en la cual los auditores se familiarizan con el objeto de la auditoría.
Por ejemplo, si un sistema SI será auditado, el auditor necesita entender qué datos contiene o procesa, cuáles son las interfaces, quién
usa el sistema, quién es el administrador, y así sucesivamente. Estas determinaciones necesitan tomarse antes de hacer el borrador de
un programa de auditoría. Sin embargo, unas pocas líneas de datos proveen mucha más información y son mucho más rápidas para
comprender que leer un manual completo a menudo con documentación muy pobre o dependiendo de las explicaciones de los auditados
quienes a menudo tienen un foco muy distinto del auditor. Adicionalmente, la mayoría de las personas, auditores incluidos, aprenden
mejor de los ejemplos que de la información “seca” que necesita cubrir casos extremadamente inusuales en la misma profundidad que
con casos más normales (dichos casos pueden ser encontrados durante las pruebas, pero en auditoría Ágil, ellos son resueltos
posteriormente y allí). Aún muchos departamentos de auditoría tienen reglas estrictas de que ningún dato debe ser solicitado hasta que el
programa de auditoría esté finalizado. Esto tiene los siguientes efectos adversos:

El programa de auditoría es bosquejado—por ejemplo, para lidiar con los datos—por gente que nunca ha visto ni siquiera una línea
de los datos.
Como resultado, los auditores deben confiar en su propia interpretación de lo que les dijeron los auditados, cuya visión del sistema
y los datos es completamente diferente de la perspectiva de los auditores. Esto, en su momento, significa que aspectos que son
posiblemente importantes para el auditado son dejados por completo fuera de la planificación porque los auditados no los
consideraron interesantes o relevantes y los auditores no supieron preguntar por ellos.
Incluso si los datos, sistemas, procesos, personas y funciones son bien entendidas, esto aún no significa que un programa de
auditoría rígido, escrito en piedra vaya a ser obtenido. Basado en lo que el auditor encuentre, puede haber indicaciones que más
trabajo es necesario para cubrir el riesgo que inicialmente era desconocido o subestimado. Por ejemplo, durante el curso de la
auditoría, puede hacerse evidente la falta de controles resultantes en un alto riesgo de fraude.
Obtener toda la información antes de comenzar cualquier trabajo en terreno, incluso si uno tuvo suficiente información desde el
primer día, crea un cuello de botella temporal. Adicionalmente, cuando los datos son finalmente solicitados, obtener los datos
incluye retrasos posteriores porque los auditados que deben proveer los datos pueden tener otros, tareas de mayor prioridad o
simplemente porque la extracción de los datos necesarios de la manera solicitada por los auditores puede tomar tiempo.
Porque la planificación incluye información limitada, el riesgo puede ser sobre—o subestimado o pasado por alto o todas ellas.
Especialmente para auditorías complejas, es típicamente mucho más fácil evaluar el riesgo con información detallada que con
 información en borrador. Por ejemplo, examinar los datos, su estructura, y notar tendencias y excepciones puede proveer pistas
útiles.

Una vez que el programa de auditoría está completado, usualmente con información mal interpretada, precisamente porque ningún dato
fue visto por los auditores, dos cosas pueden ocurrir. En el peor de los casos, tal vez por el pobre entendimiento del sistema y del riesgo
asociado, sin mencionar los plazos del reporte, esta será una auditoría de paso15, 16 en la cual las cajas de chequeo serán tiqueadas y
todo será declarado satisfactorio sin mirar profundamente en los datos o los procesos. En el mejor caso, los auditores se darán cuenta de
su malentendido y tendrán que escoger entre revisar el programa y/o los pasos de auditoría (y tendrán que explicar por qué el programa
de auditoría era inadecuado en el primer lugar) o tomar nota que algunos asuntos no fueron auditados debido al tiempo u otras
restricciones. Tiempo adicional se habría perdido si los auditores hubiesen hecho otros trabajos basado en supuestos acerca de los datos
que nunca vieron, como escribir software para analizar los datos mientras esperan por los datos. Las ineficiencias de auditoría son a
menudo un factor fuerte resultante en auditorías de paso. Debido a que las ventanas de tiempo y los plazos deben ser respetados, si el
tiempo se utiliza de forma ineficiente, significa que los auditores serán tentados a presentar las pruebas triviales que están seguros de
completar a tiempo en vez de las más involucradas o más complejas pruebas que lidian con muchos factores de riesgo importantes.

Durante una auditoría, el auditor no está al tanto de las prioridades de los hallazgos definitivos. El objetivo principal es descubrir y evaluar
el riesgo y proponer controles para estas áreas de riesgo. Los programas de auditoría a menudo esencialmente asumen que el resultado
ya es conocido y tratan de especificar no solo las áreas de riesgo, sino también como cada paso debe ser realizado. Como resultado, los
programas de auditoría son bastante adecuados para el cumplimiento o auditorías de paso. La gente de áreas operacionales tienden a
desaprobar dichas auditorías como rara vez les dicen algo útil. Este tipo de auditorías tiende a tomar mucho tiempo y usualmente resultan
en propuestas que significarán más molestias con siquiera algún valor real. Dicho esto, hay razones válidas para tener auditorías de
cumplimiento y programas y modelos estándar de auditoría que se ajustan bien a auditorías de cumplimiento. Es la aplicación a todas las
auditorías que puedan estar obsoletas.

¿Qué hace distinto la auditoría Ágil?

En vez de insistir en el cumplimiento de la metodología y el protocolo, una auditoría Ágil le da a los auditores mucha más libertad durante
la fase de acuerdo para tomar contacto con el sistema, configuraciones, datos, y las personas y procesos siendo auditados. Esto habilita
un mucho mejor entendimiento de los asuntos y riesgos a abordar al igual que cómo actuar frente a probarlos en detalle (por ejemplo, que
pruebas diseñar).

Una auditoría Ágil pone mucho menos énfasis en finalizar y documentar un programa formal de auditoría. En auditorías operacionales, un
programa de auditoría se diseña para abordar el riesgo y algunos de estos factores de riesgo pueden cristalizarse durante y no antes de la
auditoría. Por ejemplo, es muy difícil, y pernicioso, diseñar todos los posibles tipos de pruebas para encontrar fraudes antes de haber visto
los datos. Adicionalmente, el riesgo que pueda haber sido identificado como mayor puede resultar ser menor o no existente debido a
fuertes controles mitigantes. También, el riesgo que fue considerado más bajo o no considerado en absoluto puede ser promovido como el
principal factor de riesgo. En forma alternativa, a medida que progresa el trabajo en terreno, puede notarse que el riesgo que ni siquiera
fue considerado antes, porque los auditores no conocían el área lo suficiente para preguntar o los auditados no levantaron el riesgo
durante la discusión, es bastante importante. Como resultado, un programa de auditoría Ágil que se enfoca en pruebas y se adapta al
trabajo realizado y la evidencia descubierta puede ser mucho más adecuado para abordar el riesgo.

Las auditorías Ágiles, por lo tanto, abordan grandes cuellos de botella en muchas auditorías. Los datos necesarios, como las listas de
usuarios de sistemas del sistema mismo y un archivo o base de datos de autorización, pueden ser solicitados y preparados por los
auditados mientras los auditores aún están tratando de finalizar pasos restantes del programa de auditoría. Adicionalmente, los auditores
pueden analizar los datos ya recolectados mientras esperan a que el equipo de auditoría calendarice las reuniones de la fase de
planificación con otros auditados o los miembros del equipo. Al no insistir en la estricta separación temporal entre la planificación y el
trabajo en terreno, la auditoría se torna más eficiente. Las tareas se ejecutan en paralelo (por ejemplo la planificación puede continuar
mientras los auditados recolectan los datos solicitados, o el trabajo en terreno ocurre mientras las reuniones para abordar los asuntos de
planificación restantes son calendarizadas). Por ejemplo, si el equipo de auditoría ya ha establecido que intentará y comparará la lista de
usuarios generada por el sistema con la lista de autorizaciones, ¿necesita realmente el auditor esperar a terminar todos los demás pasos
del programa de auditoría? Esperar puede significar encontrar espacios de tiempo para más reuniones exploratorias con personal
relevante, pero posiblemente muy ocupado, al igual que con miembros del equipo de auditoría con la intención de finalizar los pasos
restantes antes de solicitar los datos relevantes o efectivamente ejecutando la comparación. Esto es ilustrado como ejemplos.

Ejemplos del mundo real

Una auditoría consideraba la revisión de registros de facturación producidos por dispositivos de SI. Estos registros son usados para
facturar por conexiones y volúmenes y, como resultado, pueden ser revisados en forma cruzada con la información recolectada en la red
donde se instalan sondas. Debido a su complejidad, los registros de sondas no son utilizados para la facturación. Esta es una tarea muy
compleja incluyendo correlaciones sofisticadas, como aquellas entre otras complicaciones como el tráfico utilizando diferentes segmentos
de red (por ejemplo, no ser tomados en cuenta por la misma sonda).

Como resultó, sólo existía un solo auditor con grandes habilidades capaz de completar esta tarea. El auditor tenía mucha experiencia con
estos sistemas antes de unirse al equipo de auditoría y tomó la tarea de revisar en forma cruzada los registros de facturación. Aunque
inicialmente fue necesario especificar detallados pasos en el programa de auditoría, rápidamente se hizo evidente que nadie más podía
seguir los pasos. Esto no tenía sentido. Entonces, en cambio, el auditor creó software para desarrollar la revisión cruzada y documentó la
funcionalidad en su código de alto nivel, para que todos pudieran verificar los hallazgos. Adicionalmente, el auditor solicitó una muestra
pequeña de datos simultáneamente con la liberación del anuncio de auditoría. Esto permitió al auditor para comenzar a trabajar en el
código de revisión cruzada inmediatamente.

El resultado es que una auditoría altamente compleja fue llevada a cabo en un período de tiempo bien corto y con resultados importantes.
Como consecuencia no planificada, el legado de esta auditoría fue un sistema completo que podía ser utilizado para monitorear la
facturación en forma permanente. A modo de comparación, el mismo proyecto fue asignado a una compañía externa que demoró tres
veces el mismo tiempo y concluyó que los datos no eran adecuados para su código.

Un caso similar consideró una prueba de penetración en los sistemas de la compañía por un auditor de SI. Resultó ser que obtener el
permiso necesario para llevar a cabo la prueba tomó un largo período de tiempo, al igual que la preparación de las herramientas de
penetración. La única razón por la que la auditoría fue llevada a cabo oportunamente fue porque la solicitud del permiso y la preparación
de las herramientas comenzaron antes y no después de la finalización del programa de auditoría.

Incluso en otra auditoría lidiando con la interfaz de seguridad de los sistemas, cada interfaz tenía sus propios asuntos de seguridad que
pudieron ser determinados sólo tras recolectar información detallada. Una vez más, la auditoría se completó a tiempo, pero sólo porque no
existía una estricta separación temporal entre la planificación y el trabajo en terreno. Específicamente, sabiendo que los miembros del
equipo de auditoría estaban ocupados con otras auditorías y encontrar una ventana de tiempo para planificar una reunión de equipo no
era fácil, el auditor líder preparó un documento para el equipo de auditoría con la lista de las interfaces y su función y asuntos de alto nivel
y simultáneamente le pidió datos relevantes a los auditados. Algunos de estos datos llegaron mientras se discutían detalles sobre la
arquitectura de la interfaz y las tareas estaban siendo asignadas dentro del equipo de auditoría. Por lo tanto, en la fase de planificación, el
equipo de auditoría tenía información concreta con la cual construir.

Debido a que el equipo contaba con casi toda la información necesaria tempranamente, no hubo cuellos de botella asociados con la
espera de los datos; de hecho, debido a que los datos estaban disponibles, algunas pruebas terminaron antes. Resultó ser que sólo un
set más de datos fue necesario para verificar y evaluar la importancia de un hallazgo. Esto tomó substancialmente más tiempo porque los
auditados estaban ocupados con otras prioridades, mientras que tenían mucho más tiempo cuando los datos iniciales fueron solicitados.
El equipo de auditoría también adoptó la práctica de documentar y verificar cada hallazgo con los auditados en la medida en que llegaban
y sin esperar a que todos los hallazgos se hayan completado. Esto fue bien recibido por los auditados, los que pudieron encontrar una
pequeña ventana de tiempo para discutir un único hallazgo y se les hizo muy complicado encontrar tiempo suficiente para discutir una
serie de hallazgos simultáneamente.

Malentendidos, riesgo y trampas ocultas

Al igual que en el desarrollo Ágil de software, una auditoría Ágil no es un substituto para la identificación de riesgo y la planificación
racional. Alguien, usualmente el administrador del proyecto o auditor líder, debe presentar una estructura básica del programa de
auditoría, el cual puede ser mejorado por el equipo. De todos modos, este es un paso inicial crucial en el cual se establece lo más rápido
posible un marco de trabajo para la discusión y el equipo tiene una base concreta sobre la cual construir. Esto no es diferente de los
programas estándares de auditoría, excepto que los pasos no necesitan ser tan detallados y definitivamente no necesitan estar
formalmente documentados. Como se mencionó antes, los programas de auditoría tienden a ser rígidos y escritos de una manera que un
auditor con mínimas calificaciones pueda seguirlo. En contraste, una auditoría Ágil necesita y hace un uso extensivo de las calificaciones y
experiencia de cada miembro del equipo.

Las auditorías Ágiles no tienen siempre la necesidad de documentar lo que fue realizado. La diferencia es cuando la documentación es
creada y que abarca. La auditoría Ágil no documenta formalmente en detalle lo que está destinada a hacer y cómo lo hará, pero si lo que
hizo y cómo.

Un contraejemplo útil puede ser una auditoría realizada sobre una nueva oferta de negocios. En este caso, la planificación incluía
preguntas sobre temas como:

Asuntos del mercado

Medioambiente legal/regulatorio
Procesos y sistemas
Soporte TI
Asuntos de continuidad del negocio

En este contraejemplo, típicamente se necesitaría construir un cuestionario llenado por los auditados. El programa de auditoría es,
esencialmente, este cuestionario. Por lo tanto, planificar sobre qué preguntar y qué evidencia será requerida para verificar las respuestas
es crucial y será, además, el entregable final. Debido a que este paso estará presente en auditorías Ágiles y tradicionales, por ejemplo, el
trabajo puesto en el programa de auditoría será directamente utilizado en los resultados. Los métodos Ágiles ofrecen pocas o ninguna
ventaja.

La identificación y priorización de áreas de riesgo, son componentes claves en el programa de auditoría. Puede ser que, en una auditoría
particular, se obtenga una pequeña ventaja por utilizar métodos Ágiles. La auditoría Ágil no es un método de todo o nada que la función
de auditoría debe emplear siempre o nunca. Es decisión del equipo de auditoría y del líder de equipo decidir si la paralelización de tareas
agrega eficiencia o beneficia a la auditoría de algún modo. Por ejemplo, si toda la información necesaria está disponible y cualquier
reunión solicitada es concedida en forma inmediata, luego la importancia de la auditoría Ágil disminuye.

Las auditorías Ágiles no eliminan la planificación. Una auditoría Ágil sustituye un plan rígido con un plan de mejora adaptable que se
ejecuta paralelamente con algún trabajo en terreno. La auditoría Ágil no elimina el control de calidad ni la documentación del trabajo hecho
ni, especialmente, los hallazgos. Los resultados nulos deben de todos modos ser documentados, en la medida en que provean
aseguramiento.

En forma similar, una auditoría Ágil no elimina o disminuye la importancia del liderazgo. Si algo se puede decir al respecto, al igual que el
desarrollo Ágil de software, le da más énfasis al liderazgo y la competencia del equipo, en la medida que los auditores no solo están
ejecutando pasos de auditoría estrictamente definidos. Ellos también diseñan, modifican e improvisan estos pasos.

Finalmente, puede discutirse que una auditoría bien planificada minimiza la interferencia de la auditoría con el trabajo diario del auditado,
mientras una auditoría Ágil, la que es percibida como menos bien planeada, puede resultar en más interferencia. Aunque las experiencias
no parecen justificar esta presunción—por cierto las auditorías Ágiles parecen enfocarse mucho más en los asuntos materiales—la línea
de fondo es que la administración y los auditados usualmente responden en forma positiva al éxito. Si las auditorías Ágiles resultan en
entregables o resultados más materiales y oportunos, ellos probablemente no solo serán aceptados, sino también preferidos. Como se
discutió antes, el potencial está allí porque las auditorías Ágiles pueden ahorrar tiempo y, por lo tanto, invertir más tiempo en asuntos
materiales. Una gran cantidad depende, por supuesto, de la ejecución real, que soporta la importancia de un equipo y liderazgo
competente. Esto, sin embargo, no es diferente de la gestión tradicional de auditorías.

La figura 2 compara auditorías Ágiles y no Ágiles. Por supuesto, cualquiera sea la metodología de auditoría seleccionada, debe ser
aprobada por la organización.

Lineamientos de auditorías Ágiles

Aunque cada auditoría puede tener sus propias características únicas, algunos de los lineamientos de auditorías Ágiles incluyen:

Luchar por obtener un temprano entendimiento de los asuntos claves de la auditoría y diseminar esta información dentro del equipo
de auditoría. Por ejemplo, ¿qué necesita ser chequeado y qué será necesario? Esta diseminación puede ser en forma de un simple
correo electrónico y no necesita ser formal.
Solicitar datos sabidamente necesarios inmediatamente, sin esperar a las reuniones del equipo. Si obtener todos los datos
consume mucho tiempo, enfocarse en una muestra de los datos. Por ejemplo, si la extracción de una gran cantidad de datos es
necesaria para la auditoría y consume mucho tiempo, solicitar algunas líneas inmediatamente y definir un tiempo para los datos
restantes. Comunicar los datos al equipo de auditoría a medida que vayan llegando. Esta y la tarea previa será normalmente
realizado por el auditor líder.
Sostener reuniones informales con el equipo y auditados para discutir los asuntos, asegurar que las áreas importantes identificadas
por el equipo o los auditados no sean dejadas fuera, verificar que todos los datos necesarios han sido recolectados o solicitados, y
asignar tareas. Mantener el rastro del trabajo realizado, asignado, puntos discutidos, etc., pero no en un documento formal.
Discutir los hallazgos a medida que son recolectados. Una vez que sean aceptados, documentarlos y, si es posible, verificar con los
auditados. No hay necesidad de esperar por todos los hallazgos para verificar un único hallazgo documentado. Es a menudo más
probable que los auditados se ajusten a un corto período de tiempo para discutir un único hallazgo que un tiempo mucho más
extenso para discutir un conjunto de ellos. Si un hallazgo es verificado, incluirlo en el reporte borrador y actualizar el reporte a
medida que los hallazgos verificados estén disponibles. De este modo, el tiempo de escritura del reporte también se acorta.
Mover los recursos si es necesario. Si un miembro del equipo termina con el trabajo, quizá porque los datos necesarios estuvieron
disponibles primero, ese miembro del equipo puede estar disponible para ayudar a otro miembro del equipo.
Conclusiones
Las auditorías, siendo esencialmente un proyecto, pueden emplear los métodos altamente eficientes de desarrollo Ágil para todo menos
para auditorías de cumplimiento. Estos métodos son especialmente apropiados para auditorías complejas y requieren un equipo de
auditores competentes y experimentados. Los auditores deben recordar que la línea de fondo es agregar valor al negocio. Si una
metodología sirve este fin, luego debe ser adoptada. Si es un obstáculo, debe ser abandonada. Con los requerimientos en aumento en
auditoría interna, ciertamente, para proveer aseguramiento oportuno en asuntos materiales,17 los métodos Ágiles en auditoría pueden ser
de gran ayuda.

Notas Finales
1
Agile, “Manifesto for Agile Software Development,” 2001, http://agilemanifesto.org/
2
ISACA, CISA Review Manual, 23rd Edition, USA, 2013, p. 191
3
Srinivasan, S.; Advanced Perl Programming, First Edition, O’Reilly Publishing, USA, August 1997
4 Saint, C.; “Can We Make Internal Auditing “Agile”?,” Internal Auditor, 2 July 2014, https://iaonline.theiia.org/can-we-make-internal-auditing-
agile
5
Prickett, R.; “Agile Auditing,” Audit & Risk, 10 July 2015, http://auditandrisk.org.uk/features/agile-auditing
6 Darlison, T.; “Agile Auditing—What It Means and How to Do It,” presented at IIA Annual Conference, September 2015,
https://www.iia.org.uk/media/1431921/tony-darlison-day-1.pdf
7
Hancock, B.; “Agile Audit,” The Ohio State University, USA, 31 May 2015, https://u.osu.edu/auditagile/
8
Spencer, A.; “Suncorp—Agile and Internal Audit!,” AgileBusinessManagement.org, 3 December 2013,
http://agilebusinessmanagement.org/content/suncorp-%E2%80%93-agile-and-internal-audit
9
Ibid.
10
Op cit, Prickett
11 Op cit, Darlison
12
Op cit, Hancock
13
Op cit, Spencer
14
Op cit, Prickett
15 Chambers, R.; “Drive-by Auditing: Don’t Be Guilty of ‘Hit and Run,’” Internal Auditor, 2 August 2012, https://iaonline.theiia.org/drive-by-
auditing-dont-be-guilty-of-hit-and-run
16
Berkowitz, A.; R. Rampell; “Drive-by Audits Have Become Too Common and Too Dangerous,” The Wall Street Journal, 9 August 2002,
www.wsj.com/articles/SB1028822538710052160
17
Marks, N.; “The Agile Internal Audit Department,” Resolver, 2014, http://resolver.com/wp-content/uploads/2014/06/The-agile-internal-audit-
department-Norman-Marks-Resolver-2014.pdf

Spiros Alexiou, Ph.D., CISA

Es un auditor TI que ha estado en una gran compañía por nueve años. Él tiene más de 20 años de experiencia en sistemas TI y ha
participado y liderado proyectos y auditorías empleando métodos ágiles. Él puede ser contactado en spiralexiou@gmail.com.

RELATED ARTICLES: The Minimum IT Controls to Assess in a Financial Audit (Part II) / Top Five Fraud Axioms IT Auditors Should Know / How the
IT Auditor Can Make Substantive Contributions to a Financial Audit / The Minimum IT Controls to Assess in a Financial Audit (Part I)

NEXT ARTICLE

Add Comments
 SUBMIT

Recent Comments
Opinions expressed in the ISACA Journal represent the views of the authors and advertisers. They may differ from policies and official
statements of ISACA and from opinions endorsed by authors’ employers or the editors of the Journal. The ISACA Journal does not attest to
the originality of authors’ content.