SlideShare ist ein Scribd-Unternehmen logo
1 von 156
Downloaden Sie, um offline zu lesen
Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 
1 
Universidad Central del Ecuador 
Facultad de Ciencias Administrativas 
Escuela de Contabilidad y Auditaría 
Asignatura: 
Auditoría de Sistemas Informáticos II 
Tema: 
Desarrollo del Sílabo y Reactivos 
Quito - Ecuador
Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 
El presente documento fue realizado, como guía académica y práctica para la Asignatura: 
“Auditoría de Sistemas Informáticos II”. 
Este material contiene como anexos los reactivos para su respetiva evaluación, para efectos 
de enseñanza y aprendizaje con el enfoque a resultados. 
2
Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 
3 
INDICE 
INTRODUCCION …………………………………………… 6 
MISION …………………………………………… 7 
VISION …………………………………………… 7 
OBJETIVO GENERAL …………………………………………… 7 
OBJETIVOS ESPECIFICOS …………………………………………… 8 
I UNIDAD 
RESUMEN EJECUTIVO DE COBIT …………………………………………… 9 
1. Resumen Ejecutivo de COBIT 
1.1 Administración de la información. …………………………………………… 10 
1.2 Áreas de enfoque del Gobierno de TI …………………………………………… 11 
1.3 Interrelaciones de los componentes …………………………………………… 12 
II UNIDAD 
MARCO DE TRABAJO DE COBIT …………………………………………… 13 
Marco de trabajo de control para el Gobierno de TI. Misión de Cobit. 
2.1 Principio básico de COBIT …………………………………………… 15 
2.2 Criterios de Información …………………………………………… 16 
2.3 Metas y negocios y de TI …………………………………………… 17 
2.4 Recursos de TI ………………………………………….., 19 
2.5 Recursos orientado los procesos de COBIT …………………………………... 20 
2.6 Objetivos de Control para los 34 procesos de COBIT …………………………… 31 
2.7 Controles generales y de aplicación de TI …………………………………… 34 
2.8 Generalidades de los modelos de madurez. …………………………………… 
2.9 Modelo del Marco de Trabajo de COBIT. …………………………………… 
3.3 Planear y Organizar …………………………………… 
PO1 Definir un Plan Estratégico de TI …………………………………… 
PO2 Definir la Arquitectura de la Información …………………………………… 
PO3 Determinar la Dirección Tecnológic …………………………………… 
PO4 Definir los Procesos, Organización y Relaciones de TI …………………… 
PO5 Administrar la Inversión en TI …………………………………………… 
PO6 Comunicar las Aspiraciones y la Dirección de la Gerencia …………………… 
PO7 Administrar Recursos Humanos de TI …………………………………………… 
PO8 Administrar la Calidad …………………………………………… 
PO9 Evaluar y Administrar los Riesgos de TI …………………………………… 
PO10 Administrar Proyectos …………………………………………… 
3.4 Adquirir e Implementar …………………………………………… 
AI1 Identificar solucione automatizadas ……………………………………………
Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 
4 
AI2 Adquirir y mantener software aplicativo …………………………… 
AI3 Adquirir y mantener infraestructura tecnológica …………………………… 
AI4 Facilitar la operación y el uso …………………………… 
AI5 Adquirir Recursos de TI …………………………… 
AI6 Administrar Cambios …………………………… 
A17 Instalar y acreditar soluciones y cambios …………………………… 
III UNIDAD 
3.5 Entregar y dar Soporte 
DS1 Definir y administrar los niveles de servicio …………………………… 
DS2 Administrar los servicios de terceros …………………………… 
DS3 Administrar el desempeño y la capacidad …………………………… 
DS4 Garantizar la continuidad del servicio …………………………… 
DS5 Garantizar la seguridad de los sistemas …………………………… 
DS6 Identificar y asignar costos …………………………… 
DS7 Educar y entrenar a los usuarios …………………………… 
DS8 Administrar la mesa de servicio y los incidentes …………………………… 
DS9 Administrar la configuración …………………………… 
DS10 Administrar los problemas …………………………… 
DS11 Administrar los datos …………………………… 
DS12 Administrar el ambiente físico …………………………… 
DS13 Administrar las operaciones …………………………… 
3.6 Monitorear y Evaluar …………………………… 
ME1 Monitorear y Evaluar el Desempeño de TI ME2 
Monitorear y Evaluar el Control Interno …………………………… 
ME3 Garantizar el Cumplimiento Regulatorio ME4 
Proporcionar Gobierno de TI …………………………… 
IV UNIDAD 
LOS MODELOS DE MADUREZ PARA EL CONTROL INTERNO DE COBIT 
4. Modelos de madurez para el Control Interno 
4.1 Enlaces de las metas de negocio a procesos de TI …………………………… 
4.2 Enlaces de las metas de TI a procesos de TI …………………………… 
4.3 Matriz de procesos de TI a Metas de TI …………………………… 
Mapa de procesos de TI a las áreas focales de Gobierno 
de TI, COSO, Recursos de TI de COBIT y Criterios de 
información de COBIT. …………………………… 
CONCLUSIONES …………………………… 
RECOMENDACIONES …………………………… 
COMENTARIO …………………………… 
GLOSARIO ……………………………
Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 
5 
BIBLIOGRAFIA …………………………… 
REACTIVOS ……………………………101
Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 
6 
INTRODUCCION 
El proyecto COBIT se emprendió por primera vez en el año 1995, con el fin de crear un 
mayor producto global que pudiese tener un impacto duradero sobre el campo de visión de 
los negocios, así como sobre los controles de los sistemas de información implantados. 
La primera edición del COBIT, fue publicada en 1996 y fue vendida en 98 países de todo el 
mundo. La segunda edición, fue publicada en Abril de 1998, desarrolla y mejora lo que 
poseía la anterior mediante la incorporación de un mayor número de documentos de 
referencia fundamentales, nuevos y revisados objetivos de control de alto nivel, 
intensificando las líneas maestras de auditoría, introduciendo un conjunto de herramientas 
de implementación, así como un CD-ROM completamente organizado el cual contiene la 
totalidad de los contenidos de esta segunda edición. 
Una temprana adición significativa visualizada para la familia de productos COBIT, es el 
desarrollo de las Guías de Gerencia que incluyen Factores Críticos de Éxito, Indicadores 
Clave de Desempeño y Medidas Comparativas. Los Factores Críticos de Éxito, 
identificarán los aspectos o acciones más importantes para la administración y poder tomar, 
así, dichas acciones o considerar los aspectos para lograr control sobre sus procesos de TI. 
Los Indicadores Clave de Desempeño proporcionarán medidas de éxito que permitirán a la 
gerencia conocer si un proceso de TI está alcanzando los requerimientos de negocio. La 
Medidas Comparativas definirán niveles de madurez que pueden ser utilizadas por la 
gerencia para: determinar el nivel actual de madurez de la empresa; determinar el nivel de 
madurez que se desea lograr, como una función de sus riesgos y objetivos; y proporcionar 
una base de comparación de sus prácticas de control de TI contra empresas similares o 
normas de la industria. Esta adicción, proporcionará herramientas a la gerencia para evaluar 
el ambiente de TI de su organización con respecto a los 34 Objetivos de Control de alto 
nivel de COBIT. 
En definitiva, la organización ISACF, espera que el COBIT sea adoptado por las 
comunidades de auditoría y negocio como un estándar generalmente aceptado para el 
control de las Tecnologías de la Información.
Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 
La nueva versión en español del marco referencial COBIT 4.1 de ISACA hace que este 
conjunto de prácticas generalmente aceptadas en todo el mundo sea más accesible. COBIT 
4.1 ayuda a los consejos de administración, ejecutivos y gerentes a aumentar el valor de las 
TI y reducir los riesgos relacionados. 
Ampliamente utilizado como una herramienta para el cumplimiento con Sarbanes-Oxley y 
otros estándares mundiales, COBIT, es anterior a la promulgada legislación sobre el control 
en todo el mundo. Es producto de más de 15 años de investigación y cooperación entre 
expertos globales de TI y negocios. La versión en español del marco está disponible como 
descarga gratuita de la asociación internacional sin fines de lucro ISACA. 
El enfoque hacia procesos de COBIT se ilustra con un modelo de procesos, el cual 
subdivide TI en 34 procesos de acuerdo a las áreas de responsabilidad de planear, construir, 
ejecutar y monitorear, ofreciendo una visión de punta a punta de la TI. Los conceptos de 
arquitectura empresarial ayudan a identificar aquellos recursos esenciales para el éxito de 
los procesos, es decir, aplicaciones, información, infraestructura y personas. 
7 
MISION 
La misión es "investigar, desarrollar, publicar y promocionar un conjunto de objetivos de 
control generalmente aceptados para las tecnologías de la información que sean autorizados 
(dados por alguien con autoridad), actualizados, e internacionales para el uso del día a día 
de los gestores de negocios (también directivos) y auditores." Gestores, auditores, y 
usuarios se benefician del desarrollo de COBIT porque les ayuda a entender sus Sistemas 
de Información (o tecnologías de la información) y decidir el nivel de seguridad y control 
que es necesario para proteger los activos de sus compañías mediante el desarrollo de un 
modelo de administración de las tecnologías de la información. 
VISION 
Ser el modelo de control para las TI (tecnologías de la información), ayudando a identificar 
los recursos esenciales para el éxito de los procesos, mediante aplicaciones, información, 
infraestructura y personas. 
OBJETIVO GENERAL 
Buscar, desarrollar, publicar y promover un autoritario y actualizado conjunto internacional 
de objetivos de control de tecnologías de la información, generalmente aceptadas, para el 
uso diario por parte de gestores de negocio, que cubren tanto los aspectos de información, 
como de la tecnología que la respalda. Estos dominios y objetivos de control facilitan que la 
generación y procesamiento de la información cumplan con las características de 
efectividad, eficiencia, confidencialidad, integridad, disponibilidad, cumplimiento y 
confiabilidad. su flexibilidad y versatilidad nos permite adaptarlo a cualquier tipo y tamaño 
de empresa, realizando una implementación gradual y progresiva acorde a los recursos 
disponibles y acompasando la estrategia empresarial.
Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 
8 
OBJETIVOS ESPECIFICOS 
Este dominio cubre la estrategia y las tácticas y se refiere a la identificación de la 
forma en que la tecnología de información puede contribuir de la mejor manera al 
logro de los objetivos del negocio. Además, la consecución de la visión estratégica 
necesita ser planeada, comunicada y administrada desde diferentes perspectivas. 
Finalmente, deberán establecerse una organización y una infraestructura tecnológica 
apropiadas. 
Para llevar a cabo la estrategia de TI, las soluciones de TI deben ser identificadas, 
desarrolladas o adquiridas, así como implementadas e integradas dentro del proceso 
del negocio. Además, este dominio cubre los cambios y el mantenimiento realizados 
a sistemas existentes. 
El enfoque del control en TI se lleva a cabo visualizando la información necesaria 
para dar soporte a los procesos de negocio y considerando a la información como el 
resultado de la aplicación combinada de recursos relacionados con las TI que deben 
ser administrados por procesos de TI. 
Buscar, desarrollar, publicar y promover un autoritario y actualizado conjunto 
internacional de objetivos de control de tecnologías de la información, generalmente 
aceptadas, para el uso diario por parte de gestores de negocio y auditores. 
propone un marco de acción donde se evalúan los criterios de información, como 
por ejemplo la seguridad y calidad, se auditan los recursos que comprenden la 
tecnología de información, como por ejemplo el recurso humano, instalaciones, 
sistemas, entre otros, y finalmente se realiza una evaluación sobre los procesos 
involucrados en la organización.
Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 
9 
UNIDAD I 
1. Resumen Ejecutivo de COBIT 
1.1 Administración de la información. 
1.2 Áreas de enfoque del Gobierno de TI 
1.3 Interrelaciones de los componentes
Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 
10 
RESUMEN EJECUTIVO DE COBIT 
1. RESUMEN EJECUTIVO DE COBIT 
1.1 ADMINISTRACION DE LA INFORMACION 
La información y la tecnología que las soportan representan sus más valiosos activos, 
aunque con frecuencia son poco entendidos. Las empresas exitosas reconocen los 
beneficios de la tecnología de información y la utilizan para impulsar el valor de sus 
interesados. 
La necesidad del aseguramiento del valor de TI, la administración de los riesgos asociados 
a TI, así como el incremento de requerimientos para controlar la información, se entienden 
ahora como elementos clave del Gobierno Corporativo. El valor, el riesgo y el control 
constituyen la esencia del gobierno de TI. 
El gobierno de TI es responsabilidad de los ejecutivos, del consejo de directores y consta de 
liderazgo, estructuras y procesos organizacionales que garantizan que TI en la empresa 
sostiene y extiende las estrategias y objetivos organizacionales. 
Las organizaciones deben satisfacer la calidad, los requerimientos fiduciarios y de 
seguridad de su información, así como de todos sus activos. La dirección también debe 
optimizar el uso de los recursos disponibles de TI, incluyendo aplicaciones, información, 
infraestructura y personas. Para descargar estas responsabilidades, así como para lograr sus 
objetivos, la dirección debe entender el estatus de su arquitectura empresarial para TI y 
decidir qué tipo de gobierno y de control debe aplicar. 
Se muestra algunas preguntas frecuentes y las herramientas gerenciales de información 
usadas para encontrar las respuestas, aunque estos tableros de crequieren indicadores, los 
marcadopuntuación requieren mediciones y los Benchmarking requieren una escala de 
comparación.
Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 
Una respuesta a los requerimientos de determinar y monitorear el nivel apropiado de 
control y desempeño de TI son las definiciones específicas de COBIT de los siguientes 
conceptos: 
• Benchmarking de la capacidad de los procesos de TI, expresada como modelos de 
madurez, derivados del Modelo de Madurez de la Capacidad del Instituto de Ingeniería de 
Software 
• Metas y métricas de los procesos de TI para definir y medir sus resultados y su 
desempeño, basados en los principios de Balanced Scorecard de Negocio de Robert Kaplan 
y David Norton 
• Metas de actividades para controlar estos procesos, con base en los objetivos de control 
detallados de COBIT 
11 
1.2 AREAS DE ENFOQUE DEL GOBIERNO DE TI 
Las áreas de enfoque del gobierno de TI, COSO, recursos TI de COBIT y criterios de 
información COBIT), ofreciendo así un puente entre lo que los gerentes operativos deben 
realizar y lo que los ejecutivos desean gobernar. 
Para lograr un gobierno efectivo, los ejecutivos esperan que los controles a ser 
implementados por los gerentes operativos se encuentren dentro de un marco de control 
definido para todo los procesos de TI. Los objetivos de control de TI de COBIT están 
organizados por proceso de TI; por lo tanto, el marco de trabajo brinda una alineación clara 
entre los requerimientos de gobierno de TI, los procesos de TI y los controles de TI. 
Los productos COBIT se han organizado en tres niveles diseñados para dar soporte a: 
Administración del negocio y de TI 
Administración y consejos ejecutivos 
Profesionales en Gobierno, aseguramiento, 
control y seguridad.
Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 
12 
1.3 INTERRELACIONES DE LOS COMPONENTES 
Una vez que han sido definidas las metas alineadas, estás requieren ser monitoreadas para 
garantizar que la entrega cumple con las expectativas. Esto se logra con métricas derivadas 
de las metas y capturadas en el scorecard de TI. 
Para que el cliente pueda entender las metas de TI y el scorecard de TI, todos estos 
objetivos y métricas asociadas deben expresarse en términos de negocio significativos para 
el cliente. Esto, combinado con un alineamiento efectivo de los objetivos jerárquicos 
aseguraría que el negocio puede confirmar que es probable que TI soporte los objetivos de 
la empresa. 
El apéndice I, Tablas de enlace entre metas y procesos, proporciona una visión global de 
cómo las metas genéricas de negocio se relacionan con las metas de TI, los procesos de TI 
y los criterios de la información. Las tablas ayudan a demostrar el ámbito de COBIT y las 
relaciones completas de negocio entre COBIT y los impulsores de la empresa. La figura 6 
ilustra, que estos impulsores vienen del negocio y desde la capa de Gobierno Corporativo, 
en primer lugar enfocándose más en las funcionalidades y velocidad de la entrega, mas 
tarde en la relación costo-eficiencia, retorno de inversión (ROI) y cumplimiento.
Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 
13 
UNIDAD II 
2. Marco de trabajo de control para el Gobierno de 
TI. Misión de Cobit. 
2.1 Principio básico de COBIT 
2.2 Criterios de Información 
2.3 Metas y negocios y de TI 
2.4 Recursos de TI 
2.5 Recursos orientado los procesos de COBIT 
2.6 Objetivos de Control para los 34 procesos de COBIT 
2.7 Controles generales y de aplicación de TI 
2.8 Generalidades de los modelos de madurez. 
2.9 Modelo del Marco de Trabajo de COBIT.
Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 
14 
MARCO DE TRABAJO DE COBIT 
MARCO DE TRABAJO DE CONTROL PARA EL GOBIERNO DE TI. MISION DE 
COBIT 
LA NECESIDAD DE UN MARCO DE TRABAJO PARA EL CONTROL DEL 
GOBIERNO DE TI 
¿Por qué utilizar un marco de referencia? 
Cada vez más, la alta dirección se está dando cuenta del impacto significativo que la 
información puede tener en el éxito de una empresa. 
La dirección espera un alto entendimiento de la manera en que la tecnología de información 
(TI) es operada y de la posibilidad de que sea aprovechada con éxito para tener una ventaja 
competitiva. 
En particular, la alta dirección necesita saber si con la información administrada en la 
empresa es posible que: 
Garantice el logro de sus objetivos 
Tenga suficiente flexibilidad para aprender y adaptarse 
Cuente con un manejo juicioso de los riesgos que enfrenta 
Reconozca de forma apropiada las oportunidades y actúe de acuerdo a ellas. 
Alinear la estrategia de TI con la estrategia del negocio 
Lograr que toda la estrategia de TI, así como las metas fluyan de forma gradual a 
toda la empresa 
Proporcionar estructuras organizacionales que faciliten la implementación de 
estrategias y metas 
Crear relaciones constructivas y comunicaciones efectivas entre el negocio y TI, y 
con socios externos 
Medir el desempeño de TI 
Las empresas no pueden responder de forma efectiva a estos requerimientos de negocio y 
de gobierno sin adoptar e implementar un marco de Referencia de gobierno y de control 
para TI, de tal manera que: 
Se forme un vínculo con los requerimientos del negocio 
El desempeño real con respecto a los requerimientos sea transparente 
Organice sus actividades en un modelo de procesos generalmente aceptado 
Identifique los principales recursos a ser aprovechados 
Se definan los objetivos de control Gerenciales a ser considerados 
D) ¿Quién utiliza las tecnologías de información?
Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 
Un marco de referencia de gobierno y de control requiere servir a una variedad de 
interesados internos y externos, cada uno de los cuales tiene necesidades específicas: 
Interesados dentro de la empresa que tengan un interés en generar valor de las inversiones 
en TI: 
15 
Aquellos que tomen decisiones de inversiones 
Aquellos que deciden respecto a los requerimientos 
Aquellos que utilicen los servicios de TI 
Interesados internos y externos que proporcionen servicios de TI: 
Aquellos que administren la organización y los procesos de TI 
Aquellos que desarrollen capacidades 
Aquellos que operen los servicios 
Interesados internos y externos con responsabilidades de control/riesgo: 
Aquellos con responsabilidades de seguridad, privacidad y/o riesgo 
Aquellos que realicen funciones de cumplimiento 
Aquellos que requieran o proporcionen servicios de aseguramiento 
e) ¿Para que sirve un marco de referencia? 
Para satisfacer los requerimientos previos, para el gobierno y el control de TI deben 
satisfacer las siguientes especificaciones generales: 
Brindar un enfoque de negocios que permita la alineación entre los objetivos de 
negocio y de TI. 
Establecer una orientación a procesos para definir el alcance y el grado de 
cobertura, con una estructura definida que permita una fácil navegación en el 
contenido. 
Ser generalmente aceptable al ser consistente con las mejores prácticas y estándares 
de TI aceptados, y que sea independiente de tecnologías específicas. 
Proporcionar un lenguaje común, con un juego de términos y definiciones que sean 
comprensibles en lo general para todos los interesados. 
Ayudar a satisfacer requerimientos regulatorios, al ser consistente con estándares de 
gobierno corporativo generalmente aceptados (COSO) y con controles de TI esperados por 
agentes reguladores y auditores externos. 
2.1 PRINCIPIO BASICO DE COBIT 
El marco de trabajo COBIT se creó con las características principales de ser orientado a 
negocios, orientado a procesos, basado en controles e impulsado por mediciones.
Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 
16 
2.1.2. Requerimientos de información 
El control de procesos IT en COBIT satisface los Requerimientos del Negocio, lo que es 
habilitado por una correcta Declaración de Control; y a su vez es considerado como una 
correcta Práctica de Control. 
2.1.3. Procesos de Tecnologías de Información 
COBIT clasifica los procesos del negocio relacionados con las Tecnologías de la 
Información en 4 dominios: 
Planificación y Organización. 
Adquisición e Implementación. 
Entrega y Soporte. 
Supervisión y Evaluación. 
2.1.4. Recursos de Tecnologías de Información 
Hace a la organización disponer de recursos que son utilizados por los procesos para cubrir 
los requisitos del negocio: 
Efectividad (cumplimiento de objetivos). 
Eficiencia (consecución de los objetivos con el máximo aprovechamiento de los 
recursos). 
Confidencialidad. 
Integridad.
Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 
17 
Disponibilidad. 
Cumplimiento regulatorio. 
Fiabilidad. 
2.1.5. Criterios de información 
Para satisfacer los objetivos del negocio, la información necesita adaptarse a ciertos 
criterios de control, los cuales son referidos en COBIT como requerimientos de 
información del negocio. Se definieron los siguientes siete criterios de información: 
La efectividad 
La eficiencia 
La confidencialidad 
La integridad 
La disponibilidad 
El cumplimiento 
La confiabilidad 
2.3 METAS Y NEGOCIOS DE LA TECNOLOGIA DE INFORMACIÓN 
Mientras que los criterios de información proporcionan un método genérico para definir los 
requerimientos del negocio, la definición de un conjunto de metas genéricas de negocio y 
de TI ofrece una base más refinada y relacionada con el negocio para el establecimiento de 
requerimientos de negocio y para el desarrollo de métricas que permitan la medición con 
respecto a estas metas. 
Toda empresa usa TI para habilitar iniciativas del negocio y estas pueden ser representadas 
como metas del negocio para TI. El Apéndice I proporciona una matriz de metas genéricas 
de negocios y metas de TI y como se asocian con los criterios de la información. Estos 
ejemplos genéricos se pueden utilizar como guía para determinar los requerimientos, metas 
y métricas específicas del negocio para la empresa. 
Si se pretende que TI proporcione servicios de forma exitosa para dar soporte a la estrategia 
de la empresa, debe existir una propiedad y una dirección clara de los requerimientos por 
parte del negocio (el cliente) y un claro entendimiento para TI, de cómo y qué debe 
entregar (el proveedor). 
La Figura ilustra como la estrategia de la empresa se debe traducir por parte del negocio en 
objetivos relacionados con iniciativas habilitadas por TI (Las metas de negocio para TI). 
Estos objetivos a su vez, deben conducir a una clara definición de los propios objetivos de 
TI (las metas de TI), y luego éstas a su vez definir los recursos y capacidades de TI (la
Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 
arquitectura empresarial para TI) requeridos para ejecutar, de forma exitosa la parte que le 
corresponde a TI de la estrategia empresarial. 
Para que el cliente entienda las metas y los Scorecard de TI, todos estos objetivos y sus 
métricas asociadas se deben expresar en términos de negocio significativos para el cliente, 
y esto, combinado con una alineación efectiva de la jerarquía de objetivos, asegurará que el 
negocio pueda confirmar que TI puede, con alta probabilidad, dar soporte a las metas del 
negocio. 
Una vez que han sido definidas las metas alineadas, estás requieren ser monitoreadas para 
garantizar que la entrega cumple con las expectativas. Esto se logra con métricas derivadas 
de las metas y capturadas en el scorecard de TI. 
Para que el cliente pueda entender las metas de TI y el scorecard de TI, todos estos 
objetivos y métricas asociadas deben expresarse en términos de negocio significativos para 
el cliente. Esto, combinado con un alineamiento efectivo de los objetivos jerárquicos 
aseguraría que el negocio puede confirmar que es probable que TI soporte los objetivos de 
la empresa. 
18
Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 
19 
2.4 RECURSOS DE TECNOLOGIAS DE INFORMACIÓN 
La organización de TI se desempeña con respecto a estas metas como un conjunto de 
procesos definidos con claridad que utiliza lashabilidades de las personas, y la 
infraestructura de tecnología para ejecutar aplicaciones automatizadas de negocio, mientras 
que al mismo tiempo toma ventaja de la información del negocio. Estos recursos, junto con 
los procesos, constituyen una arquitectura empresarial para TI. 
Para responder a los requerimientos que el negocio tiene hacia Tecnología de Información, 
la empresa debe invertir en los recursos requeridos para crear una capacidad técnica 
adecuada 
Ej., un sistema de planeación de recursos empresariales (ERP) para dar soporte a la 
capacidad del negocio: 
Ejemplos: 
Implementando una cadena de suministro, que genere el resultado deseado 
(mayores ventas y beneficios financieros) 
2.4.1. Los recursos de Tecnología de Información identificados en COBIT se pueden 
definir como sigue: 
Las aplicaciones incluyen tanto sistemas de usuario automatizados como 
procedimientos manuales que procesan información.
Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 
La información son los datos en todas sus formas, de entrada, procesados y 
generados por los sistemas de información, en cualquier forma en que sean 
utilizados por el negocio. 
La infraestructura es la tecnología y las instalaciones (hardware, sistemas 
operativos, sistemas de administración de base de datos, redes, multimedia, 
etc., así como el sitio donde se encuentran y el ambiente que los soporta) que 
permiten el procesamiento de las aplicaciones. 
Las personas son el personal requerido para planear, organizar, adquirir, 
implementar, entregar, soportar, monitorear y evaluar los sistemas y los 
servicios de información. Estas pueden ser internas, por outsourcing o 
contratadas, de acuerdo a como se requieran. 
20 
2.5 RECURSOS ORIENTADOS LOS PROCESOS DE COBIT 
COBIT define las actividades de TI en un modelo genérico de procesos organizado en 
cuatro dominios. 
Estos dominios son Planear y Organizar, Adquirir e Implementar, Entregar y Dar Soporte y 
Monitorear y Evaluar, esto dominios se equiparan a las áreas tradicionales de TI de planear, 
construir, ejecutar y monitorear. 
El marco de trabajo de COBIT proporciona un modelo de procesos de referencia y un 
lenguaje común para que todos en la empresa visualicen y administren las actividades de 
TI. 
La incorporación de un modelo operativo y un lenguaje común para todas las partes de un 
negocio involucradas en TI es uno de los pasos iníciales más importantes hacia un buen 
gobierno también brinda un marco de trabajo para la medición y monitoreo del desempeño 
de TI, comunicándose con los proveedores de servicios e integrando las mejores prácticas 
de administración. Un modelo de procesos fomenta la propiedad de los procesos, 
permitiendo que se definan las responsabilidades. 
Para gobernar efectivamente Tecnología de Información, es importante determinar las 
actividades y los riesgos que requieren ser administrados. Normalmente se ordenan dentro 
de dominios de responsabilidad de plan, construir, ejecutar y Monitorear. 
2.5.1. DOMINIOS DE COBIT 
 Planear y Organizar (PO) – Proporciona dirección para la entrega de 
