T espe-021849 tesis

CAPÍTULO I
AUDITORÍA INFORMÁTICA – PRESENTACIÓN DEL PROYECTO
1.1 PROYECTO -
“Auditoría Informática de los sistemas de información de la ESPE
Dominio de Planeación y Organización”.
1.2 INTRODUCCIÓN -
La evolución de los sistemas de información y comunicación en nuestro
País, ha generado la necesidad de implementar la gestión de sistemas en las
diferentes instituciones; para obtener seguridad, confiabilidad y escalabilidad en
todos los ámbitos que a tecnología de la información conciernen.
La velocidad con que los medios de comunicación progresan, ha hecho que las
empresas cada vez necesiten de más control sobre sus datos y los sistemas
que estas utilizan, provocando con ello el que el procesamiento de la
información y la rapidez con la que se realiza se vuelva de vital importancia.
La Escuela Politécnica del Ejército y su Unidad de Tecnología de la Información
y Comunicaciones, ha venido ejecutando varios proyectos relacionados con el
área informática con el fin de apoyar a las distintas actividades que se
desarrollan dentro de ella. Se han implementado algunos servicios informáticos
y otros se encuentran en desarrollo, para lo que se han adquirido equipos,
instalado redes y contratado otros servicios adicionales. Sin embargo debido a
la carga de trabajo encomendada a la unidad de TIC’s estos sistemas se han
visto afectados en la calidad que el cliente interno espera obtener de estos.

2
Motivo por el cual se ha considerado la necesidad de realizar una Auditoría
Informática con el fin de enmendar fallas en el momento oportuno, fallas que
redundan en el costo de los productos y en la calidad de los mismos; para lo
cual se ha considerado la utilización de Cobit como metodología de desarrollo.
COBIT es un Marco de referencia basado en las mejores prácticas de sistemas
de información de auditoría y control de procesos y objetivos de TI que pueden
ser implementados para controlar, auditar y administrar la organización TI.
Particularmente ayudará a entender y administrar los riesgos relacionados con
la tecnología de la información, la relación entre los procesos de
administración, las preguntas técnicas, la necesidad de controles y los riesgos
y su gestionamiento.
1.3 ANTECEDENTES -
La Escuela Politécnica del Ejército, desde hace algunos años, ha venido
ejecutando varios proyectos relacionados con el área informática, con el objeto de
apoyar a las diferentes actividades que desarrolla la Escuela.
La ESPE, como institución educativa de prestigio que brinda servicios
académicos, cuenta con la una unidad de Tecnología de la Información y
Comunicaciones que centraliza la administración y gestión de las actividades TI,
es decir se encarga del análisis, desarrollo e implantación de los sistemas
requeridos en toda la ESPE y sus sedes y se preocupa por el adecuado
funcionamiento de las aplicaciones existentes, redes y comunicaciones.

3
1.4 JUSTIFICACIÓN -
Tomando en cuenta los antecedentes antes nombrados y tomando en cuenta
que para la correcta gestión de TI y la administración de los sistemas de
información, es necesario realizar un adecuado Control, Planeación y
Organización de los procesos y sistemas que maneja la institución; se consideró
de vital importancia la realización de una Auditoría de Sistemas con el objeto de
plantear medidas correctivas para enmendar fallas en el momento oportuno.
La ESPE es una institución en constante evolución por lo que es necesario llevar
un control de los proyectos que en ella se realizan, ya que debido al cambio
constate de autoridades los avances de dichos proyectos quedan únicamente a
cargo y en conocimiento del personal asignado a ellos, de tal manera que estas
falencias redundan en costos para la institución
1.5 OBJETIVO DEL PROYECTO -
1.5.1 Objetivo General
Realizar la auditoría informática de la Escuela Politécnica del Ejército, del
dominio de Planeación y Organización, utilizando el modelo COBIT (Control
Objectives For Information and Related Technology), con el fin de evaluar el
cumplimiento de controles citados en él, identificar falencias y formular
recomendaciones.
1.5.2 Objetivos Específicos
- Presentar el marco teórico del Modelo Cobit.

4
- Describir la situación actual del área informática, las actividades y
esfuerzos necesarios para lograr los objetivos propuestos de la ESPE.
- Evaluar la eficiencia y eficacia con que los Sistemas de Información,
apoyan en la toma de decisiones a la empresa, considerando:
(i) El nivel de detalle provisto por los "Objetivos de Control" y las "Directrices
de Administración" de Cobit, principalmente enfocados en los criterios de
efectividad, disponibilidad, confidencialidad e integridad.
(ii) Políticas, procesos, procedimientos y prácticas de trabajo que serán
evaluados a diferentes niveles de la organización, desde la Administración
TI (Tecnología de Información) hasta el staff operacional.
- Aplicar el Modelo Cobit en la evaluación y auditoría de sistemas para la
unidad de tecnología de la información y comunicaciones de la ESPE.
1.6 ALCANCE -
El proyecto de tesis “EVALUACIÓN Y AUDITORÍA INFORMÁTICA DEL
SISTEMA DE INFORMACIÓN DE LA ESPE”, realizará la revisión de los planes
estratégicos de la institución para conocer el estado interno en cuanto a TI
concierne.
Tomando en cuenta que la presente tesis estará enfocada al dominio de
Planeación y Organización, se profundizará aspectos como el análisis de planes
estratégicos, operacionales, así como de los procesos que se llevan a cabo
dentro de la Unidad de Tecnología de la Información y Comunicaciones (UTIC) de
la ESPE.

5
Como primera parte se mantendrán entrevistas con el personal y las unidades
involucradas, con lo cual se espera recoger, agrupar y evaluar evidencias para
determinar si la unidad de tecnología de la información esta contribuyendo con el
logro de objetivos institucionales, adicionalmente conocer si se está planteando
una visión estratégica dentro de la unidad y si esta está siendo planeada,
comunicada y administrada.
Este plan de tesis se ejecutará en la Escuela Politécnica del Ejército, para lo cual
se realizará la revisión de controles establecidos dentro de la institución aplicando
el modelo COBIT. El proyecto que tendrá una duración de 22 semanas al final de
las cuales se espera obtener recomendaciones en base a las falencias detectadas
las cuales quedarán planteadas en el informe final para que puedan ser aplicadas
según el criterio de las autoridades.
1.7 METODOLOGÍA -
COBIT (Control Objectives For Information and Related Technology) es un
estándar generalmente aceptado para buenas prácticas en seguridad tecnológica,
en administración y control de la tecnología de la información (TI). COBIT tiene
como misión investigar, desarrollar, publicar y promover un conjunto internacional
y actualizado de objetivos de control para tecnología de información que sea de
uso cotidiano para gerentes y auditores. Esto en particular aspira a ayudar a los
líderes empresariales a entender y administrar los riesgos relacionados con la
tecnología de la Información y la relación entre los procesos de administración, las
preguntas técnicas, la necesidad de controles y los riesgos.

6
COBIT se basa en un conjunto de normas, estándares y mejores prácticas de TI,
pero han sido mejorados de acuerdo a los actuales estándares internacionales
profesionales y específicos a la industria, este modelo de referencia tiene la
facilidad de adaptarse a cualquier tipo de negocio por lo que lo adaptaremos a la
ESPE.
1.8 AUDITORÍA INFORMÁTICA -
1.8.1 Introducción -
Hoy en día los sistemas de información se han convertido en pilares
fundamentales de la empresa, ya que ayudan en la toma de decisiones y forman
parte del Management de la misma, por ello, los sistemas de información deben ir
de acuerdo con el gestionamiento de la empresa, procurando mejorarla
haciéndola cada vez más eficaz y eficiente, ya que la gestión de la empresa sobre
sistemas mal diseñados puede generar un serio problema y desencadenar un
efecto dominó sobre la misma que conlleve a poner en peligro su funcionamiento.
Debido a la importancia de los Sistemas de Información dentro de la empresa,
existe la AUDITORÍA INFORMÁTICA cuya tarea consiste en la realización de un
examen crítico con el fin de evaluar la eficiencia y eficacia de una empresa.
Dentro de sus objetivos principales están: el control de la función informática, el
análisis de la eficiencia de los Sistemas informáticos, la verificación del
cumplimiento de la Normativa y la revisión de la eficaz gestión de los recursos
informáticos.
En términos generales podemos definir a la auditoría informática como el conjunto
de técnicas, actividades y procedimientos destinados a analizar, evaluar, verificar

7
y recomendar en los asuntos relacionados a la planificación, control, eficacia,
seguridad y adecuación del servicio informático en la empresa; para plantear
alternativas de acción, la toma de decisiones que permitan corregir errores en
caso de que existiesen, o bien para mejorar la forma de acción.
Con la realización de una Auditoría Informática se logrará conocer si la calidad de
los datos es la adecuada, si es errónea, inexacta o si la misma ha sido
manipulada de alguna manera. Se podrá también conocer si la seguridad que
posean los centros de procesamiento, servidores y datos son las suficientes,
debido a que estos en los últimos tiempos se han convertido en blancos para la
realización de fraudes, espionaje, delincuencia y terrorismo informático; se deben
analizar si los planes de contingencia cumple las funciones para las cuales han
sido creados, para lo cual también se debe realizar un análisis de los riesgos a los
cuales están expuestos los Sistemas de Información. Así mismo se puede
conocer si la empresa ha sido o puede ser víctima de robo de información, si el
soporte técnico es el que necesitan los usuarios. Además se puede conocer si el
Departamento de Sistemas como tal ha manejado su presupuesto de manera
adecuada, con inversiones justificadas o si han existido desviaciones del
presupuesto planteado.
1.8.2 Ambiente de control -
Las empresas deciden realizar auditorías informáticas, el momento en el
que detectan debilidades potenciales dentro de la unidad de Tecnología de la
Información y muchas de las veces cuando sus indicadores dan muestra de
desvío dentro de la planificación del departamento.
Algunas de las razones para ejecutar esta actividad son:

8
• La presencia de aumento injustificado del presupuesto para TI, o la
necesidad de justificar inversiones informáticas de las cuales la empresa
no esta totalmente segura.
• Falta de seguridades tanto a nivel físico como lógico que permitan
salvaguardar la información de la empresa y de los equipos que en ella
funcionan.
• Sospechas de fraudes o robos de información de la empresa.
• La falta de una planificación informática adecuada y que vaya de acuerdo
con los objetivos propios de la empresa.
• Falta de organización del departamento. Cuando no coinciden los objetivos
del departamento de Informática de la Compañía y de la propia Compañía.
O cuando los estándares productividad se desvían sensiblemente de los
promedios conseguidos habitualmente.
• Insatisfacción del cliente interno en cuanto a soporte a usuarios se refiere.
Cuando no se están atendiendo peticiones de cambios de los usuarios,
como cambios de software en los terminales de usuario, no se reparan a
tiempo las averías en el hardware o en un tiempo razonable.
• La poca calidad o falta de planes de contingencia en el departamento que
permitan llevar continuidad en el servicio.
• Falta de controles relativos a la confidencialidad y seguridad de la
información, refiriéndose con esto al acceso a la propia información.

9
1.8.3 Proceso de Auditoría Informática -
Todo proceso posee una metodología para ser realizado, es así que el
método de trabajo del auditor pasa por las siguientes etapas:
1.8.3.1 Planificación De La Auditoría Informática
La auditoría informática empieza por la realización de un plan de auditoría el
cual conllevará a la consecución de los objetivos de dicha auditoría, además de
que de esta manera se asegurará el éxito de la misma. El objetivo principal de la
realización de esta planificación deberá ser el determinar la estrategia para cada
etapa de la auditoría, o el proporcionar la información necesaria para la
evaluación del riesgo y así poder determinar el enfoque de trabajo.
Para iniciar y plantear un plan de auditoría, es necesario que el auditor
comprenda el ambiente del negocio en el que se encuentra principalmente sobre
la función informática a evaluar, los riesgos y el control asociado al mismo; para lo
cual será necesario llevar acabo algunas actividades previas tales como
entrevistas y una investigación preliminar que permita tener una visión general del
área a auditar y en base a ello plantear un programa de trabajo en el cual se
deberá detallar:
• Tiempo
• Costo
• Personal necesario
• Documentos auxiliares a solicitar o formular durante el desarrollo de la
misma.

10
Algunos de los ámbitos a ser cubiertos dentro de la planificación de la auditoría
son:
1. Comprensión del negocio: al planificar el auditor debe tener una visión
suficiente del ambiente que esta siendo objeto de análisis, las funciones
que en ella se llevan a cabo, los sistemas que en ella operan, el ambiente
normativo, hacer un recorrido por la empresa y la realización de entrevistas
a la gerencia. Otra documentación que puede ser de ayuda para el
conocimiento del negocio puede ser informes de normas y reglamentos,
planes estratégicos e informes emitidos en auditorías anteriores.
2. Riesgo y materialidad de auditoría: Se debe tomar en cuenta los errores
que podrían darse a lo largo de la auditoría, estos podrían ser debido a
información errónea o porque el auditor no ha podido detectar un error que
haya ocurrido. Esta cuantificación de los riesgos no debe demostrarse
tanto a nivel monetario, sino más bien en el impacto potencial que tendría
para la empresa.
3. Objetivos de control y objetivos de auditoría: El auditor debe conocer que
controles se llevan a cabo dentro de la empresa para poder verificar así
como su existencia, el hecho de que sean eficientes, eficaces y que vayan
de acuerdo con las políticas y objetivos de la empresa. Dentro de los
objetivos de la auditoría también se encuentran: el verificar que el acceso a
la información esté debidamente resguardada, que la ocurrencia de las
transacciones sea registrada y autorizada una sola vez y que los
programas sean debidamente probados y aprobados.

11
4. Procedimientos de auditoría: Revisión de la documentación de sistemas e
identificación de los controles existentes. Entrevistas con los especialistas
técnicos a fin de conocer las técnicas y controles aplicados. Utilización de
software de manejo de base de datos para examinar el contenido de los
archivos de datos. Técnicas de diagramas de flujo para documentar
aplicaciones automatizadas.
En síntesis podemos decir que un plan de auditoría debe cubrir:
• Concentración de objetivos.
• Áreas que cubrirá.
• Personas involucradas en el proceso de auditoría.
• Plan de trabajo.
o Tareas.
o Calendario.
o Resultados parciales.
o Presupuesto.
Equipo auditor necesario
1.8.3.2 Ejecución De La Auditoría Informática
Para el desarrollo adecuado de una auditoría por lo general se debe llevar una
apropiada documentación que de modo general incluye:
a. Tema de auditoría: Donde se identifica el área a ser auditada.
b. Objetivos de Auditoría: Donde se indica el propósito del trabajo de auditoría
a realizar.

12
c. Alcances de auditoría: Se detalla los sistemas específicos o unidades de
organización que se han de incluir en la revisión en un período de tiempo
determinado.
d. Planificación previa: Donde se identifica los recursos y destrezas que se
necesitan para realizar el trabajo así como las fuentes de información para
pruebas o revisión y lugares físicos o instalaciones donde se va auditar.
e. Procedimientos de auditoría:
• Recopilación de datos.
• Identificación de lista de personas a entrevistar.
• Identificación y selección del enfoque del trabajo
• Identificación y obtención de políticas, normas y directivas.
• Desarrollo de herramientas y metodología para probar y
verificar los controles existentes.
• Procedimientos para evaluar los resultados de las pruebas y
revisiones.
• Procedimientos de comunicación con la gerencia.
• Procedimientos de seguimiento.
Para lo cual deberemos cumplir con las fases a continuación señaladas:
- Alcance y Objetivos de la Auditoría Informática.
- Estudio inicial del entorno auditadle.
- Determinación de los recursos necesarios para realizar la auditoría.
- Elaboración del plan y de los programas de trabajo, actividades de la auditoría.
- Análisis de la metodología de trabajo.

13
1.8.3.2.1 Definición de Alcance y Objetivos
Para determinar el alcance de una auditoría informática, este debe estar
determinado de acuerdo al objeto a auditar el cual está compuesto básicamente por
todos los recursos informáticos (personas, equipos, aplicaciones, capacitación, etc.),
la información y los controles.
Dentro de esta primera Fase, se deben enfocar las siguientes áreas:
- Área de Desarrollo (donde se hacen el diseño, programación y desarrollo de
sistemas).
- Área de Explotación (lugares donde se explotan los sistemas desarrollados).
- Área administrativa o de servicios al usuario.
- Sistemas o Aplicaciones (Sistema de rol de pagos).
- Seguridades.
- Normas y Directivas.
De la realización de esta fase se obtiene como resultado: los documentos de
especificaciones del ámbito y objetivos de la auditoría debidamente afinados.
Mediante este procedimiento, logramos uno de los aspectos más relevantes en la
ejecución de la Auditoría Informática como es: La Existencia de un acuerdo muy
preciso entre auditores y clientes sobre las funciones, las materias y las
organizaciones a auditar.
Al acordar la puesta en marcha de la Auditoría, es importante y beneficioso para
ambas partes expresar las excepciones de alcance de la auditoría, es decir,
definir áreas, funciones u organizaciones no van a ser auditadas. Los alcances
como las excepciones deben figurar al comienzo del Informe Final. El personal
que trabajara directa o indirectamente en la auditoría debe conocer con la mayor

14
exactitud posible los objetivos a los que su tarea debe llegar y comprender las
necesidades y pretensiones del cliente, de forma que las metas fijadas puedan
ser cumplidas con eficiencia y eficacia.
Una vez definidos los objetivos (objetivos específicos), éstos se añadirán a los
objetivos generales y comunes de a toda auditoría Informática: La operatividad de
los Sistemas y los Controles Generales Informática.
1.8.3.2.2 Estudio Inicial del Entorno Auditable.
El procedimiento a realizarse en esta fase es el siguiente:
1) Se debe definir la estructura y el orden de los elementos a estudiar
- Organización
- Unidades administrativas (estructura y tamaño)
- Número de personas por cada puesto o función de trabajo
- Número de puestos de trabajo
- Relación que existe entre las unidades
2) Analizar las aplicaciones informáticas
- Cantidad, tamaño y complejidad
- Antigüedad (versión)
- Documentación
- Métodos de diseño y programación
- Cantidad, calidad, complejidad, organización, niveles de seguridad de los
datos.
3) Análisis del entorno operativo
- Configuración del software y hardware
- Número de centros

15
- Redes de comunicación
- Número, tipo, complejidad de los procesos en el entorno operativo
4) Análisis de la Metodología de trabajo
- Normas y procedimientos
- Documentación (de las normas y procedimientos)
- Estándares
- Planificación, administración y control
El producto de esta fase, es el informe sobre los parámetros observados,
debidamente firmados y validado por el personal involucrado.
Para realizar el estudio inicial cumpliendo con lo antes mencionado, para definir la
estructura y el orden de los elementos a estudiar se deben examinar previamente
las funciones y actividades generales del departamento de sistemas en la
organización. Para su realización el auditor debe conocer lo siguiente:
Organización: Para el equipo auditor, el conocimiento de quién ordena, quién
diseña y quién ejecuta es fundamental. Para realizar esto el auditor deberá fijarse
en:
1. Organigrama: El organigrama expresa la estructura oficial de la
organización a auditar. Si se descubriera que existe un organigrama fáctico
diferente al oficial, se pondrá de manifiesto tal circunstancia.
2. Departamentos: Se entiende como departamento a los órganos que siguen
inmediatamente a la Dirección. El equipo auditor describirá brevemente las
funciones de cada uno de ellos.

16
3. Relaciones Jerárquicas y funcionales entre órganos de la Organización: El
equipo auditor verificará si se cumplen las relaciones funcionales y
jerárquicas previstas por el organigrama, o por el contrario detectará, por
ejemplo, si algún empleado tiene dos jefes. Una jerarquía implica la
correspondiente subordinación. Las funcionales por el contrario, indican
relaciones no estrictamente subordinables.
4. Flujos de Información: Además de las corrientes verticales
intradepartamentales, la estructura organizativa, produce corrientes de
información horizontal y extradepartamental. Los flujos de información
entre los grupos de una organización son necesarios para su eficiente
gestión, siempre y cuando tales corrientes no distorsionen el propio
organigrama.
En ocasiones, las organizaciones crean espontáneamente canales alternativos de
información, sin los cuales las funciones no podrían ejercerse con eficacia; estos
canales alternativos se producen porque hay pequeños o grandes fallos en la
estructura y en el organigrama que los representa. En ocasiones, la aparición de
flujos de información no previstos obedece a afinidades personales o simple
comodidad. Estos flujos de información son indeseables y producen graves
perturbaciones en la organización.
1.8.3.2.3 Análisis de la Metodología de trabajo
Normas y procedimientos:
Una metodología sólida de auditoría establece que, antes de probar el
cumplimiento con los controles, es necesario determinar (1) que existan normas
relativas a los controles y (2) que estas normas sean adecuadas para

17
proporcionar el grado de confiabilidad deseado. Sin la existencia de normas para
las operaciones, el auditor no tiene fundamento alguno que le sirva de base para
hacer una predicción.
Documentación (de las normas y procedimientos):
La documentación inherente a las normas de sistemas sirve para establecer
comunicación y registrar logros. Aún cuando las políticas, guías de orientación, o
instrucciones efectivas pueden comunicarse verbalmente, este medio es muy
poco confiable. Las palabras pueden cambiarse fácilmente, olvidarse, o bien
nunca oírse; esta deficiencia puede ser bastante seria cuando se trata de evaluar
la confiabilidad de las actividades que se implantan como resultado de tales
políticas.
Estándares:
Documentación estándar detallada de la lógica del procesamiento y del flujo de la
información relativa a la aplicación, que sea comprensible para todas las partes
relacionadas con el desarrollo de sistemas: los usuarios, analistas,
programadores, personal de operaciones, gerentes y auditores.
1.8.3.3 Finalización de la auditoría Informática
1.8.3.3.1 Preparación y redacción del Informe Final
La función de auditoría se materializa exclusivamente por escrito. Por lo tanto
la elaboración final es el exponente de su calidad. Resulta evidente la necesidad
de redactar borradores e informes parciales previos al informe final, los que

18
pueden ser elementos de contraste entre la opinión del auditor y del auditado y
que pueden descubrir fallos de apreciación en el auditor.
- Estructura del informe final.- El informe comienza con la fecha de comienzo
de la auditoría y la fecha de redacción del mismo. Se incluyen los nombres
del equipo auditor y los nombres de todas las personas entrevistadas, con
indicación de la jefatura, responsabilidad y puesto de trabajo que ostente.
- Definición de objetivos y alcance de la auditoría.
- Enumeración de temas considerados.- Antes de tratarlos con profundidad,
se enumerarán lo más exhaustivamente posible todos los temas objeto de
la auditoría.
- Cuerpo de Recomendación.- Para cada tema, se seguirá el siguiente
orden, detallándose la observación realizada y la evidencia de la debilidad
identificada.
- Situación actual (Observación).- Cuando se trate de una revisión periódica,
en la que se analiza no solamente una situación sino además su evolución
en el tiempo, se expondrá la situación prevista y la situación real.
- Riesgo.- Se detallará el riesgo al no aplicar un control adecuado que
permita mitigar la debilidad y amenazas.
- Redacción de las recomendaciones y planes de acción.- Constituyen junto
con la exposición de puntos débiles, el verdadero objetivo de la auditoría
informática.
1.8.3.3.2 Redacción de la carta de introducción o carta de presentación del informe
final

19
La carta de introducción tiene especial importancia porque en ella ha de
resumirse la auditoría realizada. Se destina exclusivamente al responsable
máximo de la organización, o a la persona concreta que encargo o contrato la
auditoría. Así como pueden existir tantas copias del informe Final como solicite el
cliente, la auditoría no hará copias de la citada carta de Introducción.
El informe que será presentado a la gerencia debe incluir solamente hechos
importantes. La inclusión de hechos poco relevantes o accesorios desvía la
atención del lector.
El término de “hechos consolidados” adquiere un especial significado de
verificación objetiva y debe estar documentalmente probada y soportada con
evidencia ecuánime. La consolidación de los hechos debe satisfacer, al menos los
siguientes criterios:
• El hecho debe poder ser sometido a cambios,
• Las ventajas del cambio deben superar los inconvenientes derivados de
mantener la situación,
• No deben existir alternativas viables que superen al cambio propuesto,
• La recomendación del auditor sobre el hecho debe mantener o mejorar las
normas y estándares existentes en la instalación.
La identificación de un hecho en un informe de auditoría implica necesariamente
la existencia de una debilidad que ha de ser corregida.
• Flujo del Hecho o Debilidad
• Debilidad identificada.
o Ha de ser relevante para el auditor e implicar un riesgo para el
cliente.
o Ha de ser exacto, y además convincente.

20
o No deben existir hechos repetidos.
• Consecuencias de mantener la debilidad
o Las consecuencias deben redactarse de modo que sean
directamente deducibles del hecho.
• Repercusión del hecho
o Se redactará las influencias directas que la debilidad pueda tener
sobre otros aspectos informáticos u otros ámbitos de la empresa.
• Conclusión del hecho
o No deben redactarse conclusiones más que en los casos en que la
exposición haya sido muy extensa o compleja.
• Recomendación del auditor informático
o Deberá entenderse por sí sola, por simple lectura.
o Deberá estar suficientemente soportada en el propio texto.
o Deberá ser concreta y exacta en el tiempo, para que pueda ser
verificada su implementación.
o La recomendación se redactará de forma que vaya dirigida
expresamente a la persona o personas que puedan implementarla.
1.8.4 Clasificación de los controles TI
Control es todo aquello que tiende a causar la reducción de los riesgos. El
control puede lograr esto reduciendo ya sea los efectos nocivos del riesgo o la
frecuencia de su ocurrencia.
Las áreas de control dentro de un sistema computarizado incluyen
1.8.4.1 Controles De Aplicación

21
Los controles de aplicación son procedimientos diseñados para asegurar la
integridad de los registros. Los controles de aplicación brindan soporte
directamente a los objetivos de control:
- Integridad,
- Valor correcto,
- Validez y
- Acceso restringido.
1.8.4.1.1 Integridad de los registros.- Los controles sobre la integridad se diseñan
para asegurar que:
- Todas las transacciones son registradas, introducidas y aceptadas para
procesamiento solo por una vez.
- Todas las transacciones introducidas y aceptadas para procesamiento son
actualizadas con los archivos de datos apropiados.
- Una vez que los datos son actualizados en el archivo, estos permanecen
correctos, vigentes y representan los valores que existen.
1.8.4.1.2 Valor correcto de los registros.- Los controles sobre el valor correcto son
diseñados para asegurar que:
- Los elementos de datos claves son registrados e introducidos al
computador con el valor correcto.
- Los cambios a los datos existentes son introducidos con el valor correcto.
- Todas las transacciones introducidas y aceptadas para procesamiento
actualizan con precisión el archivo de datos apropiado.

22
1.8.4.1.3 Validez de los registros.- Los controles sobre la validez de los registros
son diseñados para asegurar que:
- Las transacciones son autorizadas.
- Las transacciones no son ficticias y están relacionadas con el cliente.
- Los cambios a los datos existentes son autorizados, y una vez
introducidos, no son cambiados sin autorización.
1.8.4.1.4 Acceso restringido a los activos y registros.- Los controles para restringir
el acceso son diseñados para:
- Proteger contra rectificaciones de datos no autorizadas.
- Asegurar la confidencialidad de los datos.
- Proteger los activos físicos tales como el efectivo y el inventario.
Los controles de aplicación pueden ser procedimientos manuales llevados a cabo
por los usuarios de procedimientos automatizados desarrollados por los
programas de computación.
1.8.4.2 Controles Generales
Los Controles Generales son “Controles diseñados e implantados para
asegurar que el ambiente computadorizado de la organización sea estable y
adecuadamente administrado a fin de reforzar la efectividad de los controles de
aplicación.
Los Controles Generales (a veces denominados también controles de la
organización IT) fueron agrupados en las siguientes categorías:
- Controles Gerenciales del Departamento de IT,

23
- Controles sobre la Seguridad de la Información,
- Controles sobre la Operación del Computador,
- Controles sobre las Actividades de Mantenimiento de Sistemas,
- Controles sobre el Desarrollo e Implementación de Nuevos Sistemas.
1.8.4.2.1 Controles Gerenciales del Departamento de IT.- Los controles de
monitoreo son definidos para verificar las normas teóricamente existentes en el
departamento de Informática y su coherencia con las del resto de la empresa, la
calidad del control interno y su ejecución sobre el tiempo, se logra a través de
actividades de monitoreo, separada de evaluaciones o una combinación de las
dos. Para ello, habrán que analizarse puntos de enfoque como:
• Ambiente de Control.- Controles fijados entorno a la organización, infundiendo
el conocimiento del control al personal de la empresa, este es la base para
todos los componentes del control interno, proporcionando disciplina y
estructura. Evaluando:
- Conducción del Departamento de TI,
- Importancia de los controles dentro de la función de TI,
- Roles y competencia de TI,
- Segregación de funciones y responsabilidades,
- Desarrollo, capacitación y remuneración del personal de TI,
• Valoración de Riesgo.- son los procesos de control que la entidad ha definido
para identificar y analizar los riesgos relevantes y lograr el éxito en la
consecución de los objetivos planteados por la empresa y por el departamento

24
de TI, creando una base para determinar como los riesgos podrían ser
administrados. Definiendo principalmente:
- Identificar los riesgos del negocio,
- Estimar la importancia de riesgo del negocio,
- Evaluar la probabilidad de ocurrencia,
- Administración de los cambios en los riesgos de IT,
- Mitigación del riesgo y el riesgo residual.
• Información y Comunicación.- método que apoya a la identificación, captura e
intercambio de información en un marco de forma y tiempo que facilita al
personal cumplir con sus responsabilidades, enfocado en:
- Disponibilidad y calidad de la información,
- Definición de responsables y propietarios de los datos por unidad del
negocio.
- Adquirir el "feedback" del personal de TI y de los usuarios finales.
• Controles de Monitoreo.- es el proceso para evaluar la calidad del control
interno y su cumplimiento en la empresa. Su propósito es asegurar que los
controles definidos continúan operando efectivamente, evaluando y validado
mediante:
- Calidad del monitoreo continuo, función de “Quality Assurance”,
- Cobertura y alcance de las revisiones de controles y cobertura apropiada
de los riesgos de TI,
- Comunicación de debilidades, de control interno de TI dentro de la
organización.

25
1.8.4.2.2 Controles sobre la Seguridad de la Información.- El objetivo principal de
comprender, evaluar y validar los controles sobre la seguridad de la información
es asegurar que solo se otorga acceso autorizado a los programas y datos solo si
se autentifica la identidad del usuario. Puntos de enfoque:
• Administración General de las Actividades de Seguridad.- La administración
general de las actividades de seguridad se encarga de proveer una estructura
y supervisión general del entorno de seguridad de la organización y los
controles relacionados, como:
- Adecuada segregación de Funciones de Seguridad,
- Documentación de roles y responsabilidades,
- Asegurar a la gerencia de que las políticas y procedimientos del personal
son apropiados para todos los roles sensitivos de seguridad de la
información,
- Informar periódicamente a los usuarios de TI y del negocio con respecto a
sus responsabilidades en materia de seguridad y las políticas y
procedimientos relacionados.
• Administración Centralizada de la Seguridad.- Las actividades de
administración centralizada de la seguridad deben asegurar que el acceso a
las aplicaciones, datos y sistemas operativos son otorgados, modificado y
eliminado de acuerdo con las solicitudes aprobadas recibidas del personal de
nivel apropiado de la gerencia. Identificados mediante:

