GTAG14 en es

Vista previa del material en texto

IPPF – Guía práctica
Revisión de cuentas
Desarrollado por el usuario
Aplicaciones
Traducido del inglés al español - www.onlinedoctranslator.com
https://www.onlinedoctranslator.com/es/?utm_source=onlinedoctranslator&utm_medium=pdf&utm_campaign=attribution
Acerca de IPPF
El Marco Internacional de Prácticas Profesionales (IPPF) es el marco conceptual que organiza la guía autorizada 
promulgada por el Instituto de Auditores Internos. La guía de IPPF incluye:
Orientación Obligatoria
El cumplimiento de los principios establecidos en la guía obligatoria es obligatorio y esencial para la práctica profesional de la auditoría interna. La 
orientación obligatoria se desarrolla siguiendo un proceso de diligencia debida establecido, que incluye un período de exposición pública para los 
aportes de las partes interesadas. Los tres elementos obligatorios del IPPF son la Definición de Auditoría Interna, el Código de Ética y elNormas 
Internacionales para el Ejercicio Profesional de la Auditoría Interna (Normas).
Elemento Definición
Definición La Definición de Auditoría Interna establece el propósito fundamental, la naturaleza y el alcance de la auditoría 
interna.
Código ético El Código de Ética establece los principios y expectativas que rigen el comportamiento de las personas y 
organizaciones en la realización de la auditoría interna. Describe los requisitos mínimos de conducta y 
expectativas de comportamiento en lugar de actividades específicas.
Estándares internacionales Estándaresse centran en principios y proporcionan un marco para realizar y promover la auditoría 
interna. ElEstándaresson requisitos obligatorios que consisten en:
• Enunciados de requisitos básicos para el ejercicio profesional de la auditoría interna y para 
evaluar la eficacia de su desempeño. Los requisitos son aplicables internacionalmente a 
nivel organizacional e individual.
• Interpretaciones, que aclaran términos o conceptos dentro de las declaraciones.
Es necesario considerar tanto las declaraciones como sus interpretaciones para comprender y aplicar las
Estándarescorrectamente. ElEstándaresemplear términos a los que se les han dado significados específicos 
que se incluyen en el Glosario.
Guía altamente recomendada
El IIA respalda la guía altamente recomendada a través de un proceso de aprobación formal. Describe las prácticas para la implementación 
efectiva de la Definición de Auditoría Interna, el Código de Ética y el Código de Ética del IIA.Estándares. Los tres elementos fuertemente 
recomendados de IPPF son los documentos de posición, los consejos prácticos y las guías prácticas.
Elemento Definición
Papeles de posición Los documentos de posición ayudan a una amplia gama de partes interesadas, incluidas aquellas que no pertenecen a la 
profesión de auditoría interna, a comprender los problemas importantes de gobierno, riesgo o control y a delinear las funciones 
y responsabilidades relacionadas de la auditoría interna.
Consejos de práctica Los Consejos para la Práctica ayudan a los auditores internos a aplicar la Definición de Auditoría Interna, el Código de 
Ética y elEstándaresy promover las buenas prácticas. Los Consejos para la práctica abordan el enfoque, las metodologías 
y la consideración de la auditoría interna, pero no detallan los procesos o procedimientos. Incluyen prácticas 
relacionadas con: cuestiones internacionales, nacionales o específicas de la industria; tipos específicos de compromisos; y 
cuestiones legales o reglamentarias.
Guías de práctica Las guías de práctica brindan orientación detallada para realizar actividades de auditoría interna. Incluyen 
procesos y procedimientos detallados, como herramientas y técnicas, programas y enfoques paso a paso, así 
como ejemplos de entregables.
Este GTAG es una Guía de práctica bajo IPPF.
Para obtener otros materiales de orientación autorizados, visite www.theiia.org/guidance/.
Guía de auditoría de tecnología global (GTAG®) 14
Auditoría de aplicaciones desarrolladas por usuarios
Autores:
Cristina A. Bellino
Douglas Ochab, CISA
Jeffery S. Rowland, CIA, CISA
junio de 2010
Copyright © 2010 del Instituto de Auditores Internos ubicado en 247 Maitland Avenue, Altamonte Springs, FL 32701, EE. UU.
Reservados todos los derechos. Publicado en los Estados Unidos de América.
Excepto para los fines previstos por esta publicación, los lectores de este documento no pueden reproducir, almacenar en un sistema de 
recuperación, redistribuir, transmitir de ninguna forma por ningún medio (electrónico, mecánico, fotocopiado, grabación u otros) exhibir, alquilar,
prestar, revender, explotar comercialmente o adaptar los datos estadísticos y de otro tipo contenidos en este documento sin el permiso del IIA.
La información incluida en este documento es de naturaleza general y no pretende abordar a ningún individuo, actividad de auditoría interna u 
organización en particular. El objetivo de este documento es compartir herramientas, recursos, información y/u otros conocimientos que
precisa, imparcial y oportuna. Sin embargo, en función de la fecha de emisión y los entornos cambiantes, ningún individuo, actividad de 
auditoría interna u organización debe actuar sobre la información proporcionada en este documento sin consultar o examinar adecuadamente.
GTAG — Índice
1. Resumen ejecutivo.................................................... .................................................... ........................................1
2. introducción.................................................... .................................................... .................................................... ... 2
2.1. Definición de aplicaciones desarrolladas por el usuario ............................................. .................................................... ...................... 2
2.2. Beneficios de las aplicaciones desarrolladas por el usuario .................................. .................................................... ..................... 2
2.3. Riesgos asociados con las aplicaciones desarrolladas por el usuario.................................... .................................................... .. 2
2.4. Diferencias entre las aplicaciones desarrolladas por el usuario y las aplicaciones compatibles y desarrolladas por TI ......... 3
2.5. Desafíos de cumplimiento................................................. .................................................... .......................................... 4
2.6. Rol de la Auditoría Interna ............................................... .................................................... .......................................... 4
3. Alcance de una auditoría de aplicación desarrollada por el usuario.................................................... ............................... 6
3.1. Definición de lo que constituye una aplicación clave desarrollada por el usuario ............................... ..................................... 6
3.2. Determinación y definición de la población de aplicaciones desarrolladas por el usuario .................................. ........................ 6
3.3. Definición de factores de riesgo .............................................. .................................................... ............................................. 6
3.4. Clasificación de riesgo ............................................... .................................................... .................................................... .......... 9
4. CONSIDERACIONES AL REALIZAR AUDITORÍAS DE APLICACIONES DESARROLLADAS POR USUARIOS.......................... 12
4.1. Atributos y capacidades de la herramienta ............................................... .................................................... ............................. 12
4.2 Mejores prácticas para controles sobre aplicaciones desarrolladas por usuarios .................................. ...................................... 13
5. DESARROLLO DEL PROGRAMA DE AUDITORÍA........................................................................................................ ..........15
5.1. Ejemplo de programa de auditoría .................................................. .................................................... ........................................... 15
6. Resumen.................................................... .................................................... .................................................... .............21
7. APÉNDICE: MUESTRA DE FLUJO DE PROCESO DE APLICACIÓN DESARROLLADA POR EL USUARIO............................................22
8. REFERENCIAS Y RECURSOS.................................................... .................................................... ......................24
9. AUTORES Y REVISORES.................................................... .................................................... ............................. 25
GTAG — Resumen ejecutivo
1. Resumen Ejecutivo
Las aplicaciones desarrolladas por el usuario (UDA) generalmente 
consisten en hojas de cálculo y bases de datos creadas y utilizadas por los 
usuarios finales para extraer, ordenar, calcular y compilar datos 
organizacionales para analizar tendencias, tomar decisiones comerciales o 
resumir datos operativos y financieros y resultados de informes. Casi 
todas las organizaciones utilizan algún tipo de UDA porque se pueden 
desarrollar más fácilmente, son menos costosos de producir y, por lo 
general, se pueden cambiar con relativa facilidad en comparación con los 
programas e informes desarrollados por el personal de TI.
Sin embargo, una vez que los usuarios finales tienen la libertad de 
extraer, manipular, resumir y analizar sus datos UDA sin la ayuda del 
personal de TI, los usuarios finales heredan los riesgos que antes 
controlaba TI. Estos riesgos incluyen la integridad, disponibilidad y 
confidencialidad de los datos.
Los riesgos de integridad de datos existen porque los UDA no están 
sujetos a controles de equilibrio manual estructurados para validar la 
salida ni a controles estrictos de gestión de cambios y desarrollo de 
aplicaciones. Los riesgos de disponibilidad existen porque los UDA 
pueden almacenarse en medios (p. ej., computadoras de usuarios finales 
o unidades flash USB) que se pierden o destruyen fácilmente y pueden no 
ser parte del proceso de respaldo periódico automatizado del 
departamento de TI. Los riesgos de confidencialidad existen porque un 
UDA y sus datos pueden transmitirse fácilmente fuera de la empresa a 
través del correo electrónico. Los datos también se pueden almacenar sin 
los controles de acceso apropiados.
También se deben considerar los factores regulatorios, ya que los UDA 
pueden tener un impacto significativo en la capacidad de una 
organización para cumplir con las regulaciones globales. La falla en el 
control adecuado del desarrollo del sistema, los cambios y el acceso lógico 
a UDA críticos puede comprometer las actividades de cumplimiento de 
una organización relacionadas con regulaciones como la Ley Sarbanes-
Oxley de EE. UU. de 2002, la Ley de intercambio e instrumentos 
financieros de Japón, la Ley Gramm-Leach-Bliley, Estándares de seguridad 
de datos de la industria de tarjetas de pago (PCI-DSS), el Marco de Basilea 
II del Comité de Supervisión Bancaria de Basilea y otras regulaciones o 
estándares financieros y de privacidad globales. Teniendo en cuenta los 
factores regulatorios y los requisitos de cumplimiento, los auditores 
internos pueden desempeñar un papel estratégico como consultores de 
la administración sobre la mejor manera de desarrollar, implementar y 
mantener un marco de control UDA efectivo. Esta función se suma a la 
función de aseguramiento tradicional de los auditores internos para 
determinar si los controles internos sobre las UDA están diseñados 
correctamente y funcionan de manera efectiva. (Nota:Es imperativo que 
todas las partes entiendan que el desarrollo del marco de control de UDA 
es responsabilidad de la administración, y los auditores internos no deben 
apropiarse del marco).
Debido a que la administración se basa en los UDA, que pueden ser una 
parte importante de los informes financieros y los procesos operativos, así 
como la toma de decisiones relacionada, el auditor interno debe determinar y 
revisar los riesgos de los UDA e incorporar una auditoría de los UDA en el plan 
anual de auditoría interna, según corresponda. El proceso de auditoría incluye 
una serie de pasos que incluyen
identificar los UDA críticos, evaluar el nivel de riesgo asociado con 
cada UDA y probar los controles para determinar si son suficientes 
para reducir los riesgos asociados a un nivel aceptable en función del 
apetito y la tolerancia al riesgo de la organización. Los auditores 
internos deben prestar especial atención a la revisión de los asientos 
de diario manuales que normalmente respaldan los UDA como 
fuente de hojas de cálculo potencialmente importantes. Si los 
auditores internos no tienen acceso a un inventario generado por la 
administración y una clasificación de riesgo para las UDA, harían bien 
en mirar primero las UDA que respaldan los procesos de cierre 
financiero y presentación de informes como base para el alcance de 
la auditoría. En esta situación, un auditor interno probablemente 
identificaría de inmediato una debilidad de control debido a la falta 
de un marco de control de UDA suficiente, impulsado por la 
administración. Sin embargo,
GTAG-14 Auditoría de aplicaciones desarrolladas por usuariosproporciona 
instrucciones sobre cómo definir el alcance de una auditoría interna de UDA. 
Más específicamente, enfoca al auditor en:
• Identificar la disponibilidad de un marco de control de UDA existente que 
incluya políticas, procedimientos, inventarios de UDA y una 
metodología de clasificación de riesgos en la que se pueda confiar 
para fines de determinación del alcance.
• Usar los componentes del marco de control de UDA existentes para 
determinar el alcance de la población de UDA que se incluirá en la 
auditoría.
GTAG-14 también brinda orientación sobre cómo se puede 
aprovechar el papel del auditor interno como consultor para 
ayudar a la gerencia a desarrollar un marco de control UDA 
efectivo, que incluye:
• Identificación de la población UDA mediante el uso de diferentes técnicas 
de descubrimiento.
• Evaluar y clasificar los riesgos asociados con cada UDA en 
función del impacto potencial y la probabilidad de 
ocurrencia del riesgo.
A continuación, este GTAG describe otras consideraciones que los 
auditores internos deben abordar al realizar auditorías de UDA. Estas 
consideraciones pueden incluir las inquietudes de la administración, los 
resultados de auditorías anteriores, las pruebas de los controles 
generales de TI y la consideración de las mejores prácticas.
Finalmente, GTAG-14 proporciona un flujo de proceso de UDA de 
muestra, así como un programa de auditoría interna de UDA y hojas de 
trabajo de apoyo para ayudar a los auditores internos a organizar y 
ejecutar una auditoría. Sin embargo, este documento no pretende 
proporcionar pruebas y técnicas exhaustivas de auditoría interna de UDA; 
más bien, proporciona consideraciones clave para auditar los UDA.
1
GTAG — Introducción
2. Introducción 2.2. Beneficios de las aplicaciones desarrolladas por el usuario
Casi todas las organizaciones utilizan algún tipo de UDA porque 
son:
• Más rápido de desarrollar y usar.Puede tomar varias semanas y 
probablemente sea costoso para el personal de TI, que sigue un 
riguroso proceso de ciclo de vida de gestión de cambios y 
desarrollo de sistemas, para crear o modificar un informe que 
extrae información de un sistema en el formato que necesita un 
administrador. Ese mismo administrador a menudo puede 
extraer y formatear la información en cuestión de horas 
mediante el uso de herramientas y utilidades disponibles para 
los usuarios finales.
• Herramientas fácilmente disponibles a un menor costo.Las 
herramientas comúnmente disponibles, como las hojasde cálculo, 
ofrecen a los usuarios una forma de automatizar la lógica comercial 
sin pasar por un proceso largo y costoso de selección de software y/o 
desarrollo e implementación del sistema.
• Configurable y flexible.En comparación con las aplicaciones de TI 
administradas tradicionalmente, los usuarios tienen una flexibilidad 
mucho mayor para configurar los UDA para satisfacer las necesidades 
comerciales. Por ejemplo, la información en las hojas de cálculo se 
puede ordenar y reformatear fácilmente para permitir un análisis 
adicional por parte de usuarios que no están familiarizados con los 
lenguajes de programación estructurados y las metodologías de 
desarrollo de aplicaciones.
En la economía global actual, el sustento de una organización se ve afectado 
por la forma en que la actividad de TI administra la disponibilidad, integridad y 
confidencialidad de la información y los sistemas de TI utilizados para operar 
los procedimientos comerciales centrales.1
Sin embargo, los UDA pueden socavar la capacidad de la actividad de TI 
para llevar a cabo sus responsabilidades cada vez más importantes 
porque presentan desafíos únicos que tradicionalmente no son 
abordados por los procesos de TI estándar. Además, los UDA también 
presentan desafíos de cumplimiento que van desde Sarbanes-Oxley hasta 
las leyes europeas. Si no se gestionan adecuadamente, los UDA tienen el 
potencial de socavar los controles incluso en las organizaciones mejor 
gestionadas y controladas.
Este GTAG abordará:
• Definición de UDA.
• Beneficios de las UDA.
• Riesgos asociados a los UDA.
• Diferencias entre los UDA y las aplicaciones compatibles y 
desarrolladas por TI.
• Desafíos de cumplimiento.
• El papel del auditor interno para ayudar a las 
organizaciones a gestionar y mitigar los riesgos 
asociados con los UDA.
• Alcance y consideraciones para una auditoría interna de las 
UDA.
• Desarrollo de un programa de auditoría interna de la UDA. 2.3. Riesgos asociados con las aplicaciones 
desarrolladas por el usuario
Aunque los UDA brindan varios beneficios, también presentan riesgos 
para las organizaciones, algunos de los cuales podrían ser significativos. Si 
los riesgos asociados con los UDA no se gestionan y controlan 
adecuadamente, la integridad, disponibilidad y confidencialidad de los 
UDA pueden verse comprometidas.
El riesgo más importante es la integridad de los datos y la 
información que se gestionan y reportan. La gerencia puede suponer 
que los datos contenidos en un informe generado a partir de un UDA 
son tan confiables como la información generada a partir de una 
aplicación compatible y desarrollada por TI. Sin embargo, la 
naturaleza de cómo se desarrollan los UDA significa que esta 
suposición puede no ser correcta porque los UDA normalmente no 
siguen un ciclo de vida estructurado y controlado de desarrollo de 
aplicaciones/gestión de cambios.
Las fallas de control dentro de los UDA se pueden atribuir a:
• Falta de procesos de desarrollo estructurados y 
controles de gestión del cambio.La falta de estructura y 
controles en torno al desarrollo y/o cambio de UDA 
puede conducir a cálculos y resultados de datos 
inexactos. Con toda probabilidad, el factor principal de 
datos o informes inexactos se remonta a la falta de 
procesos formales de desarrollo y controles de gestión 
de cambios de aplicaciones.
• Problemas de descarga de datos.La falta de controles en 
torno a la descarga de datos de aplicaciones desarrolladas o 
compatibles con TI en la UDA puede conducir al uso de
2.1. Definición de aplicaciones desarrolladas por el usuario
Los UDA son aplicaciones que desarrollan los usuarios finales, 
generalmente en un entorno de TI no controlado. Al igual que las 
aplicaciones de TI tradicionales, los UDA automatizan y facilitan los 
procesos comerciales. Aunque los UDA más generalizados son las hojas 
de cálculo, los UDA también pueden incluir bases de datos de usuarios, 
consultas, scripts o resultados de varias herramientas de generación de 
informes. En general, una UDA es cualquier aplicación que no se gestiona 
y desarrolla en un entorno que emplea controles generales de TI sólidos.
Es muy probable que incluso las organizaciones con entornos 
de TI maduros usen y confíen en los UDA en sus actividades de 
administración diarias. Estos UDA van desde cálculos simples y 
seguimiento de información hasta el uso de macros complejas 
que compilan estados financieros. Estudios2han revelado que 
incluso las grandes empresas con entornos de TI maduros 
utilizan cientos, a veces miles, de hojas de cálculo en el curso de 
sus actividades comerciales diarias.
1Grupo de Cumplimiento de Políticas de TIInforme anual 2008: 
Gobernanza, riesgo y cumplimiento de TI: mejora de los resultados 
comerciales y mitigación del riesgo financiero
2de GartnerLos controles de hoja de cálculo necesitan un impulso
2
GTAG — Introducción
información inexacta. También pueden ocurrir problemas similares para las 
aplicaciones que dependen de la salida de UDA.
• Complejidad creciente.El riesgo de que los UDA se vuelvan más 
complejos con el tiempo de lo que se pretendía originalmente es 
a menudo un lugar común. Sin un diseño o arquitectura 
adecuados, pueden ocurrir errores en la manipulación de datos 
y/o en la salida resultante.
• Falta de experiencia como desarrollador.El desarrollo de 
UDA por parte de personas que no están familiarizadas con 
la funcionalidad de una aplicación en particular puede hacer 
que utilicen prácticas de desarrollo ineficientes o ineficaces. 
Por ejemplo, al diseñar una fórmula en una aplicación de 
hoja de cálculo, el desarrollador de la UDA puede "codificar" 
un número particular en un cálculo en lugar de hacer 
referencia al número de un campo en la hoja de cálculo o 
usar la funcionalidad de la aplicación integrada.
• Falta de controles de versión.Muchas personas pueden actualizar los 
UDA, lo que genera varios errores resultantes de la eliminación de 
cambios o correcciones cuando los archivos más antiguos 
sobrescriben una versión más nueva.
• Falta de documentación.La falta de documentación 
formal del diseño y la funcionalidad de UDA crea un 
entorno que puede llevar a que se ingrese, procese y, 
finalmente, se informe o se use información inexacta 
en otros lugares. Además, la falta de documentación 
dificulta el respaldo y/o la transición del uso de la 
UDA a otro empleado o departamento.
• Falta de apoyo.Los UDA pueden ser desarrollados por un 
empleado que utiliza una tecnología desconocida para otros en 
la organización, lo que puede crear problemas de soporte en el 
futuro.
• Controles de entrada y salida limitados.La falta de controles de 
entrada y salida apropiados, como verificaciones de integridad, 
ediciones de validez y rutinas de balanceo, puede generar 
errores en los datos.
• Falta de pruebas formales.Si no se prueba correctamente la 
integridad y la precisión de un UDA, se pueden producir errores no 
detectados.
• Columnas de datos ocultos u hojas de trabajo.Los UDA pueden 
contener columnas de datos ocultos y hojas de trabajo que no se 
detectan ni se prueban.
de esfuerzos puede ocurrir cuando los usuarios desarrollan UDA con una 
funcionalidad similar a otras UDA o aplicaciones utilizadas dentro de la 
organización. Finalmente, y en muchos casos, los deberes no están 
debidamente segregados entre la(s) persona(s) que diseñaron, 
desarrollaron y probaron el UDA. La mayoría de las veces, los usuarios 
finales que crearon el UDA son las mismas personas que lo usan. Esta 
falta de segregación puede permitir que existan errores de diseño, 
programación y/o lógica sin ser detectados.
2.4. Diferencias entre las aplicaciones desarrolladas por 
el usuario y las desarrolladas por TI
y aplicaciones compatibles
2.4.1. Desarrollo
El desarrollo de UDA sigue un proceso significativamente diferente al 
ciclo de vida de una aplicación desarrollada y respaldada por TI. En 
general, para una aplicación desarrollada y respaldada por TI, existe 
unciclo de vida estándar que abarca un análisis de factibilidad que 
incluye una evaluación de riesgos; definición de requisitos; una fase 
de diseño, construcción y fase de prueba; y una revisión posterior a 
la implementación para garantizar que el producto final satisfaga las 
necesidades de los usuarios y funcione según lo diseñado. A lo largo 
de estas etapas, un representante de gestión de riesgos, auditoría 
interna y/o seguridad de la información (SI) debe formar parte del 
proceso de gestión del proyecto para ayudar a garantizar que la 
aplicación se implemente con los controles adecuados.
Por el contrario, los UDA a menudo son desarrollados ad hoc por 
personas fuera de los roles y responsabilidades formales de TI, en un 
período corto de tiempo y, a menudo, sin el beneficio de los controles 
internos proporcionados por un ciclo de vida estructurado de desarrollo 
de aplicaciones y gestión de cambios. Una UDA generalmente se 
construye con poca consideración al diseño y sin las aprobaciones 
correspondientes. Los controles de aplicaciones suelen ser una idea de 
último momento, si es que se tienen en cuenta. Con frecuencia, hay pocas 
pruebas más allá de una revisión superficial para asegurarse de que la 
información parezca correcta. Si se realizan pruebas, a menudo las realiza 
la persona que diseñó y utiliza la aplicación. Finalmente, mientras que la 
documentación del sistema está presente con la mayoría de las 
aplicaciones desarrolladas por TI, los UDA generalmente se desarrollan 
sin ninguna documentación que explique qué hace o cómo funciona el 
UDA.
Además de la integridad de los datos, la confidencialidad también puede 
verse comprometida si no se aprovechan los mecanismos de seguridad y 
control de acceso disponibles dentro de la propia plataforma UDA. Los 
UDA generalmente se almacenan en PC menos seguras, lo que puede 
aumentar aún más la probabilidad de una violación de la confidencialidad.
Además, es posible que no se realice una copia de seguridad de los UDA 
mantenidos en una PC o que los medios de copia de seguridad se mantengan 
en la misma ubicación donde se almacena la copia original, lo que corre el 
riesgo de perder datos si la PC se destruye o se vuelve inaccesible. Pueden 
ocurrir infracciones de licencia de software si el software utilizado para crear el 
UDA no tiene la licencia adecuada para la organización. Además, la duplicación
2.4.2. Despliegue
Cuando una aplicación desarrollada por TI se pone en funcionamiento, el 
código de programación generalmente se almacena en una aplicación de 
administración de código fuente para evitar que la aplicación se cambie 
accidental o intencionalmente. Si se cambia el código, normalmente 
existen registros de auditoría que pueden detallar los cambios. Por el 
contrario, los UDA están expuestos al potencial de corrupción de datos 
como resultado de la falta de seguridad y controles de versiones. Los UDA 
generalmente se encuentran en lugares públicos.
3
GTAG — Introducción
carpetas de red accesibles que carecen de la seguridad lógica adecuada para 
proteger contra cambios no autorizados. Además, puede haber pocas pistas de 
auditoría que registren o realicen un seguimiento de los cambios.
ciertos controles sin probar los datos generados por el sistema de los que 
dependían los controles probados; los auditores no probaron los 
controles sobre las aplicaciones que procesaban transacciones 
financieramente significativas, incluidas las hojas de cálculo manuales 
importantes”.3Esta es una señal de un mayor escrutinio en el futuro sobre 
las hojas de cálculo financieras de alto riesgo.
Las debilidades en los controles de confidencialidad sobre los UDA también 
pueden generar problemas de cumplimiento. Para cumplir con las 
reglamentaciones mencionadas anteriormente además de las leyes y 
estándares de privacidad, es necesario que los auditores internos identifiquen 
la información del cliente o paciente, su ubicación de almacenamiento, su uso 
en UDA y los sistemas informáticos relacionados que almacenan la información.
El uso de UDA puede dificultar la identificación, el inventario y el control 
de la información de identificación personal (PII), como el crédito del 
cliente y la información del paciente, porque los UDA normalmente no 
forman parte de los esquemas de clasificación de datos de las 
organizaciones. Una vez que los auditores internos identifican la 
información del cliente o del paciente, los controles de acceso sobre el 
UDA deben ser suficientes no solo para protegerlo contra actualizaciones 
no autorizadas sino también para ver el acceso. Debido a que los UDA 
normalmente residen en la PC de un usuario o en un medio extraíble, se 
vuelve cada vez más difícil controlar el acceso y proteger adecuadamente 
la información.
Para las instituciones financieras de EE. UU., la guía del Consejo 
Federal de Examen de Instituciones Financieras de EE. UU. (FFIEC) 
requiere que existan estándares para las UDA.4Como se describe en 
FFIEC's Manual de examen de tecnología de la información, las 
instituciones financieras deben incluir procedimientos para 
administrar los UDA desarrollados internamente en sus estándares 
de desarrollo de aplicaciones. El FFIEC reconoce que con frecuencia 
no existen controles formales y procedimientos de gestión de 
cambios de aplicaciones en torno al desarrollo de UDA. Como 
resultado, la institución financiera necesita determinar su nivel de 
confianza en la UDA para tomar decisiones comerciales, lo que 
determinará hasta qué punto son necesarios los procedimientos 
formales de desarrollo, los controles de cambio de aplicaciones y los 
procedimientos de respaldo.
Las instituciones financieras también deben considerar los estándares 
de Basilea II relacionados con los riesgos operativos, que se definen como 
“el riesgo de pérdida resultante de procesos, personas y sistemas internos 
inadecuados o fallidos o de eventos externos”.5
El estándar describe los criterios a considerar en la medición de 
los riesgos operativos, como el robo de información. La falta de 
controles sobre las UDA puede contribuir a los riesgos 
operativos y la pérdida de información “privada y confidencial”.6
Por lo tanto, la identificación de controles sobre el desarrollo y 
uso de UDA es necesaria para garantizar el cumplimiento de las 
normas.
2.4.3. Operaciones
Los UDA no se consideran en los procesos típicos de gobierno de TI, ya que solo 
los conocen los usuarios principales y no forman parte de las evaluaciones de 
riesgos de TI ni de los esquemas de clasificación de datos típicos. Los controles 
de acceso, incluso cuando están presentes, suelen ser débiles y, a menos que se 
almacenen en una unidad compartida, es posible que no se realice una copia de 
seguridad de los UDA.
2.5. Desafíos de cumplimiento
Dada la falta frecuente de controles estructurados sobre los UDA, su uso 
puede presentar a las organizaciones varios desafíos de cumplimiento 
relacionados con las normas y reglamentos específicos de la industria y 
del país, como la Ley Sarbanes-Oxley de EE. UU., la Ley Gramm-Leach-
Bliley, la Ley de Salud Ley de Portabilidad y Responsabilidad de Seguros 
de 1996, orientación del Consejo Federal de Examen de Instituciones 
Financieras, Ley de Protección de Datos del Reino Unido de 1998, Ley de 
Intercambio e Instrumentos Financieros de Japón, ley de Alemania sobre 
confidencialidad de los empleados, regulaciones europeas de privacidad, 
Basilea II y PCI-DSS, para nombrar unos pocos.
Según Sarbanes-Oxley y la Ley de Bolsa e Instrumentos 
Financieros de Japón, las empresas públicas deben demostrar que 
los controles sobre los informes financieros están diseñados y 
funcionan de manera eficaz. Sin embargo, la falta de controles sobre 
el desarrollo y uso de UDA puede dificultar esto dependiendo de su 
uso con respecto a la información financiera externa. Los controles 
internos deben diseñarse e implementarse para limitar el riesgo 
asociado con el desarrollo y uso de UDA.
La Juntade Supervisión de Contabilidad de Empresas Públicas 
(PCAOB), que es responsable de monitorear las actividades de las 
firmas de auditoría externa de acuerdo con Sarbanes-Oxley y el 
cumplimiento del Estándar de Auditoría No. 5 (AS5): Una auditoría de 
control interno sobre la información financiera que está integrada 
con un Auditoría de Estados Financieros — emitió un Informe sobre 
la Implementación del Primer Año del Estándar de Auditoría No. 5. El 
informe indicó que: “Los auditores probaron
3Publicación de PCAOB No. 2009-006, página 8
4de FFIECManual de examen de tecnología de la información, 
Folleto de Desarrollo y Adquisición
2.6. Rol de Auditoría Interna
5Basilea II, Párrafo 644 La actividad de auditoría interna se encuentra en una posición única para 
comprender la confianza de la administración en los UDA, revisar el uso 
de los UDA por parte de la organización y evaluar el riesgo presentado.6Basilea II, Párrafo 819
4
GTAG — Introducción
a la organización Para los UDA de alto riesgo, la actividad de 
auditoría interna también está en condiciones de recomendar si 
se requieren procesos de desarrollo, gestión de cambios y 
controles y cómo implementarlos en forma de un marco de 
control de UDA.
Los auditores internos pueden recomendar y ayudar a la 
organización a desarrollar estándares basados en el riesgo que se 
pueden usar para desencadenar un proceso de desarrollo más 
riguroso para los UDA. Estos estándares también se pueden usar 
para evaluar periódicamente los UDA existentes porque el diseño 
generalmente cambia con el tiempo y puede aumentar en 
complejidad. Sin embargo, los auditores internos deben recordar 
permanecer independientes cuando ayuden a la organización a 
desarrollar estándares, procedimientos o controles para no afectar 
su objetividad. Consulte el Estándar de atributos 1130 del Marco 
Internacional de Prácticas Profesionales (IPPF) del IIA: Deterioro de la 
independencia u objetividad para obtener más información.
La participación de la actividad de auditoría interna durante el 
desarrollo de los UDA ayuda a reducir el riesgo de que los problemas y las 
debilidades de seguridad y control no se identifiquen hasta más adelante 
en el ciclo de vida del desarrollo de los UDA. Los cambios realizados más 
adelante en el ciclo de vida de un UDA pueden ser más costosos que si se 
hubieran considerado antes en el proceso de desarrollo, como en la fase 
de requisitos.
Desafortunadamente, el desarrollo de un UDA normalmente no 
ocurre como parte de un proyecto formal; por lo tanto, los auditores 
internos deben ayudar a la gerencia a crear conciencia dentro de la 
organización sobre la necesidad de estándares en torno al desarrollo 
de UDA y la aplicación de las mejores prácticas. Los auditores 
internos podrían ayudar a la gerencia a desarrollar un programa 
UDA efectivo y ayudar a promoverlo entre la comunidad de usuarios. 
Uno de los principales desafíos es crear una definición de cuándo, 
por ejemplo, una hoja de cálculo se vuelve clave para los informes 
financieros y operativos.
Los auditores internos deben revisar las políticas y los procedimientos 
de la organización para determinar si abordan adecuadamente el 
desarrollo y la protección de los UDA. Los auditores internos también 
deben probar el cumplimiento de esas políticas y procedimientos como 
parte de una auditoría interna. Si las políticas, los procedimientos, los 
inventarios y los procedimientos de evaluación de riesgos de UDA son 
deficientes o inexistentes, esas debilidades de control deben 
documentarse e informarse a la gerencia como parte de la auditoría.
Durante el curso de la realización de una revisión, los 
auditores internos deben proporcionar a la gerencia una 
evaluación independiente de si los UDA en los que se basan las 
decisiones comerciales críticas están adecuadamente 
controlados y si brindan información completa y precisa. 
Proporcionar tal evaluación requeriría que un auditor interno:
• Determinar si la gerencia ha identificado UDA 
críticos.
• Revisar la evaluación de riesgos de la gerencia.
• Seleccionar las UDAs con mayor significancia de 
riesgo.
• Evaluar el nivel de los controles de mitigación.
• Revisar la documentación.
• Evaluar los controles, cuando sea necesario, sobre:
o
o
o
o
Cambios y modificaciones. Copia de 
seguridad y recuperación.
Seguridad.
Integridad de los datos.
Los detalles relacionados con los pasos anteriores se proporcionan en 
las siguientes secciones. Existiría una debilidad de control si la gerencia no 
ha completado un inventario y una evaluación de riesgos relacionados 
con los UDA.
5
GTAG: alcance de una auditoría de aplicaciones desarrollada por el usuario
3. Alcance de una auditoría de aplicación 
desarrollada por el usuario
perdido o corrompido, la pérdida afectaría la efectividad 
del control.
Como se enfatiza enGTAG-11: Desarrollo del plan de auditoría de TI, 
es importante comenzar con la perspectiva correcta al desarrollar el 
plan de auditoría interna: “Una perspectiva adecuada a tener en 
cuenta es que la tecnología solo existe para respaldar y promover los 
objetivos de la organización y es un riesgo para la organización si su 
falla resulta en la incapacidad para lograr un objetivo comercial”. A lo 
largo de este GTAG, el término tecnologíasimplemente se reemplaza 
por el términoaplicaciones desarrolladas por el usuario. Es 
importante comprender los riesgos que presenta el uso de UDA para 
la capacidad de la organización de lograr sus objetivos operativos, 
financieros y de cumplimiento, ya sea como parte de un análisis 
enfocado o como parte de una auditoría integrada donde el 
componente UDA se considera dentro del negocio. contexto de la 
revisión. Mantener un enfoque claro en los objetivos y riesgos 
comerciales ayudará al auditor interno a desarrollar un plan de 
auditoría que centre los recursos de auditoría en los riesgos y 
controles más importantes para la organización. La actividad de 
auditoría interna puede utilizar los pasos presentados en el resto de 
la sección 3 para:
• Revisar la adecuación de un marco de control de UDA 
existente; o
• Ayudar a la gerencia a desarrollar o aumentar un marco 
de control efectivo de UDA.
3.2. Determinación y definición de la población de 
aplicaciones desarrolladas por el usuario
La gerencia puede solicitar una revisión de UDA específicos y conocidos 
(por ejemplo, aquellos que respaldan las entradas de diario) o puede 
requerir la identificación de todos los pasos y herramientas utilizados para 
respaldar los procesos comerciales. En cualquier caso, si la gerencia no 
mantiene una lista consolidada de aplicaciones de UDA, el auditor puede, 
en el rol de consultor, guiar a la gerencia sobre cómo identificar e 
inventariar las UDA mediante la evaluación de la documentación del 
proceso comercial, como los flujos de procesos comerciales y las 
narrativas de los procedimientos. Otras técnicas que la gerencia puede 
considerar para identificar la población de UDA incluyen:
• El uso de una función de búsqueda para identificar etiquetas de archivos de hojas de cálculo y 
bases de datos en todos los directorios de archivos o en directorios de archivos específicos 
relacionados con un proceso comercial.
• Uso de herramientas de software adquiridas para detectar poblaciones de UDA. 
(Consulte la sección 4.1 para conocer los atributos y capacidades de la 
herramienta de descubrimiento de UDA).
• Revisión de informes que identifican entradas de diario manuales, que 
probablemente estén respaldadas por un UDA.
3.3. Definición de factores de riesgo
Al desarrollar un marco de control de UDA, el proceso generalmente 
comienza con entrevistas a miembros clave de la gerencia y el personal. 
Esto es necesario para obtener una comprensión completa de quién usa 
los UDA y cómo se usan como parte de los procesos comerciales, las 
funciones de informes, los programas de cumplimiento o la estructura de 
control. Establecer pautas de materialidad será fundamental durantela 
fase de evaluación de riesgos que se describe más adelante en esta 
sección.
Evaluar el riesgo de la UDA que es relevante para los 
objetivos operativos, financieros y de cumplimiento 
generales de la organización presenta al auditor interno un 
desafío considerable. El uso de hojas de cálculo u otros UDA 
para acumular y calcular información financiera operativa y 
material crítica puede presentar un riesgo significativo para 
la organización, que incluye:
• Problemas de integridad de datos.
• Errores cometidos durante la entrada, el procesamiento y la salida, 
incluidas las interfaces y los informes.
• Errores o manipulación intencional debido a archivos no seguros o 
cambios no administrados.7
La Sección 3.1 describe los elementos clave requeridos de un 
marco de control UDA eficaz para permitir que el auditor alcance 
adecuadamente la revisión.
3.1. Definición de lo que constituye una aplicación 
clave desarrollada por el usuario
Definir lo que constituye un UDA clave es fundamental para 
desarrollar el alcance de la auditoría interna. Debido a que cada hoja 
de cálculo o base de datos recién creada no constituye un UDA, la 
gerencia debe determinar y definir qué constituye un UDA clave. 
Como recordatorio, para los fines de este GTAG, los UDA son 
cualquier aplicación que no se administre y desarrolle en un entorno 
de TI tradicional y bajo un proceso de desarrollo formal. Las hojas de 
cálculo utilizadas de forma ad hoc (para proporcionar listas de 
información o para ilustrar cuantitativamente los datos disponibles 
en otros lugares) generalmente no se consideran UDA. Una UDA es 
clave si se cumple al menos uno de los siguientes criterios:
• La UDA se usa para iniciar, acumular, registrar, informar o 
monitorear transacciones importantes relacionadas con 
informes financieros e informes clave de gestión operativa y/
o cumplir con los requisitos de cumplimiento normativo.
• El uso de la UDA es inherente a la realización de procesos clave 
de control financiero y/u operativo (p. ej., conciliaciones de 
cuentas e informes de indicadores clave de rendimiento), de 
modo que si la hoja de cálculo o los datos se
El auditor interno puede guiar a la gerencia sobre el uso de técnicas de 
evaluación de riesgos para identificar vulnerabilidades críticas relacionadas con 
las operaciones, las finanzas y las operaciones de la organización.
7Servicios ACL “Hojas de cálculo: una herramienta de alto riesgo para el 
análisis de datos”. Libro blanco, página 1.
6
GTAG: alcance de una auditoría de aplicaciones desarrollada por el usuario
informes y requisitos de cumplimiento según lo exige la Norma 
de Desempeño 2120 de IPPF: Gestión de Riesgos. Se deben 
considerar dos factores en la evaluación: el impacto potencial de 
una falla y la probabilidad de una falla.
Como mínimo, los factores de riesgo para identificar el impacto de 
una falla en un UDA deben incluir:
• Materialidad financiera, operativa y de cumplimiento 
normativo de la UDA.El proceso de evaluación de riesgos 
comienza con la revisión del inventario de UDA y la 
determinación de si una falla en la integridad de la UDA 
representa una amenaza probable para la confiabilidad 
de los estados financieros, los informes clave de gestión 
operativa y/o los requisitos de cumplimiento normativo.
• Vida esperada y frecuencia de uso de la aplicación.Si se 
desarrolla una hoja de cálculo o una base de datos para un 
uso repetitivo o continuo de manera regular, puede ser una 
UDA de alto impacto.
• Número de usuarios tanto de la aplicación como de los 
resultados.Si las hojas de cálculo o las bases de datos son 
accesibles para más de un usuario y se utilizan para 
proporcionar datos a múltiples destinatarios, es más probable 
que sean un UDA de alto impacto.
Los criterios de riesgo adicionales para determinar la probabilidad pueden 
incluir:
• Relación con otros sistemas y sus salidas. Es menos probable que 
las hojas de cálculo que producen resultados que se verifican 
fácilmente con otras fuentes de datos confiables se consideren 
UDA de alto riesgo. Sin embargo, las hojas de cálculo que 
dependen de enlaces a otras fuentes de datos donde los 
resultados no se confirman fácilmente probablemente califiquen 
como UDA de mayor riesgo. Considere la siguiente guía de IIA 
que se puede adaptar para su uso en la determinación de UDA 
dentro del alcance:
“Si la operación normal de la parte manual del control es 
suficiente para detectar un error en la parte automatizada (p. ej., 
el informe de la computadora), entonces el control puede 
considerarse completamente manual ya que no se confía en la 
aplicación de la computadora. Por ejemplo, una conciliación 
bancaria podría usar un informe del sistema de contabilidad 
general de transacciones en efectivo; si el informe fuera 
incorrecto o incompleto, sería detectado por el proceso de 
conciliación bancaria”.8
• Directrices establecidas y utilizadas durante el diseño de controles 
de entrada y salida (p. ej., el área de entrada de datos no 
contiene fórmulas o los datos de entrada están en el mismo 
orden que los datos de origen).
• Directrices lógicas establecidas y seguidas durante el 
desarrollo del UDA y cuando se realizan cambios en los 
UDA existentes (p. ej., uso de fórmulas que redondean y 
cruzan los datos, bloqueo y protección de celdas, 
colocación de valores críticos en celdas separadas, etc.).
• Directrices establecidas y seguidas para las pruebas y 
aprobaciones de UDA recién desarrollados y 
modificaciones a UDA existentes.
• Fallos de control previo asociados con la dependencia de los 
UDA.
• Directrices de acceso establecidas y seguidas que controlan el 
acceso a los UDA (p. ej., almacenamiento y limitación a los 
usuarios apropiados).
• Conocimiento del personal responsable de la creación y 
mantenimiento de la UDA.
• Uso del control de versiones.
• Uso de controles de seguimiento.
Como mínimo, los factores de riesgo para identificar la 
probabilidad de falla en un UDA deben incluir:
• Complejidad de obtener insumos y generar los productos 
deseados.Las hojas de cálculo con macros o enlaces a bases de 
datos u otras hojas de cálculo, grandes cantidades de datos, el 
uso de extractos de datos o cálculos complejos tienen más 
probabilidades de ser ADU clave.
• Frecuencia de modificación de la UDA.Como era de esperar, 
cuantos más cambios se produzcan en la hoja de cálculo o la 
base de datos, mayor será el riesgo de que se produzca un 
cambio descontrolado que dé lugar a un error en los 
estados financieros, los informes de gestión o los informes 
de cumplimiento normativo.
Si bien los criterios de riesgo de impacto y probabilidad pueden ser 
apropiados para algunas organizaciones, otras pueden usar los UDA de 
manera tan amplia que pueden ser necesarios otros criterios de riesgo 
relevantes para garantizar que se gaste el nivel adecuado de recursos 
para mitigar los riesgos asociados con el uso de los UDA. Los criterios de 
riesgo adicionales para determinar el impacto pueden incluir:
• El número de procesos comerciales que dependen de la 
UDA.
• El número de controles soportados por la UDA.
• Fuentes alternativas o independientes de datos y/o 
controles establecidos que detectarían una falla de 
control de UDA.
• Controles alternativos o fuentes de datos que detectarían un error 
de UDA o un problema de integridad.
• Información confidencial, como PII, contenida en la 
UDA.
El resultado de establecer y evaluar los factores de riesgo 
clave asociados con el inventario UDA determinará los criterios 
por los cuales se realiza la evaluación de riesgos.
8Sarbanes-Oxley Sección 404: Una guía para la gestión por parte de 
profesionales de control interno,Página 34
7
GTAG: alcance de una auditoría de aplicaciones desarrollada por el usuario
Ejemplo de criterios de clasificación de riesgo de impacto
1. Materialidad Financiera.El impacto en los estados financieros se define por la suma de las transacciones financieras o informes respaldados por la 
UDA enel transcurso del trimestre, neto de cualquier reversión de las entradas del trimestre anterior. Un ejemplo de clasificación de riesgo 
financiero material es:
Materialidad Financiera
Clasificación Impacto en la Cuenta de Resultados Impacto en el Balance
Alto $3 millones o más (antes de impuestos, en promedio) por trimestre $3 millones o más (en promedio) por trimestre
Medio $ 1,5 millones a < $ 3 millones $ 1,5 millones a < $ 3 millones
Bajo < $ 1,5 millones < $ 1,5 millones
Sin impacto 0 0
2. Materialidad operativa.El impacto operativo se define por la suma de la gestión de decisiones soportada por la UDA.
Materialidad operativa
Clasificación Impacto en la Gestión de Decisiones
Alto Se confía mucho en los UDA
Medio Se confía parcialmente en los UDA
Bajo No se confía en UDA críticos
Sin impacto No se confía en los UDA
3. Cumplimiento Materialidad.El impacto en el cumplimiento se define por la posibilidad de que se produzca una sanción significativa o una divulgación dañina 
como resultado de un error de los UDA utilizados para respaldar el programa de cumplimiento.
Cumplimiento Materialidad
Clasificación Impacto en los Objetivos de Cumplimiento
Alto Se confía mucho en los UDA y las sanciones son materiales por incumplimiento
Medio Se confía parcialmente en los UDA y las sanciones son moderadas por incumplimiento
Bajo No se confía en los UDA críticos y las sanciones son bajas
Sin impacto No se confía en UDA
8
GTAG: alcance de una auditoría de aplicaciones desarrollada por el usuario
3.4. Clasificación de riesgo
El siguiente paso en la preparación de la evaluación de riesgos implica la revisión y clasificación de riesgos por impacto y probabilidad de cada UDA 
utilizando el inventario y los criterios de riesgo establecidos en la sección anterior. Con base en la evaluación de estos criterios, la calificación de riesgo 
general para cada UDA puede determinarse utilizando las siguientes escalas de impacto y probabilidad.
Impacto
Clasificación Escala de impacto*
Existe la posibilidad de que un error en la UDA resulte en un impacto material en los informes financieros de la organización, la 
capacidad de toma de decisiones de la gerencia y/o la capacidad de cumplir con las normas pertinentes.
los requisitos reglamentarios.
Alto 3
Medio 2 El impacto potencial puede ser significativo para la unidad de negocios pero moderado para la organización en general.
Bajo 1 El impacto potencial para la organización es menor en tamaño y de alcance limitado.
* Basado en los criterios de riesgo identificados
La evaluación de los criterios de probabilidad determina la calificación de riesgo general para cada UDA.
Probabilidad
Clasificación Escala de probabilidad*
Alto 3 Alta probabilidad de que ocurra el riesgo
Medio 2 Probabilidad media de que el riesgo ocurra
Bajo 1 Baja probabilidad de que ocurra el riesgo
* Basado en los criterios de riesgo de probabilidad
Luego se desarrolla la calificación de riesgo general para el UDA en función del impacto y la probabilidad de que pueda ocurrir un error de alto impacto. 
Una puntuación compuesta que se puede utilizar es la escala de impacto multiplicada por la escala de probabilidad. Las siguientes son algunas pautas de 
muestra recomendadas:
Puntuaciones compuestas
Puntuacion compuesta Acción sugerida
7-9 Incluir en la muestra de auditoría anualmente
4-6 Incluir en la muestra de auditoría cada dos años
1-3 No incluir en la muestra de auditoría
9
GTAG: alcance de una auditoría de aplicaciones desarrollada por el usuario
El siguiente ejemplo muestra los resultados de una evaluación de riesgos utilizando los factores de riesgo mínimos descritos en la sección anterior. Esta 
plantilla se modificaría dependiendo de los factores de riesgo relevantes para la organización bajo revisión.
Consideraciones de impacto Consideraciones de probabilidad
Division de la empresa
1.0 Proceso de negocio
norte Y Y H 3 H 3 H 3 3 H 3 O 2 3 8 Y
norte Y Y H 3 L 1 H 3 2 H 3 O 2 3 6 Y
norte Y norte METRO 2 METRO 2 METRO 2 2 METRO 2 F 3 3 5 Y
norte Y norte METRO 2 L 1 METRO 2 2 METRO 2 I 1 2 3 norte
norte Y Y L 1 H 3 L 1 2 L 1 F 3 2 3 norte
norte Y Y L 1 METRO 2 L 1 1 L 1 F 3 2 3 norte
Proceso de negocio 2.0
10
1.
1 
fa
ct
ur
ac
ió
n
Pr
oc
es
o
Ac
ce
so
Co
ns
ul
ta
Ac
ce
so
Co
ns
ul
ta
So
br
es
al
ir
So
br
es
al
ir
So
br
es
al
ir
So
br
es
al
ir
D
es
cr
ip
ci
ón
O
bj
et
iv
o
YY
Y4
.x
ls
YY
Y3
.x
ls
YY
Y2
.x
ls
AA
AA
.x
ls
XX
X2
.m
db
XX
X.
m
db
N
om
br
e 
de
l a
rc
hi
vo
Ex
is
te
 c
