1. Universidad Autónoma de Santo Domingo, UASD
Centro Nagua
Maestría en Auditoria y Seguridad Informática
CURSO
 Taller de Aplicaciones Electrónicas y Bases de Datos
FACILITADOR
 Miguel Antonio Díaz, Ingeniero en Sistemas, MBA, Dr.C.
PREPARADO POR
 Lic. Alex Rafael Polanco Bobadilla
 Licda. Alcelis E. Ozoria Gelabert
31 de Mayo de 2012
Nagua, PMTS 33000, República Dominicana

2. Contenido
Guía y Programa de Auditoria de Desarrollo de Sistemas y Gestión de Proyectos ................................. 12
INTRODUCCIÓN ................................................................................................................................... 12
Impacto en el negocio y el riesgo ......................................................................................................... 14
Objetivos y alcance .............................................................................................................................. 15
IMPORTANCIA DE LA AUDITORÍA AL CVDS ............................................................................ 16
¿Cuál es la realidad de los proyectos TI? ............................................................................................. 16
¿Por qué los Proyectos fallan?.............................................................................................................. 16
Etapas del Ciclo de Vida del Desarrollo de Sistemas........................................................................... 18
El Programa .............................................................................................................................................. 18
Marco de Control ................................................................................................................................. 18
El Gobierno de TI Riesgo y Control .................................................................................................... 19
Responsabilidades de Auditoría de TI y los Profesionales de Aseguramiento .................................... 19
Uso de este documento ......................................................................................................................... 19
Pasos del Programa .............................................................................................................................. 19
Componentes COSO ............................................................................................................................ 21
Análisis de Madurez de los controles ....................................................................................................... 23
Marco De Aseguramiento Y Control ....................................................................................................... 25
Marco de Aseguramiento y Normas de TI de ISACA ......................................................................... 25
Marco de Controles de ISACA ............................................................................................................ 25
Habilidades Mínimas de auditoría ........................................................................................................ 27
Programa de Auditoria de Desarrollo de Sistemas y Gestión de Proyectos ............................................. 28
1 . Planificación y alcance de la auditoría ................................................................................................ 28
Ideas / Descripción de subprocesos ...................................................................................................... 28
1.1 Definir los objetivos de la auditoria. .............................................................................................. 28
1.1.1 Revisar los objetivos de la auditoria para iniciar el programa de auditoria. ............................ 28

3. 1.1.2 Modificar los objetivos de la auditoria para alinearlo con la auditoria general, el plan anual de
auditoria o la carta de la gerencia. .................................................................................................... 28
1.2 Definir los límites de la revisión. ................................................................................................... 28
1.2.1 Realizar un recorrido de alto nivel del proyecto que será revisado. ........................................ 28
1.2.2 Establecer los límites iniciales de la revision de la auditoria. ................................................. 28
1.2.3 Revisar todas las fases y pasos dentro de este programa de auditoria. .................................... 28
1.3 Definir la seguridad. ....................................................................................................................... 28
1.3.1 Obtención de las normas de desarrollo de los sistemas de la empresa, el manual de la
metodología del desarrollo de los sistemas, las normas de gestión de proyectos y el manual de
metodología del proyecto. ................................................................................................................ 29
1.3.2 Determinar si se usará COBIT y un marco de desarrollo de sistemas apropiado como buenas
prácticas de referencia. ..................................................................................................................... 29
1.4 Identificar los riesgos y los documentos. ....................................................................................... 29
1.4.1 Para los proyectos identificados como foco potencial: ........................................................... 29
1.4.2 Con base en la evaluación de riesgos, identificar los cambios en el ámbito de aplicación. .... 29
1.4.3 Discutir los riesgos de TI, de negocios y de gestión de auditoria operacional, y ajustarlo a la
evaluación de riesgos........................................................................................................................ 29
1.4.4 Con base en la evaluación de riesgos, revisar el alcance......................................................... 29
1.5 Definir el proceso de cambio.......................................................................................................... 29
1.5.1 Identificar el senior de IT responsable de la revisión de los recursos. .................................... 29
1.5.2 Establecer el proceso para sugerir e implementar cambios en el programa de auditoría y las
autorizaciones requeridas. ................................................................................................................ 29
1.6 Definir el exito de la asignación. .................................................................................................... 29
1.6.1 Identificar los controladores para una revisión exitosa (Esto debe existir en las normas de la
función de garantía y los procedimientos)........................................................................................ 29
1.6.2 Comunicar el éxito atribuye al propietario del proceso o los interesados clave y obtener un
acuerdo. ............................................................................................................................................ 29
1.7 Definir los recursos de auditoría requeridos. .................................................................................. 30
1.7.1 Determinar las habilidades de auditoría necesarios para su revisión. ..................................... 30
1.7.2 Determinar el total de recursos estimados (horas) y los plazos (fechas de inicio y final)
requieridos para la revisión. ............................................................................................................. 30
1.8 Definir los entregables.................................................................................................................... 30
1.8.1 Determinar las prestaciones provisionales, incluidas las conclusiones iniciales, informes de
situación, informes de proyectos, fechas de vencimiento para las respuestas y el informe final. .... 30

4. Comunicaciones ................................................................................................................................... 30
1.9 El proceso de auditoría se comunica con claridad al cliente. ................................................ 30
1.9.1 Llevar a cabo una conferencia de apertura para discutir los objetivos de la revisión con el
ejecutivo responsable de los sistemas operativos y de infraestructura. ............................................ 30
2 . ENTENDIMIENTO DE APOYO DE INFRAESTRUCTURA .......................................................... 30
2.1 El proceso de desarrollo de sistemas y gestión de proyectos son compatibles con las normas de la
entidad, los procesos y procedimientos. Para evaluar correctamente el proceso, la infraestructura de
apoyo debe ser revisado y evaluado. .................................................................................................... 30
2.1.1 Revisar la documentación de gestión de proyectos y establecer una comprensión del proceso
y sus controles. ................................................................................................................................. 30
2.1.2 Revisar la documentación de los sistemas en desarrollo y establecer una comprensión del
proceso y sus controles. .................................................................................................................... 30
3 . FASE DE INICIACIÓN ...................................................................................................................... 30
3.1 Gobierno ......................................................................................................................................... 30
3.1.1 Caso de negocio....................................................................................................................... 30
3.1.2 Gestión del alcance .................................................................................................................. 31
3.1.3 Funciones y responsabilidades ................................................................................................ 31
3.1.4 Aprobaciones ........................................................................................................................... 32
3.1.5 Retorno de la inversión y los indicadores clave de rendimiento ............................................. 32
3.1.6 Gestión de Escalamiento ......................................................................................................... 32
3.1.7 Decisiones de comprar o construir .......................................................................................... 32
3.2 Gestión de proyectos ...................................................................................................................... 33
3.2.1 Integración de la gestión empresarial / información ............................................................... 33
3.2.2 Composición del equipo de proyecto ...................................................................................... 33
3.2.3 Gestion de riesgo y problemas ................................................................................................ 33
3.2.4 Procedimientos de escalamiento.............................................................................................. 34
3.2.5 Gestión de la calidad ............................................................................................................... 34
3.2.6 Uso de la metodología de desarrollo ....................................................................................... 34
3.2.7 Gestión del cambio .................................................................................................................. 34
3.2.8 Planificación y control............................................................................................................. 34
3.2.9 Progreso de control .................................................................................................................. 34
3.2.10 Gestion de gastos y del tiempo .............................................................................................. 34
3.2.11 Comunicaciones .................................................................................................................... 34