26
- Asegurar que el proceso de administración de seguridad mediante la
aprobación por la gerencia de la unidad de negocios del acceso a todas las
aplicaciones y datos financieros relacionados de propiedad de esa unidad
de negocios,
- Revisiones periódicas del acceso a los usuarios por parte de la gerencia de
la unidad de negocio, para asegurar que el acceso otorgado siga siendo el
adecuado.
• Seguridad de los Datos.- Los controles definidos deben asegurar que el
acceso directo a los datos está limitado al personal autorizado de manera
apropiada y es monitoreado para detectar una posible actividad no autorizada.
Actividades evaluar y validar:
- Asegurar que todos los métodos de acceso directo a los datos (es decir,
acceso desde fuera de la aplicación) han sido definidos y documentados.
- Como los cambios directos realizados en los archivos de datos son
debidamente controlados,
- Monitoreo de posibles actividades no autorizadas, resoluciones cuando
estas han sido identificadas.
• Seguridad de la Red Interna.- Los controles sobre la seguridad de la red
interna deben asegurar qua la red está configurada y es monitoreada para
proteger los programas y datos de accesos no autorizados, mediante:
- Controles para asegurar adecuados cambios en el diseño de la red interna.
- Respalda el diseño de la red los objetivos de integridad de la información
generales de la organización (separación lógica de dominios, uso de

27
VLAN´s, autenticación de computadoras remotas, administración del
enrutador, etc.)
- Monitoreo de posibles incidentes de seguridad en la red interna, y cómo
responde a ellos.
• Seguridad de la Red Perimetral.- Mediante los controles definidos para la Red
Perimetral deben asegurar que la red está configurada y es monitoreada para
proteger los programas y datos de accesos no autorizados. Por medio de:
- Justificación de negocios para cada conexión a la red externa (Internet,
correo electrónico, EDI, EFT, discado directo, socios extranet, etc.),
- Los controles sobre las conexiones a la red externa están diseñadas para
lograr los objetivos planteados,
- Método adoptado para proteger a la red interna de los accesos no
autorizados a través de conexiones,
- Monitoreo de posibles incidentes de seguridad a través de conexiones a la
red externa.
• Seguridad Física.- Son controles operativos importantes que ayudan a
asegurar que los sistemas de una organización están protegidos de accesos
no autorizados, mediante:
- Restricción del acceso físico al establecimiento/edificio de la organización
(considerar cualquier lugar en el que se encuentren equipos de
computación y también cualquier lugar conectado con esos equipos a
través de las redes internas de la organización),
- Restricción de acceso físico a los centros de cómputos locales y remotos

28
- Acceso físico restringido a los medios de almacenamiento removibles (tales
como cintas, discos ópticos, etc.)
1.8.4.2.3 Controles sobre la Operación del Computador.- El objetivo dominante
para las operaciones del computador es asegurar que los sistemas de producción
se procesan en forma completa y correcta de acuerdo con los objetivos que
gerencia ha definido, que los problemas de procesamiento son identificados y
resueltos en forma completa y correcta para mantener la integridad de los datos.
• Administración General de las Actividades de Operaciones
computadorizadas.- Proveen de una estructura y supervisión a las actividades
de operaciones computadorizadas de la organización, definiendo controles a
evaluar tales como:
- Documentar y comunicar las políticas y procedimientos para operaciones
computadorizadas,
- Definición de roles y responsabilidades en las operaciones, adoptando
medidas de segregación de funciones,
- Programas adecuados de capacitación técnica a los empleados,
- Monitoreo adecuado para asegurar que los problemas operativos
potenciales son identificados y resueltos.
• Administración de Procesos Batch.- el procesamiento de procesos batch o por
lotes debe asegurar que los trabajos de producción autorizados son
organizados y monitoreados de manera apropiada, y que las excepciones son

29
resueltas en forma completa y correcta de acuerdo con los objetivos de la
gerencia. Para lo cual se debería evaluar y validar como mínimo:
- Monitoreo de la gerencia para asegurar el procesamiento de trabajos para
asegurar que se ejecuta de acuerdo con la programación de trabajos
aprobada.
- Aseguramiento de que sólo personal autorizado tiene acceso a la
herramienta de programación de trabajos por lotes.
- Monitoreo de la gerencia a las dependencias de trabajos y los
procedimientos de reinicio/recuperación son documentados para todos los
trabajos en la programación por lotes.
- Aseguramiento de altas, cambios y bajas de la programación de trabajos
son autorizados y completados oportunamente.
• Procesamiento en Tiempo Real.- Los controles sobre el procesamiento en
tiempo real deben asegurar que la transmisión y registro continuos de los
datos de transacciones ocurren en forma completa y correcta de acuerdo con
los objetivos de la gerencia. Los siguientes puntos de enfoque pueden resultar
útiles para identificar las actividades a evaluar y validar:
- Sólo personal autorizado tiene acceso para configurar cualquier
componente de la tecnología utilizada para facilitar el procesamiento en
tiempo real.
- Proceso para asegurar que todas las fallas en el procesamiento en tiempo
real son capturadas y resueltas oportunamente.

30
- Certifica la gerencia que los cambios en la configuración de los
componentes del procesamiento en tiempo real son autorizados y
completados oportunamente.
• Backups y Procesos de Recuperación.- Son implementados para asegurar
que los requerimientos de backup están definidos de modo de garantizar que
los datos estén disponibles cuando son necesarios, que los problemas que
requieren resolución son identificados oportunamente y que la recuperación de
esos problemas es realizada en forma completa y correcta.
- Contenido y frecuencia de la obtención de backups, los datos coinciden
con los objetivos del negocio,
- Cerciora la gerencia que los medios de backup estarían disponibles en
caso de emergencia,
- Existe un medio de almacenamiento de Backups fuera de las instalaciones
de la empresa y bajo estrictas medidas de seguridad,
- El proceso de obtención de backups asegura que los datos pueden
recuperarse conforme a lo previsto de los medios cuando sea necesario,
- Se certifica que todas las fallas operativas significativas son identificadas y
resueltas oportunamente en forma completa y correcta.
• Planes de Contingencias.- Los planes de contingencias en una empresa
ayudan a garantizar que una organización podrá continuar con sus
operaciones en caso de desastre. Los controles se deberán evaluar y validar
si la recuperación en caso de desastre se considera relevante debido a

31
requisitos de entes reguladores del territorio y/o un impacto significativo en el
principio de empresa en marcha, evaluar y validar por medio de:
- Mitiga la empresa riesgos ambientales (incendio, humo, agua, electricidad,
temperatura, humedad, etc.) en los establecimientos de computación
importantes de manera apropiada,
- Se realiza un análisis de impacto en el negocio o una evaluación de riesgo
similar para asegurar que existen planes de recuperación en caso de
desastre y las pruebas relacionadas para todas las aplicaciones
significativas y los respectivos componentes de la tecnología,
- El plan de contingencias definido por la empresa es probado anualmente,
- De existir algún cambio este es actualizado y comunicado al personal
afectado.
1.8.4.2.4 Controles sobre las Actividades de Mantenimiento de Sistemas.- Los
cambios o mantenimientos en los sistemas se pueden realizar por personal
interno como externo del departamento de sistemas, los controles definidos para
las actividades de mantenimiento tienen como objetivo, asegurar que los cambios
y los componentes de la infraestructura relacionada sean debidamente
solicitados, priorizados, realizados aprobados e implementados de acuerdo a los
objetivos de la gerencia y principalmente de la empresa. La eficacia de los
controles definidos para las actividades de administración de cambios en los
sistemas pueden ser verificados mediante los siguientes puntos de enfoque:
• Administración General de las Actividades de Cambios en los Programas.- A
nivel general se busca proveer una estructura y supervisión a las actividades

32
de administración de cambios en los sistemas para la organización. Evaluando
y validando los siguientes puntos:
- Cómo se documentan y comunican políticas y procedimientos de
administración de cambios,
- Definición de los roles y responsabilidades en la administración de
cambios,
- Asegura la gerencia que se aplica un proceso uniforme para todos los
cambios en los sistemas en todos los programas de aplicación,
componentes de infraestructura, unidades de administración y
establecimientos,
- Evalúa la gerencia la calidad funcional y operativa de sus sistemas,
- Monitorea la gerencia el cumplimiento de los controles implantados sobre
cambios en los programas.
• Solicitud de Cambio.- Los controles que se definen para probar los controles
sobre los cambios permiten asegurarse que las solicitudes de los usuarios
son capturadas, autorizadas y rastreadas hasta completadas de acuerdo con
los objetivos marcados por la gerencia de sistemas. Verificar los controles
definidos para validar la adecuada administración de los cambios mediante:
- Afirma la gerencia de que todas las solicitudes de cambios de los usuarios
son capturadas,
- Se asegura la gerencia de que todas las solicitudes de cambios de los
usuarios son autorizadas,

33
- Prioriza la gerencia sus actividades de cambios en los programas para
garantizar que las solicitudes de más alta prioridad sean completadas en
primer término,
• Construcción.- Los controles mínimos necesarios para asegurar que los
cambios se realizan de acuerdo a los objetivos planteados se debe validar:
- Se aplica el uso uniforme de los estándares de programación para las
aplicaciones desarrolladas internamente,
- Se consideran de manera uniforme los riesgos asociados con las
modificaciones a los paquetes de software,
- Monitorea la gerencia que se aplican los estándares relevantes para los
sistemas desarrollados internamente y los sistemas en paquete.
• Pruebas y Control de Calidad.- Mediante los controles sobre las pruebas y
control de calidad se debe asegurar que el personal apropiado lleva a cabo un
nivel adecuado de pruebas para determinar que el programa continúa
funcionando según lo previsto de acuerdo con los objetivos de la organización.
Puntos de enfoque para realizar la revisión:
- Analiza la gerencia de que las pruebas realizadas prueban el cambio
efectuado, así como la funcionalidad significativa dentro del sistema que no
debería haber cambiado,
- Se obtiene evidencia de la aceptación de los usuarios del cambio antes de
la implantación en producción,
- Mitiga la gerencia el riesgo de que los programas no sean modificados
después de las pruebas sino antes de la implantación en producción,

34
- Controla la gerencia la migración del código entre los entornos lógicos
desarrollo y producción.
• Implementación de los Cambios.- Los controles establecidos en las
actividades de implementación de los cambios permiten asegurar que los
cambios son solo implementados en el entorno de producción por el personal
apropiado, luego de haberse realizado pruebas y de haberse obtenido la
aprobación de la administración de usuarios del negocio. Los siguientes
puntos de atención pueden resultar útiles para identificar las actividades a
evaluar y validar:
- Asegura la gerencia de que todas las implantaciones de programas son
aprobadas por la administración de TI y de usuarios del negocio,
- Se aplica un proceso uniforme al implantar cambios en la producción,
- Los cambios emergentes son capturados, documentados y aprobados
luego de su implantación en producción,
- Sólo el personal apropiado y autorizado tiene acceso para pasar los
cambios en los programas al entorno de producción,
- Controla la gerencia la versión del programa implantada en producción es
la versión más reciente probada y aprobada por la administración de
usuarios del negocio,
- Si el programa corre en varios sitios, asegura la gerencia de que todas las
copias del programa fueron actualizadas con la versión correcta.
• Documentación y Capacitación.- Los controles definidos para deben asegurar
que la documentación y capacitación del usuario final y de soporte TI son

35
actualizadas junto con la implantación de los cambios en los programas.
Considerar como puntos a evaluar y validar: La documentación para usuarios
y técnica es actualizada en función de todos los cambios a sus sistemas,
- Asegura la gerencia de que la documentación actualizada está disponible
en el momento de la implantación,
- Los usuarios y el personal de IT reciben capacitación adecuada sobre los
cambios significativos en los sistemas.
1.8.4.2.5 Controles sobre el Desarrollo e Implementación de Nuevos Sistemas.- El
objetivo dominante verificar los controles establecidos para el desarrollo de
programas es, asegurar que los sistemas son desarrollados, configurados e
implantados para cumplir con los objetivos de la gerencia planteados por el
negocio. La eficacia de los controles definidos para las actividades de desarrollo e
implementación de nuevos sistemas pueden ser verificados mediante los
siguientes puntos de enfoque:
• Administración General de las Actividades de Desarrollo de Programas.- La
administración general de las actividades de desarrollo de programas provee
estructura y supervisión a las actividades de desarrollo de programas de la
organización. Las cuales pueden ser evaluadas y validadas mediante los
- Existe una metodología de desarrollo de sistemas formal,
- Asegura la gerencia de que se desarrollan planes de proyecto detallados
para todos los proyectos,

36
- Se realizan evaluaciones de factibilidad para los nuevos desarrollos
aprobados por la gerencia,
- Los promotores del negocio y líderes de proyecto de TI definen y acuerdan
los productos a entregar,
- Revisa la gerencia periódicamente el estado de los proyectos en curso,
- Documentó y comunicó la gerencia los roles y responsabilidades en el
desarrollo de programas,
- Monitorea la gerencia las actividades de desarrollo de programas.
• Inicio de Proyectos.- Los controles sobre el inicio de proyectos deben
asegurar que los proyectos son planificados, equipados y movilizados de
manera uniforme. Verificar y validar los controles definidos para el inicio de
proyectos:
- Se realizan adecuadamente análisis de factibilidad,
- Se identifican promotores del negocio y dueños de los datos para todos los
proyectos,
- Asegura la gerencia de que cada equipo de proyecto posee las destrezas
de negocios y tecnológicas requeridas para realizar el desarrollo.
• Análisis y Diseño.- Los controles sobre el análisis y el diseño para nuevos
desarrollos deben asegurar que los requerimientos son definidos y los
sistemas son diseñados para lograr los objetivos propuestos por la gerencia
sin afectar el desempeño actual de los sistemas. Evaluar y validar los

37
controles definidos para el análisis y diseño de nuevos sistemas mediante los
- Asegura la gerencia de que los requerimientos del sistema son
desarrollados de manera uniforme con suficiente detalle,
- El equipo de desarrollo del proyecto considera las dependencias de
sistemas e interfaces, los requerimientos de control interno y los
requerimientos de seguridad para cada proyecto,
- Se ha obtenido la aprobación del promotor del negocio antes de pasar a la
fase de construcción del proyecto.
• Construcción y Selección de de Paquetes de Desarrollo.- Los controles sobre
la construcción y selección de paquetes deben asegurar que las actividades
de desarrollo de programas internos y la selección de software en paquete son
realizadas de manera uniforme de acuerdo con los objetivos que ha definido
la gerencia. Evaluar y validar mediante los siguientes controles:
- La gerencia asegura el uso uniforme de los estándares de programación
para las aplicaciones desarrolladas internamente,
- Se asegura la gerencia de la aplicación uniforme de los pasos requeridos
para la selección, adaptación a medida e implantación de los paquetes de
software adquiridos,
- Se aplican los estándares relevantes para los sistemas desarrollados
internamente y en paquete.

38
• Pruebas y Control de Calidad.- Los controles sobre las pruebas y el control de
calidad deben asegurar que el personal apropiado realiza un nivel adecuado
de pruebas para determinar que el nuevo sistema funciona según lo previsto.
Verificar y validar los controles definidos mediante los siguientes puntos de
enfoque:
- Asegura la gerencia de que los planes de prueba responden a los
requerimientos definidos en la fase de análisis y diseño,
- Cómo certifica la gerencia de que no se modifican los programas después
de las pruebas y antes de la implantación en producción,
- Se realiza una migración controlada del código entre los entornos lógicos.
• Conversión de Datos.- Los controles sobre la conversión de datos deben
asegurar que los datos se convierten en forma completa y correcta a los
nuevos sistemas. Evaluar y validar controles mediante:
- Se realiza un mapeo correcto de los campos de datos entre los sistemas
heredados y los futuros,
- Asegura la gerencia de que los datos convertidos son y siguen siendo
completos, correctos y válidos,
- Se verifica que las interfaces de sistemas críticas son consideradas en los
planes de conversión de datos.
• Implementación de Programas.- Los controles sobre la implantación de
programas deben asegurar que los nuevos sistemas sólo son implantados en

39
el entorno de producción luego de haberse realizado pruebas adecuadas, de
haberse obtenido la aprobación del promotor del negocio y de haberse
desarrollado planes de implantación y "backout" (eliminación de
actualizaciones fallidas). Evaluar y validar controles mediante:
- Se verifica que todas las implantaciones de programas son aprobadas por
promotores del negocio y la gerencia de IT,
- Se aplica un proceso uniforme cuando se adoptan todas las decisiones de
traspaso al entorno de producción (planes de implantación, procedimientos
de "backout"),
- Se verifica que la versión del programa implantada en producción es la
más reciente, probada y aprobada por los promotores del negocio,
Si el programa corre en varios establecimientos, se asegura que todas las
copias del programa fueron actualizadas con la versión correcta.
• Capacitación y Documentación.- Los controles sobre la documentación y la
capacitación deben asegurar que los usuarios finales y el personal de soporte
técnico reciban la documentación y capacitación adecuada junto con la
implantación del programa. Los siguientes puntos de enfoque pueden resultar
útiles para identificar las actividades a evaluar y validar:
- Se desarrolla documentación técnica y para el usuario para todos los
nuevos sistemas,
- La documentación está disponible en el momento de la implantación,

40
- Los usuarios y el personal de TI recibe capacitación adecuada en todos los
nuevos sistemas,
1.8.4.3 Matriz De Evaluación De Controles
Para evaluar y validar los controles definidos en el departamento de TI, se
debe considerar el entendimiento de los procesos del negocio para determinar los
ambientes computacionales y sistemas relevantes para realizar la revisión,
puede haber uno o más ambientes o sistemas, dependiendo de la complejidad y
el nivel técnico de la organización auditada.
Los controles específicos de cada área son normalmente una mezcla de controles
manuales y automáticos. Por ejemplo, los controles que aseguran la apropiada
seguridad dentro de los sistemas de información, es un control automático que
restringe el “Acceso de Usuarios” a los utilitarios o herramientas sensitivas del
sistema. Sin embargo, la funcionalidad y efectividad de estos controles
automáticos dependen de los controles manuales para garantizar que las
opciones habilitadas manualmente al usuario corresponden a sus
responsabilidades y necesidades según el cargo que ocupa en la empresa. Cada
una de las cuatro áreas: seguridad, operaciones, mantenimiento y desarrollo
podrían ser evaluadas, sin embargo, la naturaleza y extensión de las pruebas de
controles generales podría depender de los siguientes factores:
- Complejidad de los ambientes y controles,
- Amplitud y cobertura que un control proporciona,
- Alcance del riesgo y aseguramiento requerido,
- Extensión del los cambios del sistema,

41
- La efectividad de la administración de la organización sobre los sistemas
de información y actividades de tecnología.

42
CAPÍTULO II
MODELO COBIT
2.1 INTRODUCCIÓN
COBIT (Objetivos de Control para Tecnología de Información y Tecnologías
relacionadas), fue lanzado por primera vez en septiembre de 1996, su segunda
edición en Abril de 1998, la tercera en marzo del 2000 y su última versión (COBIT
4.1) en el primer semestre del año 2007. El modelo es el resultado de una
investigación con expertos de varios países, desarrollado por ISACA (Information
Systems Audit and Control Association).
COBIT es un estándar generalmente aplicable y aceptado para las buenas
prácticas en seguridad tecnológica, en la administración y control de la tecnología
de la información (TI).
COBIT Integra y concilia normas y reglamentaciones existentes como: ISO
(9000-3)1
, Códigos de Conducta del Consejo Europeo2
, COSO3
, IFAC4
, IIA5
,
AICPA6
, ISACA y Otras.
El COBIT inicia con la simple premisa de proveer la información necesaria para
lograr sus objetivos, una organización debe administrar sus recursos de TI a
través de un conjunto de procesos agrupados naturalmente.
1
ISO(9000-3):
2
Códigos de Conducta del Consejo Europeo
3
COSO: (Committee of Sponsoring Organizations), de la Comisión de Estudios de Controles Internos.
4
IFAC: FEDERACIÓN INTERNACIONAL DE CONTADORES PÚBLICOS
5
IIA: Instituto de Auditores Internos
6
AICPA: Instituto Americano de Contadores Públicos Certificados

43
Los grupos COBIT procesan en una jerarquía simple orientada al negocio.
Cada proceso se relaciona con los recursos de TI, y los requerimientos de
seguridad, fiduciarios, y de calidad para la información.
Como el COBIT está orientado al negocio, es directo su uso para comprender
los objetivos de control de TI con el fin de administrar los riesgos del negocio
relacionados con la misma de la siguiente forma:
- Inicie con los objetivos de su negocio en el Marco de Referencia,
- Seleccione los procesos y controles de TI adecuados para su empresa de
los Objetivos de Control
- Opere desde su plan de negocio
- Evalúe sus procedimientos y resultados con las Directrices.
- Evalúe el estado de su organización identificando actividades críticas
necesarias para el éxito.
- Mida el desempeño en busca de las metas de la empresa con Las
Directrices Gerenciales.
El modelo de referencia COBIT es adaptable a cualquier tipo de negocio y los
objetivos definidos pueden ser aplicados independientemente del ambiente,
plataformas y madurez tecnológica de la organización. El conjunto de guías y
materiales COBIT proveen un marco referencial y un lenguaje común para la
administración de sistemas de información, la auditoría de sistemas de
información, las prácticas de control y la seguridad de la información, a lo largo
del ciclo de vida de los sistemas de información. COBIT puede ser integrado con
otros estándares en ciertas áreas entre los cuales están: ISO177997
, ISO90008
,
ITIL9
, CMM10
.
8
ISO 17799: Es una norma internacional que ofrece recomendaciones para realizar la gestión de la seguridad de la información dirigidas
a los responsables de iniciar e implantar o mantener la seguridad de una organización.

44
Es aplicable a los sistemas de información de toda empresa e incluso en
ambientes distribuidos, esta herramienta ha cambiado la forma en que trabajan
los profesionales de TI. Vinculando tecnología informática y prácticas de control,
proveyendo así de información pertinente y confiable. COBIT consolida y
armoniza estándares de fuentes globales prominentes en un recurso crítico para
la gerencia, los profesionales de control y los auditores.
Los lineamientos y estándares COBIT está estructurado por 4 dominios
principales de administración, los cuales a su vez implican 34 procesos de
administración asociados con la tecnología de la información de acuerdo a COBIT
3rd
Edition.
• Planificación y organización
• Adquisición e implantación
• Soporte y servicios
• Monitoreo
Cada proceso TI provee una descripción de los requerimientos del negocio e
identifica los asuntos claves que deben ser llevados a cabo para administrar
exitosamente estos procesos.
CobiT es una compilación de las mejores prácticas globales, obtenidas de un
amplio espectro de fuentes, como:
§ Estándares Técnicos de ISO, EDIFACT11
, etc.
§ Códigos de Conducta emitidos por el Consejo de Europa, OECD12
, ISACA,
etc.
9
ISO9000: Son directrices para que una organización pueda lograr la calidad de un producto o servicio de manera que las necesidades
del cliente sean satisfechas.
10
ITIL: Conjunto de bibliotecas que reúnen las mejores prácticas para la gestión de servicios de IT agrupadas en dos áreas Soporte al
Servicio, Entrega al Servicio.
11
CMM: Modelo de madurez para las etapas de desarrollo de aplicaciones define 5 niveles siendo el 1 los más bajo y 5 el nivel ideal.
11
EDIFACT: Electronic Data Interchange for Administration, Transport and Commerce

45
§ Criterios de evaluación de calidad de Sistemas IT y procesos: ITSEC13
,
TCSEC, ISO 9000, SPICE, TickIT, Common Criteria, etc.
§ Estándares profesionales para control interno y auditoría: COSO, IFAC,
AICPA, CICA, ISACA, IIA, PCIE, GAO, etc.
§ Prácticas de la industria y requerimientos de foros industriales: (IBAG,
NIST, DTI), etc.
§ Requerimientos específicos de industrias incluyendo bancos, comercio
electrónico y manufactura.
COBIT a significado el inicio de los cambios de perspectiva de control interno
relacionada al área tecnológica, el objetivo principal de COBIT es el desarrollo de
políticas claras y buenas prácticas para la seguridad y el control de Tecnología de
Información (TI), con el fin de obtener la aprobación y el apoyo de las entidades
comerciales, gubernamentales y profesionales en todo el mundo. La meta es
desarrollar estos objetivos de control principalmente a partir de la perspectiva de
los objetivos y necesidades de la empresa.
12
OECD: Organization por Economic Co-operation and Development
13
ITSEC: Information Technology Security Evaluation Criteria

46
2.2 CONTENIDO (PRODUCTOS COBIT)
Fig.2. 1 Productos de la Familia COBIT
2.2.1 Resumen Ejecutivo
En esta sección se presentan antecedentes y un resumen ejecutivo, con el fin
de proporcionar a la alta gerencia entendimiento y conciencia sobre los conceptos
clave y principios del modelo COBIT. Este resumen está dirigido a principiantes en
el uso de COBIT así como a expertos administradores.

47
2.2.2 Marco Referencial
Proporciona a la alta gerencia un entendimiento más detallado de los
conceptos clave y principios de COBIT, describiendo en detalle los 34 objetivos de
control de alto nivel e identifica los requerimientos de negocio para la información
y los recursos de TI que son impactados en forma primaria por cada objetivo de
control agrupándolos en los cuatro dominios (Planeación y Organización,
Adquisición e Implementación, Entrega de servicios y Soporte y Monitoreo)
Fig.2. 2 Resumen de Dominios de COBIT con objetivos de control
• Planeación y Organización.- 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.
Requerimientos
del Negocio
Monitoreo
Información
Planeación y Organización
Entrega y Soporte
Recursos
Adquisición e
Implementación
Efectividad
Eficiencia
Confidencialidad
Integridad
Disponibilidad
Cumplimiento
Confiabilidad
Gente
Aplicaciones
Tecnología
Instalaciones
Datos
Definir un Plan Estratégico
Definir la Arquitectura de la Información
Determinar la Dirección Tecnológica
Definir la Organización y sus Relaciones
Administrar la Inversiones (en TI)
Comunicar la dirección y objetivos gerenciales
Administrar los Recursos Humanos
Asegurar el apego de disposiciones externas
Evaluar Riesgos
Administrar Proyectos
Administrar Calidad
Monitorear el proceso
Evaluar el Control Interno
Obtener Aseguramiento Independiente
Proporcionar auditoría Independiente
Definir Niveles de Servicio
Administrar Niveles de Servicio
Administrar desempeño y capacidad
Asegurar continuidad de servicio
Garantizar la seguridad de sistemas
Identificar y asignar costos
Educar y Capacitar a usuarios
Apoyar y orientar a clientes
Administrar la configuración
Administrar problemas e incidentes
Administrar la información
Administrar las instalaciones
Administrar la operación
Identificar sistemas automatizados
Adquirir y mantener software de aplicación
Adquirir y mantener la arquitectura tecnológica
Desarrollar y mantener procedimientos
Instalar y acreditar sistemas de información
Administrar cambios
RReeqquueerriimmiieennttooss
ddee NNeeggoocciioo
PPrroocceessooss yy
DDoommiinniiooss
ddee TTII
RReeccuurrssooss ddee
TTII

48
Finalmente, deberán establecerse una organización y una infraestructura
tecnológica apropiadas.
• Adquisición e Implementación.- 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.
• Entrega y Soporte.- En este dominio hace referencia a la entrega de los
servicios requeridos, que abarca desde las operaciones tradicionales hasta
el entrenamiento, pasando por seguridad y aspectos de continuidad. Con el
fin de proveer servicios, deberán establecerse los procesos de soporte
necesarios. Este dominio incluye el procesamiento de los datos por
sistemas de aplicación, frecuentemente clasificados como controles de
aplicación.
• Monitoreo.- Todos los procesos necesitan ser evaluados regularmente a
través del tiempo para verificar su calidad y suficiencia en cuanto a los
requerimientos de control.
Este marco referencial de CobIT® está orientado hacia el entendimiento, de
que la administración y control adecuados de TI se llevan a cabo identificando la
información necesaria para soportar los procesos del negocio (Requerimientos del
Negocio) y a su vez considerando a la información como el resultado de la

49
aplicación combinada de los recursos informáticos (Recursos TI) disponibles, para
ser administrados por los procesos TI (Procesos y Dominios TI).
Fig.2. 3 Integración de Requerimientos del Negocio – Procesos y Dominios IT –
Recursos IT
2.2.3 Objetivos de Control
Los objetivos de Control en TI especifican los resultados o propósitos que se
desean alcanzar implementando procedimientos de control específicos dentro de
una actividad de TI.
Este documento proporciona 318 objetivos de control genéricos, agrupados
por los 34 objetivos de control de alto nivel del marco referencial, se identifica
cuales son las necesidades que deben ser administradas y objetivos de control en
cada proceso de IT, los mismos que ayudan a definir políticas claras y buenas
prácticas para el control aplicables a cada proceso IT.
RReeqquueerriimmiieennttooss
DDee NNeeggoocciioo
RReeccuurrssooss ddee TTII
PPrroocceessooss yy DDoommiinniiooss
DDee TTII

50
Fig.2. 4 Objetivos de Control-Resumen
2.2.4 Directrices de Auditoría
Contienen los pasos de auditoría correspondientes a cada uno de los 34
objetivos de control de TI de alto nivel para proporcionar asistencia a los auditores
de sistemas en la revisión de los procesos de TI con respecto a los 318 objetivos
detallados de control recomendados para proporcionar a la gerencia certeza o
recomendaciones de Mejoramiento, ayudando con ello a la mejor aplicación del

51
Marco Referencial y los Objetivos de Control COBIT contando con una estructura
sencilla para auditar y evaluar controles, con base en prácticas de auditoría
generalmente aceptadas y compatibles con el esquema global COBIT.
Estas Directrices de Auditoría proporcionan orientaciones para preparar planes
de auditoría que se integran al Marco Referencial COBIT y a los Objetivos de
Control detallados. Deben ser usados conjuntamente con estos dos últimos, y a
partir de ahí pueden desarrollarse programas específicos de auditoría.
2.2.5 Guías de Administración O Directrices Gerenciales
Contienen modelos de madurez, además sirven para determinar en que
posición se encuentra la organización, determinando el estado y los niveles de
control esperados y compararlos con las normas de la industria; Factores Críticos
de Éxito, en base a benchmarkings, para lo cual se necesitan escalas adecuadas
de comparación, con el fin de obtener datos lo más reales posibles e identificar las
acciones más importantes para lograr control sobre los procesos de TI; Los
Indicadores Clave de Logros de Objetivos, para identificar los niveles de
rendimiento deseados; y los Indicador Clave de Desempeño, para medir si un
control TI está cumpliendo sus objetivos.
Las guías de administración proveen factores críticos de éxito y cuáles son las
mejores prácticas administrativas para alcanzar los objetivos de control en IT.
2.2.6 Prácticas de Control
Las prácticas de control ayudan al personal encargado de diseñar e
implementar controles específicos para administrar riesgos en proyectos de IT,