om
o 
U
D
A 
de
 2
00
9 
(S
/N
)
Ex
is
te
 c
om
o 
U
D
A 
20
10
 (S
/N
)
Cu
m
pl
e 
co
n 
la
 d
ef
in
ic
ió
n 
de
 o
rg
an
iz
ac
ió
n 
de
 U
D
A 
cl
av
e
Fi
na
nc
ie
ro
, O
pe
ra
ci
on
al
 y
 R
eg
ul
at
or
io
Cu
m
pl
im
ie
nt
o 
M
at
er
ia
lid
ad
 (H
, M
, L
)
Cl
as
ifi
ca
ci
ón
 (1
, 2
, 3
)
Vi
da
 e
sp
er
ad
a 
y 
fr
ec
ue
nc
ia
 d
e 
us
o
(H
, M
, L
)
Cl
as
ifi
ca
ci
ón
 (1
, 2
, 3
)
N
úm
er
o 
de
 u
su
ar
io
s 
(H
, M
, L
)
Cl
as
ifi
ca
ci
ón
 (1
, 2
, 3
)
Im
pa
ct
o 
m
ed
io
Co
m
pl
ej
id
ad
 (H
, M
, L
)
Cl
as
ifi
ca
ci
ón
 (1
, 2
, 3
)
Ca
m
bi
ar
 la
 fr