5. 3.3 Presupuesto..................................................................................................................................... 35
3.3.1 Estado del presupuesto ............................................................................................................ 35
3.3.2 Contabilidad ............................................................................................................................ 35
3.3.3 Contabilidad en tiempo real..................................................................................................... 35
3.4 Los controles internos .................................................................................................................... 35
3.4.1 Requisitos de control interno ................................................................................................... 35
3.4.2 Control interno de evaluacion de riesgos ................................................................................ 35
3.4.3 Desarollo de las TACC............................................................................................................ 35
3.5 La adecuación de las pruebas ......................................................................................................... 35
3.6 Implantación ................................................................................................................................... 35
3.7 Proveedores externos ...................................................................................................................... 35
3.7.1 Proveedores de Servicios......................................................................................................... 35
4 . FASE DE PLANIFICACIÓN ............................................................................................................. 36
4.1 Gobierno ......................................................................................................................................... 36
4.1.1 Caso de Negocio...................................................................................................................... 36
4.1.2 Ámbito de Gestión................................................................................................................... 37
4.1.3 Funciones y responsabilidades ................................................................................................ 37
4.1.4 Retorno de la inversión y KPIs ................................................................................................ 38
4.1.5 Gestión de escalamiento .......................................................................................................... 38
4.1.6 Análisis funcional compatible con las decisiones de comprar o construir .............................. 38
4.1.7 Control: La decisión de comprar o construir se basa en los requisitos empresariales y
funcionales, con los procedimientos de contratación correspondientes y la autorización del comité
de dirección. ..................................................................................................................................... 38
4.2 Gestion de proyectos ...................................................................................................................... 39
4.2.1 Integración de la gestión empresarial/información ................................................................. 39
4.2.2 Composición del equipo de proyecto ...................................................................................... 40
4.2.3 Gestión de riesgos y problemas ............................................................................................... 40
4.2.4 Procedimientos de escalamiento.............................................................................................. 41
4.2.5 Gestión de la calidad ............................................................................................................... 41
4.2.6 Uso de la metodología de desarrollo ....................................................................................... 42
4.2.7 Gestión del cambio .................................................................................................................. 42

6. 4.2.8 Planificación y control............................................................................................................. 43
4.2.9 Hitos de puntos de decisiones.................................................................................................. 44
4.2.10 El progreso de control ........................................................................................................... 44
4.2.11 Gestión de gastos y del tiempo .............................................................................................. 44
4.2.12 Comunicaciones .................................................................................................................... 45
4.3 Presupuesto..................................................................................................................................... 45
4.3.1 Estado del presupuesto ............................................................................................................ 45
4.3.2 Contabilidad ............................................................................................................................ 45
4.4 Los controles internos .................................................................................................................... 46
4.4.1 Requisitos de control interno ................................................................................................... 46
4.4.2 Control interno de evaluacion de riesgos ................................................................................ 46
4.4.3 Desarollo de las TACC............................................................................................................ 46
4.5 La adecuación de las pruebas ......................................................................................................... 47
4.5.1 Requisitos de prueba ............................................................................................................... 47
4.5.2 Plan del proyecto ..................................................................................................................... 47
4.5.3 Pruebas de contenido ............................................................................................................... 47
4.6 Implantación ................................................................................................................................... 48
4.6.1 Plan piloto de pruebas ............................................................................................................. 48
4.6.2 Preparación de la evaluación ................................................................................................... 48
4.6.3 Planificación de recursos ......................................................................................................... 48
4.6.4 Conversión de plan .................................................................................................................. 49
4.6.5 Plan de comunicación .............................................................................................................. 49
4.6.6 Formación de planificación ..................................................................................................... 49
4.6.7 Plan de transición .................................................................................................................... 49
4.6.8 Plan de restitución ................................................................................................................... 50
4.7 Proveedores externos ...................................................................................................................... 50
4.7.1 Selección de proveedores ........................................................................................................ 50
4.7.2 SLA y el cumplimiento del contrato ....................................................................................... 50
4.7.3 La propiedad intelectual .......................................................................................................... 51
5 . FASE DE EJECUCIÓN ...................................................................................................................... 51
5.1 Gobierno ......................................................................................................................................... 52

7. 5.1.1 Caso de negocio....................................................................................................................... 52
5.1.2 Ámbito de aplicación de gestión ............................................................................................. 52
5.1.3 Funciones y responsabilidades ................................................................................................ 53
5.1.4 Retorno de la inversión y KPIs ................................................................................................ 53
5.1.5 Escalada de gestión ................................................................................................................. 53
5.2 Gestión de proyectos ...................................................................................................................... 53
5.2.1 Integración de la gestión empresarial / información ............................................................... 53
5.2.2 Composición del equipo de proyecto ...................................................................................... 54
5.2.3 Gestión de riesgos y problemas ............................................................................................... 54
5.2.4 Procedimientos de escalamiento.............................................................................................. 55
5.2.5 Gestión de la calidad ............................................................................................................... 55
5.2.6 Uso de la metodología de desarrollo ....................................................................................... 56
5.2.7 Gestión del cambio .................................................................................................................. 58
5.2.8 Planificación y control............................................................................................................. 59
5.2.9 Hitos de puntos de decisiones.................................................................................................. 59
5.2.10 Progreso de control ................................................................................................................ 59
5.2.11 Gastos y gestión del tiempo................................................................................................... 60
5.2.12 Comunicaciones .................................................................................................................... 60
5.3 Presupuesto..................................................................................................................................... 60
5.3.1 Presupuesto de diseño ............................................................................................................. 60
5.3.2 Estado del presupuesto ............................................................................................................ 61
5.3.3 Contabilidad ............................................................................................................................ 61
5.4 Los controles internos .................................................................................................................... 61
5.4.1 Subfase de diseño .................................................................................................................... 61
5.4.2 Subfase de Desarrollo/Prototipo .............................................................................................. 62
5.4.3 Pruebas .................................................................................................................................... 63
5.4.4 Conversión............................................................................................................................... 64
5.5 La adecuación de las pruebas ......................................................................................................... 65
5.5.1 Requisitos de prueba ............................................................................................................... 65
5.5.2 Proyecto de Plan ...................................................................................................................... 65
5.5.3 Pruebas de contenido ............................................................................................................... 65
5.6 Implantación ................................................................................................................................... 66

8. 5.6.1 Plan piloto de pruebas ............................................................................................................. 66
5.6.2 Preparación de la evaluación ................................................................................................... 66
5.6.3 Planificación de recursos ......................................................................................................... 66
5.6.4 Conversión de plan .................................................................................................................. 67
5.6.5 Plan de comunicación .............................................................................................................. 67
5.6.6 Formación de planificación ..................................................................................................... 67
5.6.7 Plan de transición .................................................................................................................... 67
5.6.8 Plan de restitución ................................................................................................................... 68
5.7 Los Proveedores externos ............................................................................................................... 68
5.7.1 Selección de proveedores ........................................................................................................ 68
5.7.2 SLA y el cumplimiento del contrato ....................................................................................... 68
5.7.3 Proveedor de facturación ......................................................................................................... 68
5.7.4 La propiedad intelectual .......................................................................................................... 68
5.7.5 Integración de la proporcionada por el proveedor de software de aplicación en la organización
.......................................................................................................................................................... 69
6 . FASE DE CIERRE .............................................................................................................................. 69
6.1 Gobierno ......................................................................................................................................... 69
6.1.1 caso de negocio ....................................................................................................................... 69
6.1.2 Ámbito de aplicación de gestión ............................................................................................. 69
6.1.3 Funciones y responsabilidades ................................................................................................ 69
6.1.4 Retorno de la inversión y KPIs ................................................................................................ 69
6.1.5 Gestión de escalamiento .......................................................................................................... 69
6.2 Gestión de proyectos ...................................................................................................................... 70
6.2.1 Integración de la gestión empresarial/información ................................................................. 70
6.2.2 Composición del equipo de proyecto ...................................................................................... 70
6.2.3 Gestión de riesgos y problemas ............................................................................................... 70
6.2.4 Procedimientos de escalamiento.............................................................................................. 70
6.2.5 Gestión de la calidad ............................................................................................................... 70
6.2.6 Uso de la metodología de desarrollo ....................................................................................... 70
6.2.7 Gestión del cambio .................................................................................................................. 70
6.2.8 Planificación y control............................................................................................................. 70
6.2.9 Hitos de puntos de decisiones.................................................................................................. 70

