ACERTIJO DE LA BANDERA OLÍMPICA CON ECUACIONES DE LA CIRCUNFERENCIA. Por JAVI...
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