ec
ue
nc
ia
(p
oc
o 
fr
ec
ue
nt
e 
= 
I, 
oc
as
io
na
l =
 O
, f
re
cu
en
te
 =
 F
)
Cl
as
ifi
ca
ci
ón
 (1
, 2
, 3
)
Pr
ob
ab
ili
da
d 
pr
om
ed
io
Cl
as
ifi
ca
ci
ón
 c
om
pu
es
ta
Se
r i
nc
lu
id
o 
en
 la
 p
ob
la
ci
ón
GTAG: alcance de una auditoría de aplicaciones desarrollada por el usuario
Otro enfoque a considerar evalúa el riesgo a un nivel mucho más alto. Al igual que con el enfoque anterior, la población de UDA se identifica 
mediante procesos comerciales. Este enfoque identifica el riesgo, los controles de mitigación y el riesgo residual con inclusión o exclusión 
recomendada de la población.
UDA
Contar
Riesgo inherente
Impacto/Prob.
Controles de mitigación otros
que UDACategoría UDA Riesgo Riesgo residual
Incompleto o inac-
integración curada
del sistema fuente
al libro mayor
resultando en financiera
declaración errónea.
Libro mayor auxiliar a general
conciliación y revisión del libro 
mayor y conciliación y análisis 
de ingresos. Buenos controles 
de cambio.
Interfaces:
• Ingresos/Facturación/AR
• Adiciones en masa
• Recibos de efectivo
Alto:
Sustancial
Cambios
93 Bajo: Excluir
Ingresos a corto plazo
Devengos y aplazamientos:
• Mes por adelantado
• Uso
Moderado:
Trimestral y
Actividad Anual
Alto
Revise el análisis de ingresos y 
ajuste las facturas reales a lo largo 
del tiempo. Ocurren revisiones de 
devengo material.
Clasificación errónea de
ingresos entre
períodos.
9 Bajo: Excluir
Incompleto o inac-
curar datos, defectuoso
suposiciones, o
errores lógicos resultantes
en sin soporte
reserva y diferido
saldos de ingresos
y mal expresado
ganancia.
Alto:
Sustancial
Deuda incobrable
Actividad; Manual
Cálculos
Ingresos a largo plazo
Aplazamientos y Reservas:
• Reserva general
• Reserva para deudas incobrables
Conciliación de cuentas, asientos 
de diario y revisiones de 
adecuación de reservas.
18 Alto: Incluir
Sobreestimado o subestimado
acumulaciones debido a
incompleto o inac-
curar datos.
Análisis de gastos y
revisión, balance
revisar y ajustar las facturas 
pagadas.
Moderado:
Actividad menor
Acumulaciones de gastos 28 Bajo: Excluir
Incompleto o inac-
curar datos, defectuoso
suposiciones, o
errores lógicos resultantes
en sin soporte
saldos y
gastos inexactos.
Alto:
Sustancial
Capital
gastos
e impuestos
Pasivo
Reconciliación de la cuenta
revisión, entrada de diario
revisión y contabilidad
y revisión de informes de problemas 
de informes. Existencia de análisis de 
contingencias tributarias fuertes.
Relacionado con los gastos:
• Gastos de capital
• Impuestos y Contingencias
• Compensación no monetaria
27 Bajo: Excluir
Análisis de ingresos y
revisión utilizando datos del libro 
mayor en informes de 
rendimiento provisionales y otros 
informes. Detección y corrección 
de erroresen procesos de 
disputas y cobranzas.
Moderado:
automatizado,
dólar bajo,
Alta transacción
Volúmenes
No detectar
errores de ingresos
por incom-
datos completos, consultas,
e informes
Aseguramiento de Ingresos 5 Bajo: Excluir
Revisión y amarre de estados 
financieros. Revisiones 
adicionales por senior
gestión, divulgación
comité y auditoria
comité.
Informes financieros:
• Desempeño Interino
• Finanzas detalladas
• Estado de Flujo de Caja
• Notas al pie/Otros
Alto:
Crítico
Toma de decisiones
y regulatorio
Procesos
Financiamiento inexacto
informes sociales y
divulgación.
14 Alto: Incluir
Con los UDA identificados y clasificados por riesgo, es necesario definir el alcance de la auditoría interna. El auditor interno considerará la 
naturaleza y el momento de la revisión, así como la extensión del tiempo y los recursos que se gastarán en la revisión al tomar la 
determinación final del alcance.
11
GTAG: consideraciones al realizar auditorías de 
aplicaciones desarrolladas por el usuario
4. Consideraciones en
Realización de auditorías de aplicaciones 
desarrolladas por el usuario
• Pruebas UDA.Con base en la comprensión del proceso, los 
riesgos, los controles y las funciones que se esperan de la 
UDA, el auditor interno debe probar la funcionalidad de la 
UDA desde la perspectiva del usuario final.
(Nota:Los detalles se exploran más a fondo en la sección 4.2.)
• Pruebas de controles generales de TI.Al igual que las pruebas de 
aplicaciones desarrolladas formalmente, las pruebas de UDA 
requieren una revisión detallada del acceso al sistema, los 
controles de desarrollo del sistema empleados, la gestión de 
cambios, la seguridad de la red y las copias de seguridad. Se 
debe prestar especial atención a los UDA almacenados en discos 
duros individuales en lugar de en la red. Las consideraciones de 
prueba específicas se discuten en detalle en la sección 4.2.
• Herramientas automatizadas.Los enfoques típicos para el 
descubrimiento de UDA, la evaluación de riesgos, el alcance de la 
auditoría interna y las pruebas pueden ser arduos e incompletos si se 
abordan manualmente, especialmente en organizaciones más 
grandes y complejas con cientos, si no miles, de UDA. Los auditores 
internos pueden aprovechar las herramientas automatizadas para 
garantizar que todos los componentes de una revisión de UDA se 
puedan ejecutar de manera oportuna y que el programa se pueda 
sostener a lo largo del tiempo. Consulte la sección 4.1 para obtener 
más información sobre los atributos y capacidades de la herramienta.
• Implicaciones de debilidades y excepciones de prueba. Las 
debilidades y las excepciones de prueba deben evaluarse en el 
contexto del entorno, las clasificaciones de riesgo y los controles 
manuales y del sistema relacionados.
• Tener en cuenta las pautas de mejores prácticas de la UDA al 
desarrollar el programa de auditoría interna.Estas pautas 
están diseñadas para ilustrar las mejores prácticas de la 
industria para el desarrollo, mantenimiento y uso de 
sistemas de usuario final. Si bien no se requieren todas estas 
pautas, la adopción e implementación de estos principios 
facilita la implementación del control y conduce a una mejor 
calidad y consistencia de UDA. La Sección 4.2 describe las 
mejores prácticas en los controles sobre el desarrollo y uso 
de UDA y ayudará al auditor interno a determinar los 
controles necesarios que se revisarán durante la auditoría 
interna.
Con la proliferación y el uso de UDA, es fundamental que las 
organizaciones mantengan políticas y procedimientos claramente 
definidos para definir, evaluar riesgos y monitorear UDA. El auditor 
interno debe comenzar el proceso de auditoría revisando el marco 
de control de UDA existente y los resultados relacionados. Luego, él 
o ella debe obtener una comprensión del proceso de flujo de UDA 
mientras considera la madurez de los controles para impulsar la 
amplitud de la auditoría interna. En el apéndice se incluye un ejemplo 
de un proceso de flujo.
Si la organización tiene fuertes controles de gestión de cambios, 
versiones y monitoreo en torno a los UDA, el auditor interno puede 
centrarse principalmente en probar esos controles con una 
repetición limitada de la funcionalidad de los UDA. Si la organización 
tiene controles menos maduros, el auditor interno puede confiar 
más en volver a ejecutar la funcionalidad de UDA.
Los auditores internos deben considerar lo siguiente al 
realizar una auditoría interna de UDA:
• Evaluar todas las políticas relevantes de la empresa.
Evaluar las políticas en torno al desarrollo y uso de UDA, 
así como las políticas de clasificación y propiedad de 
datos y cómo pueden o no verse afectadas por el uso de 
UDA bajo revisión.
• Evaluar las preocupaciones de la gerencia y los resultados de 
revisiones anteriores.Ya sea que la auditoría interna sea el resultado 
de la sincronización del ciclo o una solicitud de la gerencia debido a la 
incertidumbre de los controles, los auditores internos deben 
comprender los resultados de las revisiones anteriores. También es 
recomendable entrevistar a los gerentes, según corresponda, para 
aprender más sobre el medio ambiente y preguntar sobre problemas 
conocidos y áreas de preocupación.
• Evaluar y hacer recomendaciones para la automatización de 
UDA.Un valor agregado del proceso de inventario de UDA puede 
ser la identificación de dónde se pueden automatizar estas hojas 
de cálculo y bases de datos o convertirlas en una mejora del 
sistema que esté sujeta a controles formales de TI.
• Identificar roles y responsabilidades al principio del proceso. Los 
roles y responsabilidades estándar dentro de la organización 
incluyen:
4.1. Atributos y capacidades de la herramienta
Como se describe en este GTAG, un marco de control de UDA 
implementado por la organización y posteriormente revisado 
por la actividad de auditoría interna se basa en la calidad del 
siguiente proceso:
o Los clientes son los contactos clave para identificar las 
políticas, los usuarios, los pasos del proceso y los controles 
aplicables de la empresa, y son responsables de revisar y 
validar los resultados.
Los usuarios/propietarios de procesos a menudo informan al 
cliente; estas personas utilizan los UDA y completan las tareas en 
el proceso relacionado con el UDA que se está revisando.
oLos auditores internos se reúnen con los usuarios y el proceso
propietarios y revisar los UDA, incluidas las entradas, las 
salidas y la funcionalidad.
o Descubrimiento Inventario Clasificación de riesgo
Un inventario de UDA es imperativo antes de la clasificación de riesgos y 
el control adecuado. Esto requiere un proceso de descubrimiento que 
garantice que el inventario sea completo y preciso. Tecnología
12
GTAG — Consideraciones en la realización de User-
auditorías de aplicaciones desarrolladas
puede mejorar la capacidad de la organización para crear el 
inventario de una manera sostenible que puede repetirse fácilmente 
a medida que se desarrollan nuevos UDA. En un entorno empresarial 
más complejo, puede haber cientos, si no miles, de UDA que cambian 
a diario. Los procesos de inventario manual pueden requerir mucho 
tiempo, y en algunos casos pueden tardar hasta dos o tres meses en 
completarse. Durante ese tiempo, es probable que se hayan 
agregado y eliminado UDA adicionales, lo que hace que el esfuerzo 
sea aún más desafiante.
El uso de la tecnología ayudará en los esfuerzos para obtener un inventario 
que sea completo, preciso y relevante para el usuario previsto. Debido a que 
normalmente no hay tiempo para realizar el esfuerzo de realizar un proceso de 
descubrimiento manual, las herramientas automatizadas no solo tienen la 
capacidad de ayudar a las organizaciones en el descubrimiento de UDA, sino 
que también pueden realizar una clasificación de riesgos basada en la 
materialidad y la complejidad predefinidas. Además, la automatización permite 
la implementación de un programa de monitoreo continuo en apoyo del marco 
de controlde UDA de la organización. Un beneficio adicional de este enfoque es 
que el auditor interno puede enfocarse de manera más efectiva en los 
verdaderos riesgos presentados a través del uso de UDA por parte de la 
organización.
Las mejores herramientas de su clase no solo ayudan en el descubrimiento, el 
inventario y la clasificación de riesgos de los UDA, sino que también brindan las 
siguientes capacidades:
• Realizar diagnósticos para identificar errores mecánicos o 
lógicos de UDA, incluidos errores de omisión, e informar 
sobre esos errores con fines de reparación.
• Proporcionar capacidad de gestión de UDA continua para garantizar 
la integridad desde la creación hasta el almacenamiento y la 
destrucción.
• Proporcionar un flujo de trabajo con capacidad de firma 
electrónica.
• Mejorar la capacidad de administrar hojas de cálculo vinculadas.
• Proporcionar capacidad de gestión de documentación para 
entradas, cálculos y salidas clave de UDA.
• Proporcionar un proceso estructurado para la gestión de cambios 
de UDA, la integridad de los datos y los controles de versión y 
acceso.
• Proporcione visibilidad para el monitoreo continuo para 
respaldar el mantenimiento del entorno de control.
mayor necesidad de formalizar cómo se aplican los cambios. Si bien 
no se requieren todas estas pautas, la adopción e implementación de 
estos principios facilita la implementación del control y conduce a 
una mejor calidad y consistencia de los UDA.
Directrices de acceso
• Limite el acceso a hojas de cálculo y otros sistemas de usuarios 
finales almacenados en un servidor de red según sea 
necesario según las responsabilidades del trabajo.
Directrices de datos de origen
• El área de ingreso de datos generalmente no debe contener 
fórmulas. “Cuando cada celda contiene datos clave y los 
complicados algoritmos cargados de suposiciones que se 
aplicarán, confirmar que los resultados son apropiados o 
razonables puede ser prácticamente imposible, incluso si se 
calcula correctamente. Es una mejor práctica separar los 
datos de los algoritmos y suposiciones que se aplican a los 
datos”.9
• Cuando sea posible, ingreso de datos: manual o interconectado
— debe estar en el mismo orden que los datos fuente para 
facilitar la revisión y minimizar los errores de entrada.
• Fórmulas de bloqueo.
Directrices de salida de origen
• No use la misma hoja de trabajo y solo cambie los supuestos y 
las variables sin dejar una línea de base o un rastro de lo que 
se ha cambiado durante el análisis de "qué pasaría si". “La 
mejor manera de comparar y revisar los resultados de 
diferentes combinaciones de variables es (a) copiar los 
conjuntos de datos y cálculos originales en una pestaña de 
hoja de cálculo separada, y (b) crear una pestaña de hoja de 
cálculo de comparación, que presenta y contrasta el original. 
”10
• Considere cómo debe ser el formato final de la presentación. Evite 
la necesidad de volver a escribir manualmente la salida en otros 
formatos y herramientas, lo que provoca errores.11
• Identificar los usuarios autorizados para cada informe que se genera, así 
como las pautas de retención y almacenamiento de datos.
Pautas de prueba
• Asegúrese de que los cambios en los UDA críticos o altamente 
complejos se soliciten, documenten y prueben formalmente.
• Solicite a alguien que no sea el usuario o desarrollador de 
la hoja de cálculo que pruebe cálculos y lógica complejos 
o críticos.
• Utilizar revisiones de análisis y razonabilidad para detectar 
errores en los cálculos y la lógica.
La referencia a la tecnología dentro de esta sección puede ser tan 
simple como ejecutar un script para capturar todos los archivos 
ubicados en la red que contienen, por ejemplo, extensiones de 
archivo .xls o .mdb. En el otro extremo del espectro, existen paquetes 
de software listos para usar que pueden realizar todas las 
capacidades que se analizan en esta sección.
4.2. Mejores prácticas para controles sobre 
aplicaciones desarrolladas por usuarios
Estas pautas ilustran las mejores prácticas para el desarrollo, 
mantenimiento y uso de UDA. A medida que aumenta la complejidad 
y la criticidad de cualquier UDA dado, se convierte en un 9, 10, 11"Hoja de cálculo 'Peores prácticas'", CFO.com
13
GTAG: consideraciones al realizar auditorías de 
aplicaciones desarrolladas por el usuario
5. Desarrollo del Programa de Auditoría
Directrices lógicas
• Coloque los valores críticos en una celda separada y haga 
referencia a esta celda en la fórmula en lugar de incorporar 
el número en una fórmula en una o más celdas.
• Incorporar totales de lote y totales de control.
• Usar fórmulas que midan y crucen los datos.
• Garantice la integridad de los datos bloqueando o protegiendo las celdas 
para evitar cambios accidentales o intencionales en datos o fórmulas 
estáticos.
• Incluya los resultados esperados donde sea posible para comparar y 
monitorear la razonabilidad de la salida de UDA.
La Sección 5.1 describe un programa de auditoría de UDA de muestra. La 
intención general al proporcionar el programa de auditoría es 
proporcionar algo que podría usarse para un entorno más complejo.
Directrices de versión, copia de seguridad y archivado
• Use convenciones únicas de nomenclatura de carpetas y archivos 
que incluyan el mes, el trimestre y el año para ayudar a 
garantizar que solo se usen las versiones actuales y aprobadas 
de los UDA. Considere el uso de software de registro y salida 
para administrar el control de versiones.
• Garantice la copia de seguridad de los datos almacenando hojas de cálculo y otros UDA 
en un servidor de red del que se realiza una copia de seguridad diariamente.
• Almacene archivos históricos y bases de datos que no estén en uso 
en una carpeta segregada de solo lectura para evitar usarlos por 
error.
Pautas de documentación
• Documente el propósito y el uso de cada UDA crítico y 
actualícelo en consecuencia. La documentación debe incluir 
el objetivo comercial, las entradas, las salidas y la secuencia 
de ejecución de los procesos de varios pasos.
• Cree un diseño consistente para hojas de cálculo y otros UDA 
para simplificar el uso y las pruebas. Las áreas para la 
entrada de datos, cálculos y salida deben ser distintas y 
separadas.
• Etiquete archivos, conjuntos de datos, hojas de trabajo, campos clave, 
filas, columnas y datos para una fácil identificación.
• Inventario de todas las hojas de cálculo clave y otros UDA que 
afectan la preparación de los estados financieros.
• Documentar claramente las suposiciones aplicadas y 
aprovechadas para generar datos o realizar cálculos.
El libro blanco de Microsoft sobre el cumplimiento de las hojas de cálculo 
enfatiza la importancia de desarrollar una metodología de mantenimiento 
y desarrollo de hojas de cálculo a largo plazo, así como también cómo 
Microsoft Office 2007 puede ayudar a abordar los desafíos de 
cumplimiento.12
12Documento técnico "Cumplimiento de las hojas de cálculo en Microsoft Office 
System 2007"
14
GTAG: desarrollo del programa de auditoría
mento; por lo tanto, dado que el impacto comercial y/o la complejidad se consideran menores, las omisiones de los pasos del programa pueden ser 
apropiadas al considerar el apetito de riesgo de una organización.
5.1. Ejemplo de programa de auditoría
Herramienta de evaluación de aplicaciones desarrolladas por el usuario (UDA)
Área de Auditoría:
Número de auditoría:
Auditoría:
Descripción:
Descripción general de UDA y evaluación de riesgos 
Preparado por:
Revisado por:
Fecha:
Fecha:
Objetivo:
El propósito de este documento de trabajo es identificar UDA críticos que estarán dentro del alcance, así como considerar ciertos controles de 
aplicación estándar para revisar.
Pruebas:
1. Se realizó una evaluación de las solicitudes para determinar qué solicitudes se considerarían para su inclusión en la auditoría. Solicitó 
que la gerencia proporcione una lista clasificada por riesgo de los UDA departamentales, incluido el uso previsto de cada uno y lospropietarios de la aplicación.
2. Según nuestra evaluación (como se indica en el número 1), hubo X UDA críticos. Seleccionamos las aplicaciones con una puntuación 
superior a X.0, lo que resultó en X aplicaciones posibles para considerar en nuestro alcance. Nuestros comentarios y disposición 
relacionados con estas aplicaciones se incluyen en la evaluación de riesgos.
3. Para cada UDA identificado para su inclusión dentro del alcance de la auditoría del año en curso, la auditoría interna realizó 
descripciones, recorridos u otros procedimientos para determinar qué controles de aplicación estándar se deben probar (por 
ejemplo, acceso e interfaces). Se documentan los controles de aplicación identificados para pruebas y/o evaluación adicional.
15
GTAG: desarrollo del programa de auditoría
A. Seguridad y acceso al sistema
Preparado por:
Revisado por:
Fecha:
Fecha:
Solicitudes en revisión ===> Solicitud (n) Solicitud (n + 1)
Elementos a tener en cuenta al evaluar la seguridad y el acceso al sistema
1. Identifique los UDA dentro del alcance y los datos relacionados y determine los nombres de 
archivos, directorios, conjuntos de datos y/o bases de datos donde residen los UDA y los datos. 
Considerar:
• Archivos fuente y ejecutables de UDA.
• Archivos de datos relacionados tanto con la entrada como con la salida.
• Registros de seguimiento de auditoría.
• PII contenida en los datos.
2. Obtenga los derechos de acceso a los UDA dentro del alcance y los datos relacionados y 
evalúe la idoneidad de dicho acceso. Considerar:
• Administradores del sistema.
• Administradores de seguridad.
• Cuentas de usuario compartidas/predeterminadas.
• Ver acceso a PII.
3. Verifique que los controles de autenticación de usuarios en los sistemas que contienen los 
UDA y los datos restrinjan adecuadamente el acceso no autorizado. Considerar:
• Configuración de parámetros de contraseña (p. ej., longitud, complejidad, historial, período de 
caducidad).
• Bloqueo de cuenta después de un número determinado de intentos fallidos.
• Sesión terminada después de un período de inactividad.
• Autenticación de dos factores utilizada durante el acceso remoto.
4. Determine si hay otras formas de acceder al UDA oa los datos y 
evalúe los controles sobre el acceso.
5. Verificar si el acceso se revisa periódicamente. Considerar:
• Revisiones anuales.
• Revisiones y aprobaciones documentadas.
• Acciones correctivas tomadas en forma oportuna.
dieciséis
GTAG: desarrollo del programa de auditoría
B. Pistas de auditoría
Preparado por:
Revisado por:
Fecha:
Fecha:
Solicitudes en revisión ===> Solicitud (n) Solicitud (n + 1)
Elementos a tener en cuenta al evaluar los registros de auditoría
1. Identifique si existen pistas de auditoría y dónde residen.
2. Determinar la idoneidad de la pista de auditoría. Considerar:
• Las pistas de auditoría son generadas automáticamente por la aplicación.
• Los registros de auditoría no se pueden desactivar.
• La información capturada por la pista de auditoría es apropiada.
3. Verifique que los usuarios con la capacidad de cambiar o eliminar registros y programas de 
seguimiento de auditoría no sean los usuarios de la UDA y/o los datos.
4. Verifique que los registros de auditoría se revisen periódicamente y se conserven durante un 
período de tiempo apropiado.
C. Entradas, ediciones e interfaces
Preparado por:
Revisado por:
Fecha:
Fecha:
Solicitudes en revisión ===> Solicitud (n) Solicitud (n + 1)
elementos a considerar al evaluar entradas, ediciones e interfaces
1. Identificar la fuente y el tipo de datos de entrada.
2. Verifique que los controles sobre las entradas de archivos críticos sean apropiados. Considerar:
• Reglas de validación de datos.
• Las ediciones son coherentes independientemente de la fuente.
• Los recuentos y saldos de registros/artículos garantizan la integridad.
3. Verificar si se producen notificaciones o informes de errores y se han tomado 
acciones correctivas. Considerar:
• Los totales de control se concilian para garantizar la integridad.
• Los archivos de entrada erróneos se pueden recuperar y volver a ejecutar.
17
GTAG: desarrollo del programa de auditoría
D. Procesamiento de datos e integridad de datos
Preparado por:
Revisado por:
Fecha:
Fecha:
Solicitudes en revisión ===> Solicitud (n) Solicitud (n + 1)
elementos a considerar al evaluar el procesamiento de datos y la integridad de los datos
1. Determinar si los registros producidos por el sistema se anulan manualmente de forma 
rutinaria para corregir errores de procesamiento. Considerar:
• Corrección de rotura repetitiva por la misma causa.
• Acciones correctivas para corregir defectos en el código de la aplicación.
2. Determinar si se utilizan herramientas de manipulación de datos para corregir errores de 
procesamiento. Considerar:
• Utilidades que pueden sobrescribir registros.
• Sentencias SQL para anular registros de bases de datos en bases de datos relacionales.
• Los recuentos y saldos de registros/artículos garantizan la integridad.
3. Verifique que se mantengan registros de auditoría detallados para anulaciones manuales 
con la solicitud de origen de la empresa. Considerar:
• Los controles de monitoreo manual identifican la entrada no autorizada de anulaciones 
manuales.
• El ID de usuario y la marca de tiempo se capturan para anular transacciones.
• Existen registros de actividad y excepciones.
(Nota:La autorización de anulación debe revisarse durante la seguridad del sistema y la 
evaluación de acceso).
4. Verifique que los errores de procesamiento se describan claramente, se detecten rápidamente y se 
marquen para su corrección. Considerar:
• El procesamiento de registros debe detenerse una vez que se produce un error.
• Datos de informes de excepción disponibles para acciones correctivas.
• Los informes de acciones correctivas se revisan en busca de problemas.
• Elementos compensados de acuerdo con los objetivos de nivel de servicio empresarial.
5. Determinar si existe un proceso para revertir transacciones, corregir errores y volver 
a procesar transacciones con manejo manual especial. Considerar:
• Las reglas y procedimientos comerciales especiales deben ser definidos por la 
organización.
• La aplicación permite un manejo especial.
• Los registros rechazados se vuelven a procesar dentro de un marco de tiempo aceptable.
6. Verifique que existan controles de procesamiento para las hojas de cálculo. Considerar:
• Las fórmulas y los cálculos están respaldados por documentación adecuada que 
respalda la lógica que se utiliza.
• Las fórmulas y las celdas están bloqueadas para evitar cambios.
• Las referencias de celdas o los rangos de nombres se usan en fórmulas en lugar de 
constantes.
• Se utilizan totales de verificación cruzada.
• La función de cálculo automático está activada en la hoja de cálculo.
• Los cómputos incorporados son compatibles con la documentación adecuada 
que describe la lógica y la mecánica de cómputo.
18
GTAG: desarrollo del programa de auditoría
E. Informes y resultados
Preparado por:
Revisado por:
Fecha:
Fecha:
Solicitudes en revisión ===> Solicitud (n) Solicitud (n + 1)
elementos a considerar al evaluar informes y resultados
1. Verifique que los totales de control de salida se comparen con los totales de control de entrada y que 
se resuelvan los errores.
2. Verifique que la lógica de la aplicación UDA y las fórmulas críticas se validen 
periódicamente.
3. Determinar si existen controles comerciales mitigadores para detectar errores de 
salida (por ejemplo, conciliaciones posteriores y/o procesamiento de control).
F. Retención
Preparado por:
Revisado por:
Fecha:
Fecha:
Solicitudes en revisión ===> Solicitud (n) Solicitud (n + 1)
elementos a considerar al evaluar la retención
1. Verifique que los datos se retengan adecuadamente. Considerar:
• Tipo de datos y programas.
• Retenido por una cantidad de tiempo suficiente.
• Conservado en un lugar seguro.
• Documentos físicos.
• Los datos archivados son legibles