52
están orientadas a la acción y explican la razón de su aplicación, las prácticas de
control ayudan a mejorar el rendimiento de IT ya que proveen guías que permiten
conocer que controles son necesarios y cuáles son las mejores prácticas para
alcanzarlos.
2.2.7 Conjunto de Herramientas de Implementación
El conjunto de herramientas de implementación son el resultado de las
mejores lecciones aprendidas por medio de la aplicación del COBIT de forma
exitosa en empresas, pudiendo así ser reutilizadas en otras organizaciones que
deseen implementarlo.
El Conjunto de Herramientas de Implementación incluye la Síntesis Ejecutiva,
que pretende proporcionar a la alta gerencia conciencia y entendimiento de
COBIT. Adicional a ello incluye una guía de implementación con dos útiles
herramientas: Diagnóstico de la Conciencia de la Gerencia (Management
Awareness Diagnostic y el Diagnóstico de Control de TI (IT Control Diagnostic)
para proporcionar asistencia en el análisis del ambiente de control en TI de una
organización.
También se incluyen varios casos de estudio que detallan como organizaciones
en todo el mundo han implementado COBIT exitosamente. Adicionalmente, se
incluyen respuestas a las 25 preguntas más frecuentes acerca de COBIT y varias
presentaciones para distintos niveles jerárquicos y audiencias dentro de las
organizaciones.

53
2.3 DOMINIO DE PLANEACIÓN Y ORGANIZACIÓN
Para asegurar el éxito de una empresa, se debe administrar adecuadamente la
interdependencia entre los procesos del negocio y los sistemas de información, de
esta manera la administración del riesgo y la seguridad sobre los procesos IT es
dependiente de las prácticas administrativas del negocio.
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.
A continuación se detalla los objetivos contenidos dentro de los Objetivos de
alto nivel correspondientes al dominio de Planeación y Organización, que será
objeto de la presente tesis.
El Domino de Planeación y Organización se enfoca a evaluar a la
organización, en este caso la ESPE, como a la Gerencia de Tecnología (UTIC) en
cuanto esta es parte integral del éxito de la Gerencia de la Empresa al asegurar
mejoras medibles, eficientes y efectivas de los procesos relacionados de la
empresa. El Gobierno de TI 14
provee las estructuras que unen los procesos de TI,
los recursos de TI y la información con las estrategias y los objetivos de la
empresa. Además, el Gobierno de TI integra e institucionaliza buenas (o mejores)
prácticas de planeación y organización, adquisición e implementación, entrega de
servicios y soporte y monitorea el desempeño de TI para asegurar que la
14
Gobierno de TI (IT Governance) Governance es un término que representa el sistema de control o administración que
establece la alta gerencia para asegurar el logro de los objetivos de una Organización.

54
información de la empresa y las tecnologías relacionadas soportan sus objetivos
del negocio.
El dominio de Planeación y Organización encamina al Gobierno de TI a
conducir a la empresa a tomar total ventaja de su información logrando con esto
maximizar sus beneficios, capitalizar sus oportunidades y obtener ventaja
competitiva.
2.3.1 Definición de un Plan Estratégico de Tecnología de Información
Organizaciones exitosas aseguran la interdependencia entre su plan
estratégico y sus actividades de TI. TI debe estar alineado y debe permitir a la
empresa tomar ventaja total de su información para maximizar sus beneficios,
capitalizar oportunidades y ganar ventaja competitiva.
Observando en el contexto a la empresa y los procesos del Gobierno de TI
con mayor detalle, el gobierno de la empresa, el sistema por el cual las entidades
son dirigidas y controladas, direcciona y analiza el Gobierno de TI. Al mismo
tiempo, TI debería proveer insumos críticos y constituirse en un componente
importante de los planes estratégicos. De hecho TI puede influenciar las
oportunidades estratégicas de la empresa.
Fig.2. 5 Actividades de TI

55
Las empresas son gobernadas por buenas (mejores) prácticas
generalmente aceptadas para asegurar que la empresa cumpla sus metas
asegurando que lo anterior esté garantizado por ciertos controles.
También TI es gobernado por buenas (o mejores) prácticas para asegurar
que la información de la empresa y sus tecnologías relacionadas apoyan sus
objetivos del negocio, estos recursos son utilizados responsablemente y sus
riesgos son manejados apropiadamente. Estas prácticas conforman una base
para la dirección de las actividades de TI; para los propósitos duales como son el
manejo de riesgo (para obtener seguridad, confiabilidad y cumplimiento) y la
obtención de beneficios (incrementando la efectividad y eficiencia). Los reportes
son enfocados sobre los resultados de las actividades de TI, los cuales son
medidos contra diferentes prácticas y controles y el ciclo comienza otra vez.
Fig.2. 6 Actividades de la Gerencia de la Empresa
Este Objetivo de Control contiene los siguientes requerimientos:

56
- Se requiere una planeación estratégica de TI para administrar y dirigir
todos los recursos de TI de acuerdo con la estrategia del negocio y las
prioridades.
- La función de TI y los participantes del negocio son responsables de
garantizar que se materialice el valor óptimo de los portafolios de proyectos
y servicios.
- El plan estratégico debe mejorar el entendimiento de los interesados clave
respecto a las oportunidades y limitaciones de TI, evaluar el desempeño
actual y aclarar el nivel de inversión requerido.
- La estrategia de negocio y las prioridades se deben reflejar en los
portafolios y deben ser ejecutadas por los planes tácticos de TI, los cuales
establecen objetivos, planes y tareas específicas, entendidas y aceptadas
tanto por el negocio como por TI.
Lo anteriormente citado, se evaluara en base al siguiente proceso:
Control sobre el proceso de TI de:
Definición de un plan Estratégico de TI
Que satisface los requerimientos del negocio de:
Lograr un balance óptimo entre las oportunidades de tecnología de información y
los requerimientos del negocio para TI, así como para asegurar sus logros futuros.
Se hace posible a través de:
Un proceso de planeación estratégica emprendido en intervalos regulares dando
lugar a planes a largo plazo.
Los planes a largo plazo deberán ser traducidos periódicamente en planes
operacionales estableciendo metas claras y concretas a corto plazo y toma en
consideración:

57
- Estrategia del negocio de la empresa
- Definición de cómo TI soporta los objetivos de negocio
- Inventario de soluciones tecnológicas e infraestructura actual
- Monitoreo del mercado de tecnología
- Estudios de factibilidad oportunos y chequeos con la realidad
- Análisis de los sistemas existentes
- Posición de la empresa sobre riesgos, en el proceso de compra (time-on-
market), calidad
- Necesidades de la Administración senior en el proceso de compra,
soportado en revisión crítica15
2.3.2 Definición de la Arquitectura de Información
El control de Definir la Arquitectura de Información que se encamina al
cumplimiento del objetivo del negocio de optimizar la organización de los sistemas
de información, asegura la entrega de información que satisface los Criterios de
Información requeridos y se mide por medio de Indicadores Clave.
El cumplimiento de este control es posibilitado mediante la creación y el
mantenimiento de un modelo de información y asegurando que están definidos los
sistemas apropiados para optimizar el uso de esta información.
La definición de la Arquitectura de la Información, nos da un enfoque hacia los
requerimientos del negocio en cuanto a controles para tecnología de información
y la aplicación de modelos de control emergentes, por medio de la evaluación de
los siguientes requerimientos:
15
Tomado de CobiT Objetivos de Control 3ra Edicion, Emitido por el Comité Directivo de COBIT y El IT Governance
Institute MR

58
- La función de los sistemas de información debe crear y actualizar de forma
regular un modelo de información del negocio y definir los sistemas
apropiados para optimizar el uso de esta información. Esto incluye el
desarrollo de un diccionario corporativo de datos que contiene las reglas de
sintaxis de los datos de la organización, el esquema de clasificación de
datos y los niveles de seguridad.
- Este proceso mejora la calidad de la toma de decisiones gerenciales
asegurándose que se proporciona información confiable y segura, y
permite racionalizar los recursos de los sistemas de información para
igualarse con las estrategias del negocio.
- Este proceso de TI también es necesario para incrementar la
responsabilidad sobre la integridad y seguridad de los datos y para mejorar
la efectividad y control de la información compartida a lo largo de las
aplicaciones y de las entidades.
Todo esto en base al siguiente proceso de evaluación:
Definición de la Arquitectura de Información
Que satisface los requerimientos de negocio de:
Organizar de la mejor manera los sistemas de información
La creación y mantenimiento de un modelo de información de negocios y
asegurando que se definan sistemas apropiados para optimizar la utilización de
esta información.
Y toma en consideración:
Repositorio automatizado de datos y diccionario

59
Reglas de sintaxis de datos
Propiedad de la información y clasificación con base en criticidad /seguridad
Un modelo de información que represente el negocio
Normas de arquitectura de información de la empresa16
2.3.3 Determinación de la dirección tecnológica
El Control sobre el proceso de Determinar la Dirección Tecnológica que
permite cumplir con el objetivo del negocio de aprovechar la tecnología disponible
y emergente para impulsar y hacer posible la estrategia del negocio, asegura la
entrega de información al negocio que satisface los Criterios de Información
requeridos.
El cumplimiento de este control es posibilitada por:
- La creación y el mantenimiento de un plan de infraestructura técnica que
establece y maneja expectativas claras y realistas de lo que la tecnología
puede ofrecer en términos de productos, servicios y mecanismos de
entrega.
- La actualización de forma regular del plan y verificar que contenga
aspectos tales como arquitectura de sistemas, dirección tecnológica,
planes de adquisición, estándares, estrategias de migración y
contingencias.
Esto permite contar con respuestas oportunas a cambios en el ambiente
competitivo, economías de escala para consecución de personal de sistemas de
información e inversiones, así como una interoperabilidad mejorada de las
plataformas y de las aplicaciones.
16
Institute MR

60
El control de este proceso se lleva a cabo según el siguiente proceso:
Determinación de la dirección tecnológica
Aprovechar la tecnología disponible y las que van apareciendo en el mercado
para impulsar y posibilitar la estrategia del negocio.
La creación y mantenimiento de un plan de infraestructura tecnológica que
establece y administra expectativas claras y realistas de lo que puede brindar la
tecnología en términos de productos, servicios y mecanismos de entrega.
- Capacidad de la infraestructura actual
- Monitoreo de desarrollos tecnológicos por la vía de fuentes confiables
- Realización de prueba de conceptos
- Riesgos, restricciones y oportunidades
- Planes de adquisición
- estrategia de migración y mapas alternativos (roadmaps)
- Relaciones con los vendedores
- Reevaluación independiente de la tecnología
- Cambios de precio /desempeño de hardware y de software17
2.3.4 Definición de la Organización y de las Relaciones de TI
Una organización de TI se debe definir tomando en cuenta los requerimientos
de personal, funciones, delegación, autoridad, roles, responsabilidades y
17
Institute MR

61
supervisión. La organización estará incrustada en un marco de trabajo de
procesos de TI que asegura la transparencia y el control, así como el
involucramiento de los altos ejecutivos y de la gerencia del negocio.
El definir la organización de TI, conlleva cumplir lo siguiente:
- Establecer un comité estratégico que debe garantizar la vigilancia del
consejo directivo sobre la TI, con la responsabilidad de determinar las
prioridades de los recursos de TI alineados con las necesidades del
negocio.
- Deben existir procesos, políticas administrativas y procedimientos para
todas las funciones, con atención específica en el control, el aseguramiento
de la calidad, la administración de riesgos, la seguridad de la información,
la propiedad de datos y de sistemas y la segregación de tareas.
- Para garantizar el soporte oportuno de los requerimientos del negocio, TI
se debe involucrar en los procesos importantes de decisión.
El proceso de evaluación de este control es el siguiente:
Definición de la organización y de las relaciones de TI
Prestación de los servicios correctos de TI
Una organización conveniente en número y habilidades, con tareas y
responsabilidades definidas y comunicadas, acordes con el negocio y que facilita
la estrategia y provee una dirección efectiva y un control adecuado.
- Responsabilidades del nivel directivo sobre TI

62
- Dirección de la gerencia y supervisión de TI
- Alineación de TI con el negocio
- Participación de TI en los procesos clave de decisión
- Flexibilidad organizacional
- Roles y responsabilidades claras
- Equilibrio entre supervisión y delegación de autoridad (empoderamiento)
- Descripciones de puestos de trabajo
- Niveles de asignación de personal y personal clave
- Ubicación organizacional de las funciones de seguridad, calidad y control
interno
- Segregación de funciones18
2.3.5 Manejo de la Inversión en Tecnología de Información
El Control sobre el proceso de Administrar la Inversión de TI, permite alcanzar
el objetivo del negocio de asegurar el financiamiento y controlar el desembolso de
recursos financieros; de esta manera asegura la entrega de información al
negocio que satisface los Criterios de Información requeridos.
Es posibilitado por medio de una inversión periódica y de un presupuesto
operativo establecido y aprobado por el negocio
Los puntos a cumplirse para alcanzar esto son:
- Establecer y mantener un marco de trabajo para administrar los programas
de inversión en TI que abarquen costos, beneficios, prioridades dentro del
presupuesto, un proceso presupuestal formal y administración contra ese
presupuesto.
18
Institute MR

63
- Trabajar con los interesados para identificar y controlar los costos y
beneficios totales dentro del contexto de los planes estratégicos y tácticos
de TI, y tomar medidas correctivas según sean necesarias.
El proceso permite la sociedad entre TI y los interesados del negocio, facilita el
uso efectivo y eficiente de recursos de TI, y brinda transparencia y
responsabilidad dentro del costo total de la propiedad, la materialización de los
beneficios del negocio y el retorno sobre las inversiones en TI.
El proceso es el siguiente:
Manejo o administración de la inversión de TI
Asegurar el financiamiento y el control de desembolsos de recursos financieros se
hace posible a través de:
Inversión periódica y presupuestos operacionales establecidos y aprobados por el
negocio.
• Alternativas de financiamiento
• Claros responsables del presupuesto
• Control sobre los gastos actuales
• Justificación de costos y concientización sobre el costo total de la propiedad
• Justificación del beneficio y contabilización de todos los beneficios obtenidos
• Ciclo de vida del software de aplicación y de la tecnología
• Alineación con las estrategias del negocio de la empresa
• Análisis de impacto

64
• Administración de los activos19
2.3.6 Comunicación de la dirección y aspiraciones de la gerencia
El control sobre el proceso de TI de Comunicar los Objetivos y la Orientación
de la Gerencia permite alcanzar el objetivo del negocio de asegurar el
conocimiento y comprensión del usuario de los objetivos y actividades de TI y es
posibilitado por políticas establecidas y comunicadas a la comunidad de usuarios;
por otra parte, es necesario establecer normas para traducir las opciones
estratégicas en reglas prácticas y utilizables por los usuarios.
Para lograr esto, se requiere lo siguiente:
- La dirección debe elaborar un marco de trabajo de control empresarial para
TI, y definir y comunicar las políticas.
- Implantar un programa de comunicación continua para articular la misión,
los objetivos de servicio, las políticas y procedimientos, etc., aprobados y
apoyados por la dirección.
Con esto se obtendrá que la comunicación apoye el logro de los objetivos de
TI y asegure la concientización y el entendimiento de los riesgos de negocio y de
TI.
El proceso debe garantizar el cumplimiento de las leyes y reglamentos
relevantes, y se enmarca en lo siguiente:
Comunicación de los objetivos y aspiraciones de la gerencia
Asegurar que el usuario sea conciente y comprenda dichas aspiraciones
19
Institute MR

65
Políticas establecidas y transmitidas a la comunidad de usuarios; además, se
necesitan estándares para traducir las opciones estratégicas en reglas de usuario
prácticas y utilizables
• Misión claramente articulada
• Directivas tecnológicas vinculadas con aspiraciones de negocios
• Código de ética / conducta
• Compromiso con la calidad
• Políticas de seguridad y control interno
• Practicas de seguridad y control interno
• Ejemplos de liderazgo
• Programación continua de comunicaciones
• Proveer guías y verificar su cumplimiento20
2.3.7 Administración de Recursos Humanos
El control sobre el proceso de Administrar Recursos Humanos permite cumplir
con el objetivo del negocio de adquirir y mantener una fuerza de trabajo motivada
y competente y maximizar las contribuciones del personal a los procesos de TI.
Es posibilitado por prácticas saludables, justas y transparentes de administración
de personal.
Para obtener esto se debe dar cumplimiento a los siguientes requerimientos:
20
Institute MR

66
- Adquirir, mantener y motivar una fuerza de trabajo para la creación y
entrega de servicios de TI para el negocio.
- Seguir prácticas definidas y aprobadas que apoyan el reclutamiento,
entrenamiento, la evaluación del desempeño, la promoción y la
terminación.
El proceso de evaluación del control es el siguiente:
Administración de recursos humanos
Adquirir y mantener una fuerza de trabajo motivada y competente y maximizar las
contribuciones del personal a los procesos de TI
Prácticas de administración de personal, sensata, justa y transparente para
reclutar, alinear, pensionar, compensar, entrenar, promover y despedir
• Reclutamiento y promoción
• Entrenamiento y requerimientos de calificaciones
• Desarrollo de conciencia
• Entrenamiento cruzado y rotación de puestos
• Procedimientos para contratación, veto y despidos
• Evaluación objetiva y medible del desempeño
• Responsabilidades sobre los cambios técnicos y de mercado
• Balance apropiado de recursos internos y externos
• Plan de sucesión para posiciones clave21
21
Institute MR

67
2.3.8 Aseguramiento del Cumplimiento de Requerimientos Externos
Lo requerimientos externos no son nada mas que obligaciones
organizacionales, legales, regulatorias y contractuales; las cuales deben estar
dentro de un proceso definido en el cual se han desarrollado, documentado y
comunicado políticas, procedimientos y procesos para asegura el cumplimiento de
las mismas.
El control sobre el proceso de Asegurar el Cumplimiento de los
Requerimientos Externos permitirá el cumplimiento del objetivo del negocio de
cumplir con las obligaciones legales, regulatorias y contractuales.
Es posibilitado por la identificación y análisis de los requerimientos externos para
el impacto en TI, y tomando las medidas apropiadas para cumplirlas.
El proceso para la evaluación de este control es:
Aseguramiento del cumplimiento de requerimientos externos
Cumplir con obligaciones legales, regulatorias y contractuales
La identificación y análisis de los requerimientos externos en cuanto a su impacto
en TI, y realizando las medidas apropiadas para cumplir con ellos
• Leyes, regulaciones y contratos
• monitoreo de desarrollos legales y regulatorios
• Monitoreo regular sobre cumplimiento
• Seguridad y ergonomía
• Privacidad

68
• Propiedad intelectual22
2.3.9 Evaluación de Riesgos
La evaluación de riesgos permitirá a la administración decidir cual es la
inversión razonable en seguridad y en el control en lo que a TI se refiere; así
como lograr un balance entre riesgos e inversiones.
Tomando en cuenta que el ambiente de TI frecuentemente es impredecible ya
que si bien la seguridad y los controles en los sistemas de información ayudan a
administrar los riesgos, esto no los elimina y adicionalmente, el nivel de riesgo
nunca puede ser conocido ya que siempre existe un grado de incertidumbre.
En si la Administración debe decidir el nivel de riesgo que está dispuesta a
aceptar y juzgar cual puede ser el nivel tolerable contra el costo, lo cual puede ser
una decisión difícil por esta razón, la Administración necesita un marco de
referencia de las prácticas generalmente aceptadas de control y seguridad de TI
para compararlos contra el ambiente de TI existente y planeado.
Es así que el control sobre el proceso de Evaluar los Riesgos permite lograr el
objetivo del negocio de apoyar las decisiones de la administración y responder a
las amenazas reduciendo la complejidad, la objetividad creciente e identificando
factores importantes de decisión
Esto es posibilitado por la organización dedicándose a la identificación de
riesgos y al análisis de impacto de TI, que involucran funciones multidisciplinarias
y tomando medidas de eficiencia de costos para mitigar los riesgos
Los requerimientos para el control de este objetivo son:
22
Institute MR

69
- Crear y dar mantenimiento a un marco de trabajo de administración de
riesgos.
- Establecer un Marco de trabajo que documente un nivel común y acordado
de riesgos de TI, estrategias de mitigación y riesgos residuales acordados.
- Identificar, analizar y evaluar cualquier impacto potencial sobre las metas
de la organización.
- Se deben adoptar estrategias de mitigación de riesgos para minimizar los
riesgos residuales a un nivel aceptable.
- El resultado de la evaluación debe ser entendible para los participantes y
se debe expresar en términos financieros, para permitir a los participantes
alinear los riesgos a un nivel aceptable de tolerancia.
El proceso de evaluación es el siguiente:
Análisis de riesgos
Soportar las decisiones de la gerencia a través del logro de los objetivos de TI y
responder a las amenazas reduciendo su complejidad e incrementando
objetivamente e identificando factores importantes de decisión.
La participación de la propia organización en la identificación de riesgos de TI y en
el análisis de impacto, involucrando funciones multidisciplinarias y tomando
medidas costoefectivas para mitigar los riesgos
• Administración de riesgos de la propiedad y del registro de las operaciones

70
• Diferentes tipos de riesgos de TI (por ejemplo: tecnológicos, de seguridad, de
continuidad, regulatorios, etc.)
• Definir y comunicar un perfil tolerable de riesgos
• Análisis de las causas y sesiones de tormenta de ideas sobre riesgos
• Medición cuantitativa y/o cualitativa de los riesgos
• Metodología de análisis de riesgos
• Plan de acción contra los riesgos
• Volver a realiza análisis oportunos23
2.3.10 Administración de proyectos
El control sobre el proceso de Administrar Proyectos que permite alcanzar el
objetivo del negocio de establecer prioridades y entregar a tiempo y dentro de
presupuesto; es posibilitado por la organización mediante la identificación y la
priorización de los proyectos en línea con el plan operativo y la adopción y
aplicación de técnicas saludables de administración de proyectos para cada
proyecto emprendido
Los requerimientos identificados para cumplir este objetivo son:
- Establecer un programa y un marco de control administrativo de proyectos
para la administración de todos los proyectos de TI.
- El marco de trabajo debe garantizar la correcta asignación de prioridades y
la coordinación de todos los proyectos.
- El marco de trabajo debe incluir un plan maestro, asignación de recursos,
definición de entregables, aprobación de los usuarios, un enfoque de
entrega por fases, aseguramiento de la calidad, un plan formal de pruebas,
23
Institute MR

71
revisión de pruebas y revisión post-implantación para garantizar la
administración de los riesgos del proyecto y la entrega de valor para el
negocio.
Este enfoque reduce el riesgo de costos inesperados y de cancelación de
proyectos, mejora la comunicación y el involucramiento del negocio y de los
usuarios finales, asegura el valor y la calidad de los entregables de los proyectos,
y maximiza su contribución a los programas de inversión en TI.
El proceso de evaluación de este control se describe a continuación:
Administración de proyectos
Establecer prioridades y entregar servicios oportunamente y de acuerdo al
presupuesto de inversión.
La organización identificando y priorizando proyectos en línea con el plan
operacional y la adopción y aplicación de técnicas de administración de proyectos
para cada proyecto emprendido.
• El patrocinio que la gerencia de negocios debe dar a los proyectos
• Administración de programas
• Capacidad para el manejo de proyectos
• Involucramiento del usuario
• División de tareas, definición de puntos de control y aprobación de fases
• Distribución de responsabilidades
• Rastreo riguroso de puntos de control y entregables

72
• Costos y presupuestos de mano de obra, balance de recursos internos y
externos
• Planes y métodos de aseguramiento de calidad
• Programa y análisis de riesgos del proyecto
• Transición de desarrollo a operación24
2.3.11 Administración de Calidad
Administrar la calidad conlleva a una conciencia de calidad institucionalizada
de tal manera que el aseguramiento de calidad este integrado y se ejecute en
todas las actividades en especial en las de TI.
El aseguramiento de calidad de los procesos de TI está totalmente integrados
con la aseguramiento sobre los procesos del negocio para asegurar que los
productos y servicios de toda la organización tengan una ventaja competitiva.
Por esto el control sobre el proceso de Administrar Calidad que permite
alcanzar el objetivo del negocio de satisfacer los requerimientos de clientes de TI,
es posibilitado por la planeación, implementación y mantenimiento de normas y
sistemas de administración de calidad proveyendo fases distintas de desarrollo,
productos claros y responsabilidades explícitas
Los requerimientos para alcanzar este objetivo son:
- Se debe elaborar y mantener un sistema de administración de calidad, el
cual incluya procesos y estándares probados de desarrollo y de
adquisición.
24
Institute MR

73
- Establecer la planeación, implantación y mantenimiento del sistema de
administración de calidad, proporcionando requerimientos, procedimientos
y políticas claras de calidad.
- Los requerimientos de calidad se deben manifestar y documentar con
indicadores cuantificables y alcanzables.
- La mejora continua se logra por medio del constante monitoreo, corrección
de desviaciones y la comunicación de los resultados a los interesados.
La administración de calidad es esencial para garantizar que TI está dando
valor al negocio, mejora continua y transparencia para los interesados, a
continuación se detalla el proceso para la evaluación del control.
Administración de la calidad
Satisfacer los requerimientos del cliente de TI
La planeación, implementación y mantenimiento de estándares de administración
de calidad y sistemas provistos para las distintas fases de desarrollo, claros
entregables y responsabilidades explícitas
• Establecimiento de una cultura de calidad
• Planes de calidad
• Responsabilidades de aseguramiento de la calidad
• Practicas de control de calidad
• Metodología del ciclo de vida de desarrollo de sistemas
• Pruebas y documentación de sistemas y programas

74
• Revisiones y reporte de aseguramiento de calidad
• Entrenamiento e involucramiento del usuario final y del personal de
aseguramiento de calidad
• Desarrollo de una base de conocimiento de aseguramiento de calidad
• Benchmarking contra las normas de la industria25
25
Institute MR

75
CAPÍTULO III
“AUDITORÍA INFORMÁTICA DEL SISTEMA DE INFORMACIÓN DE
LA ESPE: DOMINIO PLANEACIÓN Y ORGANIZACIÓN.”
En conformidad con el Plan del proyecto de tesis, “Auditoría Informática del
Sistema de Información de la Escuela Politécnica del Ejército”, se ha realizado la
revisión de los controles referentes a la Planeación y Organización implantados
en Tecnología de la Información y Comunicaciones de la Escuela Politécnica del
Ejército, durante el período 2006-2007 de gestión de la UTIC.
La metodología empleada ha sido recopilación de información mediante
entrevistas, cuestionarios, estudio documental de información entregada por las
unidades, información que fue tabulada y detallada en matrices de control, antes
ya expuesta en el caplitulo1 del presente trabajo.
El equipo estuvo conformado por María Alexandra Tapia Mendieta y María
Ángeles Salcedo Salgado.
A continuación se detallan las observaciones y recomendaciones resultantes de la
revisión, en base del estándar COBIT
PO1. DEFINICIÓN DE UN PLAN ESTRATÉGICO DE TECNOLOGÍA DE
INFORMACIÓN
PO1.1 Tecnología de Información como parte del Plan de la Organización a
corto y largo plazo.
Observación PO1: La UTIC no participó de manera activa en la elaboración del
plan estratégico institucional.

76
Criterio –
De acuerdo al enfoque de auditoría, en el cual la alta gerencia será la responsable
de desarrollar e implementar planes a largo y corto plazo que satisfagan la misión
y las metas de la organización; es decir que se deben desarrollar planes de TI a
largo y corto plazo para ayudar a asegurar que el uso de la TI esté acorde con la
misión y las estrategias de negocio de la organización
Condición –
- La ESPE tiene un Plan Estratégico Institucional elaborado mediante eventos,
con asesoría extranjera; en el cual no existe evidencia de participación activa
de la UTIC (Evidencia : AUDI-ESPE-2007-ENT-005, AUDI-ESPE-2007-ENT-
004)
- La ESPE tiene un Plan Operativo Anual Institucional, elaborado por la Unidad
de Desarrollo Institucional, en base del Presupuesto Operativo Anual
asignado, y de los requerimientos o necesidades emergentes y urgentes de la
ESPE; más no en base a perspectivas y metas a alcanzar; para el apoyo al
plan estratégico institucional, así como no se evidencia uso de una
metodología o procedimiento formal de análisis de asignación de
presupuestos. (Evidencia: AUDI-ESPE-2007-ENT-012, AUDI-ESPE-2007-
ENT-005).
Causa-
- La falta de una metodología participativa efectiva de todos los estratos y
grupos funcionales u organizacionales y la falta de sociabilización del mismo
- Los proyectos relacionados de tecnología de información son entregados a la
UDI según el criterio de costo y factibilidad del usuario, mas no por el

77
responsable de la planificación, además se desconoce la metodología o
procedimiento para la selección de los proyectos presentados y para la
asignación de presupuesto.
- No existe evidencia de Gerencia de TI.
Efecto –
- Sin una Planificación Estratégica institucional, integrada con la participación
activa de las unidades organizacionales, en especial la de Tecnología de la
Información, es difícil obtener ventajas competitivas sostenibles y/o apoyar a
los objetivos institucionales, propiciando servicios deficientes o fuera de los
objetivos que pretende alcanzar con la Institución. El desarrollo de los
Sistemas y Tecnología de Información no es visualizado ni evaluado.
- La falta de Metodologías, Estándares normas y procedimientos definidos
institucionalmente en lo que a planeación se refiere conlleva al desarrollo en
diferentes marcos de referencia, criterios, etc.; que no permiten un desarrollo,
ejecución y cumplimiento óptimo de los Planes.
- La manera en la que se realiza la Planificación Operativa, no permite el
emprendimiento de proyectos realmente enfocados a los objetivos
institucionales y puede generar tráfico de influencias para aprobación de
presupuestos o aplicación de criterios arbitrarios y personales para ese
proceso, sin que se consiga el desarrollo de la institucional.
Recomendación PO1 –

78
- El Director de la UDI realizará hasta el primer semestre del año en curso, la
evaluación del Plan Estratégico Institucional, para una actualización del
mismo, luego del análisis y diseño de una metodología o proceso acorde con
la institución; como por ejemplo la “METODOLOGÍA ACTIVA DE
INTEGRACIÓN O DE PLANIFICACIÓN EN PARALELO”; integrando las
posibilidades de TI y la participación activa de las Unidades Organizacionales.
- El Director de la UDI reformulará la Planificación Operativa del año en curso,
con el análisis presupuestario real pertinente, en base a perspectivas y metas
a alcanzar durante el año en alineación con la Planificación Estratégica
Institucional y la Planificación Estratégica de Sistemas de Información.
- El Director de la UDI, diseñará y pondrá en ejecución un proceso participativo
para seleccionar y asignar presupuesto a los proyectos de tecnologías de
información.
Punto de vista –
PO1.2 Plan a largo plazo de Tecnología de información.
Observación PO2- No existe Plan estratégico de Tecnología de Información y
Comunicación.
Criterio –

79
De acuerdo al enfoque de auditoría, la Gerencia de TI y los dueños del proceso
de negocio serán responsables de desarrollar regularmente planes de TI a largo
plazo, que apoyen el logro de la misión y las metas generales de la organización.
De la misma manera, la Gerencia deberá implementar un proceso de planeación
a largo plazo, adoptar un enfoque estructurado y determinar la estructura para el
plan.
Condición –
§ En base a la investigación de campo un plan estratégico Informático en la
UTIC. (Evidencia: AUDI-ESPE2007-ENT 004,005, memorando No 2007-1275-
ESPE-d-6)
§ Los proyectos desarrollados por la UTIC, han recogido necesidades y
requerimientos de las unidades de la ESPE, sin alineación al plan estratégico
institucional evidenciado. (Evidencia: GT1-6)
Causa –
§ No existe evidencia de Gerencia de TI por parte de las autoridades.
§ Falta de capacitación referida al tema por parte del personal de la ESPE y de
la UTIC, acerca de la Planificación estratégica y su importancia.
§ El diseño organizacional no contempla estas funciones ni asigna estas
responsabilidades a unidad alguna específicamente. La administración de
Proyectos se lleva a cabo sin un procedimiento de selección adecuado
(Evidencia : AUDI—ESPE- 2007-ENT005,004)
Efecto –

80
§ La falta de Planificación Estratégica Informática, no permite el apoyo efectivo
de TI a la estrategia de negocio de la Institución, ni el establecimiento de
perspectivas y metas para el mejoramiento de la Función de TI.
§ No se puede evaluar el costo beneficio de la inversión de TI.
§ No es posible emprender con planes de mejoramiento, que permitan el
desarrollo sostenido de la función de TI.
§ El Director de la UDI realizará hasta el primer semestre del año en curso, el
Plan Estratégico Informático Institucional, luego del análisis y diseño de una
metodología o proceso acorde con la institución; como por ejemplo la
“METODOLOGÍA ACTIVA DE INTEGRACIÓN O DE PLANIFICACIÓN EN
PARALELO”; integrando las posibilidades de TI y la participación activa de
las Unidades Organizacionales.
§ El Director de la UTIC, durante el primer trimestre del año en curso,
organizará y ejecutará con el apoyo del departamento de Ciencias de la
Computación de la ESPE, un plan de capacitación acerca de Planificación
Estratégica de Sistemas de Información, a todo el personal que estará
involucrado en la formulación del Plan Estratégico Informático de la ESPE.
Punto de vista –

81
PO1.3 Plan a largo plazo de Tecnología de Información - Enfoque y
Estructura
PO1.4 Cambios al Plan a largo plazo de Tecnología de Información
Observación PO3 - No existe Planificación a Largo Plazo de la Unidad de TIC’s
Criterio –
La Gerencia de TI y los dueños del proceso de negocio deberán establecer y
aplicar un enfoque estructurado al proceso de planeación a largo plazo. Esto
deberá traer como resultado un plan de alta calidad que cubra las preguntas
básicas de qué, quién, cómo, cuándo y por qué el proceso de planeación de TI
debe tomar en cuenta los resultados del análisis del riesgo, incluyendo los riesgos
del negocio, entorno, tecnología y recursos humanos
Asegurar que se establezca un proceso con el fin de adaptar los cambios al plan a
largo plazo de la organización y los cambios en las condiciones de la TI. La
gerencia Senior deberá establecer una política que requiera que se desarrollen y
se mantengan planes de largo y corto plazo de TI
Condición –
• No existe Planificación a Largo Plazo de la UTIC, ni evidencia de
metodologías, estándares y procedimientos institucionalmente establecidos
para la Planificación en la ESPE. (Evidencia: Memo No 2007-1275-ESPE-d-6)
• No existe evidencia de un proceso para adaptar los cambios al plan a largo
plazo de la organización y los cambios en las condiciones de la TI; ni de
Políticas de desarrollo y mantenimiento de Planes a largo plazo (Evidencia:
Memo No 2007-1275-ESPE-d-6)

82
• No existe gestión estratégica ni gerencia de tecnología contemplada en el
diseño organizacional. (Evidencia: TH-1)
§ No se realiza proyectos encaminados al cumplimiento de los objetivos del
negocio por falta de alineación estratégica. (Evidencia: AUDI-ESPE- 2007-
ENT 004,005)
Efecto –
§ La falta de un enfoque estructurado al proceso de planeación a largo plazo,
no permite tener como resultado un plan de alta calidad que cumpla los
objetivos institucionales.
§ La falta de un proceso para adaptar los cambios al plan a largo plazo de la
organización y los cambios en las condiciones de la TI, impide la actualización
tecnológica y resta competitividad a la institución.
§ Durante el primer trimestre del año en curso, El Director de la UDI, establecerá
y aplicará un enfoque estructurado al proceso de planeación a largo plazo de
TI, para conseguir un plan de alta calidad que cubra las preguntas básicas de
qué, quién, cómo, cuándo y el por qué del proceso de planeación de TI,
considerará los resultados del análisis del riesgo, incluyendo los riesgos del
negocio, entorno, tecnología y recursos humanos
§ El Director de la UDI, establecerá un proceso para adaptar los cambios al plan
a largo plazo de la organización y los cambios en las condiciones de la TI.

83
§ El Director de la UDI, establecerá una política que requiera que se desarrollen
y se mantengan planes de largo y corto plazo de TI
Punto de vista –
PO1.5 Planeación a corto plazo para la función de Servicios de Información
Observación PO4 – No existe una metodología adecuada en la planeación a
corto plazo de la Función de Servicios de Información.
Criterio –
La planificación a corto plazo, deberá asegurar que se asignen los recursos
apropiados de la función de servicios de TI con una base consistente.
Condición –
§ La planeación que la UTIC desarrolla es únicamente a corto plazo, limitada por
el Presupuesto asignado anualmente en función del gasto de ese periodo.
(Evidencia: AUDI-ESPE-2007-ENT-004).
§ No se dispone de una metodología específica, se utiliza MS Project Manager
para elaborar cronogramas de trabajo y diagramas GANTT (Evidencia: AUDI-
ESPE-2007-ENT-004).
§ Creación del cargo de Planificador y Administrador de Proyectos Informáticos
y designación sin métodos y procedimientos claros de análisis y selección;

84
existiendo responsable de este proceso. (Evidencia: AUDI-ESPE2007-ENT
004)
§ El desarrollo de Planeación a corto plazo se cumple de acuerdo a un proceso
establecido denominado “Planificación de proyectos TIC”: (Evidencia: GT.1.1,
AUDI-ESPE2007-ENT 004)
§ La UTIC tiene un Plan RI (GT1-2), y el registro del seguimiento a los proyectos
de los que GT1 es responsable, el resto de áreas no lo evidencia (Evidencia
GT1-4: documentación de referencia, estado porcentual con fechas
establecidas y fechas reales), pero no existe un procedimiento formalmente
establecido para el seguimiento de proyectos.
§ La planificación de la UTIC, no asegura asignación de los recursos apropiados
de la función de servicios de TI con una base consistente en la evidencia del
seguimiento de cumplimiento de la planificación y ejecución de proyectos.
Causa –
- Falta de Gerencia Estratégica y Planificación de TI.
Efecto –
§ La falta de una metodología, estándar y procedimientos formales, hace que el
proceso de planeación, no establezca un esquema de prioridades para los
objetivos del negocio y cuantifique, cuáles de los requerimientos del negocio
son posibles, evidente para las autoridades, además de no asegurar
asignación de los recursos apropiados de la función de servicios de TI.

85
El Director de la UDI, establecerá dentro del primer trimestre del año en curso, las
políticas necesarias para definir metodologías, estándares, procedimientos y
enfoque para el proceso de planificación de TI, que encierren políticas de
ejecución de seguimiento, así como el desarrollo de Análisis de factibilidad
completo de los proyectos inmersos en la planificación de TI, incluido el Plan RI.
Punto de vista –
PO1.6 Comunicación de los planes de TI
Observación PO5 – No existe comunicación de los Planes de TI.
Criterio –
Se debe asegurar la comunicación de los Planes de TI a todos los niveles
organizacionales.
Condición –
No existe evidencia del procedimiento formalmente aprobado para la
comunicación de los Planes o estados de proyectos aprobados a las unidades
beneficiarias de los mismos. Estas conocen del proyecto únicamente al inicio con
el envío para aprobación y al final con el memorando de entrega del equipo o
servicio. (Evidencia: AUDI-ESPE-2007-ENT-004)
Causa –

86
Falta de un sistema de comunicación organizacional adecuado.
Efecto –
La falta de flujo de información entre la UTIC y las demás unidades, conlleva la
desinformación del desenvolvimiento de la Función de TI, con respecto a: Índice
de participantes que se involucrarán en el desarrollo del plan de TI, plan o
proyecto realizado. La proporción de participación de los dueños del negocio
frente al personal de TI y el número de participantes clave.
§ Durante el primer trimestre del año en curso, el Director de la UDI, diseñará y
pondrá en operación en la ESPE, un sistema de comunicación organizacional
con tecnología de avanzada, para establecer flujos de información
institucionales que agiliten y optimicen tiempos y tramites en los procesos de
las diferentes Unidades.
§ El Director de la UTIC, en el término del primer trimestre del año en curso,
establecerá dentro del proceso de ejecución de los proyectos, el seguimiento e
información del estado de los mismo a las Unidades beneficiarias y a las
autoridades respectivas; con el fin de que los beneficiarios de los proyectos
establecidos en el POA y que se encuentran dentro del PLAN RI, conozcan la
situación del proyecto y la gestión que la UTIC realiza para la su ejecución.
Punto de vista –

87
PO1.7 Evaluación y Monitoreo de los planes de TI
Observación PO6 – No existe Evaluación y Monitoreo de Planes de TI.
Criterio –
Se debe establecer procesos para captar y reportar la retroalimentación de los
dueños y usuarios del proceso del negocio respecto a la calidad y utilidad de los
planes de la UTIC.
Condición –
La UTIC, realiza la evaluación de la trascendencia, efectividad y eficiencia de la
planificación mediante el cumplimiento de las actividades del Plan RI. (Evidencia:
AUDI-ESPE-2007-ENT-004).
Causa –
La UDI, no ha establecido políticas para la evaluación y monitoreo de la
planificación de TI.
Efecto –
La falta de la vigilancia, evaluación y seguimiento de la Función de TI, no permite
el mejoramiento de los servicios de TI, ni un proceso estructurado de toma de
decisiones.

88
El director de la UDI, dentro del primer trimestre del año en curso, establecerá los
lineamientos y dispondrá a los responsables para evaluar y monitorear la
planificación de TI (Semestralmente), para conocer el estado actual y establecer
estrategias de mejoramiento de los servicios de TI.
Punto de vista –
PO1.8 Valoración de los sistemas existentes
Observación PO7 – No existe Valoración de los sistemas existentes
Criterio –
Previo al desarrollo o modificación del Plan Estratégico, la Gerencia debe evaluar
los sistemas existentes en términos de: nivel de automatización de negocio,
funcionalidad, estabilidad, complejidad, costo, fortalezas y debilidades, etc.
Condición –
No existe evidencia de valoración de los sistemas existentes (AUDI-ESPE-2007-
ENT-003)
Causa –
• Falta de un plan Estratégico Informático.

89
• No existe Gerencia de TI.
• Desconocimiento de procedimientos de evaluación y valoración por parte del
personal responsable.
Efecto –
La falta de valoración no permite desarrollar el Plan Estratégico Institucional ni el
Plan Estratégico de TI de manera coherente, pertinente y efectiva, causando
desorientación y deficiencia en el uso de los recursos tecnológicos, además de
que no permite establecer un proceso estructurado de toma de decisiones.
Recomendación PO7. –
El Director de la UDI, en el lapso de tres meses, establecerá y ejecutará las
políticas y procedimientos para evaluar los sistemas existentes en términos de:
nivel de automatización de negocio, funcionalidad, estabilidad, complejidad, costo,
fortalezas y debilidades, etc.
Punto de vista –

90
PO2. DEFINICIÓN DE LA ARQUITECTURA DE INFORMACIÓN
PO2.1 Modelo de la Arquitectura de Información
Observación PO8: No existe modelo de arquitectura de la información.
Criterio –
La información deberá conservar consistencia con las necesidades y deberá ser
identificada, capturada y comunicada de tal forma y dentro de períodos de tiempo
que permitan a los responsables llevar a cabo sus tareas eficiente y
oportunamente.
Condición –
§ No existe evidencia de un modelo de datos de arquitectura de la información.
Adicionalmente no se lleva de manera normalizada modelos de datos de
aplicaciones construidas por la UTIC y de los contratados no existe evidencia.
(Evidencia: AUDI-ESPE-2007ENT-003)
§ Del análisis realizado en el objetivo DS3 (Administrar el desempeño y la
Capacidad), se establece la falta de definición de los periodos en los que la
información debe estar disponible, y las características de eficiencia y
oportunidad con las que debe contar.(Evidencia: N. 2007-1275ESPE-d-6)
Causa –
§ La Planificación Estratégica Informática, en la que se establece la arquitectura
general de los sistemas de información, no existe.
§ Falta de formalidad con la que se llevan los proyectos de desarrollo de
aplicaciones.

91
§ No existe un proceso eficaz de especificación de requerimientos tecnológicos
y funcionales del negocio, lo que dificulta la definición de la arquitectura de
datos necesaria para la organización. (Evidencia: N. 2007-1275ESPE-d-6)
Efecto –
§ La falta de un modelo de arquitectura de información, impide determinar los
requerimientos de una planificación a futuro, por lo que se realizan
adquisiciones emergentes que luego no pueden ser complementadas,
afectando a la eficiencia en el uso de recursos y necesidades actuales.
§ No permite la ejecución de un proceso racional evolutivo de los sistemas de
información en apoyo a los objetivos institucionales.
§ Al no contar con información de manera eficiente y oportuna se producen
retrasos en las tareas de personal responsable de los mismos o se corre el
riesgo de que se cometan errores, se pasen por alto modificaciones hechas
que puedan ser significativas para el funcionamiento de las distintas
aplicaciones o para la obtención de datos fiables y de los cuales dependan
otros departamentos.
§ Debido a que en la unidad se manejan grandes cantidades de información, al
no tenerla debidamente organizada, la búsqueda de la misma en el momento
que se la necesite se dificulta, debido a la falta de un estándar para su
documentación y almacenamiento y esto produce también retrasos en la
obtención de información crítica.

92
§ El Director de la UDI, durante el primer trimestre del año en curso, dispondrá la
planificación y ejecución, de capacitación al personal involucrado, referente a
“Arquitectura de la Información”, a fin de realizar posteriormente el Plan
Estratégico Institucional, conforme a los requerimientos en tiempo del
Ministerio de Economía; en el Plan Estratégico se incluirá el diseño de la
Arquitectura de los Sistemas de Información Institucionales, considerando los
requerimientos de información descritos en este objetivo.
Punto de vista –
PO2.2 Diccionario de Datos y Reglas de sintaxis
Observación PO9: No existe Diccionario de datos ni Reglas de sintaxis.
Criterio.–
Asegurar la creación y la continua actualización de un diccionario de datos
corporativo que incorpore las regl0as de sintaxis de datos de la organización.
Condición –
No existe evidencia de algún tipo de diccionario de datos o la existencia de un
manual propio de sintaxis para desarrollo de sistemas o de registro de datos, por
lo que no existen actualizaciones del mismo. (Evidencia: AUDI-ESPE-2007ENT-
003)

93
Causa –
§ Falta de estándares adecuados para desarrollo de sistemas.
§ Falta de capacitación referida al tema por parte del personal de la UTIC.
§ No se han designado responsabilidades que cubran estas actividades en
forma específica y falta de responsabilidades de supervisión.
Efecto –
§ La falta de descripción de los datos o una descripción inadecuada de los
mismos incide en la calidad del software, especialmente en el indicador de
corrección y dificulta o imposibilita el mantenimiento de las aplicaciones
§ Otro efecto de la no existencia de reglas de sintaxis es la falta de consistencia
en la manera en la que se manejan los datos y en el caso de desarrollo no
existen estándares para declaraciones de variables, funciones,
procedimientos, etc.
Recomendación PO9. –
El Director de la UTIC, dispondrá al coordinador de GT5, actualizar y/o desarrollar
la documentación técnica de las aplicaciones desarrolladas o en desarrollo, en la
que se incluirá el diccionario de datos.
Punto de vista –

94
PO2.3 Esquema de Clasificación de Datos
Observación PO10: No existe un esquema de clasificación de datos, ni
clasificación de la información crítica de la institución.
Criterio –
Deberá establecerse un marco de referencia de clasificación general relativo a la
ubicación de datos en clases de información, así como la asignación de
propiedad. Las reglas de acceso para las clases deberán definirse
apropiadamente.
Condición –
§ No existe evidencia de análisis ni clasificación de acuerdo a la criticidad de la
información.
§ No existen políticas de seguridad únicamente en lo que se refiere a seguridad
en manejo de la información y seguridad de datos en servidores (Evidencia:
memo N. 2007-1275ESPE-d-6).(Evidencia: referencia: SGC.DI.079)
§ No existe una definición formal de la persona responsable de llevar al día los
backups de información, acceso, etc. (Evidencia : Nº 2007-0323-ESPE-d-6,
N2007-0321-ESPE-d-6 en dichos memos se asigna la responsabilidad de
administración de active directory y administración de redes más no de
respaldo de información)
§ El responsable de almacenar los respaldos de datos revisa correcta
etiquetación de backups, mas no el contenido del respaldo en CD que se le

95
entrega; responsabilidad que no está especificada como parte de las funciones
del cargo que desempeña (Evidencia: AUDI-ESPE-2007ENT-005).
§ No existe evidencia de reglas de acceso a la información (Evidencia:
memorando N°2007-1275-ESPE-d-6, AUDI-ESPE-2007ENT-003)
Causa –
§ El personal afirma saber exactamente cual es la información crítica que se
maneja, por lo cual no se realiza el análisis de criticidad de información.
(Evidencia: AUDI-ESPE-2007ENT-003).
§ El facilismo o confianza en el personal que labora en la unidad y la falta de una
estructura de la información no permite un adecuado control referente a la
asignación de usuarios, claves de acceso y privacidad de datos y asignación
de niveles de acceso. (Evidencia : AUDI-ESPE-2007ENT-003, AUDI-ESPE-
2007ENT-002)
Efecto –
§ La falta de clasificación de la información, impide establecer protección
adecuada.
§ Se propicia ineficiencia en el uso de recursos, porque se podría respaldar
información no crítica o no necesaria y dejar sin respaldo información
realmente importante para la institución.
§ En caso de desastre informático, se pierde la información como ha ocurrido en
el caso del servidor de datos de finanzas.
§ La falta de verificación del contenido de los respaldos pone en riesgo el
restablecimiento de la información.

96
§ No se conoce exactamente que persona está accediendo a la información de
los distintos servidores
§ El Director de la UTIC, en el lapso de dos meses, clasificará la información
institucional, estableciendo el grado de criticidad de la misma e implementará
las medidas de seguridad pertinentes, de acuerdo a esa clasificación; así
mismo, definirá los propietarios o custodios de la información crítica, con sus
niveles de acceso y el registro de auditoría del personal que ha accedido a
cualquier tipo de información con el detalle de los cambios realizados en la
información.
§ El Director de la UTIC, en el lapso de dos meses, elaborará y pondrá en
ejecución un instructivo para respaldar la información clasificada.
Punto de vista –
PO2.4 Niveles de Seguridad.
Observación PO11: No existen definiciones de Niveles de Seguridad.
Criterio –

97
La Gerencia deberá definir, implementar y mantener niveles de seguridad para
cada una de las clasificaciones de datos identificadas con un nivel superior al de
"no requiere protección".
Condición –
§ Se mantiene acceso de acuerdo a perfiles de usuario pero no de acuerdo a
niveles de seguridad de la información. (Evidencia: AUDI-ESPE-2007ENT-
003).
§ No existen niveles de seguridad definidos, por lo que no existe actualizaciones
ni evaluaciones de los mismos. (Evidencia: memo N° 2007-12-75-ESPE-d-6 ).
Causa –
§ No existe una clasificación de criticidad de la información (PO2.3)
§ No se pueden realizar evaluaciones de efectividad o actualizaciones de estos
niveles de seguridad ya que no existen.
Efecto –
Se incrementa el riesgo de acceso no autorizado, sabotaje, modificación, robo de
datos, fraude y otras acciones que pondrían en riesgo la continuidad del negocio.
§ El Director de la UTIC, en el término de tres meses, definirá e implementará
niveles de seguridad para cada una de las clasificaciones de datos
identificadas con un nivel superior al de "no requiere protección"; luego de tres
meses de implementados y en forma periódica realizará actualizaciones y

98
evaluaciones de la efectividad de estas seguridades, de manera que se pueda
retroalimentar y cubrir posibles falencias en la seguridad de la información.
Punto de vista –
PO3. DEFINICIÓN DE LA ORGANIZACIÓN Y DE LAS RELACIONES DE TI
PO3.1 Planeación de la Infraestructura Tecnológica
Observación PO12: No existe un Plan de Infraestructura Tecnológica,
desarrollado o consolidado.
Criterio –
La función de servicios de información deberá crear y actualizar regularmente un
plan de infraestructura tecnológica, que deberá abarcar aspectos tales como
arquitectura de sistemas, dirección tecnológica y estrategias de migración.
Condición –
La UTIC no posee un Plan de Infraestructura Tecnológica, ya que el Plan RI no
contiene análisis de Arquitectura de Sistemas, Dirección tecnológica y estrategias
de migración en base a las cuales se realizarían los planes de adquisiciones
(Evidencia: AUDI-ESPE-2007-ENT-004).

99
Causa –
§ Falta de una planificación estratégica informática, que defina la Infraestructura
Tecnológica (Productos, Servicios y mecanismos de entrega) a la cual la
ESPE apuntaría.
§ No se han designado responsabilidades en la supervisión y en la captación de
estas actividades en forma específica.
Efecto –
La falta de un Plan de Infraestructura tecnológica, conlleva a la deficiencia de
análisis y determinación de expectativas claras y realistas de lo que la tecnología
puede ofrecer en términos de productos, servicios y mecanismos de entrega; a la
ESPE como entidad Educativa.
El Director de la UDI, elaborará el Plan de Infraestructura Tecnológica durante los
tres meses posteriores al establecimiento del Plan Estratégico Informático; que
se traduce en planes para la adquisición de tecnología, capacitación y
reclutamiento de personal, con consideración de las políticas y normas de uso de
la tecnología.
Punto de vista –

100
PO3.2 Monitoreo de Tendencias y Regulaciones Futuras
Observación PO13: No existe registro de Monitoreo de Tendencias y
Regulaciones Futuras.
Criterio –
La función de servicios de información deberá asegurar el monitoreo continuo de
tendencias futuras y condiciones regulatorias, de tal manera que estos factores
puedan ser tomados en consideración durante el desarrollo y mantenimiento del
plan de infraestructura tecnológica.
Condición –
§ No existe reglamentos ni políticas establecidas directamente para el área de
tecnología. (Evidencia: AUDI-ESPE-2007-ENT-013).
§ La UTIC, no posee registros de Monitoreo de Tendencias Tecnológicas.
(Evidencia: AUDI-ESPE-2007-ENT-005, AUDI-ESPE-2007-ENT-004)
Causa –
§ La falta de un Plan Estratégico Informático que contenga la tendencia
tecnológica institucional para el desarrollo del monitoreo de tendencias
tecnológicas, y el estudio de condiciones regulatorias aplicables a la
institución.
No se han designado responsabilidades que cubran estas actividades en forma
específica ni de supervisión

101
Efecto –
No se logra mantener la innovación tecnológica en la Institución, por lo que se
pierde competitividad, así como la falta de cumplimiento de las regulaciones
ecuatorianas.
§ El Director de la UDI, en el lapso de un mes, establecerá las regulaciones a las
cuales la ESPE se encuentra sujeta, en cuanto a tecnología se refiere.
§ El director de la UTIC, en el lapso de dos meses, establecerá y ejecutará un
instructivo para el monitoreo continuo de tendencias futuras y condiciones
regulatorias, de tal manera que estos factores puedan ser tomados en
consideración durante el desarrollo y mantenimiento del plan de infraestructura
tecnológica.
Punto de vista –
PO3.3 Contingencias en la Infraestructura Tecnológica
Observación PO14: No existe evaluación sistemática del Plan de Infraestructura
Tecnológica.
Criterio –

102
El plan de infraestructura tecnológica deberá ser evaluado sistemáticamente en
cuanto a aspectos de contingencia.
Condición –
No existe registro o evidencia de evaluación del plan de infraestructura
Causa –
§ No existe Plan de Infraestructura Tecnológica.
No se han designado responsabilidades de supervisión y que cubran estas
actividades en forma específica.
Efecto –
La falta de análisis y evaluación de los aspectos de contingencia en el Plan de
Infraestructura Tecnológica, no permite prever alternativas de solución en caso de
eventualidades que impidan el cumplimiento del plan y por tanto pone en riesgo el
desarrollo tecnológico en apoyo a los objetivos del negocio.
§ El Director de la UDI, en el lapso de tres meses, establecerá el procedimiento
periódico y designará el responsable o responsables de la evaluación del Plan
de Infraestructura Tecnológico de la Institución y determinación de aspectos
de contingencia del mismo.
Punto de vista –

103
PO3.4 Planes de Adquisición de Hardware y Software
Observación PO15: No existe Plan de Adquisición de Hardware y Software.
Criterio –
La gerencia de la función de servicios de información deberá asegurar que los
planes de adquisición de hardware y software sean establecidos y que reflejen las
necesidades identificadas en el plan de infraestructura tecnológica.
Condición –
§ La ESPE no tiene un plan de Adquisiciones de Hardware y Software
específico, únicamente un Plan de Adquisiciones General con responsabilidad
de la unidad de Logística, donde los activos de TI son tratados como cualquier
otro bien con la diferencia que en el proceso de adquisición se especifican
bases e informe técnico.(Evidencia: AUDI-ESPE-2007-ENT-06)
§ La UTIC, realiza el Plan RI, que recoge los proyectos de adquisición de
hardware y software de la ESPE y Sedes. Institucionalmente no se reconoce al
Plan RI, como el Plan de Adquisiciones de Hardware y software.
Causa -
§ Falta de Planificación Estratégica Informática.
§ Falta de capacitación referida al tema por parte del personal de la Unidad de
Logística.

104
No se han designado responsabilidades totales a la UTIC que cubran estas
actividades en forma específica.
Efecto –
La falta de un Plan de Adquisiciones de Hardware y Software conlleva a la
adquisición de activos de TI de manera desorganizada y sin análisis de la
tendencia tecnológica a la que la organización desea llegar. Además de que la
organización no realizaría Innovación tecnológica.
§ El Director de la UDI en el primer semestre del año en curso, establecerá
Institucionalmente el Plan de Adquisición de Hardware y software, integrando
las adquisiciones totales de activos de TI de todas las unidades que componen
a la ESPE y sedes, en base del Plan Estratégico de Sistemas de Información y
del Plan Operativo Anual.
§ El Director de la UDI en el primer trimestre del año, definirá la responsabilidad
de las Adquisiciones de Hardware y Software en la Unidad de Logística con
soporte de personal especializado para el efecto.
Punto de vista –

105
PO3.5 Estándares de Tecnología
Observación PO16: No existen estándares de Tecnología establecidos.
Criterio –
La Gerencia deberá definir normas de tecnología con la finalidad de fomentar la
estandarización.
Condición
No existen políticas, normas ni estándares definidos exclusivamente para las
funciones y actividades relacionadas con las TIC's. (Evidencia: AUDI-ESPE-2007-
ENT-14; Reglamento General)
Causa –
§ Falta de Planificación estratégica Informática, en base a la cual se establezcan
los lineamientos para el tratamiento de la función de TI.
§ No se han designado responsabilidades que cubran estas actividades en
forma específica.
Efecto –
La carencia de Políticas, normas y estándares para la Gestión y Gerencia de las
TIC´s, no permite mantener confiabilidad en los sistemas de información, dificulta
la evaluación y estandarización del trabajo y no permite el cumplimiento operativo
de los objetivos y procesos. Se propicia un nivel alto de riesgo en las actividades
no controladas; impide la inducción y la regularización del trabajo cuotidiano.