9. 6.2.10 Progreso de Control ............................................................................................................... 70
6.2.11 Gestión de gastos y del tiempo .............................................................................................. 70
6.2.12 Comunicaciones .................................................................................................................... 70
6.3 Presupuesto..................................................................................................................................... 71
6.3.1 Estado del presupuesto ............................................................................................................ 71
6.3.2 Contabilidad ............................................................................................................................ 71
6.4 Los controles internos .................................................................................................................... 71
6.4.1 Requisitos de control interno ................................................................................................... 71
6.4.2 Control interno de evaluacion de riesgos ................................................................................ 71
6.4.3 Desarollo de las TAAC ........................................................................................................... 71
6.5 La adecuación de las pruebas ......................................................................................................... 71
6.5.1 Requisitos de prueba ............................................................................................................... 71
6.5.2 Proyecto de plan ...................................................................................................................... 71
6.5.3 Pruebas de contenido ............................................................................................................... 72
6.6 Implantación ................................................................................................................................... 72
6.6.1 Plan piloto de pruebas ............................................................................................................. 72
6.6.2 Preparación de la evaluación ................................................................................................... 72
6.6.3 Planificación de recursos ......................................................................................................... 72
6.6.4 Conversión de plan .................................................................................................................. 72
6.6.5 Plan de comunicación .............................................................................................................. 72
6.6.6 Formación de planificación ..................................................................................................... 72
6.6.7 Plan de transición .................................................................................................................... 72
6.6.8 Plan de restitución ................................................................................................................... 72
6.7 Los Proveedores externos ............................................................................................................... 72
6.7.1 Selección de proveedores ........................................................................................................ 72
6.7.2 SLA y el cumplimiento del contrato ....................................................................................... 72
6.7.3 Proveedor de facturación ......................................................................................................... 72
6.7.4 Propiedad intelectual ............................................................................................................... 72
7 . FASE POST IMPLANTACIÓN ......................................................................................................... 73
7.1 Gobierno ......................................................................................................................................... 73
7.1.1 Caso de negocio....................................................................................................................... 73

10. 7.1.2 Ámbito de aplicación de gestión ............................................................................................. 73
7.1.3 Retorno de la inversión y KPIs ................................................................................................ 73
7.1.4 Gestión de escalamiento .......................................................................................................... 73
7.2 Gestión de proyectos ...................................................................................................................... 73
7.2.1 Integración de la gestión empresarial/información ................................................................. 73
7.2.2 Gestión de riesgos y problemas ............................................................................................... 73
7.2.3 procedimientos de escalamiento .............................................................................................. 73
7.2.4 Gestión de la calidad ............................................................................................................... 73
7.2.5 Uso de la metodología de desarrollo ....................................................................................... 73
7.2.6 Gestión del cambio .................................................................................................................. 73
7.2.7 Planificación y control............................................................................................................. 73
7.2.8 Milestone pasa / no pasa decisiones ........................................................................................ 74
7.2.9 Progreso de control .................................................................................................................. 74
7.2.10 Gestión de gastos y del tiempo .............................................................................................. 74
7.2.11 Comunicaciones .................................................................................................................... 74
7.3 Presupuesto..................................................................................................................................... 74
7.3.1 Estado del presupuesto ............................................................................................................ 74
7.3.2 Contabilidad ............................................................................................................................ 74
7.4 Los controles internos .................................................................................................................... 75
7.4.1 Requisitos de control interno ................................................................................................... 75
7.4.2 Control interno de evaluacion de riesgos ................................................................................ 75
7.4.3 Desarollo de las TAAC ........................................................................................................... 75
7.5 La adecuación de las pruebas ......................................................................................................... 75
7.5.1 Requisitos de prueba ............................................................................................................... 75
7.5.2 Proyecto de plan ...................................................................................................................... 75
7.5.3 Pruebas de contenido ............................................................................................................... 75
7.6 Implantación ................................................................................................................................... 75
7.6.1 Plan piloto de pruebas ............................................................................................................. 75
7.6.2 Preparación de la evaluación ................................................................................................... 75
7.6.3 Planificación de recursos ......................................................................................................... 75
7.6.4 Conversión de plan .................................................................................................................. 75
7.6.5 Plan de comunicación .............................................................................................................. 75

11. 7.6.6 Formación de planificación ..................................................................................................... 76
7.6.7 Plan de transición .................................................................................................................... 76
7.6.8 Plan de restitución ................................................................................................................... 76
7.7 Proveedores externos ...................................................................................................................... 76
7.7.1 Selección de proveedores ........................................................................................................ 76
7.7.2 SLA y el cumplimiento de contratos ....................................................................................... 76
7.7.3 Propiedad intelectual ............................................................................................................... 76
Modelo de Madurez.................................................................................................................................. 77
Evaluación de Madurez vs Meta Madurez ............................................................................................... 92

12. Guía y Programa de Auditoria de Desarrollo de
Sistemas y Gestión de Proyectos
INTRODUCCIÓN
La metodología de desarrollo de sistemas (a veces referido como el ciclo de vida de los sistemas de
desarrollo) se compone de las fases desplegadas en el desarrollo o adquisición de un sistema de
software. La experiencia ha demostrado que el desarrollo de un nuevo sistema no se puede ejecutar en
un vacío. La empresa debe estar implicada como el conductor, propietario y gerente general del
proyecto. El equipo de desarrollo de TI es un miembro de este equipo del proyecto global que es
responsable de ejecutar el desarrollo técnico del plan de negocios.
Por lo tanto, la clave del éxito de cualquier iniciativa de TI es considerar el proyecto como parte de un ámbito
más amplio, que es la implementación de una solución de negocio. Para mantener el proyecto en marcha, es
necesario proporcionar para la gestión de proyectos, un conjunto estructurado de actividades relativas a la
entrega a la empresa con una capacidad definida (es necesario pero no suficiente para lograr un resultado de
negocios requerido) con base en un calendario acordado y el presupuesto. Muchas entidades utilizan la
expresión "programa" para describir una iniciativa empresarial. La definición del programa, un grupo
estructurado de proyectos interdependientes que incluye todo el ámbito de negocio, procesos, personas,
tecnología y actividades de la organización que se requieren (a la vez necesaria y suficiente) para lograr un
resultado de negocios claramente especificado, es un súper conjunto de un proyecto.
Para desarrollo de sistemas se ha utilizado tradicionalmente el enfoque en cascada, un procedimiento
centrado en el ciclo de desarrollo con la aprobación formal en la terminación de cada nivel. Los
procesos incluyen:
 Estudio de viabilidad
 Requisitos de estudio
 Definición de requisitos
 Diseño detallado
 Programación
 Pruebas
 Instalación/acreditación

13.  Revisión de post-implantación
Con la llegada de prototipos, cuarta generación de lenguajes de programación (4GL) herramientas de
desarrollo de aplicaciones y otros enfoques, marcos más dinámicos fueron requeridos. Estos incluyen:
PMBOK, PRINCE2, ágil, RUP y en espiral. Mientras que cada uno utiliza diferentes marcos de las
convenciones de nomenclatura, los procesos clave son comunes a todos:
 Inicio-Preparación de la idea inicial, caso de negocio, el alcance, la creación del equipo de
proyecto, y la preparación y aprobación del presupuesto y las solicitudes de gastos de capital
 Planificación, Preparación del plan detallado, los requisitos de la definición, la adquisición y el
ciclo de adquisición de la ayuda de consultoría externa
 Ejecución-Ejecución del plan de proyecto una vez se haya completado la fase de planificación a
la fase de puesta en funcionamiento. Subfases de la fase incluyen:
- Creación de procesos de negocio (automático y manual), instrucciones y formación
- El establecimiento de controles
- El establecimiento de procesos de conversión y de la transición, el equilibrio de las rutinas,
y proceso de verificación de la exactitud e integridad
 Pruebas:
- Los procesos de conversión del negocio
- Las pruebas de estrés de los procesos
- Retrocesos
- Puesta en marcha
 Conciliación de la conversión
 Ir en vivo de actividades asociadas con el inicio del nuevo proceso
 Cierre-Cierre de proyectos, contabilidad y costos finalizados
 Post implantación:
- Revisión del éxito de los proyectos
- Análisis financiero del caso de negocio frente a los resultados
La decisión de llevar a cabo revisiones en cada etapa depende de los riesgos identificados y la confianza
puesta en la aplicación. Las fases más importantes para los profesionales de auditoría incluyen la
planificación, ejecución y post implantación. En la fase de inicio podría ser necesario revisar si el
modelo de negocio está en duda. Se recomienda que la fase de puesta en funcionamiento se revise
después de los hechos como parte de una revisión post implantación para asegurar que el proceso de