soluciones (AI) y la entrega de servicio (DS). 
 Adquirir e Implementar (AI) – Proporciona las soluciones y las pasa para 
convertirlas en servicios. 
 Entregar y Dar Soporte (DS) – Recibe las soluciones y las hace utilizables 
por los usuarios finales.
Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 
 Monitorear y Evaluar (ME) -Monitorear todos los procesos para asegurar 
21 
que se sigue la dirección provista. 
2.5.1.1. PLANEAR Y ORGANIZAR (PO) 
Este dominio cubre las estrategias y las tácticas, y tiene que ver con identificar la manera en 
que TI puede contribuir de la mejor manera al logro de los objetivos del negocio. Además, 
la realización de la visión estratégica requiere ser planeada, comunicada y administrada 
desde diferentes perspectivas. Finalmente, se debe implementar una estructura 
organizacional y una estructura tecnológica apropiada. Este dominio cubre los siguientes 
cuestionamientos típicos de la gerencia: 
¿Están alineadas las estrategias de TI y del negocio? 
¿La empresa está alcanzando un uso óptimo de sus recursos? 
¿Entienden todas las personas dentro de la organización los objetivos de TI? 
¿Se entienden y administran los riesgos de TI? 
¿Es apropiada la calidad de los sistemas de TI para las necesidades del negocio? 
2.5.1.2. ADQUIRIR E IMPLEMENTAR (AI) 
Para llevar a cabo la estrategia de TI, las soluciones de TI necesitan ser identificadas, 
desarrolladas o adquiridas así como implementadas e integradas en los procesos del 
negocio además, el cambio y el mantenimiento de los sistemas existentes estácubierto por 
este dominio para garantizar que las soluciones sigan satisfaciendo los objetivos del 
negocio. Este dominio, por lo general, cubre los siguientes cuestionamientos de la 
gerencia: 
¿Es probable que los nuevos proyectos generan soluciones que satisfagan las 
necesidades del negocio?
Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 
¿Es probable que los nuevos proyectos sean entregados a tiempo y dentro del 
presupuesto? 
¿Trabajarán adecuadamente los nuevos sistemas una vez sean implementados? 
¿Los cambios no afectarán a las operaciones actuales del negocio? 
22 
2.5.1.3. ENTREGAR Y DAR SOPORTE (DS) 
Este dominio cubre la entrega en sí de los servicios requeridos, lo que incluye la prestación 
del servicio, la administración de la seguridad y de la continuidad, el soporte del servicio a 
los usuarios, la administración de los datos y de las instalaciones operativos. Por lo general 
cubre las siguientes preguntas de la gerencia: 
¿Se están entregando los servicios de TI de acuerdo con las prioridades del 
negocio? 
¿Están optimizados los costos de TI? 
¿Es capaz la fuerza de trabajo de utilizar los sistemas de TI de manera 
productiva y segura? 
¿Están implantadas de forma adecuada la confidencialidad, la integridad y la 
disponibilidad? 
2.5.1.4. MONITOREAR Y EVALUAR (ME) 
Todos los procesos de TI deben evaluarse de forma regular en el tiempo en cuanto a su 
calidad y cumplimiento de los requerimientos de control, este dominio abarca la 
administración del desempeño, el monitoreo del control interno, el cumplimiento 
regulatorio y la aplicación del gobierno, por lo general abarca las siguientes preguntas de la 
gerencia: 
¿Se mide el desempeño de TI para detectar los problemas antes de que sea 
demasiado tarde? 
¿La Gerencia garantiza que los controles internos son efectivos y eficientes? 
¿Puede vincularse el desempeño de lo que TI ha realizado con las metas del 
negocio? 
¿Se miden y reportan los riesgos, el control, el cumplimiento y el desempeño? 
A lo largo de estos cuatro dominios, COBIT ha identificado 34 procesos de TI 
generalmente usados. Mientras la mayoría de las empresas ha definido las 
responsabilidades de planear, construir, ejecutar y monitorear para TI, y la mayoría tienen 
los mismos procesos clave, pocas tienen la misma estructura de procesos o le aplicaran 
todos los 34 procesos de COBIT. 
COBIT proporciona una lista completa de procesos que puede ser utilizada para verificar 
que se completan las actividades y responsabilidades; sin embargo, no es necesario que 
apliquen todas, y, aun más, se pueden combinar como se necesite por cada empresa.
Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 
Para cada uno de estos 34 procesos, tiene un enlace a las metas de negocio y TI que 
soporta. Información de cómo se pueden medir las metas, también se proporcionan cuáles 
son sus actividades clave y entregables principales, y quién es el responsable de ellas. 
23 
2.6 OBJETIVOS DE CONTROL PARA LOS 34 PROCESOS DE COBIT 
COBIT (Objetivos de control para la información y tecnologías relacionadas) es una 
metodología publicada en 1996 por el Instituto de Control de TI y la ISACA (Asociación 
de Auditoría y Control de Sistemas de Información) que se usa para evaluar el 
departamento de informática de una compañía; en Francia está representada por la AFAI 
(Asociación Francesa de Auditoría y Consejo de TI). 
2.6.1. ENFOQUE DE COBIT 
Este enfoque se basa en un índice de referencia de procesos, indicadores de objetivos clave 
e indicadores de rendimiento clave que se usan para controlar los procesos para recoger 
datos que la compañía puede usar para alcanzar sus objetivos.
Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 
El enfoque COBIT propone 34 procesos organizados en 4 áreas funcionales más grandes 
que abarcan 318 objetivos: 
24 
Entrega y asistencia técnica 
Control 
Planeamiento y organización 
Aprendizaje e implementación 
2.7 CONTROLES GENERALES Y DE APLICACIÓN DE TI 
2.7.1. Los controles generales son aquellos que están inmersos en los procesos y 
servicios de TI. 
Algunos ejemplos son: 
Desarrollo de sistemas 
Administración de cambios 
Seguridad 
Operaciones de cómputo 
2.7.2. Los controles incluidos en las aplicaciones de los procesos del negocio se conocen 
por lo general como controles de aplicación 
Ejemplos: 
Integridad (Completitud) 
Precisión 
Validez 
Autorización 
Segregación de funciones 
COBIT asume que el diseño e implementación de los controles de aplicación automatizados 
son responsabilidad de TI, y están cubiertos en el dominio de Adquirir e Implementar, con 
base en los requerimientos de negocio definidos, usando los criterios de información de 
COBIT. 
La responsabilidad operativa de administrar y controlar los controles de aplicación no es de 
TI, sino del dueño del proceso de negocio. 
Por lo tanto, la responsabilidad de los controles de aplicación es una responsabilidad 
conjunta, fin a fin, entre el negocio y TI, pero la naturaleza de la responsabilidad cambia de 
la siguiente manera: 
La empresa es responsable de: 
Definir apropiadamente los requisitos funcionales y de control 
Uso adecuadamente los servicios automatizados 
Tecnología de Información es responsable de:
Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 
25 
Automatizar e implementar los requisitos de las funciones de negocio y de control 
Establecer controles para mantener la integridad de controles de aplicación. 
Por lo tanto, los procesos de TI de COBIT abarcan a los controles generales de TI, pero 
sólo los aspectos de desarrollo de los controles de aplicación; la responsabilidad de definir 
y el uso operativo es de la empresa. 
2.7.3. CONTROLES DE COBIT SOBRE LA INFORMACION 
2.7.3.1 AC1 Preparación y Autorización de Información Fuente. 
Asegurar que los documentos fuente están preparados por personal autorizado y calificado 
siguiendo los procedimientos establecidos, teniendo en cuenta una adecuada segregación de 
funciones respecto al origen y aprobación de estos documentos. Los errores y omisiones 
pueden ser minimizados a través de buenos diseños de formularios de entrada. Detectar 
errores e irregularidades para que sean informados y corregidos. 
2.7.3.2. AC2 Recolección y Entrada de Información Fuente. 
Establecer que la entrada de datos se realice en forma oportuna por personal calificado y 
autorizado. Las correcciones y reenvíos de los datos que fueron erróneamente ingresados se 
deben realizar sin comprometer los niveles de autorización de las transacciones originales.
Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 
En donde sea apropiado para reconstrucción, retener los documentos fuentes originales 
durante el tiempo necesario. 
2.7.3.3. AC3 Chequeos de Exactitud, Integridad y Autenticidad 
Asegurar que las transacciones son exactas, completas y válidas. Validar los datos 
ingresados, y editar o devolver para corregir, tan cerca del punto de origen como sea 
posible. 
2.7.3.4 AC4 Integridad y Validez del Procesamiento 
Mantener la integridad y validación de los datos a través del ciclo de procesamiento. 
Detección de transacciones erróneas no interrumpe le procesamiento de transacciones 
validas. 
2.7.3.5. AC5 Revisión de Salidas, Reconciliación y Manejo de Errores 
Establecer procedimientos y responsabilidades asociadas para asegurar que la salida se 
maneja de una forma autorizada, entregada al destinatario apropiado, y protegida durante la 
transmisión; que se verifica, detecta y corrige la exactitud de la salida; y que se usa la 
información proporcionada en la salida. 
2.7.3.6. AC6 Autenticación e Integridad de Transacciones 
Antes de pasar datos de la transacción entre aplicaciones internas y funciones de 
negocio/operativas (dentro o fuera de la empresa), verificar el apropiado direccionamiento, 
autenticidad del origen e integridad del contenido. Mantener la autenticidad y la integridad 
durante la transmisión o el transporte. 
26 
2.8 GENERALIDADES DE LOS MODELOS DE MADUREZ. 
2.8.1. Nuevo modelo de madurez 
Es un modelo de Madurez que permite el mejoramiento del desarrollo de productos y 
servicios, consiste en un conjunto de las mejores prácticas que cubre el ciclo de vida de un 
producto 
Es una forma de medir la madurez de los procesos a través del “Process Capability 
Model”, basado en el estándar internacionalmente reconocido “ISO/IEC 15504 Software 
Engineering – ProcessAssessment Standard”, diferente en su diseño y uso al modelo de 
madurez que incluía COBIT 4.1. 
La nueva versión de COBIT tomará precisamente el modelo de madurez definido por ISO 
en la norma ISO/IEC 15504 más conocida como SPICE (Software Process Improvement 
Capability Determinatorio. 
2.8.2. Los niveles definidos en el modelo SPICE son los siguientes: 
Nivel 0: Incompleto 
Nivel 1: Realizado 
Nivel 2: Gestionado
Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 
27 
Nivel 3: Establecido 
Nivel 4: Predecible 
Nivel 5: Optimizado 
Nivel Características Área Clave del Proceso 
Optimizado (5) Capacidad de 
Mejoramiento Continuo. 
- Proceso de Gestión de 
Cambio. 
- Innovación Tecnológica. 
- Prevención de Fallas. 
Administrado (4) Planeación de la calidad 
del producto y seguimiento 
de las mediciones del 
proceso de producción del 
software 
- Gestión de Calidad del 
Software. 
- Gestión cuantitativa del 
proceso de generación del 
software. 
Definido (3) Proceso de Ciclo de Vida 
definido e 
institucionalizado para 
proveer control de calidad 
- Revisión Pares (Colegas). 
Coordinación inter-grupos 
Aplicación de la Ingeniería 
de Software 
Software para la gestión 
del desarrollo 
Programa de capacitación 
Definición de la 
organización del proceso 
Foco en la organización del 
proceso 
Repetible (2) Supervisión de la gestión y 
seguimiento del proyecto 
Planificación formal 
Gestión de la configuración 
del software 
Control de Calidad del 
software 
Gestión de los desarrollos 
subcontratados 
Supervisión y seguimiento 
de la ejecución del 
proyecto de software 
Planificación formal del 
proyecto de software 
Gestión de requerimientos 
Inicial Ad-hoc (impredecible, 
caótico) 
– 
Este modelo ayuda a la gerencia de TI a buscar por medio de benchmarking y herramientas 
de auto-evaluación respuesta a la necesidad de saber qué hacer de manera eficiente. 
Comenzando con los procesos y los objetivos de control de alto nivel de COBIT, el
Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 
propietario del proceso se debe poder evaluar de forma progresiva, contra los objetivos de 
control. 
28 
2.8.3 DIFERENCIAS DE ESTE NUEVO MODELO 
Al estar basado en ISO/IEC 15504 es más exigente respecto a lo que debe cumplir 
cada proceso para ascender de nivel, dado que este estándar plantear que se deben 
cumplir los 9 atributos definidos para cada proceso, como requisito para acreditar 
dicho grado de madurez. 
Una evaluación realizada bajo este nuevo modelo no es comparable y no puede ser 
mezclada con evaluaciones realizadas bajo el modelo de COBIT 4.1, dado que se 
distorsionarían los resultados por ser distintas las exigencias. 
Generalmente, aplicando este modelo de COBIT 5, deberían dar resultados de 
niveles más bajos de madurez. 
A continuación, se expone el mapeo oficial de ISACA entre ambos modelos de madurez: 
COMPARACIÓN ENTRE AMBOS MODELOS DE MADUREZ
Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 
29 
2.9 MODELO DEL MARCO DE TRABAJO DE COBIT. 
El marco de trabajo de COBIT, por tanto, relaciona los requerimientos de la información y 
de gobierno a los objetivos de la función de servicios TI. 
Para resumir, los recursos de TI son manejados por procesos de TI para lograr metas de TI 
que respondan a los requerimientos del negocio, dn detalle, el marco de trabajo general de 
COBIT está compuesto de cuatro dominios que contienen 34 procesos genéricos, 
administrando los recursos de TI para proporcionar información al negocio de acuerdo con 
los requerimientos del negocio y de gobierno. 
2.9.1. COMO SATISFACE COBIT LA NECESIDAD DE CONTROL DE LAS TI 
Como respuesta a las necesidades descritas en la sección anterior, el marco de trabajo 
COBIT se creó con las características principales de ser orientado a negocios, orientado a 
procesos, basado en controles e impulsado por mediciones a la orientación a negocios es el 
tema principal de COBIT. 
Está diseñado para ser utilizado no solo por proveedores de servicios, usuarios y auditores 
de TI, sino también y principalmente, como guía integral para la gerencia y para los 
propietarios de los procesos de negocio. 
Proporcionar la información que la empresa requiere para lograr sus objetivos, la empresa 
necesita administrar y controlar los recursos de TI usando un conjunto estructurado d me 
procesos que ofrezcan los servicios requeridos de información.El marco de trabajo COBIT 
ofrece herramientas para garantizar la alineación con los requerimientos del negocio.
Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 
30 
3.3 PLANEAR Y ORGANIZAR 
PO1 DEFINIR UN PLAN ESTRATÉGICO DE TI 
PLAN ESTRATÉGICO DE TI 
Definición: Es necesaria para Gestionar y dirigir todos los Recursos de TI en línea Con la 
estrategia y Prioridades del negocio. 
Objetivos: 
1. Administración del valor de TI
Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 
31 
2. Alineación de TI con el negocio 
3. Evaluación del desempeño y la 
Capacidad actual. 
4.Plan estratégico 
5. Planes tácticos 
6. Administración del portafolio de TI 
MODELO DE MADUREZ 
Inicial: Cuando se conoce la necesidad de una Planeación estratégica. 
Repetible: Cuando ocurren respuestas a las solicitudes de la información. 
Definido : Cuando se sigue un enfoque que garantiza la facilidad de la planeación 
Administrado: Se define con responsabilidades de alto nivel. 
Optimizado: Se toma en cuenta el establecimiento de las metas del negocio. 
PO2 DEFINIR LA ARQUITECTURA DE LA INFORMACION. 
OBJETIVOS 
Modelo de arquitectura de información empresarial 
Diccionario de Datos empresarial y reglas de sintaxis de datos 
Esquema de clasificación de datos 
Administración de integridad 
MODELO DE MADUREZ 
Inicial: Cuando se reconoce la necesidad de una arquitectura de información. 
Repetible: Cuando existen procedimientos similares que siguen los individuos 
Definido : Se acepta la responsabilidad en la aplicación en la cual se comunicara 
Administrado: Se otorga el soporte completo al desarrollo de implantación por 
medio de técnicas. 
Optimizado: El personal de TI tiene la experiencia y habilidades necesarias para 
desarrollar.
Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 
32 
PO3- DETERMINAR LA DIRECCIÓN TECNOLÓGICA. 
Objetivos de Control 
Planeación de la dirección tecnológica. 
Plan de infraestructura tecnológica. 
Monitoreo de tendencias y regulaciones futuras. 
Estándares tecnológicos. 
Consejo de arquitectura de TI. 
Modelo de Madurez 
No existe: No existe conciencia sobre la importancia de la planeación de la 
infraestructura tecnológica para la entidad. 
Inicia: Cuando la gerencia reconoce la necesidad de planear la infraestructura 
tecnológica. 
Repetible: Se difunde la necesidad e importancia de la planeación tecnológica. 
Definido: Cuando la gerencia está consciente de la importancia del plan de 
infraestructura tecnología. 
Administrado : La dirección garantiza el desarrollo del plan de infraestructura 
tecnológica 
Optimizado: La dirección del plan de infraestructura esta impulsada en los 
estándares de avances industriales e internacionales. 
PO4- DEFINIR LOS PROCESOS, ORGANIZACIÓN Y RELACIONES TI. 
Agiliza la respuesta a las estrategias del negocio mientras se cumplan los requerimientos 
del gobierno.
Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 
Enfocado al El establecimiento de estructuras organizacionales de TI transparentes, 
flexibles y responsables y en la definición e implementación de procesos de TI. 
Se logra con la definición de un marco de trabajo de procesos de TI. El establecimiento de 
un cuerpo y una estructura organizacional apropiada. La definición de roles y 
responsabilidades 
Se mide con el porcentaje de roles con descripciones de puestos. El número de procesos de 
negocio que no reciben soporte de TI y que deberían de recibirlo. Número de actividades 
clave de TI que no son aprobadas. 
33 
Objetivos de Control PO4 
Marco de trabajo de proceso de TI. 
Comité estratégico de Ti. 
Comité directivo de TI. 
Ubicación organizacional de la función de TI. 
Estructura organizacional. 
Establecimiento de roles y responsabilidades. 
Responsabilidades de aseguramiento de calidad de TI. 
Responsabilidad sobre el riesgo, la seguridad y el cumplimiento. 
Propiedad de datos y de sistemas. 
Supervisión. 
Segregación de funciones. 
Personal de TI. 
Personal clave de TI. 
Políticas y procedimientos para personal contratado. 
Relaciones. 
PO5. ADMINISTRAR LA INVERSION EN TI 
Establece y mantiene un marco de trabajo Para administrar los programas de inversión en 
TI 
SE LOGRA 
El pronostico de presupuestos 
Definición de criterios formales 
Medición del valor del negocio 
SE MIDE 
Porcentaje de reducción en el costo unitario 
Porcentaje de l valor
Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 
34 
Porcentaje de gasto 
OBJETIVOS DE CONTROL 
Marco de trabajo Para la administración financiera 
Prioridades dentro del presupuesto de TI 
Proceso presupuestal 
Administración de costos de TI 
Administración de beneficios 
MODELO DE MADUREZ 
P06.COMUNICAR LAS ASPIRACIONES Y LA DIRECCION DE LA GERENCIA 
Se debe implementar un programa de comunicación continua para dar a conocer la misión, 
los objetivos de servicio, políticas y procedimientos aprobados y apoyados por la dirección 
SE LOGRA CON 
Definición de marco de trabajo. 
Elaboración e implantación de politicas 
El refuerzo de políticas 
SE MIDE 
Optimizado 
no existente 
Inicia 
l 
Definido Repetible 
Administrado
Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 
35 
Numero de interrupciones en el negocio 
Porcentaje de interesados 
Porcentaje de interesados que no cumplen las políticas. 
OBJETIVOS DE CONTROL 
1. Ambiente de políticas y de control 
2. Riesgo corporativo 
3. Administracion de políticas para TI 
4. Implantacion de políticas de TI 
5. Comunicacion de los objetivos 
MODELO DE MADUREZ 
P07 ADMINISTRAR LOS RECURSOS HUMANOS DE TI 
OBJETIVOS 
Reclutamiento y Retención 
Asignación de Roles 
Dependencia sobre individuos 
Evaluacion del Desempeño 
Cambios y Terminación del trabajo 
Procedimientos de investigacion del personal 
Entramiento del Personal de TI
Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 
36 
Competencias del Personal 
MODELO DE MADUREZ 
PO8 ADMINISTRAR LA CALIDAD 
OBJETIVOS 
SISTEMA DE ADMINISTRACION DE CALIDAD 
ESTÁNDARES Y PRÁCTICAS DE CALIDAD 
ESTÁNDARES DE DESARROLLO Y DE ADQUISICION 
ENFOQUE EN EL CLIENTE DE TI 
MEJORA CONTINUA 
MEDICION, MONITOREO Y REVISION DE LA CALIDAD 
MODELO DE MADUREZ
Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 
37 
P09. EVALUAR Y ADMINISTRAR LOS RIESGOS DE TI 
Responsabilidad de la Administración 
Tratamiento idóneop/responder adecuadamente 
Evaluar, documentar y dar mantenimiento 
Analizar y comunicar los riesgos de TI 
PLANEAR Y ORGANIZAR 
PO9 OBJETIVOS DE CONTROL
Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 
38 
PO10 ADMINISTRACIÓN DE PROYECTOS 
Coordinación de todos los proyectos y Programas de TI que se han establecido 
Incluir un Plan Maestro de Recursos Asegurar y Garantizar la Calidad y Definición 
de un Plan Formal 
Garantiza a la Administración de los Posibles Riesgos del Proyecto y la Entrega de 
Valor para el Negocio. 
PO10 OBJETIVOS DE CONTROL 
MODELO DE MADUREZ 
No Existente: La mala administración de los proyectos y con las fallas de desarrollo en el 
proyecto. 
1 Inicial / Ad Hoc : Existe una carencia de compromiso y Administración por parte de la 
gerencia. 
2 Repetible: La organización está en proceso de Desarrollar y utilizar algunas técnicas y 
métodos proyecto por proyecto. 
3 Definido: Se establece una oficina de admón de proyectos dentro de TI, con roles y 
responsabilidades iniciales definidas.
Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 
4 Administrado y Medible: La administración de proyectos se mide y evalúa a través de la 
organización y no sólo en TI. 
5 Optimizado: Se ha definido e implantado una estrategia de TI para contratar el desarrollo 
y los proyectos operativos. 
39 
3.4 ADQUIRIR E IMPLEMENTAR 
3.4.1 .-IDENTIFICAR SOLUCIONES AUTOMATIZADAS AI1 
3.4.1.1.- DESCRIPCIÓN DEL PROCESO. 
La necesidad de una nueva aplicación o función requiere de análisis antes de la compra o 
desarrollo para garantizar que los requisitos del negocio se satisfacen con un enfoque 
efectivo y eficiente. Este proceso cubre la definición de las necesidades, considera las 
fuentes alternativas, realiza una revisión de la factibilidad tecnológica y económica, ejecuta 
un análisis de riesgo y de costo-beneficio y concluye con una decisión final de “desarrollar” 
o “comprar”. Todos estos pasos permiten a las organizaciones minimizar el costo para 
Adquirir e Implementar soluciones, mientras que al mismo tiempo facilitan el logro de los 
objetivos del negocio.
Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 
40 
3.4.1.2.- OBJETIVOS DE CONTROL 
AI1.1 Definición y Mantenimiento de los Requerimientos Técnicos y Funcionales del 
Negocio 
Identificar, dar prioridades, especificar y acordar los requerimientos de negocio funcionales 
y técnicos que cubran el alcance completo de todas las iniciativas requeridas para lograr los 
resultados esperados de los programas de inversión en TI. 
AI1.2 Reporte de Análisis de Riesgos 
Identificar, documentar y analizar los riesgos asociados con los requerimientos del negocio 
y diseño de soluciones como parte de los procesos organizacionales para el desarrollo de 
los requerimientos. 
AI1.3 Estudio de Factibilidad y Formulación de Cursos de Acción Alternativos 
Desarrollar un estudio de factibilidad que examine la posibilidad de Implementar los 
requerimientos. La administración del negocio, apoyada por la función de TI, debe evaluar 
la factibilidad y los cursos alternativos de acción y realizar recomendaciones al 
patrocinador del negocio. 
AI1.4 Requerimientos, Decisión de Factibilidad y Aprobación 
Verificar que el proceso requiere al patrocinador del negocio para aprobar y autoriza los 
requisitos de negocio, tanto funcionales como técnicos, y los reportes del estudio de
Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 
factibilidad en las etapas clave predeterminadas. El patrocinador del negocio tiene la 
decisión final con respecto a la elección de la solución y al enfoque de adquisición. 
41 
3.4.1.3.- MODELO DE MADUREZ 
La administración del proceso de Identificar soluciones automatizadas que satisfaga el 
requerimiento de negocio de TI de traducir los requerimientos funcionales y de control 
del negocio a diseño efectivo y eficiente de soluciones automatizadas es: 
0 No Existente cuando 
La organización no requiere de la identificación de los requerimientos funcionales y 
operativos para el desarrollo, implementación o modificación de soluciones, tales como 
sistemas, servicios, infraestructura y datos. La organización no está consciente de las 
soluciones tecnológicas disponibles que son potencialmente relevantes para su negocio. 
1 Inicial / Ad Hoc cuando 
Existe conciencia de la necesidad de definir requerimientos y de identificar soluciones 
tecnológicas. Grupos individuales se reúnen para analizar las necesidades de manera 
informal y los requerimientos se documentan algunas veces. Los individuos identifican 
soluciones con base en una conciencia limitada de mercado o como respuesta a ofertas de 
proveedores. Existe una investigación o análisis estructurado mínimo de la tecnología 
disponible 
2 Repetible pero Intuitivo cuando 
Existen algunos enfoques intuitivos para identificar que existen soluciones de TI y éstos 
varían a lo largo del negocio. Las soluciones se identifican de manera informal con base en 
la experiencia interna y en el conocimiento de la función de TI. El éxito de cada proyecto 
depende de la experiencia de unos cuantos individuos clave. La calidad de la 
documentación y de la toma de decisiones varía de forma considerable. Se usan enfoques 
no estructurados para definir los requerimientos e identificar las soluciones tecnológicas. 
3 Definido cuando 
Existen enfoques claros y estructurados para determinar las soluciones de TI. El enfoque 
para la determinación de las soluciones de TI requiere la consideración de alternativas 
evaluadas contra los requerimientos del negocio o del usuario, las oportunidades 
tecnológicas, la factibilidad económica, las evaluaciones de riesgo y otros factores. El 
proceso para determinar las soluciones de TI se aplica para algunos proyectos con base en 
factores tales como las decisiones tomadas por el personal involucrado, la cantidad de 
tiempo administrativo dedicado, y el tamaño y prioridad del requerimiento de negocio
Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 
original. Se usan enfoques estructurados para definir requerimientos e identificar soluciones 
de TI. 
42 
4 Administrado y Medible cuando 
Existe una metodología establecida para la identificación y la evaluación de las soluciones 
de TI y se usa para la mayoría de los proyectos. La documentación de los proyectos es de 
buena calidad y cada etapa se aprueba adecuadamente. Los requerimientos están bien 
articulados y de acuerdo con las estructuras predefinidas. Se consideran soluciones 
alternativas, incluyendo el análisis de costos y beneficios. La metodología es clara, 
definida, generalmente entendida y medible. Existe una interfaz definida de forma clara 
entre la gerencia de TI y la del negocio para la identificación y evaluación de las soluciones 
de TI. 
5 Optimizado cuando 
La metodología para la identificación y evaluación de las soluciones de TI está sujeta a una 
mejora continua. La metodología de adquisición e implantación tiene la flexibilidad para 
proyectos de grande y de pequeña escala. La metodología está soportada en bases de datos 
de conocimiento internas y externas que contienen material de referencia sobre soluciones 
tecnológicas. La metodología en sí misma genera documentación en una estructura 
predefinida que hace que la producción y el mantenimiento sean eficientes. Con frecuencia, 
se identifican nuevas oportunidades de uso de la tecnología para ganar una ventaja 
competitiva, ejercer influencia en la re-ingeniería de los procesos de negocio y mejorar la 
eficiencia en general. La gerencia detecta y toma medidas si las soluciones de TI se 
aprueban sin considerar tecnologías alternativas o los requerimientos funcionales del 
negocio. 
3.4.2.-ADQUIRIR Y MANTENER SOFTWARE APLICATIVO AI2 
3.4.2.1-DESCRIPCIÓN DEL PROCESO 
Las aplicaciones deben estra disponibles de acuerdo con los requerimientos del negocio. 
Este proceso cubre el diseño de las aplicaciones, la inclusión apropiada de controles 
aplicativos y requerimientos de seguridad, y el desarrollo y la configuración en sí de 
acuerdo a los estándares. Esto permite a las organizaciones apoyar la operatividad del 
negocio de forma apropiada.
Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 
43 
3.4.2.2.-OBJETIVOS DE CONTROL 
AI2.1 Diseño de Alto Nivel 
Traducir los requerimientos del negocio a una especificación de diseño de alto nivel para la 
adquisición de software 
Teniendo en cuenta las directivas tecnológicas y la arquitectura de información dentro de la 
organización. Tener aprobada las especificaciones de diseño por gerencia para garantizar 
que el diseño de alto nivel responde a los requerimientos. Reevaluar cuando sucedan 
discrepancias significativas técnicas o lógicas durante el desarrollo o mantenimiento. 
AI2.2 Diseño Detallado 
Preparar el diseño detallado y los requerimientos técnicos del software de aplicación. 
Definir el criterio de aceptación de los requerimientos. Aprobar los requerimientos para 
garantizar que corresponden al diseño de alto nivel. Realizar reevaluaciones cuand sucedan 
discrepancias significativas técnicas o lógicas durante el desarrollo o mantenimiento. 
AI2.3 Control y Posibilidad de Auditar las Aplicaciones 
Implementar controles de negocio, cuando aplique, en controles de aplicación 
automatizados tal que el procedimiento sea exacto, completo, oportuno, autorizado y 
auditable. 
AI2.4 Seguridad y Disponibilidad de las Aplicaciones 
Abordar la seguridad de las aplicaciones y los requerimientos de disponibilidad en 
respuesta a los riesgos identificados y en línea con la clasificación de datos, la arquitectura 
de la información, la arquitectura de seguridad de la información y la tolerancia a riesgos de 
la organización. 
AI2.5 Configuración e Implementación de Software Aplicativo Adquirido
Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 
Configurar e implementar software de aplicaciones adquiridas para conseguir los objetivos 
de negocio. 
44 
AI2.6 Actualizaciones Importantes en Sistemas Existentes 
En caso de cambios importantes a los sistemas existentes que resulten en cambios 
significativos al diseño actual y/o funcionalidad, seguir un proceso de desarrollo similar al 
empleado para el desarrollo de sistemas nuevos. 
AI2.7 Desarrollo de Software Aplicativo 
Garantizar que la funcionalidad de automatización se desarrolla de acuerdo con las 
condiciones de diseño, los estándares de desarrollo y documentación, los requerimientos de 
calidad y estándares de aprobación. Asegurar que todos los aspectos legales y contractuales 
se identifican y direccionan para el software aplicativo desarrollado por terceros. 
AI2.8 Aseguramiento de la Calidad del Software 
Desarrollar, Implementar los recursos y ejecutar un plan de aseguramiento de calidad del 
software, para obtener la calidad que se especifica en la definición de los requerimientos y 
en las políticas y procedimientos de calidad de la organización. 
AI2.9 Administración de los Requerimientos de Aplicaciones 
Seguir el estado de los requerimientos individuales (incluyendo todos los requerimientos 
rechazados) durante el diseño, desarrollo e implementación, y aprobar los cambios a los 
requerimientos a través de un proceso de gestión de cambios establecido. 
AI2.10 Mantenimiento de Software Aplicativo 
Desarrollar una estrategia y un plan para el mantenimiento de aplicaciones de software.
Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 
45 
3.4.2..3.-MODELO DE MADUREZ 
La administración del proceso de Adquirir y mantener software aplicativo que satisfaga 
el requerimiento de negocio de TI de hacer disponibles aplicaciones de acuerdo con los 
requerimientos del negocio, en tiempo y a un costo razonable es: 
0 No Existente cuando 
No existe un proceso de diseño y especificación de aplicaciones. Típicamente, las 
aplicaciones se obtienen con base en ofertas de proveedores, en el reconocimiento de la 
marca o en la familiaridad del personal de TI con productos especificos, considerando poco 
o nada los requerimientos actuales. 
1 Inicial / Ad Hoc cuando 
Existe conciencia de la necesidad de contar con un proceso de adquisición y mantenimiento 
de aplicaciones. Los enfoques para la adquisición y mantenimientos de software aplicativo 
varían de un proyecto a otro. Es probable que se hayan adquirido en forma independiente 
una variedad de soluciones individuales para requerimientos particulares del negocio, 
teniendo como resultado ineficiencias en el mantenimiento y soporte. Se tiene poca 
consideración hacia la seguridad y disponibilidad de la aplicación en el diseño o 
adquisición de software aplicativo. 
2 Repetible pero Intuitivo cuando 
Existen procesos de adquisición y mantenimiento de aplicaciones, con diferencias pero 
similares, en base a la experiencia dentro de la operación de TI. El mantenimiento es a 
menudo problemático y se resiente cuando se pierde el conocimiento interno de la 
organización. Se tiene poca consideración hacia la seguridad y disponibilidad de la 
aplicación en el diseño o adquisición de software aplicativo 
3 Definido cuando 
Existe un proceso claro, definido y de comprensión general para la adquisición y 
mantenimiento de software aplicativos. Este proceso va de acuerdo con la estrategia de TI y 
del negocio. Se intenta aplicar los procesos de manera consistente a traves de diferentes 
aplicaciones y proyectos. Las metodologías son por lo general, inflexibles y difíciles de 
aplicar en todos los casos, por lo que es muy probable que se salten pasos. Las actividades 
de mantenimiento se planean, programan y coordinan 
4 Administrado y Medible cuando 
Existe una metodología formal y bien comprendida que incluye un proceso de diseño y 
especificación, un criterio de adquisición, un proceso de prueba y requerimientos para la 
documentación. Existen mecanismos de aprobación documentados y acordados, para
Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 
garantizar que se sigan todos los pasos y se autoricen las excepciones. Han evolucionado 
prácticas y procedimientos para ajustarlos la medida de la organización, los utilizan todo el 
personal y son apropiados para la mayoría de los requerimientos de aplicación 
46 
5 Optimizado cuando 
Las prácticas de adquisición y mantenimiento de software aplicativo se alinean con el 
proceso definido. El enfoque es con base en componentes, con aplicaciones predefinidas y 
estandarizadas que corresponden a las necesidades del negocio. El enfoque se extiende 
para toda la empresa. La metodología de adquisición y mantenimiento presenta un avance y 
permite un posicionamiento estratégico rápido, que permite un alto grado de reacción y 
flexibilidad para responder a requerimientos cambiantes del negocio. La metodología de 
adquisición e implantación de software aplicativo ha sido sujeta a mejora continua y se 
soporta con bases de datos internos y externas que contienen materiales de referencia y las 
mejores prácticas . 
3.4.3.-ADQUIRIR Y MANTENER INFRAESTRUCTURA TECNOLÓGICA AI3 
3.4..3.1.-DESCRIPCIÓN DEL PROCESO 
Las organizaciones deben contar con procesos para adquirir, implementar y actualizar la 
infraestructura tecnológica. Esto requiere de un enfoque planeado para adquirir, mantener 
y proteger la infraestructura de acuerdo con las estrategias técnológicas convenidas y la 
disposición del ambiente de desarrollo y pruebas.Esto garantiza que exista un soporte 
tecnológico continuo para las aplicaciones del negocio. 
• El número de componentes de infraestructura que ya no se pueden soportar (o 
que ya no se podrán en el futuro cercano)
Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 
47 
3.4.3.2.-OBJETIVOS DE CONTROL 
AI3.1 Plan de Adquisición de Infraestructura Tecnológica 
Generar un plan para adquirir, Implementar y mantener la infraestructura tecnológica que 
satisfaga los requerimientos establecidos funcionales y técnicos del negocio, y que esté de 
acuerdo con la dirección tecnológica de la organización. El plan debe considerar 
extensiones futuras para adiciones de capacidad, costos de transición, riesgos tecnológicos 
y vida útil de la inversión para actualizaciones de tecnología. Evaluar los costos de 
complejidad y la viabilidad comercial del proveedor y el producto al añadir nueva 
capacidad técnica. 
AI3.2 Protección y Disponibilidad del Recurso de Infraestructura 
Implementar medidas de control interno, seguridad y auditabilidad durante la 
configuración, integración y mantenimiento del hardware y del software de la 
infraestructura para proteger los recursos y garantizar su disponibilidad e integridad. Se 
deben definir y comprender claramente las responsabilidades al utilizar componentes de 
infraestructura sensitivos por todos aquellos que desarrollan e integran los componentes de 
infraestructura. Se debe monitorear y evaluar su uso. 
AI3.3 Mantenimiento de la Infraestructura 
Desarrollar una estrategia y un plan de mantenimiento de la infraestructura y garantizar que 
se controlan los cambios, de acuerdo con el procedimiento de administración de cambios de 
la organización. Incluir una revisión periódica contra las necesidades del negocio, 
administración de parches y estrategias de actualización, riesgos, evaluación de 
vulnerabilidades y requerimientos de seguridad. 
AI3.4 Ambiente de Prueba de Factibilidad 
Establecer el ambiente de desarrollo y pruebas para soportar la efectividad y eficiencia de 
las pruebas de factibilidad e integración de aplicaciones e infraestructura, en las primeras 
fases del proceso de adquisición y desarrollo. Hay que considerar la funcionalidad, la 
configuración de hardware y software, pruebas de integración y desempeño, migración 
entre ambientes, control de la versiones, datos y herramientas de prueba y seguridad. 
3.4.3.3.-MODELO DE MADUREZ
Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 
La administración del proceso de Adquirir y mantener infraestructura de tecnología que 
satisfaga el requerimiento de negocio de TI de adquirir y mantener una infraestructura 
de TI integrada y estandarizada es: 
48 
0 No Existente cuando 
No se reconoce la administración de la infraestructura de tecnólogia como un asunto 
importante al cual debe ser resuelto. 
1 Inicial /Ad Hoc cuando 
Se realizan cambios a la infraestructura para cada nueva aplicación, sin ningún plan en 
conjunto. Aunque se tiene la percepción de que la infraestructura de TI es importante, no 
existe un enfoque general consistente. La actividad de mantenimiento reacciona 
anecesidades de corto plazo. El ambiente de producción es el ambiente de prueba. 
2 Repetible pero Intuitivo cuando 
No hay consistencia entre enfoques tácticos al adquirir y dar mantenimiento a la 
infraestructura de TI. La adquisición y mantenimiento de la infraestructura de TI no se basa 
en una estrategia definida y no considera las necesidades de las aplicaciones del negocio 
que se deben respaldar. Se tiene la noción de que la infraestructura de TI es importante, que 
se apoya en algunas prácticas formales. 
Algunos mantenimientos se programan, pero no se programa ni se coordina en su totalidad. 
Para algunos ambientes, existe un ambiente de prueba por separado. 
3 Definido cuando 
Existe un claro, definido y generalmente entendido proceso para adquirir y dar 
mantenimiento a la infraestructura TI. El proceso respalda las necesidades de las 
aplicaciones críticas del negocio y concuerda con la estrategia de negocio de TI, pero no se 
aplica en forma consistente. Se planea, programa y coordina el mantenimiento. Existen 
ambientes separados para prueba y producción. 
4 Administrado y Medible cuando 
Se desarrolla el proceso de adquisición y mantenimiento de la infraestructura de tecnología 
a tal punto que funciona bien para la mayoría de las situaciones, se le da un seguimiento 
consistente y un enfoque hacia la reutilización. La infraestructura de TI soporta 
adecuadamente lasaplicaciones del neg ocio. El proceso está bien organizado y es 
preventivo. Tanto el costo como el tiempo de realización para alcanzar el nivel esperado de 
escalamiento, flexibilidad e integración se han optimizado parcialmente. 
5 Optimizado cuando 
El proceso de adquisición y mantenimiento de la infraestructura de tecnología es preventivo 
y está estrechamente en línea con las aplicaciones críticas del negocio y con la arquitectura 
de la tecnología. Se siguen buenas prácticas respecto a las soluciones de tecnología, y la
Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 
organización tiene concienc ia de las últimas plataformas desarrolladas y herramientas de 
administración. Se reducen costos al racionalizar y estandarizar los componentes de la 
infraestructura y con el uso de la automatización. Con un alto nivel de conciencia se 
pueden identificar los medios óptimos para mejorar el desempeño en forma preventiva, 
incluyendo el consierar la opción de contratar servicios externos . La infraestructura de TI 
se entiende como el apoyo clave para impulsar el uso de TI. 
49 
3.4.4.-FACILITAR LA OPERACIÓN Y EL USO AI4 
3.4.4.1.-DESCRIPCIÓN DEL PROCESO 
El conocimiento sobre los nuevos sistemas debe estar disponible. Este proceso requiere la 
generación de documentación y manuales para usuarios y para TI, y proporciona 
entrenamiento para garantizar el uso y la operación correctos de las aplicaciones y la 
infraestructura. 
3.4.4.2.-OBJETIVOS DE CONTROL 
AI 4.1 Plan para Soluciones de Operación 
Desarrollar un plan para identificar y documentar todos los aspectos técnicos, la capacidad 
de operación y los niveles de servicio requeridos, de manera que todos los interesados 
puedan tomar la responsabilidad oportunamente por la producción de procedimientos de 
administración, de usuarios y operativos, como resultado de la introducción o actualización 
de sistemas automatizados o de infraestructura.
Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 
50 
AI4.2 Transferencia de Conocimiento a la Gerencia del Negocio 
Transferir el conocimiento a la gerencia de la empresa para permitirles tomar posesión del 
sistema y los datos y ejercer la responsabilidad por la entrega y calidad del servicio, del 
control interno y de los procesos administrativos de la aplicación. La transferencia de 
conocimientos incluye la aprobación de acceso, administración de privilegios, segregación 
de tareas, controles automatizados del negocio, respaldo/recuperación, seguridad física y 
archivo de la documentación fuente. 
AI4.3 Transferencia de Conocimiento a Usuarios Finales 
Transferencia de conocimiento y habilidades para permitir que los usuarios finales utilicen 
con efectividad y eficiencia el sistema de aplicación como apoyo a los procesos del 
negocio. La transferencia de conocimiento incluye el desarrollo de un plan de 
entrenamiento que aborde al entrenamiento inicial y al continuo, así como el desarrollo de 
habilidades, materiales de entrenamiento, manuales de usuario, manuales de procedimiento, 
ayuda en línea, asistencia a usuarios, identificación del usuario clave, y evaluación. 
AI4.4 Transferencia de Conocimiento al Personal de Operaciones y Soporte 
Transferir el conocimiento y las habilidades para permitir al personal de soporte técnico y 
de operaciones que entregue, apoyen y mantenga la aplicación y la infraestructura asociada 
de manera efectiva y eficiente de acuerdo a los niveles de servicio requeridos. La 
transferencia del conocimiento debe incluir al entrenamiento inicial y continuo, el 
desarrollo de las habilidades, los materiales de entrenamiento, los manuales de operación, 
los manuales de procedimientos y escenarios de atención al usuario. 
3.4.4.3.-MODELO DE MADUREZ 
La administración del proceso de Facilitar la operación y el uso que satisfaga el 
requerimiento de negocio de TI de garantizar la satisfacción de los usuarios finales con 
ofrecimiento de servicios y niveles de servicio, e integrar de forma transparente 
aplicaciones y soluciones de tecnología dentro de los procesos del negocio es: 
O No Existente cuando 
No existe el proceso con respecto a la producción de documentación de usuario, manuales 
de operación y material de entrenamiento. 
Los únicos materiales existentes son aquellos que se suministran con los productos que se 
adquieren. 
1 Inicial / Ad Hoc cuando 
Existe la percepción de que la documentación de proceso es necesaria. La documentación 
se genera ocasionalmente y se distribuye en forma desigual a grupos limitados. Mucha de la 
documentación y muchos de los procedimientos ya caducaron. Los materiales de
Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 
entrenamiento tienden a ser esquemas únicos con calidad variable. Virtualmente no existen 
procedimientos de integración a través de los diferentes sistemas y unidades de negocio. 
No hay aportes de las unidades de negocio en el diseño de programas de entrenamiento 
51 
2 Repetible pero Intuitivo cuando 
Se utilizan enfoques similares para generar r procedimientos y documentación, pero no se 
basan en un enfoque estructural o marco de trabajo. No hay un enfoque uniforme para el 
desarrollo de procedimientos de usuario y de operación. Individuos o equipos de proyecto 
generan los materiales de entrenamiento, y la calidad depende de los individuos que se 
involucran. Los procedimientos y la calidad del soporte al usuario van desde pobre a muy 
buena, con una consistencia e integración muy pequeña a lo largo de la organización. Se 
proporcionan o facilitan programas de entrenamiento para el negocio y los usuarios, pero 
no hay un plan general para ofrecer o dar entrenamiento. 
3 Definido cuando 
Existe un esquema bien definido, aceptado y comprendido para documentación del usuario, 
manuales de operación y materiales de entrenamiento. . Se guardan y se mantienen los 
procedimientos en una biblioteca formal y cualquiera que necesite saber tiene acceso a 
ellas. Las correcciones a la documentación y a los procedimientos se realizan por reacción. 
Los procedimientos se encuentran disponibles fuera de línea y se pueden acceder y 
mantener en caso de desastre. Existe un proceso que especifica las actualizaciones de 
procedimientos y los materiales de entrenamiento para que sea un entregable explícito de 
un proyecto de cambio. A pesar de la existencia de enfoques definidos, el contenido actual 
varía debido a que no hay un control para reforzar el cumplimiento de estándares. Los 
usuarios se involucran en los procesos informalmente. Cada vez se utilizan más 
herramientas automatizadas en la generación y distribución de procedimientos. Se planea y 
programa tanto el entrenamiento del negocio como de los usuario. 
4 Administrado y Medible cuando 
Existe un esquema definido para los procedimientos de mantenimiento y para los materiales 
de entrenamiento que cuentan con el soporte de la administración de TI. El enfoque 
considerado para los procedimientos de mantenimiento y los manuales de entrenamiento 
cubren todos los sistemas y las unidades de negocio, de manera que se pueden observar los 
procesos desde una perspectiva de negocio.. El desarrollo automatizado de procedimientos 
se integra cada vez más con el desarrollo de sistemas aplicativos, facilitando la consistencia 
y el acceso al usuario. El entrenamiento de negocio y usuario es sensible a las necesidades 
del negocio. La administración de TI está desarrollando medidas para el desarrollo y la 
entrega de documentación, materiales y programas de entrenamiento. 
5 Optimizado cuando 
El proceso para la documentación de usuario y de operación se mejora constantemente con 
la adopción de nuevas herramientas o métodos. Los materiales de procedimientos y de 
entrenamiento se tratan como una base de conocimiento en evolución constante que se
Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 
mantiene en forma electrónica, con el uso de administración de conocimiento actualizada, 
flujo de trabajo y tecnologías de distribución, que los hacen accesibles y fáciles de 
mantener. El material de documentación y entrenamiento se actualiza para reflejar los 
cambios en la organización, en la operación y en el software. Tanto el desarrollo de 
materiales de documentación y entrenamiento como la entrega de programas de 
entrenamiento, se encuentran completamente integrados con el negocio y con las 
definiciones de proceso del negocio, siendo así un apoyo a los requerimientos de toda la 
organización y no tan sólo procedimientos orientados a TI. 
52 
3.4.5.-ADQUIRIR RECURSOS DE TI AI5 
3.4.5.1.-DESCRIPCIÓN DEL PROCESO. 
Se deben suministrar recursos TI, incluyendo personas, hardware, software y servicios. 
Esto requiere de la definición y ejecución de los procedimientos de adquisición, la 
selección de proveedores, el ajuste de arreglos contractuales y la adquisición en sí. El 
hacerlo así garantiza que la organización tenga todos los recursos de TI que se requieren de 
una manera oportuna y rentable. 
3.4.5.2.-OBJETIVOS DE CONTROL
Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 
53 
AI5.1 Control de Adquisición 
Desarrollar y seguir un conjunto de procedimientos y estándares consistentes con el proceso 
general de adquisición de la organización y con la estrategia de adquisición para adquirir 
infraestructura relacionada con TI, instalaciones, hardware, software y servicios necesarios 
por el negocio. 
AI5.2 Administración de Contratos con Proveedores 
Formular procedimiento para establecer, modificar y concluir contratos para todos los 
proveedores. El procedimiento debe cubrir, como mínimo, responsabilidades y obligaciones 
legales, financieras, organizacionales, documentales, de desempeño, de seguridad, de 
propiedad intelectual y responsabilidades de conclusión así como obligaciones (que 
incluyan cláusulas de penalización). Todos los contratos y las modificaciones a contratos 
las deben revisar asesores legales. 
AI5.3 Selección de Proveedores 
Seleccionar proveedores de acuerdo a una práctica justa y formal para garantizar la mejor 
viable y encajable según los requerimientos especificados. Los requerimientos deben estar 
optimizados con las entradas de los proveedores potenciales. 
AI5.4 Adquisición de Recursos de TI 
Proteger y hacer cumplir los intereses de la organización en todo los contratos de 
adquisiciones, incluyendo los derechos y obligaciones de todas las partes en los términos 
contractuales para la adquisición de software, recursos de desarrollo, infraestructura 
servicios. 
3.4.5.3-MODELO DE MADUREZ
Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 
La administración del proceso de Adquirir recursos de TI que satisfaga el requerimiento 
de negocio de TI de mejorar la rentabilidad d TI y su contribución a la utilidad del 
negocio es: 
54 
0 No Existente cuando 
No existe un proceso definido de adquisición de recursos de TI. La organización no 
reconoce la necesidad de tener políticas y procedimientos claros de adquisición para 
garantizar que todos los recursos de TI se encuentren disponibles y de forma oportuna y 
rentable 
1 Inicial / Ad Hoc cuando 
La organización ha reconocido la necesidad de tener políticas y procedimientos 
documentados que enlacen la adquisición de TI con el proceso general de adquisiciones de 
la organización. Los contratos para la adquisición de recursos de TI son elaborados y 
administrados por gerentes de proyecto y otras personas que ejercen su juicio profesional 
más que seguir resultados de procedimientos y políticas formales. Sólo existe un relación 
ad hoc entre los procesos de administración de adquisiciones y contratos corporativos y TI. 
Los contratos de adquisición se administran a la terminación de los proyectos más que 
sobre una base continua. 
2 Repetible pero Intuitivo cuando 
Existe conciencia organizacional de la necesidad de tener políticas y procedimientos 
básicos para la adquisición de TI. Las políticas y procedimientos se integran parcialmente 
con el proceso general de adquisición de la organización del negocio. Los procesos de 
adquisición se utilizan principalmente en proyectos mayores y bastante visibles. 
3 Definido cuando
Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 
La administración establece políticas y procedimientos para la adquisición de TI. Las 
políticas y procedimientos toman como guía el proceso general de adquisición de la 
organización. La adquisición de TI se integra en gran parte con los sistemas generales de 
adquisición del negocio. Existen estándares de TI para la adquisición de recursos de TI. Los 
proveedores de recursos de TI se integran dentro de mecanismos de administración de 
proyectos de la organización desde una perspectiva de administración de contrato. 
La administración de TI comunica la necesidad de contar con una administración adecuada 
de adquisiciones y contratos en toda la función de TI. 
55 
4 Administrado y Medible cuando 
La adquisición de TI se integra totalmente con los sistemas generales de adquisición de la 
organización. Se utilizan los estándares para la adquisición de recursos de TI en todos los 
procesos de adquisición. Se toman medidas para la administración de contratos y 
adquisiciones relevantes para l s casos de negocio que requieran la adquisición de TI. Se 
dispones de reportes que sustentan los objetivos de negocio. La administración de Ti 
implanta el uso de procesos de administración para adquisición y contratos en todas las 
adquisiciones mediante la revisión de medición al desempeño 
5 Optimizado cuando 
La administración instituye y da recursos a procesos exhaustivos para la adquisición de TI. 
La administración impulsa el cumplimiento de las políticas y procedimientos de 
adquisición de TI. Se toman las medidas en la administración de contratos y adquisiciones, 
relevantes en casos de negocio para adquisición de TI. Se establecen buenas relaciones con 
el tiempo con la mayoría de los proveedores y socios, y se mide y vigila la calidad de estas 
relaciones. Se manejan las relaciones en forma estratégica. Los estándares, políticos y 
procedimientos de TI para la adquisición de recursos TI se manejan estratégicamente y 
responden a la medición del proceso. La administración de TI comunica la importancia 
estratégica de tener una administración apropiada de adquisiciones y contratos, a través de 
la función TI. 
3.4.6.-ADMINISTRAR CAMBIOS AI6 
3.4.6.1.-DESCRIPCIÓN DEL PROCESO 
Todos los cambios, incluyendo el mantenimiento de emergencia y parches, relacionados 
con la infraestructura y las aplicaciones dentro del ambiente de producción, deben 
administrarse formalmente y controladamente. Los cambios (incluyendo procedimientos, 
procesos, sistema y parámetros del servicio) se deben registrar, evaluar y autorizar previo a 
la implantación y revisar contra los resultados planeados después de la implementación. . 
Esto garantiza la reducción de riesgos que impactan negativamente la estabilidad o 
integridad del ambiente de producción.
Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 
56 
3.4.6.2.-OBJETIVOS DE CONTROL 
AI6.1 ESTÁNDARES Y PROCEDIMIENTOS PARA CAMBIOS 
Establecer procedimientos de administración de cambio formales para manejar de manera 
estándar todas las solicitudes (incluyendo mantenimiento y parches) para cambios a 
aplicaciones, procedimientos, procesos, parámetros de sistemas y servicio, y las 
plataformas fundamentales. 
AI6.2 EVALUACIÓN DE IMPACTO, PRIORIZACIÓN Y AUTORIZACIÓN.
Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 
Garantizar que todas las solicitudes de cambio se evalúan de una estructurada manera en 
cuanto a impactos en el sistema operacional y su funcionalidad. Esta evaluación deberá 
incluir categorización y priorización de los cambio. Previo a la migración hacia producción, 
los interesados correspondientes autorizan los cambios. 
57 
AI6.3 CAMBIOS DE EMERGENCIA. 
Establecer un proceso para definir, plantear, evaluar y autorizar los cambios de emergencia 
que no sigan el proceso de cambio establecido. La documentación y pruebas se realizan, 
posiblemente, después de la implantación del cambio de emergencia. 
AI6.4 SEGUIMIENTO Y REPORTE DE ESTATUS DE CAMBIO. 
Establecer un sistema de seguimiento y reporte para mantener actualizados a los solicitantes 
de cambio a las aplicaciones, a los procedimientos, a los procesos, parámetros de sistemas y 
del servicio y las plataformas fundamentales. 
AI6.5 CIERRE Y DOCUMENTACIÓN DEL CAMBIO 
Siempre que se implantan cambios al sistema, actualizar el sistema asociado y la 
documentación de usuario y procedimientos correspondientes. Establecer un proceso de 
revisión para garantizar la implantación completa de los cambios. 
3.4.6.3-MODELO DE MADUREZ 
La administración del proceso de Administrar cambios que satisfaga el requerimiento de 
negocio de TI de responder a los requerimientos de acuerdo con la estrategia del 
negocio, mientras que se reducen los defectos y repeticiones de trabajos en la entrega de 
soluciones y servicios es: 
0 NO EXISTENTE CUANDO: 
Un proceso definido de administración de cambio y los cambios se pueden realizar 
virtualmente sin control. No hay conciencia de que el cambio pude causar una interrupción 
para TI y las operaciones del negocio y no hay conciencia de los beneficios de la buena 
administración de cambio. 
1 INICIAL / AD HOC CUANDO: 
Se reconoce que los cambios se deben administrar y controlas. Las prácticas varían y es 
muy probable que se puedan dar cambios sin autorización. Hay documentación de cambio 
pobre o no existente y la documentación de configuración es incompleta y no confiable. 
Es posible que ocurran errores junto con interrupciones al ambiente de producción, 
provocados por una pobre administración de cambios. 
3 DEFINIDO CUANDO:
Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 
Existe un proceso formal definido para la administración del cambio, que incluye la 
categorización, asignación de prioridades, procedimientos de emergencia, autorización del 
cambio y administración de liberación, y va surgiendo el cumplimiento. Se dan soluciones 
temporales a los problemas y los procesos a menudo se omiten o se hacen a un lado. Aún 
pueden ocurrir errores y los cambios no autorizados ocurren ocasionalmente. El análisis de 
impacto de los cambios de TI en operaciones de negocios se está volviendo formal, para 
apoyar la implantación planeada de nuevas aplicaciones y tecnologías. 
58 
4 ADMINISTRADO Y MEDIBLE CUANDO: 
El proceso de administración de cambio se desarrolla bien y es consistente para todos los 
cambios, y la gerencia confía que hay excepciones mínimas. El proceso es eficiente y 
efectivo, pero se basa en manuales de procedimientos y controles considerables para 
garantizar el logro de la calidad. Todos los cambios están sujetos a una planeación 
minuciosa y a la evaluación del impacto para minimizar la probabilidad de tener problemas 
de post-producción. Se da un proceso de aprobación para cambios. La documentación de 
administración de cambios es vigente y correcta, con seguimiento formar a los cambios. La 
documentación de configuración es generalmente exacta. La planeación e implantación de 
la administración de cambios de TI se van integrando con los cambios en los procesos de 
negocio, para asegurar que se resuelven los asuntos referentes al entrenamiento, cambio 
organizacional y continuidad del negocio. Existe una coordinación creciente entre la 
administración de cambio de TI y el rediseño del proceso de negocio. Hay un proceso 
consistente para monitorear la calidad y el desempeño del proceso de administración de 
cambios. 
5 OPTIMIZANDO CUANDO: 
El proceso de administración de cambios se revisa con regularidad y se actualiza para 
permanecer en línea con las buenas prácticas. El proceso de revisión refleja los resultados 
del monitoreo. La información de la configuración es computarizada y proporciona un 
control de versión. El rastreo del cambio es sofisticado e incluye herramientas para detectar 
software no autorizado y sin licencia. La administración de cambio de TI se integra con la 
administración de cambio del negocio para garantizar que TI sea un factor que hace posible 
el incremento de productividad y la creación de nuevas oportunidades de negocio para la 
organización. 
3.4.7.-INSTALAR Y ACREDITAR SOLUCIONES Y CAMBIOS AI7 
3.4.7.1.-DESCRIPCIÓN DEL PROCESO 
Los nuevos sistemas necesitan estar funcionales una vez que su desarrollo se completa. 
Esto requiere pruebas adecuadas en un ambiente dedicado con datos de prueba relevantes, 
para definir la transición e instrucciones de migración, planear la liberación y la transición
Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 
en si al ambiente de producción y revisar la post-implantación. Esto garantiza que los 
sistemas operativos estén en línea con las expectativas convenidas y con los resultados. 
59 
3.4.7.2.-OBJETIVOS DE CONTROL 
AI7.1 ENTRENAMIENTO 
Entrenar al personal de los departamentos de usuario afectados y al grupo de operaciones 
de la función de TI de acuerdo con el plan definido de entrenamiento e implantación y a 
los materiales asociados, como parte de cada proyecto de sistemas de la información de 
desarrollo, implementación o modificación. 
AI7.2 PLAN DE PRUEBA 
Establecer un plan de pruebas basado en los estándares de la organización que define roles, 
responsabilidades, y criterios de entrada y salida. Asegurar que el plan está aprobado por 
las partes relevantes. 
AI7.3 PLAN DE IMPLANTACIÓN 
Establecer un plan de implantación y respaldo y vuelta atrás. Obtener aprobación de las 
partes relevantes. 
AI7.4 AMBIENTE DE PRUEBA 
Definir y establecer un entorno seguro de pruebas representativo del entorno de operaciones 
planeado relativo a seguridad, controles internos, practicas operativos, calidad de los datos 
y requerimientos de privacidad, y cargas de trabajo. 
AI7.5 CONVERSION DE SISTEMAS Y DATOS 
Plan de conversión de datos y migración de infraestructuras como parte de métodos de 
desarrollo de la organización, incluyendo pistas de auditoría, respaldo y vuelta atrás. 
AI7.6 PRUEBA DE CAMBIOS
Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 
Pruebas de cambios independientemente en acuerdo con los planes de pruebas definidos 
antes de la migración al entorno de operaciones. Asegurar que el plan considera la 
seguridad y el desempeño. 
AI7.7 PRUEBA DE ACEPTACIÓN FINAL 
Asegurar que el dueño de proceso de negocio y los interesados de TI evalúan los resultados 
de los procesos de pruebas como determina el plan de pruebas. Remediar los errores 
significativos identificados en el proceso de pruebas, habiendo completado el conjunto de 
pruebas identificadas en el plan de pruebas y cualquier prueba de regresión necesaria. 
Siguiendo la evaluación, aprobación promoción a producción. 
AI7.8 PROMOCIÓN A PRODUCCIÓN 
Seguimiento a pruebas, controlar la entrega de los sistemas cambiados a operaciones, 
manteniéndolo en línea con el plan de implantación. Obtener la aprobación de los 
interesados clave, tales como usuarios, dueño de sistemas y gerente de operaciones. Cuando 
sea apropiado, ejecutar el sistema en paralelo con el viejo sistema por un tiempo, y 
comparar el comportamiento y los resultados. 
AI7.9 REVISIÓN POSTERIOR A LA IMPLANTACIÓN 
Establecer procedimientos en línea con los estándares de gestión de cambios 
organizacionales para requerir una revisión posterior a la implantación como conjunto de 
salida en el plan de implementación. 
60 
3.4.7.3.-MODELO DE MADUREZ 
La administración del proceso de Instalar y acreditar soluciones y cambios que 
satisfagan el requerimiento de negocio de TI de implementar sistemas nuevos o 
modificados que funcionen sin mayores problemas después de su instalación es: 
0 No Existente cuando: 
Hay una ausencia completa de procesos formales de instalación o acreditación y ni la 
gerencia sénior ni el personal de TI reconocen la necesidad de verificar que las soluciones 
se ajustan para el propósito deseado. 
1 Inicial / Ad Hoc cuando: 
Existe la percepción de la necesidad de verificar y confirmar que las soluciones 
implantadas sirven para el propósito esperado. Las pruebas se realizan para algunos 
proyectos, pero la iniciativa de pruebas se deja a los equipos de proyectos particulares y los 
enfoques que se toman varían. La acreditación formal y la autorización son raras o no 
existentes. 
2 Repetible pero Intuitivo cuando: 
Existe cierta consistencia entre los enfoques de prueba y acreditación, pero por lo regular 
no se basan en ninguna metodología. Los equipos individuales de desarrollo deciden 
normalmente el enfoque de prueba y casi siempre hay ausencia de pruebas de integración. 
Hay un proceso de aprobación informal.
Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 
61 
3 Definido cuando: 
Se cuenta con una metodología formal en relación con la instalación, migración, conversión 
y aceptación. Los procesos de TI para instalación y acreditación están integrados dentro del 
ciclo de vida del sistema y están automatizados hasta cierto punto. El entrenamiento, 
pruebas y transición y acreditación a producción tienen muy probablemente variaciones 
respecto al proceso definido, con base en las decisiones individuales. La calidad de los 
sistemas que pasan a producción es inconsistente, y los nuevos sistemas a menudo generan 
un nivel significativo de problemas posteriores a la implantación. 
4 Administrado y Medible cuando: 
Los procedimientos son formales y se desarrollan para ser organizados y prácticos con 
ambientes de prueba definidos y con procedimientos de acreditación. En la práctica, todos 
los cambios mayores de sistemas siguen este enfoque formal. La evaluación de satisfacción 
requerimientos del usuario es estándar y medible, y produce mediciones que la gerencia 
puede revisar y analizar de forma efectiva. 
La calidad de los sistemas que entran en producción es satisfactoria para la gerencia, aún 
con niveles razonables de problemas posteriores a la implantación. La automatización del 
proceso es ad hoc y depende del proyecto. Es posible que la gerencia esté satisfecha con el 
nivel actual de eficiencia a pesar de la ausencia de una evaluación posterior a la 
implementación. El sistema de prueba refleja adecuadamente el ambiente de producción. 
La prueba de stress para los nuevos sistemas y la prueba de regresión para sistemas 
existentes se aplican para proyectos mayores. 
5 Optimizado cuando: 
Los procesos de instalación y acreditación se han refinado a un nivel de buena práctica, con 
base en los resultados de mejora continua y refinamiento. Los procesos de TI para la 
instalación y acreditación están totalmente integrados dentro del ciclo de vida del sistema y 
se automatizan cuando es apropiado, arrojando el estatus más eficiente de entrenamiento, 
pruebas y transición a producción para los nuevos sistemas.
Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 
3.5 Entregar y dar Soporte 
DS1 Definir y administrar los niveles de servicio. 
DS2 Administrar los servicios de terceros 
DS3 Administrar el desempeño y la capacidad 
DS4 Garantizar la continuidad del servicio 
DS5 Garantizar la seguridad de los sistemas 
DS6 Identificar y asignar costos 
DS7 Educar y entrenar a los usuarios 
DS8 Administrar la mesa de servicio y los incidentes 
DS9 Administrar la configuración 
DS10 Administrar los problemas 
DS11 Administrar los datos 
DS12 Administrar el ambiente físico 
DS13 Administrar las operaciones 
3.6 Monitorear y Evaluar 
ME1 Monitorear y Evaluar el Desempeño de TI ME2 Monitorear y Evaluar el Control 
Interno 
ME3 Garantizar el Cumplimiento Regulatorio ME4 Proporcionar Gobierno de TI 
62 
UNIDAD III 
LOS CUATRO DOMINIOS 
Y LOS 34 OBJETIVOS DE 
CONTROL DE COBIT
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final
Cobit 4, trabajo final

Weitere ähnliche Inhalte

Was ist angesagt?

Marcos de referencia en la gestión de servicios de ti
Marcos de referencia en la gestión de servicios de tiMarcos de referencia en la gestión de servicios de ti
Marcos de referencia en la gestión de servicios de tiIshtar Metztli
 
Proceso, modelos y metodos de ingenieria de software
Proceso, modelos y metodos de ingenieria de softwareProceso, modelos y metodos de ingenieria de software
Proceso, modelos y metodos de ingenieria de softwaresergio
 
3. conceptos de calidad del software
3. conceptos de calidad del software3. conceptos de calidad del software
3. conceptos de calidad del softwareJuan Pablo Carvallo
 
CIM 05 - Modelado e Intercambio de Información
CIM 05 - Modelado e Intercambio de InformaciónCIM 05 - Modelado e Intercambio de Información
CIM 05 - Modelado e Intercambio de InformaciónLuis Pedraza
 
Preguntas sobre los sistemas de informacion
Preguntas  sobre los  sistemas de informacionPreguntas  sobre los  sistemas de informacion
Preguntas sobre los sistemas de informacionYajaira Hernandez
 
Aseguramiento de la calidad del software SQA
Aseguramiento de la calidad del software SQAAseguramiento de la calidad del software SQA
Aseguramiento de la calidad del software SQAAnita Ortiz
 
Tabla comparativa ITIL y COBIT
Tabla comparativa ITIL y COBITTabla comparativa ITIL y COBIT
Tabla comparativa ITIL y COBITJoshua Rreal
 
Estándares para gestión de proyectos de ti
Estándares para gestión de proyectos de tiEstándares para gestión de proyectos de ti
Estándares para gestión de proyectos de tiJoannamar
 
Sesión 2: Visión General. El proceso del software
Sesión 2: Visión General. El proceso del softwareSesión 2: Visión General. El proceso del software
Sesión 2: Visión General. El proceso del softwareCoesi Consultoria
 
PERFIL DEL AUDITOR INFORMÁTICO
PERFIL DEL AUDITOR INFORMÁTICOPERFIL DEL AUDITOR INFORMÁTICO
PERFIL DEL AUDITOR INFORMÁTICOivanvelascog
 
Software para auditoría informática
Software para auditoría informáticaSoftware para auditoría informática
Software para auditoría informáticameme694
 

Was ist angesagt? (20)

MeRinde
MeRindeMeRinde
MeRinde
 
Peti Metodologia
Peti MetodologiaPeti Metodologia
Peti Metodologia
 
Como determinar la Capacidad de los Procesos de COBIT 5
Como determinar la Capacidad de los Procesos de COBIT 5Como determinar la Capacidad de los Procesos de COBIT 5
Como determinar la Capacidad de los Procesos de COBIT 5
 
Marcos de referencia en la gestión de servicios de ti
Marcos de referencia en la gestión de servicios de tiMarcos de referencia en la gestión de servicios de ti
Marcos de referencia en la gestión de servicios de ti
 
02 captura de requisitos
02 captura de requisitos02 captura de requisitos
02 captura de requisitos
 
METODOLOGIA RUP
METODOLOGIA RUPMETODOLOGIA RUP
METODOLOGIA RUP
 
METODO WATCH
METODO WATCHMETODO WATCH
METODO WATCH
 
Modelo Cocomo
Modelo CocomoModelo Cocomo
Modelo Cocomo
 
Estimación de Proyectos de Software
Estimación de Proyectos de SoftwareEstimación de Proyectos de Software
Estimación de Proyectos de Software
 
Proceso, modelos y metodos de ingenieria de software
Proceso, modelos y metodos de ingenieria de softwareProceso, modelos y metodos de ingenieria de software
Proceso, modelos y metodos de ingenieria de software
 
3. conceptos de calidad del software
3. conceptos de calidad del software3. conceptos de calidad del software
3. conceptos de calidad del software
 
CIM 05 - Modelado e Intercambio de Información
CIM 05 - Modelado e Intercambio de InformaciónCIM 05 - Modelado e Intercambio de Información
CIM 05 - Modelado e Intercambio de Información
 
Auditoria ITIL
Auditoria ITILAuditoria ITIL
Auditoria ITIL
 
Preguntas sobre los sistemas de informacion
Preguntas  sobre los  sistemas de informacionPreguntas  sobre los  sistemas de informacion
Preguntas sobre los sistemas de informacion
 
Aseguramiento de la calidad del software SQA
Aseguramiento de la calidad del software SQAAseguramiento de la calidad del software SQA
Aseguramiento de la calidad del software SQA
 
Tabla comparativa ITIL y COBIT
Tabla comparativa ITIL y COBITTabla comparativa ITIL y COBIT
Tabla comparativa ITIL y COBIT
 
Estándares para gestión de proyectos de ti
Estándares para gestión de proyectos de tiEstándares para gestión de proyectos de ti
Estándares para gestión de proyectos de ti
 
Sesión 2: Visión General. El proceso del software
Sesión 2: Visión General. El proceso del softwareSesión 2: Visión General. El proceso del software
Sesión 2: Visión General. El proceso del software
 
PERFIL DEL AUDITOR INFORMÁTICO
PERFIL DEL AUDITOR INFORMÁTICOPERFIL DEL AUDITOR INFORMÁTICO
PERFIL DEL AUDITOR INFORMÁTICO
 
Software para auditoría informática
Software para auditoría informáticaSoftware para auditoría informática
Software para auditoría informática
 

Andere mochten auch

Proyecto de auditoría informática aplicando la metodología cobit 4.1
Proyecto de auditoría informática aplicando la metodología cobit 4.1Proyecto de auditoría informática aplicando la metodología cobit 4.1
Proyecto de auditoría informática aplicando la metodología cobit 4.1Luis Angello RH-CyberComputer
 
Trabajo final auditoría
Trabajo final  auditoríaTrabajo final  auditoría
Trabajo final auditoríamitcheljrn
 
Proyecto final de auditoría
Proyecto final de auditoríaProyecto final de auditoría
Proyecto final de auditoríaJuan Jose Flores
 
Cobit planificar y organizar
Cobit planificar y organizarCobit planificar y organizar
Cobit planificar y organizarIsrael Rey
 
EXPOSICION AUDITORIA DE OFIMATICA Y DIRECCION
EXPOSICION AUDITORIA DE OFIMATICA Y DIRECCIONEXPOSICION AUDITORIA DE OFIMATICA Y DIRECCION
EXPOSICION AUDITORIA DE OFIMATICA Y DIRECCIONcarolinanocua
 
Contratación informática Gladys Sobenis
Contratación informática Gladys SobenisContratación informática Gladys Sobenis
Contratación informática Gladys Sobenisgla09
 
COBIT - Auditoría
COBIT - AuditoríaCOBIT - Auditoría
COBIT - AuditoríaEfrain Reyes
 
Valores y Etica del Auditor Informático
Valores y Etica del Auditor InformáticoValores y Etica del Auditor Informático
Valores y Etica del Auditor InformáticoYESLUP
 
TECNICAS DE LA AUDITORIA DEL SISTEMA INFORMATICO
TECNICAS DE LA AUDITORIA DEL SISTEMA INFORMATICOTECNICAS DE LA AUDITORIA DEL SISTEMA INFORMATICO
TECNICAS DE LA AUDITORIA DEL SISTEMA INFORMATICORosa Barba
 
Proyecto Cobit Auditoria
Proyecto  Cobit AuditoriaProyecto  Cobit Auditoria
Proyecto Cobit Auditoriacarloscv
 
Auditoria informatica[1]
Auditoria informatica[1]Auditoria informatica[1]
Auditoria informatica[1]JennyRodrig
 
Auditoria de sistemas informaticos
Auditoria de sistemas informaticosAuditoria de sistemas informaticos
Auditoria de sistemas informaticosLADY ALVEAR
 
Auditoria de sistemas
Auditoria de sistemasAuditoria de sistemas
Auditoria de sistemaslonller123
 
Auditoria informatica pa exponer
Auditoria informatica pa exponerAuditoria informatica pa exponer
Auditoria informatica pa exponerJeampierre Meza
 
Auditoria de la dirección y Auditoria de la Ofimatica
Auditoria de la dirección y Auditoria de la OfimaticaAuditoria de la dirección y Auditoria de la Ofimatica
Auditoria de la dirección y Auditoria de la OfimaticaKarenth M.
 
Cobit dominio planificacion y organizacion
Cobit dominio planificacion y organizacionCobit dominio planificacion y organizacion
Cobit dominio planificacion y organizacioncarlosskovar
 
8. tipos de auditoria en informatica
8.  tipos de  auditoria en informatica8.  tipos de  auditoria en informatica
8. tipos de auditoria en informaticaGemiunivo
 
Auditoria de la ofimatica
Auditoria de la ofimaticaAuditoria de la ofimatica
Auditoria de la ofimaticaManuel Medina
 

Andere mochten auch (20)

Proyecto de auditoría informática aplicando la metodología cobit 4.1
Proyecto de auditoría informática aplicando la metodología cobit 4.1Proyecto de auditoría informática aplicando la metodología cobit 4.1
Proyecto de auditoría informática aplicando la metodología cobit 4.1
 
Trabajo final auditoría
Trabajo final  auditoríaTrabajo final  auditoría
Trabajo final auditoría
 
Proyecto final de auditoría
Proyecto final de auditoríaProyecto final de auditoría
Proyecto final de auditoría
 
Cobit planificar y organizar
Cobit planificar y organizarCobit planificar y organizar
Cobit planificar y organizar
 
Aplicaci{on COBIT
Aplicaci{on COBITAplicaci{on COBIT
Aplicaci{on COBIT
 
EXPOSICION AUDITORIA DE OFIMATICA Y DIRECCION
EXPOSICION AUDITORIA DE OFIMATICA Y DIRECCIONEXPOSICION AUDITORIA DE OFIMATICA Y DIRECCION
EXPOSICION AUDITORIA DE OFIMATICA Y DIRECCION
 
Contratación informática Gladys Sobenis
Contratación informática Gladys SobenisContratación informática Gladys Sobenis
Contratación informática Gladys Sobenis
 
COBIT - Auditoría
COBIT - AuditoríaCOBIT - Auditoría
COBIT - Auditoría
 
Valores y Etica del Auditor Informático
Valores y Etica del Auditor InformáticoValores y Etica del Auditor Informático
Valores y Etica del Auditor Informático
 
TECNICAS DE LA AUDITORIA DEL SISTEMA INFORMATICO
TECNICAS DE LA AUDITORIA DEL SISTEMA INFORMATICOTECNICAS DE LA AUDITORIA DEL SISTEMA INFORMATICO
TECNICAS DE LA AUDITORIA DEL SISTEMA INFORMATICO
 
Proyecto Cobit Auditoria
Proyecto  Cobit AuditoriaProyecto  Cobit Auditoria
Proyecto Cobit Auditoria
 
Auditoria informatica[1]
Auditoria informatica[1]Auditoria informatica[1]
Auditoria informatica[1]
 
Auditoria de sistemas informaticos
Auditoria de sistemas informaticosAuditoria de sistemas informaticos
Auditoria de sistemas informaticos
 
Auditoria de sistemas
Auditoria de sistemasAuditoria de sistemas
Auditoria de sistemas
 
Auditoria informatica pa exponer
Auditoria informatica pa exponerAuditoria informatica pa exponer
Auditoria informatica pa exponer
 
Auditoria de la dirección y Auditoria de la Ofimatica
Auditoria de la dirección y Auditoria de la OfimaticaAuditoria de la dirección y Auditoria de la Ofimatica
Auditoria de la dirección y Auditoria de la Ofimatica
 
Cobit dominio planificacion y organizacion
Cobit dominio planificacion y organizacionCobit dominio planificacion y organizacion
Cobit dominio planificacion y organizacion
 
Auditoria de sistemas
Auditoria de sistemasAuditoria de sistemas
Auditoria de sistemas
 
8. tipos de auditoria en informatica
8.  tipos de  auditoria en informatica8.  tipos de  auditoria en informatica
8. tipos de auditoria en informatica
 
Auditoria de la ofimatica
Auditoria de la ofimaticaAuditoria de la ofimatica
Auditoria de la ofimatica
 

Ähnlich wie Cobit 4, trabajo final

Ähnlich wie Cobit 4, trabajo final (20)

COBIT 4.1
COBIT 4.1COBIT 4.1
COBIT 4.1
 
Cobit 4.1
Cobit 4.1Cobit 4.1
Cobit 4.1
 
Metodología COBIT
Metodología COBITMetodología COBIT
Metodología COBIT
 
Estándares cobit e informe coso
Estándares cobit e  informe cosoEstándares cobit e  informe coso
Estándares cobit e informe coso
 
C O B I T - Sistema de Investigación
C O B I T - Sistema de InvestigaciónC O B I T - Sistema de Investigación
C O B I T - Sistema de Investigación
 
COBIT JASIK
COBIT JASIKCOBIT JASIK
COBIT JASIK
 
Cobit asignacion especial
Cobit asignacion especialCobit asignacion especial
Cobit asignacion especial
 
Cobit 5 informe
Cobit 5 informeCobit 5 informe
Cobit 5 informe
 
Tema de exposicion
Tema de exposicionTema de exposicion
Tema de exposicion
 
Cobit
CobitCobit
Cobit
 
Cobit
CobitCobit
Cobit
 
Capítulo 6 cobit
Capítulo 6 cobit Capítulo 6 cobit
Capítulo 6 cobit
 
Cobit 5
Cobit 5 Cobit 5
Cobit 5
 
Cobit 4.1 resumen
Cobit 4.1 resumenCobit 4.1 resumen
Cobit 4.1 resumen
 
PRESENTACION TRABAJO ASINCRONICO 6.pptx
PRESENTACION TRABAJO ASINCRONICO 6.pptxPRESENTACION TRABAJO ASINCRONICO 6.pptx
PRESENTACION TRABAJO ASINCRONICO 6.pptx
 
PRESENTACION TRABAJO ASINCRONICO 6.pptx
PRESENTACION TRABAJO ASINCRONICO 6.pptxPRESENTACION TRABAJO ASINCRONICO 6.pptx
PRESENTACION TRABAJO ASINCRONICO 6.pptx
 
Cobit
CobitCobit
Cobit
 
Cobit 2(antecedes historia)2
Cobit 2(antecedes historia)2Cobit 2(antecedes historia)2
Cobit 2(antecedes historia)2
 
Cobit 4
Cobit 4Cobit 4
Cobit 4
 
Cobit
CobitCobit
Cobit
 

Kürzlich hochgeladen

21 MARZO DIA INTERNACIONAL DOS BOSQUES.pdf
21 MARZO DIA INTERNACIONAL DOS BOSQUES.pdf21 MARZO DIA INTERNACIONAL DOS BOSQUES.pdf
21 MARZO DIA INTERNACIONAL DOS BOSQUES.pdfceeabarcia
 
1° GRADO UNIDAD DE APRENDIZAJE 0 - 2024.pdf
1° GRADO UNIDAD DE APRENDIZAJE 0 - 2024.pdf1° GRADO UNIDAD DE APRENDIZAJE 0 - 2024.pdf
1° GRADO UNIDAD DE APRENDIZAJE 0 - 2024.pdfdiana593621
 
plan espacios inspiradores para nivel primaria
plan espacios inspiradores para nivel primariaplan espacios inspiradores para nivel primaria
plan espacios inspiradores para nivel primariaElizabeth252489
 
TECNOLOGÍA EDUCATIVA, USO DE LAS TIC.pptx
TECNOLOGÍA EDUCATIVA, USO DE LAS TIC.pptxTECNOLOGÍA EDUCATIVA, USO DE LAS TIC.pptx
TECNOLOGÍA EDUCATIVA, USO DE LAS TIC.pptxFranciscoCruz296518
 
PPT Protocolo de desregulación emocional.pptx
PPT Protocolo de desregulación emocional.pptxPPT Protocolo de desregulación emocional.pptx
PPT Protocolo de desregulación emocional.pptxKarenSepulveda23
 
Xardín de San Carlos (A Coruña) IES Monelos
Xardín de San Carlos (A Coruña) IES MonelosXardín de San Carlos (A Coruña) IES Monelos
Xardín de San Carlos (A Coruña) IES MonelosAgrela Elvixeo
 
Presentación del tema: tecnología educativa
Presentación del tema: tecnología educativaPresentación del tema: tecnología educativa
Presentación del tema: tecnología educativaricardoruizaleman
 
sociales ciencias segundo trimestre tercero
sociales ciencias segundo trimestre tercerosociales ciencias segundo trimestre tercero
sociales ciencias segundo trimestre terceroCEIP TIERRA DE PINARES
 
Herbert James Drape. Erotismo y sensualidad.pptx
Herbert James Drape. Erotismo y sensualidad.pptxHerbert James Drape. Erotismo y sensualidad.pptx
Herbert James Drape. Erotismo y sensualidad.pptxArs Erótica
 
EL ECLIPSE DE LA PAZ (cuento literario). Autor y diseñador JAVIER SOLIS NOYOLA
EL ECLIPSE DE LA PAZ (cuento literario). Autor y diseñador JAVIER SOLIS NOYOLAEL ECLIPSE DE LA PAZ (cuento literario). Autor y diseñador JAVIER SOLIS NOYOLA
EL ECLIPSE DE LA PAZ (cuento literario). Autor y diseñador JAVIER SOLIS NOYOLAJAVIER SOLIS NOYOLA
 
Presentación contribuciones socioeconómicas del SUPV 2023
Presentación contribuciones socioeconómicas del SUPV 2023Presentación contribuciones socioeconómicas del SUPV 2023
Presentación contribuciones socioeconómicas del SUPV 2023Ivie
 
ficha de aplicacion para estudiantes El agua para niños de primaria
ficha de aplicacion para estudiantes El agua para niños de primariaficha de aplicacion para estudiantes El agua para niños de primaria
ficha de aplicacion para estudiantes El agua para niños de primariamichel carlos Capillo Dominguez
 
CARPETA PEDAGÓGICA 2024.docx para educacion
CARPETA PEDAGÓGICA 2024.docx para educacionCARPETA PEDAGÓGICA 2024.docx para educacion
CARPETA PEDAGÓGICA 2024.docx para educacionCarolVigo1
 
SECUENCIA DIDÁCTICA Matemática 1er grado
SECUENCIA  DIDÁCTICA Matemática 1er gradoSECUENCIA  DIDÁCTICA Matemática 1er grado
SECUENCIA DIDÁCTICA Matemática 1er gradoAnaMara883998
 
Tecnología educativa en la era actual .pptx
Tecnología educativa en la era actual .pptxTecnología educativa en la era actual .pptx
Tecnología educativa en la era actual .pptxJulioSantin2
 

Kürzlich hochgeladen (20)

21 MARZO DIA INTERNACIONAL DOS BOSQUES.pdf
21 MARZO DIA INTERNACIONAL DOS BOSQUES.pdf21 MARZO DIA INTERNACIONAL DOS BOSQUES.pdf
21 MARZO DIA INTERNACIONAL DOS BOSQUES.pdf
 
1° GRADO UNIDAD DE APRENDIZAJE 0 - 2024.pdf
1° GRADO UNIDAD DE APRENDIZAJE 0 - 2024.pdf1° GRADO UNIDAD DE APRENDIZAJE 0 - 2024.pdf
1° GRADO UNIDAD DE APRENDIZAJE 0 - 2024.pdf
 
plan espacios inspiradores para nivel primaria
plan espacios inspiradores para nivel primariaplan espacios inspiradores para nivel primaria
plan espacios inspiradores para nivel primaria
 
TECNOLOGÍA EDUCATIVA, USO DE LAS TIC.pptx
TECNOLOGÍA EDUCATIVA, USO DE LAS TIC.pptxTECNOLOGÍA EDUCATIVA, USO DE LAS TIC.pptx
TECNOLOGÍA EDUCATIVA, USO DE LAS TIC.pptx
 
PPT Protocolo de desregulación emocional.pptx
PPT Protocolo de desregulación emocional.pptxPPT Protocolo de desregulación emocional.pptx
PPT Protocolo de desregulación emocional.pptx
 
Conducta ética en investigación científica.pdf
Conducta ética en investigación científica.pdfConducta ética en investigación científica.pdf
Conducta ética en investigación científica.pdf
 
Sesión de clase ES: Adoración sin fin...
Sesión de clase ES: Adoración sin fin...Sesión de clase ES: Adoración sin fin...
Sesión de clase ES: Adoración sin fin...
 
Xardín de San Carlos (A Coruña) IES Monelos
Xardín de San Carlos (A Coruña) IES MonelosXardín de San Carlos (A Coruña) IES Monelos
Xardín de San Carlos (A Coruña) IES Monelos
 
Presentación del tema: tecnología educativa
Presentación del tema: tecnología educativaPresentación del tema: tecnología educativa
Presentación del tema: tecnología educativa
 
Tema 6.- La identidad visual corporativa y el naming.pdf
Tema 6.- La identidad visual corporativa y el naming.pdfTema 6.- La identidad visual corporativa y el naming.pdf
Tema 6.- La identidad visual corporativa y el naming.pdf
 
sociales ciencias segundo trimestre tercero
sociales ciencias segundo trimestre tercerosociales ciencias segundo trimestre tercero
sociales ciencias segundo trimestre tercero
 
Herbert James Drape. Erotismo y sensualidad.pptx
Herbert James Drape. Erotismo y sensualidad.pptxHerbert James Drape. Erotismo y sensualidad.pptx
Herbert James Drape. Erotismo y sensualidad.pptx
 
EL ECLIPSE DE LA PAZ (cuento literario). Autor y diseñador JAVIER SOLIS NOYOLA
EL ECLIPSE DE LA PAZ (cuento literario). Autor y diseñador JAVIER SOLIS NOYOLAEL ECLIPSE DE LA PAZ (cuento literario). Autor y diseñador JAVIER SOLIS NOYOLA
EL ECLIPSE DE LA PAZ (cuento literario). Autor y diseñador JAVIER SOLIS NOYOLA
 
Presentación contribuciones socioeconómicas del SUPV 2023
Presentación contribuciones socioeconómicas del SUPV 2023Presentación contribuciones socioeconómicas del SUPV 2023
Presentación contribuciones socioeconómicas del SUPV 2023
 
Actividad de bienestar docente 2016 Pereira
Actividad de bienestar docente 2016 PereiraActividad de bienestar docente 2016 Pereira
Actividad de bienestar docente 2016 Pereira
 
VISITA DE ESTUDO À CRUZ VERMELHA _
VISITA DE ESTUDO À CRUZ VERMELHA                   _VISITA DE ESTUDO À CRUZ VERMELHA                   _
VISITA DE ESTUDO À CRUZ VERMELHA _
 
ficha de aplicacion para estudiantes El agua para niños de primaria
ficha de aplicacion para estudiantes El agua para niños de primariaficha de aplicacion para estudiantes El agua para niños de primaria
ficha de aplicacion para estudiantes El agua para niños de primaria
 
CARPETA PEDAGÓGICA 2024.docx para educacion
CARPETA PEDAGÓGICA 2024.docx para educacionCARPETA PEDAGÓGICA 2024.docx para educacion
CARPETA PEDAGÓGICA 2024.docx para educacion
 
SECUENCIA DIDÁCTICA Matemática 1er grado
SECUENCIA  DIDÁCTICA Matemática 1er gradoSECUENCIA  DIDÁCTICA Matemática 1er grado
SECUENCIA DIDÁCTICA Matemática 1er grado
 
Tecnología educativa en la era actual .pptx
Tecnología educativa en la era actual .pptxTecnología educativa en la era actual .pptx
Tecnología educativa en la era actual .pptx
 

Cobit 4, trabajo final

  • 1. Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 1 Universidad Central del Ecuador Facultad de Ciencias Administrativas Escuela de Contabilidad y Auditaría Asignatura: Auditoría de Sistemas Informáticos II Tema: Desarrollo del Sílabo y Reactivos Quito - Ecuador
  • 2. Auditoría de Sistemas Informáticos II (Silabo + Reactivos) El presente documento fue realizado, como guía académica y práctica para la Asignatura: “Auditoría de Sistemas Informáticos II”. Este material contiene como anexos los reactivos para su respetiva evaluación, para efectos de enseñanza y aprendizaje con el enfoque a resultados. 2
  • 3. Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 3 INDICE INTRODUCCION …………………………………………… 6 MISION …………………………………………… 7 VISION …………………………………………… 7 OBJETIVO GENERAL …………………………………………… 7 OBJETIVOS ESPECIFICOS …………………………………………… 8 I UNIDAD RESUMEN EJECUTIVO DE COBIT …………………………………………… 9 1. Resumen Ejecutivo de COBIT 1.1 Administración de la información. …………………………………………… 10 1.2 Áreas de enfoque del Gobierno de TI …………………………………………… 11 1.3 Interrelaciones de los componentes …………………………………………… 12 II UNIDAD MARCO DE TRABAJO DE COBIT …………………………………………… 13 Marco de trabajo de control para el Gobierno de TI. Misión de Cobit. 2.1 Principio básico de COBIT …………………………………………… 15 2.2 Criterios de Información …………………………………………… 16 2.3 Metas y negocios y de TI …………………………………………… 17 2.4 Recursos de TI ………………………………………….., 19 2.5 Recursos orientado los procesos de COBIT …………………………………... 20 2.6 Objetivos de Control para los 34 procesos de COBIT …………………………… 31 2.7 Controles generales y de aplicación de TI …………………………………… 34 2.8 Generalidades de los modelos de madurez. …………………………………… 2.9 Modelo del Marco de Trabajo de COBIT. …………………………………… 3.3 Planear y Organizar …………………………………… PO1 Definir un Plan Estratégico de TI …………………………………… PO2 Definir la Arquitectura de la Información …………………………………… PO3 Determinar la Dirección Tecnológic …………………………………… PO4 Definir los Procesos, Organización y Relaciones de TI …………………… PO5 Administrar la Inversión en TI …………………………………………… PO6 Comunicar las Aspiraciones y la Dirección de la Gerencia …………………… PO7 Administrar Recursos Humanos de TI …………………………………………… PO8 Administrar la Calidad …………………………………………… PO9 Evaluar y Administrar los Riesgos de TI …………………………………… PO10 Administrar Proyectos …………………………………………… 3.4 Adquirir e Implementar …………………………………………… AI1 Identificar solucione automatizadas ……………………………………………
  • 4. Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 4 AI2 Adquirir y mantener software aplicativo …………………………… AI3 Adquirir y mantener infraestructura tecnológica …………………………… AI4 Facilitar la operación y el uso …………………………… AI5 Adquirir Recursos de TI …………………………… AI6 Administrar Cambios …………………………… A17 Instalar y acreditar soluciones y cambios …………………………… III UNIDAD 3.5 Entregar y dar Soporte DS1 Definir y administrar los niveles de servicio …………………………… DS2 Administrar los servicios de terceros …………………………… DS3 Administrar el desempeño y la capacidad …………………………… DS4 Garantizar la continuidad del servicio …………………………… DS5 Garantizar la seguridad de los sistemas …………………………… DS6 Identificar y asignar costos …………………………… DS7 Educar y entrenar a los usuarios …………………………… DS8 Administrar la mesa de servicio y los incidentes …………………………… DS9 Administrar la configuración …………………………… DS10 Administrar los problemas …………………………… DS11 Administrar los datos …………………………… DS12 Administrar el ambiente físico …………………………… DS13 Administrar las operaciones …………………………… 3.6 Monitorear y Evaluar …………………………… ME1 Monitorear y Evaluar el Desempeño de TI ME2 Monitorear y Evaluar el Control Interno …………………………… ME3 Garantizar el Cumplimiento Regulatorio ME4 Proporcionar Gobierno de TI …………………………… IV UNIDAD LOS MODELOS DE MADUREZ PARA EL CONTROL INTERNO DE COBIT 4. Modelos de madurez para el Control Interno 4.1 Enlaces de las metas de negocio a procesos de TI …………………………… 4.2 Enlaces de las metas de TI a procesos de TI …………………………… 4.3 Matriz de procesos de TI a Metas de TI …………………………… Mapa de procesos de TI a las áreas focales de Gobierno de TI, COSO, Recursos de TI de COBIT y Criterios de información de COBIT. …………………………… CONCLUSIONES …………………………… RECOMENDACIONES …………………………… COMENTARIO …………………………… GLOSARIO ……………………………
  • 5. Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 5 BIBLIOGRAFIA …………………………… REACTIVOS ……………………………101
  • 6. Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 6 INTRODUCCION El proyecto COBIT se emprendió por primera vez en el año 1995, con el fin de crear un mayor producto global que pudiese tener un impacto duradero sobre el campo de visión de los negocios, así como sobre los controles de los sistemas de información implantados. La primera edición del COBIT, fue publicada en 1996 y fue vendida en 98 países de todo el mundo. La segunda edición, fue publicada en Abril de 1998, desarrolla y mejora lo que poseía la anterior mediante la incorporación de un mayor número de documentos de referencia fundamentales, nuevos y revisados objetivos de control de alto nivel, intensificando las líneas maestras de auditoría, introduciendo un conjunto de herramientas de implementación, así como un CD-ROM completamente organizado el cual contiene la totalidad de los contenidos de esta segunda edición. Una temprana adición significativa visualizada para la familia de productos COBIT, es el desarrollo de las Guías de Gerencia que incluyen Factores Críticos de Éxito, Indicadores Clave de Desempeño y Medidas Comparativas. Los Factores Críticos de Éxito, identificarán los aspectos o acciones más importantes para la administración y poder tomar, así, dichas acciones o considerar los aspectos para lograr control sobre sus procesos de TI. Los Indicadores Clave de Desempeño proporcionarán medidas de éxito que permitirán a la gerencia conocer si un proceso de TI está alcanzando los requerimientos de negocio. La Medidas Comparativas definirán niveles de madurez que pueden ser utilizadas por la gerencia para: determinar el nivel actual de madurez de la empresa; determinar el nivel de madurez que se desea lograr, como una función de sus riesgos y objetivos; y proporcionar una base de comparación de sus prácticas de control de TI contra empresas similares o normas de la industria. Esta adicción, proporcionará herramientas a la gerencia para evaluar el ambiente de TI de su organización con respecto a los 34 Objetivos de Control de alto nivel de COBIT. En definitiva, la organización ISACF, espera que el COBIT sea adoptado por las comunidades de auditoría y negocio como un estándar generalmente aceptado para el control de las Tecnologías de la Información.
  • 7. Auditoría de Sistemas Informáticos II (Silabo + Reactivos) La nueva versión en español del marco referencial COBIT 4.1 de ISACA hace que este conjunto de prácticas generalmente aceptadas en todo el mundo sea más accesible. COBIT 4.1 ayuda a los consejos de administración, ejecutivos y gerentes a aumentar el valor de las TI y reducir los riesgos relacionados. Ampliamente utilizado como una herramienta para el cumplimiento con Sarbanes-Oxley y otros estándares mundiales, COBIT, es anterior a la promulgada legislación sobre el control en todo el mundo. Es producto de más de 15 años de investigación y cooperación entre expertos globales de TI y negocios. La versión en español del marco está disponible como descarga gratuita de la asociación internacional sin fines de lucro ISACA. El enfoque hacia procesos de COBIT se ilustra con un modelo de procesos, el cual subdivide TI en 34 procesos de acuerdo a las áreas de responsabilidad de planear, construir, ejecutar y monitorear, ofreciendo una visión de punta a punta de la TI. Los conceptos de arquitectura empresarial ayudan a identificar aquellos recursos esenciales para el éxito de los procesos, es decir, aplicaciones, información, infraestructura y personas. 7 MISION La misión es "investigar, desarrollar, publicar y promocionar un conjunto de objetivos de control generalmente aceptados para las tecnologías de la información que sean autorizados (dados por alguien con autoridad), actualizados, e internacionales para el uso del día a día de los gestores de negocios (también directivos) y auditores." Gestores, auditores, y usuarios se benefician del desarrollo de COBIT porque les ayuda a entender sus Sistemas de Información (o tecnologías de la información) y decidir el nivel de seguridad y control que es necesario para proteger los activos de sus compañías mediante el desarrollo de un modelo de administración de las tecnologías de la información. VISION Ser el modelo de control para las TI (tecnologías de la información), ayudando a identificar los recursos esenciales para el éxito de los procesos, mediante aplicaciones, información, infraestructura y personas. OBJETIVO GENERAL Buscar, desarrollar, publicar y promover un autoritario y actualizado conjunto internacional de objetivos de control de tecnologías de la información, generalmente aceptadas, para el uso diario por parte de gestores de negocio, que cubren tanto los aspectos de información, como de la tecnología que la respalda. Estos dominios y objetivos de control facilitan que la generación y procesamiento de la información cumplan con las características de efectividad, eficiencia, confidencialidad, integridad, disponibilidad, cumplimiento y confiabilidad. su flexibilidad y versatilidad nos permite adaptarlo a cualquier tipo y tamaño de empresa, realizando una implementación gradual y progresiva acorde a los recursos disponibles y acompasando la estrategia empresarial.
  • 8. Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 8 OBJETIVOS ESPECIFICOS Este dominio cubre la estrategia y las tácticas y se refiere a la identificación de la forma en que la tecnología de información puede contribuir de la mejor manera al logro de los objetivos del negocio. Además, la consecución de la visión estratégica necesita ser planeada, comunicada y administrada desde diferentes perspectivas. Finalmente, deberán establecerse una organización y una infraestructura tecnológica apropiadas. Para llevar a cabo la estrategia de TI, las soluciones de TI deben ser identificadas, desarrolladas o adquiridas, así como implementadas e integradas dentro del proceso del negocio. Además, este dominio cubre los cambios y el mantenimiento realizados a sistemas existentes. El enfoque del control en TI se lleva a cabo visualizando la información necesaria para dar soporte a los procesos de negocio y considerando a la información como el resultado de la aplicación combinada de recursos relacionados con las TI que deben ser administrados por procesos de TI. Buscar, desarrollar, publicar y promover un autoritario y actualizado conjunto internacional de objetivos de control de tecnologías de la información, generalmente aceptadas, para el uso diario por parte de gestores de negocio y auditores. propone un marco de acción donde se evalúan los criterios de información, como por ejemplo la seguridad y calidad, se auditan los recursos que comprenden la tecnología de información, como por ejemplo el recurso humano, instalaciones, sistemas, entre otros, y finalmente se realiza una evaluación sobre los procesos involucrados en la organización.
  • 9. Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 9 UNIDAD I 1. Resumen Ejecutivo de COBIT 1.1 Administración de la información. 1.2 Áreas de enfoque del Gobierno de TI 1.3 Interrelaciones de los componentes
  • 10. Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 10 RESUMEN EJECUTIVO DE COBIT 1. RESUMEN EJECUTIVO DE COBIT 1.1 ADMINISTRACION DE LA INFORMACION La información y la tecnología que las soportan representan sus más valiosos activos, aunque con frecuencia son poco entendidos. Las empresas exitosas reconocen los beneficios de la tecnología de información y la utilizan para impulsar el valor de sus interesados. La necesidad del aseguramiento del valor de TI, la administración de los riesgos asociados a TI, así como el incremento de requerimientos para controlar la información, se entienden ahora como elementos clave del Gobierno Corporativo. El valor, el riesgo y el control constituyen la esencia del gobierno de TI. El gobierno de TI es responsabilidad de los ejecutivos, del consejo de directores y consta de liderazgo, estructuras y procesos organizacionales que garantizan que TI en la empresa sostiene y extiende las estrategias y objetivos organizacionales. Las organizaciones deben satisfacer la calidad, los requerimientos fiduciarios y de seguridad de su información, así como de todos sus activos. La dirección también debe optimizar el uso de los recursos disponibles de TI, incluyendo aplicaciones, información, infraestructura y personas. Para descargar estas responsabilidades, así como para lograr sus objetivos, la dirección debe entender el estatus de su arquitectura empresarial para TI y decidir qué tipo de gobierno y de control debe aplicar. Se muestra algunas preguntas frecuentes y las herramientas gerenciales de información usadas para encontrar las respuestas, aunque estos tableros de crequieren indicadores, los marcadopuntuación requieren mediciones y los Benchmarking requieren una escala de comparación.
  • 11. Auditoría de Sistemas Informáticos II (Silabo + Reactivos) Una respuesta a los requerimientos de determinar y monitorear el nivel apropiado de control y desempeño de TI son las definiciones específicas de COBIT de los siguientes conceptos: • Benchmarking de la capacidad de los procesos de TI, expresada como modelos de madurez, derivados del Modelo de Madurez de la Capacidad del Instituto de Ingeniería de Software • Metas y métricas de los procesos de TI para definir y medir sus resultados y su desempeño, basados en los principios de Balanced Scorecard de Negocio de Robert Kaplan y David Norton • Metas de actividades para controlar estos procesos, con base en los objetivos de control detallados de COBIT 11 1.2 AREAS DE ENFOQUE DEL GOBIERNO DE TI Las áreas de enfoque del gobierno de TI, COSO, recursos TI de COBIT y criterios de información COBIT), ofreciendo así un puente entre lo que los gerentes operativos deben realizar y lo que los ejecutivos desean gobernar. Para lograr un gobierno efectivo, los ejecutivos esperan que los controles a ser implementados por los gerentes operativos se encuentren dentro de un marco de control definido para todo los procesos de TI. Los objetivos de control de TI de COBIT están organizados por proceso de TI; por lo tanto, el marco de trabajo brinda una alineación clara entre los requerimientos de gobierno de TI, los procesos de TI y los controles de TI. Los productos COBIT se han organizado en tres niveles diseñados para dar soporte a: Administración del negocio y de TI Administración y consejos ejecutivos Profesionales en Gobierno, aseguramiento, control y seguridad.
  • 12. Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 12 1.3 INTERRELACIONES DE LOS COMPONENTES Una vez que han sido definidas las metas alineadas, estás requieren ser monitoreadas para garantizar que la entrega cumple con las expectativas. Esto se logra con métricas derivadas de las metas y capturadas en el scorecard de TI. Para que el cliente pueda entender las metas de TI y el scorecard de TI, todos estos objetivos y métricas asociadas deben expresarse en términos de negocio significativos para el cliente. Esto, combinado con un alineamiento efectivo de los objetivos jerárquicos aseguraría que el negocio puede confirmar que es probable que TI soporte los objetivos de la empresa. El apéndice I, Tablas de enlace entre metas y procesos, proporciona una visión global de cómo las metas genéricas de negocio se relacionan con las metas de TI, los procesos de TI y los criterios de la información. Las tablas ayudan a demostrar el ámbito de COBIT y las relaciones completas de negocio entre COBIT y los impulsores de la empresa. La figura 6 ilustra, que estos impulsores vienen del negocio y desde la capa de Gobierno Corporativo, en primer lugar enfocándose más en las funcionalidades y velocidad de la entrega, mas tarde en la relación costo-eficiencia, retorno de inversión (ROI) y cumplimiento.
  • 13. Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 13 UNIDAD II 2. Marco de trabajo de control para el Gobierno de TI. Misión de Cobit. 2.1 Principio básico de COBIT 2.2 Criterios de Información 2.3 Metas y negocios y de TI 2.4 Recursos de TI 2.5 Recursos orientado los procesos de COBIT 2.6 Objetivos de Control para los 34 procesos de COBIT 2.7 Controles generales y de aplicación de TI 2.8 Generalidades de los modelos de madurez. 2.9 Modelo del Marco de Trabajo de COBIT.
  • 14. Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 14 MARCO DE TRABAJO DE COBIT MARCO DE TRABAJO DE CONTROL PARA EL GOBIERNO DE TI. MISION DE COBIT LA NECESIDAD DE UN MARCO DE TRABAJO PARA EL CONTROL DEL GOBIERNO DE TI ¿Por qué utilizar un marco de referencia? Cada vez más, la alta dirección se está dando cuenta del impacto significativo que la información puede tener en el éxito de una empresa. La dirección espera un alto entendimiento de la manera en que la tecnología de información (TI) es operada y de la posibilidad de que sea aprovechada con éxito para tener una ventaja competitiva. En particular, la alta dirección necesita saber si con la información administrada en la empresa es posible que: Garantice el logro de sus objetivos Tenga suficiente flexibilidad para aprender y adaptarse Cuente con un manejo juicioso de los riesgos que enfrenta Reconozca de forma apropiada las oportunidades y actúe de acuerdo a ellas. Alinear la estrategia de TI con la estrategia del negocio Lograr que toda la estrategia de TI, así como las metas fluyan de forma gradual a toda la empresa Proporcionar estructuras organizacionales que faciliten la implementación de estrategias y metas Crear relaciones constructivas y comunicaciones efectivas entre el negocio y TI, y con socios externos Medir el desempeño de TI Las empresas no pueden responder de forma efectiva a estos requerimientos de negocio y de gobierno sin adoptar e implementar un marco de Referencia de gobierno y de control para TI, de tal manera que: Se forme un vínculo con los requerimientos del negocio El desempeño real con respecto a los requerimientos sea transparente Organice sus actividades en un modelo de procesos generalmente aceptado Identifique los principales recursos a ser aprovechados Se definan los objetivos de control Gerenciales a ser considerados D) ¿Quién utiliza las tecnologías de información?
  • 15. Auditoría de Sistemas Informáticos II (Silabo + Reactivos) Un marco de referencia de gobierno y de control requiere servir a una variedad de interesados internos y externos, cada uno de los cuales tiene necesidades específicas: Interesados dentro de la empresa que tengan un interés en generar valor de las inversiones en TI: 15 Aquellos que tomen decisiones de inversiones Aquellos que deciden respecto a los requerimientos Aquellos que utilicen los servicios de TI Interesados internos y externos que proporcionen servicios de TI: Aquellos que administren la organización y los procesos de TI Aquellos que desarrollen capacidades Aquellos que operen los servicios Interesados internos y externos con responsabilidades de control/riesgo: Aquellos con responsabilidades de seguridad, privacidad y/o riesgo Aquellos que realicen funciones de cumplimiento Aquellos que requieran o proporcionen servicios de aseguramiento e) ¿Para que sirve un marco de referencia? Para satisfacer los requerimientos previos, para el gobierno y el control de TI deben satisfacer las siguientes especificaciones generales: Brindar un enfoque de negocios que permita la alineación entre los objetivos de negocio y de TI. Establecer una orientación a procesos para definir el alcance y el grado de cobertura, con una estructura definida que permita una fácil navegación en el contenido. Ser generalmente aceptable al ser consistente con las mejores prácticas y estándares de TI aceptados, y que sea independiente de tecnologías específicas. Proporcionar un lenguaje común, con un juego de términos y definiciones que sean comprensibles en lo general para todos los interesados. Ayudar a satisfacer requerimientos regulatorios, al ser consistente con estándares de gobierno corporativo generalmente aceptados (COSO) y con controles de TI esperados por agentes reguladores y auditores externos. 2.1 PRINCIPIO BASICO DE COBIT El marco de trabajo COBIT se creó con las características principales de ser orientado a negocios, orientado a procesos, basado en controles e impulsado por mediciones.
  • 16. Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 16 2.1.2. Requerimientos de información El control de procesos IT en COBIT satisface los Requerimientos del Negocio, lo que es habilitado por una correcta Declaración de Control; y a su vez es considerado como una correcta Práctica de Control. 2.1.3. Procesos de Tecnologías de Información COBIT clasifica los procesos del negocio relacionados con las Tecnologías de la Información en 4 dominios: Planificación y Organización. Adquisición e Implementación. Entrega y Soporte. Supervisión y Evaluación. 2.1.4. Recursos de Tecnologías de Información Hace a la organización disponer de recursos que son utilizados por los procesos para cubrir los requisitos del negocio: Efectividad (cumplimiento de objetivos). Eficiencia (consecución de los objetivos con el máximo aprovechamiento de los recursos). Confidencialidad. Integridad.
  • 17. Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 17 Disponibilidad. Cumplimiento regulatorio. Fiabilidad. 2.1.5. Criterios de información Para satisfacer los objetivos del negocio, la información necesita adaptarse a ciertos criterios de control, los cuales son referidos en COBIT como requerimientos de información del negocio. Se definieron los siguientes siete criterios de información: La efectividad La eficiencia La confidencialidad La integridad La disponibilidad El cumplimiento La confiabilidad 2.3 METAS Y NEGOCIOS DE LA TECNOLOGIA DE INFORMACIÓN Mientras que los criterios de información proporcionan un método genérico para definir los requerimientos del negocio, la definición de un conjunto de metas genéricas de negocio y de TI ofrece una base más refinada y relacionada con el negocio para el establecimiento de requerimientos de negocio y para el desarrollo de métricas que permitan la medición con respecto a estas metas. Toda empresa usa TI para habilitar iniciativas del negocio y estas pueden ser representadas como metas del negocio para TI. El Apéndice I proporciona una matriz de metas genéricas de negocios y metas de TI y como se asocian con los criterios de la información. Estos ejemplos genéricos se pueden utilizar como guía para determinar los requerimientos, metas y métricas específicas del negocio para la empresa. Si se pretende que TI proporcione servicios de forma exitosa para dar soporte a la estrategia de la empresa, debe existir una propiedad y una dirección clara de los requerimientos por parte del negocio (el cliente) y un claro entendimiento para TI, de cómo y qué debe entregar (el proveedor). La Figura ilustra como la estrategia de la empresa se debe traducir por parte del negocio en objetivos relacionados con iniciativas habilitadas por TI (Las metas de negocio para TI). Estos objetivos a su vez, deben conducir a una clara definición de los propios objetivos de TI (las metas de TI), y luego éstas a su vez definir los recursos y capacidades de TI (la
  • 18. Auditoría de Sistemas Informáticos II (Silabo + Reactivos) arquitectura empresarial para TI) requeridos para ejecutar, de forma exitosa la parte que le corresponde a TI de la estrategia empresarial. Para que el cliente entienda las metas y los Scorecard de TI, todos estos objetivos y sus métricas asociadas se deben expresar en términos de negocio significativos para el cliente, y esto, combinado con una alineación efectiva de la jerarquía de objetivos, asegurará que el negocio pueda confirmar que TI puede, con alta probabilidad, dar soporte a las metas del negocio. Una vez que han sido definidas las metas alineadas, estás requieren ser monitoreadas para garantizar que la entrega cumple con las expectativas. Esto se logra con métricas derivadas de las metas y capturadas en el scorecard de TI. Para que el cliente pueda entender las metas de TI y el scorecard de TI, todos estos objetivos y métricas asociadas deben expresarse en términos de negocio significativos para el cliente. Esto, combinado con un alineamiento efectivo de los objetivos jerárquicos aseguraría que el negocio puede confirmar que es probable que TI soporte los objetivos de la empresa. 18
  • 19. Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 19 2.4 RECURSOS DE TECNOLOGIAS DE INFORMACIÓN La organización de TI se desempeña con respecto a estas metas como un conjunto de procesos definidos con claridad que utiliza lashabilidades de las personas, y la infraestructura de tecnología para ejecutar aplicaciones automatizadas de negocio, mientras que al mismo tiempo toma ventaja de la información del negocio. Estos recursos, junto con los procesos, constituyen una arquitectura empresarial para TI. Para responder a los requerimientos que el negocio tiene hacia Tecnología de Información, la empresa debe invertir en los recursos requeridos para crear una capacidad técnica adecuada Ej., un sistema de planeación de recursos empresariales (ERP) para dar soporte a la capacidad del negocio: Ejemplos: Implementando una cadena de suministro, que genere el resultado deseado (mayores ventas y beneficios financieros) 2.4.1. Los recursos de Tecnología de Información identificados en COBIT se pueden definir como sigue: Las aplicaciones incluyen tanto sistemas de usuario automatizados como procedimientos manuales que procesan información.
  • 20. Auditoría de Sistemas Informáticos II (Silabo + Reactivos) La información son los datos en todas sus formas, de entrada, procesados y generados por los sistemas de información, en cualquier forma en que sean utilizados por el negocio. La infraestructura es la tecnología y las instalaciones (hardware, sistemas operativos, sistemas de administración de base de datos, redes, multimedia, etc., así como el sitio donde se encuentran y el ambiente que los soporta) que permiten el procesamiento de las aplicaciones. Las personas son el personal requerido para planear, organizar, adquirir, implementar, entregar, soportar, monitorear y evaluar los sistemas y los servicios de información. Estas pueden ser internas, por outsourcing o contratadas, de acuerdo a como se requieran. 20 2.5 RECURSOS ORIENTADOS LOS PROCESOS DE COBIT COBIT define las actividades de TI en un modelo genérico de procesos organizado en cuatro dominios. Estos dominios son Planear y Organizar, Adquirir e Implementar, Entregar y Dar Soporte y Monitorear y Evaluar, esto dominios se equiparan a las áreas tradicionales de TI de planear, construir, ejecutar y monitorear. El marco de trabajo de COBIT proporciona un modelo de procesos de referencia y un lenguaje común para que todos en la empresa visualicen y administren las actividades de TI. La incorporación de un modelo operativo y un lenguaje común para todas las partes de un negocio involucradas en TI es uno de los pasos iníciales más importantes hacia un buen gobierno también brinda un marco de trabajo para la medición y monitoreo del desempeño de TI, comunicándose con los proveedores de servicios e integrando las mejores prácticas de administración. Un modelo de procesos fomenta la propiedad de los procesos, permitiendo que se definan las responsabilidades. Para gobernar efectivamente Tecnología de Información, es importante determinar las actividades y los riesgos que requieren ser administrados. Normalmente se ordenan dentro de dominios de responsabilidad de plan, construir, ejecutar y Monitorear. 2.5.1. DOMINIOS DE COBIT  Planear y Organizar (PO) – Proporciona dirección para la entrega de soluciones (AI) y la entrega de servicio (DS).  Adquirir e Implementar (AI) – Proporciona las soluciones y las pasa para convertirlas en servicios.  Entregar y Dar Soporte (DS) – Recibe las soluciones y las hace utilizables por los usuarios finales.
  • 21. Auditoría de Sistemas Informáticos II (Silabo + Reactivos)  Monitorear y Evaluar (ME) -Monitorear todos los procesos para asegurar 21 que se sigue la dirección provista. 2.5.1.1. PLANEAR Y ORGANIZAR (PO) Este dominio cubre las estrategias y las tácticas, y tiene que ver con identificar la manera en que TI puede contribuir de la mejor manera al logro de los objetivos del negocio. Además, la realización de la visión estratégica requiere ser planeada, comunicada y administrada desde diferentes perspectivas. Finalmente, se debe implementar una estructura organizacional y una estructura tecnológica apropiada. Este dominio cubre los siguientes cuestionamientos típicos de la gerencia: ¿Están alineadas las estrategias de TI y del negocio? ¿La empresa está alcanzando un uso óptimo de sus recursos? ¿Entienden todas las personas dentro de la organización los objetivos de TI? ¿Se entienden y administran los riesgos de TI? ¿Es apropiada la calidad de los sistemas de TI para las necesidades del negocio? 2.5.1.2. ADQUIRIR E IMPLEMENTAR (AI) Para llevar a cabo la estrategia de TI, las soluciones de TI necesitan ser identificadas, desarrolladas o adquiridas así como implementadas e integradas en los procesos del negocio además, el cambio y el mantenimiento de los sistemas existentes estácubierto por este dominio para garantizar que las soluciones sigan satisfaciendo los objetivos del negocio. Este dominio, por lo general, cubre los siguientes cuestionamientos de la gerencia: ¿Es probable que los nuevos proyectos generan soluciones que satisfagan las necesidades del negocio?
  • 22. Auditoría de Sistemas Informáticos II (Silabo + Reactivos) ¿Es probable que los nuevos proyectos sean entregados a tiempo y dentro del presupuesto? ¿Trabajarán adecuadamente los nuevos sistemas una vez sean implementados? ¿Los cambios no afectarán a las operaciones actuales del negocio? 22 2.5.1.3. ENTREGAR Y DAR SOPORTE (DS) Este dominio cubre la entrega en sí de los servicios requeridos, lo que incluye la prestación del servicio, la administración de la seguridad y de la continuidad, el soporte del servicio a los usuarios, la administración de los datos y de las instalaciones operativos. Por lo general cubre las siguientes preguntas de la gerencia: ¿Se están entregando los servicios de TI de acuerdo con las prioridades del negocio? ¿Están optimizados los costos de TI? ¿Es capaz la fuerza de trabajo de utilizar los sistemas de TI de manera productiva y segura? ¿Están implantadas de forma adecuada la confidencialidad, la integridad y la disponibilidad? 2.5.1.4. MONITOREAR Y EVALUAR (ME) Todos los procesos de TI deben evaluarse de forma regular en el tiempo en cuanto a su calidad y cumplimiento de los requerimientos de control, este dominio abarca la administración del desempeño, el monitoreo del control interno, el cumplimiento regulatorio y la aplicación del gobierno, por lo general abarca las siguientes preguntas de la gerencia: ¿Se mide el desempeño de TI para detectar los problemas antes de que sea demasiado tarde? ¿La Gerencia garantiza que los controles internos son efectivos y eficientes? ¿Puede vincularse el desempeño de lo que TI ha realizado con las metas del negocio? ¿Se miden y reportan los riesgos, el control, el cumplimiento y el desempeño? A lo largo de estos cuatro dominios, COBIT ha identificado 34 procesos de TI generalmente usados. Mientras la mayoría de las empresas ha definido las responsabilidades de planear, construir, ejecutar y monitorear para TI, y la mayoría tienen los mismos procesos clave, pocas tienen la misma estructura de procesos o le aplicaran todos los 34 procesos de COBIT. COBIT proporciona una lista completa de procesos que puede ser utilizada para verificar que se completan las actividades y responsabilidades; sin embargo, no es necesario que apliquen todas, y, aun más, se pueden combinar como se necesite por cada empresa.
  • 23. Auditoría de Sistemas Informáticos II (Silabo + Reactivos) Para cada uno de estos 34 procesos, tiene un enlace a las metas de negocio y TI que soporta. Información de cómo se pueden medir las metas, también se proporcionan cuáles son sus actividades clave y entregables principales, y quién es el responsable de ellas. 23 2.6 OBJETIVOS DE CONTROL PARA LOS 34 PROCESOS DE COBIT COBIT (Objetivos de control para la información y tecnologías relacionadas) es una metodología publicada en 1996 por el Instituto de Control de TI y la ISACA (Asociación de Auditoría y Control de Sistemas de Información) que se usa para evaluar el departamento de informática de una compañía; en Francia está representada por la AFAI (Asociación Francesa de Auditoría y Consejo de TI). 2.6.1. ENFOQUE DE COBIT Este enfoque se basa en un índice de referencia de procesos, indicadores de objetivos clave e indicadores de rendimiento clave que se usan para controlar los procesos para recoger datos que la compañía puede usar para alcanzar sus objetivos.
  • 24. Auditoría de Sistemas Informáticos II (Silabo + Reactivos) El enfoque COBIT propone 34 procesos organizados en 4 áreas funcionales más grandes que abarcan 318 objetivos: 24 Entrega y asistencia técnica Control Planeamiento y organización Aprendizaje e implementación 2.7 CONTROLES GENERALES Y DE APLICACIÓN DE TI 2.7.1. Los controles generales son aquellos que están inmersos en los procesos y servicios de TI. Algunos ejemplos son: Desarrollo de sistemas Administración de cambios Seguridad Operaciones de cómputo 2.7.2. Los controles incluidos en las aplicaciones de los procesos del negocio se conocen por lo general como controles de aplicación Ejemplos: Integridad (Completitud) Precisión Validez Autorización Segregación de funciones COBIT asume que el diseño e implementación de los controles de aplicación automatizados son responsabilidad de TI, y están cubiertos en el dominio de Adquirir e Implementar, con base en los requerimientos de negocio definidos, usando los criterios de información de COBIT. La responsabilidad operativa de administrar y controlar los controles de aplicación no es de TI, sino del dueño del proceso de negocio. Por lo tanto, la responsabilidad de los controles de aplicación es una responsabilidad conjunta, fin a fin, entre el negocio y TI, pero la naturaleza de la responsabilidad cambia de la siguiente manera: La empresa es responsable de: Definir apropiadamente los requisitos funcionales y de control Uso adecuadamente los servicios automatizados Tecnología de Información es responsable de:
  • 25. Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 25 Automatizar e implementar los requisitos de las funciones de negocio y de control Establecer controles para mantener la integridad de controles de aplicación. Por lo tanto, los procesos de TI de COBIT abarcan a los controles generales de TI, pero sólo los aspectos de desarrollo de los controles de aplicación; la responsabilidad de definir y el uso operativo es de la empresa. 2.7.3. CONTROLES DE COBIT SOBRE LA INFORMACION 2.7.3.1 AC1 Preparación y Autorización de Información Fuente. Asegurar que los documentos fuente están preparados por personal autorizado y calificado siguiendo los procedimientos establecidos, teniendo en cuenta una adecuada segregación de funciones respecto al origen y aprobación de estos documentos. Los errores y omisiones pueden ser minimizados a través de buenos diseños de formularios de entrada. Detectar errores e irregularidades para que sean informados y corregidos. 2.7.3.2. AC2 Recolección y Entrada de Información Fuente. Establecer que la entrada de datos se realice en forma oportuna por personal calificado y autorizado. Las correcciones y reenvíos de los datos que fueron erróneamente ingresados se deben realizar sin comprometer los niveles de autorización de las transacciones originales.
  • 26. Auditoría de Sistemas Informáticos II (Silabo + Reactivos) En donde sea apropiado para reconstrucción, retener los documentos fuentes originales durante el tiempo necesario. 2.7.3.3. AC3 Chequeos de Exactitud, Integridad y Autenticidad Asegurar que las transacciones son exactas, completas y válidas. Validar los datos ingresados, y editar o devolver para corregir, tan cerca del punto de origen como sea posible. 2.7.3.4 AC4 Integridad y Validez del Procesamiento Mantener la integridad y validación de los datos a través del ciclo de procesamiento. Detección de transacciones erróneas no interrumpe le procesamiento de transacciones validas. 2.7.3.5. AC5 Revisión de Salidas, Reconciliación y Manejo de Errores Establecer procedimientos y responsabilidades asociadas para asegurar que la salida se maneja de una forma autorizada, entregada al destinatario apropiado, y protegida durante la transmisión; que se verifica, detecta y corrige la exactitud de la salida; y que se usa la información proporcionada en la salida. 2.7.3.6. AC6 Autenticación e Integridad de Transacciones Antes de pasar datos de la transacción entre aplicaciones internas y funciones de negocio/operativas (dentro o fuera de la empresa), verificar el apropiado direccionamiento, autenticidad del origen e integridad del contenido. Mantener la autenticidad y la integridad durante la transmisión o el transporte. 26 2.8 GENERALIDADES DE LOS MODELOS DE MADUREZ. 2.8.1. Nuevo modelo de madurez Es un modelo de Madurez que permite el mejoramiento del desarrollo de productos y servicios, consiste en un conjunto de las mejores prácticas que cubre el ciclo de vida de un producto Es una forma de medir la madurez de los procesos a través del “Process Capability Model”, basado en el estándar internacionalmente reconocido “ISO/IEC 15504 Software Engineering – ProcessAssessment Standard”, diferente en su diseño y uso al modelo de madurez que incluía COBIT 4.1. La nueva versión de COBIT tomará precisamente el modelo de madurez definido por ISO en la norma ISO/IEC 15504 más conocida como SPICE (Software Process Improvement Capability Determinatorio. 2.8.2. Los niveles definidos en el modelo SPICE son los siguientes: Nivel 0: Incompleto Nivel 1: Realizado Nivel 2: Gestionado
  • 27. Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 27 Nivel 3: Establecido Nivel 4: Predecible Nivel 5: Optimizado Nivel Características Área Clave del Proceso Optimizado (5) Capacidad de Mejoramiento Continuo. - Proceso de Gestión de Cambio. - Innovación Tecnológica. - Prevención de Fallas. Administrado (4) Planeación de la calidad del producto y seguimiento de las mediciones del proceso de producción del software - Gestión de Calidad del Software. - Gestión cuantitativa del proceso de generación del software. Definido (3) Proceso de Ciclo de Vida definido e institucionalizado para proveer control de calidad - Revisión Pares (Colegas). Coordinación inter-grupos Aplicación de la Ingeniería de Software Software para la gestión del desarrollo Programa de capacitación Definición de la organización del proceso Foco en la organización del proceso Repetible (2) Supervisión de la gestión y seguimiento del proyecto Planificación formal Gestión de la configuración del software Control de Calidad del software Gestión de los desarrollos subcontratados Supervisión y seguimiento de la ejecución del proyecto de software Planificación formal del proyecto de software Gestión de requerimientos Inicial Ad-hoc (impredecible, caótico) – Este modelo ayuda a la gerencia de TI a buscar por medio de benchmarking y herramientas de auto-evaluación respuesta a la necesidad de saber qué hacer de manera eficiente. Comenzando con los procesos y los objetivos de control de alto nivel de COBIT, el
  • 28. Auditoría de Sistemas Informáticos II (Silabo + Reactivos) propietario del proceso se debe poder evaluar de forma progresiva, contra los objetivos de control. 28 2.8.3 DIFERENCIAS DE ESTE NUEVO MODELO Al estar basado en ISO/IEC 15504 es más exigente respecto a lo que debe cumplir cada proceso para ascender de nivel, dado que este estándar plantear que se deben cumplir los 9 atributos definidos para cada proceso, como requisito para acreditar dicho grado de madurez. Una evaluación realizada bajo este nuevo modelo no es comparable y no puede ser mezclada con evaluaciones realizadas bajo el modelo de COBIT 4.1, dado que se distorsionarían los resultados por ser distintas las exigencias. Generalmente, aplicando este modelo de COBIT 5, deberían dar resultados de niveles más bajos de madurez. A continuación, se expone el mapeo oficial de ISACA entre ambos modelos de madurez: COMPARACIÓN ENTRE AMBOS MODELOS DE MADUREZ
  • 29. Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 29 2.9 MODELO DEL MARCO DE TRABAJO DE COBIT. El marco de trabajo de COBIT, por tanto, relaciona los requerimientos de la información y de gobierno a los objetivos de la función de servicios TI. Para resumir, los recursos de TI son manejados por procesos de TI para lograr metas de TI que respondan a los requerimientos del negocio, dn detalle, el marco de trabajo general de COBIT está compuesto de cuatro dominios que contienen 34 procesos genéricos, administrando los recursos de TI para proporcionar información al negocio de acuerdo con los requerimientos del negocio y de gobierno. 2.9.1. COMO SATISFACE COBIT LA NECESIDAD DE CONTROL DE LAS TI Como respuesta a las necesidades descritas en la sección anterior, el marco de trabajo COBIT se creó con las características principales de ser orientado a negocios, orientado a procesos, basado en controles e impulsado por mediciones a la orientación a negocios es el tema principal de COBIT. Está diseñado para ser utilizado no solo por proveedores de servicios, usuarios y auditores de TI, sino también y principalmente, como guía integral para la gerencia y para los propietarios de los procesos de negocio. Proporcionar la información que la empresa requiere para lograr sus objetivos, la empresa necesita administrar y controlar los recursos de TI usando un conjunto estructurado d me procesos que ofrezcan los servicios requeridos de información.El marco de trabajo COBIT ofrece herramientas para garantizar la alineación con los requerimientos del negocio.
  • 30. Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 30 3.3 PLANEAR Y ORGANIZAR PO1 DEFINIR UN PLAN ESTRATÉGICO DE TI PLAN ESTRATÉGICO DE TI Definición: Es necesaria para Gestionar y dirigir todos los Recursos de TI en línea Con la estrategia y Prioridades del negocio. Objetivos: 1. Administración del valor de TI
  • 31. Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 31 2. Alineación de TI con el negocio 3. Evaluación del desempeño y la Capacidad actual. 4.Plan estratégico 5. Planes tácticos 6. Administración del portafolio de TI MODELO DE MADUREZ Inicial: Cuando se conoce la necesidad de una Planeación estratégica. Repetible: Cuando ocurren respuestas a las solicitudes de la información. Definido : Cuando se sigue un enfoque que garantiza la facilidad de la planeación Administrado: Se define con responsabilidades de alto nivel. Optimizado: Se toma en cuenta el establecimiento de las metas del negocio. PO2 DEFINIR LA ARQUITECTURA DE LA INFORMACION. OBJETIVOS Modelo de arquitectura de información empresarial Diccionario de Datos empresarial y reglas de sintaxis de datos Esquema de clasificación de datos Administración de integridad MODELO DE MADUREZ Inicial: Cuando se reconoce la necesidad de una arquitectura de información. Repetible: Cuando existen procedimientos similares que siguen los individuos Definido : Se acepta la responsabilidad en la aplicación en la cual se comunicara Administrado: Se otorga el soporte completo al desarrollo de implantación por medio de técnicas. Optimizado: El personal de TI tiene la experiencia y habilidades necesarias para desarrollar.
  • 32. Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 32 PO3- DETERMINAR LA DIRECCIÓN TECNOLÓGICA. Objetivos de Control Planeación de la dirección tecnológica. Plan de infraestructura tecnológica. Monitoreo de tendencias y regulaciones futuras. Estándares tecnológicos. Consejo de arquitectura de TI. Modelo de Madurez No existe: No existe conciencia sobre la importancia de la planeación de la infraestructura tecnológica para la entidad. Inicia: Cuando la gerencia reconoce la necesidad de planear la infraestructura tecnológica. Repetible: Se difunde la necesidad e importancia de la planeación tecnológica. Definido: Cuando la gerencia está consciente de la importancia del plan de infraestructura tecnología. Administrado : La dirección garantiza el desarrollo del plan de infraestructura tecnológica Optimizado: La dirección del plan de infraestructura esta impulsada en los estándares de avances industriales e internacionales. PO4- DEFINIR LOS PROCESOS, ORGANIZACIÓN Y RELACIONES TI. Agiliza la respuesta a las estrategias del negocio mientras se cumplan los requerimientos del gobierno.
  • 33. Auditoría de Sistemas Informáticos II (Silabo + Reactivos) Enfocado al El establecimiento de estructuras organizacionales de TI transparentes, flexibles y responsables y en la definición e implementación de procesos de TI. Se logra con la definición de un marco de trabajo de procesos de TI. El establecimiento de un cuerpo y una estructura organizacional apropiada. La definición de roles y responsabilidades Se mide con el porcentaje de roles con descripciones de puestos. El número de procesos de negocio que no reciben soporte de TI y que deberían de recibirlo. Número de actividades clave de TI que no son aprobadas. 33 Objetivos de Control PO4 Marco de trabajo de proceso de TI. Comité estratégico de Ti. Comité directivo de TI. Ubicación organizacional de la función de TI. Estructura organizacional. Establecimiento de roles y responsabilidades. Responsabilidades de aseguramiento de calidad de TI. Responsabilidad sobre el riesgo, la seguridad y el cumplimiento. Propiedad de datos y de sistemas. Supervisión. Segregación de funciones. Personal de TI. Personal clave de TI. Políticas y procedimientos para personal contratado. Relaciones. PO5. ADMINISTRAR LA INVERSION EN TI Establece y mantiene un marco de trabajo Para administrar los programas de inversión en TI SE LOGRA El pronostico de presupuestos Definición de criterios formales Medición del valor del negocio SE MIDE Porcentaje de reducción en el costo unitario Porcentaje de l valor
  • 34. Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 34 Porcentaje de gasto OBJETIVOS DE CONTROL Marco de trabajo Para la administración financiera Prioridades dentro del presupuesto de TI Proceso presupuestal Administración de costos de TI Administración de beneficios MODELO DE MADUREZ P06.COMUNICAR LAS ASPIRACIONES Y LA DIRECCION DE LA GERENCIA Se debe implementar un programa de comunicación continua para dar a conocer la misión, los objetivos de servicio, políticas y procedimientos aprobados y apoyados por la dirección SE LOGRA CON Definición de marco de trabajo. Elaboración e implantación de politicas El refuerzo de políticas SE MIDE Optimizado no existente Inicia l Definido Repetible Administrado
  • 35. Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 35 Numero de interrupciones en el negocio Porcentaje de interesados Porcentaje de interesados que no cumplen las políticas. OBJETIVOS DE CONTROL 1. Ambiente de políticas y de control 2. Riesgo corporativo 3. Administracion de políticas para TI 4. Implantacion de políticas de TI 5. Comunicacion de los objetivos MODELO DE MADUREZ P07 ADMINISTRAR LOS RECURSOS HUMANOS DE TI OBJETIVOS Reclutamiento y Retención Asignación de Roles Dependencia sobre individuos Evaluacion del Desempeño Cambios y Terminación del trabajo Procedimientos de investigacion del personal Entramiento del Personal de TI
  • 36. Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 36 Competencias del Personal MODELO DE MADUREZ PO8 ADMINISTRAR LA CALIDAD OBJETIVOS SISTEMA DE ADMINISTRACION DE CALIDAD ESTÁNDARES Y PRÁCTICAS DE CALIDAD ESTÁNDARES DE DESARROLLO Y DE ADQUISICION ENFOQUE EN EL CLIENTE DE TI MEJORA CONTINUA MEDICION, MONITOREO Y REVISION DE LA CALIDAD MODELO DE MADUREZ
  • 37. Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 37 P09. EVALUAR Y ADMINISTRAR LOS RIESGOS DE TI Responsabilidad de la Administración Tratamiento idóneop/responder adecuadamente Evaluar, documentar y dar mantenimiento Analizar y comunicar los riesgos de TI PLANEAR Y ORGANIZAR PO9 OBJETIVOS DE CONTROL
  • 38. Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 38 PO10 ADMINISTRACIÓN DE PROYECTOS Coordinación de todos los proyectos y Programas de TI que se han establecido Incluir un Plan Maestro de Recursos Asegurar y Garantizar la Calidad y Definición de un Plan Formal Garantiza a la Administración de los Posibles Riesgos del Proyecto y la Entrega de Valor para el Negocio. PO10 OBJETIVOS DE CONTROL MODELO DE MADUREZ No Existente: La mala administración de los proyectos y con las fallas de desarrollo en el proyecto. 1 Inicial / Ad Hoc : Existe una carencia de compromiso y Administración por parte de la gerencia. 2 Repetible: La organización está en proceso de Desarrollar y utilizar algunas técnicas y métodos proyecto por proyecto. 3 Definido: Se establece una oficina de admón de proyectos dentro de TI, con roles y responsabilidades iniciales definidas.
  • 39. Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 4 Administrado y Medible: La administración de proyectos se mide y evalúa a través de la organización y no sólo en TI. 5 Optimizado: Se ha definido e implantado una estrategia de TI para contratar el desarrollo y los proyectos operativos. 39 3.4 ADQUIRIR E IMPLEMENTAR 3.4.1 .-IDENTIFICAR SOLUCIONES AUTOMATIZADAS AI1 3.4.1.1.- DESCRIPCIÓN DEL PROCESO. La necesidad de una nueva aplicación o función requiere de análisis antes de la compra o desarrollo para garantizar que los requisitos del negocio se satisfacen con un enfoque efectivo y eficiente. Este proceso cubre la definición de las necesidades, considera las fuentes alternativas, realiza una revisión de la factibilidad tecnológica y económica, ejecuta un análisis de riesgo y de costo-beneficio y concluye con una decisión final de “desarrollar” o “comprar”. Todos estos pasos permiten a las organizaciones minimizar el costo para Adquirir e Implementar soluciones, mientras que al mismo tiempo facilitan el logro de los objetivos del negocio.
  • 40. Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 40 3.4.1.2.- OBJETIVOS DE CONTROL AI1.1 Definición y Mantenimiento de los Requerimientos Técnicos y Funcionales del Negocio Identificar, dar prioridades, especificar y acordar los requerimientos de negocio funcionales y técnicos que cubran el alcance completo de todas las iniciativas requeridas para lograr los resultados esperados de los programas de inversión en TI. AI1.2 Reporte de Análisis de Riesgos Identificar, documentar y analizar los riesgos asociados con los requerimientos del negocio y diseño de soluciones como parte de los procesos organizacionales para el desarrollo de los requerimientos. AI1.3 Estudio de Factibilidad y Formulación de Cursos de Acción Alternativos Desarrollar un estudio de factibilidad que examine la posibilidad de Implementar los requerimientos. La administración del negocio, apoyada por la función de TI, debe evaluar la factibilidad y los cursos alternativos de acción y realizar recomendaciones al patrocinador del negocio. AI1.4 Requerimientos, Decisión de Factibilidad y Aprobación Verificar que el proceso requiere al patrocinador del negocio para aprobar y autoriza los requisitos de negocio, tanto funcionales como técnicos, y los reportes del estudio de
  • 41. Auditoría de Sistemas Informáticos II (Silabo + Reactivos) factibilidad en las etapas clave predeterminadas. El patrocinador del negocio tiene la decisión final con respecto a la elección de la solución y al enfoque de adquisición. 41 3.4.1.3.- MODELO DE MADUREZ La administración del proceso de Identificar soluciones automatizadas que satisfaga el requerimiento de negocio de TI de traducir los requerimientos funcionales y de control del negocio a diseño efectivo y eficiente de soluciones automatizadas es: 0 No Existente cuando La organización no requiere de la identificación de los requerimientos funcionales y operativos para el desarrollo, implementación o modificación de soluciones, tales como sistemas, servicios, infraestructura y datos. La organización no está consciente de las soluciones tecnológicas disponibles que son potencialmente relevantes para su negocio. 1 Inicial / Ad Hoc cuando Existe conciencia de la necesidad de definir requerimientos y de identificar soluciones tecnológicas. Grupos individuales se reúnen para analizar las necesidades de manera informal y los requerimientos se documentan algunas veces. Los individuos identifican soluciones con base en una conciencia limitada de mercado o como respuesta a ofertas de proveedores. Existe una investigación o análisis estructurado mínimo de la tecnología disponible 2 Repetible pero Intuitivo cuando Existen algunos enfoques intuitivos para identificar que existen soluciones de TI y éstos varían a lo largo del negocio. Las soluciones se identifican de manera informal con base en la experiencia interna y en el conocimiento de la función de TI. El éxito de cada proyecto depende de la experiencia de unos cuantos individuos clave. La calidad de la documentación y de la toma de decisiones varía de forma considerable. Se usan enfoques no estructurados para definir los requerimientos e identificar las soluciones tecnológicas. 3 Definido cuando Existen enfoques claros y estructurados para determinar las soluciones de TI. El enfoque para la determinación de las soluciones de TI requiere la consideración de alternativas evaluadas contra los requerimientos del negocio o del usuario, las oportunidades tecnológicas, la factibilidad económica, las evaluaciones de riesgo y otros factores. El proceso para determinar las soluciones de TI se aplica para algunos proyectos con base en factores tales como las decisiones tomadas por el personal involucrado, la cantidad de tiempo administrativo dedicado, y el tamaño y prioridad del requerimiento de negocio
  • 42. Auditoría de Sistemas Informáticos II (Silabo + Reactivos) original. Se usan enfoques estructurados para definir requerimientos e identificar soluciones de TI. 42 4 Administrado y Medible cuando Existe una metodología establecida para la identificación y la evaluación de las soluciones de TI y se usa para la mayoría de los proyectos. La documentación de los proyectos es de buena calidad y cada etapa se aprueba adecuadamente. Los requerimientos están bien articulados y de acuerdo con las estructuras predefinidas. Se consideran soluciones alternativas, incluyendo el análisis de costos y beneficios. La metodología es clara, definida, generalmente entendida y medible. Existe una interfaz definida de forma clara entre la gerencia de TI y la del negocio para la identificación y evaluación de las soluciones de TI. 5 Optimizado cuando La metodología para la identificación y evaluación de las soluciones de TI está sujeta a una mejora continua. La metodología de adquisición e implantación tiene la flexibilidad para proyectos de grande y de pequeña escala. La metodología está soportada en bases de datos de conocimiento internas y externas que contienen material de referencia sobre soluciones tecnológicas. La metodología en sí misma genera documentación en una estructura predefinida que hace que la producción y el mantenimiento sean eficientes. Con frecuencia, se identifican nuevas oportunidades de uso de la tecnología para ganar una ventaja competitiva, ejercer influencia en la re-ingeniería de los procesos de negocio y mejorar la eficiencia en general. La gerencia detecta y toma medidas si las soluciones de TI se aprueban sin considerar tecnologías alternativas o los requerimientos funcionales del negocio. 3.4.2.-ADQUIRIR Y MANTENER SOFTWARE APLICATIVO AI2 3.4.2.1-DESCRIPCIÓN DEL PROCESO Las aplicaciones deben estra disponibles de acuerdo con los requerimientos del negocio. Este proceso cubre el diseño de las aplicaciones, la inclusión apropiada de controles aplicativos y requerimientos de seguridad, y el desarrollo y la configuración en sí de acuerdo a los estándares. Esto permite a las organizaciones apoyar la operatividad del negocio de forma apropiada.
  • 43. Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 43 3.4.2.2.-OBJETIVOS DE CONTROL AI2.1 Diseño de Alto Nivel Traducir los requerimientos del negocio a una especificación de diseño de alto nivel para la adquisición de software Teniendo en cuenta las directivas tecnológicas y la arquitectura de información dentro de la organización. Tener aprobada las especificaciones de diseño por gerencia para garantizar que el diseño de alto nivel responde a los requerimientos. Reevaluar cuando sucedan discrepancias significativas técnicas o lógicas durante el desarrollo o mantenimiento. AI2.2 Diseño Detallado Preparar el diseño detallado y los requerimientos técnicos del software de aplicación. Definir el criterio de aceptación de los requerimientos. Aprobar los requerimientos para garantizar que corresponden al diseño de alto nivel. Realizar reevaluaciones cuand sucedan discrepancias significativas técnicas o lógicas durante el desarrollo o mantenimiento. AI2.3 Control y Posibilidad de Auditar las Aplicaciones Implementar controles de negocio, cuando aplique, en controles de aplicación automatizados tal que el procedimiento sea exacto, completo, oportuno, autorizado y auditable. AI2.4 Seguridad y Disponibilidad de las Aplicaciones Abordar la seguridad de las aplicaciones y los requerimientos de disponibilidad en respuesta a los riesgos identificados y en línea con la clasificación de datos, la arquitectura de la información, la arquitectura de seguridad de la información y la tolerancia a riesgos de la organización. AI2.5 Configuración e Implementación de Software Aplicativo Adquirido
  • 44. Auditoría de Sistemas Informáticos II (Silabo + Reactivos) Configurar e implementar software de aplicaciones adquiridas para conseguir los objetivos de negocio. 44 AI2.6 Actualizaciones Importantes en Sistemas Existentes En caso de cambios importantes a los sistemas existentes que resulten en cambios significativos al diseño actual y/o funcionalidad, seguir un proceso de desarrollo similar al empleado para el desarrollo de sistemas nuevos. AI2.7 Desarrollo de Software Aplicativo Garantizar que la funcionalidad de automatización se desarrolla de acuerdo con las condiciones de diseño, los estándares de desarrollo y documentación, los requerimientos de calidad y estándares de aprobación. Asegurar que todos los aspectos legales y contractuales se identifican y direccionan para el software aplicativo desarrollado por terceros. AI2.8 Aseguramiento de la Calidad del Software Desarrollar, Implementar los recursos y ejecutar un plan de aseguramiento de calidad del software, para obtener la calidad que se especifica en la definición de los requerimientos y en las políticas y procedimientos de calidad de la organización. AI2.9 Administración de los Requerimientos de Aplicaciones Seguir el estado de los requerimientos individuales (incluyendo todos los requerimientos rechazados) durante el diseño, desarrollo e implementación, y aprobar los cambios a los requerimientos a través de un proceso de gestión de cambios establecido. AI2.10 Mantenimiento de Software Aplicativo Desarrollar una estrategia y un plan para el mantenimiento de aplicaciones de software.
  • 45. Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 45 3.4.2..3.-MODELO DE MADUREZ La administración del proceso de Adquirir y mantener software aplicativo que satisfaga el requerimiento de negocio de TI de hacer disponibles aplicaciones de acuerdo con los requerimientos del negocio, en tiempo y a un costo razonable es: 0 No Existente cuando No existe un proceso de diseño y especificación de aplicaciones. Típicamente, las aplicaciones se obtienen con base en ofertas de proveedores, en el reconocimiento de la marca o en la familiaridad del personal de TI con productos especificos, considerando poco o nada los requerimientos actuales. 1 Inicial / Ad Hoc cuando Existe conciencia de la necesidad de contar con un proceso de adquisición y mantenimiento de aplicaciones. Los enfoques para la adquisición y mantenimientos de software aplicativo varían de un proyecto a otro. Es probable que se hayan adquirido en forma independiente una variedad de soluciones individuales para requerimientos particulares del negocio, teniendo como resultado ineficiencias en el mantenimiento y soporte. Se tiene poca consideración hacia la seguridad y disponibilidad de la aplicación en el diseño o adquisición de software aplicativo. 2 Repetible pero Intuitivo cuando Existen procesos de adquisición y mantenimiento de aplicaciones, con diferencias pero similares, en base a la experiencia dentro de la operación de TI. El mantenimiento es a menudo problemático y se resiente cuando se pierde el conocimiento interno de la organización. Se tiene poca consideración hacia la seguridad y disponibilidad de la aplicación en el diseño o adquisición de software aplicativo 3 Definido cuando Existe un proceso claro, definido y de comprensión general para la adquisición y mantenimiento de software aplicativos. Este proceso va de acuerdo con la estrategia de TI y del negocio. Se intenta aplicar los procesos de manera consistente a traves de diferentes aplicaciones y proyectos. Las metodologías son por lo general, inflexibles y difíciles de aplicar en todos los casos, por lo que es muy probable que se salten pasos. Las actividades de mantenimiento se planean, programan y coordinan 4 Administrado y Medible cuando Existe una metodología formal y bien comprendida que incluye un proceso de diseño y especificación, un criterio de adquisición, un proceso de prueba y requerimientos para la documentación. Existen mecanismos de aprobación documentados y acordados, para
  • 46. Auditoría de Sistemas Informáticos II (Silabo + Reactivos) garantizar que se sigan todos los pasos y se autoricen las excepciones. Han evolucionado prácticas y procedimientos para ajustarlos la medida de la organización, los utilizan todo el personal y son apropiados para la mayoría de los requerimientos de aplicación 46 5 Optimizado cuando Las prácticas de adquisición y mantenimiento de software aplicativo se alinean con el proceso definido. El enfoque es con base en componentes, con aplicaciones predefinidas y estandarizadas que corresponden a las necesidades del negocio. El enfoque se extiende para toda la empresa. La metodología de adquisición y mantenimiento presenta un avance y permite un posicionamiento estratégico rápido, que permite un alto grado de reacción y flexibilidad para responder a requerimientos cambiantes del negocio. La metodología de adquisición e implantación de software aplicativo ha sido sujeta a mejora continua y se soporta con bases de datos internos y externas que contienen materiales de referencia y las mejores prácticas . 3.4.3.-ADQUIRIR Y MANTENER INFRAESTRUCTURA TECNOLÓGICA AI3 3.4..3.1.-DESCRIPCIÓN DEL PROCESO Las organizaciones deben contar con procesos para adquirir, implementar y actualizar la infraestructura tecnológica. Esto requiere de un enfoque planeado para adquirir, mantener y proteger la infraestructura de acuerdo con las estrategias técnológicas convenidas y la disposición del ambiente de desarrollo y pruebas.Esto garantiza que exista un soporte tecnológico continuo para las aplicaciones del negocio. • El número de componentes de infraestructura que ya no se pueden soportar (o que ya no se podrán en el futuro cercano)
  • 47. Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 47 3.4.3.2.-OBJETIVOS DE CONTROL AI3.1 Plan de Adquisición de Infraestructura Tecnológica Generar un plan para adquirir, Implementar y mantener la infraestructura tecnológica que satisfaga los requerimientos establecidos funcionales y técnicos del negocio, y que esté de acuerdo con la dirección tecnológica de la organización. El plan debe considerar extensiones futuras para adiciones de capacidad, costos de transición, riesgos tecnológicos y vida útil de la inversión para actualizaciones de tecnología. Evaluar los costos de complejidad y la viabilidad comercial del proveedor y el producto al añadir nueva capacidad técnica. AI3.2 Protección y Disponibilidad del Recurso de Infraestructura Implementar medidas de control interno, seguridad y auditabilidad durante la configuración, integración y mantenimiento del hardware y del software de la infraestructura para proteger los recursos y garantizar su disponibilidad e integridad. Se deben definir y comprender claramente las responsabilidades al utilizar componentes de infraestructura sensitivos por todos aquellos que desarrollan e integran los componentes de infraestructura. Se debe monitorear y evaluar su uso. AI3.3 Mantenimiento de la Infraestructura Desarrollar una estrategia y un plan de mantenimiento de la infraestructura y garantizar que se controlan los cambios, de acuerdo con el procedimiento de administración de cambios de la organización. Incluir una revisión periódica contra las necesidades del negocio, administración de parches y estrategias de actualización, riesgos, evaluación de vulnerabilidades y requerimientos de seguridad. AI3.4 Ambiente de Prueba de Factibilidad Establecer el ambiente de desarrollo y pruebas para soportar la efectividad y eficiencia de las pruebas de factibilidad e integración de aplicaciones e infraestructura, en las primeras fases del proceso de adquisición y desarrollo. Hay que considerar la funcionalidad, la configuración de hardware y software, pruebas de integración y desempeño, migración entre ambientes, control de la versiones, datos y herramientas de prueba y seguridad. 3.4.3.3.-MODELO DE MADUREZ
  • 48. Auditoría de Sistemas Informáticos II (Silabo + Reactivos) La administración del proceso de Adquirir y mantener infraestructura de tecnología que satisfaga el requerimiento de negocio de TI de adquirir y mantener una infraestructura de TI integrada y estandarizada es: 48 0 No Existente cuando No se reconoce la administración de la infraestructura de tecnólogia como un asunto importante al cual debe ser resuelto. 1 Inicial /Ad Hoc cuando Se realizan cambios a la infraestructura para cada nueva aplicación, sin ningún plan en conjunto. Aunque se tiene la percepción de que la infraestructura de TI es importante, no existe un enfoque general consistente. La actividad de mantenimiento reacciona anecesidades de corto plazo. El ambiente de producción es el ambiente de prueba. 2 Repetible pero Intuitivo cuando No hay consistencia entre enfoques tácticos al adquirir y dar mantenimiento a la infraestructura de TI. La adquisición y mantenimiento de la infraestructura de TI no se basa en una estrategia definida y no considera las necesidades de las aplicaciones del negocio que se deben respaldar. Se tiene la noción de que la infraestructura de TI es importante, que se apoya en algunas prácticas formales. Algunos mantenimientos se programan, pero no se programa ni se coordina en su totalidad. Para algunos ambientes, existe un ambiente de prueba por separado. 3 Definido cuando Existe un claro, definido y generalmente entendido proceso para adquirir y dar mantenimiento a la infraestructura TI. El proceso respalda las necesidades de las aplicaciones críticas del negocio y concuerda con la estrategia de negocio de TI, pero no se aplica en forma consistente. Se planea, programa y coordina el mantenimiento. Existen ambientes separados para prueba y producción. 4 Administrado y Medible cuando Se desarrolla el proceso de adquisición y mantenimiento de la infraestructura de tecnología a tal punto que funciona bien para la mayoría de las situaciones, se le da un seguimiento consistente y un enfoque hacia la reutilización. La infraestructura de TI soporta adecuadamente lasaplicaciones del neg ocio. El proceso está bien organizado y es preventivo. Tanto el costo como el tiempo de realización para alcanzar el nivel esperado de escalamiento, flexibilidad e integración se han optimizado parcialmente. 5 Optimizado cuando El proceso de adquisición y mantenimiento de la infraestructura de tecnología es preventivo y está estrechamente en línea con las aplicaciones críticas del negocio y con la arquitectura de la tecnología. Se siguen buenas prácticas respecto a las soluciones de tecnología, y la
  • 49. Auditoría de Sistemas Informáticos II (Silabo + Reactivos) organización tiene concienc ia de las últimas plataformas desarrolladas y herramientas de administración. Se reducen costos al racionalizar y estandarizar los componentes de la infraestructura y con el uso de la automatización. Con un alto nivel de conciencia se pueden identificar los medios óptimos para mejorar el desempeño en forma preventiva, incluyendo el consierar la opción de contratar servicios externos . La infraestructura de TI se entiende como el apoyo clave para impulsar el uso de TI. 49 3.4.4.-FACILITAR LA OPERACIÓN Y EL USO AI4 3.4.4.1.-DESCRIPCIÓN DEL PROCESO El conocimiento sobre los nuevos sistemas debe estar disponible. Este proceso requiere la generación de documentación y manuales para usuarios y para TI, y proporciona entrenamiento para garantizar el uso y la operación correctos de las aplicaciones y la infraestructura. 3.4.4.2.-OBJETIVOS DE CONTROL AI 4.1 Plan para Soluciones de Operación Desarrollar un plan para identificar y documentar todos los aspectos técnicos, la capacidad de operación y los niveles de servicio requeridos, de manera que todos los interesados puedan tomar la responsabilidad oportunamente por la producción de procedimientos de administración, de usuarios y operativos, como resultado de la introducción o actualización de sistemas automatizados o de infraestructura.
  • 50. Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 50 AI4.2 Transferencia de Conocimiento a la Gerencia del Negocio Transferir el conocimiento a la gerencia de la empresa para permitirles tomar posesión del sistema y los datos y ejercer la responsabilidad por la entrega y calidad del servicio, del control interno y de los procesos administrativos de la aplicación. La transferencia de conocimientos incluye la aprobación de acceso, administración de privilegios, segregación de tareas, controles automatizados del negocio, respaldo/recuperación, seguridad física y archivo de la documentación fuente. AI4.3 Transferencia de Conocimiento a Usuarios Finales Transferencia de conocimiento y habilidades para permitir que los usuarios finales utilicen con efectividad y eficiencia el sistema de aplicación como apoyo a los procesos del negocio. La transferencia de conocimiento incluye el desarrollo de un plan de entrenamiento que aborde al entrenamiento inicial y al continuo, así como el desarrollo de habilidades, materiales de entrenamiento, manuales de usuario, manuales de procedimiento, ayuda en línea, asistencia a usuarios, identificación del usuario clave, y evaluación. AI4.4 Transferencia de Conocimiento al Personal de Operaciones y Soporte Transferir el conocimiento y las habilidades para permitir al personal de soporte técnico y de operaciones que entregue, apoyen y mantenga la aplicación y la infraestructura asociada de manera efectiva y eficiente de acuerdo a los niveles de servicio requeridos. La transferencia del conocimiento debe incluir al entrenamiento inicial y continuo, el desarrollo de las habilidades, los materiales de entrenamiento, los manuales de operación, los manuales de procedimientos y escenarios de atención al usuario. 3.4.4.3.-MODELO DE MADUREZ La administración del proceso de Facilitar la operación y el uso que satisfaga el requerimiento de negocio de TI de garantizar la satisfacción de los usuarios finales con ofrecimiento de servicios y niveles de servicio, e integrar de forma transparente aplicaciones y soluciones de tecnología dentro de los procesos del negocio es: O No Existente cuando No existe el proceso con respecto a la producción de documentación de usuario, manuales de operación y material de entrenamiento. Los únicos materiales existentes son aquellos que se suministran con los productos que se adquieren. 1 Inicial / Ad Hoc cuando Existe la percepción de que la documentación de proceso es necesaria. La documentación se genera ocasionalmente y se distribuye en forma desigual a grupos limitados. Mucha de la documentación y muchos de los procedimientos ya caducaron. Los materiales de
  • 51. Auditoría de Sistemas Informáticos II (Silabo + Reactivos) entrenamiento tienden a ser esquemas únicos con calidad variable. Virtualmente no existen procedimientos de integración a través de los diferentes sistemas y unidades de negocio. No hay aportes de las unidades de negocio en el diseño de programas de entrenamiento 51 2 Repetible pero Intuitivo cuando Se utilizan enfoques similares para generar r procedimientos y documentación, pero no se basan en un enfoque estructural o marco de trabajo. No hay un enfoque uniforme para el desarrollo de procedimientos de usuario y de operación. Individuos o equipos de proyecto generan los materiales de entrenamiento, y la calidad depende de los individuos que se involucran. Los procedimientos y la calidad del soporte al usuario van desde pobre a muy buena, con una consistencia e integración muy pequeña a lo largo de la organización. Se proporcionan o facilitan programas de entrenamiento para el negocio y los usuarios, pero no hay un plan general para ofrecer o dar entrenamiento. 3 Definido cuando Existe un esquema bien definido, aceptado y comprendido para documentación del usuario, manuales de operación y materiales de entrenamiento. . Se guardan y se mantienen los procedimientos en una biblioteca formal y cualquiera que necesite saber tiene acceso a ellas. Las correcciones a la documentación y a los procedimientos se realizan por reacción. Los procedimientos se encuentran disponibles fuera de línea y se pueden acceder y mantener en caso de desastre. Existe un proceso que especifica las actualizaciones de procedimientos y los materiales de entrenamiento para que sea un entregable explícito de un proyecto de cambio. A pesar de la existencia de enfoques definidos, el contenido actual varía debido a que no hay un control para reforzar el cumplimiento de estándares. Los usuarios se involucran en los procesos informalmente. Cada vez se utilizan más herramientas automatizadas en la generación y distribución de procedimientos. Se planea y programa tanto el entrenamiento del negocio como de los usuario. 4 Administrado y Medible cuando Existe un esquema definido para los procedimientos de mantenimiento y para los materiales de entrenamiento que cuentan con el soporte de la administración de TI. El enfoque considerado para los procedimientos de mantenimiento y los manuales de entrenamiento cubren todos los sistemas y las unidades de negocio, de manera que se pueden observar los procesos desde una perspectiva de negocio.. El desarrollo automatizado de procedimientos se integra cada vez más con el desarrollo de sistemas aplicativos, facilitando la consistencia y el acceso al usuario. El entrenamiento de negocio y usuario es sensible a las necesidades del negocio. La administración de TI está desarrollando medidas para el desarrollo y la entrega de documentación, materiales y programas de entrenamiento. 5 Optimizado cuando El proceso para la documentación de usuario y de operación se mejora constantemente con la adopción de nuevas herramientas o métodos. Los materiales de procedimientos y de entrenamiento se tratan como una base de conocimiento en evolución constante que se
  • 52. Auditoría de Sistemas Informáticos II (Silabo + Reactivos) mantiene en forma electrónica, con el uso de administración de conocimiento actualizada, flujo de trabajo y tecnologías de distribución, que los hacen accesibles y fáciles de mantener. El material de documentación y entrenamiento se actualiza para reflejar los cambios en la organización, en la operación y en el software. Tanto el desarrollo de materiales de documentación y entrenamiento como la entrega de programas de entrenamiento, se encuentran completamente integrados con el negocio y con las definiciones de proceso del negocio, siendo así un apoyo a los requerimientos de toda la organización y no tan sólo procedimientos orientados a TI. 52 3.4.5.-ADQUIRIR RECURSOS DE TI AI5 3.4.5.1.-DESCRIPCIÓN DEL PROCESO. Se deben suministrar recursos TI, incluyendo personas, hardware, software y servicios. Esto requiere de la definición y ejecución de los procedimientos de adquisición, la selección de proveedores, el ajuste de arreglos contractuales y la adquisición en sí. El hacerlo así garantiza que la organización tenga todos los recursos de TI que se requieren de una manera oportuna y rentable. 3.4.5.2.-OBJETIVOS DE CONTROL
  • 53. Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 53 AI5.1 Control de Adquisición Desarrollar y seguir un conjunto de procedimientos y estándares consistentes con el proceso general de adquisición de la organización y con la estrategia de adquisición para adquirir infraestructura relacionada con TI, instalaciones, hardware, software y servicios necesarios por el negocio. AI5.2 Administración de Contratos con Proveedores Formular procedimiento para establecer, modificar y concluir contratos para todos los proveedores. El procedimiento debe cubrir, como mínimo, responsabilidades y obligaciones legales, financieras, organizacionales, documentales, de desempeño, de seguridad, de propiedad intelectual y responsabilidades de conclusión así como obligaciones (que incluyan cláusulas de penalización). Todos los contratos y las modificaciones a contratos las deben revisar asesores legales. AI5.3 Selección de Proveedores Seleccionar proveedores de acuerdo a una práctica justa y formal para garantizar la mejor viable y encajable según los requerimientos especificados. Los requerimientos deben estar optimizados con las entradas de los proveedores potenciales. AI5.4 Adquisición de Recursos de TI Proteger y hacer cumplir los intereses de la organización en todo los contratos de adquisiciones, incluyendo los derechos y obligaciones de todas las partes en los términos contractuales para la adquisición de software, recursos de desarrollo, infraestructura servicios. 3.4.5.3-MODELO DE MADUREZ
  • 54. Auditoría de Sistemas Informáticos II (Silabo + Reactivos) La administración del proceso de Adquirir recursos de TI que satisfaga el requerimiento de negocio de TI de mejorar la rentabilidad d TI y su contribución a la utilidad del negocio es: 54 0 No Existente cuando No existe un proceso definido de adquisición de recursos de TI. La organización no reconoce la necesidad de tener políticas y procedimientos claros de adquisición para garantizar que todos los recursos de TI se encuentren disponibles y de forma oportuna y rentable 1 Inicial / Ad Hoc cuando La organización ha reconocido la necesidad de tener políticas y procedimientos documentados que enlacen la adquisición de TI con el proceso general de adquisiciones de la organización. Los contratos para la adquisición de recursos de TI son elaborados y administrados por gerentes de proyecto y otras personas que ejercen su juicio profesional más que seguir resultados de procedimientos y políticas formales. Sólo existe un relación ad hoc entre los procesos de administración de adquisiciones y contratos corporativos y TI. Los contratos de adquisición se administran a la terminación de los proyectos más que sobre una base continua. 2 Repetible pero Intuitivo cuando Existe conciencia organizacional de la necesidad de tener políticas y procedimientos básicos para la adquisición de TI. Las políticas y procedimientos se integran parcialmente con el proceso general de adquisición de la organización del negocio. Los procesos de adquisición se utilizan principalmente en proyectos mayores y bastante visibles. 3 Definido cuando
  • 55. Auditoría de Sistemas Informáticos II (Silabo + Reactivos) La administración establece políticas y procedimientos para la adquisición de TI. Las políticas y procedimientos toman como guía el proceso general de adquisición de la organización. La adquisición de TI se integra en gran parte con los sistemas generales de adquisición del negocio. Existen estándares de TI para la adquisición de recursos de TI. Los proveedores de recursos de TI se integran dentro de mecanismos de administración de proyectos de la organización desde una perspectiva de administración de contrato. La administración de TI comunica la necesidad de contar con una administración adecuada de adquisiciones y contratos en toda la función de TI. 55 4 Administrado y Medible cuando La adquisición de TI se integra totalmente con los sistemas generales de adquisición de la organización. Se utilizan los estándares para la adquisición de recursos de TI en todos los procesos de adquisición. Se toman medidas para la administración de contratos y adquisiciones relevantes para l s casos de negocio que requieran la adquisición de TI. Se dispones de reportes que sustentan los objetivos de negocio. La administración de Ti implanta el uso de procesos de administración para adquisición y contratos en todas las adquisiciones mediante la revisión de medición al desempeño 5 Optimizado cuando La administración instituye y da recursos a procesos exhaustivos para la adquisición de TI. La administración impulsa el cumplimiento de las políticas y procedimientos de adquisición de TI. Se toman las medidas en la administración de contratos y adquisiciones, relevantes en casos de negocio para adquisición de TI. Se establecen buenas relaciones con el tiempo con la mayoría de los proveedores y socios, y se mide y vigila la calidad de estas relaciones. Se manejan las relaciones en forma estratégica. Los estándares, políticos y procedimientos de TI para la adquisición de recursos TI se manejan estratégicamente y responden a la medición del proceso. La administración de TI comunica la importancia estratégica de tener una administración apropiada de adquisiciones y contratos, a través de la función TI. 3.4.6.-ADMINISTRAR CAMBIOS AI6 3.4.6.1.-DESCRIPCIÓN DEL PROCESO Todos los cambios, incluyendo el mantenimiento de emergencia y parches, relacionados con la infraestructura y las aplicaciones dentro del ambiente de producción, deben administrarse formalmente y controladamente. Los cambios (incluyendo procedimientos, procesos, sistema y parámetros del servicio) se deben registrar, evaluar y autorizar previo a la implantación y revisar contra los resultados planeados después de la implementación. . Esto garantiza la reducción de riesgos que impactan negativamente la estabilidad o integridad del ambiente de producción.
  • 56. Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 56 3.4.6.2.-OBJETIVOS DE CONTROL AI6.1 ESTÁNDARES Y PROCEDIMIENTOS PARA CAMBIOS Establecer procedimientos de administración de cambio formales para manejar de manera estándar todas las solicitudes (incluyendo mantenimiento y parches) para cambios a aplicaciones, procedimientos, procesos, parámetros de sistemas y servicio, y las plataformas fundamentales. AI6.2 EVALUACIÓN DE IMPACTO, PRIORIZACIÓN Y AUTORIZACIÓN.
  • 57. Auditoría de Sistemas Informáticos II (Silabo + Reactivos) Garantizar que todas las solicitudes de cambio se evalúan de una estructurada manera en cuanto a impactos en el sistema operacional y su funcionalidad. Esta evaluación deberá incluir categorización y priorización de los cambio. Previo a la migración hacia producción, los interesados correspondientes autorizan los cambios. 57 AI6.3 CAMBIOS DE EMERGENCIA. Establecer un proceso para definir, plantear, evaluar y autorizar los cambios de emergencia que no sigan el proceso de cambio establecido. La documentación y pruebas se realizan, posiblemente, después de la implantación del cambio de emergencia. AI6.4 SEGUIMIENTO Y REPORTE DE ESTATUS DE CAMBIO. Establecer un sistema de seguimiento y reporte para mantener actualizados a los solicitantes de cambio a las aplicaciones, a los procedimientos, a los procesos, parámetros de sistemas y del servicio y las plataformas fundamentales. AI6.5 CIERRE Y DOCUMENTACIÓN DEL CAMBIO Siempre que se implantan cambios al sistema, actualizar el sistema asociado y la documentación de usuario y procedimientos correspondientes. Establecer un proceso de revisión para garantizar la implantación completa de los cambios. 3.4.6.3-MODELO DE MADUREZ La administración del proceso de Administrar cambios que satisfaga el requerimiento de negocio de TI de responder a los requerimientos de acuerdo con la estrategia del negocio, mientras que se reducen los defectos y repeticiones de trabajos en la entrega de soluciones y servicios es: 0 NO EXISTENTE CUANDO: Un proceso definido de administración de cambio y los cambios se pueden realizar virtualmente sin control. No hay conciencia de que el cambio pude causar una interrupción para TI y las operaciones del negocio y no hay conciencia de los beneficios de la buena administración de cambio. 1 INICIAL / AD HOC CUANDO: Se reconoce que los cambios se deben administrar y controlas. Las prácticas varían y es muy probable que se puedan dar cambios sin autorización. Hay documentación de cambio pobre o no existente y la documentación de configuración es incompleta y no confiable. Es posible que ocurran errores junto con interrupciones al ambiente de producción, provocados por una pobre administración de cambios. 3 DEFINIDO CUANDO:
  • 58. Auditoría de Sistemas Informáticos II (Silabo + Reactivos) Existe un proceso formal definido para la administración del cambio, que incluye la categorización, asignación de prioridades, procedimientos de emergencia, autorización del cambio y administración de liberación, y va surgiendo el cumplimiento. Se dan soluciones temporales a los problemas y los procesos a menudo se omiten o se hacen a un lado. Aún pueden ocurrir errores y los cambios no autorizados ocurren ocasionalmente. El análisis de impacto de los cambios de TI en operaciones de negocios se está volviendo formal, para apoyar la implantación planeada de nuevas aplicaciones y tecnologías. 58 4 ADMINISTRADO Y MEDIBLE CUANDO: El proceso de administración de cambio se desarrolla bien y es consistente para todos los cambios, y la gerencia confía que hay excepciones mínimas. El proceso es eficiente y efectivo, pero se basa en manuales de procedimientos y controles considerables para garantizar el logro de la calidad. Todos los cambios están sujetos a una planeación minuciosa y a la evaluación del impacto para minimizar la probabilidad de tener problemas de post-producción. Se da un proceso de aprobación para cambios. La documentación de administración de cambios es vigente y correcta, con seguimiento formar a los cambios. La documentación de configuración es generalmente exacta. La planeación e implantación de la administración de cambios de TI se van integrando con los cambios en los procesos de negocio, para asegurar que se resuelven los asuntos referentes al entrenamiento, cambio organizacional y continuidad del negocio. Existe una coordinación creciente entre la administración de cambio de TI y el rediseño del proceso de negocio. Hay un proceso consistente para monitorear la calidad y el desempeño del proceso de administración de cambios. 5 OPTIMIZANDO CUANDO: El proceso de administración de cambios se revisa con regularidad y se actualiza para permanecer en línea con las buenas prácticas. El proceso de revisión refleja los resultados del monitoreo. La información de la configuración es computarizada y proporciona un control de versión. El rastreo del cambio es sofisticado e incluye herramientas para detectar software no autorizado y sin licencia. La administración de cambio de TI se integra con la administración de cambio del negocio para garantizar que TI sea un factor que hace posible el incremento de productividad y la creación de nuevas oportunidades de negocio para la organización. 3.4.7.-INSTALAR Y ACREDITAR SOLUCIONES Y CAMBIOS AI7 3.4.7.1.-DESCRIPCIÓN DEL PROCESO Los nuevos sistemas necesitan estar funcionales una vez que su desarrollo se completa. Esto requiere pruebas adecuadas en un ambiente dedicado con datos de prueba relevantes, para definir la transición e instrucciones de migración, planear la liberación y la transición
  • 59. Auditoría de Sistemas Informáticos II (Silabo + Reactivos) en si al ambiente de producción y revisar la post-implantación. Esto garantiza que los sistemas operativos estén en línea con las expectativas convenidas y con los resultados. 59 3.4.7.2.-OBJETIVOS DE CONTROL AI7.1 ENTRENAMIENTO Entrenar al personal de los departamentos de usuario afectados y al grupo de operaciones de la función de TI de acuerdo con el plan definido de entrenamiento e implantación y a los materiales asociados, como parte de cada proyecto de sistemas de la información de desarrollo, implementación o modificación. AI7.2 PLAN DE PRUEBA Establecer un plan de pruebas basado en los estándares de la organización que define roles, responsabilidades, y criterios de entrada y salida. Asegurar que el plan está aprobado por las partes relevantes. AI7.3 PLAN DE IMPLANTACIÓN Establecer un plan de implantación y respaldo y vuelta atrás. Obtener aprobación de las partes relevantes. AI7.4 AMBIENTE DE PRUEBA Definir y establecer un entorno seguro de pruebas representativo del entorno de operaciones planeado relativo a seguridad, controles internos, practicas operativos, calidad de los datos y requerimientos de privacidad, y cargas de trabajo. AI7.5 CONVERSION DE SISTEMAS Y DATOS Plan de conversión de datos y migración de infraestructuras como parte de métodos de desarrollo de la organización, incluyendo pistas de auditoría, respaldo y vuelta atrás. AI7.6 PRUEBA DE CAMBIOS
  • 60. Auditoría de Sistemas Informáticos II (Silabo + Reactivos) Pruebas de cambios independientemente en acuerdo con los planes de pruebas definidos antes de la migración al entorno de operaciones. Asegurar que el plan considera la seguridad y el desempeño. AI7.7 PRUEBA DE ACEPTACIÓN FINAL Asegurar que el dueño de proceso de negocio y los interesados de TI evalúan los resultados de los procesos de pruebas como determina el plan de pruebas. Remediar los errores significativos identificados en el proceso de pruebas, habiendo completado el conjunto de pruebas identificadas en el plan de pruebas y cualquier prueba de regresión necesaria. Siguiendo la evaluación, aprobación promoción a producción. AI7.8 PROMOCIÓN A PRODUCCIÓN Seguimiento a pruebas, controlar la entrega de los sistemas cambiados a operaciones, manteniéndolo en línea con el plan de implantación. Obtener la aprobación de los interesados clave, tales como usuarios, dueño de sistemas y gerente de operaciones. Cuando sea apropiado, ejecutar el sistema en paralelo con el viejo sistema por un tiempo, y comparar el comportamiento y los resultados. AI7.9 REVISIÓN POSTERIOR A LA IMPLANTACIÓN Establecer procedimientos en línea con los estándares de gestión de cambios organizacionales para requerir una revisión posterior a la implantación como conjunto de salida en el plan de implementación. 60 3.4.7.3.-MODELO DE MADUREZ La administración del proceso de Instalar y acreditar soluciones y cambios que satisfagan el requerimiento de negocio de TI de implementar sistemas nuevos o modificados que funcionen sin mayores problemas después de su instalación es: 0 No Existente cuando: Hay una ausencia completa de procesos formales de instalación o acreditación y ni la gerencia sénior ni el personal de TI reconocen la necesidad de verificar que las soluciones se ajustan para el propósito deseado. 1 Inicial / Ad Hoc cuando: Existe la percepción de la necesidad de verificar y confirmar que las soluciones implantadas sirven para el propósito esperado. Las pruebas se realizan para algunos proyectos, pero la iniciativa de pruebas se deja a los equipos de proyectos particulares y los enfoques que se toman varían. La acreditación formal y la autorización son raras o no existentes. 2 Repetible pero Intuitivo cuando: Existe cierta consistencia entre los enfoques de prueba y acreditación, pero por lo regular no se basan en ninguna metodología. Los equipos individuales de desarrollo deciden normalmente el enfoque de prueba y casi siempre hay ausencia de pruebas de integración. Hay un proceso de aprobación informal.
  • 61. Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 61 3 Definido cuando: Se cuenta con una metodología formal en relación con la instalación, migración, conversión y aceptación. Los procesos de TI para instalación y acreditación están integrados dentro del ciclo de vida del sistema y están automatizados hasta cierto punto. El entrenamiento, pruebas y transición y acreditación a producción tienen muy probablemente variaciones respecto al proceso definido, con base en las decisiones individuales. La calidad de los sistemas que pasan a producción es inconsistente, y los nuevos sistemas a menudo generan un nivel significativo de problemas posteriores a la implantación. 4 Administrado y Medible cuando: Los procedimientos son formales y se desarrollan para ser organizados y prácticos con ambientes de prueba definidos y con procedimientos de acreditación. En la práctica, todos los cambios mayores de sistemas siguen este enfoque formal. La evaluación de satisfacción requerimientos del usuario es estándar y medible, y produce mediciones que la gerencia puede revisar y analizar de forma efectiva. La calidad de los sistemas que entran en producción es satisfactoria para la gerencia, aún con niveles razonables de problemas posteriores a la implantación. La automatización del proceso es ad hoc y depende del proyecto. Es posible que la gerencia esté satisfecha con el nivel actual de eficiencia a pesar de la ausencia de una evaluación posterior a la implementación. El sistema de prueba refleja adecuadamente el ambiente de producción. La prueba de stress para los nuevos sistemas y la prueba de regresión para sistemas existentes se aplican para proyectos mayores. 5 Optimizado cuando: Los procesos de instalación y acreditación se han refinado a un nivel de buena práctica, con base en los resultados de mejora continua y refinamiento. Los procesos de TI para la instalación y acreditación están totalmente integrados dentro del ciclo de vida del sistema y se automatizan cuando es apropiado, arrojando el estatus más eficiente de entrenamiento, pruebas y transición a producción para los nuevos sistemas.
  • 62. Auditoría de Sistemas Informáticos II (Silabo + Reactivos) 3.5 Entregar y dar Soporte DS1 Definir y administrar los niveles de servicio. DS2 Administrar los servicios de terceros DS3 Administrar el desempeño y la capacidad DS4 Garantizar la continuidad del servicio DS5 Garantizar la seguridad de los sistemas DS6 Identificar y asignar costos DS7 Educar y entrenar a los usuarios DS8 Administrar la mesa de servicio y los incidentes DS9 Administrar la configuración DS10 Administrar los problemas DS11 Administrar los datos DS12 Administrar el ambiente físico DS13 Administrar las operaciones 3.6 Monitorear y Evaluar ME1 Monitorear y Evaluar el Desempeño de TI ME2 Monitorear y Evaluar el Control Interno ME3 Garantizar el Cumplimiento Regulatorio ME4 Proporcionar Gobierno de TI 62 UNIDAD III LOS CUATRO DOMINIOS Y LOS 34 OBJETIVOS DE CONTROL DE COBIT