106
§ El Director de la UDI, establecerá durante el primer bimestre las políticas
necesarias para definir los estándares de que se aplicará a las actividades de
TI.
§ El Director de la UTIC, dentro de los tres primeros meses del año en curso,
elaborará, tramitará su aprobación y pondrá en ejecución políticas, normas y
estándares para la regulación de las Funciones de TI. Se recomienda basar
estas en ITIL (Librería de las mejoras prácticas destinadas a facilitar la entrega
de Servicios de TI)
Punto de vista –
PO4. DETERMINACIÓN DE LA DIRECCIÓN TECNOLÓGICA
PO4.1 Planeación de TI o Comité de planeación/ dirección de la función de
servicios de información
Observación PO17: No existe comité de planeación o dirección para vigilar la
función de TI.
Criterio –

107
La gerencia de la organización deberá designar un Comité de Planeación o
Dirección para vigilar la función de TI y sus actividades. Entre los miembros del
comité deberán encontrarse representantes de la alta gerencia, de la gerencia
usuaria y de la función de TI. El comité deberá reunirse regularmente y reportar a
la alta gerencia.
Condición –
§ En la Estructura Organizacional de la ESPE y en las funcione definidas en el
Reglamento General de la ESPE (Art. 202), para la UTIC, no existe unidad o
entidad alguna de vigilancia de las funciones de TI. (Evidencia: AUDI-ESPE-
2007-ENT-005)
Causa –
§ Entre el personal de la UDI, encargado del diseño de la Organización
Institucional, no existe asesoría tecnológica especializada.
§ Falta de un plan estratégico Informático, en el cual se enmarque las
estrategias para la vigilancia de la función de TI.
Efecto –
La falta de un comité de vigilancia/dirección de TI, impide mantener una visión
coherente entre los objetivos institucionales y la gestión tecnológica. Ha
provocado toda la falencia evidente de orientación tecnológica, falta de planes,
estándares, regulaciones, evaluación, valoración y actualización tecnológica. El
riesgo es realmente crítico y ha tenido su efecto a través de los años ubicando a
la ESPE, fuera del grupo de universidades y politécnicas con tecnología de
avanzada.

108
El Director de la UDI, durante el primer bimestre del presente año, realizará el
rediseño organizacional de la Institución, estableciendo un organigrama
estructural conforme a la Técnica de Organización y Métodos e incluirá un comité
de vigilancia de la Función de TI en el nivel de Alta Gerencia; definirá sus
responsabilidades en base de los procedimientos de gerencia, dirección y
vigilancia de TI, enmarcado en ITIL (Librería de las mejoras prácticas destinadas
a facilitar la entrega de Servicios de TI).
Punto de vista –
PO4.2 Ubicación de los servicios de información en la organización
Observación PO18: La UTIC no se encuentra en un nivel organizacional en el
cual pueda asesorar y apoyar en la toma de decisiones ni realizar gestión
estratégica, solamente desarrolla funciones operativas. (Evidencia: AUDI-ESPE-
2007-ENT-005; TH-1)
Criterio –
La ubicación de la función de TI en la estructura organizacional general, mediante
la cual la alta gerencia deberá asegurar la existencia de autoridad, actitud crítica e

109
independencia con un grado tal que sea posible garantizar soluciones de
tecnología de información efectivas y progreso suficiente al implementarlas.
Condición –
La estructura organizacional de la ESPE, está definida mediante la “Red
Organizacional” en base de procesos, en donde la UTIC se encuentra en un nivel
operativo de soporte, con dependencia directa de la Gerencia Administrativa sin
embargo, aunque es parte de una Gerencia, este nivel no le permite asesorar o
participar en la toma de decisiones. (Evidencia: AUDI-ESPE-2007-ENT-005; TH-
1).
Causa –
§ Falta de Gestión estratégica a nivel institucional que permita mantener una
estructura organizacional adecuada en el área de TI.
§ No se ha realizado por parte de la ESPE, la organización estructural de la
UTIC, enfocada, en la importancia de esta para la institución
Efecto –
La ubicación inadecuada de la función de TI en la estructura organizacional
general, no permite asegurar la existencia de autoridad, actitud crítica e
independencia con un grado tal que sea posible garantizar soluciones de
tecnología de información efectiva y progreso suficiente al implementarlas.
Durante el primer trimestre del año en curso, el Director de la UDI, analizará y
evaluará el actual posicionamiento organizacional de la UTIC, de manera que se

110
ubique a esta Unidad, en un nivel en el que apoye de mejor manera a la
institución, considerando que se trata de una Institución de Educación Superior,
organizada en departamentos científicos y carreras profesionales, por lo que
deberá existir coherencia con los postulados de docencia, investigación y
extensión, para responder a las iniciativas clave del negocio y enfocarse en todas
las necesidades corporativas de automatización.
Punto de vista –
PO4.3 Revisión de Logros Organizacionales
Observación PO19: No existe revisión de Logros Institucionales.
Criterio –
Deberá establecerse un marco de referencia, con el propósito de revisar que la
estructura organizacional, cumpla continuamente con los objetivos y se adapte a
las circunstancias cambiantes.
Condición –
§ La UDI, no posee un proceso definido para la revisión de logros institucionales
de la función de TI, (evidencia: No. AUDI-ESPE-2007-ENT-005)
§ Falta de evaluación de eficiencia y efectividad de la estructura organizacional
de la Unidad de Tecnologías, además no existe definición clara de las

111
funciones, tareas o metas de cada GT; impidiendo la evaluación de los logros
institucionales.
Causa –
§ Falta del plan estratégico institucional que contenga la evaluación de la
estructura organizacional de TI.
§ Falta de evaluación de la estructura de la Unidad de Tecnologías, en
efectividad y eficiencia.
§ Falta de responsabilidad de supervisión.
Efecto –
§ La falta de una valoración y evaluación a la estructura organizacional conlleva
a desconocer si está dando los resultados necesarios en concordancia con los
objetivos a alcanzar de la Unidad u Organización, de tal manera que mediante
la evaluación continua de flujos de información en la estructura establecida,
evaluación de las funciones de la dirección, trabajo en conjunto optimo de los
elementos constitutivos de la estructura, indicadores de desempeño de la
función de TI en la Institución determinarían una organización conveniente en
número y habilidades, con tareas y responsabilidades definidas y
comunicadas, acordes con el negocio y que facilita la estrategia y provee una
dirección efectiva y un control adecuado.
El Director de la UDI desarrollará un marco de referencia para la evaluación,
valoración y análisis de la estructura organizacional actualmente implantada,

112
con el propósito de verificar que la estructura organizacional sea conveniente
en número y habilidades, con tareas y responsabilidades definidas y
comunicadas, acordes con el negocio y que facilita la estrategia y provee una
dirección efectiva y un control adecuado, además de mostrar un flujo de
información fluido.
Punto de vista –
PO4.4 Funciones y Responsabilidades
Observación PO20: No han sido determinadas en los manuales o reglamentos,
las responsabilidades y funciones del personal respecto de los sistemas de
información.
Criterio –
La Gerencia deberá asegurar que todo el personal en la organización conozca
sus funciones y responsabilidades en relación con los sistemas de información,
contar con la autoridad suficiente para llevar a cabo las funciones y
responsabilidades que le hayan sido asignadas. Ninguna persona en forma
individual deberá controlar todos los aspectos clave de una transacción o evento.
Condición –