14. auditoría no interfiera con las actividades en marcha.
El proceso de desarrollo de sistemas se produce durante un período de tiempo, que puede ir desde unas
pocas semanas para un pequeño proyecto y para varios años para proyectos y/o programas a gran escala.
Para proyectos más grandes con periodos prolongados de tiempo, puede ser necesario programar
múltiples revisiones de un mismo proyecto. El momento de la revisión debe estar alineado con el plan
de desarrollo y las fechas clave de hitos.
Impacto en el negocio y el riesgo
Las aplicaciones desarrolladas o adquiridas son la columna vertebral de las operaciones de la empresa.
Estos sistemas (tanto automáticos y manuales) proveen aportes a los sistemas de información
financiera, son la fuente para el análisis relacionado con las decisiones empresariales, o bien realizar o
controlar los procesos críticos de los medios de subsistencia de la empresa. El incumplimiento de la
buena práctica de desarrollo de sistemas y gestión de proyectos puede resultar en:
 Selección de proveedores inapropiado
 La solución no cumple con las empresas y/o necesidades de los usuarios, no funciona como se
esperaba, o no puede integrarse con el plan estratégico de TI, arquitectura de la información y la
dirección de la tecnología
 Falta de comprensión de los objetivos del proyecto y los requisitos
 Insuficiente participación de los interesados en la definición de requisitos y la revisión de los entregables
 Mala solución que faltan requisitos seleccionados o significativos descubierto más adelante en
el proyecto, haciendo costosa remodelación y retrasos en la puesta en práctica
 Las soluciones alternativas que no se identifican
 Altos costos de soluciones fragmentadas
 Las discrepancias contractuales y las diferencias entre las expectativas de negocio y capacidades
de los proveedores
 Gestión de conocimiento de los riesgos en la adquisición de software
 Las brechas entre los controles y las amenazas o los riesgos reales
 Sistema de seguridad y confidencialidad comprometida
 Las transacciones no válidas o transacciones procesadas incorrectamente
 Los controles de compensación costosos
 Reducción de la disponibilidad del sistema y la integridad cuestionable de la información
 Mala calidad del software, pruebas insuficientes y un alto número de fracasos

15.  El enfoque desorganizado e ineficaz la gestión de proyectos, las prioridades inapropiadas, las
funciones críticas de retraso
 Los presupuestos y recursos insuficientes
 La falta de respuesta a las cuestiones del proyecto con las decisiones óptimas aprobadas
 Las responsabilidades poco claras y rendición de cuentas para asegurar el control de costes y el
éxito del Proyecto
 La creciente dependencia de personal clave, los problemas en las operaciones diarias, ayudar a
la sobrecarga de escritorio
 Incapacidad para poner en práctica el nuevo sistema o la capacidad de retroceder el nuevo
sistema y restaurar el viejo sistema
Objetivos y alcance
Objectivos –los objetivos del desarrollo de sistemas de gestión de proyectos y la revisión de auditoría
son los siguientes:
 Ofrecer una gestión con una evaluación independiente del progreso, la calidad y el logro de los
objetivos del proyecto/programa en etapas definidas en el proyecto/programa.
 Ofrecer una gestión con una evaluación de los controles internos de los procesos de negocio
propuestos en un punto en el ciclo de desarrollo, donde las mejoras pueden ser fácilmente
aplicadas y los procesos adaptados.
 Satisfacer los procesos de auditoría de los objetivos de la revisión del proceso antes de que salga
la confianza en vivo, dar lugar a confianza futura en el proceso basado en el trabajo de control
realizado mientras la aplicación está en fase de desarrollo, e implementar técnicas de auditoría
integradas asistida por ordenador como las (TAAC), como parte del diseño de la aplicación.
Alcance –La revisión se centrará en las fases de (iniciación / planificación / ejecución / cierre / post-
implantación) del proceso de desarrollo de sistemas para la aplicación. Se apoyará en la metodología de
desarrollo de sistemas para proporcionar un diseño, desarrollo y metodología de prueba y la
metodología de gestión de proyectos para proporcionar una planificación precisa y eficiente, la
presupuestación y el control de costes. Dentro de cada fase, la revisión se centrará en:
 Gobierno
 Gestión de proyectos
 Presupuesto
 Los controles internos

16.  procesos de negocio
 Los terceros proveedores y otras influencias externas
IMPORTANCIA DE LA AUDITORÍA AL CVDS
Aunque cualquier departamento o área de una organización es susceptible de ser auditado, hay una
serie de circunstancias que hacen especialmente importante al área de desarrollo, y por tanto también de
auditoría, frente a otras funciones o áreas dentro del departamento de informática:
• Los avances en tecnologías de las computadoras han hecho que actualmente el desafío más
importante y el principal reto sea la calidad del software.
• El gasto destinado a software es cada vez superior al que se dedica al hardware.
• El software como producto es muy difícil de validar. Un mayor control en el proceso de desarrollo
incrementa la calidad del mismo y disminuye los costos de mantenimiento.
• El índice de fracasos en proyectos de desarrollo es demasiado alto, lo cual denota la inexistencia o
mal funcionamiento de los controles en este proceso.
• Las aplicaciones informáticas, que son el producto principal obtenido al final del desarrollo,
pasan a ser la herramienta de trabajo principal de las áreas informatizadas, convirtiéndose en un
factor esencial para la gestión y la toma de decisiones.
¿Cuál es la realidad de los proyectos TI?
En 2007 del total de lo proyectos de TI monitoreados, sólo el 29% lo logró a tiempo y en costo, los
costos promedio se excedieron 56% y en promedio tomó 84% más de tiempo para completarse1.
• 15% de los proyectos fracasan y son cancelados totalmente.
• 51% no cumplen sus objetivos.
• 42% en promedio por encima del presupuesto.
• 82% no cumplen el cronograma.
• US $55.000 millones perdidos en proyectos sólo en USA.
• US $17.000 millones en sobrecostos.
¿Por qué los Proyectos fallan?
1. Falta de comprensión del problema, visión ligera del alcance
2. Problemas tecnológicos y con proveedores
3. Problemas de comunicación y trabajo en equipo
1
Over due and over budget, over and over again” The Economist, june 11th 2008

17. 4. Problemas de liderazgo
5. Problemas metodológicos. Falta de un proceso de administración de proyectos.
Para tratar la auditoría al CVDS es necesario, en primer lugar, acotar las funciones o tareas que son
responsabilidad del área. Teniendo en cuenta que puede haber variaciones de una organización a otra,
las funciones que tradicionalmente se asignan al área son:
• Planificación del área y participación en la elaboración del plan estratégico de informática.
• Desarrollo de nuevos sistemas.
• Estudio de nuevos lenguajes, técnicas, metodologías, estándares, herramientas, etc. y adopción
de los mismos para mantener un nivel de vigencia adecuado al momento.
• Establecimiento de un plan de formación para el personal adscrito al área.
• Establecimiento de normas y controles para todas las actividades que se realizan en el área y
comprobación de su observancia.
Una metodología aplicable es la propuesta por la ISACA
(Information Systems Audit and Control Association), que está
basada en la evaluación de riesgos partiendo de los riesgos
potenciales a los que está sometida una actividad (en este caso el
desarrollo de un sistema de información), se determinan una serie
de objetivos de control que minimicen esos riesgos.
Para cada objetivo de control se especifican una o más técnicas de control, también denominadas
simplemente controles, que contribuyan a lograr el cumplimiento de dicho objetivo. Además, se
aportan una serie de pruebas de cumplimiento que permitan la comprobación de la existencia y correcta
aplicación de dichos controles.
Una vez fijados los objetivos de control, será función del auditor determinar el grado de cumplimiento
de cada uno de ellos. Para cada objetivo se estudiarán todos los controles asociados al mismo, usando
para ello las pruebas de cumplimiento propuestas. Con cada prueba de cumplimiento se obtendrá alguna
evidencia, bien sea directa o indirecta, sobre la corrección de los planes. Si una simple comprobación no
ofrece ninguna evidencia, será necesaria la realización de exámenes más profundos.

