factores de Éxito para la implantación de cobit
DESCRIPTION
El adecuado control interno permite a las empresas mejorar sus recursos y evitar los riegos. Se utiliza cobit para llegar a ese control.TRANSCRIPT
UNIVERSIDAD AUTÓNOMA DE DURANGO
CAMPUS ZACATECAS
“FACTORES DE ÉXITO PARA LA IMPLANTACIÓN DE COBIT® EN LA DIRECCIÓN DE TI
DE LA EMPRESA.”
TESIS
Que para obtener el grado de Maestro en Informática Administrativa
Presenta I.S.C. Julián Fuentes Parga
Asesor M.C. José Manuel Carrillo Hernández
Zacatecas, Zac., Diciembre 2007
HOJA DE AUTORIZACIÓN DEL TRABAJO DE TESIS
D E D I C A T O R I A S
A mi esposa Lucy Porque sin su apoyo y sacrificio
nada de esto hubiera sido posible
A mis padres Por mostrarme el camino
A G R A D E C I M I E N T O S A la Universidad Autónoma de Durango. A los maestros de la Maestría en Informática Administrativa. A mis compañeros. A mis Hermanos y familiares por el apoyo brindado durante esta travesía.
R E S U M E N
Un adecuado control interno permite a las empresas tener una mejor
administración de sus recursos y de los riesgos que se tienen en la organización.
Actualmente existen varias normativas a las que las empresas deben apegarse
para conseguir la apertura de mercados o para cumplir con los lineamientos
gubernamentales de los diversos países en los que tienen inversiones o a los que
desean hacer llegar sus productos.
Tal es el caso de la Ley Sarbanes-Oxley (Ley SOx), una ley estadounidense
que aplica a todas las compañías norteamericanas o extranjeras que coticen en la
bolsa de valores de Estados Unidos (NYSE) y que pretende proteger a los
inversionistas, exigiendo cierto nivel de control interno a las empresas para que
garanticen que los resultados financieros emitidos son fidedignos y por ende la
información financiera de la empresa es correcta.
En el presente trabajo de investigación se describe la problemática que se
ha tenido en la dirección de TI de La Empresa para establecer el nivel de control
interno adecuado para cumplir con la ley SOx, que si bien aún no es obligatoria
para La Empresa, se está preparando el camino para cuando dicha ley deba ser
cumplida.
A través de entrevistas realizadas a los altos mandos de la dirección de TI,
se obtuvieron opiniones sobre los factores que representan problemas u
obstáculos para la correcta implantación de los controles que permitirán el
cumplimiento con la ley citada anteriormente
Tomando como base las brechas detectadas en las entrevistas y la
situación deseada por la dirección de TI, se emitieron una serie de
recomendaciones para cubrir dichas brechas a fin de lograr la implantación de un
nivel de control interno adecuado que permita cumplir con la Ley SOx.
Es importante señalar que para la realización del presente trabajo de
investigación se recopiló información principalmente de las siguientes fuentes
bibliográficas:
IT Governance Institute. (2004). IT Control objectives for Sarbanes-Oxley.
IL, USA: IT Governance Institute.
SEC. (2002). Sarbanes Oxley Act of 2002. USA.
La web de Auditoria. (s.f.). El informe COSO. Recuperado el 2007, de
www.lawebdeauditoria.com:
http://212.9.83.4/auditoria/home.nsf/COSO_1?OpenPage
I N D I C E S
ÍNDICE DE CONTENIDO
P R O P O S I C I Ó N .................................................................................... 8 ENUNCIADO DE LA PROPOSICIÓN ............................................................... 9 CONTENIDO Y LÍMITES ................................................................................. 13 JUSTIFICACIÓN ............................................................................................. 14 FUENTES DE CONOCIMIENTO UTILIZADAS ............................................... 19 PROBLEMAS CORRELACIONADOS ............................................................. 21 PERIODO DE TIEMPO UTILIZADO ............................................................... 23
CAPÍTULO I ....................................................................................................... 25
MARCO TEÓRICO ............................................................................................. 25 I.1. LA LEY SARBANES – OXLEY (SOX) ....................................................... 25
I.1.A. Historia ................................................................................................ 25 I.1.B. Alcance de la Ley SOx ........................................................................ 26
I.2. COBIT® ..................................................................................................... 29 I.2.A. Definición de COBIT® ......................................................................... 29 I.2.B. Historia ................................................................................................ 31 I.2.C. Los principios del marco de referencia ............................................... 32
I.2.C.a. COBIT® y el Gobierno de TI ......................................................... 33 I.2.C.b. COBIT® como integrador de estándares ...................................... 36 I.2.C.c. El principio fundamental de COBIT ............................................... 36 I.2.C.d. Los recursos de COBIT ................................................................ 38
I.2.D. Los dominios de COBIT® ................................................................... 39 I.2.D.a. Planeación y Organización (PO) ................................................... 40 I.2.D.b. Adquisición e implementación (AI) ................................................ 42 I.2.D.c. Entrega y Soporte (DS) ................................................................. 44 I.2.D.d. Monitoreo ...................................................................................... 48
I.2.E. Modelos de madurez de COBIT® ....................................................... 49 I.3. LOS ESTÁNDARES ACEPTADOS ........................................................... 56
I.3.A. COSO ................................................................................................. 56 I.3.A.a. Entorno de control ......................................................................... 57 I.3.A.b. Evaluación de los riesgos ............................................................. 58 I.3.A.c. Actividades de control ................................................................... 58 I.3.A.d. Información y comunicación .......................................................... 58 I.3.A.e. Monitoreo ...................................................................................... 59
I.3.B. ITIL (Information Technology Infrastructure Library) ........................... 60 I.3.B.a. Soporte al Servicio ........................................................................ 61 I.3.B.b. Entrega del Servicio ...................................................................... 61
I.4 LA DIRECCIÓN DE TI DE LA EMPRESA .................................................. 62 I.4.A. Breve reseña histórica ........................................................................ 62 I.4.B. Estructura Actual ................................................................................. 63 I.4.C. Servicios de la dirección de TI ............................................................ 64
I.5. COBIT EN LA DIRECCIÓN DE TI DE LA EMPRESA ............................... 65 I.5.A. Orígenes del proyecto ......................................................................... 65 I.5.B. Los controles a implementar ............................................................... 67 I.5.C. Roles y responsabilidades .................................................................. 71
CAPITULO II ...................................................................................................... 74
DESARROLLO DE LA INVESTIGACIÓN .......................................................... 74 II.1. ANÁLISIS DE LA SITUACIÓN ACTUAL .................................................. 74
II.1.A. Formato de entrevista ........................................................................ 75 II.1.B. Análisis de datos e interpretación de resultados ................................ 78
II.1.B.a. Comunicación .............................................................................. 79 II.1.B.b. Diseño de los Controles ............................................................... 80 II.1.B.c. Implementación ............................................................................ 81 II.1.B.d. Estructura Organizacional ............................................................ 83 II.1.B.e. Apoyo de la Dirección .................................................................. 84 II.1.B.f. Percepción de los Controles ......................................................... 86 II.1.B.g. Grado de Conciencia del Personal ............................................... 87
II.1.C. Explicación de la situación actual ...................................................... 89 II.1.C.a. Comunicación .............................................................................. 89 II.1.C.b. Diseño .......................................................................................... 92 II.1.C.c. Implantación ................................................................................. 93 II.1.C.d. Apoyo por parte de la dirección de TI .......................................... 95 II.1.C.e. Percepción de los controles por parte del personal de TI ............ 95 II.1.C.f. Principales obstáculos para la implantación de los controles ....... 96
II.2. ANÁLISIS DE LA SITUACIÓN DESEADA ............................................... 97 II.3. PROPUESTA DE MEJORA O SOLUCIÓN .............................................. 98
II.3.A. Comunicación .................................................................................... 99 II.3.B. Diseño .............................................................................................. 105 II.3.C. Implementación ................................................................................ 106
C O N C L U S I O N E S ........................................................................... 110
B I B L I O G R A F Í A .............................................................................. 114
A N E X O S ...................................................................................................... 122 ANEXO A. DEFINICIÓN DE TÉRMINOS ....................................................... A-1
ÍNDICE DE TABLAS Y GRÁFICAS
TABLAS
Tabla I. Los títulos de la Ley Sarbanes-Oxley ....................................................... 29 Tabla II. Requerimientos del Negocio para la información ................................... 37 Tabla III. Definiciones de las categorías de la información .................................. 38 Tabla IV. Definiciones de los recursos de TI ........................................................ 39 Tabla V. Procesos y Objetivos de Control del Dominio PO ................................... 40 Tabla VI. Procesos y Objetivos de Control del Dominio AI .................................... 43 Tabla VII. Procesos y Objetivos de Control del Dominio DS ................................. 45 Tabla VIII. Procesos y Objetivos de Control del Dominio M .................................. 48 Tabla IX. Modelo genérico de madurez ................................................................ 51 Tabla X. Atributos de madurez ............................................................................. 53 Tabla XI. Los controles a implementar en la Dirección de TI ................................ 68 Tabla XII. Formato de entrevista ........................................................................... 75 Tabla XIII. Población Entrevistada ........................................................................ 78 Tabla XIV. Percepción sobre la Comunicación ..................................................... 79 Tabla XV. Percepción sobre el diseño de los controles ........................................ 80 Tabla XVI. Validación del cumplimiento de los controles ...................................... 81 Tabla XVII. Percepción sobre la estructura organizacional de TI .......................... 83 Tabla XVIII. Percepción sobre el apoyo de la dirección ........................................ 84 Tabla XIX. Percepción sobre cómo se visualizan los controles ............................. 86 Tabla XX. Grado de conciencia del personal de TI sobre los controles ................ 87
GRÁFICAS
Gráfica 1. Los proceso de TI definidos en los dominios de COBIT. ...................... 35 Gráfica 2. El principio fundamental de COBIT ....................................................... 37 Gráfica 3. Representación gráfica de los modelos de madurez ........................... 50 Gráfica 4. Población Entrevistada ......................................................................... 78 Gráfica 5. Percepción sobre la comunicación del proyecto ................................... 79 Gráfica 6. Percepción sobre el diseño de los controles ......................................... 80 Gráfica 7. Percepción sobre la validación del cumplimiento de los controles ....... 82 Gráfica 8. Percepción sobre la estructura organizacional de TI ............................ 83 Gráfica 9. Percepción sobre el apoyo de la dirección ........................................... 85 Gráfica 10. Percepción sobre cómo se visualizan los controles ............................ 86 Gráfica 11. Grado de conciencia del personal de TI sobre los controles .............. 88
P R O P O S I C I Ó N
9
ENUNCIADO DE LA PROPOSICIÓN
En el mundo globalizado y competitivo en el que están inmersas las
empresas, es necesario cada vez contar con un mayor número de ventajas
competitivas que permita a las mismas destacar de la competencia y por ende
aumentar el número de clientes a través de la entrega de productos y servicios de
calidad que satisfagan las expectativas de sus clientes y entreguen valor agregado
al mismo.
De la misma manera, las organizaciones de TI están enfocando cada vez
más sus esfuerzos hacia la satisfacción de los requerimientos de sus clientes, que
en la iniciativa privada son las diferentes áreas de negocio que conforman la
empresa. Los esfuerzos que se deben realizar para lograr la satisfacción de los
clientes deben empezar con establecer un esquema de control interno adecuado
que permita que las actividades de TI se realicen de una manera ordenada y
eficiente que permita maximizar los resultados con la inversión de una menor
cantidad de recursos.
Para tener un control interno adecuado, se requiere tener una serie de
conceptos perfectamente definidos y delimitados, dentro de los cuales se pueden
mencionar los siguientes:
Políticas que definan claramente los parámetros bajo los cuales se
deberán realizar las actividades o se deberán entregar los productos y servicios. A
10
estas políticas se deberán apegar todos los colaboradores para garantizar que las
actividades se realizan dentro de los parámetros establecidos.
Procesos y Procedimientos debidamente documentados, que garanticen
que las actividades son repetibles, se realizan de acuerdo a la secuencia definida
y que arrojan los resultados esperados.
Responsabilidades de todos los niveles de la organización perfectamente
definidas y delimitadas, que apoyen a la consecución de los objetivos y minimicen
los errores provocados por la falta de un responsable puntual de la entrega de
resultados.
Comunicación efectiva que garantice que la información llega a todos los
niveles y roles a los que debe llegar.
Monitoreo continuo que permita detectar desviaciones lo más pronto
posible para tomar medidas preventivas o correctivas para regresar a los
parámetros correctos.
Ciclo de mejora continua que permita mejorar los procesos con base a la
experiencia y la información proporcionada por el monitoreo.
Actualmente existen varios estándares aceptados que ayudan a las
organizaciones a contar con un control interno adecuado; cada uno de ellos
11
enfocándose en áreas específicas; así por ejemplo, se pueden mencionar:
ITIL.- Que define los procesos y actividades para soportar los servicios de
TI.
ISO:27001.- Que define un conjunto de mejores prácticas para la seguridad
de la información,
COBIT.- Que es una estructura aceptada para el gobierno de las
tecnologías de la información y las prácticas de control.
Sarbanes-Oxley (SOx).- Ley estadounidense que establece objetivos de
control para lograr un control interno adecuado que garantice la confiabilidad de la
información financiera que emiten las empresas, con el fin de proteger a los
inversionistas.
Cabe aclarar que el establecer esquemas de control interno no es tarea fácil
y requiere un esfuerzo sumamente importante por parte de las organizaciones, ya
que en muchas de ellas, se presta más atención a la operación diaria y se deja en
segundo plano la administración y control de las actividades.
Pero no se debe olvidar que la administración y control de las actividades
que se realizan pueden proporcionar la información suficiente para mejorar los
productos y servicios, otorgando por ende una atención más adecuada a las
12
necesidades de los clientes.
Por lo anteriormente descrito, este trabajo de investigación pretende
determinar los factores de éxito para la implantación de COBIT® en la dirección de
TI de La Empresa, lo cual permitirá tener un nivel de control interno adecuado que
le ayude a cumplir con la ley SOx.
Considerando que en la dirección de TI de La Empresa se inició la
implantación de COBIT® desde hace dos años y aún no se tienen los resultados
esperados, se realizó un estudio para conocer el nivel de madurez actual del
control interno; así mismo, se pretende conocer los factores que no han permitido
o han retrasado la correcta implantación de COBIT® para posteriormente
identificar y proponer los factores de éxito que se deberán tener en cuenta para
realizar la implantación exitosa de COBIT®.
Objetivo General:
Determinar los factores de éxito para la correcta implantación de COBIT®
en la dirección de TI de La Empresa.
Objetivos Específicos
1.- Identificar las necesidades que se cubren con la implantación de
13
COBIT® en la dirección de TI de La Empresa.
2.- Conocer la percepción que tiene el personal directivo de la dirección de
TI respecto la implantación de COBIT® en la dirección de TI de La Empresa.
3.-. Identificar los principales factores que obstaculizan la implantación de
COBIT® en la dirección de TI de La Empresa.
4.- Emitir recomendaciones para la implantación exitosa de COBIT® en la
dirección de TI de La Empresa.
Hipótesis Planteada:
Debido a la complejidad que representa la implantación de COBIT® en la
dirección de TI de La Empresa, es necesario analizar y determinar los factores que
permitan la implantación adecuada de COBIT®.
CONTENIDO Y LÍMITES
El presente trabajo de investigación está basado en las áreas de
conocimiento de administración, administración de calidad, gobernabilidad de TI y
tecnologías de información.
Este trabajo de investigación es de tipo descriptivo, ya que se pretende
analizar la situación actual para conocer los factores que no han permitido la
correcta implantación de COBIT® en la dirección de TI de La Empresa.
14
El diseño de esta investigación es no experimental, ya que no se
manipulará ninguna de las variables del fenómeno estudiado, sólo se observarán
las mismas en su contexto natural para posteriormente analizarlas.
Este estudio es transversal, ya que la medición de las variables
establecidas se realizó en un solo momento de tiempo.
El presente trabajo de investigación se desarrolló dentro de las
instalaciones de la dirección de TI de La Empresa.
JUSTIFICACIÓN
La evolución que han venido teniendo las empresas y organizaciones ha
sido marcada por tener cada vez un mejor control de las actividades que realizan y
de la información derivada de la ejecución de dichas actividades, trayendo consigo
una mayor eficiencia en las operaciones. Esta eficiencia ha sido fomentada por la
explotación de la información de las actividades que actualmente se realizan, de
tal forma que las organizaciones están dejando de ser reactivas para convertirse
en organizaciones proactivas, adelantándose cada vez más a los hechos.
Las organizaciones de TI deben jugar un doble papel fundamental para
lograr la explotación de la información; el primer papel, al generar mecanismos
15
para aprovechar los datos y convertirlos en información valiosa que permita tomar
decisiones efectivas en el momento indicado. El segundo papel, al aprovechar los
mismos mecanismos que genera en su propio beneficio para explotar su propia
información que le permitan ajustar sus actividades y proponer soluciones
efectivas de raíz a las problemáticas que enfrenta.
Desafortunadamente, en muchos de los casos las organizaciones de TI sólo
generan herramientas para que las áreas de negocio exploten la información que
generan, pero no adaptan o generan dichas herramientas para explotar la
información propia que les permita lograr un mayor nivel de control y por ende de
eficiencia.
Otra problemática común para las organizaciones de TI, es que están
demasiado ocupadas con la operación del día a día como para tener tiempo para
realizar las actividades bajo ciertos parámetros de orden y control que les permitan
aprovechar la información para ser proactivos e ir mejorando sus operaciones de
tal forma que les permita tener más tiempo para realizar cada vez una
administración más efectiva.
Hace casi un par de años, en la dirección de TI de La Empresa se inició con
los preparativos para una posible certificación en la ley SOx. Dicha ley
estadounidense establece objetivos de control para el control interno corporativo,
que garantice que la información financiera emitida por las empresas que cotizan
en la bolsa de valores estadounidense sea confiable, con lo cual se busca
16
restablecer la confianza de los inversionistas después de los escándalos
financieros de compañías como Enron y World Com.
Debido a que la ley SOx es muy general, se reconocen dos marcos de
referencia mediante los cuales se da cumplimiento a dicha ley, dichos marcos de
referencia son COSO y COBIT; como mencionamos anteriormente, COBIT define
los objetivos de control para organizaciones de TI.
Por lo anterior y para lograr el cumplimiento de la ley SOx, en la dirección
de TI de La Empresa se determinó la implantación de los objetivos de control de
COBIT.
Para lograr lo anterior, se realizó un análisis para determinar aquellos
controles que aplicaban a la dirección de TI, basándose en la forma de operar y en
las condiciones en las que se encontraba la misma en ese momento.
Considerando que el esfuerzo para la implantación de TODOS los controles
COBIT sería demasiado y que ya se contaba con un proyecto de gobernabilidad
de TI que ya establecía cierto control para la parte estratégica de TI, se determinó
dividir el proyecto en dos fases:
Fase 1 (Activity Level) o controles operativos de COBIT, dentro de la cual
se estableció que se deberían implantar 131 Controles.
17
Fase 2 (Company Level) o controles estratégicos. En esta fase se
determinó que se deberían implantar 132 controles y que se llevaría a cabo una
vez que se hubieran implantado satisfactoriamente los controles de activity level.
Una vez que se determinó la estrategia para la implantación de los
controles COBIT, se realizó un análisis de los 131 controles de activity level para
determinar las brechas existentes entre los mismos y la situación que guardaba en
ese momento la dirección de TI.
Con base en las brechas detectadas, se diseñaron una serie de políticas,
procesos, procedimientos, formatos y otros documentos que sustentarían los 131
controles y que se deberían implantar en la dirección de TI para lograr el nivel de
control requerido por COBIT.
Una vez que fueron diseñados los controles, se procedió a la implantación
de los mismos, lo cual significaba realizar las actividades de acuerdo a lo que se
había establecido en los documentos y generar la evidencia que comprobara que
dichos controles se estaban ejecutando de manera efectiva.
Para poder realizar la evaluación de los controles, es necesario establecer
un periodo de tiempo para lograr la madurez del control, durante este periodo de
tiempo se recolecta la evidencia necesaria que garantice que el control es maduro;
es decir, que el control se está llevando de acuerdo a lo establecido y se
monitorea que la nueva forma de realizar las actividades se esté llevando a cabo
18
de forma cotidiana.
Posteriormente, se realizó una evaluación tanto del diseño como de la
efectividad de dichos controles, misma que arrojó que los controles no eran
efectivos; es decir, que no se estaban ejecutando de acuerdo a lo que se había
documentado y no se estaba generando la evidencia suficiente que demostrara la
ejecución de los mismos y que por ende, no se habían alcanzado los resultados
esperados.
Parte de los resultados de las evaluaciones, dejaron ver que incluso, las
condiciones de la dirección de TI habían cambiado desde el momento del diseño
de los controles hasta el momento de la evaluación, por lo que también se hizo
necesario ajustar el diseño de algunos de los controles para adecuarlos a las
nuevas condiciones de la dirección de TI.
Cabe hacer mención de que las actividades para el análisis y detección de
las brechas, así como para el diseño de los controles y su posterior evaluación
fueron desarrolladas por compañías consultoras expertas en el tema.
Un factor importante a considerar es que desde que se realizó el diseño de
los controles hasta que se realizó la implantación y posteriormente hasta que se
realizó la evaluación de los mismos, se tuvieron cambios estructurales importantes
en la Dirección de TI.
19
Por todo lo anteriormente descrito, este estudio pretende analizar la
situación actual de la implantación de los controles COBIT, así como de la
situación de la dirección de TI para posteriormente determinar los factores de éxito
que se deberán considerar o seguir para lograr la correcta implantación de dichos
controles.
Se considera que es conveniente realizar este estudio debido a que aún no
se logra la implantación satisfactoria de los controles COBIT y que es necesario
establecer las acciones a seguir para lograr la correcta implantación de los
mismos.
Con la realización del presente estudio, se obtendrán beneficios para la
dirección de TI, ya que se emitirán una serie de recomendaciones para lograr la
correcta implantación de los controles COBIT, lo cual permitirá contar con un nivel
de control adecuado que permita la certificación en la Ley SOx, las actividades de
la dirección de TI se realizarán bajo ciertos parámetros de control que permitirán
que los productos y servicios proporcionados por la dirección de TI tengan una
mejor calidad y sean más eficientes.
FUENTES DE CONOCIMIENTO UTILIZADAS
Las fuentes de conocimiento utilizadas para dar sustento a la presente
20
investigación fueron:
Cursos de certificación de COBIT e ITIL, los cuales permitieron conocer
de manera general los orígenes, objetivos y características de estos marcos de
referencia.
Estándares, marcos de referencia y mejores prácticas, las cuales
permitieron conocer de manera particular los objetivos de control planteados en
cada uno de ellos.
Presentaciones de diversos proveedores, mismas que se obtuvieron de
Internet, las cuales permitieron contar con muchos conceptos e información
diversa acerca de los temas relacionados con la investigación.
Artículos de Internet y revistas, que hicieron posible el contar con datos
estadísticos e información relevante sobre temas de interés relacionados con la
investigación.
Las técnicas de recolección de información empleadas en la presente
investigación fueron:
Entrevistas realizadas al personal de los puestos clave identificados, para
conocer estatus, opiniones y problemáticas.
21
Observación, para determinar las actitudes del personal y posibles
problemas dentro de la dirección de TI.
PROBLEMAS CORRELACIONADOS
En caso de que se quisiera retomar la presente investigación como base
para otros trabajos, se considera que uno de los principales problemas sobre los
que se debería continuar la investigación, sería analizar y determinar si los
factores de éxito para la implantación de COBIT que se identificaron en esta
investigación, son los mismos y aplican de manera similar para otras
organizaciones de la iniciativa privada.
Otro punto importante sería validar si los obstáculos encontrados en el
presente trabajo de investigación se tienen también en otras empresas de la
iniciativa privada.
Dentro de los problemas correlacionados a la presente investigación que
podrían ser objeto de futuras investigaciones, se puede mencionar:
El tipo de cultura organizacional que prevalece en las empresas de la
iniciativa privada en México es un factor determinante para la forma en la que se
administran las áreas de la empresa, trayendo consigo diferentes vicios que no
permiten un desarrollo adecuado de las áreas de TI; es decir, en muchas de las
22
empresas, las áreas de TI son visualizadas como un área que no aporta valor al
negocio en lugar de visualizarse como áreas estratégicas que pueden generar una
ventaja competitiva para la empresa.
La idiosincrasia de los mexicanos puede llegar a obstaculizar los intentos de
una empresa para que funcione dentro de los parámetros de control que le
permitan una mayor eficiencia, a tal punto que pueden llegar a boicotear cualquier
iniciativa para establecer control, al sentirse vigilados y amenazados por los
esquemas controlados.
Aún existe resistencia por parte de algunas organizaciones hacia los temas
de calidad y control, cuando en una organización la dirección no comulga con
estos temas, puede ser infructífero cualquier intento de establecer control, ya que
se pueden llegar a desestimar los esfuerzos que esto implica y no serán
asignados los recursos necesarios para el logro de los objetivos.
El tipo de comunicación que impera en una organización puede significar
problemas graves no solo para la implantación de control, sino también para la
consecución de los objetivos de la organización; desafortunadamente, es más
común de lo que se piensa que en una organización existan problemas de
comunicación que truncan iniciativas importantes de crecimiento y mejora para la
misma organización.
23
PERIODO DE TIEMPO UTILIZADO
El presente trabajo de investigación fue desarrollado en el periodo de
tiempo de octubre a diciembre del año 2007.
D E M O S T R A C I Ó N
25
CAPÍTULO I
MARCO TEÓRICO
I.1. LA LEY SARBANES – OXLEY (SOX)
I.1.A. Historia
La Ley SOx nació a consecuencia de una serie de escándalos financieros
importantes en varias empresas estadounidenses que tuvieron lugar a finales del
2001. En compañías como Enron, Worldcom, entre otras, fueron evidenciadas
prácticas administrativas no apropiadas que llevaron a varias de ellas a la quiebra,
y se evidenciaron fraudes que mermaron la confianza de los inversionistas sobre
la información financiera que las compañías estaban emitiendo.
Por tal motivo, el senador Paul Sarbanes y el representante Michel Oxley
lograron que en un tiempo record el gobierno de Estados Unidos aprobara la
Sarbanes-Oxley Act (Ley Sarbanes-Oxley), la cual debe su nombre a la unión de
los apellidos de sus creadores.
Fue así que en Julio del 2002 el gobierno estadounidense aprobó la ley
Sarbanes-Oxley como un mecanismo para fortalecer el control interno de las
empresas, con la finalidad de devolver la confianza que los inversionistas habían
perdido tiempo atrás.
26
I.1.B. Alcance de la Ley SOx
Aún y cuando la ley Sarbanes-Oxley es una ley estadounidense, es
aplicable a todas las empresas que cotizan en la New York Stock Exchange
(NYSE) y en la National Association of Securities Dealers by Automatic Quotation
(NASDAQ); por lo tanto, esto incluye tanto a empresas estadounidenses como
para las extranjeras que cotizan en dichas bolsas de valores, incluyendo tanto a la
matriz como a sus subsidiarias y afiliadas.
La ley SOx está compuesta por 11 títulos que regulan desde
responsabilidades adicionales para las mesas directivas, hasta penas criminales.
Las principales novedades de esta ley son:
En el título I se establece la creación de un mecanismo denominado “Public
Company Accounting Oversight Board” (PCAOB), cuya principal función es la de
tener un registro de las compañías auditoras y supervisar su trabajo para
garantizar que se apegan a los estándares de control de calidad y principios
éticos. De esta manera se pretende garantizar que las firmas de auditoría no estén
coludidas con las empresas para emitir información financiera incorrecta que
proporcione una imagen financiera diferente a la que realmente tienen las
empresas.
En el título II se establecen temas de independencia de auditoría, limitando
27
los servicios que las empresas auditoras pueden prestar a sus clientes a los que
auditan. Por lo anterior, queda prohibido para una empresa auditora proporcionar
a sus clientes de auditoría servicios de contabilidad y todos aquellos servicios
relacionados con la preparación y emisión de los reportes anuales, auditoría
interna, servicios legales, servicios actuariales y todos aquellos que la PCAOB
determine.
En el título III se establece el concepto de responsabilidad corporativa, la
sección 302 establece que los reportes financieros que la empresa entrega al
público deben estar certificados por el CEO (director general) y el CFO (director de
finanzas) con la intención de responsabilizarlos por el establecimiento y
mantenimiento del control interno necesario para que la información que se
entrega siempre sea verídica.
Debido a que esta certificación no está sujeta a alguna revisión por parte de
auditores externos y para garantizar la transparencia y confiabilidad de la
información, se hace necesario que la misma sea verificada por personal
independiente a la empresa; dicho personal conforma el comité de auditoría.
En el título IV se tiene la sección 404, la cual es la que más polémica ha
causado, ya que establece la responsabilidad de la dirección sobre la creación y
mantenimiento del control interno para la generación de los resultados financieros;
adicionalmente, el reporte del auditor externo debe incluir una evaluación de los
procedimientos de control interno para los resultados financieros y su efectividad
28
operativa.
Es para esta sección 404, que en junio del 2005 (a un año de su
implantación) en Estados Unidos ya había un total de 1,968 empresas –de un total
de 2,872 reportando sus resultados financieros de acuerdo a las especificaciones
de la ley SOx.1
Es precisamente la implantación del control interno adecuado (sección 404)
la que está significando un esfuerzo titánico para las empresas, tanto en lo
económico como en las horas de trabajo requeridas para su correcta implantación.
En el 2005, la Securities and Exchange Commission (SEC) estimaba que
las empresas gastarían anualmente alrededor de 5.4 millones de horas de trabajo
de su personal en la implantación de la sección 404 de la ley SOx. 2
Al principio, las empresas estaban preocupadas por el hecho de revelar al
público sus carencias en cuanto al control interno, temiendo que esto afectara los
valores de las acciones de sus compañías; sin embargo, esto no sucedió y de
acuerdo a un estudio realizado por Deloitte, los precios de las acciones sólo
tuvieron variaciones menores al 5%.
1 “Preguntas Frecuentes de SOx”. en Deloitte. Chile. 2005. 2 MARTIN, Steven. “Las Ventajas de Sarbanex-Oxley”, en Information Week. Mayo 2005. p.19.
29
El resto de los títulos de la ley Sarbanes-Oxley se muestran en la siguiente
tabla:
Tabla I. Los títulos de la Ley Sarbanes-Oxley Título Regula:
I Junta de Supervisión de Firmas de Auditoría Sección 101, sobre retención y salvaguardia de documentos de auditoría
II Independencia de los Auditores Sección 201, sobre monitoreo y pre aprobación de servicios diferentes a los de auditoria
III
Responsabilidad Corporativa Sección 302, sobre Certificación por parte del CEO y CFO de los reportes entregados a la SEC. Sección 306, sobre monitoreo y prevención de operaciones con información privilegiada
IV Revelaciones Financieras Mejoradas Sección 404, sobre control interno Sección 409, sobre revelación oportuna de cualquier cambio material
V Conflicto de Intereses Sección 501, sobre monitoreo y revelación de analista de valores
VI Recursos y Autoridad de la Comisión VII Estudios e Informes
VIII
Responsabilidad Corporativa y Fraude Sección 802, sobre la retención y protección de documentos y registros de auditoría. Sección 806, sobre comunicación y recepción de denuncias.
IX Sanciones por crímenes de cuello y corbata Sección 906, sobre certificación de la información financiera
X Declaraciones de Impuestos Corporativos XI
Responsabilidad por Fraudes Corporativos Sección 1102, sobre retención y salvaguardia de la información
I.2. COBIT®
I.2.A. Definición de COBIT®
COBIT.- Control Objectives for Information and related Technology
(objetivos de control para la información y la tecnología relacionada).
30
Los objetivos de control para la información y la tecnología relacionada
(COBIT®) es un marco de referencia de buenas prácticas para las organizaciones
de TI. Este marco está formado por un conjunto de dominios y procesos que
representan las actividades de TI en una estructura manejable y lógica.
Este marco de referencia de buenas prácticas es el resultado del esfuerzo
de cientos de expertos alrededor del mundo y están dirigidas fuertemente a lograr
un control adecuado y en menor medida a la ejecución de las actividades.
Como resultado de la adopción de estas prácticas (implementación de
COBIT), se obtienen resultados importantes como los citados a continuación:
♦ Una mejor alineación de TI mediante un enfoque de negocio.
♦ Una vista comprensible de TI.
♦ Orientación a Procesos, estableciendo claramente la propiedad y la
responsabilidad de los mismos.
♦ Lograr un entendimiento compartido con todas las partes interesadas
basándose en un lenguaje común.
♦ Aseguran la entrega del servicio.
♦ Ayudan a optimizar las inversiones realizadas por TI.
♦ Establecen parámetros de comparación que ayuden a determinar
cuando las cosas no marchan adecuadamente.
31
La misión de COBIT
“Investigar, desarrollar, publicar y promover un conjunto de objetivos de control en tecnología de información con autoridad, actualizados, de carácter internacional y aceptados generalmente para el uso cotidiano de gerentes de empresas y auditores”.3
I.2.B. Historia
Como cualquier estándar, COBIT ha tenido una evolución importante desde
su creación en 1996; por lo cual, se han venido publicando diferentes ediciones en
las cuales se ha venido incrementando el alcance y beneficios. Esta evolución se
presenta a manera de resumen a continuación:
La primera edición fue liberada en abril de1996 por la Information Systems
Audit and Control Foundation (ISACF) como una herramienta de control y para
realizar auditorías.
La segunda edición fue publicada en abril de 1998 y en ella se incluyó un
mayor número de documentos fuente, una revisión a los objetivos de control de
alto nivel, objetivos de control detallados y la adición de un conjunto de
herramientas de implementación.
La tercera edición fue liberada en Julio del 2000, una de las novedades 3 COBIT Objetivos de Control. IT Governance Institute. 3ra. Edición. USA 1996. p. 1.
32
principales fue que dicho documento fue editado por el Instituto de Gobierno de TI
(IT Governance Institute), el cual fue formado por la Information Systems Audit and
Control Association (ISACA) en 1998. En esta versión de COBIT se agregaron las
directrices gerenciales y se enfocó más hacia el Gobierno de TI.
La cuarta edición y más actual contiene una mayor integración con otros
estándares más detallados, tiene un mayor enfoque hacia el Gobierno de TI e
incluye también el análisis detallado de métricas.
I.2.C. Los principios del marco de referencia
Durante mucho tiempo se consideró a TI como un ente aislado para la
consecución de los objetivos de la empresa; sin embargo, en el mercado global en
el que están inmersos todas las empresas cada vez se hace más evidente que
para lograr el éxito se requiere que todas las áreas de la misma estén enfocadas y
trabajando para lograr dichos objetivos, lo que llevará a la empresa a lograr el
éxito.
Por lo anterior, es necesario que entre el gobierno de la empresa y el
gobierno de TI se tenga una alineación que permita que TI sea considerada como
parte integral de la estrategia.
33
I.2.C.a. COBIT® y el Gobierno de TI
Lo primero que se debe hacer al hablar de gobierno de TI, es definir lo que
esto significa y para tal efecto, COBIT proporciona la siguiente definición de
gobierno de TI:
“Una estructura de relaciones y procesos para dirigir y controlar la empresa con el objeto de alcanzar los objetivos de la empresa y añadir valor mientras se balancean los riesgos versus el retorno sobre TI y sus procesos”.4
La estructura del gobierno de TI permite que los procesos de TI sean unidos
con los recursos de TI, así como con las estrategias y los objetivos de la empresa.
Por lo tanto, el gobierno de TI es parte integral del éxito del gobierno corporativo o
de la empresa, garantizando así una medición efectiva y eficiente de los procesos
de la empresa para mejorarlos.
Las empresas deben ser gobernadas por mejores prácticas generalmente
aceptadas, que permitan asegurar que la empresa está cumpliendo sus metas y
que esto está soportado por ciertos controles.
De la misma manera, TI debe ser gobernado por mejores prácticas que
garanticen que la información de la empresa y sus tecnologías relacionadas
apoyen a los objetivos del negocio, estos recursos deben ser utilizados de manera
4 COBIT Objetivos de Control. IT Governance Institute. 3ra. Edición. USA 1996. p. 5
34
responsable y los riesgos relacionados a TI son manejados apropiadamente.
COBIT está diseñado para su uso por parte de tres diferentes audiencias:
Administración/Gerencia: Para apoyarlos en el logro de un balance
adecuado entre los riesgos y las inversiones en un ambiente de TI frecuentemente
impredecible.
Usuarios: Para garantizar la seguridad y los controles de los servicios
proporcionados por tecnología de información o por terceros.
Auditores: Para soportar sus criterios de revisión y proporcionar
recomendaciones referentes a los controles internos a la administración.
Orientación a los objetivos del negocio
COBIT está alineado con los objetivos del negocio, debido que los objetivos
de control tienen una clara relación con los objetivos del negocio, ya que están
definidos con una orientación a los procesos del negocio.
Con base en las actividades de investigación, en el marco de referencia de
COBIT se han identificado:
♦ 4 Dominios.
♦ 34 Objetivos de alto nivel.
35
♦ 318 Objetivos de control detallados.
Los cuales se representan a continuación:
Gráfica 1. Los proceso de TI definidos en los dominios de COBIT.5
5 COBIT Objetivos de Control. IT Governance Institute. 3ra. Edición. USA 1996. p. 8
36
I.2.C.b. COBIT® como integrador de estándares
Actualmente se tienen dos diferentes tipos de modelos de control:
♦ Los modelos de control de negocios (como COSO)
♦ Los modelos más enfocados a TI (como DTI).6
COBIT está diseñado para cubrir la brecha existente entre los dos tipos de
modelos de control; por lo tanto, COBIT se visualiza como una herramienta más
completa para llevar a cabo la administración y para operar a un nivel más alto a
los estándares de tecnología. Por lo anterior se dice que COBIT es el modelo para
el gobierno de TI.
I.2.C.c. El principio fundamental de COBIT
“El principio fundamental del marco referencial de COBIT se refiere a que el enfoque del control en TI se lleva a cabo visualizando la información necesaria para dar soporte a los procesos de negocio y considerando a la información como el resultado de la aplicación combinada de recursos relacionados con la Tecnología de Información que deben ser administrados por procesos de TI”.7
6 Security Code of Conduct del DTI (Departamento de Industria y Comercio, Reino Unido) 7 COBIT Objetivos de Control. IT Governance Institute. 3ra. Edición. USA 1996. p. 14
37
Requerimientos de Negocio
Gráfica 2. El principio fundamental de COBIT
Para que los objetivos del negocio puedan ser satisfechos, la información
debe cumplir con ciertos criterios del negocio, que de acuerdo a COBIT son
conocidos como requerimientos del negocio para la información. Dichos criterios
son resumidos a continuación:
Tabla II. Requerimientos del Negocio para la información 8 Tipo Requerimiento
Requerimientos de Calidad Calidad Costo Entrega o Distribución de Servicios
Requerimientos Fiduciarios (COSO)
Efectividad y eficiencia de las operaciones Confiabilidad de la información Cumplimiento de las leyes y regulaciones
Requerimientos de Seguridad Confidencialidad Integridad Disponibilidad
Dentro de estos requerimientos, se observó que varios de ellos se
traslapaban con algunos otros de un tipo diferente; así por ejemplo, el aspecto de
entrega o distribución del servicio (de la Calidad) se traslapa con el aspecto de 8 COBIT Objetivos de Control. IT Governance Institute. 3ra. Edición. USA 1996. p. 15
Recursos de TI
Procesos de TI
38
disponibilidad (de seguridad) y también con el de efectividad y eficiencia.
Analizando los requerimientos de calidad, fiduciarios y de seguridad de
manera más amplia, se llegó a siete categorías distintas, mismas que se describen
a continuación:
Tabla III. Definiciones de las categorías de la información 9 Categoría Requerimiento
Efectividad
Se refiere a que la información relevante sea pertinente para el proceso del negocio, así como a que su entrega sea oportuna, correcta, consistente y de manera utilizable.
Eficiencia Se refiere a la provisión de información a través de la utilización óptima (más productiva y económica) de recursos.
Confidencialidad Se refiere a la protección de información sensible contra divulgación no autorizada.
Integridad
Se refiere a la precisión y suficiencia de la información, así como a su validez de acuerdo con los valores y expectativas del negocio.
Disponibilidad
Se refiere a la disponibilidad de la información cuando ésta es requerida por el proceso de negocio ahora y en el futuro. También se refiere a la salvaguarda de los recursos necesarios y capacidades asociadas.
Cumplimiento
Se refiere al cumplimiento de aquellas leyes, regulaciones y acuerdos contractuales a los que el proceso de negocios está sujeto, por ejemplo, criterios de negocio impuestos externamente.
Confiabilidad de la Información
Se refiere a la provisión de información apropiada para la administración con el fin de operar la entidad y para ejercer sus responsabilidades de reportes financieros y de cumplimiento.
I.2.C.d. Los recursos de COBIT 9 Ibidem.
39
Los recursos de TI que COBIT ha identificado son los siguientes:
Tabla IV. Definiciones de los recursos de TI 10 Recurso Descripción
Datos Son objetos en su más amplio sentido, (por ejemplo, externos e internos), estructurados y no estructurados, gráficos, sonido, etc.
Sistemas de Aplicaciones Se entiende como sistemas de aplicación la suma de procedimientos manuales y programados.
Tecnología La tecnología cubre hardware, sistemas operativos, sistemas de administración de bases de datos, redes, multimedia, etc.
Instalaciones Recursos para alojar y dar soporte a los sistemas de información.
Personal
Habilidades del personal, conocimiento, sensibilización y productividad para planear, organizar, adquirir, entregar, soportar y monitorear servicios y sistemas de información.
I.2.D. Los dominios de COBIT®
Como se mencionó anteriormente, se tienen cuatro grandes dominios
identificados por COBIT, los cuales son identificados por las palabras que la
gerencia utilizaría en las actividades del día a día:
• Planeación y organización.
• Adquisición e implementación.
• Entrega y Soporte.
• Monitoreo
10 Ibidem.
40
Cada uno de estos dominios son descritos a continuación; adicionalmente,
se muestra la relación existente entre los procesos (objetivos de alto nivel) y los
objetivos control (detallados).
I.2.D.a. Planeación y Organización (PO) “Este dominio cubre las estrategias 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á establecerse una organización y una infraestructura tecnológica apropiadas”.11
Tabla V. Procesos y Objetivos de Control del Dominio PO 1.0 Definición de un Plan Estratégico de Tecnología de Información 1.1 Tecnología de Información como parte del Plan de la Organización a corto y largo plazo 1.2 Plan a largo plazo de Tecnología de Información 1.3 Plan a largo plazo de Tecnología de Información - Enfoque y Estructura 1.4 Cambios al Plan a largo plazo de Tecnología de Información 1.5 Planeación a corto plazo para la función de Servicios de Información 1.6 Comunicación de los planes de TI 1.7 Evaluación y Monitoreo de los planes de TI. 1.8 Valoración de los sistemas existentes. 2.0 Definición de la Arquitectura de Información 2.1 Modelo de la Arquitectura de Información 2.2 Diccionario de Datos y Reglas de sintaxis de datos corporativos 2.3 Esquema de Clasificación de Datos 2.4 Niveles de Seguridad. 3.0 Determinación de la Dirección Tecnológica 3.1 Planeación de la Infraestructura Tecnológica 3.2 Monitoreo de Tendencias y Regulaciones Futuras 3.3 Contingencias en la Infraestructura Tecnológica 3.4 Planes de Adquisición de Hardware y Software 3.5 Estándares de Tecnología 4.0 Definición de la Organización y de las Relaciones de TI 4.1 Planeación de TI o Comité de planeación/dirección de la función de servicios de
11 COBIT Objetivos de Control. IT Governance Institute. 3ra. Edición. USA 1996. p. 17.
41
información 4.2 Ubicación de los servicios de información en la organización 4.3 Revisión de Logros Organizacionales 4.4 Funciones y Responsabilidades 4.5 Responsabilidad del aseguramiento de calidad 4.6 Responsabilidad por la seguridad lógica y física 4.7 Propiedad y Custodia 4.8 Propiedad de Datos y Sistemas 4.9 Supervisión 4.10 Segregación de Funciones 4.11 Asignación de Personal para Tecnología de Información 4.12 Descripción de Puestos para el Personal de la Función de TI 4.13 Personal clave de TI 4.14 Procedimientos y políticas para el personal contratado 4.15 Relaciones 5.0 Manejo de la Inversión en Tecnología de Información 5.1 Presupuesto Operativo Anual para la Función de Servicio de información 5.2 Monitoreo de Costo - Beneficio 5.3 Justificación de Costo – Beneficio 6.0 Comunicación de los Objetivos y Aspiraciones de la Gerencia 6.1 Ambiente positivo de control de la información 6.2 Responsabilidad de la Gerencia en cuanto a Políticas 6.3 Comunicación de las Políticas de la Organización 6.4 Recursos para la implementación de Políticas 6.5 Mantenimiento de Políticas 6.6 Cumplimiento de Políticas, Procedimientos y Estándares 6.7 Compromiso con la Calidad 6.8 Política sobre el Marco Referencial para la Seguridad y el Control Interno 6.9 Derechos de propiedad intelectual 6.10 Políticas Específicas 6.11 Comunicación de Conciencia de Seguridad en TI 7.0 Administración de Recursos Humanos 7.1 Reclutamiento y Promoción de Personal 7.2 Calificación del Personal 7.3 Roles y Responsabilidades 7.4 Entrenamiento del personal 7.5 Entrenamiento Cruzado o Respaldo de Personal 7.6 Procedimientos para la Acreditación del Personal 7.7 Evaluación de Desempeño de los Empleados 7.8 Cambios de Puesto y Terminación de contrato de trabajo 8.0 Aseguramiento del Cumplimiento con Requerimientos Externos 8.1 Revisión de Requerimientos Externos 8.2 Prácticas y Procedimientos para el Cumplimiento de Requerimientos Externos 8.3 Cumplimiento de los Estándares de Seguridad y Ergonomía 8.4 Privacidad, Propiedad Intelectual y Flujo de Datos 8.5 Comercio Electrónico 8.6 Cumplimiento con Contratos de Seguros 9.0 Análisis de Riesgos 9.1 Análisis de Riesgos del Negocio 9.2 Enfoque de Análisis de Riesgos 9.3 Identificación de Riesgos
42
9.4 Medición de Riesgos 9.5 Plan de Acción para mitigar los Riesgos 9.6 Aceptación de Riesgos 9.7 Selección de Protección. 9.8 Compromiso de Análisis de Riesgos 10.0 Administración de Proyectos 10.1 Marco Referencial para la Administración de Proyectos 10.2 Participación del Departamento Usuario en la Iniciación de Proyectos 10.3 Miembros y Responsabilidades del Equipo del Proyecto 10.4 Definición del Proyecto 10.5 Aprobación del Proyecto 10.6 Plan maestro del proyecto 10.7 Plan Maestro del Proyecto 10.8 Plan de Aseguramiento de Calidad de Sistemas 10.9 Planeación de Métodos de Aseguramiento 10.10 Administración Formal de Riesgos de Proyectos 10.11 Plan de Prueba 10.12 Plan de Entrenamiento 10.13 Plan de Revisión Post Implementación 11.0 Administración de Calidad 11.1 Plan General de Calidad 11.2 Enfoque de Aseguramiento de Calidad 11.3 Planeación del Aseguramiento de Calidad 11.4 Revisión de Aseguramiento de Calidad sobre el Cumplimiento de Estándares y procedimientos de la Función de Servicios de Información 11.5 Metodología del Ciclo de Vida de Desarrollo de Sistemas 11.6 Metodología del Ciclo de Vida de Desarrollo de Sistemas para Cambios Mayores a la Tecnología Actual 11.7 Actualización de la Metodología del Ciclo de Vida de Desarrollo de Sistemas 11.8 Coordinación y Comunicación 11.9 Marco Referencial para la Adquisición y Mantenimiento de la Infraestructura de Tecnología 11.10 Relaciones con Terceras Partes en su rol de Implementadores 11.11 Estándares para la Documentación de Programas 11.12 Estándares para Pruebas de Programas 11.13 Estándares para Pruebas de Sistemas 11.14 Pruebas Piloto/En Paralelo 11.15 Documentación de las Pruebas del Sistema 11.16 Evaluación del Aseguramiento de la Calidad sobre el Cumplimiento de Estándares de Desarrollo 11.17 Revisión del Aseguramiento de Calidad sobre el Logro de los Objetivos de la Función de Servicios de Información 11.18 Métricas de Calidad 11.19 Reportes de Revisiones de Aseguramiento de la Calidad
I.2.D.b. Adquisición e implementación (AI)
“Para llevar a cabo la estrategia de TI, las soluciones de TI deben ser
43
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, para asegurar que el ciclo de vida es continuo para esos sistemas”.12
Tabla VI. Procesos y Objetivos de Control del Dominio AI 1.0 Identificación de Soluciones 1.1 Definición de Requerimientos de Información 1.2 Formulación de Acciones Alternativas 1.3 Formulación de Estrategias de Adquisición. 1.4 Requerimientos de Servicios de Terceros 1.5 Estudio de Factibilidad Tecnológica 1.6 Estudio de Factibilidad Económica 1.7 Arquitectura de Información 1.8 Reporte de Análisis de Riesgos 1.9 Controles de Seguridad costo-efectivo 1.10 Diseño de Pistas de Auditoría 1.11 Ergonomía 1.12 Selección de Software del Sistema 1.13 Control de Abastecimiento 1.14 Adquisición de Productos de Software 1.15 Mantenimiento de Software de Terceras Partes 1.16 Contratos para la Programación de Aplicaciones 1.17 Aceptación de Instalaciones 1.18 Aceptación de Tecnología 2.0 Adquisición y Mantenimiento de Software de Aplicación 2.1 Métodos de Diseño 2.2 Cambios Significativos a Sistemas Actuales 2.3 Aprobación del Diseño 2.4 Definición y Documentación de Requerimientos de Archivos 2.5 Especificaciones de Programas 2.6 Diseño para la Recopilación de Datos Fuente 2.7 Definición y Documentación de Requerimientos de Entrada de Datos 2.8 Definición de Interfases 2.9 Interfases Usuario-Máquina 2.10 Definición y Documentación de Requerimientos de Procesamiento 2.11 Definición y Documentación de Requerimientos de Salida de Datos 2.12 Controlabilidad 2.13 Disponibilidad como Factor Clave de Diseño 2.14 Consideración de Integridad de TI en programas de software de aplicaciones 2.15 Pruebas al Software de Aplicación 2.16 Materiales de Consulta y Soporte para Usuario 2.17 Reevaluación del Diseño del Sistema 3.0 Adquisición y Mantenimiento de la Arquitectura de Tecnología 3.1 Evaluación de Nuevo Hardware y Software 3.2 Mantenimiento Preventivo para Hardware 3.3 Seguridad del Software del Sistema
12 Ibidem. pp. 17-18.
44
3.4 Instalación del Software del Sistema 3.5 Mantenimiento del Software del Sistema 3.6 Controles para Cambios del Software del Sistema 3.7 Uso y Monitoreo de Utilidades/Utilitarios del Sistema 4.0 Procedimientos de Desarrollo y Mantenimiento de TI 4.1 Requerimientos Operacionales y Niveles de Servicio 4.2 Manual de Procedimientos para Usuario 4.3 Manual de Operación 4.4 Material de Entrenamiento 5.0 Instalación y Acreditación de Sistemas 5.1 Entrenamiento 5.2 Medición del Desempeño del Software de Aplicación 5.3 Plan de Implementación 5.4 Conversión del Sistema 5.5 Conversión de datos 5.6 Planes y estrategias de pruebas 5.7 Pruebas a cambios 5.8 Criterios y Desempeño de Pruebas en Paralelo/Piloto 5.9 Prueba de Aceptación Final 5.10 Pruebas y Acreditación de la Seguridad 5.11 Prueba Operacional 5.12 Promoción a Producción 5.13 Evaluación de la Satisfacción de los Requerimientos del Usuario 5.14 Revisión Gerencial Post – Implementación 6.0 Administración de Cambios 6.1 Inicio y Control de Solicitudes de Cambio 6.2 Análisis de Impacto 6.3 Control de Cambios 6.4 Cambios de Emergencia 6.5 Documentación y Procedimientos 6.6 Mantenimiento Autorizado 6.7 Política de Liberación de Software 6.8 Distribución de Software
I.2.D.c. Entrega y Soporte (DS)
“En este dominio se hace referencia a la entrega o distribución de los servicios requeridos, que abarca desde las operaciones tradicionales hasta el entrenamiento, pasando por la seguridad en los sistemas y la continuidad de las operaciones así como aspectos sobre entrenamiento. Con el fin de proveer servicios, deberán establecerse los procesos de soporte necesarios. Este dominio incluye el procesamiento de los datos el cual es ejecutado por los sistemas de
45
aplicación, frecuentemente clasificados como controles de aplicación”.13
Tabla VII. Procesos y Objetivos de Control del Dominio DS 1.0 Definición de Niveles de Servicio 1.1 Marco de Referencia para acuerdos de Nivel de Servicio 1.2 Aspectos sobre los Acuerdos de Nivel de Servicio 1.3 Procedimientos de Desempeño 1.4 Monitoreo y Reporte 1.5 Revisión de Contratos y Acuerdos de Nivel de Servicio 1.6 Elementos sujetos a Cargo 1.7 Programa de Mejoramiento del Servicio 2.0 Administración de Servicios prestados por Terceros 2.1 Interfases con Proveedores 2.2 Relaciones con los Dueños 2.3 Contratos con Terceros 2.4 Calificaciones de terceros 2.5 Contratos con Outsourcing 2.6 Continuidad del Servicios 2.7 Relaciones de Seguridad 2.8 Monitoreo 3.0 Administración de Desempeño y Capacidad 3.1 Requerimientos de Disponibilidad y Desempeño 3.2 Plan de Disponibilidad 3.3 Monitoreo y Reporte 3.4 Herramientas de Modelado 3.5 Administración de Desempeño Proactivo 3.6 Pronóstico de Carga de Trabajo 3.7 Administración de Capacidad de Recursos 3.8 Disponibilidad de Recursos 3.9 Calendarización / Programación de recursos 4.0 Aseguramiento de Servicio Continuo 4.1 Marco de Referencia de Continuidad de Tecnología de Información 4.2 Estrategia y Filosofía del Plan de Continuidad de Tecnología de Información 4.3 Contenido del Plan de Continuidad de Tecnología de Información 4.4 Minimización de requerimientos de Continuidad de Tecnología de Información 4.5 Mantenimiento del Plan de Continuidad de Tecnología de Información 4.6 Pruebas del Plan de Continuidad de Tecnología de Información 4.7 Entrenamiento sobre el Plan de Continuidad de Tecnología de Información 4.8 Distribución del Plan de Continuidad de Tecnología de Información 4.9 Procedimientos de Respaldo de Procesamiento para Departamentos Usuarios 4.10 Recursos críticos de Tecnología de Información 4.11 Centro de Cómputo y Hardware de respaldo 4.12 Almacenamiento de copias de respaldo fuera del sitio 4.13 Procedimientos de Refinamiento del Plan de Continuidad de TI 5.0 Garantizar la Seguridad de Sistemas 5.1 Administrar Medidas de Seguridad
13 Ibidem. p. 18.
46
5.2 Identificación, Autenticación y Acceso 5.3 Seguridad de Acceso a Datos en Línea 5.4 Administración de Cuentas de Usuario 5.5 Revisión Gerencial de Cuentas de Usuario 5.6 Control de Usuarios sobre Cuentas de Usuario 5.7 Vigilancia de Seguridad 5.8 Clasificación de Datos 5.9 Administración Centralizada de Identificación y Derechos de Acceso 5.10 Reportes de Violación y de Actividades de Seguridad 5.11 Manejo de Incidentes 5.12 Re-acreditación 5.13 Confianza en las Contrapartes 5.14 Autorización de Transacciones 5.15 No Rechazo 5.16 Sendero Seguro 5.17 Protección de las funciones de seguridad 5.18 Administración de las Llaves Criptográficas 5.19 Prevención, Detección y Corrección de Software “Malicioso” 5.20 Arquitecturas de Firewalls y conexión a redes públicas 5.21 Protección de Valores Electrónicos 6.0 Identificación y Asignación de Costos 6.1 Elementos Sujetos a Cargo 6.2 Procedimientos de Costeo 6.3 Procedimientos de Cargo y Facturación a Usuarios 7.0 Educación y Entrenamiento de Usuarios 7.1 Identificación de Necesidades de Entrenamiento 7.2 Organización de Entrenamiento 7.3 Entrenamiento sobre Principios y Conciencia de Seguridad 8.0 Apoyo y Asistencia a los Clientes de Tecnología de Información 8.1 Help Desk 8.2 Registro de consultas del Cliente 8.3 Escalamiento de consultas del Cliente 8.4 Monitoreo de Atención a Clientes 8.5 Análisis y Reporte de Tendencias 9.0 Administración de la Configuración 9.1 Registro de la Configuración 9.2 Base de la Configuración 9.3 Registro de status 9.4 Control de la Configuración 9.5 Software no Autorizado 9.6 Almacenamiento de Software 9.7 Procedimientos para la Administración de la Configuración 9.8 Contabilidad y registro del Software 10.0 Administración de Problemas e Incidentes 10.1 Sistema de Administración de Problemas 10.2 Escalamiento de Problemas 10.3 Seguimiento de Problemas y Pistas de Auditoría 10.4 Autorizaciones para acceso temporal y de emergencia. 10.5 Prioridades en Procesos de Emergencia 11.0 Administración de Datos
47
11.1 Procedimientos de Preparación de Datos 11.2 Procedimientos de Autorización de Documentos Fuente 11.3 Recopilación de Datos de Documentos Fuente 11.4 Manejo de Errores de Documentos Fuente 11.5 Retención de Documentos Fuente 11.6 Procedimientos para la Autorización de Entrada de Datos 11.7 Chequeos de Exactitud, Suficiencia y Autorización 11.8 Manejo de Errores en la Entrada de Datos 11.9 Integridad de Procesamiento de Datos 11.10 Validación y Edición de Procesamiento de Datos 11.11 Manejo de Errores en el Procesamiento de Datos 11.12 Manejo y Retención de Datos de Salida 11.13 Distribución de Datos de Salida 11.14 Balanceo y Conciliación de Datos de Salida 11.15 Revisión de Salida de Datos y Manejo de Errores 11.16 Provisiones de Seguridad para Reportes de Salida 11.17 Protección de Información Sensitiva durante transmisión y transporte 11.18 Protección de Información Sensitiva a ser Desechada 11.19 Administración de Almacenamiento 11.20 Períodos de Retención y Términos de Almacenamiento 11.21 Sistema de Administración de la Librería de Medios 11.22 Responsabilidades de la Administración de la Librería de Medios 11.23 Respaldo y Restauración 11.24 Funciones de Respaldo 11.25 Almacenamiento de Respaldo 11.26 Archivo 11.27 Protección de Mensajes Sensitivos 11.28 Autenticación e Integridad 11.29 Integridad de Transacciones Electrónicas 11.30 Integridad Continua de Datos Almacenados 12.0 Administración de Instalaciones 12.1 Seguridad Física 12.2 Discreción (bajo perfil) de las Instalaciones de Tecnología de Información 12.3 Escolta de Visitantes 12.4 Salud y Seguridad del Personal 12.5 Protección contra Factores Ambientales 12.6 Suministro Ininterrumpido de Energía 13.0 Administración de Operaciones 13.1 Manual de Instrucciones y procedimientos de Operaciones de procesamiento 13.2 Documentación del Proceso de Inicio y de Otras Operaciones 13.3 Calendarización/programación de Trabajos 13.4 Ejecución de los Trabajos estándar programados 13.5 Continuidad de Procesamiento 13.6 Bitácoras de Operación 13.7 Protección de Formas Especiales y dispositivos de salida 13.8 Operaciones Remotas
48
I.2.D.d. 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 dominio también advierte a la Administración sobre la necesidad de asegurar procesos de control independientes, los cuales son provistos por auditorías internas y externas u obtenidas de fuentes alternativas”.14
Tabla VIII. Procesos y Objetivos de Control del Dominio M 1.0 Monitoreo del Proceso 1.1 Recolección de Datos de Monitoreo 1.2 Análisis del Desempeño 1.3 Evaluación de la Satisfacción de Clientes 1.4 Reportes Gerenciales 2.0 Evaluar lo adecuado del Control Interno 2.1 Monitoreo de Control Interno 2.2 Operación oportuna del Control Interno 2.3 Reporte sobre el Nivel de Control Interno 2.4 Seguridad en las operaciones y aseguramiento del Control Interno 3.0 Obtención de Aseguramiento Independiente 3.1 Certificación / Acreditación Independiente de Control Interno y Seguridad de los servicios de TI 3.2 Certificación / Acreditación Independiente de Control Interno y Seguridad de proveedores externos de servicios 3.3 Evaluación Independiente de la Efectividad de los Servicios de TI 3.4 Evaluación Independiente de la Efectividad de proveedores externos de servicios 3.5 Aseguramiento Independiente del Cumplimiento de leyes y requerimientos regulatorios y compromisos contractuales 3.6 Aseguramiento Independiente del Cumplimiento de leyes y requerimientos regulatorios y compromisos contractuales con proveedores externos de servicios 3.7 Competencia de la Función de Aseguramiento Independiente 3.8 Participación Proactiva de Auditoría 4.0 Proveer Auditoría Independiente 4.1 Estatutos de Auditoria 4.2 Independencia 4.3 Ética y Estándares Profesionales 4.4 Competencia 4.5 Planeación 4.6 Desempeño del Trabajo de Auditoria 4.7 Reporte 4.8 Actividades de Seguimiento
14 Ibidem.
49
I.2.E. Modelos de madurez de COBIT®
COBIT provee modelos de madurez para el control de los procesos de TI,
los cuales permitan a la administración ubicarse en el punto donde se encuentra la
organización actualmente, comparar donde está la organización en relación a las
mejores empresas de su clase y compararse contra los estándares internacionales
para que de esta manera pueda determinar hasta dónde quiere llegar la empresa.
Este modelo de madurez para la administración y control de los procesos
de TI, está basado en un mecanismo que permita que la empresa se evalúe a sí
misma en una escala de de 0 (no existente) hasta 5 (nivel optimizado).
Dicho modelo toma como base el modelo de madurez que utiliza el
Software Engineering Institute para evaluar la madurez de la capacidad de
desarrollo de software.
En la siguiente figura se muestra un método gráfico de presentación que
permite reflejar los resultados de manera más fácil en los resúmenes gerenciales:
50
Gráfica 3. Representación gráfica de los modelos de madurez 15
Mediante esta representación gráfica, se puede ubicar fácilmente el estado
que guarda la empresa en el momento de la evaluación e indicar en el mismo
gráfico donde se encuentra el promedio de industria, así como marcar el objetivo
al que se quiere llegar.
Cabe aclarar que aunque este gráfico NO se presenta en la versión 3.0 de
COBIT (que es la que se está usando para el proyecto) y se obtuvo de la versión
4.0, aplica de la misma manera para representar el grado de madurez en la
versión 3.0
Las mediciones son realizadas tomando como base el modelo genérico de
madurez que se muestra a continuación:
15 COBIT Objetivos de Control. IT Governance Institute. 3ra. Edición. USA 1996. p. 127.
51
Tabla IX. Modelo genérico de madurez 16 0 No existente. Hay una completa falta de cualquier proceso de gobierno de TI identificable. La organización no ha reconocido aun que hay aspectos que deben ser identificados y por lo tanto no hay comunicación al respecto. . 1 Inicial / Ad Hoc. Hay evidencia de que la organización ha reconocido que existen aspectos del gobierno de TI que deben ser considerados. Hay, sin embargo, procesos no estandarizados, pero en su lugar, hay procedimientos ad hoc aplicados sobre un caso individual o sobre bases de caso a caso. El enfoque Gerencial es caótico y hay una esporádica e inconsistente comunicación sobre aspectos y enfoques que deban ser considerados. Puede haber algún reconocimiento para utilizar el valor de TI en el desempeño orientado al resultado de los procesos relacionados de la empresa. No hay procesos de análisis estándar. El monitoreo de TI está implementado en una forma reactiva a incidentes que han causado algunas pérdidas o apuros a la organización. 2 Repetible pero intuitiva. Hay una conciencia global sobre los aspectos del gobierno de TI. Las actividades del gobierno de TI y los indicadores de desempeño están en desarrollo, incluyendo la planeación de TI y los procesos de entrega y monitoreo. Como parte de los esfuerzos, las actividades del gobierno de TI están formalmente establecidas dentro del proceso de administración del cambio con el involucramiento activo de la alta gerencia. Procesos seleccionados de TI son identificados para mejorar y/o controlar el núcleo de los procesos de la empresa, son efectivamente planeados y monitoreados como si fueran inversiones y son derivados en el contexto de un marco de referencia de la arquitectura de TI. La gerencia ha identificado los métodos y técnicas básicos de análisis y medición del gobierno de TI, sin embargo, el proceso no ha sido adoptado a través la organización. No hay entrenamiento y comunicación sobre los estándares de gobernabilidad y las responsabilidades son dejadas a los individuos. Los individuos direccionan los procesos de gobernabilidad como si no fueran procesos y proyectos de TI. Las herramientas de gobernabilidad son limitadas, escogidas e implementadas para lograr métricas de gobernabilidad pero puede que no se usen en toda su capacidad debido a la falta de experiencia en su funcionalidad. 3 Procesos Definidos. La necesidad de actuar con respecto al gobierno de TI es entendida y aceptada. Se desarrolla un grupo básico de indicadores de Gobierno de TI, donde el encadenamiento entre medidas de ingresos y controladores de desempeño es definido, documentado e integrado dentro de la planeación operacional y estratégica. Los procedimientos han sido estandarizados, documentados e implementados. La Gerencia ha comunicado los procedimientos estandarizados y se establece un entrenamiento informal. Los indicadores de desempeño sobre las actividades de gobernabilidad de TI son registrados y monitoreados generando mejoras a todo lo largo de la empresa. Aunque medidos, los procedimientos no son sofisticados pero son la formalización de prácticas existentes. Las herramientas están estandarizadas, utilizando técnicas disponibles y modernas. La idea de utilizar tarjetas de medición que balancean el negocio y TI son adoptadas por la organización. Esto, sin embargo, deja que el individuo, de acuerdo con su entrenamiento, siga y aplique los estándares. El análisis de causa efecto es ocasionalmente aplicado. La mayoría de los procesos son monitoreados sobre métricas (bases), pero cualquier desviación, debido a que generalmente se basa en las iniciativas de los individuos, probablemente no serían detectadas por la Gerencia. De todas maneras, el registro total del desempeño de los procesos claves es realizado y la gerencia es recompensada basada en mediciones clave de desempeño. 4 Administrado y medible. Hay un completo entendimiento de los aspectos de Gobierno de TI a todos los niveles de la organización, soportado por un entrenamiento formal. Hay un claro
16 Ibidem. p. 21.
52
entendimiento de quien es el cliente y sus responsabilidades están definidas y monitoreadas a través de acuerdos de nivel de servicio. Las responsabilidades son claras y el proceso de “propiedad” está establecido. Los procesos de TI están alineados con el negocio y con la estrategia de TI. El mejoramiento de los procesos de TI está basado primariamente sobre un entendimiento cuantitativo y por ello es posible monitorear y medir el cumplimiento con procesos y con métrica de procesos. Todos los responsables o propietarios de los procesos son advertidos sobre los riesgos, la importancia de TI y las oportunidades que TI puede ofrecer. La Gerencia ha definido una tolerancia bajo la cual los procesos deben operar. Se toman acciones en la mayoría, pero no en todos los casos, donde parece que los procesos no están operando efectiva o eficientemente. Los procesos se mejoran ocasionalmente y se refuerzan las mejores prácticas internas. Se estandariza el uso de análisis causa-efectos. Hay un limitado, primario y táctico uso de la tecnología, basado en técnicas de madurez y reforzado con herramientas estándar. Hay involucramiento de todos los expertos internos requeridos. El gobierno de TI involucra los procesos a todo lo ancho de la empresa. Las actividades del gobierno de TI están llegando a integrarse con los procesos de gobierno de la empresa. 5 Optimizado. En esta fase hay un entendimiento avanzado y hacia futuro de los aspectos y soluciones del gobierno de TI. El entrenamiento y las comunicaciones son soportadas por conceptos y técnicas de vanguardia. Los procesos han sido refinados a un nivel de mejores prácticas externas basadas sobre resultados de mejoramiento continuo y modelos de madurez con otras organizaciones. La implementación de esas políticas han permitido a la organización, a la gente y a los procesos que se adapten rápidamente y por completo a los requerimientos de gobierno de TI. Todos los problemas y desviaciones son analizados de raíz y con base en ese análisis se identifican e inician acciones eficientes y oportunas. La Tecnología de Información es utilizada de una manera extensiva y optimizada para automatizar el flujo de trabajo y proporcionar herramientas para mejorar la calidad y la efectividad. Los riesgos y el retorno de los procesos de TI son definidos, balanceados y comunicados a través de toda la empresa. Se aprovechan expertos externos y se utilizan benchmarks como guías. El monitoreo y el autoanálisis de riesgos y las comunicaciones acerca de las expectativas del gobierno influencian la organización y hay un óptimo uso de la tecnología para soportar la medición, el análisis, las comunicaciones y el entrenamiento. El gobierno de la empresa y el gobierno de TI están estratégicamente conectados empujando a los recursos humanos y financieros a incrementar la ventaja competitiva de la empresa.
La siguiente tabla lista los atributos y las características de administración
de los procesos de TI, al tiempo que describe la evolución desde un proceso no
existente (0) hasta uno optimizado (5). Dichos atributos pueden utilizarse para
realizar una evaluación más profunda y para realizar un análisis de las brechas
existentes entre la situación actual que guarda alguna organización y para
establecer los mecanismos de control necesarios para cerrar esas brechas.
53
Tabla X. Atributos de madurez 17 Conciencia y comunicación
Políticas, estándares y procedimientos
Herramientas y automatización
Habilidades y experiencia
Responsabilidad y rendición de cuentas
Establecimiento y medición de metas
1 Surge el reconocimiento de la necesidad del proceso Existe comunicación esporádica de los problemas.
Existen enfoques ad hoc hacia los procesos y las prácticas Los procesos y las prácticas no están definidos
Pueden existir algunas herramientas; el uso se basa en herramienta estándar de escritorio No existe un enfoque planeado para el uso de herramientas
No están definidas las habilidades requeridas para el proceso No existe un plan de entrenamiento y no hay entrenamiento formal
No existe definición de responsabilidades y de rendición de cuentas. Las personas toman la propiedad de los problemas con base en su propia iniciativa de manera reactiva.
Las metas no están claras y no existen las mediciones.
2 Existe conciencia de la necesidad de actuar La gerencia comunica los problemas generales
Surgen procesos similares y comunes pero en su mayoría son intuitivos y parten de la experiencia individual Algunos aspectos de los procesos son repetibles debido a la experiencia individual, y puede existir alguna documentación y entendimiento informal de las políticas y procedimientos
Existen enfoques comunes para el uso de herramientas pero se basan en soluciones desarrolladas por individuos clave. Pueden haberse adquirido herramientas de proveedores, pero probablemente no se aplican de forma correcta o incluso no usarse.
Se identifican los requerimientos mínimos de habilidades para áreas críticas Se da entrenamiento como respuesta a las necesidades, en lugar de hacerlo con base en un plan acordado. Existe entrenamiento informal sobre la marcha.
Un individuo asume su responsabilidad, y por lo general debe rendir cuentas aún si esto no está acordado de modo formal. Existe confusión acerca de la responsabilidad cuando ocurren problemas y una cultura de culpas tiende a existir.
Existen algunas metas; se establecen algunas mediciones financieras pero solo las conoce la alta dirección. Hay monitoreo inconsistente en áreas aisladas.
17 Ibidem. p. 23.
54
3 Existe el entendimiento de la necesidad de actuar La gerencia es más formal y estructurada en su comunicación
Surge el uso de buenas prácticas Los procesos, políticas y procedimientos están definidos y documentados para todas las actividades clave
Existe un plan para el uso y estandarización de las herramientas para automatizar el proceso Se usan herramientas por su propósito básico, pero pueden no estar de acuerdo al plan acordado, y pueden no estar integradas entre sí
Se definen y documentan los requerimientos y habilidades para todas las áreas. Existe un plan de entrenamiento formal pero todavía se basa en iniciativas individuales
La responsabilidad y la rendición de cuentas sobre los procesos están definidas y se han identificado a los propietarios de los procesos de negocio. Es poco probable que el propietario del proceso tenga la autoridad plena para ejercer las responsabilidades.
Se establecen algunas mediciones y metas de efectividad, pero no se comunican, y existe una relación clara con las metas del negocio. Surgen los procesos de medición pero no se aplican de modo consistente. Se adoptan ideas de un balanced scorecard de TI así como la aplicación intuitiva ocasional de análisis de causas raíz.
4 Hay entendimiento de los requerimientos completos Se aplican técnicas maduras de comunicación y se usan herramientas estándar de comunicación
El proceso es sólido y completo; se aplican las mejores prácticas internas. Todos los aspectos del proceso están documentados y son repetibles. La dirección ha terminado y aprobado las políticas. Se adoptan y siguen estándares para el desarrollo y mantenimiento de procesos y procedimientos.
Se implantan las herramientas de acuerdo a un plan estándar y algunas se han integrado con otras herramientas relacionadas Se usan herramientas en las principales áreas para automatizar la administración del proceso y monitorear las actividades y controles críticos
Los requerimientos de habilidades se actualizan rutinariamente para todas las áreas, se asegura la capacidad para todas las áreas críticas y se fomenta la certificación Se aplican técnicas maduras de entrenamiento de acuerdo al plan y se fomenta la compartición del conocimiento. Todos los expertos internos están involucrados y se evalúa la efectividad del plan de entrenamiento.
Las responsabilidades y la rendición de cuentas sobre los procesos están aceptadas y funcionan de modo que se permite al propietario del proceso descargar sus responsabilidades. Existe una cultura de recompensas que activa la acción positiva.
La eficiencia y la efectividad se miden y comunican y están ligadas a las metas del negocio y al plan estratégico de TI. Se implementa el balanced scorecard de TI en algunas áreas, con excepciones conocidas por la gerencia y se está estandarizando el análisis de causas raíz. Surge la mejora continua.
55
5 Existe un entendimiento avanzado y a futuro de los requerimientos Existe una comunicación proactiva de los problemas, basada en las tendencias, se aplican técnicas maduras de comunicación y se usan herramientas integradas de comunicación
Se aplican las mejores prácticas y estándares externos La documentación de procesos ha evolucionado a flujos de trabajo automatizados. Los procesos, las políticas y los procedimientos están estandarizados e integrados para permitir una administración y mejoras integrales
Se usan juegos de herramientas estandarizados a lo largo de la empresa. Las herramientas están completamente integradas con otras herramientas relacionadas para permitir un soporte integral de los procesos. Se usan las herramientas para dar soporte a la mejora del proceso y detectar de forma automática las excepciones de control
La organización fomenta de manera formal la mejora continua de las habilidades, con base en metas personales y organizacionales claramente definidas. El entrenamiento y la educación dan soporte a las mejores prácticas externas y al uso de conceptos y técnicas de vanguardia. La compartición del conocimiento es parte de la cultura empresarial y se implementan sistemas basados en conocimiento. Se usan a expertos externos y a líderes de la industria como guía.
Los propietarios de procesos tienen la facultad de tomar decisiones y medidas. La aceptación de la responsabilidad ha descendido en cascada a través de la organización de forma consistente.
Existe un sistema de medición de desempeño integrado que liga al desempeño de TI con las metas del negocio por la aplicación global del balanced scorecard de TI. La dirección nota las excepciones de forma global y consistente y el análisis de causas raíz se aplica. La mejora continua es una forma de vida.
56
I.3. LOS ESTÁNDARES ACEPTADOS
I.3.A. COSO
El informe COSO es un documento que establece una definición común de
un sistema de control interno y proporciona un estándar con el cual las
organizaciones pueden comparar y mejorar sus sistemas de control interno. Este
documento fue publicado en 1992 y desde entonces ha contado con una gran
aceptación que lo ha llevado a ser el estándar de referencia para el control interno.
El interés en este documento ha sido reavivado por las exigencias de la ley
Sarbanes-Oxley, ya que mediante la utilización de COSO (modelo de Gobierno
Corporativo) y la de COBIT (modelo de Gobierno de TI), entre otros, se logra la
conformidad con la ley Sarbanes-Oxley.
El objetivo de COSO es:
• Asegurar la calidad de la información financiera, haciendo énfasis en
el control interno y las normas éticas.
• Estandarizar criterios sobre las interpretaciones y conceptos
relacionados a control interno.
El informe COSO está conformado por dos secciones:
57
• Un resumen ejecutivo para la dirección, en el cual se explican de
manera general los principales conceptos del informe.
• El marco de referencia, en el cual se presentan en detalle los 5
elementos básicos del control interno que interactúan entre ellos y
están integrados en el proceso de dirección:
o Entorno de Control.
o Administración de los riesgos.
o Actividades de Control.
o Información y comunicación.
o Monitoreo.
El Informe COSO define el control interno como una forma de garantizar
que se cumplan los tres objetivos siguientes:
1. Eficacia y eficiencia de las operaciones
2. Fiabilidad de la información financiera
3. Cumplimiento de las leyes y normas que sean aplicables.
I.3.A.a. Entorno de control
Se refiere a la cultura organizacional de la empresa y la actitud y filosofía
de la dirección con respecto al control interno. Se consideran elementos como la
ética, la integridad de las personas, la capacidad de los empleados, la asignación
58
de autoridades y responsabilidades, el desarrollo de los empleados, entre otras.
I.3.A.b. Evaluación de los riesgos
Una vez que se han establecido los objetivos de la empresa, se deben
identificar y evaluar los riesgos relevantes que podrían impedir que se alcancen
dichos objetivos.
Los riesgos deben ser administrados tomando en cuenta que las empresas
se encuentran en un entorno dinámico y cambiante.
I.3.A.c. Actividades de control
Se refiere a todas aquellas medidas que ayudan a asegurar que las
operaciones se están realizando bajo un cierto nivel de control. Estas medidas
incluyen políticas y procedimientos y todos aquellos controles que son revisados
por una auditoría externa.
I.3.A.d. Información y comunicación
Se refiere a la difusión oportuna de la información necesaria para que todos
los niveles puedan cumplir con sus actividades y obligaciones, dicha información
debe ser identificada y ordenada antes de ser difundida. Se considera tanto la
59
información interna como la externa.
Se deben establecer los canales adecuados que aseguren que se lleve a
cabo una adecuada comunicación.
El personal debe estar informado sobre la relevancia que cobra su
participación en el esfuerzo de implementación del control interno.
I.3.A.e. Monitoreo
El sistema de control interno requiere de un proceso de monitoreo continuo
que permita verificar que está funcionando de manera adecuada, que permita
detectar desviaciones en el momento adecuado para establecer acciones
correctivas para regresar a los parámetros normales de funcionamiento.
Dicho monitoreo también brinda la ventaja de detectar áreas de mejora
como parte del proceso de mejora continua en el que se deben tener este tipo de
sistemas de control interno.
Aun y cuando la dirección de la empresa es la principal responsable del
control interno, cabe mencionar que todos los colaboradores de la organización
son responsables en mayor o menor medida del diseño, la implantación y correcto
funcionamiento del control interno.
60
I.3.B. ITIL (Information Technology Infrastructure Library)
La biblioteca de infraestructura de tecnologías de información, la cual fue
creada por la OGC (Office of Government Commerce).
Es una serie de libros que brindan un conjunto detallado de mejores
prácticas referentes a los procesos de administración y entrega de los servicios de
TI.
Los objetivos de ITIL son:
• Alinear y administrar eficientemente los servicios de TI de acuerdo a
las necesidades actuales y futuras de la empresa.
• Mejorar la calidad de los servicios de TI entregados a los clientes.
• Eficientar los costos que representa el proveer el servicio.
• Reducir los riesgos asociados a los servicios de TI.
• Agregar valor al negocio
En la versión 2.0 de ITIL se tienen 7 libros de los cuales 2 son los más
utilizados:
61
I.3.B.a. Soporte al Servicio
Soporte al Servicio contempla los siguientes Procesos:
• Mesa de Servicio
• Administración de Incidentes.
• Administración de Problemas.
• Administración de Cambios.
• Administración de Liberaciones.
• Administración de Configuraciones.
I.3.B.b. Entrega del Servicio
Entrega del servicio contempla los siguientes procesos:
• Administración del Nivel de Servicio.
• Administración de la Disponibilidad.
• Administración de la Capacidad.
• Administración financiera para servicios de TI.
• Administración de la Continuidad del Servicio de TI.
62
I.4 LA DIRECCIÓN DE TI DE LA EMPRESA
I.4.A. Breve reseña histórica
La Dirección de Tecnología de Información de La Empresa ha pasado por
varias transformaciones en su estructura, originalmente sólo se tenían
consideradas dos grandes áreas:
• Infraestructura.
• Desarrollo de Aplicaciones.
Con esta distribución, se coordinaba al personal de TI de las fábricas de
cerveza, compañías de servicio y fleteras.
A principios del 2000 se realizó una reestructuración corporativa mediante
la cual la dirección de TI empezó a coordinar también al personal de las agencias
distribuidoras.
Con el paso del tiempo, se han tenido diversas reestructuraciones tanto a
nivel corporativo como en la dirección de TI, mismas que se han dado buscando
una mayor eficiencia en la entrega de servicios y la administración de los recursos.
Obviamente que estas reestructuraciones y los constantes cambios en las
estrategias a nivel corporativo hicieron crecer de manera más que importante las
63
actividades que se desarrollaban en el corporativo, lo que dio lugar a la necesidad
de iniciar a implantar un esquema de control interno que permitiera una
administración adecuada de los recursos y servicios que se generan en la
dirección de TI.
I.4.B. Estructura Actual
Actualmente la dirección de tecnología de información depende de la
dirección de procesos y tecnología de información y está conformada por las áreas
de:
• Infraestructura.
• Proyectos y mantenimiento a Aplicaciones.
• Seguridad Informática.
• Gestión de TI.
En la dirección de TI se coordina desde el corporativo al personal de TI de
las diferentes UEN (Unidad Estratégica de Negocios) como lo son cervecerías,
agencias, compañías de servicio, fleteras y recientemente de las tiendas de
conveniencia, etc.
La coordinación de tal cantidad de personal y de recursos requiere que se
tenga una robusta plantilla de personal dentro de cada una de las áreas
mencionadas anteriormente.
64
La plantilla de personal de la dirección de TI está conformada por personal
interno (perteneciente a La Empresa) y personal externo, ya que para muchos
proyectos se contratan servicios en outsourcing y en otros casos se contrata al
personal a través de terceros.
La mayor parte de las actividades y personal de TI se encuentra
concentrada en el corporativo en la Cd. De México. D.F. y se tiene personal en las
UENs mencionadas anteriormente. Las cantidades de personal en cada una de
ellas depende de las actividades que se realicen; sin embargo, para agencias se
tiene una persona que atiende a la agencia y sus sub-agencias y en el caso de las
fábricas se tiene un poco más de personal.
I.4.C. Servicios de la dirección de TI
Actualmente los servicios que proporciona la dirección de TI se basan
principalmente en el desarrollo de soluciones de tecnología de información para el
negocio, dentro de estas soluciones se está considerando tanto a las aplicaciones
como la infraestructura y los servicios que soportan a las aplicaciones.
Adicionalmente se tienen servicios de administración de plataformas; es
decir, la creación de cuentas de usuario para red, correo, internet y demás
servicios habilitadores (aún y cuando estos servicios también soportan a las
aplicaciones, requieren de cierta interacción con el usuario).
65
Otro servicio que también requiere de interacción directa con el usuario es
la mesa de servicio, ya que es el único punto de contacto para la resolución de
incidentes y problemas relacionados con aplicaciones, servicios e infraestructura.
La entrega de equipo de cómputo es otro servicio habilitador que requiere
de una interacción directa con el usuario.
I.5. COBIT EN LA DIRECCIÓN DE TI DE LA EMPRESA
I.5.A. Orígenes del proyecto
Aun y cuando ya se había venido trabajando para establecer un sistema de
control interno en la dirección de TI, siempre se habían tenido varios esfuerzos
aislados que no fructificaron de manera adecuada, ya que los mismos se
realizaban por áreas sin involucrar al resto de las áreas de la dirección de TI.
Estos esfuerzos se veían minados también por el cambio de prioridades en
la dirección de TI, lo que provocaba que se abandonaran los esfuerzos antes de
ver los resultados palpables.
El detonante para la implementación del control interno mediante COBIT,
fue la probabilidad de que La Empresa se tuviera que certificar en la Ley
66
Sarbanes-Oxley, lo cual podría darse por alguna de las siguientes situaciones:
• Por el probable ingreso de La Empresa a cotizar en la bolsa de
valores estadounidense.
• Por la sociedad que se tiene con la compañía Anhausser-Bush, ya
que siendo una compañía estadounidense está obligada a apegarse
a la Ley SOx y cabría la posibilidad de que siendo socios se obligara
a La Empresa a apegarse a dicha Ley.
Visualizando el escenario descrito, La Empresa decidió empezar a
prepararse para una posible certificación en Sox, ya que a partir de que se notifica
a una empresa de que se debe apegar a Sox, solo tiene seis meses para
evidenciar que tiene un control interno adecuado que garantice la transparencia y
confiabilidad de la información financiera que se emite a la bolsa y al público en
general.
Como se comentó anteriormente, para la generación de un esquema de
control interno adecuado que cumpla los requerimientos de la ley Sox, se puede
tomar como base los marcos de referencia COSO y COBIT. COSO establece las
pautas para el gobierno corporativo (control interno corporativo) y COBIT
establece los lineamientos para el Gobierno de TI (control interno de TI).
Lo anterior se debe a que la ley Sox es muy general y sólo proporciona las
pautas de lo que se deberá hacer para tener un adecuado nivel de control interno
que garantice la transparencia de la información financiera. En este sentido,
67
COSO y COBIT son un poco más particulares aunque solo dicen el qué y no el
cómo, es por esto, que estos marcos de referencia se pueden complementar con
otros estándares que indican el cómo.
Por lo anteriormente descrito, para la parte del negocio se empezó a
implementar COSO y para la dirección de TI se inició con la implementación de
COBIT.
De acuerdo a los lineamientos establecidos por la Ley Sox, cuando se está
realizando la preparación para la certificación en dicha ley, es válido que las
empresas se asesoren con compañías de auditoría para que les ayuden a
detectar las brechas existentes en su control interno tomando como base los
requerimientos de Sox.
Tomando como base esa facilidad, se contrató a una empresa de auditoría
que apoyó a la dirección de TI de La Empresa a determinar cuáles controles de
COBIT deberían ser implementados y a detectar las brechas existentes entre el
control interno que se tenía contra el que se requería tener para cumplir con
COBIT y por ende con Sox.
I.5.B. Los controles a implementar
Una vez que se determinó cuales de los controles de COBIT se necesitaban
implementar en la dirección de TI y que fueron documentadas las brechas
68
existentes, éstos fueron asignados a las diferentes áreas de la dirección para que
se realizara el diseño de los documentos que cerrarían las brechas detectadas
entre la situación de la dirección de TI y los objetivos de control de COBIT.
En la siguiente tabla se muestran los Controles COBIT clasificados por el
área responsable del diseño y por el dominio COBIT correspondiente:
Tabla XI. Los controles a implementar en la Dirección de TI Área
Responsable Dominio COBIT Descripción del Control
Administración de Proveedores y Finanzas
DS
DS1.6 Elementos Sujetos a Cargos DS2.1 Interfaces con proveedores DS2.2 Relaciones con los propietarios (usuarios dueños) DS2.3 Contratos con terceros DS2.4 Calificaciones de terceros DS2.5 Contratos de Outsourcing DS2.6 Continuidad de servicios DS2.7 Relaciones con la seguridad DS2.8 Monitoreo
Calidad de Procesos
AI AI5.13 Evaluación del Cumplimiento de los Requerimientos del Usuario AI5.14 Revisión Gerencial Post – Implementación
DS
DS1.1 Marco de Referencia para el Acuerdo de Niveles de Servicio DS1.2 Aspectos Sobre los Acuerdos de Niveles de Servicios. DS1.3 Procedimiento de desempeño DS1.4 Monitoreo y Reporte DS1.5 Revisión de Acuerdos y Contratos de Nivel de Servicio DS1.7 Programa de Mejoramiento de Servicio
Comunicación y Formación TI AI AI5.1 Entrenamiento
AI5.3 Plan de implementación
Desarrollo AI
AI2.1 Métodos de Diseño AI2.10 Definición y Documentación de Requerimientos de Procesamiento AI2.11 Definición y Documentación de Requerimientos de Salida de Datos AI2.12 Controlabilidad AI2.13 Disponibilidad como Factor Clave de Diseño AI2.15 Pruebas de Software de Aplicación AI2.16 Materiales de Consulta y Soporte para Usuarios AI2.17 Reevaluación del Diseño del Sistema AI2.3 Aprobación del Diseño AI2.4 Definición y Documentación de Requerimientos de Archivos
69
AI2.5 Especificaciones de Programas AI2.6 Diseño para la Recopilación de Datos Fuente AI2.7 Definición y Documentación de Requerimientos de Entrada de Datos AI2.8 Definición de Interfaces AI2.9 Interfaz Usuario-Máquina AI4.1 Requerimientos Operacionales y Niveles de Servicio AI4.2 Manual de Procedimientos para Usuario AI4.4 Material de Entrenamiento AI5.10 Pruebas y Acreditación de Seguridad AI5.11 Prueba Operacional AI5.2 Medición del Desempeño del Software de Aplicación AI5.4 Conversión del Sistema AI5.5 Conversión de Datos AI5.6 Planes y estrategias de pruebas AI5.7 Pruebas a Cambios AI5.8 Criterios y Desempeño de Pruebas en Paralelo/PilotoAI5.9 Prueba de Aceptación Final
DS
DS11.11 Manejo de Errores en el Procesamiento de Datos DS11.14 Balanceo y Conciliación de Datos de Salida DS11.15 Revisión de Salida de Datos y Manejo de Errores DS11.6 Procedimientos para la autorización de entrada de
datos DS11.7 Chequeos de Exactitud, Suficiencia y Autorización DS11.8 Manejo de Errores en la Entrada de Dato DS11.9 Integridad de Procesamiento de Datos
Desarrollo/Mantenimiento AI
AI2.2 Cambios Significativos a Sistemas Actuales AI6.1 Inicio y Control de Solicitudes de Cambio AI6.2 Análisis de Impacto AI6.3 Control de Cambios AI6.4 Cambios de Emergencia AI6.5 Documentación y Procedimientos AI6.6 Mantenimiento Autorizado AI6.7 Política de Liberación de Software AI6.8 Distribución de Software
Infraestructura
AI
AI3.2 Mantenimiento Preventivo para Hardware AI3.3 Seguridad del Software del Sistema AI3.4 Instalación del Software del Sistema AI3.5 Mantenimiento del Software del Sistema AI3.6 Controles para cambios del software del sistema AI3.7 Uso y monitoreo de los utilitarios (utilities) del sistema AI4.3 Manual de Operaciones AI5.12 Paso o promoción a Producción (Separación de Ambiente de Pruebas y Desarrollo)
DS
DS10.1 Sistema de administración de problemas DS10.2 Escalamiento de Problemas. DS10.3 Seguimiento de problemas y pistas de auditoría DS10.4 Autorizaciones de Accesos temporales y de Emergencia DS11.12 Manejo y Relación de Datos de Salida DS11.19 Administración de Almacenamiento DS11.20 Períodos de Retención y Términos de Almacenamiento DS11.21 Sistema de Administración de la Librería de Medios
70
DS11.22 Responsabilidades de la Administración de la Librería de Medios DS11.23 Respaldo y Restauración DS11.24 Funciones de Respaldo DS11.25 Almacenamiento de Respaldo DS11.26 Archivo DS11.30 Integridad Continua de Datos Almacenados DS13.1 Manual de instrucciones y Procedimientos de operaciones de procesamiento DS13.2 Documentación del Proceso de Inicio y de Otras Operaciones DS13.3 Programación de trabajos DS13.4 Desviaciones de la programación de trabajos estándar DS13.5 Continuidad del procesamiento DS13.6 Bitácoras de operación DS13.7 Custodia de Formularios Especiales y de Dispositivos de Salida DS13.8 Operaciones remotas DS5.20 Arquitecturas de Firewalls y conexión a redes públicas DS5.21 Protección de valores DS5.4 Administración de Cuentas de Usuario DS5.9 Administración Centralizada de Identificación y Derechos de Acceso DS9.1 Registro de la Configuración DS9.2 Configuración Base DS9.3 Registro de Estatus DS9.4 Control de la Configuración DS9.6 Almacenamiento de Software DS9.7 Procesamientos administrativos de la ConfiguraciónDS9.8 Registro o contabilidad del software
Innovación y Arquitectura
AI AI2.14 Consideraciones de Integridad de TI para el Software de Programas de Aplicación AI3.1 Evaluación de Nuevo Hardware y Software
DS DS11.10 Validación y Edición de Procesamiento de Datos
Seguridad Informática DS
DS10.5 Prioridades de Procesamiento de Emergencia DS11.13 Distribución de Datos de salida DS11.16 Provisiones de Seguridad para Reportes de Salida DS11.17 Protección de Información Sensitiva durante transmisión y transporte DS11.18 Protección de Información Sensitiva a ser Desechada DS11.27 Protección de Mensajes Sensitivos DS11.28 Autenticación e Integridad DS11.29 Integridad de Transacciones Electrónicas DS5.1 Administrar medidas de Seguridad DS5.10 Reportes de Violación y Actividades de Seguridad DS5.11 Manejo de Incidentes DS5.12 Re-Acreditación DS5.13 Confianza en las contrapartes DS5.14 Autorización de Transacciones. DS5.15 No Rechazo DS5.16 Sendero Seguro DS5.17 Protección de las Funciones de Seguridad
71
DS5.18 Administración de las Llaves Criptográficas DS5.19 Prevención, Detección y Corrección de Software NO autorizado DS5.2 Identificación, Autentificación y Acceso DS5.3 Seguridad de Acceso a Datos en Línea DS5.5 Revisión General de Cuentas de Usuario DS5.6 Control de Usuarios sobre Cuentas de Usuario DS5.7 Vigilancia de Seguridad DS5.8 Clasificación de Datos DS9.5 Software NO autorizado
I.5.C. Roles y responsabilidades
Para la implementación de COBIT en la dirección de TI de La Empresa, se
establecieron los siguientes roles:
Consultoría:
Empresa de auditoría que fue contratada para llevar a cabo las siguientes
actividades:
1.- Determinar los controles de COBIT que se debían implantar en la
dirección de TI de La Empresa.
2.- Realizar el análisis para detectar las brechas existentes entre la
situación de La Empresa contra los objetivos de control de COBIT.
3.- Realizar las pruebas del diseño de los controles de COBIT, para
asegurar que dichos controles fueron diseñados en apego a los objetivos de
control.
4.- Realizar las pruebas de ejecución (efectividad) para asegurar que lo que
72
se había establecido en los controles (políticas, procesos, procedimientos,
formatos, etc,) se estaba ejecutando adecuadamente.
Auditoría de QA:
Empresa de auditoría encargada de validar que las pruebas realizadas por
la consultoría se hayan realizado en apego a los controles y a los estándares de
auditoría establecidos.
Dueños de los Controles:
Los cuales son los responsables del diseño de los controles, tomando en
cuenta las brechas detectadas por la consultoría y estableciendo y documentando
la forma de cerrar las mismas para asegurar que el objetivo de control se
cumpliera.
Responsable también de implantar los controles; es decir, gestionar que las
actividades que se documentaron en políticas, procesos, procedimientos, etc., se
estén ejecutando de manera adecuada, con apego a lo establecido y generando la
evidencia correspondiente.
Calidad de Procesos:
Responsable de realizar la gestión del proyecto de control interno (Sox-
73
COBIT) a través de las siguientes actividades:
• Gestión del plan de trabajo del proyecto en general y de las
remediaciones particulares de los controles.
• Programar y gestionar las revisiones de diseño y efectividad de los
controles.
• Llevar el control de la información generada por el proyecto y de la
actualización del indicador de desempeño del proyecto.
• Administrar la documentación generada por las diferentes áreas para
su oficialización y custodia.
• Gestionar las mejoras a la documentación vigente.
Operadores y Colaboradores de la Dirección de TI:
Responsables de poner en práctica los controles, ya que aún y cuando se
tienen responsables puntuales del diseño e implementación de los controles, la
responsabilidad de ejecutarlos, seguirlos y mantenerlos es de todos los
colaboradores de la dirección de TI.
74
CAPITULO II
DESARROLLO DE LA INVESTIGACIÓN
II.1. ANÁLISIS DE LA SITUACIÓN ACTUAL
Para la realización del presente trabajo de investigación se optó por realizar
una serie de entrevistas entre los directivos de TI con la finalidad de obtener
información referente a la percepción de los mismos acerca del proyecto de
implantación de controles COBIT en la dirección de TI.
Originalmente los datos de la entrevista se estuvieron capturando en una
hoja de Microsoft Excel a manera de concentrarlos en un solo lugar para que se
facilitara la tarea del análisis de la información obtenida.
Posteriormente con la información cualitativa de las entrevistas, se realizó
un análisis e interpretación de la misma y se realizó una tabla en Microsoft Excel
para poder transformar esa información cualitativa en parámetros cuantitativos de
frecuencias que nos permitieran visualizar de manera estadística las opiniones de
los entrevistados.
Dicha representación cuantitativa se realizó tomando en cuenta las
diferentes áreas en las que se dividió la entrevista y que podremos apreciar a en la
sección posterior.
75
Para realizar la representación gráfica de los resultados obtenidos, se utilizó
el software SPSS for Windows Ver 12.0.
II.1.A. Formato de entrevista
Tabla XII. Formato de entrevista Entrevista sobre la implementación de Controles COBIT (Activity Level)
Pregunta SI/NO ComentarioComunicaciónComo se dio a conocer su participación en el diseño y/o implantación de los controles Sox (COBIT)Como se dan a conocer los cambios en los controles Sox?.Como se comunican las responsabilidades del personal a su cargo respecto a los contoles Sox (COBIT).DiseñoConsidera que el diseño de los controles ha sido el adecuado?En el diseño de los controles se involucró a todos los niveles de la estructura?.Lo que está documentado corresponde a lo que realmente se ejecuta?.ImplantaciónComo se valida en el área el cumplimiento hacia los controles Sox?.La estructura organizacional actual es suficiente para llevar a cabo lo establecido por los controles Sox?.Cual es la principal complicación para que los controles sean llevados de manera correcta?.EstrategiaEl apoyo de la Dirección de TI ha sido el suficiente para la implantación de los controles Sox?.Actitud / PercepciónComo percibe el personal su participación hacia los Controles Sox?.El personal está conciente y acepta sus responsabilidades hacia los Controles Sox?.Comentarios
Comentarios Adicionales
Este es el formato que se utilizó en la entrevista que fue aplicada a la
primera línea de reporte de la dirección de TI de LA EMPRESA.
76
Con esta entrevista se buscó obtener información relevante sobre la
percepción que tienen los directores, gerentes y coordinadores acerca del
proyecto de implementación de los controles COBIT.
El formato de entrevista está dividido en 5 secciones, mismas que se
describen a continuación:
Comunicación:
En esta sección se pretende detectar la efectividad que se ha tenido en la
comunicación del proyecto desde sus inicios hasta la actualidad y ver cuáles son
los principales obstáculos que se han tenido en este aspecto.
Diseño:
Con esta sección se busca obtener retroalimentación de parte de los
encuestados sobre el diseño de los controles; detectar si desde su punto de vista
los controles reflejan la realidad de la operación, lo que permitiría que la
implementación de los controles fuera mucho más sencilla.
Implantación:
Esta sección fue diseñada para obtener información acerca del estado
actual de la implantación de los controles, saber si actualmente se está
77
monitoreando el cumplimiento de los mismos, si la estructura organizacional actual
es la adecuada para trabajar con el nivel de control que se requiere y determinar
cuáles son los principales obstáculos que se han visualizado para la correcta
implantación de los controles.
Estrategia:
En el apartado de estrategia, básicamente se busca determinar si se ha
tenido el suficiente apoyo por parte de la dirección de TI para el logro de la
implementación de los controles COBIT.
Actitud / Percepción:
Finalmente, con la sección de actitud / percepción se busca obtener
información sobre la percepción que tiene el personal de TI y si se aceptan las
responsabilidades que conlleva trabajar bajo el nivel de control que se requiere y
que se está buscando con la implantación de los mismos.
78
II.1.B. Análisis de datos e interpretación de resultados
Tabla XIII. Población Entrevistada
Puesto
3 27.3 27.3 27.35 45.5 45.5 72.73 27.3 27.3 100.0
11 100.0 100.0
DirectorGerenteCoordinadorTotal
ValidFrequency Percent Valid Percent
CumulativePercent
Gráfica 4. Población Entrevistada
En la gráfica se puede observar la población a la que se entrevistó. Ésta
población corresponde a la primera línea de reporte de la dirección de TI.
79
II.1.B.a. Comunicación
Tabla XIV. Percepción sobre la Comunicación
Comunicación
11 100.0 100.0 100.0No EfectivaValidFrequency Percent Valid Percent
CumulativePercent
Gráfica 5. Percepción sobre la comunicación del proyecto
En la gráfica se puede apreciar que el 100% del personal encuestado
coincide en que la comunicación del proyecto no ha sido efectiva. Entendiendo
como comunicación efectiva aquella mediante la cual se ha dado a conocer de
manera satisfactoria los objetivos del proyecto, los cambios en los controles y la
80
comunicación de las responsabilidades en todos los niveles de la estructura
organizacional de TI.
II.1.B.b. Diseño de los Controles
Tabla XV. Percepción sobre el diseño de los controles
Diseño de los Controles
7 63.6 63.6 63.64 36.4 36.4 100.0
11 100.0 100.0
InadecuadoAdecuadoTotal
ValidFrequency Percent Valid Percent
CumulativePercent
Gráfica 6. Percepción sobre el diseño de los controles
81
En esta gráfica se puede observar que el 63.6% de los entrevistados
consideran que el diseño de los controles no es el adecuado. Un diseño adecuado
significa que el control se apega a la realidad operativa pero guardando siempre el
factor de control requerido por COBIT. Un diseño adecuado facilita la implantación
del control y ayuda a que el cumplimiento del mismo sea más sencillo, lo que
favorece al éxito del control.
II.1.B.c. Implementación
Tabla XVI. Validación del cumplimiento de los controles
Validación del Cumplimiento
8 72.7 72.7 72.73 27.3 27.3 100.0
11 100.0 100.0
No se realizaSe realizaTotal
ValidFrequency Percent Valid Percent
CumulativePercent
82
Gráfica 7. Percepción sobre la validación del cumplimiento de los controles
En esta gráfica se puede observar que el 72.7% de los entrevistados hizo
saber que actualmente no se realiza una validación del cumplimiento de los
controles COBIT que ayude a garantizar la implantación adecuada de los mismos.
En este sentido se debe entender como validación del cumplimento a una
serie de actividades de revisión/verificación de que los controles se están
cumpliendo en cada una de las áreas de la dirección de TI de manera adecuada y
que se está generando la evidencia necesaria que soporte dicho cumplimiento.
83
II.1.B.d. Estructura Organizacional
Tabla XVII. Percepción sobre la estructura organizacional de TI
Estructura Organizacional
3 27.3 27.3 27.38 72.7 72.7 100.0
11 100.0 100.0
InadecuadoAdecuadoTotal
ValidFrequency Percent Valid Percent
CumulativePercent
Gráfica 8. Percepción sobre la estructura organizacional de TI
En esta gráfica se puede observar que el 72.7% de la población
entrevistada considera que la estructura organizacional actual de la dirección de TI
84
es la adecuada para la operación de los controles COBIT
Se entiende como estructura organizacional adecuada a los recursos
humanos que se encuentran distribuidos en las diferentes áreas de TI y que son
suficientes y adecuados para llevar a cabo las actividades del día a día (operación
normal) bajo un ambiente de control requerido por los controles COBIT.
II.1.B.e. Apoyo de la Dirección
Tabla XVIII. Percepción sobre el apoyo de la dirección
Apoyo de la Dirección
6 54.5 54.5 54.55 45.5 45.5 100.0
11 100.0 100.0
InsuficienteSuficienteTotal
ValidFrequency Percent Valid Percent
CumulativePercent
85
Gráfica 9. Percepción sobre el apoyo de la dirección
En esta gráfica se puede ver que la percepción sobre el apoyo que la
dirección de TI ha brindado al proyecto se encuentra muy dividida entre los
entrevistados. Mientras que el 54.55% opina que el apoyo ha sido insuficiente, el
resto opina lo contrario, esta diferencia la hace la opinión de una persona.
Se debe entender como apoyo de la dirección a las actividades que la
misma ha realizado para que el proyecto sea exitoso; es decir, que la dirección
haya tomado medidas para garantizar el cumplimiento de los controles, así como
86
que ha proporcionado los recursos suficientes y necesarios para la adecuada
implementación de los mismos.
II.1.B.f. Percepción de los Controles
Tabla XIX. Percepción sobre cómo se visualizan los controles
Visualización de los Controles
7 63.6 63.6 63.64 36.4 36.4 100.0
11 100.0 100.0
Carga AdicionalApoyoTotal
ValidFrequency Percent Valid Percent
CumulativePercent
Gráfica 10. Percepción sobre cómo se visualizan los controles
87
Esta gráfica es muy interesante y muestra como el 63.6% de los
entrevistados percibe que el personal a su cargo considera que los controles
COBIT son una carga adicional a su trabajo, más que como un apoyo para que el
trabajo que ejecutan día a día sea mejor y les ayuden a ser más eficientes y tener
un mejor control sobre las actividades que realizan.
II.1.B.g. Grado de Conciencia del Personal
Tabla XX. Grado de conciencia del personal de TI sobre los controles
Personal Conciente
4 36.4 36.4 36.47 63.6 63.6 100.0
11 100.0 100.0
No ConcienteCocienteTotal
ValidFrequency Percent Valid Percent
CumulativePercent
88
Gráfica 11. Grado de conciencia del personal de TI sobre los controles
En este caso se aprecia que el 63.6% de los entrevistados opina que el
personal a su cargo es consciente de la importancia de llevar a cabo las
operaciones bajo un nivel adecuado de control; mientras que el resto aún no
comprende la finalidad de realizar sus actividades bajo control y menos aún que
acepten sus responsabilidades para realizar sus actividades bajo este marco de
control que se busca implementar.
89
II.1.C. Explicación de la situación actual
De acuerdo a las entrevistas realizadas al personal anteriormente descrito,
a continuación se describe la situación actual de la implantación de los controles
COBIT en la dirección de TI.
La situación actual también fue dividida en las mismas áreas que se han
venido manejando a lo largo del Capítulo II para una mejor clasificación de las
brechas detectadas.
Cabe hacer mención que todas las opiniones levantadas fueron analizadas
de manera individual y posteriormente en su conjunto; todas aquellas que carecían
de un sustento y que parecían más excusa que problema, no fueron tomadas en
cuenta para NO sesgar el resultado de la investigación.
II.1.C.a. Comunicación
Una de los datos más relevantes obtenidos durante las entrevistas, es que
casi la totalidad del personal entrevistado coincide en que nunca se dio a conocer
el alcance completo del proyecto, los objetivos y los beneficios del mismo.
Esto provocó una falta de visión de lo que se deseaba lograr con el
proyecto, por lo que al carecer de un objetivo claro, el personal no podía aportar
sus ideas para la adecuada implementación de los objetivos de control.
90
Aún cuando al inicio del proyecto se realizó una serie de reuniones con las
personas que estarían involucradas en el diseño de los controles, procesos y
procedimientos, no se realizó una concientización general sobre el proyecto. Se
asumió que todo el personal sabía de lo que se trataba el proyecto y sobre
términos desconocidos para el personal de TI, tal es el caso de SOx, ITIL, COBIT,
etc.
Sólo algunas personas que tenían conocimiento sobre esos temas
entendían bien los conceptos y lo que se pretendía lograr con la implantación de
los controles; mientras que la gran mayoría desconocía por completo el tema. Esto
provocó que en la mayoría de las personas no se supiera que era lo que
aportaban al hacer las cosas del día a día bajo un entorno de control, por lo que al
final de cuentas se percibía como una carga adicional que no les daba ningún
valor a la manera en la que venían operando durante mucho tiempo.
Durante el transcurso del proyecto no fueron dados a conocer los procesos,
los mapas de procesos y la interrelación entre los mismos. Dado que nadie sabía
cómo participaba dentro de los procesos, nunca se tuvo visibilidad de cómo
impactaba el que algún colaborador dejara de hacer lo que estaba establecido en
los controles.
Una vez que se inició con el proyecto, sólo se involucró a muy pocas
personas de muy alto nivel (en la estructura organizacional); se tuvieron muchos
91
problemas para que dichas personas permearan la información hacia sus
colaboradores, por lo que muchos de ellos se vieron en la necesidad de buscar
otras alternativas para obtener la información clave sobre el proyecto y muchos
más se quedaron al margen esperando que la información les fuera entregada a
manera de instrucción para seguirlo como se debería.
Actualmente los colaboradores no tienen claro cuáles son los controles y la
documentación que deben conocer y dominar para cada puesto. Esto ha resultado
complicado para ellos, ya que no saben cuál es la totalidad de controles que se
deben seguir y cuáles son las evidencias que se deberían estar generando como
parte del soporte a los controles.
Todos los controles y la documentación que los soporta están sujetos a un
proceso de mejora continua; como parte de dicho proceso, se van teniendo una
serie de adecuaciones necesarias para que los controles se mantengan vigentes.
Cuando se realizan dichas adecuaciones, se envía un comunicado a todo el
personal de TI informando que determinado control ha cambiado y aún cuando en
dicho comunicado se resaltan los principales cambios en el control, esta
comunicación no está siendo efectiva.
Se ha detectado que cuando se envían dichos comunicados por correo
electrónico, la mayoría de los colaboradores los omiten o no los leen con
detenimiento; lo que provoca que los cambios no sean asimilados y entendidos
por el personal involucrado. Lo anterior trae consigo que el personal nunca
92
conozca los principales cambios que se van generando en cada proceso y por
ende, que siempre se estén queriendo seguir los controles como originalmente se
tenían definidos, por lo que al final de cuentas se cae en re-trabajos al tener que
adaptar lo que ya se había hecho hacia las nuevas formas de trabajo o nuevos
formatos.
II.1.C.b. Diseño
Referente al diseño de los controles, el personal percibe que durante el
diseño de dichos controles no se involucró a todo el personal que conocía los
detalles finos de la operación. Al carecer de esta visibilidad de la operación fina, se
desarrollaron controles que son difíciles de llevar porque significan una actividad
adicional a la de la operación diaria; de hecho, los controles no son visualizados
como parte de la operación y como actualmente la mayoría del personal está
demasiado ocupado con la operación, dejan de lado todo aquello que es ajeno a la
misma.
Como parte de esa falta de involucramiento del personal clave, los diseños
de los controles fueron realizados a muy alto nivel y de manera compleja, por lo
que resultan difíciles de entender y muchas veces de operar por parte del personal
que los debe llevar a cabo en el día a día.
Actualmente el personal ha detectado que muchos de los documentos
tienen áreas de mejora que se pueden corregir y simplificar. Como se comentó en
93
párrafos anteriores, estos controles están sujetos a un proceso de mejora continua
y adicionalmente, en la dirección de TI se han tenido muchos cambios que han
impactado también la manera de operar y por ende, se tienen desviaciones de los
controles que fueron diseñados originalmente contra la situación actual de la
dirección de TI.
II.1.C.c. Implantación
Existen varios factores que no han permitido una adecuada implantación de
los controles, uno de ellos es el diseño de los controles, lo cual ya fue comentado
en párrafos anteriores por lo que ya no se tocará en este punto.
Debido a que no se logra tener aún el compromiso pleno de parte de todas
las áreas de la dirección de TI, actualmente no se está llevando a cabo una
validación del cumplimiento de los controles por parte de las mismas.
Si bien, existe un área que es encargada de realizar las revisiones de
apego a procesos, es necesario que cada área esté validando que los controles
que debe cumplir sean llevados tal y como se tiene documentado.
En algunos casos para cumplir con los controles, algunas áreas han
solicitado a sus colaboradores que se generen evidencias de las actividades
aunque no sea en los formatos oficiales que se han definido para cada caso. Esto
es debido a la supuesta complejidad que existe para el llenado de los formatos
94
que se tienen definidos; sin embargo, esta es una de las principales excusas que
se han manifestado desde el principio del proyecto. Si bien existe alguna
complejidad para el llenado de los formatos, la falta de cumplimiento ha sido más
bien consecuencia de que aún no se consigue planificar los proyectos tomando en
cuenta que todos ellos requieren de cierta documentación (evidencia) que es
necesario generar para comprobar el cumplimiento de los controles.
En el caso de las áreas de desarrollo de sistemas, se ha visualizado que los
usuarios por parte del negocio son ajenos al proyecto de control interno y de
cumplimiento a la Ley SOX, por lo que no comprenden que los controles que se
están implantando van a permitir a la dirección de TI entregar productos y
servicios de mejor calidad.
Lejos de tener un apoyo por parte de los usuarios, se tienen mayores
presiones debido a que para cada usuario su aplicación es la más importante y
tratan de recortarle tiempo a los proyectos sin tomar en cuenta que durante el
proyecto se está considerando la generación de la documentación necesaria para
el cumplimiento de los controles que se tienen definidos.
Algunas de las áreas que se están proponiendo trabajar bajo los esquemas
de control establecidos, son visualizadas por el resto de las áreas como
obstáculos y no como áreas que están tratando de generar valor al llevar al pie de
la letra los controles establecidos.
95
Se percibe también que la estructura organizacional de la dirección de TI no
es la adecuada para la correcta implementación de los controles, ya que en
muchos de los casos, la postura de las áreas es rígida para responder a los
cambios que se han tenido en la dirección de TI.
II.1.C.d. Apoyo por parte de la dirección de TI
En cuestión de apoyo por parte de la dirección de TI, se considera que este
no ha sido el suficiente para garantizar que los controles sean implantados de la
manera adecuada. Esto ha sido en parte debido a los diferentes cambios que se
han tenido en la estrategia de la dirección de TI, lo que ha obligado a asignar
prioridades menores a este proyecto que a otros que se van presentando y que
tienen “una mayor urgencia” que la implantación de los controles.
Debido a la reciente incorporación de la dirección de TI hacia la dirección de
procesos y tecnología de información, actualmente se están unificando los criterios
con los que se deberá operar en la dirección de TI.
II.1.C.e. Percepción de los controles por parte del personal de TI
Actualmente el personal de la dirección de TI percibe los controles como
algo tedioso y adicional al trabajo, esto es debido a los siguientes factores:
96
• El personal se encuentra demasiado involucrado en la operación del
día a día.
• Se ha trabajado de la misma forma (sin control) durante mucho
tiempo, por lo que ahora se tiene un problema de resistencia al
cambio.
• En algunos casos no se tiene un diseño del todo adecuado en los
controles.
En la mayoría de los casos, el personal tiene claro que se deben cumplir los
controles de manera adecuada pero les cuesta trabajo adaptarse a este esquema
de trabajo bajo control.
II.1.C.f. Principales obstáculos para la implantación de los controles
A manera de resumen, se pueden listar los principales obstáculos
detectados para la adecuada implantación de los controles:
• Falta de comunicación del objetivo, beneficios y alcance.
• Cambio en las prioridades por parte de la Dirección de TI.
• No se tiene la convicción de los beneficios que tiene trabajar bajo
control.
• El Control Interno NO se ha adoptado como necesario.
• Resistencia al cambio.
97
• El medio ambiente de urgencia de los usuarios del negocio, lo cual
no permite que los proyectos sean programados con los tiempos
adecuados para la generación de los controles.
II.2. ANÁLISIS DE LA SITUACIÓN DESEADA
Como en todo proyecto de apego a normativas, es de suma importancia
que el cumplimiento de los controles que soportan a dichas normativas se lleve a
cabo de manera estricta para garantizar que las actividades que se realizan se
hacen de la misma manera siempre y bajo los requerimientos de control
estipulados por la normativa.
Por lo anteriormente descrito, la situación deseada es la siguiente:
Diseño de los controles lo más acercado posible a la realidad operativa para
que el cumplimiento de los mismos sea más fácil de lograr.
Es necesaria una comunicación efectiva que garantice que los objetivos, las
implicaciones y las consecuencias de la falta de cumplimiento a los controles son
comprendidos por todos los colaboradores de la dirección de TI.
Se requiere un apoyo suficiente de la dirección de TI para que se obligue al
personal al cumplimento de los controles, ya que este tipo de proyectos no son
98
cuestión de voluntad y buenos deseos; por el contrario, aún y cuando no se esté
muy de acuerdo con ellos, se deberán cumplir al pie de la letra.
Es de suma importancia el compromiso por parte de todos los
colaboradores de la dirección de TI para el cumplimiento de los controles, ya que
todos intervienen en el cumplimiento de una u otra manera; por lo tanto, a medida
que el personal se comprometa con el cumplimiento, será mayor el grado de éxito
que se tenga en el cumplimiento a las normativas.
II.3. PROPUESTA DE MEJORA O SOLUCIÓN
Como se mencionó anteriormente, las resultados de las entrevistas fueron
analizados de manera individual y en su conjunto para tener una mejor visibilidad
de las brechas existentes entre la situación actual de TI y lo que representa la
situación deseada.
Con base en lo anterior, se emitieron recomendaciones de mejora para
cada una de las observaciones que se consideraron que estaban bien
fundamentadas y que no evidenciaban algún tipo de excusa por parte del personal
de TI.
Adicionalmente, en estas propuestas de mejora se incluyen aquellos puntos
que se ha observado que tienen oportunidades de mejora desde la perspectiva del
99
área de Calidad de Procesos, quien es el área responsable de la coordinación del
proyecto de implantación de los controles COBIT.
II.3.A. Comunicación
Una de las principales áreas que tienen oportunidades de mejora es la de
comunicación en todos los sentidos del proyecto, para cubrir las brechas
detectadas en cuanto a la comunicación se emitieron las siguientes
recomendaciones que tienen la finalidad de lograr una comunicación efectiva
durante el proyecto, ya que el cumplimiento a los controles COBIT no son un
proyecto momentáneo que en algún tiempo se vaya a dejar de cumplir, por el
contrario, es una cultura que llegó para quedarse dentro de la dirección de TI
Curso de concientización sobre el cumplimento de los controles:
Para asegurar que todo el personal de la dirección de TI tiene el
conocimiento necesario sobre el alcance del proyecto, los objetivos y beneficios
del mismo, se considera necesario realizar un curso de concientización sobre el
cumplimiento de los controles, el cual deberá contener los siguientes temas:
• La Ley SOx para La Empresa.- Donde se explique el porqué La Empresa
está buscando cumplir con dicha Ley.
• Los marcos de referencia.- Donde se describan los diferentes marcos de
100
referencia que se utilizan para el cumplimiento de la ley Sox y su aplicación
en la dirección de TI (COSO, COBIT, ITIL, etc.)
• Los controles COBIT.- En el cual se exponga la relación existente entre los
controles de COBIT y el cumplimiento con la ley Sox.
• Objetivos y alcance del proyecto de cumplimiento a los controles COBIT.-
Donde se explique a detalle lo que se espera del proyecto y como cada
área participa en él.
Este curso de concientización se realizará a manera de e-learning de
certificación; es decir, que será de carácter obligatorio para el personal de la
dirección de TI y se deberá presentar una evaluación que el personal deberá
aprobar con un mínimo de 80%.
En caso de que alguien no apruebe la evaluación en dos oportunidades,
deberá tomar nuevamente el curso de concientización.
Para la elaboración de este curso, se buscará el apoyo de Tecnología
Educativa de La Empresa y en caso de que no sea posible el apoyo, se contratará
un proveedor para que sea desarrollado con base en material preparado
previamente por la dirección de TI.
Generar y difundir los mapas de procesos y sus interrelaciones:
101
Con la finalidad de que cada colaborador identifique los procesos en los que
participa y como impacta en los demás el que él deje de hacer las cosas, es
necesario generar los mapas de los procesos individuales y su interrelación con el
resto de los procesos (mapa general de procesos).
Los mapas de procesos incluirán los siguientes datos:
• Responsables del proceso.
• Principales clientes y proveedores.
• Principales entradas y salidas.
• Las interrelaciones con el resto de los procesos.
Una vez que se hayan generado dichos mapas, será necesario realizar
sesiones de retroalimentación con los participantes de cada proceso. En estas
sesiones se explicarán cada uno de los procesos y de manera general el mapa
general de procesos.
Generar y difundir el registro de documentos que aplican por persona:
Para ayudar al personal a conocer cuáles son los controles puntuales que
deberá cumplir y los documentos que deberá conocer, se generará un registro de
102
los documentos que aplican por persona.
En este registro se reflejará a manera de tabla, aquellos documentos en los
cuales se mencione la participación de un rol en específico, o bien, las
responsabilidades que se tienen en cada uno de los documentos.
Dentro de los documentos que se mencionarán en dicho registro se
encuentran:
• Mapas de procesos.
• Procesos.
• Procedimientos
• Formatos
• Registros
• Estándares
• Mejores prácticas
• Guías
• Otros documentos (documentos diferentes a los anteriores pero que
será necesario que se conozcan).
Este registro será seccionado por área y en cada una de ellas se tendrá a
todos los integrantes de la misma y los documentos que deberá conocer cada uno
de ellos.
103
Sesiones de retroalimentación sobre los cambios a documentos:
Para asegurar que los cambios a los documentos son comprendidos por
todos los involucrados, ahora en lugar de generar un comunicado dando a conocer
los cambios a los documentos, se generarán sesiones de retroalimentación, en las
cuales se explique de manera detallada los cambios en dichos documentos a
todos los involucrados en ellos. Estas sesiones se realizarán de manera presencial
en un aula.
Envío de comunicados confirmando las decisiones importantes sobre
el proyecto:
Para evitar que se interpreten de manera diferente los lineamientos o
acuerdos que se tomen sobre el proyecto y que por ende, se den indicaciones
diferentes a las originales a las áreas de la dirección de TI, cada vez que se llegue
a algún acuerdo sobre el proyecto, estos deberán ser comunicados a través de
comunicación interna de TI a todos los involucrados en el proyecto.
Asimismo, se deberá utilizar a comunicación interna para dar a conocer de
manera periódica el estatus del proyecto, avances y compromisos.
Comunicar al negocio el proyecto que se está llevando dentro de la
dirección de TI:
104
Para lograr la sensibilidad del usuario del negocio sobre el esfuerzo que
está realizando la dirección de TI para la implantación de un esquema de control
interno adecuado, se emitirá un comunicado dirigido a todos los usuarios de TI, en
el cual se dé a conocer de manera general:
• Por qué TI está implantando controles.
• El objetivo de los controles.
• La participación del usuario en este proceso de implantación de los
controles.
• La participación del usuario una vez que se concluya la
implantación.
Este comunicado se enviará a través de comunicación interna de La
Empresa.
Evaluaciones de conocimiento de Control Interno:
Para asegurar que el personal de la dirección de TI tiene los conocimientos
suficientes acerca del proyecto, será necesario realizar evaluaciones de
conocimiento periódicas, estas evaluaciones se realizarán durante las
evaluaciones de efectividad de los controles, mismas que se tienen contempladas
realizar cada seis meses.
105
II.3.B. Diseño
Referente al diseño de los controles, estos se encuentran en un proceso de
mejora continua, por lo que en este sentido, lo que se hace y se seguirá
promoviendo es mejorarlos de acuerdo a las observaciones del personal que haga
uso de los mismos y de la propia área de calidad de procesos.
Cabe mencionar que siempre que exista algún cambio en las condiciones
de la dirección de TI, se deberán realizar reuniones para determinar el impacto de
dichos cambios sobre los controles que se tengan implementados en ese
momento.
Actualmente la validación de la efectividad del diseño de los controles la
realiza una casa consultora, con la intención de que posteriormente sea la propia
área de calidad de procesos quien realice esas validaciones, es necesario que el
equipo de calidad de procesos adquiera el conocimiento necesario para realizar
dichas validaciones para asegurar que cuando se tengan cambios en los
documentos estos sigan cumpliendo los objetivos de control.
106
II.3.C. Implementación
Establecer el cumplimiento de los controles en las evaluaciones de
desempeño:
Debido a que actualmente no se ha podido responsabilizar a todos los
colaboradores de la dirección de TI sobre el cumplimento de los controles y
considerando que mientras que no se tenga un esquema de sanciones que se
apliquen cuando no se cumpla con lo establecido será difícil de garantizar el
cumplimiento, se deberá incluir como parte de la evaluación de desempeño y
potencial del personal el cumplimiento a los controles correspondientes (con base
en el registro de documentos que aplican por persona que se propone en el
apartado de comunicación).
Dichas evaluaciones forman parte del sistema de evaluación y desempeño
de potencial, dentro del cual se establecen las metas con las que se medirá el
desempeño de cada colaborador durante el año. Cada una de esas metas
representa un porcentaje de la puntuación total que puede obtener un colaborador
como parte de su desempeño y con base a ese porcentaje total obtenido se
calcula el aumento de sueldo al que será acreedor el colaborador.
Con esta actividad se busca que el personal se preocupe por el
cumplimiento de los controles, ya que de lo contrario estará en juego su beneficio
personal reflejándose en el porcentaje de aumento que percibirá en el año.
107
Tablero operativo de cumplimiento a los controles:
Con la finalidad de efectuar un seguimiento periódico del cumplimiento a los
controles por cada una de las áreas, se deberán generar tableros operativos en
los que se vayan plasmando los resultados obtenidos mes con mes (al estilo de
los tableros de Balanced Score Card).
Será de suma importancia que adicional a los tableros de control operativo,
se generen reuniones formales de revisión mensual, en las cuales se revisen
dichos tableros para medir de manera constante el desempeño de los mismos y
por ende de cada área. En estas reuniones se deberán tomar las medidas
necesarias para corregir las desviaciones que sean detectadas durante las
revisiones para posteriormente generar los planes de trabajo adecuados para la
remediación de dichas desviaciones.
Equipo de revisión de apego a procesos:
Será necesario implementar un equipo de revisión de apego a procesos que
revise periódicamente el cumplimiento a los controles por parte de cada una de las
áreas y de los controles que le corresponden al área de calidad de procesos.
Las revisiones que deberá realizar el equipo de revisión serán las
siguientes:
108
• Apego a procesos.
• Eficiencia de procesos.
• Calidad de software.
Sistema de control de documentos:
Actualmente en la dirección de TI se lleva el control documental de manera
manual sin el apoyo de alguna herramienta de control de documentos, lo cual
complica la gestión de los documentos que soportan a los controles COBIT que se
están implantando; por tal motivo, se recomienda de manera importante que sea
implementada una herramienta de ese tipo.
Considerando que La Empresa ya cuenta con un sistema (desarrollado
internamente) para el control de los documentos, el cual se utiliza para la gestión
de la documentación de las normativas (como ISO) que deben cumplir las
diferentes unidades de negocio de La Empresa y tomando en cuenta que el
objetivo es muy similar sino es que idéntico, se hace la recomendación de
implantar dicho sistema para facilitar la gestión de la documentación que se
genera para soporte de los controles COBIT.
Dentro de las funcionalidades con las que cuenta dicho sistema,
mencionaremos las más destacadas:
109
• La información se almacena en un solo repositorio de datos.
• Se cuenta con un control de acceso, lo que permite que cada
persona pueda consultar únicamente los documentos a los que tiene
derecho de consultar.
• Se cuenta con un flujo de autorización y publicación de información
que facilita dicho proceso al hacerse a través de la misma
herramienta.
• Se pueden obtener de manera automática los registros de
documentos que aplican por persona.
• Cuando surgen cambios de nomenclaturas, formatos, etc., dichos
cambios sólo se generan una vez en las plantillas y los documentos
basados en las mismas heredan los cambios de forma automática.
Para cerrar la sección de recomendaciones, cabe mencionar que para llevar
a cabo la implantación de la mayoría de ellas, será necesario generar planes de
trabajo individuales considerando las condiciones en las que se inicie cada una de
esas recomendaciones.
C O N C L U S I O N E S
111
Al término del presente trabajo de investigación se observó que las
principales problemáticas para la implantación adecuada de los controles COBIT
que ayudarán al cumplimiento de la Ley SOx a la dirección de TI de La Empresa
son:
La falta de una comunicación efectiva que haga conscientes a los
colaboradores de la dirección de TI sobre los objetivos del proyecto de
cumplimiento a la Ley Sox, sus beneficios y consecuencias de no cumplir con los
mismos; lo anterior queda de manifiesto ya que el 100% de las personas
entrevistadas opinan que la comunicación a lo largo del proyecto no ha logrado
sus objetivos y en la actualidad no se puede considerar como efectiva.
Lo anterior queda demostrado también en cuanto a la conciencia de parte
del personal de TI, ya que aunque 63% del personal entrevistado considera que el
personal es consciente de que se debe cumplir con los controles, el mismo
porcentaje opina que el personal de TI visualiza los controles como una carga
adicional al trabajo.
El 63% del personal opina que el diseño de los controles no ha sido del todo
adecuado, lo que ha traído como consecuencia que los mismos no sean
implementados fácilmente como parte de la operación normal de la dirección.
En este sentido, es necesario mencionar que originalmente los controles
fueron diseñados de manera que se tuviera incluida la operación dentro del
112
documento pero sin llevarse los vicios que ya tenía la operación. Si actualmente
algunos controles no se adaptan a la operación, ha sido también parte de la
evolución que ha venido teniendo la dirección de TI, por lo que ahora será
necesario retomar aquellos que han tenido cambios significativos para adecuarlos
a la operación actual.
Cabe mencionar que mucha de esta problemática se debe a que se carece
aún de una línea bien definida por parte de la dirección de TI, misma que ha
cambiado de prioridades de manera frecuente para adaptarse a los cambios que
va marcando el negocio.
Si bien existen varias áreas de oportunidad para lograr los objetivos del
proyecto, el camino no es del todo difícil, ya que se cuenta con los principales
recursos para llevar a cabo el cambio en la forma en la que se ha venido llevando
el proyecto; de tal suerte, que permita una mejor administración del mismo y un
cumplimiento adecuado; sin embargo, se tendrá que trabajar muy intensamente
para disminuir la resistencia al cambio que aún se tiene en la dirección de TI de La
Empresa.
Fundamental serán las acciones que se tomen en caso de incumplimientos
a los controles, ya que el cumplimiento de los mismos no es una alternativa, sino
la única opción para lograr un adecuado nivel de control interno que permita el
cumplimiento con la Ley SOx.
113
Algo que también es sumamente importante, es que para todos los
controles, será necesario asignar de manera adecuada la responsabilidad, así
como los recursos necesarios para garantizar el éxito de los mismos.
B I B L I O G R A F Í A
115
APM Grupo. (19 de Octubre de 2007). ¿Qué es ITIL? Recuperado el 2007, de www.itil-officialsite.com: www.itil-officialsite.com/Qualifications/Examiners/SharonTaylor.asp&sa=X&oi=translate&resnum=10&ct=result&prev=/search%3Fq%3DSharon%2BTaylor%26hl%3Des
Asofis. (s.f.). Control interno -Informe Coso. Recuperado el 2007, de www.asofis.org.mx: http://www.asofis.org.mx/mejores_practicas/COSO.pdf
Betz, C. T. (13 de Mayo de 2007). We already have service strategists. Recuperado el 2007, de www.erp4it.com: http://www.itskeptic.org/node/188#comment-929
Carnegie Mellon University. (Agosto de 2006). CMMI for Acquisition, Versión 1.2. Recuperado el 2007, de www.sei.cmu.edu: http://www.sei.cmu.edu/publications/documents/07.reports/07tr017.html
Carnegie Mellon University. (Agosto de 2006). CMMI for development, Versión 1.2. Recuperado el 2007, de www.sei.cmu.edu: http://www.sei.cmu.edu/pub/documents/06.reports/pdf/06tr008.pdf
Carnegie Mellon University. (09 de Diciembre de 2006). CMMI-DEV, Version 1.2 Errata Sheet. Recuperado el 2007, de www.sei.cmu.edu: http://www.sei.cmu.edu/cmmi/models/errata-dev.pdf
Cash, D. (s.f.). World-class Service Management Standard Moves with the Times by OGC's Debra Cash. Recuperado el 2007, de www.best-management-practice.com: http://www.best-management-practice.com/Knowledge-Centre/Guest-Writer/ITIL/?DI=571311
Channel Planet, Colaboración de Etek. (07 de Febrero de 2005). El modelo COBIT para auditoría y control de sistemas de información. Recuperado el 2007, de www.channelplanet.com: http://www.channelplanet.com/index.php?idcategoria=13932
Comité Directivo de COBIT y el IT Governance Institute MR. (s.f.). COBIT Objetivos de COntrol. Recuperado el 2007, de www.itgi.org: www.itgi.org
Coopers & Lybrand. (1997). Los nuevos conceptos del control interno (informe COSO) (1 ed.). Madrid: Diaz de Santos, S.A.
DATASEC IT Security & Control. (s.f.). Control Interno _Basado en el informe COSO. Recuperado el 2007, de www.datasec-soft.com: http://www.datasec-soft.com/archivos/sp/PPTS/Presentacion_Control_Interno_COSO-ES.ppt
Deloitte. (s.f.). Sarbanes Oxley FAQ´s. Recuperado el 2007, de www.deloitte.com: http://www.deloitte.com/dtt/article/0,1002,cid%253D112807,00.html
116
Deloitte. (s.f.). Sarbanes-Oxley. Recuperado el 2007, de www.deloitte.com: http://www.deloitte.com/dtt/section_node/0,1042,sid%253D96325,00.html
Dugmore, J. a. (s.f.). ISO/IEC 20000 and ITIL - The Difference Explained by Jenny Dugmore and Alison Holt. Recuperado el 2007, de www.best-management-practice.com: http://www.best-management-practice.com/Knowledge-Centre/Guest-Writer/ITIL/?DI=571307
Ezcobit. (s.f.). Overview. Obtenido de www.ezcobit.com: http://www.ezcobit.com/UsingCobit/index.html
Fernandez de Lara, C. (Abril de 2007). Alineación de TI con el negocio. InfoWorld , 12-15.
FoxIT. (s.f.). BS15000. Recuperado el 2007, de www.foxit.net: http://www.foxit.net/asp/FOX_HTML_Page.asp?pageid=190&go2=190,x
FoxIT. (s.f.). Consolidated ITIL and Sarbanes-Oxley. Recuperado el 2007, de www.foxit.net: http://www.foxit.net/asp/Frames_Set.asp?go2=BS15000
FoxIT. (s.f.). Consultancy Introduction. Recuperado el 2007, de www.foxit.net: http://www.foxit.net/asp/Frames_Set.asp?go2=BS15000
FoxIT. (s.f.). Fox IT Governance Methodology. Obtenido de www.foxit.net: http://www.foxit.net/asp/Frames_Set.asp?go2=BS15000
FoxIT. (s.f.). Fox IT Governance Model. Recuperado el 2007, de www.foxit.net: http://www.foxit.net/asp/Frames_Set.asp?go2=BS15000
FoxIT. (s.f.). From BS15000 to ISO20000. Recuperado el 2007, de www.foxit.net: http://www.foxit.net/asp/Frames_Set.asp?go2=BS15000
FoxIT. (s.f.). International standard for IT service management. Recuperado el 2007, de www.foxit.net: http://www.foxit.net/asp/Frames_Set.asp?go2=BS15000
FoxIT. (s.f.). ISO20000. Recuperado el 2007, de www.foxit.net: http://www.foxit.net/asp/Frames_Set.asp?go2=BS15000
FoxIT. (s.f.). ISO20000 Overview. Obtenido de www.foxit.net: http://www.foxit.net/asp/Frames_Set.asp?go2=BS15000
FoxIT. (s.f.). ISO20000Compliance Assessment. Recuperado el 2007, de www.foxit.net: http://www.foxit.net/asp/Frames_Set.asp?go2=BS15000
FoxIT. (s.f.). Iso2000is the quality standar for IT service Management. Recuperado el 2007, de www.foxit.net: http://www.foxit.net/asp/Frames_Set.asp?go2=BS15000
FoxIT. (s.f.). IT Effectiveness. Recuperado el 2007, de www.foxit.net: http://www.foxit.net/asp/Frames_Set.asp?go2=BS15000
117
FoxIT. (s.f.). IT Governance. Recuperado el 2007, de www.foxit.net: http://www.foxit.net/asp/Frames_Set.asp?go2=BS15000
FoxIT. (s.f.). Preparing for ISO20000. Recuperado el 2007, de http://www.foxit.net/asp/Frames_Set.asp?go2=BS15000: http://www.foxit.net/asp/Frames_Set.asp?go2=BS15000
FoxIT. (s.f.). S-ox Compiance-Sustainability. Recuperado el 2007, de www.foxit.net: http://www.foxit.net/asp/Frames_Set.asp?go2=BS15000
González, E. (19 de Febrero de 2007). Las implantaciones de ITIL ganan terreno para optimizar las necesidades empresariales. Recuperado el 2007, de www.idg.es: http://www.idg.es/pcworldtech/mostrarnoticia.asp?id=54135&seccion=actualidad
Government Technology. (9 de Mayo de 2005). European Commission Selects COBIT as an Information Systems Security Standard. Recuperado el 2007, de www.govtech.com: http://www.govtech.com/gt/articles/93952
Gurney, R. (s.f.). Roadmap to ITIL Qualifications by Wardown Consulting Ltd's Rosemary Gurney. Recuperado el 2007, de www.best-management-practice.com: http://www.best-management-practice.com/Knowledge-Centre/Guest-Writer/ITIL/?DI=571309
Hernández Ayala, N. J. (s.f.). ¿Porqué afecta la Sarbanes Oxley Act a las empresas mexicanas? Recuperado el 2007, de www.gestiopolis.com: http://www.gestiopolis.com/canales3/ger/oxley.htm
IBM Global Services. (Septiembre de 2004). IBM and the IT Infrastructure Library. How IBM supports ITIL and provides ITIL-based capabilities and solutions. Recuperado el 2007, de www.ibm.com: http://www-935.ibm.com/services/us/igs/pdf/wp-g510-3008-03f-supports-provides-itil-capabilities-solutions.pdf
Ingall, S. (s.f.). "...but i don´t know what to do!" by FOS IT´s Steve Ingall. Recuperado el 2007, de www.best-management-practice.com: http://www.best-management-practice.com/Knowledge-Centre/Guest-Writer/ITIL/?DI=571310
IT Governance Institute. (2006). COBIT 4.1. Recuperado el 2007, de www.isaca.org: http://www.isaca.org/cobit
IT Governance Institute. (1996). COBIT Objetivos de Control 3.0 (3ra ed.). USA: IT Governance Institute.
IT Governance Institute. (s.f.). COBIT Reunión Informativa del consejo sobre la gobernabilidad TI. Recuperado el 2007, de www.itgi.org: http://www.itgi.org/template_ITGI.cfm?template=/ContentManagement/ContentDisplay.cfm&ContentID=33303
118
IT Governance Institute EE. UU. (Junio de 2006). IT Governance Institute. Obtenido de www.itgi.org: www.itgi.org
IT Governance Institute. (2004). IT Control objectives for Sarbanes-Oxley. IL, USA: IT Governance Institute.
IT Governance Institute. (2006). IT Control Objectives for Sarbanes-Oxley: The Role of IT in the Design and Implementation of Internal Control Over Financial Reporting, 2nd Edition. Recuperado el 2007, de www.isaca.org: http://www.isaca.org/Template.cfm?Section=Home&CONTENTID=32621&TEMPLATE=/ContentManagement/ContentDisplay.cfm
IT Governance Institute. (2007). ITASSURANCEGUIDE: USINGCOBIT. Recuperado el 2007, de www.itgi.org: http://www.itgi.org
IT Governance Institute. (2006). Mapping of SEI’s CMM for Software With COBIT® 4.0. Recuperado el 2007, de www.itgi.org: http://www.itgi.org
IT Governance Institute. (Julio de 2000). The ITGovernance Institute® is pleased to offer you this complimentary download of COBIT®. Recuperado el 2007, de www.itgi.org: http://www.isaca.org/ContentManagement/ContentDisplay.cfm?ContentID=33925
Iturbide, F. (2005). Ley Sarbanes-Oxley Act (SOX, SOA). Recuperado el 2007, de www.cybsec.com: http://web.unvi.utp.ac.pa/bibliotecavirtual/files/LEY_SOX_314.pdf
Jaimes, C. (Julio de 2004). El nuevo rol del CIO. Information Week , 6-7.
Kalendae. (s.f.). BS15000 and ISO20000 Frequently Asked Question (FAQs). Recuperado el 2007, de kalendae.com.mx: http://www.kalendae.com.mx/index.php?option=com_content&task=view&id=43&Itemid=20
kalendae. (s.f.). Gobernabilidad Modelo. Recuperado el 2007, de www.kalendae.com.mx: URL: http://www.kalendae.com.mx/index.php?option=com_content&task=view&id=38&Itemid=197
Kalendae. (s.f.). Gobernabilidad-Metodología. Recuperado el 2007, de www.kalendae.com.mx: URL: http://www.kalendae.com.mx/index.php?option=com_content&task=view&id=39&Itemid=246
Kalendae. (s.f.). Gobernabilidad-Tecnología de la información. Obtenido de www.kalendae.com.mx: http://www.kalendae.com.mx/index.php?option=com_content&task=view&id=34&Itemid=196
119
Kalendae. (s.f.). ITIL. Recuperado el 2007, de www.kalendae.com.mx: http://www.kalendae.com.mx/index.php?option=com_content&task=view&id=35&Itemid=202
kpmg. (s.f.). Ley Sabanes-Oxley. Recuperado el 2007, de www.kpmg.com.mx: http://www.kpmg.com.mx/gobiernocorporativo/html/rrr_sox.htm
La web de Auditoria. (s.f.). El especial Sarbanes Oxley. Recuperado el 2007, de www.lawebdeauditoria.com: http://212.9.83.4/auditoria/home.nsf/SOX_pral?OpenForm
La web de Auditoria. (s.f.). El informe COSO. Recuperado el 2007, de www.lawebdeauditoria.com: http://212.9.83.4/auditoria/home.nsf/COSO_1?OpenPage
La web de auditoría. (s.f.). El paso de la SOX en la organizaciòn. Recuperado el 2007, de www.lawebdeauditoria.com: http://www.auditoria.com.mx/noticias/boletin/2005/0509.htm
Marín de Guerrero, M. A. (02 de Julio de 2002). Nuevos conceptos de control interno informe COSO. Recuperado el 2007, de www.iicau.cl: http://www.iicau.cl/SAC/Descargas/COSO.pdf
Marlin, S. (Mayo de 2005). Las Ventajas de Sarbanes-Oxley. Information Week , 19-23.
Palacios, J. (14 de Mayo de 2007). Entrevista con Sharon Taylor, Arquitecto en Jefe de ITIL v3. Recuperado el Agosto de 2007, de www.sg.com.mx: http://www.sg.com.mx/content/view/249/
Paz, O. (10 de Enero de 2006). ITIL: Mejores prácticas para gestionar los servicios de tecnologías de información. Recuperado el 2007, de www.channelplanet.com: http://www.channelplanet.com/index.php?idcategoria=15742
Philips, R. a. (s.f.). Bridging the Gap between Project and Service Management by FGI's Ruth Phillips and Angelina Lukehurst. Recuperado el 2007, de www.best-management-practice.com: http://www.best-management-practice.com/Knowledge-Centre/Guest-Writer/ITIL/?DI=571308
Picas, R. (s.f.). El rol del gerente de sistemas (CIO). Recuperado el 2007, de www.logistec.cl: http://www.logistec.cl/noticia.php?noticia_id=1370&categoria_id=6
Picas, R. (s.f.). Gerente equipo gerencial en el uso de la tecnoligía. Recuperado el Septiembre de 2007, de www.logistec.cl: http://www.logistec.cl/noticia.php?noticia_id=1320&categoria_id=6
Rezzoagli, L. C. (2005). Manual para la elaboración de tesis (1ª Edición ed.). Durango, México: Fomento Educativo y Cultural Francisco de Ibarra, A.C.
120
Santiago, E. (17 de Mayo de 2006). Importancia y retos de la gobernabilidad de tecnología. Recuperado el 2007, de ww.channelplanet.com: http://www.channelplanet.com/?idcategoria=1634
SAS. (s.f.). Sarbanes-Oxley Compliance. Recuperado el 2007, de www.sas.com: http://www.sas.com/offices/latinamerica/chile/solutions/financial/sox/
SEC. (s.f.). La SEC en Español: Información para los inversionistas. Recuperado el 2007, de www.sec.gov: http://www.sec.gov/investor/espanol/quehacemos.htm
SEC. (2002). Sarbanes Oxley Act of 2002. USA: SEC.
SEC. (s.f.). Sobre el SEC. Recuperado el 2007, de www.secbd.org/: http://www.secbd.org/
Taylor, S. (s.f.). Sobre APMG. Recuperado el 2007, de www.itil-officialsite.com: http://www.itil-officialsite.com/Qualifications/Examiners/SharonTaylor.asp&sa=X&oi=translate&resnum=10&ct=result&prev=/search%3Fq%3DSharon%2BTaylor%26hl%3Des
Taylor, S. (s.f.). Sobre TSO. Recuperado el 2007, de www.itil-officialsite.com: www.itil-officialsite.com/Qualifications/Examiners/SharonTaylor.asp&sa=X&oi=translate&resnum=10&ct=result&prev=/search%3Fq%3DSharon%2BTaylor%26hl%3Des
Taylor, S. (s.f.). Something better than ITIL? by ITIL Chief Architect Sharon Taylor. Recuperado el 2007, de www.best-management-practice.com: http://www.best-management-practice.com/Knowledge-Centre/Guest-Writer/ITIL-?DI=571036
Vargas Fernández, L. (Junio de 2007). En que consiste COBIT 4.0. Recuperado el 2007, de www.monografias.com: http://www.monografias.com/trabajos38/cobit/cobit.shtml
Wikipedia. (s.f.). Acto de Sarbanes-Oxley. Recuperado el 2007, de en.wikipedia.org: http://en.wikipedia.org/wiki/Sarbanes-Oxley_Act&sa=X&oi=translate&resnum=1&ct=result&prev=/search%3Fq%3DSarbanes-Oxley%26hl%3Des
Wikipedia. (s.f.). Comisiòn de seguridades y de intercambio de Estados Unidos. Recuperado el 2007, de en.wikipedia.org: http://en.wikipedia.org/wiki/United_States_Securities_and_Exchange_Commission
Young, J. (Junio de 2006). PCAOB (Public Company Accounting Oversight Board). Recuperado el 2007, de www.contadoresaic.org: http://www.contadoresaic.org/noticias/boletin%202006/boletin%201-15%20septiembre%2006/pcaob.htm
121
Zayas, J. (2006). ITIL. Recuperado el 2007, de www.inlac.org: http://www.inlac.org/documentos/28-4.pdf
A N E X O S
A-1
A.
ANEXO A. DEFINICIÓN DE TÉRMINOS
Balanced Score Card
Es un Sistema de integrado de Gestión Estratégica, que permite ver, como la estrategia se traslada a la acción, gestionando la misma a través de relaciones causa efecto, vinculando el logro de objetivos estratégicos a través de cuatro perspectivas con Indicadores e Inductores ejecutados a través de Iniciativas. Actúa como un sistema de medición, un sistema de administración estratégica, y una herramienta de comunicación.
COBIT
Objetivos de Control para la información y Tecnologías relacionadas (COBIT, en inglés: Control Objectives for Information and related Technology) es un conjunto de mejores prácticas para el manejo de información creado por la Asociación para la Auditoría y Control de Sistemas de Información (ISACA, en inglés: Information Systems Audit and Control Association), y el Instituto de Administración de las Tecnologías de la Información (ITGI, en inglés: IT Governance Institute) en 1992.
Controles Activity Level
Controles de COBIT que definen la parte operacional en las Organizaciones de TI.
Controles Company Level
Controles de COBIT que definen la parte estratégica en las Organizaciones de TI.
COSO (Committee of Sponsoring Organizations of the Treadway
Commission)
Comité de organizaciones patrocinadoras de la comisión Treadway. Estándar aceptado a nivel internacional para el gobierno corporativo.
A-2
e-learning
De Electronic Learning – Anglicismo,, Neologismo. Aprendizaje asistido por tecnologías de la información. El e-Learning fomenta el uso intensivo de las TIC facilitando la creación, adopción y distribución de contenidos, así como la adaptación del ritmo de aprendizaje y la disponibilidad de las herramientas de aprendizaje independientemente de límites horarios o geográficos. Permitiendo al alumno intercambiar opiniones y aportes a través de las Tecnologías de Información y Comunicación.
Gobernabilidad de TI
Una estructura de relaciones y procesos para dirigir y controlar la empresa con el objeto de alcanzar los objetivos de la empresa y añadir valor mientras se balancean los riesgos versus el retorno sobre TI y sus procesos.
ISO:27001
El estándar para la seguridad de la información ISO/IEC 27001 (Information technology - Security techniques - Information security management systems - Requirements) fue aprobado y publicado como estándar internacional en Octubre de 2005 por International Organization for Standardization y por la comisión International Electrotechnical Commission.
Especifica los requisitos necesarios para establecer, implantar, mantener y
mejorar un Sistema de Gestión de la Seguridad de la Información (SGSI) según el conocido “Ciclo de Deming”: PDCA - acrónimo de Plan, Do, Check, Act (Planificar, Hacer, Verificar, Actuar). Es consistente con las mejores prácticas descritas en ISO/IEC 17799 (actual ISO/IEC 27002) y tiene su origen en la revisión de la norma británica British Standard BS 7799-2:2002.
ITIL (Information Technology Infrastructure Library)
La Information Technology Infrastructure Library (‘Biblioteca de Infraestructura de Tecnologías de Información’), frecuentemente abreviada ITIL, es un marco de trabajo de las mejores prácticas destinadas a facilitar la entrega de servicios de tecnologías de la información (TI) de alta calidad. ITIL resume un extenso conjunto de procedimientos de gestión ideados para ayudar a las organizaciones a lograr calidad y eficiencia en las operaciones de TI.
Ley Sarbanes-Oxley (SOx):
A-3
La Sarbanes-Oxley Act of 2002, Pub. L. No. 107-204, 116 Stat. 745 (30 de julio de 2002), es una ley de Estados Unidos también conocida como el Acta de Reforma de la Contabilidad Pública de Empresas y de Protección al Inversionista. También es llamada SOx o SarbOx.
PCAOB (Public Company Accounting Oversight Board)
La PCAOB establece y supervisa las normas de las empresas de auditoría y de las personas que invierten en las sociedades con cotización oficial. Se encarga de mantener la integridad de la empresa pública del proceso de auditoría y garantizar que los auditores y las sociedades de auditoría son independientes.
Tecnologías de información (TI)
Las Tecnologías de la Información han sido conceptualizadas como la integración y convergencia de la computación microelectrónica, las telecomunicaciones y la técnica para el procesamiento de datos, sus principales componentes son: el factor humano, los contenidos de la información, el equipamiento, la infraestructura material, el software y los mecanismos de intercambio electrónico de información, los elementos de política y regulaciones y los recursos financieros.