113
• No existe estructura organizacional definida formalmente en la UTIC. (AUDI-
ESPE-2007-ENT-005), esta se encuentra establecida según los procesos
existentes de la Unidad.
• Las funciones de la Dirección de la UTIC se encuentran definidas en el
Reglamento General de la ESPE(Art. 202), las cuales no han sido
cumplidas, por esa razón no existe una Gestión de tecnología, planificación
y control de los proyectos y actividades de la UTIC y no se han dado las
directrices (Políticas, Normas y Estándares) para el control de la Función
de TI y sus actividades. (AUDI-ESPE-2007-ENT-005).
• Las funciones generales de la UTIC se encuentran definidas en el reglamento
General de la ESPE, sin embargo en la unidad no se ejecutan de la manera
prevista; porque las responsabilidades son divididas por el personal según la
carga de trabajo existente en cada área.
• Existen funciones y responsabilidades no definidas como por ejemplo: manejo
de Sistemas de Información, manejo del equipo Informático, acceso a
aplicativos (AUDI-ESPE-2007-ENT-004).
Causa –
§ Falta de un plan estratégico informático, alineado con el plan estratégico
institucional en base a los cuales se pueda definir funciones y
responsabilidades acordes.
§ Los procedimientos e instructivos no se encuentran detallados.
§ Falta de Gestión estratégica de la dirección de la UTIC para la definición de
funciones y responsabilidades acordes a los diferentes puestos establecidos y
falta de seguimiento.

114
Efecto –
La falta de definición de las funciones y responsabilidades y de políticas de
seguridad y acceso a la información sobre los sistemas de Información,
conlleva al incremento de los riesgos en la seguridad de la misma.
El Director de la UDI establecerá las responsabilidades y funciones del manejo
de los Sistemas de Información, mediante reglamentos y manuales,
enmarcados en ITIL (Librería de las mejoras prácticas destinadas a facilitar la
entrega de Servicios de TI).
Punto de vista –
PO4.5 Responsabilidad del aseguramiento de calidad
Observación PO21: No existen responsables del aseguramiento de la calidad, en
sistemas de información.
Criterio –
La Gerencia deberá asignar la responsabilidad de la ejecución de la función de
aseguramiento de calidad a miembros del personal de la función de servicios de
información y asegurar que existan sistemas de aseguramiento de calidad

115
apropiados, controles y experiencia en comunicaciones dentro del grupo de
aseguramiento de calidad de la función de servicios de información. La ubicación
de la función dentro del área de servicios de información, las responsabilidades y
el tamaño del grupo de aseguramiento de calidad deberán satisfacer los
requerimientos de la empresa.
Condición –
§ Según entrevista al director de la UTIC (AUDI-ESPE-2007-ENT-005), no existe
un grupo de Aseguramiento de la Calidad de la Función de TI, pese a la
existencia a nivel institucional del Macro Proceso de Seguimiento y Mejora de
los Servicios de Administración, mediante el cual se realiza la Gestión de la
Calidad para el mejoramiento continuo de los Servicios de Administración.
Causa –
§ Falta de un plan estratégico informático alineado con el plan estratégico
institucional en base a los cuales se pueda definir funciones y
responsabilidades acordes.
§ Falta de Gestión estratégica de la dirección de la UTIC para la definición de
funciones y responsabilidades acordes a los diferentes puestos establecidos.
§ Falta de segregación de funciones y responsabilidad de seguimiento.
Efecto –
§ La falta de un aseguramiento de la calidad conlleva a que la Función de TI no
logre satisfacer los requerimientos de la institución en su totalidad, por ende no
aporte a alcanzar las metas establecidas en el Plan Estratégico Institucional y
no se puedan efectuar procesos de mejora.

116
El Director de la UDI establecerá una comisión responsable del aseguramiento de
la calidad conformada por los miembros de la función de Servicios de información
y establecer sistemas de aseguramiento de calidad apropiados, para lo cual se
puede tomar como base el Aseguramiento de Calidad que ofrece ITIL (Librería de
las mejoras prácticas destinadas a facilitar la entrega de Servicios de TI).
Punto de vista –
PO4.6 Responsabilidad por la seguridad lógica y física
Observación PO22: No existen responsables de la seguridad lógica y física de
los datos, formalmente designados.
Criterio –
La Gerencia deberá asignar formalmente la responsabilidad de la seguridad lógica
y física de los activos de información de la organización a un Gerente de
Seguridad. Como mínimo, la responsabilidad de la Gerencia de seguridad deberá
establecerse a todos los niveles de la organización para manejar los problemas
generales de seguridad en la organización.
Condición –

117
• La UTIC, no posee una estructura en base a la cual se establecen los
responsables de la seguridad lógica y física de los activos de información.
(Evidencia: AUDI-ESPE-2007-005, AUDI-ESPE-2007-003, AUDI-ESPE-2007-
014,015 ).
• La UTIC, no tienen reglas definidas de acceso a la información, definición de
propietario o responsable del almacenamiento de la misma quien se pueda
definir como la encargada o la custodia de dicha información y quien sea la
responsable de respaldarla. (PO2.3)
• La ubicación física de los servidores es dispersa a pesar de existir un área
adecuada para estos, como son los de Talento Humano, Financiero, Biblioteca
atribuyendo esta situación a la falta de garantías en cuanto a resguardo de la
seguridad e integridad del mismo por parte de UTIC (Evidencia: AUDI-ESPE-
2007-ENT-002, AUDI-ESPE-2007-ENT-00X)
• No existen Políticas de seguridad de la información. (Evidencia: Memorando
No. 2007-1275-ESPE-d-6) por lo cual no están de acuerdo a la criticidad de la
información que se maneja.(Evidencia: SGC.DI.079)
Causa –
§ Falta de Gerencia de TI.
§ Falta de normatividad relativa al tema.
§ Falta de definición de procesos y funciones de importancia (servidores)
Efecto –
§ La no existencia de políticas, normas y estándares que regulen y
establezcan las lineamientos en cuanto a seguridad lógica y física de los

118
activos de información, aumentan el riesgo de acceso indebido a la
información, fraudes, alteraciones o pérdida de información crítica, en
definitiva limita la garantía en el almacenamiento de la información en
cuanto a seguridad e integridad.
§ El Director de la UTIC, dentro del primer trimestre del año en curso,
establecerá las políticas, normas y procedimientos; para la correcta
administración de servidores y asignación formal de la responsabilidad de la
seguridad lógica y física de los activos de información de la ESPE, tomando en
cuenta las mejores prácticas para el manejo de los mismos (Estipulados en
ITIL); así como también gestionar la reubicación de todos los servidores a la
sala de comunicaciones, con garantías establecidas para los mismos en
cuanto a su seguridad e integridad..
Punto de vista –
PO4.7 Propiedad y Custodia
Observación PO23: No se mantiene una estructura en base de la cual se
establezca propietarios y custodios de datos.
Criterio –

119
La Gerencia deberá crear una estructura para designar formalmente a los
propietarios y custodios de los datos. Sus funciones y responsabilidades deberán
estar claramente definidas.
Condición –
La UTIC no posee una estructura en base a la cual se establecen propietarios y
custodios de los datos. (Evidencia: Entrevista No. AUDI-ESPE-2007-005, No.
AUDI-ESPE-2007-003 No. AUDI-ESPE-2007-014)
Causa –
§ Falta de Gestión, dirección y control de la dirección de la Unidad para
establecer los propietarios.
§ Falta dé responsabilidad de supervisión.
Efecto –
El no poseer una estructura en base a la cual se establezcan los propietarios y
custodio de los datos, con sus roles, funciones y responsabilidades bien definidos,
conlleva a la falta de seguridad en la integridad, manipulación y posible pérdida
de información.
El Director de la UTIC, durante el primer trimestre del año en curso, establecerá
una estructura para designar formalmente a los propietarios y custodios de los
datos, definiendo las políticas necesarias para establecer claramente sus
responsabilidades y funciones.

120
Punto de vista –
PO4.8 Propiedad de Datos y Sistemas
Observación PO24: No existen propietarios asignados a los activos de
información.
Criterio –
La Gerencia deberá asegurar que todos los activos de información (sistemas y
datos) cuenten con un propietario asignado que tome decisiones sobre la
clasificación y los derechos de acceso. Los propietarios del sistema normalmente
delegarán la custodia diaria al grupo de distribución/operación de sistemas y las
responsabilidades de seguridad a un administrador de la seguridad. Los
Propietarios, sin embargo, permanecerán como responsables del mantenimiento
de medidas de seguridad apropiadas.
Condición –
§ No existen Políticas de Seguridad ni definición o asignación de propietarios de
la información, que tengan responsabilidad sobre la clasificación y los
derechos de acceso (Evidencia: No. AUDI-ESPE-2007-005, No. AUDI-ESPE-
2007-003, 2007-1275-ESPE-d-6).
Causa –
§ Falta de normatividad.

121
Efecto –
La responsabilidad no definida crea arbitrariedad en el acceso y confidencialidad
de los datos y el consiguiente riesgo en la integridad y disponibilidad de la
información.
§ El Director de la UTIC y el Director de Talento Humano, durante el primer
trimestre del año, establecerán los responsables de la clasificación y acceso a
la información y los propietarios de la información con sus respectivos
derechos.
§ El Director de la UTIC, establecerá políticas para registrar el acceso y los
cambios en los activos de información, para prevenir modificaciones no
autorizadas y que puedan ocasionar problemas para la continuidad del
negocio debido a información errónea o falsa.
Punto de vista –
PO4.9 Supervisión
Observación PO25: No existen prácticas de supervisión adecuadas en los
servicios de información.

122
Criterio –
La alta gerencia deberá implementar prácticas de supervisión adecuadas en la
organización de servicios de información, para asegurar que las funciones y
responsabilidades sean llevadas a cabo apropiadamente, para evaluar si todo el
personal cuenta con suficiente autoridad y recursos para llevar a cabo sus tareas
y responsabilidades, y para revisar de manera general los indicadores clave de
desempeño.
Condición –
§ La vigilancia y supervisión administrativa del Sistema de Gestión de Calidad, la
realiza la UDI, pero no existe una supervisión de gestión tecnológica.
§ No se establecen indicadores claves de desempeño en base a los cuales se
pueda evaluar al personal y funciones que desempeña. Los indicadores
presentados (SGCDI114), no aplican para la supervisión de los servicios de
información
Causa –
Falta de normatividad que contenga la estrategia y técnicas de supervisión de la
función de TI para su óptimo funcionamiento.
Efecto –
La falta de Prácticas de Supervisión adecuadas, de los servicios de información
impide el establecer la línea base para el mejoramiento continuo e incrementa la
falta de credibilidad en los sistemas de información, así como la valoración de las
inversiones que se da a la misma.

123
§ El Director de la UDI, durante el primer trimestre del año en curso, determinará
indicadores claves de desempeño específicos, para cada proceso descrito en
la UTIC, de manera que esta información permita la evaluación y valoración de
la Función de TI y establecerá políticas de supervisión de los servicios de
información, enmarcados en las prácticas estipuladas en ITIL.
Punto de vista –
PO4.10 Segregación de Funciones
Observación PO26: No existe segregación de funciones.
Criterio –
La alta gerencia deberá implementar una división de roles y responsabilidades
que excluya la posibilidad de que un solo individuo responda un proceso crítico.
La Gerencia deberá asegurar también que el personal lleve a cabo únicamente
aquellas tareas estipuladas para sus respectivos puestos. En particular, deberá
mantenerse una segregación de funciones entre las siguientes funciones: uso de
sistemas de información; entrada de datos; operación de cómputo; administración
de redes; administración de sistemas; desarrollo y mantenimiento de sistemas

124
administración de cambios administración de seguridad; y auditoría a la
seguridad.
Condición –
§ La UTIC, posee funciones y responsabilidades asignadas definidas en la Lista
de Personal y Funciones presentada por la UTIC (Evidencia DP-1), sin
embargo la segregación de funciones no se ejerce ya que éstas se adjudican
de acuerdo a la carga de trabajo. (AUDI-ESPE-2007-ENT-
001,002,003,004,005)
§ La Unidad de Talento Humano mantiene el orgánico funcional y numérico
aprobado (Enero 2008), en los que se observa que la descripción de Puestos
para las funciones definidas no tienen concordancia con las funciones
descritas por el personal de la UTIC. (Evidencia:TH-2 TH-3).
§ Existen funciones y responsabilidades de importancia que no se encuentran
definidas (Evidencia: AUDI-ESPE-2007-ENT-001,002,003,004,005, PO4.4)
Causa –
§ El orgánico funcional de la ESPE, se encuentra en proceso de elaboración y
aprobación hasta Noviembre del 2007. (AUDI-ESPE-ENT-014).
§ No existen políticas ni lineamientos definidos para segregar funciones.
§ No existe un estudio adecuado de clasificación de puestos y división de trabajo
(Evidencia: DSx).
Efecto –

125
§ La falta de definición de un orgánico funcional de la organización no permite
una apropiada inducción y desempeño dentro de los roles y responsabilidades
que el personal tanto de TI como de las otras unidades deben cumplir.
§ La definición de funciones y segregación de las mismas, no permite la
especialización y experticia en el desempeño de las mismas, además de
riesgos en la seguridad en la administración de activos de información de la
Institución.
El Director de la UTIC, establecerá políticas para establecer la segregación
correcta de funciones y excluir la posibilidad de que un solo individuo responda a
un proceso crítico.
Punto de vista –
PO4.11 Asignación de Personal para Tecnología de Información
Observación PO27: No existe evaluación formal para determinar los
requerimientos de asignación de personal de la UTIC.
Criterio –

126
Las evaluaciones de los requerimientos de asignación de personal, deberán
llevarse a cabo regularmente, para asegurar que la función de servicios de
información cuente con un número suficiente de personal competente de
tecnología de información.
Los requerimientos de asignación de personal deberán ser evaluados por lo
menos anualmente o al presentarse cambios mayores en el negocio, en el
ambiente operacional o de tecnología de información. Deberá actuarse
oportunamente tomando como base los resultados de las evaluaciones para
asegurar una asignación de personal adecuada en el presente y en el futuro
Condición –
§ La Unidad de Talento Humano (UTH), tiene un proceso de Provisión de
Personal, sin embargo en este no se evidencia proceso de análisis para la
creación de requerimientos de personal.(Evidencia: AUDI-ESPE-2007-ENT-
014, TH 3.1)
§ La UTIC, se encuentra en un punto crítico en cuanto a personal, porque
existen vacantes que no han sido suplidas por más de 6 meses a pesar de la
carga de trabajo existente. (Evidencia: AUDI-ESPE-2007-ENT-005)
§ La Unidad de Tecnología, no posee proceso de evaluación para el análisis de
requerimientos de personal. (Evidencia: AUDI-ESPE-2007-ENT-005).
§ No existe continuidad en la gestión de la dirección de la Unidad, debido a las
políticas internas de designación como Director de la UTIC a Oficiales en
servicio activo, con especialidad en electrónica, no en sistemas e informática,
con periodos de cambio muy corto.(Art. 203-204 Reglamento General ESPE)
Causa –

127
§ Falta de políticas adecuadas para administración de Recursos Humanos.
Efecto –
El establecer evaluaciones de requerimientos de asignación de personal permite
obtener una institución adecuada en número y en habilidades, con roles y
responsabilidades definidos y comunicados, alineados con el negocio y que
facilita la estrategia y provee la orientación efectiva y el control adecuado.
Durante el primer trimestre del presente año, el Director de Talento Humano
establecerá un procedimiento para evaluar los requerimientos y asignar personal
competente de tecnología de información.
Punto de vista –
PO4.12 Descripción de Puestos para el Personal de la Función de TI.
Observación PO28: La Descripción de puestos para el personal de la UTIC, no
se encuentra correctamente definida.
Criterio –

128
La Gerencia deberá asegurar que las descripciones de los puestos para el
personal de TI sean establecidas y actualizadas regularmente. Estas
descripciones de puestos deberán delinear claramente tanto la responsabilidad
como la autoridad, incluir las definiciones de las habilidades y la experiencia
necesarias para el puesto, y ser adecuadas para su utilización en evaluaciones de
desempeño.
Condición –
Mediante estudio documental del Manual de Descripción de Puestos y la
Estructura Orgánica Funcional, podemos determinar que la descripción de cargos
establecidos, en relación con las funciones que actualmente el personal ejerce, no
se encuentran alineados. (Evidencia: DP-1, TH-2, TH-3)
Causa –
§ Falta de Administración de Recursos Humanos.
§ Orgánico funcional y Descripción de puestos establecido sin un proceso
correcto de definición.
§ Falta de Gestión de la dirección de la UTIC.
§ Falta de capacitación de la UTH en lo que referencia a la descripción de
puestos de la UTIC.
Efecto –
La falta de descripción de puestos no permite definir la responsabilidad ni la
autoridad en los cargos, se incurre en una selección inadecuada de personal que
carece de habilidades y experiencia necesarias para el puesto, además de que no
se puede lograr evaluaciones de desempeño reales.

129
El Director de Talento Humano, realizará un análisis de puestos de manera
técnica, para definir el orgánico posicional de la UTIC, mediante el análisis de
necesidades y requerimientos reales que evite creación de cargos innecesarios,
además de una descripción de puestos que este acorde al nivel profesional que
se necesita.
Punto de vista –
PO4.13 Personal clave de TI
Observación PO29: No se ha definido el personal clave de la UTIC.
Criterio –
La Gerencia de TI deberá definir e identificar al personal clave de tecnología de
información.
Condición –
§ El director de la UTIC clasificó a su personal en el siguiente orden de
importancia:
o Personal de GT3, Redes y Comunicaciones

130
o Personal de GT2, Soporte Técnico
o Personal de GT4 y GT5, Sistemas de Información.
§ No existe documento de análisis o designación que evidencie la definición de
personal clave de TI (Evidencia: AUDI-ESPE-2007-ENT-005)
Causa –
§ Falta de Administración de Recursos Humanos.
§ Falta de gestión de la Dirección de la UTIC
§ Falta de políticas institucionales de TI.
Efecto –
La identificación del Personal Clave de TI, muestra que hay procesos claros de
dirección y control, con segregación donde se necesita, especialización donde se
requiere y delegación de autoridad donde sea beneficioso.
Dentro del primer trimestre del año en curso, el Director de Talento Humano, con
el apoyo del Director de la UTIC, establecerá un procedimiento de análisis y
determinará el personal clave específico de TI.
Punto de vista –

131
PO4.14 Procedimientos y políticas para el personal contratado
Observación PO30: No existen políticas para controlar actividades del personal
externo contratado por la UTIC.
Criterio –
La Gerencia deberá definir e implementar políticas y procedimientos relevantes,
para controlar las actividades de consultores y demás personal externo contratado
por la función de TI, para asegurar la protección de los activos de información de
la organización
Condición –
§ La Unidad de Talento Humano en sus procesos no define un proceso para
reclutamiento y contratación de personal externo.(Evidencia TH3.1, TH3.2,
TH3.3)
§ La UTIC, no posee políticas o procedimientos establecidos para el tratamiento
de personal externo contratado (Servicios ocasionales). (Evidencia AUDI-
ESPE-2007-ENT-005)
Causa –
§ Falta de una Administración de Recurso humano.
§ Falta de políticas establecidas institucionalmente, para el manejo de Personal
externo contratado.
Efecto –
La falta de Procedimientos y políticas para el personal contratado conlleva a
poner en riesgo la protección de los activos de información de la organización.

132
§ El Director de Talento Humano, definirá en el primer trimestre del año en
curso, el proceso de contratación de personal externo (Servicios
Profesionales).
§ El Director de la UTIC, establecerá Procedimientos y políticas para el personal
contratado, encaminadas a resguardar la seguridad de los activos de TI.
Punto de vista –
PO4.15 Relaciones
Observación PO31: La UTIC no mantiene relaciones óptimas, fluidas e
interactivas.
Criterio –
La Gerencia de TI deberá llevar a cabo las acciones necesarias para establecer y
mantener una coordinación, comunicación y un enlace óptimos entre la función de
TI y demás interesados dentro y fuera de la función de servicios de información
(usuarios, proveedores, oficiales de seguridad, administradores de riesgos)

133
Condición –
§ Las acciones para mantener la coordinación, comunicación y enlace de la
UTIC con otras Unidades están definidas en los procesos establecidos en el
SGC, en cuyos diagramas de flujo se observa la participación de cada unidad
así como su responsabilidad sobre los procesos y la manera de relación,
coordinación y comunicación; las mismas que se realizan mediante reuniones
entre los involucrados en los procesos y memorandos, que no siempre son
efectivas (Evidencia: SGC, AUDI-ESPE-2007-ENT-004).
Causa –
Falta de normatividad y entendimiento del rol de los sistemas de información en la
organización.
Efecto –
No establecer acciones de coordinación, comunicación y enlace, limita la
participación de la UTIC en procesos de decisión, para responder a las iniciativas
clave del negocio y enfocándose en todas las necesidades corporativas de
automatización.
En el primer trimestre del año en curso, el Director de la UTIC, establecerá
procedimientos y políticas para mejorar la coordinación, comunicación y enlace
de la Unidad con usuarios y proveedores.
Punto de vista –

134
PO5. MANEJO DE LA INVERSIÓN EN TECNOLOGÍA DE LA INFORMACIÓN
PO5.1 Presupuesto Operativo Anual para la Función de Servicios de
información.-
Observación PO32: El presupuesto asignado se fija únicamente de acuerdo a
techos presupuestarios, sin evidencia de alternativas de financiamiento.
Criterio –
La alta gerencia deberá implementar un proceso de asignación de presupuestos,
para asegurar que un presupuesto operativo anual para TI sea establecido y
aprobado en línea con los planes a largo y corto plazo de la organización, así
como con los planes a largo y corto plazo de tecnología de información. Deberán
investigarse alternativas de financiamiento.
Condición –
§ El presupuesto anual asignado para la UTIC, no se fija de acuerdo a la
priorización de necesidades institucionales, ni plan de infraestructura
tecnológica (PO3), sino únicamente de acuerdo a los techos presupuestarios
de la ESPE y bajo criterios del staff (rector, HCP, directores de cada una de
las unidades, planificación), no existe evidencia del uso de otras alternativas
de financiamiento, por lo que no siempre se asigna la totalidad del

135
presupuesto solicitado por las unidades. (Evidencia: AUDI-ESPE-2007ENT-
012).
§ De acuerdo lo revisado para la conclusión del PO1 referente a planes
estratégicos y portafolio de proyectos de TI, se evidencia que tampoco
existen procedimientos para la asignación de presupuesto alineados con
objetivos estratégicos de la organización ya que NO existe un plan
estratégico de UTIC.
§ Cada usuario (en este caso las unidades) ponen el valor referencial a sus
necesidades y no se realiza un análisis real de los costos de proyectos
Causa –
§ Procedimientos de planificación y priorización de proyectos no adecuados,
centralismo no participativo.
Efecto –
§ Al carecer de un plan de infraestructura tecnológica, no se puede
argumentar la necesidad y la importancia de la inversión en ella como para
que pueda formar parte del POA aprobado y que se le asigne el presupuesto
necesario.
§ Al no hacer un análisis del presupuesto solicitado o pedir dicho análisis para
presentar el presupuesto de los proyectos, se podría estar
sobredimensionando el costo de los mismos.
§ Si el único presupuesto con el que se cuenta es el techo presupuestario de
la ESPE por medio de la asignación por parte del ministerio, podría no

136
cubrirse la necesidad de presupuesto para poner en marcha proyectos
necesarios para el avance de la institución.
§ Al realizar priorizaciones de los proyectos sin una base técnica y sin revisar
si el proyecto está alineado con el plan estratégico institucional, se estaría
aprobando proyectos que muchas de las veces no aportarían al logro de los
objetivos institucionales.
El Director de la UDI, establecerá un procedimiento para permitir la presentación
de los proyectos con un justificativo y análisis de costos reales, además de una
selección apropiada de alternativas a la solución del problema presentado, para
que esto sirva para la priorización y aprobación de los proyectos, en base de un
instructivo apropiado, que considere el impacto de cada proyecto en el
cumplimiento de los objetivos institucionales.
Punto de vista –
PO5.2 Monitoreo de Costo – Beneficio
Observación PO33: No existe monitoreo Costo- Beneficio
Criterio –

137
La Gerencia deberá establecer un proceso de monitoreo de costos que compare
los costos reales contra los presupuestados. Aun más, los posibles beneficios
derivados de la actividad de tecnología de información deberán ser identificados y
reportados.
Condición –
§ No existe evidencia de análisis costo-beneficio (Evidencia: análisis proceso
DS6 y AI1 referente a información sobre el desempeño y capacidad) que se
realice como parte de la presentación o monitoreo de proyectos, no se tiene
un documento en donde se resuma o reporte el análisis comparativo de lo
presupuestado contra el gasto real, a pesar de que se tiene como evidencia
los certificados de existencia de fondos (AUDI-ESPE-2007ENT-004);
únicamente se realizan reportes en caso de gastos imprevistos, en los que
se debe quitar el presupuesto asignado a otros proyectos para cubrir
contingencias, porque esto debe informarse al Ministerio de Defensa.
§ No existe un control de gastos por parte de la UDI, ya que es responsable
únicamente de la planeación del gasto mas no del control de estos
§ De acuerdo al mapa de procesos provista por el SGC quien debe llevar este
proceso es el Director Financiero (referencia: memo 2007-0216-SGC).
§ No existen revisiones post-implementación, de acuerdo con la información
evaluada en el AI7.
§ No se ha realizado un plan de disponibilidad de servicios de tecnología
(Evidencia correlacionada: análisis Dominio Soporte y Servicios: DS3).

138
Causa –
§ No existe un plan estratégico de sistemas de información que se encuentre
alineado con el institucional por lo cual no existe un aseguramiento de la
alineación de los proyectos con los objetivos de la institución (referencia:
PO1).
§ Falta de cultura de monitoreo.
Efecto –
§ La ejecución de los proyectos podrían no estar brindando a la ESPE los
beneficios esperados por su implementación ni el aporte al cumplimiento de
los objetivos institucionales.
§ Se pueden incurrir en gastos innecesarios para la organización.
§ El Director de la UDI, establecerá un procedimiento para la presentación de
los proyectos, con un análisis justificativo de los beneficios que se percibirán
al ejecutarlos.
§ El Director de la UDI, establecerá un procedimiento para el monitoreo de los
proyectos, mediante una bitácora en la que se incluirá el detalle de los
gastos en que incurre el proyecto y la comparación con lo presupuestado en
cada actividad; luego de la implementación de los proyectos se deberá
presentar un análisis, para determinar si los proyectos permitieron alcanzar
los beneficios esperados.

139
Punto de vista –
PO5.3 Justificación de Costo – Beneficio
Observación PO34: No existe evidencia de análisis que justifiquen costos de
servicios y actividades de la UTIC
Criterio –
Deberá establecerse un control gerencial que garantice que los servicios que
presta la función de TI, presenten un costo justificado y se encuentren en línea
con la industria. Los beneficios derivados de las actividades de tecnología de
información deberán ser analizados en forma similar.
Condición –
§ De acuerdo a la información presentada en detalle en el dominio de Adquisición
e Implantación (AI1), se conoce que por la cantidad de proyectos que en la
ESPE se manejan, no existe un aseguramiento de la alineación de los
proyectos con los objetivos de la organización o con la industria.
§ No se tiene evidencia que certifique que al momento de la evaluación de
aprobación de proyectos, se revise toda la información presentada sobre el
mismo.

140
§ No existe análisis justificativo de costos de los servicios y actividades de la
UTIC (Evidencia: DS6 identificación y asignación de costos, AUDI-ESPE-
2007ENT-005)
Causa –
§ No existe dicho control por parte del área de planificación de la ESPE, ya
que únicamente se encargan de la planificación del gasto mas no del análisis
de los proyectos y presupuestos presentados por cada una de las unidades.
(AUDI-ESPE-2007ENT-012)
§ En la investigación del dominio Mantenimiento y Soporte (DS3
administración de desempeño y capacidad), se señala que no se ha
realizado un plan de disponibilidad de servicios de tecnología, con el cual se
pueda llevar un control adecuado del funcionamiento de los servicios de
tecnología implantados en la ESPE.
§ La justificación de la existencia o no de un servicio o si este debe
permanecer activo o si está alineado con la industria actual, requiere de un
monitoreo post-implementación, bajo el cual se pueda justificar el seguir
incurriendo en el costo de la existencia del mismo, monitoreo que de
acuerdo con la información obtenida en el dominio de Adquisición e
implementación (AI7 instalar y acreditar soluciones y cambios), no existe.
Efecto –
§ Sin control o monitoreo sobre los proyectos que se llevan a cabo en la
unidad, es imposible justificar la inversión en TI ni mantener credibilidad en
los servicios.

141
§ Sin un análisis de servicios y su disponibilidad, tampoco se puede llegar a
una justificación de los costos por mantenimiento y mejoramiento de los
mismos.
§ Al no realizar un análisis de que los servicios estén alineados con los
objetivos de la organización, puede ser que estos servicios sean
innecesarios y se estén incurriendo en gastos que no apoyan al crecimiento
de la organización y a alcanzar sus objetivos.
§ Si no se mantiene un análisis de costos, tampoco se puede cobrar por esos
servicios a los usuarios, ni elaborar presupuestos adecuados para su
desarrollo y mejora.
§ Hasta el primer trimestre del año en curso, el Director de la UTIC,
determinará el costo de los servicios que presta la unidad, incluyendo costos
de inversión, operación y mantenimiento.
§ Durante el primer trimestre del año en curso, el Director de la UDI, evaluará
los servicios que presta la UTIC y determinará si los servicios que se están
prestando, aportan al cumplimiento de los objetivos y la visión de la
institución y con ello justificar su existencia, eliminación o mejoramiento.
Punto de vista –

142
PO6. COMUNICACIÓN DE LOS OBJETIVOS Y ASPIRACIONES DE LA
GERENCIA
PO6.1 Ambiente Positivo de Control de la Información
Observación PO35: No existen manuales de ética para la ESPE, ni evidencia de
programas de concientización para fomentar ambiente de control positivo.
Criterio –
Con el fin de proveer guías para el desempeño apropiado, evitar tentaciones de
acciones no éticas y crear disciplina donde se requiera, la Gerencia deberá crear
un marco de referencia y un programa de concientización que fomente un
ambiente de control positivo a través de toda la organización.
Condición –
§ De acuerdo a entrevista mantenida, la Procuradora de la ESPE, señala que no
existe un código de ética. (Evidencia: AUDI-ESPE-2007ENT-014)
§ En el reglamento General de la ESPE, el capítulo III referente a los valores
institucionales, estipula que la conducta de todo el personal de la institución,
estará bajo la práctica de los valores enunciados en el artículo 4, pero se no
enuncia sanciones en caso de incumplimiento de las mismas.
Causa –
No se ha considerado la necesidad de creación de manuales de ética, por falta de
interés o por extremada confianza en el personal de la institución.

143
Efecto –
Al no existir un código de ética difundido nivel de la ESPE, ni programas que
propicien esta actividad, la Institución se encuentra sujeta a riesgos potenciales
de comportamientos poco éticos, en la implantación, uso y evaluación de los
sistemas de información.
Durante el primer trimestre del año en curso, el Director de la UTIC, elaborará un
código de ética, gestionará su aprobación y pondrá en marcha un programa anual
de concientización ética, para la implantación, uso y evaluación de los sistemas
de información, en los que se incluyan normas de conducta y disciplina,
estipulando sanciones en caso de ser infringidas.
Punto de vista –
PO6.2 Responsabilidad de la Gerencia sobre las Políticas
Observación PO36: No existen políticas referentes a tecnología de la información
y se desconoce la responsabilidad acerca de su difusión.
Criterio –