18. En los controles en los que sea impracticable una revisión exhaustiva de los elementos de verificación,
bien porque los recursos de auditoría sean limitados o porque el número de elementos a inspeccionar sea
muy elevado, se examinará una muestra representativa que permita inferir el estado de todo el conjunto.
El estudio global de todas las conclusiones, pruebas y evidencias obtenidas sobre cada control
permitirán al auditor obtener el nivel de satisfacción de cada objetivo de control, así como cuáles son
los puntos fuertes y débiles del mismo. Con esta información y teniendo en cuenta las particularidades
de la organización en estudio, se determinará cuáles son los riesgos no cubiertos, en qué medida lo son
y qué consecuencias se pueden derivar de esa situación. Estas conclusiones, junto con las
recomendaciones acumuladas, serán las que se plasmen en el informe de auditoría.
Etapas del Ciclo de Vida del Desarrollo de Sistemas
Aprobación,
planificación
Análisis Diseño Construcción Implantación
y gestión del
proyecto
EL PROGRAMA
Marco de Control
Este programa de auditoría se han desarrollado en consonancia con los objetivos de TI Governance
Institute® (Control de ITGITM) para la información y tecnologías relacionadas (COBIT®),
específicamente COBIT 4.1, utilizando las buenas prácticas generalmente aplicables y aceptadas, y
reflejadas en el ITAF, secciones 3400 -procesos de gestión de TI, 3600 -procesos de auditoría y
aseguramiento, y 3800 -gestión de auditoría de TI y aseguramiento.
Muchas organizaciones han adoptado varios marcos a nivel empresarial, incluido el Marco de Control
Interno del Comité de Organizaciones Patrocinadoras de la Comisión Treadway (COSO).

19. El Gobierno de TI Riesgo y Control
El gobierno de TI, el riesgo y el control son fundamentales para la realización de cualquier proceso de
gestión de seguridad. La gobernanza del proceso bajo revisión será evaluada como parte de las políticas
y controles de gestión de supervisión. Riesgo juega un papel importante en la evaluación de lo que debe
auditar y cómo los enfoques de gestión y gestionan el riesgo. Ambos temas serán evaluados como pasos
en el programa de auditoría. Los controles son el punto de evaluación primaria en el proceso. El
programa de auditoría identificará los objetivos de control y los pasos para determinar el diseño del
control y la eficacia.
Responsabilidades de Auditoría de TI y los Profesionales de Aseguramiento
Este documento es para ser utilizado como una herramienta crítica y punto de partida. Puede ser
modificado por los profesionales de auditoria de TI, y no pretende ser una lista de control o
cuestionario. Se supone que los profesionales de auditoría de TI son Certified Information Systems
Auditor (CISA), o tiene la experiencia en la materia necesaria, requerida para llevar a cabo el trabajo y
ser supervisado por un profesional con la certificación CISA y la experiencia necesaria para revisar
adecuadamente el trabajo realizado.
Uso de este documento
Este programa de auditoría fue desarrollado para ayudar a los profesionales de auditoría en el diseño y
la ejecución de una revisión sobre las diferentes fases del proyecto. El programa de auditoría se
segmenta de acuerdo a la fase. Los profesionales de auditoría deben personalizar y seleccionar aquellas
fases en el ámbito específico de revisión de la auditoría. Además, la evaluación de los controles internos
específicos basados en la aplicación dentro del ámbito de aplicación, y se trata en la sección de
Controles Internos de este programa.
Pasos del Programa
En la primera columna del programa se describen los pasos a realizar. El esquema de numeración utilizado
proporciona un trabajo de numeración incorporado en el documento para facilitar la referencia cruzada con
el documento de trabajo específico para esa sección. Se anima a los profesionales de auditoría de TI a
realizar modificaciones a este documento para adaptarlo al entorno específico que se esté evaluando.
Pasos 1 y 2 forman parte de la recopilación de datos y la preparación previa al trabajo de campo. Debido
a que el pre-trabajo de campo es esencial para una revisión exitosa y profesional, los pasos han

20. sido detallados en este plan. Los pasos de primer nivel, por ejemplo, 1.1, están en negrita y
proporcionar al revisor un alcance o una explicación de alto nivel de la finalidad para las subetapas.
Comenzando en el paso 3, se detallan los pasos asociados con el programa. Para simplificar el uso del
programa, el programa de auditoría describe los objetivos de la auditoría. La razón para llevar a cabo los
pasos en el área temática. Los controles específicos de seguimiento se muestran en AZUL. Cada paso
de revisión se enumeran a continuación del control. Estas medidas pueden incluir la evaluación del
diseño de control a pie a través de un proceso, entrevistas, observación, o la otra parte para verificar el
proceso y los controles que refiere ese proceso. En muchos casos, una vez que el diseño del control se
ha comprobado, las pruebas específicas se llevan a cabo para dar garantías de que el proceso asociado
con el control se está siguiendo. Los objetivos de la prueba se muestran en VERDE. El proceso de
prueba específica sigue el objetivo de la prueba.
El Programa de Auditoria de Desarrollo de Sistemas y Gestión de Proyectos está destinado a ser
utilizado durante las diversas fases del proyecto. En todas las fases, la gestión de proyectos se dirige. Sin
embargo, en sistemas específicos, procesos de desarrollo y controles variarán en función de esa fase.
Las áreas de control que no son aplicables, son de color GRIS. Esto da al profesional la oportunidad de
volver a añadirlas en el plan si es apropiado.
La evaluación de la madurez, se describe con más detalle más adelante en este documento; constituye la
última sección del programa.
El plan de auditoría de recapitulación, los procesos asociados con la
realización y revisión de papeles de trabajo, la preparación de las
cuestiones y recomendaciones, redacción de informes y el informe de
intercambio de información han sido excluida de este documento, ya que
es un estándar para la función de auditoría y deben ser identificados en
otras partes de las normas de la empresa.

21. Proceso de COBIT relacionado y Subproceso a Evaluar
COBIT proporciona unas directrices de auditoria para los profesionales de auditoría para referirse a los
objetivos de control COBIT específicos de apoyo a la etapa de auditoría. Los objetivos de control de
COBIT deben ser identificados para cada etapa de la auditoría. Múltiples referencias cruzadas no son
infrecuentes. Procesos en los niveles inferiores en el programa de trabajo son muy granulares a ser una
referencia cruzada con COBIT. El programa de auditoría se organiza a manera de facilitar una
evaluación a través de una estructura paralela al proceso de desarrollo. COBIT provee a fondo los
objetivos de control y prácticas de control sugeridas en cada nivel.
Componentes COSO
Como se señala en la introducción, los marcos de COSO y otras similares se han convertido en cada vez
más popular entre los profesionales de auditoría. Mientras que la función de la auditoría de TI tiene a
COBIT como un marco operativo de auditoría y los profesionales utilizan en el marco establecido por la
empresa. Desde que COSO es el marco de control interno más frecuente, se ha incluido en este documento
y es un puente para alinear seguridad de la auditoria de TI con el resto de la función de auditoría. Muchas
de las empresas de auditoría incluyen los componentes de control de COSO dentro de su informe y un
resumen de las actividades de aseguramiento al comité de auditoría del consejo de administración.
Para cada control, el profesional de auditoría debe indicar el componente(s) de COSO que se refirió. Esto es
posible, pero no es necesario en general, para extender este análisis al paso específico del nivel de auditoría.
El marco original de control interno COSO contenía cinco componentes. En 2004, COSO se revisó el
Marco de Gestión de Riesgo Empresarial (ERM) integrado y se extendió a ocho componentes. La
principal diferencia entre los dos marcos es el enfoque adicional en el ERM y la integración en el
modelo de decisión de negocios. ERM está en proceso de ser adoptados por las grandes empresas. Los
dos marcos se comparan en la figura 1.
El marco original COSO de control interno responde a las necesidades de la auditoría de TI y seguridad
profesional: ambiente de control, evaluación de riesgos, actividades de control, información y
comunicación, y monitoreo. Como tal, ISACA ha optado por utilizar el modelo de cinco componentes
de estos programas de auditoría. A medida que más empresas implementan el modelo de ERM, las
otras tres columnas se pueden añadir, si procede. Al completar las columnas de los componentes de
COSO, tenga en cuenta las definiciones de los componentes como se describe en la figura 1.

22. Figura 1— Comparativa de los controles internos de COSO y los marcos integrados ERM
Marco de Control Interno Marco Integrado del ERM
El ambiente de control: El ambiente de control establece el tono Ambiente Interno: El ambiente interno abarca el tono de una
de una organización, influyendo en la conciencia de control de su organización, y establece las bases de cómo el riesgo se ve y se
gente. Es la base para todos los demás componentes del control dirigió a las personas de la entidad, incluyendo la filosofía de gestión
interno, aportando disciplina y estructura. Factores del ambiente de del riesgo y tolerancia al riesgo, la integridad y valores éticos, y el
control incluyen la integridad, valores éticos, estilo de gestión de medio ambiente en el que operan.
operación, la delegación de los sistemas de autoridad, así como los
procesos de gestión y desarrollo de personas de la organización.
Establecimiento de Objetivos: Los objetivos deben existir antes que
la administración puede identificar eventos potenciales que afectan a
su logro. La gestión del riesgo asegura que la gestión ha puesto en
marcha un proceso para establecer objetivos y que los objetivos
elegidos apoyen y se alinean con la misión de la entidad y que sean
compatibles con su apetito por el riesgo.
Identificación de eventos: Los eventos internos y externos que
afectan el logro de los objetivos de la entidad deben ser identificados,
distinguiendo entre riesgos y oportunidades. Las oportunidades se
canalizan de vuelta a la estrategia de gestión o los procesos de
establecimiento de objetivos.
Evaluación de Riesgos: Cada entidad se enfrenta a una variedad de Evaluación de riesgos: Los riesgos son analizados, teniendo en
riesgos a partir de fuentes externas e internas que deben ser cuenta la probabilidad e impacto, como una base para determinar la
evaluados. Una condición previa para la evaluación de riesgos es el forma en que podría ser manejado. Las áreas de riesgo se evaluarán
establecimiento de objetivos, y por lo tanto la evaluación de riesgos de forma inherente y residual.
es la identificación y análisis de riesgos relevantes para el logro de
los objetivos asignados. La evaluación de riesgos es un requisito
previo para determinar cómo los riesgos deberían ser manejados.
Respuesta a los Riesgos: Gestión de riesgo de las respuestas,
selecciona evitar, aceptar, reducir o compartir los riesgos
desarrollando un conjunto de acciones para alinear los riesgos con las
tolerancias al riesgo de la entidad y apetito de riesgo.
Actividades de Control: Las actividades de control son las Actividades de Control: Las políticas y procedimientos se
políticas y procedimientos que ayudan a asegurar las directivas de establecen e implementan para ayudar a garantizar las respuestas a los
gestión que se llevan a cabo. Ayudan a asegurar que las acciones riesgos que se lleven realmente a cabo.
necesarias se toman para hacer frente a los riesgos para la
consecución de los objetivos de la entidad. Las actividades de
control se producen en toda la organización, en todos los niveles y
en todas las funciones. Incluyen una amplia gama de actividades tan
diversas como aprobaciones, autorizaciones, verificaciones,
conciliaciones, revisiones de desempeño operacional, seguridad de
activos y segregación de funciones.
Información y Comunicación: Los sistemas de información Información y Comunicación: La información pertinente es
juegan un papel clave en los sistemas de control interno, ya que identificada, capturada, y comunicada en la forma y plazo que
producen los informes, incluidos los operativos, financieros e permiten a las personas para llevar a cabo sus responsabilidades. La
información relacionada con el cumplimiento que hacen que sea comunicación efectiva también se produce en un sentido más amplio,
posible ejecutar y controlar el negocio. En un sentido más amplio, que fluye hacia abajo, al otro lado, y la entidad.
la comunicación efectiva debe garantizar el flujo de información
hacia abajo, arriba y a través de la organización. La comunicación
efectiva también debe garantizarse con las partes externas, tales
como clientes, proveedores, reguladores y accionistas.
Monitoreo: Los sistemas de control interno deben ser supervisados Monitoreo: La totalidad de la gestión del riesgo es supervisado y las
-un proceso que evalúa la calidad del desempeño del sistema a modificaciones que sean necesarias. El monitoreo se realiza a través
través del tiempo. Esto se logra a través de actividades de de actividades de gestión en curso, evaluaciones independientes o
seguimiento en curso o evaluaciones separadas. Deficiencias de ambas cosas.
control interno detectadas a través de estas actividades de
monitoreo debe ser reportado las acciones globales y correctivas se
deben tomar para garantizar la mejora continua del sistema.
La Informacion para la figura 1 fue obtenida del sitio web de COSO www.coso.org/aboutus.htm.
Prioridad
Las buenas prácticas requieren que los profesionales auditoría definan el nivel de prioridad para los
pasos del programa de acuerdo al grado de urgencia de realización de cada partida.

23. Requerimientos (a solicitar al área auditada)
Esta columna se puede utilizar para marcar los requerimientos que el profesional de la auditoría de TI
requiera para investigar más a fondo o establecer como un hallazgo potencial. Los posibles hallazgos
que deben ser documentados en un documento de trabajo que indica la disposición de los hallazgos
(formalmente informado, informado como una nota o hallazgo verbal, o renunciado).
ANÁLISIS DE MADUREZ DE LOS CONTROLES
Una de las peticiones constantes de los profesionales que se han sometido a auditoría de TI, es un deseo
de entender cómo su rendimiento se compara con las buenas prácticas. Los profesionales de auditoría
deben proporcionar una base objetiva para las conclusiones de revisión. El Modelo de Madurez para la
gestión y el control sobre los procesos de TI se basa en un método de evaluación de la organización, por
lo que puede ser evaluado a partir de un nivel de madurez de inexistente (0) y optimizado (5). Este
enfoque se deriva del modelo de madurez del Software Engineering Institute (SEI) de la Universidad
Carnegie Mellon y se define por la madurez del desarrollo de software.
La Guía de Aseguramiento de TI utilizando COBIT, Apéndice VII-Modelo de Madurez de Control
Interno, en la figura 2, proporciona un modelo de madurez genérico que muestra el estado del entorno
de control interno y el establecimiento de controles internos de una empresa. Se muestra cómo la
gestión del control interno, y la conciencia de la necesidad de establecer mejores controles internos, por
lo general se desarrolla a partir una base ad hoc a un nivel optimizado. El modelo proporciona una guía
de alto nivel para ayudar a los usuarios de COBIT a apreciar lo que se requiere para la eficacia de los
controles internos de TI y para ayudar a posicionar su empresa en la escala de madurez.
1.1.1.1.1 Figura 2— Modelo de Madurez de Control Interno
1.1.1.1.2 Nivel 1.1.1.1.3 Estado de Medio Ambiente de 1.1.1.1.4 Establecimiento
de Madurez Control Interno de Controles Internos
1.1.1.1.5 0 1.1.1.1.6 No hay ningún reconocimiento de la 1.1.1.1.7 No hay ninguna intención de evaluar la
Inexistente necesidad de un control interno. El control no es parte necesidad de control interno. Los incidentes se tratan a
de la cultura de la organización o misión. Hay un alto medida que surjan.
riesgo de deficiencias de control y los incidentes.
1.1.1.1.8 1 1.1.1.1.9 Hay algo de reconocimiento de la necesidad 1.1.1.1.10 No hay conciencia de la necesidad de una
Inicial/ad hoc de un control interno. El enfoque de los requisitos de evaluación de lo que se necesita en términos de
riesgo y el control es ad hoc y desorganizados, sin una controles de TI. Cuando se realiza, es sólo sobre una
comunicación o un control. Las deficiencias no se base ad hoc, en un nivel alto y en reacción a incidentes
identifican. Los empleados no son conscientes de sus significativos. La evaluación aborda sólo el incidente
responsabilidades. real.
1.1.1.1.11 2 1.1.1.1.12 Los controles están en su lugar, pero no 1.1.1.1.13 Evaluación de las necesidades de control se
Repetible pero están documentados. Su funcionamiento depende de los produce sólo cuando sea necesario para determinados
intuitivo conocimientos y la motivación de las personas. La procesos de TI para determinar el nivel actual de