144
La Gerencia deberá asumir la responsabilidad completa de la formulación, el
desarrollo, la documentación, la promulgación y el control de políticas que cubran
metas y directrices generales.
Condición –
§ No existen políticas definidas acerca de TI. (Evidencia: AUDI-ESPE-2007ENT-
005, AUDI-ESPE-2007ENT-014)
§ El Reglamento General de la ESPE estipula que el encargado de proponer
reformas a la normativa institucional y proponer proyectos de reglamentos,
normas y otros es la Procuraduría; en el mismo reglamento se determina que el
director de la UTIC es quien debe tomar las acciones necesarias para la
promulgación y aprobación de políticas de la unidad a la cual pertenece.
(referencia: reglamento general de la ESPE, cap X, art 61, literal p y o)
Causa –
§ Desconocimiento del encargado de promulgar las normativas sobre sistemas de
información, que de acuerdo a la entrevista es el director de UTIC (referencia:
AUDI-ESPE-2007ENT-014).
§ Desconocimiento de las políticas expuestas en el reglamento general de la
ESPE.
§ Falta de conocimiento de estándares internacionales de seguridad de la
información y la importancia de las mismas.
Efecto –

145
§ Se incurre en riesgos en seguridad de información; causada por alteraciones,
robo o pérdida, que podría atentar contra la continuidad del negocio y el
objetivo de mejora continua.
Hasta el primer trimestre del año en curso, el Director de la UDI, formulará,
desarrollará, documentará, promulgará y controlará la ejecución de políticas que
cubran metas y directrices generales, referidas a TI.
Punto de vista –
PO6.3 Comunicación de las Políticas de la Organización
Observación PO37: No existe evidencia de métodos de comunicación de
políticas organizacionales.
Criterio –
La Gerencia deberá asegurar que las políticas organizacionales sean claramente
comunicadas, comprendidas y aceptadas por todos los niveles de la organización.
Condición –

146
§ No existen Leyes y reglamentos específicos sobre TI (Evidencia: AUDI-ESPE-
2007ENT-005, AUDI-ESPE-2007ENT-014).
§ El reglamento general de la ESPE, establece que procuraduría está encargada
de difundir la normatividad institucional y remitirla a la Unidad de Tecnologías de
Información y Comunicación para su publicación en el portal institucional
(referencia: Reglamento General de la ESPE, cap X, art 61, literal r).
Causa –
§ No existen políticas de TI para ser difundidas.
§ No existe una planificación de comunicación de políticas mediante el cual se
asegure que el personal revisó dicho reglamento.
§ No existe diseñado ni implantado un sistema de comunicación organizacional.
Efecto –
§ La falta de de políticas incrementan significativamente los riesgos en seguridad
de los sistemas de información, especialmente en la deficiente operación de
ellos.
El Director de la UDI, diseñará y pondrá en ejecución un sistema de comunicación
organizacional, para comunicar las políticas institucionales referidas a TI.
Punto de vista –

147
PO6.4 Recursos para la implementación de Políticas.
Observación PO38: No existe evidencia de asignación de recursos para
implantación de políticas de TI.
Criterio –
La Gerencia deberá destinar recursos para la implementación de sus políticas y
para asegurar su cumplimiento, de tal manera que ellas se construyan dentro y
formen parte integral de las operaciones
Condición –
§ No existe evidencia de recursos asignados, considerando que no existen
políticas de TI establecidas (Evidencia: AUDI-ESPE-2007ENT-005).
§ De acuerdo al reglamento general de la ESPE, capítulo XIV referente al
DIRECTOR DE LA UNIDAD DE TECNOLOGÍAS DE LA INFORMACIÓN Y
COMUNICACIÓN, artículo 202, literal k. Autoriza al director de la unidad a
promulgar políticas que le permitan su adecuada gestión, políticas que deben
ser presentadas a procuraduría para ser aprobadas e implantadas dentro del
área.
Causa –
§ Falta de inducción y desconocimiento de la funciones del Director de la UTIC así
como de las políticas institucionales a las que se rige.
Efecto –

148
Si no existen recursos para promulgar políticas, se promueve un desinterés
peligroso en cuanto al desarrollo de tecnologías de Información.
El Director de la UDI, gestionará la asignación de recursos para la promulgación
de políticas de TI, a través del sistema de comunicación organizacional diseñado
e implantado.
Punto de vista –
PO6.5 Mantenimiento de Políticas
Observación PO39: No existe evidencia de mantenimientos de políticas de TI, ya
que estas no existen
Criterio –
Las políticas deberán ser ajustadas regularmente para adecuarse a las
condiciones cambiantes.
Condición –

149
No existe evidencia de los mantenimientos ya que tampoco existen
reglamentaciones de TI (Evidencia: AUDI-ESPE-2007ENT-005, AUDI-ESPE-
2007ENT-014)
Causa –
• Falta de conocimiento de estándares internacionales referentes a TI y su
gerenciamiento.
Efecto –
Cuando no se actualizan las políticas de TI, estas pierden vigencia y aumentan
los riesgos referidos y la institución pierde competitividad.
El Director de la UDI, establecerá un procedimiento semestral de revisión y
actualización de políticas de TI, que será ejecutado por el Director de la UTIC.
Punto de vista –
PO6.6 Cumplimiento de Políticas, Procedimientos y Estándares
Observación PO40: No existe evidencia de procedimientos para monitorear si el
personal de la institución ha comprendido y cumplido la normatividad institucional.
Criterio –

150
La Gerencia deberá asegurar que se establezcan procedimientos apropiados para
determinar si el personal comprende los procedimientos y políticas
implementados, y que éste cumple con dichas políticas y procedimientos.
Condición –
No existen registros ni estudios relacionados con la comprensión y cumplimiento
de normatividad institucional; de acuerdo a la entrevista mantenida con la Sra.
Procuradora (referencia: AUDI-ESPE-2007ENT-014), señala que los encargados
de vigilar el cumplimiento de los reglamentos y políticas son todas y cada una de
las personal de la ESPE y se encuentra a cargo de todos los funcionarios de la
misma en la medida de sus responsabilidades.
Causa –
Desconocimiento del control interno.
Efecto –
Si se desconoce que el personal comprenda las políticas, no existe seguridad en
la implementación de éstas, ineficiencia e ineficacia.
El Director de la UTIC, establecerá procedimientos apropiados para determinar si
el personal comprende los procedimientos y políticas implementados, y que éste
cumple con dichas políticas y procedimientos.
Punto de vista –

151
PO6.7 Compromiso con la Calidad
Observación PO41: No se han definido ni documentado políticas ni objetivos de
tI orientados hacia la calidad.
Criterio –
La Gerencia de la función de servicios de información deberá definir, documentar
y mantener una filosofía de calidad, así como políticas y objetivos que sean
consistentes con la filosofía y las políticas de la corporación a este respecto.
Condición –
No existe evidencia de manuales o documentación de la UTIC específica
orientada hacia la calidad.
Causa –
El control de calidad se encuentra centralizado en la UDI, pero la esta unidad no
efectúa gerenciamiento de TI.
Efecto –
Es imposible conseguir calidad o certificarse sin el compromiso formal de la
calidad, sólo podría ser algo aparente pero no efectivo.

152
El Director de la UTIC, definirá, documentará y mantendrá una filosofía de calidad,
así como políticas y objetivos que sean consistentes con la filosofía y las políticas
de la ESPE a este respecto.
Punto de vista –
PO6.8 Política sobre el Marco de Referencia para la Seguridad y el Control
Interno.
Observación PO42: No existen políticas sobre el marco de referencia para la
Seguridad y el Control Interno.
Criterio –
La Gerencia deberá asumir la responsabilidad total del desarrollo y mantenimiento
de una política sobre el marco de referencia, que establezca el enfoque general
de la organización en cuanto a seguridad y control interno para establecer y
mejorar la protección de los recursos de tecnología de información.
Condición –
§ No existe evidencia de la emisión de políticas referidas a seguridad ni al
cumplimento del control interno (Evidencia: AUDI-ESPE-2007ENT-014,
Reglamento general de la ESPE).

153
§ El Director de Talento Humano, informa que esta dirección se encuentra a cargo
de la función de Inteligencia y de control interno, según determinan reglamentos
militares para el efecto (Evidencia: AUDI-ESPE-2007ENT-013).
Causa –
• Desconocimiento de las mejores prácticas de TI.
Efecto –
No se puede establecer y mejorar la protección de los recursos de tecnología de
información.
El Director de la UDI, asumirá la responsabilidad total del desarrollo y
mantenimiento de una política sobre el marco de referencia, que establezca el
enfoque general de la organización en cuanto a seguridad y control interno de TI.
Punto de vista –
PO6.9 Derechos de propiedad intelectual
Observación PO43: No existen políticas desarrolladas sobre derechos de
propiedad intelectual.

154
Criterio –
La gerencia deberá proveer e implementar una política por escrito sobre derechos
de propiedad intelectual, que cubra el desarrollo de software, tanto interno como
contratado a externos.
Condición –
No existe evidencia de políticas o reglamentos referidos a los Derechos de
propiedad intelectual (Evidencia: AUDI-ESPE-2007ENT-014)
Causa –
§ Desconocimiento de la aplicación de Ley en la Institución.
§ No se han considerado las aplicaciones desarrolladas en tesis de grado.
Efecto –
Riesgo de piratería de software e incumplimiento de la ley con sus
consecuencias.
La Procuradora de la ESPE, dentro del primer trimestre del año en curso,
presentará para su aprobación por parte del Consejo Politécnico, el reglamento
interno para la aplicación de la Ley de propiedad intelectual en la ESPE.
Punto de vista –

155
PO6.10 Políticas para Situaciones Específicas
Observación PO44: No existen políticas que se apliquen a situaciones
específicas.
Criterio –
Deberán ponerse en práctica medidas que aseguren el establecimiento de
políticas, para situaciones específicas con el fin de documentar las decisiones
gerenciales con respecto al tratamiento de actividades, aplicaciones, sistemas o
tecnologías particulares.
Condición –
En los reglamentos de la ESPE, no existe evidencia de normas referentes a
políticas, procedimientos o tratamiento de situaciones particulares. (Evidencia:
AUDI-ESPE-2007ENT-014)
Causa –
No se han realizado políticas de TI generales, por lo que se concluye que
tampoco se las ha realizado para el tratamiento de sistemas o aplicaciones
particulares.
Efecto –
Al presentarse algún tipo de situación no conocida o que no se ha dado antes en
la institución, no existe ninguna política que permita tomar decisiones al respecto,
creando incertidumbre y problemas legales.

156
El Director de la UTIC, mantendrá un registro de situaciones especiales para
asegurar el establecimiento de políticas, que permitan decisiones gerenciales con
respecto al tratamiento de actividades, aplicaciones, sistemas o tecnologías
particulares.
Punto de vista –
PO6.11 Comunicación para educar y concienciar (crear conciencia) sobre
Seguridad de TI.
Observación PO45: No existe evidencia de procedimientos o campañas de
concientización sobre seguridad de TI.
Criterio –
Un programa de concientización sobre seguridad de TI debe comunicar las
políticas de TI a cada usuario de TI y asegurar el completo entendimiento de la
importancia de la seguridad de TI.
Condición –
Debido a la no existencia de políticas y reglamentos sobre seguridades, se puede
concluir que no existen programas de concientización sobre la seguridad, ni se
puede asegurar el entendimiento de las mismas por parte del usuario (Evidencia:
AUDI-ESPE-2007ENT-014, AUDI-ESPE-2007ENT-005)

157
Causa –
Inexistencia de políticas de seguridad de TI.
Efecto –
Al no tener el usuario conocimiento de la importancia de TI y de su colaboración
para la seguridad de información, podría convertirse en una fuente por medio de
la cual se generen debilidades para la institución.
El Director de la UTIC, diseñará un programa anual de concienciación, para
promover el conocimiento y práctica de políticas de seguridad; este programa
incluirá indicadores de evaluación de la efectividad del programa, así como el
procedimiento para esta evaluación.
Punto de vista –
PO7. ADMINISTRACIÓN DE RECURSOS HUMANOS
PO7.1 Reclutamiento y Promoción de Personal
Observación PO46 – No existe estructura orgánica funcional definida.

158
Criterio –
La Gerencia deberá implementar y evaluar regularmente los procesos necesarios
para asegurar que las prácticas de reclutamiento y promoción de personal tengan
como base criterios objetivos y consideren factores como la educación, la
experiencia y la responsabilidad.
Condición –
§ La UTH tiene definido el subproceso de Reclutamiento de Personal dentro del
proceso de Provisión de Personal (Evidencia: TH3.1), sin embargo no existe
evidencia (registros) de las prácticas de reclutamiento y promoción de personal.
§ En la UTIC, existen varias vacantes no atendidas desde hace más de seis
meses. (Evidencia: AUDI-ESPE-2007-ENT-005)
§ La ESPE no posee orgánico funcional y numérico establecido, así como un
manual de descripción de cargos actualizado que permitan establecer de
manera correcta los perfiles para los cargos de la UTIC.
§ Se desconoce la forma en la que se designan Directores de la UTIC y su
proceso de selección.
Causa-
La estructura orgánica funcional y administración de personal, se encuentra en
una reestructuración con asesoramiento de la SENRES en cuanto a lo que tiene
que ver con los tipos de contrato, remuneraciones, etc. (AUDI-ESPE-2007-ENT-
014)
Efecto –

159
La falta de una clara descripción de puestos y la definición de un orgánico
funcional y numérico conlleva a la deficiencia en el desarrollo y mantenimiento de
un plan de administración de recursos humanos, que apoye al plan estratégico
institucional.
En el primer trimestre del año en curso, el Director de Talento Humano,
implementará y evaluará regularmente los procesos necesarios para asegurar que
las prácticas de reclutamiento y promoción de personal tengan como base
criterios objetivos y consideren factores como la educación, la experiencia y la
responsabilidad.
Punto de vista –
PO7.2 Personal Calificado
Observación PO47 – La Gerencia de la Función de TI no realiza calificación y
procesos de educación, entrenamiento y/o experiencia apropiados para el
personal.
Criterio –

160
La Gerencia de la función de servicios de información deberá verificar
regularmente que el personal que lleva a cabo tareas específicas, esté calificado
tomando como base una educación, entrenamiento y/o experiencia apropiados,
según se requiera.
Condición –
§ La evaluación de desempeño del personal, realizada la Unidad de Talento
Humano, es de carácter general y de orden administrativo.
§ No existe evaluación por parte del Director de la UTIC en cuanto a tareas
específicas y calificación del personal de la UTIC. (AUDI-ESPE-2007-ENT-005)
Causa-
No existen procedimientos referidos a la evaluación técnica o seguimiento de
actividades específicas en la ESPE, en general.
Efecto –
Desconocimiento del nivel de eficiencia, capacidad y experiencia del personal,
que redunde en el cumplimiento de los objetivos institucionales.
• El Director de la UDI, definirá durante el primer trimestre del año en curso, las
políticas necesarias para que las diferentes unidades evalúen la capacidad
técnica del personal que las componen y elaboren requerimientos de
capacitación para el personal a su cargo.
§ El Director de Talento Humano, elaborará y ejecutará el procedimiento para
evaluar la capacidad técnica a más de la de desempeño.

161
§ El Director de la UTIC, realizará evaluaciones periódicas al personal en cuanto a
sus funciones roles y responsabilidades, que sean valoradas para
reconocimiento o correctivos específicos, con el objetivo de mantener Personal
calificado.
Punto de vista –
PO7.3 Roles y Responsabilidades
Observación PO48 - Los roles y responsabilidades que cumple el personal de la
UTIC, no concuerda con los definidos.
Criterio –
La Gerencia debe definir claramente los roles y responsabilidades del personal,
incluyendo los requisitos para adherirse a las políticas y procedimientos
establecidos por la gerencia, el código de ética y las prácticas profesionales. Los
términos y condiciones de los cargos deben estrechar la responsabilidad de los
empleados por la seguridad de la información y el control interno.
Condición –
• El personal de la UTIC ejecuta funciones y actividades descritas por los
procesos que maneja, sin embargo, estas no son realizadas a cabalidad.
(Evidencia:AUDI-ESPE-2007-ENT 004, SGC)

162
• Del estudio documental realizado al orgánico funcional y manual de descripción
de cargos, se puede establecer que no existe concordancia entre el cargo
descrito y las funciones que el personal desempeña según los procesos
establecidos, porque estos se cumplen de acuerdo a la carga de trabajo.
Causa-
Falta de responsabilidades de supervisión por parte de la Dirección de la UTIC.
Efecto –
Riesgo de cumplimiento no adecuado de los procesos, que atenten contra la
seguridad de información y control interno.
El Director de Talento Humano, durante el primer trimestre del año en curso,
definirá claramente los roles y responsabilidades del personal, incluyendo los
requisitos para adherirse a las políticas y procedimientos establecidos por la
gerencia, el código de ética y las prácticas profesionales. Los términos y
condiciones de los cargos deben estrechar la responsabilidad de los empleados
por la seguridad de la información y el control interno.
Punto de vista –

163
PO7.4 Entrenamiento de Personal
Observación PO49 - No existen programas de educación y entrenamiento
dirigidos a incrementar habilidad técnica y administrativa del personal.
Criterio –
La Gerencia deberá asegurar que los empleados reciban orientación al ser
contratados, así como entrenamiento y capacitación constantes con la finalidad
de conservar los conocimientos, habilidades, destrezas y conciencia de seguridad
al nivel requerido, para la ejecución efectiva de sus tareas.
Condición –
§ La UTH, establece en sus procesos el de “Capacitación y Entrenamiento de
Personal” (Evidencia: TH 5.1), sin embargo en este no se describe ningún
Programa de educación y entrenamiento para el personal.
§ La capacitación del Personal se establece mediante requerimientos presentados
por cada Unidad; pero no existe análisis ni planificación que permita cumplir con
los objetivos del Plan estratégico institucional. (Evidencia: TH5.1)
Causa-
Falta de políticas referidas al tema.
Efecto –

164
El Director de Talento Humano, implantará desde el primer semestre del año en
curso, un programa de capacitación y entrenamiento de personal de TI, en base
de los requerimientos institucionales (Plan estratégico Institucional y Plan
estratégico Informático), considerando el plan de carrera, el análisis y clasificación
de cargos.
Punto de vista –
PO7.5 Entrenamiento Cruzado o Respaldo de personal
Observación PO50 - No existen programas de educación y entrenamiento
cruzado o respaldo de personal.
Criterio –
La Gerencia deberá proporcionar un suficiente entrenamiento cruzado o contar
con personal de respaldo para personal clave identificado, con la finalidad de
solucionar posibles ausencias.
La Gerencia debe establecer planes de sucesión para todas las funciones y
posiciones claves.
Condición –
§ Dentro de los procesos establecidos por la UTH, no existe alguno referido a
entrenamiento cruzado o respaldo de personal (Evidencia: TH 5.1).

165
Causa-
Falta de políticas referidas al tema.
Efecto –
La institución corre el riesgo de depender de personas claves, para la continuidad
en sus operaciones.
El Director de Talento Humano, establecerá el procedimiento para proporcionar
entrenamiento cruzado y contar con personal de respaldo para personal clave
identificado y lo pondrá en ejecución desde el primer trimestre del año en curso.
El Director de la UTIC, establecerá planes y procedimiento de sucesión de
personal clave, desde el primer trimestre del año en curso.
Punto de vista –
PO7.6 Procedimientos de Acreditación de Personal
Observación PO51 - No existen procedimientos para la acreditación de
Personal.
Criterio –

166
La Gerencia de TI deberá asegurar que su personal se sujete a una revisión o
acreditación de seguridad antes de ser contratado, transferido o promovido,
dependiendo de lo delicado o sensible del puesto. Un empleado que no haya
pasado por este procedimiento de revisión o acreditación al ser contratado por
primera vez, no deberá ser colocado en un puesto delicado hasta que éste haya
obtenido la acreditación de seguridad.
Condición –
Dentro del proceso de Reclutamiento de personal, no existe un procedimiento de
revisión o acreditación de seguridad antes de ser contratado, ni políticas acerca
de la ubicación inicial del personal contratado (Evidencia: TH3.2)
Causa-
Falta de normatividad referida al tema.
Efecto –
El Director de Talento Humano, desde el primer trimestre del año en curso
implantará un procedimiento para asegurar que el personal de TI, se sujete a una
revisión o acreditación de seguridad antes de ser contratado, transferido o
promovido, dependiendo de lo delicado o sensible del puesto. Un empleado que
no haya pasado por este procedimiento de revisión o acreditación al ser

167
contratado por primera vez, no deberá ser colocado en un puesto delicado hasta
que éste haya obtenido la acreditación de seguridad.
Punto de vista –
PO7.7 Evaluación de Desempeño de los Empleados
Observación PO52 - La evaluación de desempeño, no es de trascendencia ni
apoya a la ESPE en sus objetivos.
Criterio –
La Gerencia deberá implementar un proceso de evaluación de desempeño de los
empleados, reforzadas con un efectivo sistema de recompensas que sea
diseñado para ayudar a los empleados a entender la conexión entre su
desempeño y el éxito de la organización. La evaluación debe ser realizada según
los estándares establecidos y las responsabilidades específicas del puesto. Los
empleados deberán recibir asesoría sobre su desempeño o su conducta cuando
lo requiera.
Condición –
§ Dentro del macroproceso de Gestión del Talento Humano, se encuentra el
proceso para evaluación del desempeño de Personal, pero no existen registros

168
de estas evaluaciones, ni análisis en base a ellas para incentivos, ascensión de
cargos, etc. (Evidencia: AUDI-ESPE-2007- ENT-014, TH4.1)
§ Las evaluaciones realizadas, no reflejan la conexión entre su desempeño y el
éxito de la organización.
Causa-
Efecto –
Riesgo de mantener personal desmotivado, poco eficaz y eficiente en el
desenvolvimiento de sus funciones.
El Director de Talento Humano, desde el primer semestre del año en curso,
implementará un proceso de evaluación de desempeño de los empleados,
reforzadas con un efectivo sistema de recompensas que sea diseñado para
ayudar a los empleados a entender la conexión entre su desempeño y el éxito de
la organización. La evaluación será realizada según los estándares establecidos y
las responsabilidades específicas del puesto. Los empleados recibirán asesoría
sobre su desempeño o su conducta cuando se requiera.
Punto de vista –

169
PO7.8 Cambio y Terminación de Trabajo
Observación PO53 - No existe proceso definido para el cambio y terminación de
trabajo.
Criterio –
La Gerencia debe asegurar que se tomen acciones apropiadas y a tiempo en
cuanto a cambios y terminación de trabajo para que los controles internos y de
seguridad no se vean perjudicados por estos eventos.
Condición –
Dentro del macroproceso de Gestión del Talento Humano, no existen procesos
para el cambio y terminación de trabajo. (Evidencia: TH1.1)
Causa-
Efecto –
Riesgo de acceso indebido a los sistemas de información, fraude, sabotaje y otras
acciones, que atenten contra la seguridad de información.
El Director de Talento humano, desde el primer trimestre del año en curso,
implantará un procedimiento para asegurar que se tomen acciones apropiadas y a
tiempo en cuanto a cambios y terminación de trabajo para que los controles
internos y de seguridad no se vean perjudicados por estos eventos.

170
Punto de vista –
PO8. ASEGURAMIENTO DE CUMPLIMIENTO DE REQUERIMIENTOS
EXTERNO
PO8.1 Revisión de Requerimientos Externos
Observación PO54- No existe revisión de requerimientos externos para el
aseguramiento del cumplimiento de los mismos.
Criterio –
La organización deberá establecer y mantener procedimientos para la revisión de
requerimientos externos y para la coordinación de estas actividades. La
investigación continua deberá determinar los requerimientos externos aplicables
en la organización.
Condición –
§ La UTIC no posee un procedimiento para establecer y mantener los
requerimientos externos y para la coordinación de estas actividades; no existen
definidos controles internos para el cumplimiento de leyes y reglamentos
referidos a TI del Ecuador.

171
§ No existe evidencia de análisis de requerimientos legales, gubernamentales o
cualquier otro requerimiento externo relacionado con las prácticas y controles de
tecnología de información. (Evidencia: AUDI-ESPE-2007- ENT-014)
Causa-
§ Falta de políticas que contenga la definición de Requerimientos externos y su
prioridad para la UTIC y la institución.
§ Falta de aplicación del Control Interno en la UTIC.
§ Falta de capacitación sobre el tema al personal de la UTIC.
Efecto –
Riesgo de infrinjir eventualmente leyes y reglamentos tanto internos como
externos.
El Director de la UDI, desde el primer trimestre del año en curso, establecerá un
procedimiento para la revisión de requerimientos externos y para la coordinación
de estas actividades.
Punto de vista –

172
PO8.2 Prácticas y Procedimientos para el Cumplimiento de Requerimientos
Externos
Observación PO55 - No existen prácticas ni procedimientos para el
cumplimiento de requerimientos externos.
Criterio –
Las prácticas organizacionales deberán asegurar que se lleven a cabo
oportunamente las acciones correctivas apropiadas para garantizar el
cumplimiento de los requerimientos externos. Además, deberán establecerse y
mantenerse procedimientos adecuados que aseguren el cumplimiento continuo. A
este respecto la Gerencia deberá solicitar apoyo legal en caso necesario.
Condición –
En la UTIC, no existen prácticas ni normas establecidas para el cumplimiento de
requerimientos externos. (Evidencia: AUDI-ESPE-2007-ENT-005 y AUDI-ESPE-
2007-ENT-014)
Causa-
§ Falta de políticas que contenga la definición de Requerimientos externos y su
prioridad para la UTIC y la institución.
§ Falta de aplicación del Control Interno en la UTIC.
§ Falta de capacitación sobre el tema al personal de la UTIC.
Efecto –

173
Riesgo de infringir eventualmente leyes y reglamentos tanto internos como
externos.
El Director de la UDI, desde el primer trimestre del año en curso, implantará
procedimientos y prácticas organizacionales para asegurar que se lleven a cabo
oportunamente acciones correctivas que garanticen el cumplimiento de los
requerimientos externos en forma continua, solicitará apoyo legal en caso
necesario.
Punto de vista –
PO8.3 Cumplimiento de Seguridad y Ergonomía
Observación PO56 - No existe evidencia de estándares de seguridad y
ergonomía del ambiente de trabajo para usuarios y personal de TI.
Criterio –
La Gerencia deberá asegurar el cumplimiento de los estándares ergonómicos y
de seguridad en el ambiente de trabajo de los usuarios y el personal de TI.
Condición –

174
§ La unidad encargada de la seguridad de la ESPE no conoce del tema
(Evidencia: Entrevista AUDI-ESOE-2007-ENT-013).
§ Existe un manual de seguridad física de la ESPE, pero tampoco existe evidencia
de su aplicación.
Causa-
Efecto –
Riesgos de infracción de normas de seguridad y ergonomía en el trabajo.
El Director de la UDI, desde el primer trimestre del año en curso, establecerá
políticas y normas que permitan asegurar el cumplimiento de los estándares
ergonómicos y de seguridad en el ambiente de trabajo de los usuarios y el
personal de TI.
Punto de vista –
PO8.4 Privacidad, propiedad intelectual y Flujo de Datos

175
Observación PO57: No existe evidencia de controles establecidos para la
ejecución y cumplimiento de la ley de propiedad intelectual, ni políticas, controles
o reglamentos para la regulación de la privacidad y flujo de datos.
Criterio –
La Gerencia deberá asegurar el cumplimiento de las regulaciones sobre
privacidad, propiedad intelectual, flujo de datos a entes externos y regulaciones
aplicables a las prácticas de tecnología de información de la organización.
Condición –
La ESPE no posee controles internos definidos para asegurar el cumplimiento de
regulaciones sobre privacidad, propiedad intelectual, flujo de datos a entes
externos y criptografía aplicable a las prácticas de tecnología de la información.
(Evidencia: AUDI-ESPE-2007- ENT-014)
Causa-
§ Falta de Definición de Políticas de control interno en al UTIC.
§ Falta de capacitación acerca del tema en el personal de la UTIC.
§ Falta de responsabilidad de seguimiento.
Efecto –
Riesgo de infringir eventualmente leyes y reglamentos relacionados con la
privacidad, propiedad intelectual y flujo de datos que conlleven a sanciones y
demandas a la Institución.

176
El Director de la UDI, durante el primer trimestre del año en curso, establecerá las
políticas y normas necesarias para asegurar el cumplimiento de las regulaciones
sobre privacidad, propiedad intelectual, flujo de datos a entes externos y
regulaciones de criptografía aplicables a las prácticas de tecnología de
información de la organización.
Punto de vista –
PO9. ANÁLISIS DE RIESGOS
PO9.1 Evaluación de Riesgos del Negocio
Observación PO58: No existe evaluación sistemática de riesgos.
Criterio –
La Gerencia deberá establecer un marco de referencia de evaluación sistemática
de riesgos del negocio, al que deberá incorporar una evaluación regular de los
riesgos de información relevantes para el logro de los objetivos del negocio,
formando una base para determinar la manera en la que los riesgos deben ser
manejados a un nivel aceptable.
Condición –

177
§ No existe un proceso para la Evaluación e Identificación de Riesgos del negocio,
ni un marco de referencia relacionado. (Evidencia: AUDI-ESPE-2007-ENT-005)
§ Existe un Plan de Contingencias, que determina medidas para evitar los riesgos
listados en el documento, sin embargo no existen políticas de manejo de
riesgos, formalmente definidas; la información para la identificación de riesgos
provino de los coordinadores de cada área de la UTIC, mas no se realizó un
estudio sistemático fundamentado en resultado de auditorías, inspecciones o
incidentes. (Evidencia: Plan de Contingencia)
Causa-
Efecto –
- La falta de evaluación e identificación de riesgos, incide en la falta de políticas
para el control de los mismos.
- Un Plan de contingencias elaborado con riesgos improbables no tiene validez y
desvía peligrosamente la atención de los objetivos del plan y la continuidad del
negocio.
El Director de la UDI, durante el primer semestre del año en curso, establecerá un
procedimiento de evaluación sistemática de riesgos del negocio, que incorpore
una evaluación regular de los riesgos de información relevantes para el logro de
los objetivos del negocio, formando una base para determinar la manera en la que
los riesgos deben ser manejados a un nivel aceptable.

178
Punto de vista –
PO9.2 Enfoque de Evaluación de Riesgos
Observación PO59: No existe evidencia del establecimiento de un enfoque
general para la evaluación de riesgos (alcance, límites, metodología,
responsabilidades y habilidades).
Criterio –
La Gerencia deberá establecer un enfoque general para la evaluación de riesgos
en TI, que defina el alcance y los límites, la metodología a ser adoptada para las
evaluaciones de riesgos, las responsabilidades y las habilidades requeridas.
Condición –
§ El plan de contingencia contiene un análisis de riesgos enfocado de forma
general a la ESPE, pero no se contempla los activos de TI. (Evidencia: Plan de
Contingencias, entrevista No. AUDI-ESPE-2007-ENT-015 )
§ No se ha designado al responsable de la seguridad, quien deberá identificar
soluciones para la mitigación de riesgos y vulnerabilidades. (Evidencia: GT1.4,
entrevista No. AUDI-ESPE-2007-ENT-015)
Causa-
Falta de normatividad y capacitación en el tema.

179
Efecto –
Escasa capacidad de reacción ante eventos imprevistos que inciden en la
continuidad del negocio.
§ El Director de la UDI, desde el primer trimestre del año en curso, establecerá
una política general para la evaluación de riesgos que defina el alcance y los
límites, la metodología a ser adoptada para las evaluaciones de riesgos, las
responsabilidades y las habilidades requeridas (ANÁLISIS CUANTITATIVO DE
RIESGOS (ACR)).
§ El Director de la UTIC en el primer trimestre del año en curso designará al
responsable de seguridad de la información.
Punto de vista –
PO9.3 Identificación de Riesgos
Observación PO60: No existe Identificación de riesgos específicos para TI.
Criterio –

180
La evaluación de riesgos deberá enfocarse al examen de los elementos
esenciales de riesgo y las relaciones causa/efecto entre ellos. Los elementos
esenciales de riesgo incluyen activos tangibles e intangibles, valor de los activos,
amenazas, vulnerabilidades, protecciones, consecuencias y probabilidad de
amenaza. El proceso de identificación de riesgos debe incluir una clasificación
cualitativa y, donde sea apropiado, clasificación cuantitativa de riesgos y debe
obtener insumos de las tormentas de ideas de la Gerencia, de planeación
estratégica, auditorías anteriores y otros análisis. El análisis de riesgos debe
considerar el negocio, regulaciones, aspectos legales, tecnología, comercio entre
socios y riesgos del recurso humano
Condición –
§ La información para la identificación de riesgos provino de los coordinadores de
cada área constitutiva de la UTIC, mas no se realizan un estudio sistemático o
un fundamento en resultado de auditorías, inspecciones e incidentes.
(Evidencia: AUDI-ESPE-2007- ENT-005)
§ Los riesgos más relevantes para la UTIC son: Terremoto, Erupción, Inundación,
Robo, Errores, Tormentas Eléctricas, Infección de Virus. No se analiza riesgos
como el Avance Tecnológico. (Evidencia: Plan de Contingencia)
§ El Plan de Contingencia no tiene ninguna incidencia en el Plan RI, ni en el Plan
de Adquisiciones Tecnológicas. (Evidencia: AUDI-ESPE-2007- ENT-004)
Causa-
§ Falta de un Plan estratégico informático que contenga la administración de
riesgos como estrategia para la función de TI.
§ No se ha identificado la información crítica o equipos críticos de la ESPE.

181
§ Falta de capacitación en referencia a este tema.
Efecto –
Escasa capacidad de reacción ante eventos imprevistos que inciden en la
continuidad del negocio.
El Director de la UTIC, desde el primer trimestre del año en curso, implantará un
procedimiento para la evaluación de riesgos, que contemplará un examen de los
elementos esenciales de riesgo y las relaciones causa/efecto entre ellos, tomará
como referencia las librerías ITIL.
Punto de vista –
PO9.4 Medición de Riesgos
Observación PO61: La medición de riesgos establecida no demuestra su
incidencia en TI.
Criterio –
El enfoque de la evaluación de riesgos deberá asegurar que la información del
análisis de la identificación de riesgos genere como resultado una medida

182
cuantitativa y/o cualitativa del riesgo al cual está expuesta el área examinada.
Asimismo, deberá evaluarse la capacidad de aceptación de riesgos de la
organización.
Condición –
El plan de contingencias vigente contiene la identificación de riesgos, pero no
existe análisis ni medición cuantitativa o cualitativa de riesgos de TI.
Causa-
§ Falta de capacitación en referencia a este tema.
Efecto –
Deficiencia en la elaboración del plan de contingencias, riesgo en la continuidad
del negocio.
procedimiento para la medición y actualización de riesgos y designará a un
responsable para tal efecto.
Punto de vista –

183
PO9.5 Plan de Acción contra Riesgos
Observación PO62: No existe Plan de Acción contra Riesgos.
Criterio –
El enfoque de evaluación de riesgos deberá proporcionar la definición de un plan
de acción contra riesgos para asegurar que el costo– efectividad de los controles
y las medidas de seguridad que mitiguen los riesgos en forma continua. El plan de
acción contra los riesgos debe identificar la estrategia de riesgos en términos de
evitar, mitigar o aceptar el riesgo.
Condición –
Existe un Plan de Contingencias, pero no existe en forma específica un Plan de
acción contra riesgos, que asegure la efectividad de los controles y las medidas
de seguridad que mitiguen los riesgos en forma continua. (Evidencia: Plan de
Contingencia)
Causa-
Falta de capacitación en referencia a este tema.
Efecto –
Deficiencia en la elaboración del plan de contingencias y riesgo en mantener la
continuidad en el negocio.

184
procedimiento para asegurar la actualización del plan de riesgos o contingencias y
designará a un responsable para tal efecto.
Punto de vista –
PO10. DEFINIR LA ADMINISTRACIÓN DE LOS PROYECTOS
PO10.1 Marco de Referencia para la Administración de Proyectos
Observación PO63: Existe un formato, mas no un marco de referencia
formalmente definido para la administración de proyectos.
Criterio –
Establecer un marco de referencia general para la administración de proyectos.
Definición de los alcances, límites y metodología de administración de cada uno
de los proyectos a ser emprendido. Asignación de responsabilidades, la
determinación de tareas, la elaboración de presupuestos de tiempo y recursos, los
avances, los puntos de revisión y las aprobaciones.
Las tareas de aseguramiento deberán ser definidas durante la fase de planeación
del marco de referencia de administración de proyectos. Las tareas de

185
aseguramiento deberán apoyar la acreditación de sistemas nuevos o modificados
y garantizar que los controles internos y los dispositivos de seguridad cumplan
con los requerimientos necesarios.
Condición –
§ Existe un formato para la presentación de proyectos, emitido por la UDI, mas no
existe un procedimiento detallado y formalmente establecido que defina
alcances, límites y metodología de administración de cada uno de los proyectos
a ser emprendido. (Evidencia: GT1-6)
§ De acuerdo al proyecto "ACTUALIZAR Y AMPLIAR LA INFRAESTRUCTURA
DE EQUIPOS INFORMÁTICOS DEL ÁREA ACADÉMICA PARA LA ESPE
SANGOLQUÍ Y SEDES", se puede notar que en el punto referente a
metodología se realiza únicamente, un desglose de las actividades a cubrir para
la consecución del proyecto pero no se explica la metodología a emplearse.
§ La mayor parte de los proyectos se refieren a adquisiciones, en donde interviene
personal de la UTIC, en vez de la Unidad de Logística, distorsionándose la
función de la UTIC.
Causa –
§ Desconocimiento de estándares de metodologías para seguimiento de
proyectos.
§ No existe una definición del papel que desempeñará la UTIC al fungir como
unidad de apoyo en algunos proyectos.
Efecto –

186
Desorden y falta de control en la planificación, ejecución y evaluación de
proyectos, que redunda en riesgo potencial de falla en la eficacia de las acciones
para el cumplimiento de los objetivos institucionales.
Recomendación PO63-
El Director de la UDI, desde el primer trimestre del año en curso, establecerá e
implantará un marco de referencia general para la administración de proyectos, en
el que se incluirá la definición del alcance, límites y metodología de administración
de cada uno de los proyectos a ser emprendido, asignación de responsabilidades,
determinación de tareas, elaboración de presupuestos de tiempo y recursos,
beneficios que contraería la ejecución del proyecto, determinación de avances,
puntos de revisión y aprobaciones. Las tareas de aseguramiento deberán ser
definidas durante la fase de planeación del marco de referencia de administración
de proyectos, estas tareas deberán apoyar la acreditación de sistemas nuevos o
modificados y garantizar que los controles internos y los dispositivos de seguridad
cumplan con los requerimientos necesarios. Realizará la capacitación al personal
sobre este marco de referencia y evaluará su difusión y aplicación.
Punto de vista –