24. 1.1.1.1.1 Figura 2— Modelo de Madurez de Control Interno
1.1.1.1.2 Nivel 1.1.1.1.3 Estado de Medio Ambiente de 1.1.1.1.4 Establecimiento
de Madurez Control Interno de Controles Internos
efectividad no es evaluada adecuadamente. Muchos madurez de control, el nivel objetivo que debe
puntos débiles de control existen y no se tratan alcanzarse, y las lagunas que existen. Un enfoque de
adecuadamente, el impacto puede ser severo. Las taller informal, la participación de los gerentes de TI y
acciones de manejo para resolver las cuestiones de el equipo involucrado en el proceso, se utiliza para
control no son prioridad ni consistente. Los empleados definir un enfoque adecuado a los controles para el
no pueden ser conscientes de sus responsabilidades. proceso y para motivar a un plan de acción acordado.
1.1.1.1.14 3 1.1.1.1.15 Los controles están en su lugar y 1.1.1.1.16 Procesos críticos de TI se identifican sobre
Definido documentado adecuadamente. Efectividad de la la base de los indicadores de valor y riesgo. Un análisis
operación se evalúa de forma periódica y no es un detallado se realiza para identificar los requisitos de
número promedio de cuestiones. Sin embargo, el control y la causa raíz de las lagunas y desarrollar
proceso de evaluación no está documentado. Si bien la oportunidades de mejora. Además de los talleres
gestión es capaz de hacer frente de manera predecible facilitados, se utilizan herramientas y las entrevistas se
con la mayoría de los problemas de control, algunas llevan a cabo para apoyar el análisis y asegurarse de
debilidades de control y los efectos que persisten que un propietario de procesos de TI y quién dirige el
todavía podrían ser graves. Los empleados son proceso de evaluación y mejora.
conscientes de sus responsabilidades de control.
1.1.1.1.17 4 1.1.1.1.18 Hay un control interno efectivo y gestión del 1.1.1.1.19 TI criticidad proceso se define habitualmente
Administrado riesgo del medio ambiente la. Una evaluación formal y con el pleno apoyo y el acuerdo de los propietarios de
y medible documentada de los controles se produce con los procesos de negocio relevantes. Evaluación de los
frecuencia. Muchos controles están automatizados y se requisitos de control se basa en la política y la madurez
revisarán periódicamente. La administración es real de estos procesos, tras un minucioso análisis y
probable que para detectar la mayoría de los problemas medida la participación de las principales partes
de control, pero no todos los problemas se identifican interesadas. La rendición de cuentas para estas
de forma rutinaria. No hay un seguimiento constante evaluaciones es clara y forzada. Las estrategias de
para hacer frente a las deficiencias de control. Un uso mejora se apoyan en los casos de negocios. El
limitado, táctico de la tecnología se aplica a rendimiento en el logro de los resultados deseados es
automatizar los controles. constantemente monitoreado. Reseñas externas de
control se organizan de vez en cuando.
1.1.1.1.20 5 1.1.1.1.21 Un riesgo para toda la empresa y el 1.1.1.1.22 Los cambios de negocio en cuenta la
Optimizado programa de control ofrece un control continuo y eficaz criticidad de los procesos de TI y cubrir cualquier
del riesgo y la resolución de problemas. El control necesidad de volver a evaluar la capacidad del proceso
interno y gestión de riesgos se integran con las de control. Los propietarios de los procesos de TI
prácticas empresariales, apoyados con sistemas realizan regularmente auto-evaluaciones para confirmar
automáticos en tiempo real con la plena rendición de que los controles están en el nivel adecuado de
cuentas para el seguimiento de control, gestión de madurez para satisfacer las necesidades de negocio y
riesgos y la aplicación del cumplimiento normativo. La consideran que los atributos de madurez para encontrar
evaluación de control es continua, basada en la maneras de hacer controles más eficientes y eficaces.
autoevaluación y la brecha de análisis de causa raíz. Los puntos de referencia de la organización a las
Los empleados están activamente involucrados en las mejores prácticas externas y busca asesoramiento
mejoras de control. externo sobre la efectividad del control interno. Para
los procesos críticos, revisiones independientes de
llevarse a cabo para dar garantías de que los controles
están en el nivel deseado de madurez y funciona según
lo previsto.
La evaluación del modelo de madurez es uno de los pasos finales en el proceso de evaluación. Los
profesionales de auditoría de TI pueden abordar los controles clave en el ámbito del programa de
trabajo, y formular una evaluación objetiva del nivel de madurez de las prácticas de control. La
evaluación de la madurez puede ser una parte del informe de auditoría y puede ser utilizado como un
indicador de año en año para documentar la progresión en la mejora de los controles. Sin embargo, debe
tenerse en cuenta que la percepción sobre el nivel de madurez puede variar entre el proceso de SI/TI
propietario de los activos y el auditor. Por lo tanto, el auditor deberá obtener el acuerdo del titular de la

25. participación de los interesados antes de presentar el informe final a la gestión.
Al concluir la revisión, una vez que todas las conclusiones y recomendaciones se hayan completado, el
profesional evalúa el estado actual del sistema de control de COBIT, y le asigna un nivel de madurez
utilizando la escala de seis niveles. Algunos doctores en el área utilizan decimales (X.25, X.5, X.75)
para indicar gradaciones en el modelo de madurez. Como referencia adicional, COBIT ofrece una
definición de las denominaciones de madurez por parte de objetivo de control. Si bien este enfoque no
es obligatorio, el proceso se ofrece como una sección separada al final del programa de auditoría para
aquellas empresas que deseen ponerla en práctica. Se sugiere que una evaluación de la madurez se haga
en el nivel de control de COBIT. Para proporcionar un mayor valor al cliente, el profesional también
puede obtener los objetivos de madurez del cliente. Con los niveles de madurez evaluados y el destino,
el profesional puede crear una presentación eficaz gráfica que describe el logro o brechas entre los
objetivos de madurez real y objetivo. Un gráfico se ofrece en la última página de este documento, con
base en las evaluaciones de la muestra.
MARCO DE ASEGURAMIENTO Y CONTROL
Marco de Aseguramiento y Normas de TI de ISACA
En el desarrollo de sistemas y gestión de proyectos del ITAF se incluyen las siguientes secciones:
• 3420 –Gestión de proyectos de TI.
• 3450 –Procesos de TI.
• 3490 –Apoyo de TI al Cumplimiento Normativo.
• 3650 –Ciclo de Vida de Desarrollo de Sistemas.
• 3650 –Los controles de auditoría de aplicación.
• 3657 –Auditoría de Estrategias Alternativas de Desarrollo de Software.
ISACA ha reconocido desde hace tiempo la naturaleza especializada de TI y se esfuerza por avanzar en
las normas aplicables a escala mundial. Directrices y procedimientos ofrecen una guía detallada sobre
cómo seguir las normas. Las Directrices de Auditoría de SI G23 y las revisiones al Ciclo de Vida del
Desarrollo de Sistemas (CVDS), G26 Reingeniería de Procesos de Negocio (BPR), revisiones de
proyectos y G29 revisión post-implementación, y el Procedimiento de Auditoría de Aplicaciones de
Negocio P10 Control de cambios son relevantes para este programa de auditoría.
Marco de Controles de ISACA

26. COBIT es un marco de gobernanza de TI y apoyo al conjunto de herramientas que permite a los administradores
cerrar la brecha entre los requerimientos de control, cuestiones técnicas y riesgos de negocio. COBIT permite el
desarrollo de una política clara y de buenas prácticas para el control de TI en toda la empresa.
Utilizando COBIT como marco de control en el que basan en la auditoría de las actividades alinea
auditoría de TI y seguridad con las buenas prácticas desarrolladas por la empresa.
El dominio COBIT Adquisición e Implementación (AI) aborda las buenas prácticas para el desarrollo
de sistemas, el dominio Planeación y Organización (PO), las direcciones de los procesos de TI PO10 la
gestión de proyectos. Las áreas de COBIT para esta evaluación son:
 Los proyectos PO10 –se han establecido para manejar el programa y el marco de la gestión de proyectos
para la gestión de todos los proyectos de TI. El marco garantiza la priorización correcta y la coordinación
de todos los proyectos. El marco incluye un plan maestro, la asignación de recursos, la definición de las
prestaciones, la aprobación de los usuarios, un enfoque gradual para la entrega, control de calidad, un
plan de pruebas formales, y las pruebas y el examen posterior a la ejecución de la instalación para
garantizar una gestión de riesgos del proyecto y la entrega de valor al negocio. Este enfoque reduce el
riesgo de costos inesperados y cancelaciones de proyectos, mejora las comunicaciones y la asociación de
usuarios de negocios y al final, se asegura el valor y la calidad de los entregables del proyecto, y
maximiza su contribución a los programas de inversiones habilitadas por TI.
 AI1 Identificar soluciones automatizadas –la necesidad de una nueva aplicación o función requiere