187
PO10.2 Participación del Departamento Usuario en la Iniciación de
Proyectos
Observación PO64: La participación del usuario no se encuentra normada.
Criterio –
El marco de referencia de la administración de proyectos de la organización
deberá fomentar la participación del departamento usuario afectado en la
definición y autorización de cualquier proyecto de desarrollo, implementación o
modificación.
Condición –
§ La participación del usuario, se realiza únicamente para presentar sus
requerimientos para el proyecto y a la finalización del mismo, en caso de que su
requerimiento haya sido atendido (Evidencia: proyecto "Actualizar y ampliar la
infraestructura de equipos informáticos del área académica para la ESPE
Sangolquí y Sedes").
§ No existe monitoreo postimplementación por parte del usuario, en concordancia
en el dominio de Adquisición e Implantación (AI7).
§ Las unidades académicas, por contar con presupuesto para un proyecto,
realizan adquisiciones por su cuenta (software, hardware), sin participación de la
UTIC o contando con la UTIC únicamente para la elaboración de las bases
técnicas (Evidencia: entrevistas AUDI-ESPE-2007ENT-003).
Causa –
No existe normatividad en cuanto a participación del usuario se refiere.
Efecto –

188
§ Se pierde el control del proyecto y se incrementa el riesgo de ineficacia e
ineficiencia del proyecto.
§ Pérdida de credibilidad en las funciones de la UTIC.
§ Arbitrariedad en la selección de alternativas de cumplimiento de necesidades.
políticas que permitan fomentar la participación del departamento usuario
afectado en la definición y autorización de cualquier proyecto de desarrollo,
implementación o modificación.
Punto de vista –
PO10.3 Miembros y Responsabilidades del Equipo del Proyecto
Observación PO65: No existen políticas formalmente aprobadas para la
designación de miembros del equipo de proyecto, ni responsabilidades
específicas de los participantes en los proyectos.
Criterio –

189
El marco de referencia de administración de proyectos de la organización deberá
especificar las bases para asignar a los miembros del personal al proyecto y
definir las responsabilidades y autoridades de los miembros del equipo del
proyecto.
Condición –
§ La asignación de personal a los proyectos según el reglamento interno de la
ESPE, se realiza dependiendo del perfil del proyecto, no necesariamente será
una persona miembro de la UTIC.
§ Al asignar un proyecto a la UTIC, éste a su vez es asignado a uno o varios
Grupos de gestión dependiendo de la índole del proyecto, a la persona
responsable se le designa considerando su carga de trabajo. (Evidencia: AUDI-
ESPE-2007ENT-004)
§ Se ha encargado de adquisiciones de software a la Ing. M. Cristina Lemos
(GT4); y de adquisiciones de hardware se encarga directamente GT1 pero con
el apoyo de la revisión de bases técnicas en GT2, a pesar de que este proceso
es responsable la Dirección de Logística(Evidencia: memorando 2007-0216-
SGC, RF.1.1).
§ En algunas ocasiones el responsable del proyecto es enviado en prestación de
servicios y se realiza una reasignación del mismo.
Causa –
§ No existe una base técnica para asignar la persona responsable ni al equipo.
§ Para enviar a personal en prestación de servicios, no se analiza previamente si
dicha persona está ya asignada a un proyecto ya aprobado (referencia: AUDI-
ESPE-2007ENT-001, 002, 003, 004).

190
§ Existe una mala definición del proceso de adquisiciones ya que es parte tanto
del proceso de compras de logística, como del de la gestión tecnológica, por lo
que no se sabe realmente quien es el responsable.
Efecto –
§ Si el personal asignado para los proyectos no tiene el conocimiento técnico
suficiente, existe riesgo en el cumplimiento eficaz y eficiente del proyecto.
§ La falta de una designación formal del responsable del proyecto, puede producir
especulación al respecto dentro de la unidad y causar malestares entre las
personas que posiblemente estarían a cargo de los mismos.
§ La asignación de proyectos de acuerdo a la carga de trabajo del personal no es
totalmente efectiva, ni se la puede conocer a ciencia cierta, ya que no existen
análisis reales de cargas de trabajo del personal de la UTIC.
políticas y normativa para asignar a los miembros del personal de los proyectos y
definir las responsabilidades y autoridades de los miembros del equipo del
proyecto de manera formal.
Punto de vista –

191
PO10.4 Definición del Proyecto
Observación PO66: No existe definición clara de proyectos en cuanto al alcance
y límites.
Criterio –
generar la creación de un estatuto claro y por escrito que defina la naturaleza y el
alcance de cada proyecto de implementación antes de que los trabajos del mismo
empiecen.
Condición –
§ A pesar de que existe un formato en el cual se presentan los proyectos para
someterlos a aprobación, no se encuentra una definición clara de los alcances
del mismo (Evidencia: GT1-6).
§ No existe una metodología formalmente definida para el desarrollo de proyectos.
Causa –
No existen procesos definidos ni reglamentación completa al respecto.
Efecto –
§ Al no saber exactamente lo que se pretende conocer por medio de cada uno de
los puntos expuestos en el formato, se pueden presentar datos innecesarios,
erróneos, poco importantes e incluso que puedan no servir como argumentos
para la presentación y validación de los proyectos.
§ Al no definir los alcances del proyecto correctamente, se puede
sobredimensionar lo que realmente se desea alcanzar con la ejecución del

192
mismo y traería consigo información equivocada e incluso podría no alcanzarse
lo propuesto en el proyecto.
Desde el primer trimestre de año en curso, el Director de la UDI, implementará y
evaluará el cumplimiento de políticas y normativa para definir la naturaleza y el
alcance de cada proyecto de implementación antes de que los trabajos del mismo
empiecen, se analizará el formato de presentación de los proyectos, de manera
que se defina en cada uno de los puntos la información que se debe enfocar en
ellos, y definir en donde se debe puntualizar el alcance que tendrá el proyecto.
Punto de vista –
PO10.5 Aprobación del Proyecto
Observación PO67: No existen análisis reales de factibilidad de los proyectos, ni
evidencia de que la alta gerencia revise cada uno de los puntos de la
presentación de los proyectos incluyendo su factibilidad.
Criterio –
asegurar que la alta gerencia de la organización revise los reportes de los

193
estudios de factibilidad relevantes para cada proyecto propuesto, como una base
para fundamentar la decisión de proceder con el proyecto.
Condición –
§ No existe evidencia de que se emplea un procedimiento para revisar todos y
cada uno de los elementos de un proyecto para su aprobación, a pesar de que
se utiliza un formato para su presentación.
§ No existe análisis de factibilidad ni de riesgos en la presentación y aprobación
de proyectos (evidencia: proyectos: "Actualizar y ampliar la infraestructura de
equipos informáticos del área académica para la ESPE Sangolquí y Sedes",
“ESPE digital”).
§ La aprobación o desaprobación de los proyectos, se la realiza en una reunión de
staff; pero no se conoce bajo que procedimientos de priorización se los aprueba.
Causa –
§ Desconocimiento del personal sobre análisis de factibilidad.
§ No existe procesos definidos ni reglamentación completa.
Efecto –
§ Existe un riesgo potencial de fracaso o retardo en la ejecución del proyecto.
§ Riesgo potencial de realizar una priorización no adecuada, que redunde en
el incumplimiento de los objetivos institucionales y se empleen recursos en
forma ineficiente.

194
El Director de la UDI, desde el primer trimestre del año en curso, establecerá y
pondrá en ejecución políticas y normativas que permita asegurar que la alta
gerencia de la organización, revise los reportes de los estudios de factibilidad
relevantes para cada proyecto propuesto, como una base para fundamentar la
decisión de aprobarlo.
Punto de vista –
PO10.6 Aprobación de las Fases del Proyecto.
Observación PO68: No existe evidencia de políticas o normatividad referente al
diseño de proyecto en fases ni aprobación de las fases del proyecto.
Criterio –
disponer que los Gerentes designados en representación de las funciones del
usuario y de los servicios de TI aprueben el trabajo realizado en cada fase del
ciclo antes de iniciar los trabajos de la siguiente fase.
Condición –
§ En el documento de planificación de los proyectos, no se define hitos de revisión
y aprobación formal del avance del proyecto por fases; el formato que se utiliza
no prevé esta actividad.

195
§ La participación de usuarios como personal que podría aprobar o no la
finalización una fase de un proyecto no se ha establecido formalmente..
§ Existe una aprobación empírica y no formal en proyecto de desarrollo de
aplicaciones, esta únicamente se la hace verbalmente con el usuario que haya
hecho el requerimiento, no existen actas de revisión de todos los sistemas.
§ En el proyecto "Actualizar y ampliar la infraestructura de equipos informáticos
del área académica para la ESPE Sangolquí y Sedes" existe una definición de
fases de acuerdo al equipamiento a adquirir en cada una de las fases, más no
se hace constar puntos de revisión.
Causa –
Falta de políticas y normatividad al respecto
Efecto –
§ Dificulta el seguimiento de los proyectos.
§ Se propicia reclamos no fundamentados al no contar con documentos formales
de aceptación de las fases del proyecto y no existiría un aval de que se
satisfacen las necesidades del usuario.
implantará políticas y normas para definir fases dentro del proceso de
planificación, ejecución y evaluación de proyectos y dispondrá que los
representantes designados como usuarios conjuntamente con los representantes
de los servicios de TI aprueben el trabajo realizado en cada fase del ciclo antes

196
de iniciar los trabajos de la siguiente fase; esta aprobación será formal y constará
en actas legalmente suscritas por los representantes.
Punto de vista –
PO10.7 Plan Maestro del Proyecto
Observación PO69: No existe evidencia de plan maestro de proyectos.
Criterio –
Creación de plan maestro aprobado para cada uno de los proyectos en el cual se
monitoreen los proyectos durante toda su vida que incluya tiempo y costos.
Existencia de plan de proyecto con objetivos, recursos, responsables e
información que permita medir los avances del proyecto.
Condición –
§ No existe monitoreo de los proyectos.
§ No existen definidos puntos de revisión en los proyectos.(Evidencia: PO10.6)
§ La persona a la cual se le asigne la responsabilidad del proyecto lo lleva de
acuerdo a su criterio y las revisiones del estado de un proyecto únicamente se
hace el momento en el que algún superior solicita saber el estado o el avance
del mismo (Evidencia: AUDI-ESPE-2007ENT-003).

197
§ En el formato en el cual se presentan los proyectos existe una definición de un
cronograma para la ejecución de los proyectos y en caso de no cumplirse con
dichos tiempos, se presenta un informe indicando la razón del retraso
suscitado.
§ Dentro de los procesos del SGC (referencia: 2007-0216-SGC GT.1.1), se
establece que el encargado de realizar el seguimiento de los proyectos es GT1,
pero se desconoce como realizan este seguimiento, ya que las mismas
unidades a las que están asignados los proyectos no siempre realizan el
seguimiento y este debería ser reportado a GT1 para su consolidación.
Causa –
§ En el formato de los proyectos no existe una definición de puntos de revisión.
§ No existe un seguimiento de proyectos formalizado.
Efecto –
§ No se puede conocer con certeza el avance de los proyectos o el momento en el
que se han retrasados.
§ Falta de coordinación entre el seguimiento que hacen cada una de las unidades
con las que hace GT1.
pondrá en ejecución políticas y normativas para monitorear los proyectos
utilizando un plan maestro de seguimiento y evaluación; el plan de proyecto

198
contendrá objetivos, recursos, responsables e información que permita medir los
avances del proyecto.
Punto de vista –
PO10.8 Plan de Aseguramiento de la Calidad del Sistema
Observación PO70: No existe un plan de aseguramiento de calidad de sistemas
de información.
Criterio –
La Gerencia deberá asegurar que la implementación de un sistema nuevo o la
modificación de otro incluya la preparación de un plan de calidad que sea
integrado posteriormente al plan maestro del proyecto y que sea formalmente
revisado y acordado por todas las partes interesadas.
Condición –
§ No existe un plan formalmente aprobado que asegure la calidad con la que se
modifiquen o implementen sistemas nuevos o ya existentes (Evidencia: AUDI-
ESPE-2007ENT-003).
§ No existe un estándar en el que se permita el acceso a los usuarios de los
distintos sistemas, porque cada usuario, a pesar de que tuviera el mismo perfil,
muchas veces tiene distintos requerimientos.

199
Causa –
Falta de políticas y normatividad al respecto
Efecto –
Seguimiento inadecuado de control de cambios y fallas en la calidad de los
sistemas.
implantará políticas y normas para asegurar que la implementación de un sistema
nuevo o la modificación de otro incluya la preparación de un plan de calidad que
sea integrado posteriormente al plan maestro del proyecto y que sea formalmente
revisado y acordado por todas las partes interesadas.
Punto de vista –
PO10.10 Administración Formal de Riesgos de Proyectos
Observación PO71: El análisis de riesgos en los proyectos es incompleto.
Criterio –

200
La Gerencia deberá implementar un programa de administración formal de
riesgos de proyectos, para eliminar o minimizar los riesgos asociados con
proyectos individuales (por ejemplo, identificación y control de áreas o eventos
que tengan la posibilidad de causar cambios no deseados).
Condición –
A pesar de que el formato de presentación contiene el punto referente al análisis
de riesgos, no existe una metodología o procedimiento formalmente establecido
para dicho análisis, por lo que esta actividad se realiza a buen criterio de quien
formula el proyecto; en muchos de los casos no existe (Evidencia: AUDI-ESPE-
2007ENT-004).
Causa –
Falta de políticas, normatividad y capacitación al respecto.
Efecto –
Retraso, suspensión temporal o definitiva en la ejecución de proyectos.
El Director de la UDI, desde el primer trimestre del año en curso, establecerá un
programa de administración formal de riesgos de proyectos, para eliminar o
minimizar los riesgos asociados con cada proyecto individual.
Punto de vista –

201
PO10.11 Plan de Prueba
Observación PO72: No existe evidencia de un plan de pruebas formal para el
desarrollo o modificación de las aplicaciones.
Criterio –
requerir la creación de un plan de pruebas para cada proyecto de desarrollo,
implementación y modificación.
Condición –
§ Antes de la puesta en marcha del sistema, sea modificación o
implementación, se realizan pruebas en un servidor que se tiene para ese
propósito, pero el procedimiento no se encuentra formalizado. (Evidencia:
AUDI-ESPE-2007-ENT003).
§ En el caso de adquisiciones de hardware, se realiza es una verificación del
cumplimiento de las características técnicas solicitadas y que se encuentre
en funcionamiento adecuado. (Evidencia: AUDI-ESPE-2007-ENT004)
Causa –
No existe un marco de referencia para la administración de proyectos, que
debería contener el plan de pruebas.
Efecto –
Riesgo en la aceptación y puesta en marcha de los sistemas o proyectos.

202
El Director de la UDI, durante el primer trimestre del año en curso, establecerá e
implantará políticas y normatividad para requerir la creación de un plan de
pruebas en cada proyecto de desarrollo, implementación y modificación.
Punto de vista –
PO10.12 Plan de Entrenamiento
Observación PO73: No existe la planificación de entrenamiento en los proyectos
de desarrollo.
Criterio –
requerir la creación de un plan de entrenamiento para cada proyecto de
desarrollo, implementación y modificación.
Condición –
§ Se realiza capacitación al usuario pero no existe evidencia de un plan de
entrenamiento (Evidencia: AUDI-ESPE-2007ENT-003, GT4-6)
§ De acuerdo con la información entregada por el SGC (Evidencia: 2007-0216-
SGC, GT.4.5) en el proceso de implantación y administración de aplicativos
(Evidencia: 2007-0216-SGC, GT.5.1) se debe realizar la capacitación en caso

203
de que sea necesaria; quienes analizan si es necesaria dicha capacitación, es
el personal de GT4 o el Administrador de aplicativos. Como constancia de que
esta capacitación se lleva a cabo se entregan los certificados (referencia: GT4-
6) mas no la planificación de la capacitación.
Causa –
Falta de formalidad en la ejecución de los procesos.
Efecto –
No se asegura la calidad de la capacitación, incrementando el riesgo en la
operación de los sistemas.
implantará políticas y normatividad para requerir la creación de un plan de
entrenamiento para cada proyecto de desarrollo, implementación y modificación.
Punto de vista –
PO10.13 Plan de Revisión Post – Implementación

204
Observación PO74: No existe evidencia de planes de revisión post
implementación pese a que existe dentro de los procesos.
Criterio –
disponer que, como parte integral de las actividades del equipo del proyecto, se
desarrolle un plan de revisión post - implementación para cada sistema de
información nuevo o modificado, con la finalidad de determinar si el proyecto ha
generado los beneficios planeados.
Condición –
§ En cuando a proyecto de adquisición de hardware, existe únicamente un registro
de los equipos al momento de su llegada pero no hay un control posterior.
§ En concordancia con la información obtenida en el dominio de Adquisición e
Implantación(AI7), no existe una revisión post implementación
§ No existe un seguimiento de desempeño del equipamiento o aplicaciones
después de su implementación (evidencia: AUDI-ESPE-2007ENT-003).
Causa –
§ Desconocimiento del procedimiento referente a la Administración de Aplicativos
(Evidencia: 2007-0216-SGC, GT.5.1) en donde indica que el Administrador de
sistemas debe monitorear para conocer si el aplicativo funciona
adecuadamente.
§ Desconocimiento de la necesidad de la realización de revisiones después de la
implantación.
Efecto –

205
Se desconoce la evolución de la implementación o modificación y no pueden
prevenirse posibles fallas o pérdidas de datos que se estén presentando o se
puedan presentar en la aplicación, por tanto se desconocería si la aplicación está
alcanzando los objetivos bajo los cuales fue concebida.
El Director de la UTIC, en forma inmediata, dispondrá que, como parte integral de
las actividades del equipo del proyecto, se desarrolle y ejecute un plan de revisión
post - implementación para cada sistema de información nuevo o modificado, con
la finalidad de determinar si el proyecto ha generado los beneficios planeados.
Punto de vista –
PO11. ADMINISTRACIÓN DE LA CALIDAD
PO11.1 Plan General de Calidad
Observación PO75: No existe evidencia de de un plan general de calidad.
Criterio –

206
La alta gerencia deberá desarrollar y mantener regularmente un plan general de
calidad basado en los planes organizacionales y de tecnología de información a
largo plazo. El plan deberá promover la filosofía de mejora continua y contestar a
las preguntas básicas de qué, quién y cómo.
La Gerencia deberá establecer un enfoque estándar con respecto al
aseguramiento de calidad, que cubra tanto las actividades de aseguramiento de
calidad generales como las específicas de un proyecto. El enfoque deberá
determinar los tipos de actividades de aseguramiento de calidad (revisiones,
auditorías, inspecciones, etc.) que deben realizarse para alcanzar los objetivos del
plan general de calidad. Asimismo deberá requerir una revisión específica de
aseguramiento de calidad.
Condición –
§ No existe evidencia de un plan general y enfoques de calidad.
Causa –
§ De acuerdo al memo N°2007-0215-SGC, se nos indicó que para cualquier
información referente al sistema de Gestión de la calidad, nos dirigiéramos a
la Web (http://sgc.espe.edu.ec), pero no existe en la Web el plan general de
calidad al que se rigen.
§ No existe evidencia de un enfoque de Aseguramiento de la calidad debido a
que tampoco existe un plan general de calidad, en donde se especifique
dichos enfoques.
Efecto –

207
§ Al no tener este plan general, no se conoce enfocándose a que objetivos o
procedimientos de calidad se están realizando los controles o el
aseguramiento de la calidad.
§ Establecer un plan general de calidad, especificando los lineamientos
(enfoque) hacia los cuales e deben encaminar los procedimientos de
aseguramiento de la calidad de cada una de las unidades.
Punto de vista –
PO11. 2 Enfoque de Aseguramiento de Calidad
Observación PO76: No existe evidencia de la presencia de un plan general de
calidad.
Criterio –
La alta gerencia deberá desarrollar y mantener regularmente un plan general de
calidad basado en los planes organizacionales y de tecnología de información a
largo plazo. El plan deberá promover la filosofía de mejora continua y contestar a
las preguntas básicas de qué, quién y cómo.

208
La Gerencia deberá establecer un enfoque estándar con respecto al
aseguramiento de calidad, que cubra tanto las actividades de aseguramiento de
calidad generales como las específicas de un proyecto. El enfoque deberá
determinar el (los) tipo(s) de actividades de aseguramiento de calidad (tales como
revisiones, auditorías, inspecciones, etc.) que deben realizarse para alcanzar los
objetivos del plan general de calidad. Asimismo deberá requerir una revisión
específica de aseguramiento de calidad.
Condición –
§ No existe evidencia de un plan general y enfoques de calidad.
Causa –
§ De acuerdo al memo N°2007-0215-SGC, se nos indicó que para cualquier
información referente al sistema de Gestión de la calidad, nos dirigiéramos a
la Web (http://sgc.espe.edu.ec), pero no existe en la Web el plan general de
calidad al que se rigen.
§ No existe evidencia de un enfoque de Aseguramiento de la calidad debido a
que tampoco existe un plan general de calidad, en donde se especifique
dichos enfoques.
Efecto –
§ Al no tener este plan general, no se conoce enfocándose a que objetivos o
procedimientos de calidad se están realizando los controles o el
aseguramiento de la calidad

209
§ Establecer un plan general de calidad, especificando los lineamientos
(enfoque) hacia los cuales e deben encaminar los procedimientos de
aseguramiento de la calidad de cada una de las unidades.
Punto de vista –
PO11.3 Planeación del Aseguramiento de Calidad
Observación PO77: No existe plan de aseguramiento de la calidad, por lo tanto
tampoco un planeamiento del aseguramiento de la calidad.
Criterio –
La Gerencia deberá implementar un proceso de planeación de aseguramiento de
calidad para determinar el alcance y la duración de las actividades de
Condición –
§ No existe evidencia de un plan de Aseguramiento de la Calidad donde se
especifiquen alcance, duración y actividades de aseguramiento; se procedió a
revisar la página WEB http://sgc.espe.edu.ec, pero no se encontró el plan de
§ Existen planes de acción para las unidades, pero estos no contienen un
enfoque relacionado a las labores de la UTIC. (Evidencia: SGCDI009)

210
Causa –
Normatividad y procesos incompletos.
Efecto –
Riesgo en el funcionamiento adecuado de los sistemas y en la continuidad del
negocio.
El Director de la UDI, desde el primer trimestre del año en curso, desarrollará e
implantará un proceso de planeación de aseguramiento de calidad para
determinar el alcance y la duración de las actividades de aseguramiento de
calidad en TI.
Punto de vista –
PO11.4 Revisión del Aseguramiento de la Calidad sobre el Cumplimiento de
Estándares y Procedimientos de TI
Observación PO78: No existen revisiones del aseguramiento de calidad, ni
estándares de TI.
Criterio –

211
La Gerencia deberá asegurar que las responsabilidades asignadas al personal de
aseguramiento de calidad, incluyan una revisión del cumplimiento general de los
estándares y procedimientos de TI.
Condición –
De acuerdo a las entrevistas mantenidas con cada uno de los Grupos de trabajo
de la UTIC y a la Procuradora de la ESPE, los procedimientos para revisar el
aseguramiento de la calidad basándose en estándares no existen, tampoco
políticas propias para tecnología de la información (referencia: AUDI-ESPE-2007-
ENT-001, 002, 003, 004, 005).
Causa –
Desconocimiento de estándares y procedimientos de TI
Efecto –
Riesgo de no adoptar las mejores prácticas de TI y no permitir el apoyo adecuado
de los sistemas de información a los objetivos del negocio.
pondrá en ejecución políticas y normatividad para asegurar que las
responsabilidades asignadas al personal de aseguramiento de calidad, incluyan
una revisión del cumplimiento general de los estándares y procedimientos de TI.
Punto de vista –

212
PO11.5 Metodología del Ciclo de Vida de Desarrollo de Sistemas
PO11.6 Metodología del Ciclo de Vida de Desarrollo de Sistemas para
Cambios Mayores a la Tecnología Actual.
PO11.7 Actualización de la Metodología del Ciclo de Vida de Desarrollo de
Sistemas.
Observación PO79: No existe evidencia de la aplicación de la metodología del
ciclo de vida de desarrollo de sistemas en general ni actualizaciones de la misma.
Criterio –
La alta gerencia de la organización deberá definir e implementar estándares de
sistemas de información y adoptar una metodología del ciclo de vida de desarrollo
de sistemas que gobierne el proceso de desarrollo, adquisición, implementación y
mantenimiento de sistemas de información computarizados y tecnologías
relacionadas. La metodología del ciclo de vida de desarrollo de sistemas elegida
deberá ser la apropiada para los sistemas a ser desarrollados, adquiridos,
implementados y mantenidos.
En el caso de requerirse cambios mayores a la tecnología actual, como en el caso
de adquisición de nueva tecnología, la Gerencia deberá asegurar el cumplimiento
de la metodología del ciclo de vida de desarrollo de sistemas
La alta gerencia deberá implementar una revisión periódica de su metodología del
ciclo de vida de desarrollo de sistemas para asegurar que incluya técnicas y
procedimientos actuales generalmente aceptados.

213
Condición –
Existe una metodología básica del Ciclo de Vida de Desarrollo de Sistemas
(MSG-1), pero no existe evidencia de aplicación de la misma en desarrollo,
implementación y mantenimiento de aplicaciones (Referencia: análisis realizado
en el dominio de Adquisición e Implantación AI2).
Causa –
Falta de alineamiento a metodologías y estándares de desarrollo.
Efecto –
Errores y falencias en los procesos de desarrollo, adquisición, implementación y
mantenimiento de los sistemas orientados a la tecnología actual.
El Director de la UDI, en el primer trimestre del año en curso, definirá e
implementará estándares de sistemas de información y adoptará una metodología
del ciclo de vida de desarrollo de sistemas que gobierne el proceso de desarrollo,
adquisición, implementación y mantenimiento de sistemas de información
computarizados y tecnologías relacionadas, en caso de requerirse cambios
mayores a la tecnología actual, deberá asegurar el cumplimiento de la
metodología del ciclo de vida de desarrollo de sistemas, implementará además
una revisión periódica de la metodología para asegurar que incluya técnicas y
procedimientos actuales generalmente aceptados.
Punto de vista –

214
PO11.8 Coordinación y Comunicación
Observación PO80: No existe evidencia de un proceso para asegurar la
coordinación y comunicación entre clientes y desarrolladores.
Criterio –
La Gerencia deberá establecer un proceso para asegurar la coordinación y
comunicación estrecha entre los clientes de la función TI y los implementadores
de sistemas. Este proceso deberá ocasionar que los métodos estructurados que
utilice la metodología del ciclo de vida de desarrollo de sistemas, aseguren la
provisión de soluciones de tecnología de información de calidad que satisfagan
las demandas de negocio. La Gerencia deberá promover una organización que se
caracterice por la estrecha cooperación y comunicación a lo largo del ciclo de vida
de desarrollo de sistemas.
Condición –
No existe evidencia de métodos estructurados, ni de metodología del ciclo de vida
de desarrollo de sistemas, en el que se considere la coordinación y comunicación
con el usuario. (Referencia: AUDI-ESPE-2007ENT-003).
Causa –
Desconocimiento de estándares y procedimientos de TI
Efecto –

215
§ Existencia de múltiples implementaciones que muchas veces pueden no ser
necesarias.
§ Falta de seguimiento de modificaciones de los sistemas.
§ El requerimiento del usuario puede no ser atendido.
El Director de la UTIC, desde el primer trimestre del año en curso, establecerá
con la aprobación reglamentaria, un proceso para asegurar la coordinación y
comunicación entre los clientes de la función TI y los implementadores de
sistemas. Este proceso deberá ocasionar que los métodos estructurados que
utilice la metodología del ciclo de vida de desarrollo de sistemas, aseguren la
provisión de soluciones de tecnología de información de calidad que satisfagan
las demandas de negocio.
Punto de vista –
PO11.9 Marco de Referencia de Adquisición y Mantenimiento para la
Infraestructura de Tecnología
Observación PO81: No existe Marco de referencia establecido para la
Adquisición y Mantenimiento de la Infraestructura tecnológica.

216
Criterio –
Deberá establecerse un marco de referencia general referente a la adquisición y
mantenimiento de la infraestructura de tecnología. Los diferentes pasos que
deben ser seguidos con respecto a la infraestructura de tecnología (tales como
adquisición; programación, documentación y pruebas; establecimiento de
parámetros; mantenimiento y aplicación de correcciones) deberán estar regidos
por y mantenerse en línea con el marco de referencia para la adquisición y
mantenimiento de la infraestructura de tecnología.
Condición –
No existe evidencia de un Marco de referencia para la Adquisición y
mantenimiento de la infraestructura tecnológica, según información en referencia
al Plan de Infraestructura Tecnológica. (PO 3.1) (Evidencia: AUDI-ESPE-2007-
ENT- 001,002,003,004,005).
Causa –
Normatividad y procesos incompletos.
Efecto –
La falta de un Marco de referencia para la Adquisición y mantenimiento de la
Infraestructura tecnológica, conlleva a la deficiencia de análisis y determinación
de expectativas y necesidades claras y realistas de tecnología que la ESPE como
entidad Educativa necesita.

217
El director de la UDI, durante el primer trimestre del año en curso, deberá
establecer un marco de referencia general de adquisición y mantenimiento de la
infraestructura de tecnología; que contenga la adquisición; programación,
documentación y pruebas; establecimiento de parámetros; mantenimiento y
aplicación de correcciones.
Punto de vista –
PO11.10 Relaciones con Terceras Partes como Implementadores
Observación PO82: No existen procesos para asegurar las buenas relaciones de
trabajo con los implementadores externos.
Criterio –
La Gerencia deberá crear un proceso para asegurar las buenas relaciones de
trabajo con los implementadores externos que pertenezcan a terceras partes.
Dicho proceso deberá disponer que el usuario y el implementador estén de
acuerdo sobre los criterios de aceptación, el manejo de cambios, los problemas
durante el desarrollo, las funciones de los usuarios, las instalaciones, las
herramientas, el software, los estándares y los procedimientos.
Condición –

218
No existen políticas establecidas para el establecimiento de acuerdos que
permitan asegurar las relaciones con terceras partes se refiere. (Evidencia: AUDI-
ESPE-2007-ENT 001,002,003,004,005,014)
Causa –
No existe políticas y normatividad en referencia al tema.
Efecto –
Riesgo en el funcionamiento adecuado de los sistemas y en la continuidad del
negocio
El director de la UDI, durante el primer trimestre del año en curso, deberá crear e
implementar un proceso para asegurar las buenas relaciones de trabajo con los
implementadores externos, así como las políticas y normativa referentes a
acuerdos de servicios.
Punto de vista –
PO11.11 Estándares para la Documentación de Programas
PO11.12 Estándares para Pruebas de Programas
PO11.13 Estándares para Pruebas de Sistemas

219
PO11.14 Pruebas Piloto/En Paralelo
PO11.15 Documentación de las Pruebas del Sistema
Observación PO83: No existen procedimientos de documentación de sistemas,
ni estándares establecidos para las actividades del ciclo de vida de desarrollo de
sistemas.
Criterio –
La metodología del ciclo de vida de desarrollo de sistemas deberá incorporar y
proporcionar estándares para la documentación, verificación y pruebas de
programas que hayan sido comunicados y ratificados al personal interesado, así
como definir las condiciones bajo las cuales deberán conducirse y documentar las
pruebas piloto o en paralelo de sistemas nuevos y/o actuales.
Condición –
§ No existe aplicación de la metodología del ciclo de vida de desarrollo.
§ No existen estándares adaptados a las actividades de desarrollo de sistemas
(Evidencia: AUDI-ESPE-2007-014)
§ No se realizan pruebas en base a una planificación (PO10.11)
§ No existe evidencia de documentación de resultado de pruebas realizadas sobre
implementaciones o modificaciones, las pruebas que se han realizado se las
han hecho sobre un servidor destinado para estas labores, pero dicho
procedimiento e incluso la aprobación del usuario se la lleva informalmente.
(Evidencia: AUDI-ESPE-2007-ENT003.)
Causa –

220
Inexistencia de metodologías, que conlleva a la falta de documentación y
controles de cambios.
Efecto –
§ Riesgo de ineficacia en el cumplimiento del objetivo de las aplicaciones.
§ No se tiene un control adecuado de las modificaciones, que impide un
mantenimiento correcto de las aplicaciones.
El Director de la UTIC, durante el primer trimestre del año en curso, incorporará a
la metodología de desarrollo de sistemas y proporcionará estándares para la
documentación, verificación y pruebas de programas que hayan sido
comunicados y ratificados al personal interesado. Definirá las condiciones bajo las
cuales deberán conducirse y documentar las pruebas piloto o en paralelo de
sistemas nuevos y/o actuales.
Punto de vista –
PO11.16 Evaluación del Aseguramiento de la Calidad sobre el Cumplimiento
de Estándares de Desarrollo
PO11.17 Revisión del Aseguramiento de Calidad sobre el Logro de los
Objetivos de TI

221
PO11.19 Reportes de Revisiones de Aseguramiento de Calidad
Observación PO84: No existen procedimientos de aseguramiento de la calidad
de estándares, ni revisión o reportes de esta actividad.
Criterio –
El enfoque de aseguramiento de calidad de la organización deberá requerir que
una revisión post - implementación de un sistema de información operacional
evalúe si el equipo encargado del proyecto, cumplió con las estipulaciones de la
metodología del ciclo de vida de desarrollo de sistemas, así como incluir una
revisión de hasta qué punto los sistemas particulares y las actividades de
desarrollo de aplicaciones han alcanzado los objetivos de la función de servicios
de información
Los reportes de revisiones de aseguramiento de calidad deberán ser preparados y
enviados a la Gerencia de los departamentos usuarios y de la función de servicios
de información (TI).
Condición –
§ No existe seguimiento post implementación (AI7, PO10.13).
§ No se puede evaluar al equipo involucrado de acuerdo a la metodología de ciclo
de vida de desarrollo ya que dicha metodología no existe.
§ No existe evidencia de monitoreo de proyectos en cuanto a alcances de
objetivos, ya que tampoco esta formalizado procedimiento de seguimiento de
proyectos, pese a que dicha función la ejerce GT1.
Causa –
§ La inexistencia de metodologías y estándares dentro de la UTIC.

222
§ La falta de definición de un adecuado marco de administración de proyectos.
Efecto –
sistemas.
implantará políticas y normatividad para realizar una revisión post -
implementación de los sistemas de información, en las que se evalúe si el equipo
encargado del proyecto, cumplió con las estipulaciones de la metodología del
ciclo de vida de desarrollo de sistemas; si los sistemas y las actividades de
desarrollo de aplicaciones han alcanzado los objetivos de la función de servicios
de información; los reportes de revisiones de aseguramiento de calidad deberán
ser preparados y enviados a la Dirección de los departamentos usuarios y de la
función de servicios de información (TI).
Punto de vista –
PO11.18 Métricas de calidad
Observación PO85: No existen Métricas de Calidad definidas para TI.

223
Criterio –
La gerencia deberá definir y utilizar métricas para medir los resultados de
actividades, evaluando si las metas de calidad han sido alcanzadas
Condición –
No existen Métricas de calidad definidas para lo que TI se refiere, tan solo las
estipuladas organizacionalmente por la ISO. (Evidencia: SGC)
Causa –
Falta de Políticas, normas y estándares para el aseguramiento de la Calidad de
TI, según información obtenida en este dominio. (PO 10.8)
Efecto –
sistemas.
El Director de la UTIC, desde el primer trimestre del año en curso, definirá y
utilizará métricas para medir los resultados de actividades, evaluando si las metas
de calidad han sido alcanzadas
Punto de vista –

224
CAPÍTULO IV
RESUMEN EJECUTIVO
DEFINICIÓN DE LA ARQUITECTURA DE INFORMACIÓN
Actualmente en la ESPE no existe una adecuada clasificación de la información
de acuerdo a importancia, por lo cual no se le da las adecuadas seguridades, lo
que conlleva a poner en peligro la integridad de datos sumamente importantes
para la institución y que su pérdida provocaría graves percances a la institución.
MANEJO DE LA INVERSIÓN EN TECNOLOGÍA DE LA INFORMACIÓN
El adecuado manejo de esta inversión asegura el financiamiento de proyectos de
TI, así como a controlar los desembolsos de los recursos; para lo cual se hace
necesario inversión periódica y presupuestos establecidos y aprobados por la
institución para darles cumplimiento, y una adecuada justificación de los costos en
los que se incurrirán para la puesta en marcha de proyectos y presentación de los
beneficios que se percibirán al implantarlo; análisis que al momento no existe.
COMUNICACIÓN DE LOS OBJETIVOS Y ASPIRACIONES DE LA GERENCIA
Es indispensable ya que la gerencia necesita que todo el personal comprenda las
metas planteadas, de manera que formen una fuerza conjunta para alcanzarlas,
para ello se necesita que las políticas establecidas sean conocidas y entendidas
por todo el personal. Al momento no existen políticas institucionales sobre TI,
propiciado por el desconocimiento de la función del director de TI, quien según el

225
reglamento interno, es el encargado de promulgar reglamentos, estándares y
normas referentes a Tecnología de l Información dentro de la ESPE.
DEFINIR LA ADMINISTRACIÓN DE LOS PROYECTOS
Para establecer prioridades, entregar servicios oportunamente de acuerdo a lo
presupuestado; se deben identificar los proyectos y verificar que estén alineados
con el plan operacional aplicando técnicas de administración de proyectos.
En la ESPE existen formatos aprobados para la presentación de proyectos, pero
es necesaria su mejora y capacitación al personal sobre la elaboración de dicho
formato, en el cual sugerimos se anexe el punto en el que se explique alcances,
límites, puntos de revisión y aprobaciones. Adicionalmente se debe realizar un
completo análisis de factibilidad y riesgos de los proyectos, ya que actualmente no
se la realiza en su totalidad ni se la mantiene documentada del cual se deberá
incluir en la presentación de los proyectos breve resumen del análisis.
Y como parte de las necesidades, se debe definir formalmente el cómo se
llevarán y documentarán los proyectos, de manera que conste toda la información
necesaria y alusiva al proyecto incluyendo las aprobaciones por fases, informes,
planes de prueba, planes de entrenamiento a los usuarios, planes de revisión
post-implementación.
11. ADMINISTRACIÓN DE LA CALIDAD
Para satisfacer las necesidades y requerimientos del cliente de TI, por medio de la
planeación, implementación y mantenimiento de estándares de administración de
calidad y sistemas provistos para las fases de desarrollo, entregables y
responsabilidades.

226
La Escuela Politécnica del Ejercito, se encuentra inmersa en un proceso de
aseguramiento de la calidad ISO 9000, cuya información reposa en la UDI y es
publicada en el sitio web http://sgc.espe.edu.ec; sin embargo no existe evidencia
de de un plan general de calidad, en el cual se especifique el enfoque y los
factores a tomar en cuenta para el aseguramiento de la calidad; sin embargo cabe
anotar, que este tipo de certificación al que la ESPE se alinea evalúa únicamente
cumplimiento administrativo . Si bien existen planes de acción para las unidades,
estos no contienen un enfoque relacionado a las labores de la UTIC.
Al establecer un plan general de calidad, especificando los lineamientos (enfoque)
hacia los cuales se deben encaminar los procedimientos de aseguramiento de la
calidad de cada una de las unidades se desarrollará e implantará un proceso de
planeación de aseguramiento de calidad para determinar el alcance y la duración
de las actividades de aseguramiento de calidad en TI.

227
CAPITULO V
CONCLUSIONES Y RECOMENDACIONES
5.1 CONCLUSIONES
- El marco de referencia COBIT posee en su estructura teórica las herramientas
necesarias para la evaluación y auditoría de sistemas de tal manera que su
aplicación ayuda a satisfacer las múltiples necesidades de la administración en
aspectos de determinación de riesgos, definición de controles necesarios y el
aspecto técnico; y provee buenas prácticas en la ejecución de los procesos y
presenta actividades en una estructura que ayuda a optimizar la inversión de la
información y proporcionar un mecanismo de medición que establece cuando
las actividades van por el camino equivocado.
- El marco de referencia COBIT, aplicado para la ejecución de este proyecto
apoyó de manera eficiente en la evaluación y auditoria del Sistema de
Información de la ESPE, permitiendo la detección de falencias y la
determinación de recomendaciones.
- El desconocimiento del enfoque y base teórica de proyectos como este y del
Modelo COBIT en sí, hace que el personal sea renuente a participar y brindar la
información necesaria requerida incurriendo en el aumento de observaciones
debido a la falta de evidencia.
- La Escuela Politécnica del Ejército, se encuentra desalineada en lo que a la
Planificación y Organización se refiere del cumplimiento de los Objetivos de
Control enmarcados en COBIT, así como de metodologías y estándares
internacionales existentes.

228
- La ESPE actualmente posee una estructura organizacional deficiente en cuanto
a gestión estratégica de tecnología se refiere, la falta de políticas y estándares
impiden el control de TI, la ubicación organizacional de la UTIC y la falta de
gestión estratégica en un nivel gerencial impiden el alineamiento de TI a las
necesidades y requerimientos de la institución y la poca importancia a la
Arquitectura de Información y funciones relacionadas se denotan en una UTIC
con procesos y funciones poco eficientes.
- El proyecto de Evaluación y Auditoria del Sistema de Información de la ESPE,
era totalmente necesario, ya que permite a conocer a las autoridades el estado
de la UTIC, así como de las diferentes unidades en referencia a la Tecnología
de la Información; dando los hitos para el inicio de una verdadera Gestión de
Tecnología, inexistente en la ESPE.
- La Escuela Politécnica del Ejército, no posee una conciencia de UNIDAD como
institución, ya que desconoce la interrelación entre sus unidades y
departamentos para cualquier tipo de Gestión estratégica, especialmente la
Gestión estratégica informática.
5.2 RECOMENDACIONES
- Registrar las observaciones y recomendaciones, producidas por el proyecto de
“Evaluación y Auditoria del Sistema de Información de la ESPE”, dentro de los
hitos a ser analizados para las Acciones de Mejora a desarrollarse durante el
año.
- Se recomienda dar mayor importancia a la ejecución de proyectos de evaluación
por medio de la sociabilización y conocimiento de toda la Comunidad

229
Politécnica, para evitar desconocimiento, miedo y por ende falta de colaboración
de la misma.
- La UTIC debe dar apertura a este tipo de evaluación de sus funciones,
colaborando con la documentación y evidencias requeridas y manteniendo
registros documentados reales de las actividades que realizan.
- El departamento de Planificación de la ESPE como directivos que son, deben
capacitarse y abrirse acerca de proyectos de este tipo para que sean entes
colaboradores mas no de disturbio y freno a la ejecución de los mismos.
- La ESPE debe evaluar, analizar y restablecer su estructura organizacional
acorde a sus objetivos estratégicos así como definir las políticas, normas y
reglamentos a los cuales las diferentes unidades en el ejercicio de sus funciones
se alinearan para la supervisión y control de las mismas.

230
BIBLIOGRAFÍA:
• http://www.auditoriasistemas.com/
• http://dmi.uib.es/~bbuades/auditoria/sld006.htm
• http://www.solomanuales.org/curso-
MatriculaShow.cfm?id_curso=32722070041969505457666768544565&id
_centro=43204110021466565570676950524550&Nombre=MARY&Mail=
masalcedos@yahoo.com&Pais=10&Provincia=58
• http://www.monografias.com/trabajos5/audi/audi.shtml
• http://dmi.uib.es/~bbuades/auditoria/auditoria.PPT#266,11,Metodología
(2)
• http://www.audit.gov.tw/span/span2-2.htm
• Auditoría Mario B. Ron Resumen
• Marco Conceptual Modelo COBIT / Mario B. Ron
• Fases de una Auditoría / Mario B. Ron
• “Evaluación de los Sistemas de Tecnología Informática y Revisión de las
Seguridades de Plataforma Específica para la empresa EMAPA-I”/
Andrea M. Tobar.
• Management Guidelines – Cobit 3rd
Edition, Objetivos de Control Cobit,
Resumen Ejecutivo Cobit, Marco Referencial Cobit, Implementation Tool
Set – Cobit 3rd
Edition
• Modelo Coso Report
• Auditoría interna moderna de Brink y UIT
• WHITTINGTON, O. Ray, PANY Kurt, Auditoría: Un enfoque Integral, Irwin
McGrawHill, 12ª. Edición, Santa Fe de Bogota, Colombia, 2000

231
• Normas de Auditoría Interna emitidas por el The Institute of Internal
Auditors
• Enciclopedia de la Auditoría, Grupo Editorial Océano, Barcelona, España,
1999
• ARENS, Alvin, Auditoría: Un enfoque integral, Prentince Hall
• Guía de Auditoría, McGrawHill, México, 1996
• Robert L. Grinaker Ben B. Barr, Auditoría Examen de los Estados
Financieros México 1989
• MEIGS, Principios de Auditoría, Editorial Diana México 1975
• Maldonado Milton, Auditoría de Gestión – Economía, Ecología, Eficacia,
Eficiencia, Etica, 2001
• Auditoría Operacional de José Dagoberto Pinilla
• http://www.monografias.com/trabajos14/auditoriasistemas/auditoriasistem
as.shtml

232
ÍNDICE DE CONTENIDOS
CAPÍTULO I_____________________________________________________ 1
AUDITORÍA INFORMÁTICA – PRESENTACIÓN DEL PROYECTO________ 1
1.1 PROYECTO - ______________________________________________ 1
1.2 INTRODUCCIÓN - __________________________________________ 1
1.3 ANTECEDENTES - _________________________________________ 2
1.4 JUSTIFICACIÓN - __________________________________________ 3
1.5 OBJETIVO DEL PROYECTO -_________________________________ 3
1.5.1 Objetivo General_________________________________________ 3
1.5.2 Objetivos Específicos _____________________________________ 3
1.6 ALCANCE - _______________________________________________ 4
1.7 METODOLOGÍA -___________________________________________ 5
1.8 AUDITORÍA INFORMÁTICA - _________________________________ 6
1.8.1 Introducción - ___________________________________________ 6
1.8.2 Ambiente de control - _____________________________________ 7
1.8.3 Proceso de Auditoría Informática - ___________________________ 9
1.8.4 Clasificación de los controles TI ____________________________ 20
CAPÍTULO II ___________________________________________________ 42
MODELO COBIT ______________________________________________ 42
2.1 INTRODUCCIÓN __________________________________________ 42
2.2 CONTENIDO (PRODUCTOS COBIT) __________________________ 46
2.2.1 Resumen Ejecutivo______________________________________ 46
2.2.2 Marco Referencial ______________________________________ 47
2.2.3 Objetivos de Control_____________________________________ 49
2.2.4 Directrices de Auditoría __________________________________ 50
2.2.5 Guías de Administración O Directrices Gerenciales_____________ 51
2.2.6 Prácticas de Control _____________________________________ 51
2.2.7 Conjunto de Herramientas de Implementación_________________ 52
2.3 DOMINIO DE PLANEACIÓN Y ORGANIZACIÓN _________________ 53
2.3.1 Definición de un Plan Estratégico de Tecnología de Información___ 54
2.3.2 Definición de la Arquitectura de Información __________________ 57
2.3.3 Determinación de la dirección tecnológica ____________________ 59
2.3.4 Definición de la Organización y de las Relaciones de TI _________ 60
2.3.5 Manejo de la Inversión en Tecnología de Información ___________ 62
2.3.6 Comunicación de la dirección y aspiraciones de la gerencia ______ 64
2.3.7 Administración de Recursos Humanos_______________________ 65
2.3.8 Aseguramiento del Cumplimiento de Requerimientos Externos____ 67
2.3.9 Evaluación de Riesgos___________________________________ 68
2.3.10 Administración de proyectos______________________________ 70
2.3.11 Administración de Calidad _______________________________ 72
CAPÍTULO III___________________________________________________ 75
“AUDITORÍA INFORMÁTICA DEL SISTEMA DE INFORMACIÓN DE LA
ESPE: DOMINIO PLANEACIÓN Y ORGANIZACIÓN.” _________________ 75
PO1. DEFINICIÓN DE UN PLAN ESTRATÉGICO DE TECNOLOGÍA DE
INFORMACIÓN ______________________________________________ 75

233
PO1.1 Tecnología de Información como parte del Plan de la Organización a
corto y largo plazo. __________________________________________ 75
PO1.2 Plan a largo plazo de Tecnología de información. _____________ 78
PO1.3 Plan a largo plazo de Tecnología de Información - Enfoque y
Estructura _________________________________________________ 81
PO1.4 Cambios al Plan a largo plazo de Tecnología de Información ____ 81
PO1.5 Planeación a corto plazo para la función de Servicios de Información
_________________________________________________________ 83
PO1.6 Comunicación de los planes de TI _________________________ 85
PO1.7 Evaluación y Monitoreo de los planes de TI__________________ 87
PO1.8 Valoración de los sistemas existentes ______________________ 88
PO2. DEFINICIÓN DE LA ARQUITECTURA DE INFORMACIÓN________ 90
PO2.1 Modelo de la Arquitectura de Información ___________________ 90
PO2.2 Diccionario de Datos y Reglas de sintaxis ___________________ 92
PO2.3 Esquema de Clasificación de Datos________________________ 94
PO2.4 Niveles de Seguridad. __________________________________ 96
PO3. DEFINICIÓN DE LA ORGANIZACIÓN Y DE LAS RELACIONES DE TI
___________________________________________________________ 98
PO3.1 Planeación de la Infraestructura Tecnológica_________________ 98
PO3.2 Monitoreo de Tendencias y Regulaciones Futuras ___________ 100
PO3.3 Contingencias en la Infraestructura Tecnológica _____________ 101
PO3.4 Planes de Adquisición de Hardware y Software______________ 103
PO3.5 Estándares de Tecnología ______________________________ 105
PO4. DETERMINACIÓN DE LA DIRECCIÓN TECNOLÓGICA_________ 106
PO4.1 Planeación de TI o Comité de planeación/ dirección de la función de
servicios de información _____________________________________ 106
PO4.2 Ubicación de los servicios de información en la organización ___ 108
PO4.3 Revisión de Logros Organizacionales _____________________ 110
PO4.4 Funciones y Responsabilidades__________________________ 112
PO4.5 Responsabilidad del aseguramiento de calidad ______________ 114
PO4.6 Responsabilidad por la seguridad lógica y física _____________ 116
PO4.7 Propiedad y Custodia__________________________________ 118
PO4.8 Propiedad de Datos y Sistemas __________________________ 120
PO4.9 Supervisión__________________________________________ 121
PO4.10 Segregación de Funciones_____________________________ 123
PO4.11 Asignación de Personal para Tecnología de Información _____ 125
PO4.12 Descripción de Puestos para el Personal de la Función de TI. _ 127
PO4.13 Personal clave de TI__________________________________ 129
PO4.14 Procedimientos y políticas para el personal contratado _______ 131
PO4.15 Relaciones _________________________________________ 132
PO5. MANEJO DE LA INVERSIÓN EN TECNOLOGÍA DE LA INFORMACIÓN
__________________________________________________________ 134
PO5.1 Presupuesto Operativo Anual para la Función de Servicios de
información.- ______________________________________________ 134
PO5.2 Monitoreo de Costo – Beneficio __________________________ 136
PO5.3 Justificación de Costo – Beneficio ________________________ 139
PO6. COMUNICACIÓN DE LOS OBJETIVOS Y ASPIRACIONES DE LA
GERENCIA_________________________________________________ 142
PO6.1 Ambiente Positivo de Control de la Información______________ 142
PO6.2 Responsabilidad de la Gerencia sobre las Políticas___________ 143

234
PO6.3 Comunicación de las Políticas de la Organización____________ 145
PO6.4 Recursos para la implementación de Políticas. ______________ 147
PO6.5 Mantenimiento de Políticas _____________________________ 148
PO6.6 Cumplimiento de Políticas, Procedimientos y Estándares ______ 149
PO6.7 Compromiso con la Calidad _____________________________ 151
PO6.8 Política sobre el Marco de Referencia para la Seguridad y el Control
Interno. __________________________________________________ 152
PO6.9 Derechos de propiedad intelectual________________________ 153
PO6.10 Políticas para Situaciones Específicas____________________ 155
PO6.11 Comunicación para educar y concienciar (crear conciencia) sobre
Seguridad de TI. ___________________________________________ 156
PO7. ADMINISTRACIÓN DE RECURSOS HUMANOS_______________ 157
PO7.1 Reclutamiento y Promoción de Personal ___________________ 157
PO7.2 Personal Calificado ___________________________________ 159
PO7.3 Roles y Responsabilidades _____________________________ 161
PO7.4 Entrenamiento de Personal _____________________________ 163
PO7.5 Entrenamiento Cruzado o Respaldo de personal_____________ 164
PO7.6 Procedimientos de Acreditación de Personal________________ 165
PO7.7 Evaluación de Desempeño de los Empleados _______________ 167
PO7.8 Cambio y Terminación de Trabajo ________________________ 169
PO8. ASEGURAMIENTO DE CUMPLIMIENTO DE REQUERIMIENTOS
EXTERNO _________________________________________________ 170
PO8.1 Revisión de Requerimientos Externos _____________________ 170
PO8.2 Prácticas y Procedimientos para el Cumplimiento de Requerimientos
Externos _________________________________________________ 172
PO8.3 Cumplimiento de Seguridad y Ergonomía __________________ 173
PO8.4 Privacidad, propiedad intelectual y Flujo de Datos____________ 174
PO9. ANÁLISIS DE RIESGOS__________________________________ 176
PO9.1 Evaluación de Riesgos del Negocio_______________________ 176
PO9.2 Enfoque de Evaluación de Riesgos _______________________ 178
PO9.3 Identificación de Riesgos _______________________________ 179
PO9.4 Medición de Riesgos __________________________________ 181
PO9.5 Plan de Acción contra Riesgos___________________________ 183
PO10. DEFINIR LA ADMINISTRACIÓN DE LOS PROYECTOS ________ 184
PO10.1 Marco de Referencia para la Administración de Proyectos ____ 184
PO10.2 Participación del Departamento Usuario en la Iniciación de
Proyectos ________________________________________________ 187
PO10.3 Miembros y Responsabilidades del Equipo del Proyecto______ 188
PO10.4 Definición del Proyecto________________________________ 191
PO10.5 Aprobación del Proyecto ______________________________ 192
PO10.6 Aprobación de las Fases del Proyecto. ___________________ 194
PO10.7 Plan Maestro del Proyecto _____________________________ 196
PO10.8 Plan de Aseguramiento de la Calidad del Sistema___________ 198
PO10.10 Administración Formal de Riesgos de Proyectos___________ 199
PO10.11 Plan de Prueba_____________________________________ 201
PO10.12 Plan de Entrenamiento_______________________________ 202
PO10.13 Plan de Revisión Post – Implementación_________________ 203
PO11. ADMINISTRACIÓN DE LA CALIDAD _______________________ 205
PO11.1 Plan General de Calidad ______________________________ 205
PO11. 2 Enfoque de Aseguramiento de Calidad___________________ 207

235
PO11.3 Planeación del Aseguramiento de Calidad_________________ 209
PO11.4 Revisión del Aseguramiento de la Calidad sobre el Cumplimiento de
Estándares y Procedimientos de TI_____________________________ 210
PO11.5 Metodología del Ciclo de Vida de Desarrollo de Sistemas_____ 212
PO11.6 Metodología del Ciclo de Vida de Desarrollo de Sistemas para
Cambios Mayores a la Tecnología Actual. _______________________ 212
PO11.7 Actualización de la Metodología del Ciclo de Vida de Desarrollo de
Sistemas._________________________________________________ 212
PO11.8 Coordinación y Comunicación __________________________ 214
PO11.9 Marco de Referencia de Adquisición y Mantenimiento para la
Infraestructura de Tecnología _________________________________ 215
PO11.10 Relaciones con Terceras Partes como Implementadores ____ 217
PO11.11 Estándares para la Documentación de Programas _________ 218
PO11.12 Estándares para Pruebas de Programas _________________ 218
PO11.13 Estándares para Pruebas de Sistemas __________________ 218
PO11.14 Pruebas Piloto/En Paralelo____________________________ 219
PO11.15 Documentación de las Pruebas del Sistema ______________ 219
PO11.16 Evaluación del Aseguramiento de la Calidad sobre el Cumplimiento
de Estándares de Desarrollo__________________________________ 220
PO11.17 Revisión del Aseguramiento de Calidad sobre el Logro de los
Objetivos de TI ____________________________________________ 220
PO11.19 Reportes de Revisiones de Aseguramiento de Calidad ______ 221
PO11.18 Métricas de calidad _________________________________ 222
CAPÍTULO IV__________________________________________________ 224
RESUMEN EJECUTIVO ________________________________________ 224
CAPITULO V __________________________________________________ 227
CONCLUSIONES Y RECOMENDACIONES ________________________ 227
5.1 CONCLUSIONES_________________________________________ 227
5.2 RECOMENDACIONES ____________________________________ 228
BIBLIOGRAFÍA: _______________________________________________ 230
ÍNDICE DE FIGURAS
Fig.2. 1 Productos de la Familia COBIT _______________________________ 46
Fig.2. 2 Resumen de Dominios de COBIT con objetivos de control__________ 47
Fig.2. 3 Integración de Requerimientos del Negocio Procesos y Dominios IT
Recursos IT ____________________________________________________ 49
Fig.2. 4 Objetivos de Control-Resumen _______________________________ 50
Fig.2. 5 Actividades de TI__________________________________________ 54
Fig.2. 6 Actividades de la Gerencia de la Empresa ______________________ 55

T espe-021849 tesis

Más contenido relacionado

La actualidad más candente (18)

Similar a T espe-021849 tesis (20)

T espe-021849 tesis