de un análisis antes de la adquisición o creación que asegure que los requerimientos del negocio se
cumplen en un enfoque eficaz y eficiente. Este proceso abarca la definición de las necesidades, la
consideración de fuentes alternativas, la revisión de la viabilidad tecnológica y económica, la
ejecución de un análisis de riesgos y análisis de costo-beneficio, y la conclusión de una decisión
definitiva "hacer" o "comprar." Todos estos pasos permiten a las organizaciones minimizar el coste
de adquirir e implementar soluciones garantizando al mismo tiempo que permiten a la empresa
alcanzar sus objetivos.
 AI2 Adquir y mantener software aplicativo –las aplicaciones están disponibles en línea con los
requerimientos del negocio. Este proceso abarca el diseño de las aplicaciones, la inclusión adecuada
de los controles de aplicación y requisitos de seguridad y el desarrollo y la configuración en línea
con las normas. Esto permite a las organizaciones apoyar adecuadamente las operaciones de negocio
con las aplicaciones automatizadas correctas.
 AI3 Adquirir y mantener infraestructura tecnología –las organizaciones que tienen procedimientos

27. para la adquisición, implementación y actualización de la infraestructura tecnológica. Esto requiere un
enfoque planificado para la adquisición, mantenimiento y protección de la infraestructura en
consonancia con las estrategias de tecnología acordadas y la provisión de entornos de desarrollo y
prueba. Esto asegura que existe un apoyo permanente tecnológico para las aplicaciones empresariales.
 AI4 Facilitar la operación y uso –el conocimiento sobre los sistemas nuevos que se encuentren disponibles.
Este proceso requiere la producción de documentación y manuales para los usuarios de TI, y proporciona
una formación que garantice el buen uso y funcionamiento de las aplicaciones y la infraestructura.
 AI5Adquirir recursos de TI –los recursos de TI, incluyendo personas, hardware, software y
servicios, deben ser adquiridos. Esto requiere la definición y aplicación de los procedimientos de
contratación, la selección de proveedores, la configuración de los acuerdos contractuales, y la
adquisición en sí. Así, asegura que la organización tiene todo lo que requiere, recursos de manera
oportuna y rentable.
 AI7 Instalar y acreditar soluciones y cambios –los nuevos sistemas deben ponerse en marcha, una
vez completado su desarrollo. Esto requiere pruebas adecuadas en un ambiente dedicado con datos
de las pruebas pertinentes, la definición de las instrucciones de despliegue y la migración, la
planificación de la liberación y la promoción real de la producción, y una revisión post-
implementación. Esto asegura que los sistemas operativos están en línea con las expectativas
acordadas y los resultados.
Consulte las Prácticas de Control de COBIT: Guía para lograr los objetivos de control de éxito de
Gobierno de TI, 2da Edición, publicado en 2007 del Gobierno de IT Governance Institute, por el valor
de control de la práctica relacionada con los conductores y el riesgo.
Habilidades Mínimas de auditoría
El profesional de auditoría de TI y seguridad debe tener una comprensión del desarrollo de la buena
práctica de los sistemas y los procesos de gestión de proyectos. Los profesionales de haber logrado la
certificación CISA o tener las habilidades técnicas necesarias para realizar algunos pasos de auditoría.
Puede requerir la comprensión específica de los entornos de sistemas operativos en uso, los sistemas de
gestión de bibliotecas y de informática, técnicas de auditoría asistidas (TAAC).

28. Programa de Auditoria de Desarrollo de Sistemas y Gestión de Proyectos
COSO
Evaluación de Riesgos
Actividades de Control
Información y comunicación
Ambiente de Control
Proceso de
Subproceso
PASOS DEL PROGRAMA COBIT Prioridad
a evaluar
relacionado
Monitoreo
1 . PLANIFICACIÓN Y ALCANCE DE LA AUDITORÍA
1
Ideas / Descripción de subprocesos
1.1 Definir los objetivos de la auditoria. ME2 ME2.1
Los objetivos de la auditoría son de alto nivel y describen los objetivos generales de auditoría.
1.1.1.1 Revisar los objetivos de la auditoria para iniciar el programa de auditoria.
1.1.1.2 Modificar los objetivos de la auditoria para alinearlo con la auditoria general, el plan anual de auditoria o la carta de
la gerencia.
1.2 Definir los límites de la revisión.
La revisión debe tener un alcance definido. El revisor debe comprender el entorno operativo y preparar una propuesta de alcance, ME2 ME2.1
sin perjuicio para una posterior evaluación de riesgos.
1.2.1.1 Realizar un recorrido de alto nivel del proyecto que será revisado.
1.2.1.1.1.1 Determinar en que fase del proyecto esta.
1.2.1.1.1.2 Obtener una lista de los cambios implementados a la producción para el periodo de prueba.
1.2.1.1.1.3 Determinar las aplicaciones y/o entornos operativos atendidos por proyectos.
1.2.1.1.1.4 Obtener una lista de las aplicaciones críticas de las especificadas en la Sarbanes-Oxley.
1.2.1.1.1.5 Obtener una lista de los nuevos sistemas implementados o mejoras importantes a los sistemas existentes para el periodo de
prueba.
1.2.1.2 Establecer los límites iniciales de la revision de la auditoria.
1.2.1.2.1.1 Identificar las limitaciones y restrinciones que afectan a la auditoria de sistemas especificos.
1.2.1.3 Revisar todas las fases y pasos dentro de este programa de auditoria.
1.2.1.3.1.1 Seleccionar los pasos dentro de la fase que son aplicables a los alcances y los límites establecidos.
1.2.1.3.1.2 Considerar medidas adicionales según sea necesario en function del alcance establecido.
1.2.1.3.1.3 Considerar el uso de programas adidionales de auditorias para aplicaciones especificas y problemas operacionales de TI.
1.3 Definir la seguridad.

29. COSO
Evaluación de Riesgos
Actividades de Control
Información y comunicación
Ambiente de Control
Proceso de
Subproceso
PASOS DEL PROGRAMA COBIT Prioridad
a evaluar
relacionado
Monitoreo
La revisión require de dos fuentes. Los estandares corporativos definidos en la documentacion de politicas y procedimientos que
establezca las expectativas de las empresas. Como minino, los estándares corportativos deben ser implementados. La segunda
fuente, una referencia de buenas prácticas, establece estándares de la industria. Las mejoras deben ser propuestas para hacer frente
a las diferencias entre los dos.
1.3.1.1 Obtención de las normas de desarrollo de los sistemas de la empresa, el manual de la metodología del desarrollo de
los sistemas, las normas de gestión de proyectos y el manual de metodología del proyecto.
1.3.1.2 Determinar si se usará COBIT y un marco de desarrollo de sistemas apropiado como buenas prácticas de referencia.
1.4 Identificar los riesgos y los documentos.
En la evaluación de riesgos es necesario evaluar los recursos de auditoria en donde debe centrarse. En la mayoría de las
organizaciones, los recursos de auditoría no están disponibles para todos los procesos. El enfoque basado en el riesgo garantiza la
utilización de los recuros de auditoria de la la manera más efiecaz.
1.4.1.1 Para los proyectos identificados como foco potencial:
1.4.1.1.1.1 Identificar el riesgo del negocio asociado a la aplicación en desarrollo.
1.4.1.1.1.2 Identificar los riesgos tecnológicos asociados a la aplicación en desarrollo.
1.4.1.1.1.3 Evaluar los riesgos empresariales y tecnológicos.
1.4.1.2 Con base en la evaluación de riesgos, identificar los cambios en el ámbito de aplicación.
1.4.1.3 Discutir los riesgos de TI, de negocios y de gestión de auditoria operacional, y ajustarlo a la evaluación de riesgos.
1.4.1.4 Con base en la evaluación de riesgos, revisar el alcance.
1.5 Definir el proceso de cambio.
El enfoque de la auditoria se basa en la compresión de la revición del entorno operativo y los riesgos asociados. Y como es que se
lleva a cabo la investigación y el análisis, los cambios en el alcance y el enfoque.
1.5.1.1 Identificar el senior de IT responsable de la revisión de los recursos.
1.5.1.2 Establecer el proceso para sugerir e implementar cambios en el programa de auditoría y las autorizaciones
requeridas.
1.6 Definir el exito de la asignación.
Es necesario identificar los factores de éxito. Es esencial la comunicación entre el equipo de auditoría de TI, los otros equipos de
aseguramiento y la empresa.
1.6.1.1 Identificar los controladores para una revisión exitosa (Esto debe existir en las normas de la función de garantía y
los procedimientos)
1.6.1.2 Comunicar el éxito atribuye al propietario del proceso o los interesados clave y obtener un acuerdo.