GOBIERNODETIUTILIZANDO COBIT Y VAL IT - CAMPUS …€¦ · · 2013-05-15R econocimientos Page 6...

GOBIERNO DE TI UTILIZANDO

COBIT® Y VAL ITTM:TIBO CASO DE ESTUDIO,

2DA EDICION

Reconocimientos

I T G o v e r n a n c e I n s t i t u t e

IT Governance Institute

El TI Governance Institute (ITGITM) (www.itgi.org) se estableció en 1998 para promover el avance del pensamientointernacional y estándares para dirigir y controlar las tecnologías de la información de las empresas. El gobiernoefectivo de las TI ayuda a asegurar que las TI soportan los objetivos del negocio, optimizan las inversiones en TI ygestionan los riesgos y oportunidades relacionados con las TI de manera apropiada. ITGI ofrece investigaciónoriginal y casos de estudio para ayudar a los líderes y Juntas Directivas de las empresas en sus responsabilidades degobierno de TI.

Limitación de ResponsabilidadITGI y los autores de Gobierno de TI utilizando COBIT® y Val IT™: TIBO – Caso de Estudio, 2 da Edición, hanconcebido esta publicación primordialmente como un recurso educativo para educadores. ITGI, ISACA® y losautores no declaran que la utilización de este producto asegurará un resultado exitoso. La publicación no debería serconsiderada como conteniendo todos los procedimientos y pruebas apropiadas ni omitiendo todos losprocedimientos o pruebas apropiadas que están razonablemente orientados a obtener los mismos resultados. Aldeterminar la conveniencia de un procedimiento o prueba específica, el/la profesional del control debería aplicar supropio juicio profesional a la circunstancia de control específica presentada por un sistema en particular o un entornode TI. Se hace notar que esa publicación es una actualización de CobiT® in Academia: TIBO Case Study.

Revelación 2007 IT Governance Institute. Derechos reservados. Esta publicación está destinada solamente para usoacadémico y podrá ser utilizada de ninguna otra manera (incluyendo cualquier propósito comercial). Lareproducción de partes de esta publicación está permitida solamente para el uso descripto y debe incluir la completadescripción del derecho de autor y los reconocimientos: l derecho de autor y los reconocimientos: ‘ 2007 ITGovernance Institute. Derechos reservados. Impreso con permiso’. Gobierno de TI utilizando COBIT® y Val IT™:

TIBO – Caso de Estudio, 2da Edición, no podrá ser utilizado, copiado o reproducido de ninguna forma o por

ningún medio (electrónico, mecánico, fotocopiado, grabación o cualquier otra medio) sin el previo permiso escritodel ITGI. Cualquier modificación, distribución, exposición, transmisión, o almacenamiento de cualquier forma omedio (electrónico, mecánico, fotocopiado, grabación u otro) de Gobierno de TI utilizando COBIT® y Val IT™:

TIBO – Caso de Estudio, 2da Edición está prohibido. No se otorga ningún otro permiso o derecho sobre este

trabajo.

IT Governance Institute3701 Algonquin Road, Suite 1010Rolling Meadows, IL 60008 USAPhone: +1.847.590.7491Fax: +1.847.253.1443E-mail: [email protected] sites: www.itgi.org and www.isaca.org

ISBN 978-1-60420-025-6

Gobierno de TI utilizando COBIT® y Val IT™: TIBO – Caso de Estudio, 2da Edición

Printed in the United States of America

Reconocimientos


ITGI Desea Reconocer a:

ResearcherEd O’Donnell, University of Kansas, USA

ContribuitorsRoger Stephen Debreceny, Ph.D., FCPA, University of Hawaii, USASteven De Haes, University of Antwerp Management School, BelgiumErik Guldentops, CISA, CISM, University of Antwerp Management School, BelgiumRobert Parker, CISA, CA, CMC, FCA, CanadaV. Sambamurthy, Ph.D., Michigan State University, USAScott Lee Summers, Ph.D., Brigham Young University, USAJohn Thorp, The Thorp Network, CanadaWim Van Grembergen, Ph.D., UniversityofAntwerp (UA) and UniversityofAntwerp Management School (UAMS)

and TI Alignment and Governance Research Institute (ITAG), BelgiumRamesh Venkataraman, Ph.D., Indiana University, USA

ITGI Board of TrusteesEverett C. Johnson, CPA, Deloitte & Touche (retired), USA, International PresidentGeorges Ataya, CISA, CISM, CISSP, ICT Control sa-nv, Belgium, Vice PresidentWilliam C. Boni, CISM, Motorola, USA, Vice PresidentLucio Augusto Molina Focazzio, CISA, Colombia, Vice PresidentAvinash Kadam, CISA, CISM, CBCP, CISSP, Miel e-Security Pvt. Ltd., India, Vice PresidentJean-Louis Leignel, MAGE Conseil, France, Vice PresidentHoward Nicholson, CISA, City of Salisbury, Australia, Vice PresidentFrank Yam, CISA, CIA, CCP, CFE, CFSA, FFA, FHKCS, FH KIoD, Focus Strategic Group, Hong Kong, Vice PresidentMariosDamianides, CISA, CISM, CA, CPA, Ernst & Young LLP, USA, Past International PresidentRobert S. Roussey, CPA, University of Southern California, USA, Past International PresidentRonald Saull, CSP, Great-West Life Assurance and IGM Financial, Canada, Trustee

IT Governance CommitteeTony Hayes, FCPA, Queensland Government, Australia, ChairMax Blecher, Virtual Alliance, South AfricaSushil Chatterji, SingaporeAnil Jogani, CISA, FCA, Tally Solutions Limited, UKJohn W. Lainhart, IV, CISA, CISM, CIPP/G, IBM, USARomulo Lomparte, CISA, Banco de Credito BCP, PeruMichael Schirmbrand, Ph.D., CISA, CISM, CPA, KPMG LLP, AustriaRonald Saull, CSP, Great-West Life Assurance and IGM Financial, Canada

ITGI Advisory PanelRonald Saull, CSP, Great-West Life Assurance and IGM Financial, Canada, ChairRoland Bader, F. Hoffmann-La Roche AG, SwitzerlandLinda Betz, IBM Corporation, USAJean-Pierre Corniou, Renault, France Rob Clyde, CISM, Symantec, USARichard Granger, NHS Connecting for Health, UKHoward Schmidt, CISM, R&H Security Consulting LLC, USAAlex Siow Yuen Khong, StarHub Ltd., SingaporeAmit Yoran, Yoran Associates, USA

Reconocimientos


Academic Relations CommitteeScott Lee Summers, Ph.D., Brigham Young University, USA, ChairCasey G. Cegielski, Ph.D., CISA, Auburn University, USAPatrick Hanrion, CISM, CISSP, CNE, MCSE, Microsoft, USADonna Hutcheson, CISA, XR Group Inc., USACejka Jiri Josef, CISA, Dipl. El. -Ing., KPMG Fides Peat, SwitzerlandMichael Lambert, CISA, CISM, CARRA, CanadaEd O’Donnell, University of Kansas, USATheodore Tryfonas, Ph.D., CISA, Universityof Glamorgan, WalesRamesh Venkataraman, Ph.D., Indiana University, USA

COBIT Steering CommitteeRoger Stephen Debreceny, Ph.D., FCPA, University of Hawaii, USA, ChairGary S. Baker, CA, Deloitte & Touche, CanadaSteven DeHaes, University of Antwerp Management School, BelgiumRafael Eduardo Fabius, CISA, Republica AFAP, S.A., UruguayUrs Fischer, CISA, CIA, CPA (Swiss), Swiss Life, SwitzerlandErik Guldentops, CISA, CISM, Universityof Antwerp Management School, BelgiumGary Hardy, TI Winners, South AfricaJimmy Heschl, CISM, CISA, KPMG, AustriaDebbie A. Lew, CISA, Ernst & Young LLP, USAMaxwell J. Shanahan, CISA, FCPA, Max Shanahan & Associates, AustraliaDirk E. Steuperaert, CISA, PricewaterhouseCoopers LLC, BelgiumRobert E. Stroud, CA Inc., USA

Reconocimientos


ITGI Affiliates and SponsorsISACA chaptersAmerican Institute for CertifiedPublic Accountants ASISInternationalThe Center for Internet SecurityCommonwealth Association of Corporate Governance Inc.FIDA InformInformation Security ForumInformation Systems Security AssociationInstitut de la Gouvernance des Systèmes d’InformationInstitute ofManagementAccountantsISACAITGI JapanSolvay Business SchoolUniversity of AntwerpManagement SchoolAldion ConsultingPte. Ltd.CA Inc.Hewlett-PackardIBMITpreneurs Nederlands BVLogLogic Inc.Phoenix Business andSystems Process Inc.Project Rx Inc.Symantec CorporationWolcott Group LLCWorld Pass TI Solutions

Reconocimientos


Este Trabajo ha sido traducido al español por Ricardo Bría ([email protected]) de la versión en inglésde ‘Gobierno de TI utilizando COBIT® y Val IT™: TIBO – Caso de Estudio, 2 da Edición’, con permiso de ITGI.Ricardo Bría asume toda la responsabilidad de la exactitud y fidelidad de la traducción.

©2007 ITGI. Todos los derechos reservados. COBIT es una marca registrada de la Information SystemsAudit and Control Association y el IT Governance Institute.

This Work is translated by Ricardo Bría ([email protected]) into Spanish from the English languageversion of ‘IT Governance Using COBIT® and Val IT™: TIBO - Case Study2nd Edition’ with the permission ofthe IT Governance Institute. Ricardo Bría assumes sole responsibility for the accuracy and faithfulness of thetranslation.

©2007 ITGI. All rights reserved. COBIT is a registered trademark of the Information Systems Audit andControl Association and the TI Governance Institute.

TABLA DE CONTENIDO


Contenido1. PROPOSITO DEL DOCUMENTO 8

2. DESCRIPCIÓN DEL CASO DE ESTUDIO 9UN DIA EN LA VIDA DE LA HISTORIA DE LA SUBCONTRATACION DE TIBO 9EL PERFIL DE TIBO 11EL ENTORNO TI DE LA EMPRESA 12

Proyectos 12Tecnología 12Estándares y Procedimientos 13Seguridad 13

LA ESTRUCTURA ORGANIZATIVA 13Consejo de Administración (Board of Directors) 13Comité Ejecutivo 14Grupo de Estrategia de Negocio 14Comité de Coordinación de TI 14Dirección de TI 14Equipos de trabajos de TI 15Operación del Negocio 15

3. MATERIAL ADICIONALEL ASUNTO DE LA SEGURIDAD 17

Preguntas 17EL ASUNTO DE LA SUBCONTRATACION 17

Preguntas 17ELASUNTODELAALINEACIÓNESTRATEGICA 17

Información y Antecedentes Adicionales 17Preguntas 18

APENDICE 1—FINANCIAL OMBUDSMAN SERVICE 19

APENDICE 2—OBJETIVOS DE CONTROL Y MODELOS DE MADUREZ DE COBIT 20

COBIT Y PRODUCTOS RELACIONADOS 50

1. PROPOSITO DEL DOCUMENTO


El Caso de Estudio TIBO, 2 da Edición es un producto desarrollado el ITGI, en colaboración con un grupode académicos y especialistas internacionales, como parte de Gobierno de TI utilizando COBIT® y ValIT™. El objetivo de este documento es presentar un caso de estudio completo (incluyendo la descripcióndel caso, preguntas a los alumnos y amplias notas para el Profesor) en el cual los alumnos puedan aplicarsu conocimiento de COBIT a una situación práctica. Este caso puede ser integrado dentro del Programa deestudios de las carreras en Sistemas de Información, Seguridad de la Información, Auditoría, Auditoría deSistemas de Información y/o Sistemas de Información Contable.

Este caso ha sido diseñado para ser utilizado primariamente en cursos de Post Grado.

El caso también podría ser utilizado en clases de Grado, siempre que los alumnos hayan estado losuficientemente expuestos a conceptos de control interno en un entorno de IT, marcos generales decontrol y COBIT en particular.

El caso ha sido diseñado para mapear el libro Gobierno de TI utilizando COBIT® y Val IT™: TIBO–Caso deEstudio, 2 da Edición, que explica todos los elementos de COBIT y que también ha sido desarrollado por elITGI. El material de este caso se nutre directamente de los procesos de TI de COBIT.

Se sugiere que el caso se presente en una o posiblemente dos clases (ver Figura 1-Mapa Sugerido delCaso), luego de la presentación de COBIT (sesión 0). Se sugiere también que la primera parte del caso seacubierta en una clase de aproximadamente 1.5 horas. A los alumnos se le deberá entregar previamente,como material de lectura, el caso de estudio y el Board Briefing on IT Governance 2 Edition1, yposteriormente en clase, las preguntas relacionadas con cada uno de los asuntos que trata el Caso:seguridad, servicios a terceros, alineación estratégica (incluidos en la Sección de Material Adicional). Laspreguntas podrán ser discutidas de manera interactiva en una segunda sesión o en presentaciones depequeños grupos. En las Notas para el Profesor se provee material adicional de lectura y solucionessugeridas para cada una de las partes del Caso.

El ITGI ha desarrollado tres productos adicionales que pueden acompañar a este Caso de estudio en laserie de documentos sobre Gobierno de TI utilizando COBIT® y Val IT™ para académicos:

Libro para el estudiante, 2 da Edición Presentación,2 da Edición, 35 slides de PowerPointo sobre COBIT Mini Casos, 2 da Edición, para ejercicios más pequeños de COBIT, o para ser utilizados para alumnos

de grado o post grado.Figura 1-Mapa Sugerido del Caso

1ITGI, Board Briefing on IT Governance, 2nd Edition, USA, 2003

Session

1

2

3

Student Guideto COBIT

Reading

Security

Introduction toCobiT

Part OneTOBICCase

Activity

Outsourcing Strategy

Board Briefing

RelevantAdditionalMaterial

2. DESCRIPCIONES DEL CASO DE ESTUDIO


UN DIA EN LA VIDA DE LA HISTORIA DE LASUBCONTRATACION DE TIBO

Era evidente que el Chief Executive Officer (CEO) del Trusted Imperial Banking Organisation (TIBO),John Mitchell, no estaba de humor para charlas cordiales. El Director de IT, Steven De Haes, fueconvocado de manera urgente a la oficina del CEO en la Planta 30 del edificio central del Banco en eldistrito financiero de Londres por la asistente personal del CEO, Pyms Forsythe. De Haes tenía unpresentimiento acerca del motivo cuando Forsythe lo llamó a la reunión minutos antes. Forsythe le dijo,“Mitchell ha recibido la Encuesta de Defensa del Consumidor Financiero (Financial OmbudsmanSurvey)2 y ha estado hablando por teléfono con el Vicepresidente Senior (SVP) de Banca Personal (BP)desde entonces. No está muy contento, y tu estrambótico Web-enabled Banking Operations (We-BOP)creo que está más muerto que vivo. De todas manera, quiere verte ya.”

De Haes sabía que el SVP de BP, Wim Van Grembergen, no era amigo de IT. El área de TI había estadotrabajando en el We-BOP para BP desde hace un año, para enfrentar a una dura competencia por clientesen el Reino Unido. La competencia provenía no solo de las ofertas de Internet de algunos Bancos, sinotambién de Bancos Online. A De Haes le hubiera gustado que su jefe, el Chief Operating Officer (COO),Erik Guldentops, estuviera con el, pero estaba de viaje fuera del país (otra vez). Bruscamente, Mitchelldijo: “Qué demonios estáis haciendo en TI con We-BOP? Me ha llamado el Defensor del Consumidorpara decirme que está trabajando en una Reclamación formal por nuestro servicio de e-banking!. Harecibido más de 40 reclamaciones en los últimos dos meses solamente. He hablado con Wim VanGrembergen, y me comenta que el no ha estado involucrado con We-BOP en los últimos 6 meses, desdeque decidisteis subcontratarlo. Quiero que vuelvas a traer a We-BOP internamente y quiero que lo hagasYA!!”.

Al cabo de un rato, De Haes pudo calmar al CEO y brindarle algo más de información sobre el proyecto ysu historia. Esto reveló que hay un gran descontento en TI relacionado con la calidad del trabajo delcontratista, pero también entre el área de BP e TI ya que TI tomó por su cuenta la decisión de subcontratarel servicio. De Haes manifestó que TI tomó la decisión de buena fe porque el área de BP estaba “furiosa”con su inhabilidad para competir en el mercado de e-banking. La discusión, reveló también que habíahabido varias señales de advertencia respecto de la calidad del servicio.

“Tienes razón Steven. Hablando con Wim hace un rato, me he enterado que el informe que genera laMesa de Ayuda del subcontratista es enviado a Joshua Dean, uno de los tuyos de Soporte a Usuarios.Joshua asumía que el contratista estaba gestionando de manera efectiva todas estas incidencias yreclamos. Pero no estaban siendo ingresadas en su sistema de Soporte a usuarios. Joshua había notadoque los informes eran cada vez más extensos y se lo había mencionado a Ed O’Donnell. Ed no sesorprendió, ya que había notado que la factura por el servicio de Mesa de Ayuda subcontratada había idoincrementándose en los últimos meses. Además, Katherine, del área de Desarrollo, había escuchado queel proveedor de servicios en Singapur no podía resolver los problemas con transacciones erróneas” dijoMitchell.

Estaba claro que el CEO de TIBO iba a tener que convocar a todos los involucrados si quería llegar alfondo de este asunto. Le pidió a Forsythe que organizara una reunión para el día siguiente. “Pyms, porfavor, cambia también la reunión de Seguridad del Comité de Auditoría del Consejo de Dirección. Sé quetodos hemos estado muy seriamente preocupados con el enfoque de “bombero” que le hemos dado a laSeguridad desde el 11 de Septiembre de 2001 y el incidente del virus y el de hacking, pero primero

2Una Organización para la defensa del consumidor. Ver Apéndice 1



tenemos que resolver el problema de We-BOP”.

“Hey…, Steven, antes que te vayas. Tienes alguna idea de a quién deberíamos llamar como nuestroexperto en seguridad para la reunión con el Comité de Auditoría?”

“Si recuerdas, John, nosotros elevamos una solicitud para incorporar un Senior CISO3 pero la decisióndel Comité Ejecutivo fue que estábamos bien así y que podíamos obviarla. Todavía estoy debatiendo conAuditoría Interna porque están tratando de asignarme esa responsabilidad a mí, ya que Eric y Roger nopudieron ponerse de acuerdo en quién debería tenerla. En realidad, solo tenemos a Ida Doano, nuestraadministradora de seguridad, pero Ida no tiene el nivel ni el perfil como para estar en esa reunión.”

De regreso a su oficina, De Haes no podía dejar de pensar en cómo se había iniciado todo. TI habíaplanificado el We-BOP, pero no poseía las habilidades ni capacidades de desarrollo, ya que la mayoría dela gente de TI era del entorno de mainframe. En un partido de golf, De Haes escuchó a un amigo de otroBanco hablar de una extraordinaria empresa de desarrollo de software de Singapur que generaaplicaciones y brinda el servicio de e-banking.

El contrato fue redactado en base al acuerdo estándar de proveedores, negociado por De Haes yGuldentops y firmado por el CEO de TIBO. El departamento legal del Banco también revisó el contratoy se realizaron algunos cambios en aspectos legales. El acuerdo de nivel de servicio (SLA) del contratocubría:• El alcance del trabajo• Los tiempos para el desarrollo y la implantación• Desempeño, Seguimiento y Reporting• Roles y Responsabilidades• Pagos y Funcionalidades

El objetivo era que el contratista fuera el proveedor de servicios completos de e-banking, —incluyendofuncionalidad de front-office, interfaces con el back office y las funciones de Mesa de Ayuda (Soporte alCliente)— en dos etapas. En la primera, los clientes tendrían acceso a sus cuentas corrientes y de ahorros.Las próximas funciones a ser integradas en la aplicación Web serían Préstamos y Tarjetas de Crédito. Lainfraestructura de back-office había sido desarrollada internamente y estaba operativa.

Cuando la aplicación se puso operativa, todo funcionó correctamente para el reducido volumen deusuarios (5% de la base de clientes). Luego de seis meses, cuando el número de usuarios seincrementó, comenzaron los problemas con la calidad del servicio:• Insatisfactorio tiempo de respuesta• Clientes podían acceder al sistema solo durante ciertos momentos en el día (disponibilidad del

sistema)• Ocasionalmente, las transacciones no se procesaban o se procesaban de manera errónea.

Como resultado, la Mesa de Ayuda recibió un número creciente de preguntas y reclamaciones. Elproveedor informaba estas incidencias mensualmente y generaba facturas adicionales dado el incrementodel trabajo en la Mesa de Ayuda. Hasta ahora, estos problemas no habían escalado por encima del niveloperativo, donde eran resueltos por TI y personal del área de BP haciendo horas extras.

Antes de llamar a Guldentops, el COO, en Manila para informarle del estado del problema con el We-BOP, De Haes reflexionó acerca de la pobre Doano, administradora de seguridad, quien estaba totalmente

3Chief Information Security Officer



saturada con el desarrollo de procedimientos de seguridad, la familiarización con las herramientas deseguridad, la administración de contraseñas para los usuarios del área de BP que querían acceso a todo yla generación de informes que no proveían la información que se necesitaba y que eran leídos por pocos.

Mientras sonaba el teléfono, De Haes también comenzó cambiar mentalmente la agenda prevista para eldía siguiente. Iba a tener que hablar con Dean y su gente acerca de su falta de reacción a las alertas delCortafuegos y también con O’Donnell, quien aparentemente sabía que las debilidades existían. Y,también estaba la poco deseada reunión para revisar prioridades de proyectos con Van Grembergen. DeHaes necesitaba que encontrar la manera de convencerlos de lo poco razonable de sus expectativas.Finalmente, Guldentops contestó el teléfono.

“Hola Erik, sé que es cerca de medianoche en Manila, pero tenemos un problema GORDO...”

EL PERFIL DE TIBO

TIBO es una Institución financiera de tamaño medio con las siguientes características: El “corazón” de su negocio incluye la banca de individuos—cuentas de ahorro, cuentas corrientes,

préstamos y tarjetas de crédito— así como realizar servicios de compensación y liquidación paraotros bancos de la zona. Una de sus fortalezas ha sido la atención personalizada a sus clientes de partede los gerentes de cuenta de la banca personal.

Está reduciendo su red de agencias y persiguiendo agresivamente el negocio de e-banking. Está comenzando a adquirir servicios de TI de terceros (subcontratos o UTEs). Ha pasado por varias fusiones locales y como resultado tiene un entorno complejo con servicios

compartidos de IT que son difíciles de integrar. Es una organización orientada a los procesos con una cultura emergente de incorporación de

“stakeholders”, pero sin una estrategia formal y tendencia a cambiar prioridades luego de prolongadosdebates con dichos stakeholders.

Está compitiendo en un Mercado que está sufriendo numerosos cambios, incluyendo la crecientepresencia de entidades de Ahorro y Préstamo y Bancos Internacionales. Nuevos productos estánsiendo incorporados por la competencia –incluyendo tasas de interés más elevadas- que son muyatractivas para los clientes. Adicionalmente, se empieza a notar la proliferación de oferta de serviciosfinancieros con acceso 24/7.

Posee una base de clientes fiel, buenos ingresos y sus adquisiciones hasta ahora han sido exitosas,pero los efectos del incremento de la competencia se están haciendo sentir. Hay preocupaciónrespecto de pérdida de Mercado y disminución de beneficios.

Es consciente de indicadores que los Reguladores están preocupados por el riesgo sistémico, ya queTIBO provee servicios de compensación y pagos a otras entidades financieras.



EL ENTORNO TI DE LA EMPRESA

ProyectosLos proyectos de TIBO incluyen: We-BOP En la actualidad (parcialmente implementado y subcontratado), incluye el acceso de

clientes a aplicaciones de ahorros y cuentas corrientes; próximamente se implementarán los módulosde préstamos y tarjetas; todos con una única interface para el cliente.

Customer relationship management (CRM)—Tendrá como objetivo disponer de toda la informaciónde clientes en un solo sitio para permitir la venta cruzada de productos, facilitar la gestión de losgerentes de cuenta y empleados de sectores de soporte a clientes.

Core business applications rebuilding (CoBAR) —Incluye primariamente las aplicaciones deAhorros, Cheques y Préstamos

IT_Net—Expansión de la Red de IT y plataformas de aplicaciones estandarizadas. For_Pay—Servicios de pagos al Exterior Work_it—Aplicación Workflow y conectividad remota para Gerentes de Cuenta

TecnologíaEl ambiente de TI consiste de tres plataformas distintas. La plataforma mainframe provee las aplicacionesprimarias del negocio y financieras del CoBAR; incluyen ahorro, cheques, préstamos, fideicomiso, bancapersonal e interfacecon tarjetas de crédito (alianza con una de las grandes compañías de tarjetas). Todasson aplicaciones en tiempo real, con procesos nocturnos de actualización. Las aplicaciones decompensación y liquidación así como las contables – balance, cuentas a pagar, activos inmovilizados yconciliaciones bancarias – operan también en el mainframe. Esta plataforma de mainframe también seutiliza para ForPay, como un servicio a otros bancos.

Un nuevo entorno Cliente-Servidor que consiste de 5 servers UNIX, formarán la base para lanueva aplicación CRM, que está en una etapa inicial de desarrollo.

La conectividad al sistema corporativo está provista por IT_Net, que es una red virtual privada(VPN), provista por el proveedor de telecomunicaciones de la empresa. En términos generales, lainfraestructura de red está envejeciendo y al límite de su capacidad. Solamente los seniormanagers tienen portátiles.

La red de PCs, involucra servidores Windows utilizados como servidores de datos, impresión,servicios de comunicación y gateway. Las estaciones de trabajo corren bajo Windows. Esta es laplataforma para la aplicación Work_it. La conectividad remota se introducirá basada en lafuncionalidad disponible en IT_Net.

El acceso al mainframe se otorga por un sistema de administración de seguridad. La seguridad UNIXestá provista por el sistema operativo del Host; no se utilizan herramientas de seguridad propietarias.Los contrafuegos son instalados y gestionados por el proveedor de IT_Net, como un serviciocontratado.

La casa Central tiene aproximadamente 600 empleados. A nivel nacional, la corporación empleaaproximadamente 9,000 personas, de las cuales 450 están en TI. Los servicios de TI son críticos paratodos los 600 empleados de la Casa Central.



Estándares y ProcedimientosLos procedimientos de TI son desarrollados internamente, y varían en calidad y conformación entre lasdiferentes áreas de TI. El desarrollo de la estrategia de TI es relativamente informal; está basada endiscusiones con la gerencia y documentada a través de minutas de reunión, en lugar de procesosdeterminados o formatos estándar. TI querría mayores directivas de las áreas de negocio y la DirecciónEjecutiva, pero las decisiones estratégicas se toman a nivel de cada proyecto.La organización de TI es bastante tradicional, con un grupo de desarrollo de sistemas, un grupo deoperaciones y un grupo de sistemas y tecnología. El grupo gerencial consiste de un gerente por cada unode los tres grupos, más el Director del Área.

Los desarrollos de sistemas son mayoritariamente internos, basados en el mainframe, con unametodología de ciclo de vida de desarrollo de sistemas (SDLC) adquirida varios años atrás y ajustada a lamedida del Banco. En los últimos años estos métodos han demostrado estar obsoletos y ser muylaboriosos para llevar a cabo. No obstante, al menos se han asegurado contar con una razonabledocumentación de los sistemas. Hay muy poca experiencia en adquisición de paquetes. Muy pocaspersonas tienen alguna experiencia con sistemas Cliente-Servidor y ninguna tiene experiencia endesarrollos web.

Operaciones está bien organizada, con buena disciplina y procedimientos estrictos. Generalmente, todo eltrabajo es tratado con alta prioridad. Hay turnos cubriendo operaciones las 24 horas del día, con unpequeño grupo nocturno que gestiona los procesos de batch nocturnos. Los acuerdos de nivel de serviciointernos (SLAs) están definidos en términos técnicos y en realidad son declaraciones de nivel de servicio;por ejemplo, disponibilidad objetivo y requerimientos de capacidad de la red. Hay una pequeña Mesa deAyuda interna, utilizada mayoritariamente para ocasionales consultas de usuarios y restauración decontraseñas.

SeguridadLa seguridad está basada en un procedimiento de larga data, el cual está basado a su vez en el tradicionalsistema de administración de seguridad de mainframes. Las estaciones de trabajo no poseen unidades dediskette o CD.La política de seguridad, simple pero no muy actualizada, establece las responsabilidadesgenerales y la importancia de la privacidad y seguridad de los datos del banco. TI tiene serversendurecidos, cortafuegos, encriptación y una VPN. La autenticación de usuarios basada en Tokens estásustentada por una política de seguridad de amplio cumplimiento. Existe un pequeño grupo de soporteadministrativo a la seguridad que gestiona los nuevos empleados, las bajas y los cambios de derechos deacceso. No existe un Gerente de Seguridad dedicado, aunque el administrador de seguridad es elresponsable de la asignación y gestión de privilegios. Debido a las presiones del negocio y el entornotecnológico, el personal tiende a ser laxo respecto de las reglas de seguridad. La seguridad aún segestiona en modo reactivo y el banco ha solicitado ayudas puntuales y asesoramiento a terceros. Previo aesta situación, la opinión generalizada es que ha habido pocos eventos dignos de preocupación.

LA ESTRUCTURA ORGANIZATIVA

Las siguientes secciones describen las entidades encontradas en TIBO.

Consejo de Administración (Board of Directors)El Consejo de TIBO tiene los siguientes atributos: El Consejero Delegado (Chariman of the Board) no está involucrado en la operación del día a día. Está compuesto por miembros internos y externos; la mayoría de los miembros del Comité de



Auditoría son externos. Los miembros no tienen muchos conocimientos técnicos, pero son conscientes del riesgo y se

interesan por lo que hace el resto.

Comité EjecutivoSus miembros tienen los siguientes atributos: Tienen gran influencia sobre el Consejo, pero necesitan la cooperación de los miembros externos. Sus metas son lograr resultados y son, en cierta manera, proclives a correr riesgos. Está compuesto por el Chief Exective Officer (CEO), Chief Financial Officer (CFO), Chief Operating

Officer (COO) y un Director del negocio. TI se encuentra dentro de las responsabilidades del COO. El Control no está muy alto en su lista de prioridades, pero escuchan a Auditoría y apoyan la

implantación de recomendaciones. Recientemente, apoyaron el desarrollo del sistema de banca por Internet.

Grupo de Estrategia de NegocioTiene los siguientes atributos: Reporta al Director de Negocios y no posee inclinación hacia las tecnologías. Sus mayores prioridades son el CRM y el proyecto CRM. Acaba de finalizar un proceso de redimensionamiento, reduciendo en un 50% el número de Agencias. Ha realizado un estudio comparativo (Benchmark) del costo del TI para el área de Negocios y

concluido que el sector interno de TI es mas caro que en la competencia. Quiere un valor neto presente positivo (NPV) para inversiones significativas en infraestructuras de TI.

Las iniciativas estratégicas en curso son: Cierre de Agencias de bajo rendimiento (casi completado). Sistema de banca por Internet (We-BOP), para descargar la demanda de servicios en las Agencias (en

curso). Desarrollar capacidades de CRM para crear oportunidades de venta cruzada de servicios bancarios

(proyecto iniciado).

Comité de Coordinación de TIEste Comité involucra una mezcla de Gerentes de TI y áreas usuarias (ver figura 2). Se reúnemensualmente y se ocupa primariamente del control de proyectos actuales y futuros. Reportatrimestralmente al Grupo de Estrategias de Negocio. Ha estado muy poco involucrado con el We-BOPdado a que su desarrollo y operación están subcontratados.

Dirección de TIEl Director de TI y el equipo gerencial: Muy técnicos y deseosos de dejar una impronta en el e-business, específicamente a través del We-

BOP, al cual soportan enteramente. Preocupados por la antigüedad / capacidad de la Red, en vista del proyecto de e-banking Apoyan firmemente fuertes controles sobre TI Concuerdan en que es necesario mayor cooperación con el Grupo de Estrategias de Negocio, que

generalmente apoya las prioridades de proyectos de la Dirección de TI, pero con quien no siemprehay acuerdo respecto de las prioridades.

Firmes creyentes que los sistemas centrales actuales pueden soportar el negocio por varios años, seponen molestos cuando se trata el tema de la reconstrucción de dichos sistemas.



Equipos de trabajos de TILos Equipos de TI de TIBO: Profesionales altamente calificados y muy orientados a la calidad; han implantado un sólido proceso

de control de proyectos y medición de desempeño. Sin embargo, este es demasiado detallado y seutiliza solamente a nivel local.

Continuamente dispersos por temas de gestión de cambios, como resultado de los permanentescambios a las aplicaciones y la infraestructura.

Preocupados por la velocidad de los cambios, especialmente la contratación externa y proyectosauspiciados por los responsables del Negocio, que no siempre son comercialmente exitosos y utilizanrecursos necesarios para inversiones necesarias de infraestructura, tales como la nueva Red paraincrementar la conectividad y estandarizar las soluciones.

Preocupados también por el incremento de los problemas de mantenimiento y la escasez dehabilidades disponibles relacionadas con los sistemas centrales; sensación de frustración creciente.

Operación del NegocioLos Ejecutivos son / están: Adquiriendo conocimientos de TI y un poco celosos que TI conserve su presupuesto, mientras que

ellos deben redimensionarse. Reclamando mayor conectividad remota y flujos de trabajo (Workflow) automatizados para ser más

efectivos en una red de Agencias reducida. Protestando por el rendimiento y el soporte de los sistemas centrales y promoviendo la celebración de

SLAs y la reconstrucción de los mismos por ser prácticamente obsoletos. Requiriendo conectar cada vez mas clientes de e-banking aunque no sean rentables en lo

inmediato, tensando los sistemas de operación y soporte.



Figura 3—Acuerdo de Nivel de Servicio del Contrato de Outsourcing

We-BOPRevisión Fecha Descripción Páginas afectadas1.0 Febrero 200x Primera Edición Todas

Propósito de este DocumentoEste documento constituye un acuerdo entre el contratantey una tercera parte, definidas en la próxima Sección, para eldesarrollo de un servicio completo de e-bankingdenominado aquí como “We-BOP.”. Detalla el entorno, lasexpectativas, los entregables y las responsabilidadesasociadas con la implementación de este acuerdo.Partes del Acuerdo

Este acuerdo, fechado en Febrero de 200x, es entre TIBO©

con oficinas situadas en …. (a partir de aquí, denominado“el contratante”) y ….., con oficinas ubicadas en ……(apartir de aquí denominado “el proveedor”).Alcance del TrabajoEl alcance de este acuerdo es para que el proveedordesarrolle un servicio complete de e-banking, We-BOP.Este servicio incluye: El desarrollo de una aplicación web de cara al cliente

(front office) con la siguiente funcionalidad:– Acceso a cuentas de ahorro– Access a cuentas corrientes– Administración de Tarjetas de Crédito– Administración de Préstamos

El desarrollo de interfaces del front office con laretaguardia (back office) del contratante.

Establecimiento de una Mesa de Ayuda como soporte aclientes (help desk) de la aplicación desarrollada, We-BOP.

Definición de Fechas de entrega para el Desarrollo eImplementaciónLa aplicación We-BOP y su interface se desarrollarán endos fases: Fase 1: Estará operativo el 30 Abril 200x

– Aplicación web de cara al cliente que permita:Acceso a cuentas de ahorroAccess a cuentas corrientes

– La interface entre dicha aplicación y la retaguardiadel contratante– Mesa de Ayuda operativa para soporte al cliente

Fase 2: Operativa el 31 Marzo 200x+1– Funcionalidades extendidas de la aplicación web:

Tarjetas de CréditoPréstamos

Desempeño, Seguimiento y ReportingWe-BOPEl proveedor informará trimestralmente respecto deldesempeño del sistema We-BOP .El informe será enviado al Director de TI del contratante.Mesa de Ayuda El proveedor informará mensualmenterespecto de los pedidos a Mesa de Ayuda y cómo sesolucionan. Este informe será enviado al Director de TI delcontratante. El proveedor generará un fichero específico deerrores para el control y la gestión de errores reportados,que podrá ser accedido directamente por el contratante.Roles y ResponsabilidadesComunicación Los contactos y comunicaciones entre el

contratante y el proveedor se realizan por correoelectrónico, teléfono y reuniones regulares. El contratante yel proveedor deben comunicar su estructura organizativa (ysus cambios) mutuamente, a fin de que cada grupo puedamantener su lista de distribución actualizada. El contratantey el proveedor deben informarse mutuamente las ausenciasde personal no planificadas (reuniones, vacaciones,reemplazos, etc.).Responsabilidades del Contratante El contratante debeproporcionar al proveedor toda la información relacionadacon las especificaciones necesarias de su retaguardia (back-office) para establecer las interfaces con la aplicación web(front office). El proveedor debe ser informado decualquier cambio en la retaguardia que pudiera afectar lainterface. El contratante responderá rápidamente –dentro de5 días laborables- cualquier requerimiento del proveedorrespecto de información o decisiones que sonrazonablemente necesarias para que el proveedor puedadesarrollar el sistema y proveer los servicios.Responsabilidades del Proveedor El proveedor garantizaque el desarrollo del sistema We-BOP y la función de Mesade Ayuda serán realizadas de manera humana yprofesional, consistentes con los estándares razonablementeaplicables a este tipo de servicios.El proveedor no divulgará ninguna informaciónconfidencial respecto del contratante que pudieraobtener durante el proceso de desarrollo.Pagos y PenalidadesPara el desarrollo de la aplicación web, el contratanteabonará al proveedor como sigue:

25 % al inicio del proyecto50 % luego de la entrega de la Fase 125 % luego de la entrega de la Fase 2

Por la Mesa de Ayuda, el proveedor facturaráuna suma fija mensual de US $ xxxx.xx.Si la aplicación web no puede ser entregada enla fecha estipulada, el contratante facturará unapenalidad por día de demora de US $ xxxx.xx .Todos los importes a ser abonados por el contratante, en lamoneda de la factura, serán depositados en la cuentadesignada por el proveedor. Todas las facturas seránabonadas dentro de los 30 días de la fecha de la misma. Encaso contrario, el proveedor podrá agregar un cargoadministrativo de 1.5% a la factura correspondiente.

Firmas

CEO del Contratante FechaCEO del Proveedor Fecha

3. MATERIALS ADDICIONAL


EL ASUNTO DE LA SEGURIDAD

Preguntas1. En una llamada anónima al CFO, una persona manifiesta tener acceso a información de clientes

proveniente de los sistemas de la empresa y da pruebas de ello mediante un fax conteniendoinformación sensible (nombres, gerentes de cuenta, etc.) Analizar los riesgos de seguridad. Recomendar algunas buenas prácticas para mitigar los riesgos.

2. Se le informa que la filtración ha ocurrido en la empresa subcontratada y se le hace entrega de unacopia del actual (breve e inadecuado) acuerdo de nivel de servicio (SLA). Los datos se filtraron porqueel contratista utilizó datos reales y on-line, durante las pruebas de aceptación de la segunda fase de unainstalación de un servidor web inseguro. Defina qué debería haber incluido la Gerencia en el SLA en relación a la seguridad. Qué es lo que cree que realmente pasó que permitió que esa información se hiciera pública?

EL ASUNTO DE LA SUBCONTRATACION

Preguntas1. Se ha presentado aquí un detallado proceso de subcontratación. Evalúe el proceso. Describir los

problemas encontrados por TIBO o los riesgos a los que se enfrenta e identifique las mejores prácticasque, de haberse implementado podrían haber prevenido o aliviado dichos problemas y riesgos.

2. Identificar los roles que deberían jugar en el proceso de Subcontratación la Auditoría, laDirección de TI y el CEO. Comparar estas mejores prácticas con los roles desempeñados.

EL ASUNTO DE LA ALINEACIÓN ESTRATEGICA

Información y Antecedentes AdicionalesLa estrategia del negocio está determinada por la estrategia del Grupo de Estrategia de Negocio, queestá compuesto por el CEO, los Vice Presidentes de operaciones minoristas y mayoristas y dosmiembros externos. Uno de los miembros externos es Charles Penrose, el ex-CEO de Accubank.Accubank se fusionó con TIBO hace 18 meses. El otro miembro externo es Nigel Sorrell. Nigel estambién miembro del Consejo de Administración.

El Grupo de Estrategia de Negocio se reúne el primer Martes de cada mes para revisar el progreso deiniciativas estratégicas en marcha y discutir la dirección estratégica del Banco. La información pararevisar el grado de avance se obtiene normalmente invitando al Gerente del Proyecto de la iniciativa encuestión a dar una breve presentación. El grupo trata de mantenerse actualizado y atento a eventos quepodrían alterar las prácticas de la industria. En concreto, el grupo ha estado pensando en:

Estrategias de Canales Tendencias actuales Retención y relación con Clientes

El Grupo de Estrategia de Negocio tiene excelentes procedimientos de documentación. Mantiene undocumento de iniciativas estratégicas que detalla cada una de las iniciativas, incluyendo gráficos de sugrado de avance. Este documento se distribuye al Consejo de Administración y al Comité Ejecutivo.

3. MATERIALS ADDICIONAL


El Comité Ejecutivo se reúne el primer Jueves de cada mes. La discusión de asuntos estratégicos es unpunto permanente de la Agenda del Comité. John Mitchell siempre se asegura que se le dedique laatención adecuada al tema de la dirección estratégica del Banco.

El Consejo de Administración se reúne trimestralmente (ver figura 4). Las iniciativas estratégicas estánsiempre dentro de los múltiples temas que se tratan en dichas reuniones.

Las decisiones estratégicas se delegan hacia niveles más bajos de la organización para su implementación.Por ejemplo, la iniciativa We-BOP se delegó en el Director de TI. El Director de TI le asignó a unGerente de Proyecto que comenzara a buscar soluciones alternativas y posibles para la iniciativa We-BOP. Este decidió que la manera más segura de ingresar al campo del e-banking era subcontratando estafuncionalidad.

Figura 4—Consejo y Grupo de Estrategia de Negocio

Consejo de Administración

Sir Alex Penfro-Hughes

CompanyChairman

John A. MitchellCEO

Sally SalonNon-executiveBoard Member

Nigel SorrellNon-executiveBoard Member

Roger DebrecenyCFO

ErikGuldentopsCOO

Roger LuxSenior VP ofWholesale

Wim VanGrembergenSenior VP of

Retail

Grupo deEstrategia de

Negocio

John A. Mitchell Nigel Sorrell Roger Lux Wim Van CharlesPenroseCEO Non-executive Senior VP of Grembergen Former CEO of

(Chair) Board Member Wholesale Senior VP of AccubankRetail (acquired 18 months ago)

Preguntas1. Analice las implicancias de gobierno en la forma en que el Consejo, el nivel Ejecutivo y la Dirección

de TI gestionaron el proceso de subcontratación. Cuáles serían las mejores prácticas para el gobiernode servicios prestados por terceros?

2. Porqué el CEO no estaba enterado de los reclamos de clientes antes de conocer el Informe delDefensor del Consumidor? Cómo se podría evitar esto en el futuro? Qué cambios en gobiernopropone para solucionar este problema?

3. Estando el Consejo a punto de comenzar con la iniciativa CRM, cómo se podría lograr una mayoralineación entre TI y la estrategia del negocio que la que fue evidente en la iniciativa We-BOP?

APPENDIX 1—FINANCIAL OMBUDSMAN SERVICE


El Servicio de Defensa del Consumidor Financiero (Financial Ombudsman Service) es unaagencia de regulación muy poderosa de Inglaterra que puede ayudarle si tiene una reclamaciónfinanciera que resolver con su: Banco Sociedad de Construcción Asesor Financiero Cooperativa de Crédito Compañía de Seguros Firma de Inversiones Agente de Bolsa Compañía de Fideicomiso

El Servicio de Defensa del Consumidor fue establecido por ley para proveer a los consumidores unservicio gratuito e independiente para resolver disputas con entidades financieras. Puede brindar ayudacon la mayoría de las reclamaciones relacionadas con:: Servicios bancarios Tarjetas de Crédito Políticas de Seguros de Inversión Asesoría financiera y de inversión Pólizas de Seguro Gestión de Fondos e Inversiones Seguros de Vida Hipotecas Planes de Pensión Planes y cuentas de ahorro Acciones y bonos

Puede imponer multas, pero el mayor impacto de dichos incidentes resulta de la publicación que se realizade los mismos.

APPENDIX 2—OBJETIVOS DE CONTROL Y MODELOS DE

MADUREZ DE COBIT


PO1 DEFINIR UN PLAN ESTRATEGICO PARA TI

Descripción del ProcesoSe requiere una planeación estratégica de TI para administrar y dirigir todos los recursos de TI de acuerdocon la estrategia del negocio y las prioridades. La función de TI y los participantes del negocio sonresponsables de garantizar que se materialice el valor óptimo de los portafolios de proyectos y servicios.El plan estratégico debe mejorar el entendimiento de los interesados clave respecto a las oportunidades ylimitaciones de TI, evaluar el desempeño actual y aclarar el nivel de inversión requerido. La estrategia denegocio y las prioridades se deben reflejar en los portafolios y deben ser ejecutadas por los planes tácticosde TI, los cuales establecen objetivos, planes y tareas específicas, entendidas y aceptadas tanto por elnegocio como por TI.

PO1.1 Administración del valor de TITrabajar con el negocio para garantizar que el portafolio de inversiones de TI de la empresa contengaprogramas con casos de negocio sólidos. Reconocer que existen inversiones obligatorias, de sustento ydiscrecionales que difieren en complejidad y grado de libertad en cuanto a la asignación de fondos. Losprocesos de TI deben proporcionar una entrega efectiva y eficiente de los componentes TI de losprogramas y advertencias oportunas sobre las desviaciones del plan, incluyendo costo, calendario ofuncionalidad, que pudieran impactar los resultados esperados de los programas. Los servicios de TI sedeben ejecutar contra acuerdos de niveles de servicios equitativos y exigibles. La rendición de cuentas dellogro de los beneficios y del control de los costos es claramente asignada y monitoreada. Establecer unaevaluación de los casos de negocio que sea justa, transparente, repetible y comparable, incluyendo elvalor financiero, el riesgo de no cumplir con una capacidad y el riesgo de no materializar los beneficiosesperados.

PO1.2 Alineación de TI con el negocioEducar a los ejecutivos sobre las capacidades tecnológicas actuales y sobre el rumbo futuro, sobre lasoportunidades que ofrece TI, y sobre qué debe hacer el negocio para capitalizar esas oportunidades.Asegurarse de que el rumbo del negocio al cual está alineado la TI está bien entendido. Las estrategias denegocio y de TI deben estar integradas, relacionando de manera clara las metas de la empresa y las metasde TI y reconociendo las oportunidades así como las limitaciones en la capacidad actual, y se debencomunicar de manera amplia. Identificar las áreas en que el negocio (estrategia) depende de forma críticade la TI, y mediar entre los imperativos del negocio y la tecnología, de tal modo que se puedan establecerprioridades concertadas.

PO1.3 Evaluación del desempeño actualEvaluar el desempeño de los planes existentes y de los sistemas de información en términos de sucontribución a los objetivos de negocio, su funcionalidad, su estabilidad, su complejidad, sus costos, susfortalezas y debilidades.

PO1.4 IT Plan estratégico de TICrear un plan estratégico que defina, en cooperación con los interesados relevantes, cómo la TIcontribuirá a los objetivos estratégicos de la empresa (metas) así como los costos y riesgos relacionados.Incluye cómo la TI dará soporte a los programas de inversión facilitados por TI y a la entrega de losservicios operacionales. Define cómo se cumplirán y medirán los objetivos y recibirá una autorizaciónformal de los interesados. El plan estratégico de TI debe incluir el presupuesto de la inversión / operativo,las fuentes de financiamiento, la estrategia de procuración, la estrategia de adquisición, y losrequerimientos legales y regulatorios. El plan estratégico debe ser lo suficientemente detallado para

APPENDIX 2

permitir la definición de planes tácticos de TI.

PO1.5 IT Planes tácticos de TICrear un portafolio de planes tácticos de TI que se deriven del plan estratégico de TI. Estos planestácticos describen las iniciativas y los requerimientos de recursos requeridos por TI, y cómo el uso de losrecursos y el logro de los beneficios serán monitoreados y administrados. Los planes tácticos deben tenerel detalle suficiente para permitir la definición de planes proyectados. Administrar de forma activa losplanes tácticos y las iniciativas de TI establecidas por medio del análisis de los portafolios de proyectos yservicios. Esto incluye el equilibrio de los requerimientos y recursos de forma regular, comparándolos conel logro de metas estratégicas y tácticas y con los beneficios esperados, y tomando las medidas necesariasen caso de desviaciones.

PO1.6 IT Administración del portafolio de TIAdministrar de forma activa, junto con el negocio, el portafolio de programas de inversión de TIrequerido para lograr objetivos de negocio estratégicos y específicos por medio de la identificación,definición, evaluación, asignación de prioridades, selección, inicio, administración y control de losprogramas. Esto incluye clarificar los resultados de negocio deseados, garantizar que los objetivos de losprogramas den soporte al logro de los resultados, entender el alcance completo del esfuerzo requeridopara lograr los resultados, definir una rendición de cuentas clara con medidas de soporte, definirproyectos dentro del programa, asignar recursos y financiamiento, delegar autoridad, y licenciar losproyectos requeridos al momento de lanzar el programa.

APENDICE 2


Modelo de MadurezAdministración del proceso de Definir un plan estratégico de TI que satisfaga el requisito denegocio de TI de sostener o extender la estrategia de negocio y los requerimientos de gobierno almismo tiempo que se mantiene la transparencia sobre los beneficios costos y riesgos es:0 No existente cuando

no se lleva a cabo la planeación estratégica de TI. No existe conciencia por parte de la gerencia deque la planeación estratégica de TI es requerida para dar soporte a las metas del negocio.

1 Inicial/Ad Hoc cuandoLa gerencia de TI conoce la necesidad de una planeación estratégica de TI. La planeación de TI serealiza según se necesite como respuesta a un requisito de negocio específico. La planeaciónestratégica de TI se discute de forma ocasional en las reuniones de la gerencia de TI. La alineaciónde los requerimientos de las aplicaciones y tecnología del negocio se lleva a cabo de modo reactivoen lugar de hacerlo por medio de una estrategia organizacional. La posición de riesgo estratégico seidentifica de manera informal proyecto por proyecto.

2 Repetible pero intuitiva cuandoLa planeación estratégica de TI se comparte con la gerencia del negocio según se necesite. Laactualización de los planes de TI ocurre como respuesta a las solicitudes de la dirección. Lasdecisiones estratégicas se toman proyecto por proyecto, sin ser consistentes con una estrategiaglobal de la organización. Los riesgos y beneficios al usuario, resultado de decisiones estratégicasimportantes se reconocen de forma intuitiva.

3 Proceso definido cuandoUna política define cómo y cuándo realizar la planeación estratégica de TI. La planeaciónestratégica de TI sigue un enfoque estructurado, el cual se documenta y se da a conocer a todo elequipo. El proceso de planeación de TI es razonablemente sólido y garantiza que es factible realizaruna planeación adecuada. Sin embargo, se otorga discrecionalidad a gerentes individualesespecíficos con respecto a la implantación del proceso, y no existen procedimientos para analizar elproceso. La estrategia general de TI incluye una definición consistente de los riesgos que laorganización está dispuesta a tomar como innovador o como seguidor. Las estrategias de recursoshumanos, técnicos y financieros de TI influencian cada vez más la adquisición de nuevos productosy tecnologías. La planeación estratégica de TI se discute en reuniones de la dirección del negocio.

4 Administrado y medible cuandoLa planeación estratégica de TI es una práctica estándar y las excepciones son advertidas por ladirección. La planeación estratégica de TI es una función administrativa definida conresponsabilidades de alto nivel. La dirección puede monitorear el proceso estratégico de TI, tomardecisiones informadas con base en el plan y medir su efectividad. La planeación de TI de corto ylargo plazo sucede y se distribuye en forma de cascada hacia la organización, y las actualizacionesse realizan según son necesarias. La estrategia de TI y la estrategia organizacional se vuelven cadavez más coordinadas al abordar procesos de negocio y capacidades de valor agregado y alaprovechar el uso de aplicaciones y tecnologías por medio de la re-ingeniería de procesos denegocio. Existen procesos bien definidos para determinar e uso de recursos internos y externosrequeridos en el desarrollo y las operaciones de los sistemas.

5 Optimizado cuandoLa planeación estratégica de TI es un proceso documentado y vivo, que cada vez más se toma encuenta en el establecimiento de las metas del negocio y da como resultado un valor observable denegocios por medio de las inversiones en TI. Las consideraciones de riesgo y de valor agregado seactualizan de modo constante en el proceso de planeación estratégica de TI. Se desarrollan planesrealistas a largo plazo de TI y se actualizan de manera constante para reflejar los cambiantesavances tecnológicos y el progreso relacionado al negocio. Se realizan evaluaciones porcomparación contra normas industriales bien entendidas y confiables y se integran con el proceso deformulación de la estrategia. El plan estratégico incluye cómo los nuevos avances tecnológicos

APENDICE 2


pueden impulsar creación de nuevas capacidades de negocio y mejorar la ventaja competitiva de laorganización.

APENDICE 2


PO9 EVALUAR Y ADMINISTRAR LOS RIESGOS DE TI

Descripción del ProcesoCrear y dar mantenimiento a un marco de trabajo de administración de riesgos. El marco de trabajodocumenta un nivel común y acordado de riesgos de TI, estrategias de mitigación y riesgos residualesacordados. Cualquier impacto potencial sobre las metas de la organización, causado por algún evento noplaneado se debe identificar, analizar y evaluar. Se deben adoptar estrategias de mitigación de riesgospara minimizar los riesgos residuales a un nivel aceptable. El resultado de la evaluación debe serentendible para los participantes y se debe expresar en términos financieros, para permitir a losparticipantes alinear los riesgos a un nivel aceptable de tolerancia..

PO9.1 Alineación de la administración de riesgos de TI y del negocioIntegrar el gobierno, la administración de riesgos y el marco de control de TI, al marco de trabajo deadministración de riesgos de la organización. Esto incluye la alineación con el apetito de riesgo y con elnivel de tolerancia al riesgo de la organización

PO9.2 Establecimiento del contexto del riesgoEstablecer el contexto en el cual el marco de trabajo de evaluación de riesgos se aplica para garantizarresultados apropiados. Esto incluye la determinación del contexto interno y externo de cada evaluaciónde riesgos, la meta de la evaluación y los criterios contra los cuales se evalúan los riesgos.

PO9.3 Identificación de eventosIdentificar todos aquellos eventos (amenazas y vulnerabilidades) con un impacto potencial sobre lasmetas o las operaciones de la empresa, aspectos de negocio, regulatorios, legales, tecnológicos, desociedad comercial, de recursos humanos y operativos. Determinar la naturaleza del impacto – positivo,negativo o ambos – y dar mantenimiento a esta información.

PO9.4 IT Evaluación de riesgosEvaluar de forma recurrente la posibilidad e impacto de todos los riesgos identificados, usando métodoscualitativos y cuantitativos. La posibilidad e impacto asociados a los riesgos inherentes y residuales sedebe determinar de forma individual, por categoría y con base en el portafolio.

PO9.5 Respuesta a los riesgosIdentificar los propietarios de los riesgos y a los dueños de procesos afectados, y elaborar y mantenerrespuestas a los riesgos que garanticen que los controles rentables y las medidas de seguridad mitigan laexposición a los riesgos de forma continua. La respuesta a los riesgos debe identificar estrategias deriesgo tales como evitar, reducir, compartir o aceptar. Al elaborar la respuesta, considerar los costos ybeneficios y seleccionar respuestas que limiten los riesgos residuales dentro de los niveles de toleranciade riesgos definidos.

PO9.6 Mantenimiento y monitoreo de un plan de acción de riesgosAsignar prioridades y planear las actividades de control a todos los niveles para implantar las respuestasa los riesgos, identificadas como necesarias, incluyendo la identificación de costos, beneficios y laresponsabilidad de la ejecución. Buscar la aprobación para las acciones recomendadas y la aceptación decualquier riesgo residual, y asegurarse de que las acciones comprometidas son propiedad del dueño (s) delos procesos afectados. Monitorear la ejecución de los planes y reportar cualquier desviación a la altadirección.

APENDICE 2


Modelo de MadurezLa administración del proceso de Evaluar y administrar los riesgos de TI que satisfaga el requisitode negocio de TI de analizar y comunicar los riesgos de TI y su impacto potencial sobre los procesos ylas metas de negocio es:0 No existente cuando

La evaluación de riesgos para los procesos y las decisiones de negocio no ocurre. La organización notoma en cuenta los impactos en el negocio asociados a las vulnerabilidades de seguridad y a lasincertidumbres del desarrollo de proyectos. La administración de riesgos no se ha identificado comoalgo relevante para adquirir soluciones de TI y para prestar servicios de TI

1 Inicial/Ad Hoc cuandoLos riesgos de TI se toman en cuenta de manera ad hoc. Se realizan evaluaciones informales deriesgos según lo determine cada proyecto. En algunas ocasiones se identifican evaluaciones de riesgosen un plan de proyectos pero se asignan a gerentes específicos con poca frecuencia. Los riesgosespecíficos relacionados con TI tales como seguridad, disponibilidad e integridad se toman en cuentaocasionalmente proyecto por proyecto. Los riesgos relativos a TI que afectan las operaciones del díacon día, son rara vez discutidas en reuniones gerenciales. Cuando se toman en cuenta los riesgos, lamitigación es inconsistente. Existe un entendimiento emergente de que los riesgos de TI sonimportantes y necesitan ser considerados.

2 Repetible pero intuitiva cuandoExiste un enfoque de evaluación de riesgos inmaduro y en evolución y se implanta a discreción de losgerentes de proyecto. La administración de riesgos se da por lo general a altos niveles y se aplica demanera típica solo a proyectos grandes o como respuesta a problemas. Los procesos de mitigación deriesgos están en implantación donde se identifican riesgos.

3 Proceso definido cuandoUna política de administración de riesgos para toda la organización define cuándo y cómo realizar lasevaluaciones de riesgos. La administración de riesgos sigue un proceso definido el cual estádocumentado. El entrenamiento sobre administración de riesgos está disponible para todo el personal.La decisión de seguir el proceso de administración de riesgos y de recibir entrenamiento se delega a ladiscreción del individuo. La metodología para la evaluación de riesgos es convincente y sólida, ygarantiza que los riesgos claves sean identificados. Un proceso para mitigar los riesgos clave por logeneral se institucionaliza una vez que los riesgos se identifican. Las descripciones de puestos tomanen cuenta las responsabilidades de administración de riesgos.

4 Administrado y medible cuandoLa evaluación y administración de riesgos son procesos estándar. Las excepciones al proceso deadministración de riesgos se reportan a la gerencia de TI. La administración de riesgos de TI es unaresponsabilidad de alto nivel. Los riesgos se evalúan y se mitigan a nivel de proyecto individual ytambién por lo regular se hace con respecto a la operación global de TI. La gerencia recibenotificación sobre los cambios en el ambiente de negocios y de TI que pudieran afectar de manerasignificativa los escenarios de riesgo relacionados con la TI. La gerencia puede monitorear la posiciónde riesgo y tomar decisiones informadas respecto a la exposición que está dispuesta a aceptar. Todoslos riesgos identificados tienen un propietario denominado, y la alta dirección, así como la gerenciade TI han determinado los niveles de riesgo que la organización está dispuesta a tolerar. La gerenciade TI ha elaborado medidas estándar para evaluar el riesgo y para definir las proporcionesriesgo/retorno. La gerencia presupuesta para que un proyecto operativo de administración de riesgosre-evalúe los riesgos de manera regular. Se establece una base de datos administrativa y parte delproceso de administración de riesgos se empieza a automatizar. La gerencia de TI toma en cuenta lasestrategias de mitigación de riesgo.

5 Optimizado cuandoLa administración de riesgos ha evolucionado al nivel en que un proceso estructurado está implantadoen toda la organización y es bien administrado. Las buenas prácticas se aplican en toda la

APENDICE 2


organización. La captura, análisis y reporte de los datos de administración de riesgos están altamenteautomatizados. La orientación se toma de los líderes en el campo y la organización de TI participa engrupos de interés para intercambiar experiencias. La administración de riesgos está altamenteintegrada en todo el negocio y en las operaciones de TI está bien aceptada, y abarca a los usuarios deservicios de TI. La dirección detectará y actuará cuando se realicen decisiones grandes de inversión,operación o de TI, sin tomar en cuenta el plan de administración de riesgos. La dirección evalúa lasestrategias de mitigación de riesgos de manera continua.

APENDICE 2


PO10 ADMINISTRAR ROYECTOS

Descripción del ProcesoEstablecer un programa y un marco de control administrativo de proyectos para la administración detodos los proyectos de TI. El marco de trabajo debe garantizar la correcta asignación de prioridades y lacoordinación de todos los proyectos. El marco de trabajo debe incluir un plan maestro, asignación derecursos, definición de entregables, aprobación de los usuarios, un enfoque de entrega por fases,aseguramiento de la calidad, un plan formal de pruebas, revisión de pruebas y revisión post-implantacióndespués de la implantación para garantizar la administración de los riesgos del proyecto y la entrega devalor para el negocio. Este enfoque reduce el riesgo de costos inesperados y de cancelación de proyectos,mejora la comunicación y el involucramiento del negocio y de los usuarios finales, asegura el valor y lacalidad de los entregables de los proyectos, y maximiza su contribución a los programas de inversión enTI.

P010.1 Marco de trabajo para la administración de programasMantener el programa de los proyectos, relacionados con el portafolio de programas de inversión en TI,por medio de la identificación, definición, evaluación, otorgamiento de prioridades, selección, inicio,administración y control de los proyectos. Asegurarse de que los proyectos apoyen los objetivos delprograma. Coordinar las actividades e interdependencias de múltiples proyectos, administrar lacontribución de todos los proyectos dentro del programa hasta obtener los resultados esperados, y resolverlos requerimientos y conflictos de recursos.

P010.2 Marco de trabajo para la administración de proyectosEstablecer y mantener un marco de trabajo para la administración de proyectos que defina el alcance y loslímites de la administración de proyectos, así como las metodologías a ser adoptadas y aplicadas a cadaproyecto emprendido. Las metodologías deben cubrir, como mínimo, el inicio, la planeación, laejecución, el control y el cierre de las etapas de los proyectos, así como los puntos de verificación y lasaprobaciones. El marco de trabajo y las metodologías de soporte se deben integrar con la administracióndel portafolio empresarial y con los procesos de administración de programas.

P010.3 Enfoque de administración de proyectosEstablecer un enfoque de administración de proyectos que corresponda al tamaño, complejidad yrequerimientos regulatorios de cada proyecto. La estructura de gobierno de proyectos puede incluir losroles, las responsabilidades y la rendición de cuentas del patrocinador del programa, patrocinadores delproyecto, comité de dirección, oficina de proyectos, y gerente del proyecto, así como los mecanismos pormedio de los cuales pueden satisfacer esas responsabilidades (tales como reportes y revisiones por etapa).Asegurarse que todos los proyectos de TI cuenten con patrocinadores con la suficiente autoridad paraapropiarse de la ejecución del proyecto dentro del programa estratégico global.

P010.4 Compromiso de los interesadosObtener el compromiso y la participación de los interesados afectados en la definición y ejecución delproyecto dentro del contexto del programa global de inversión en TI.

P010.5 Estatuto de alcance del proyectoDefinir y documentar la naturaleza y alcance del proyecto para confirmar y desarrollar, entre losinteresados, un entendimiento común del alcance del proyecto y cómo se relaciona con otros proyectosdentro del programa global de inversión en TI. La definición se debe aprobar de manera formal por partede los patrocinadores del programa y del proyecto antes de arrancar el proyecto.

APENDICE 2


P010.6 Inicio de las fases del proyectoAsegurarse que el arranque de las etapas importantes del proyecto se apruebe de manera formal y secomunique a todos los interesados. La aprobación de la fase inicial se debe basar en las decisiones degobierno del programa. La aprobación de las fases subsiguientes se debe basar en la revisión y aceptaciónde los entregables de la fase previa, y la aprobación de un caso de negocio actualizado en la próximarevisión importante del programa. En el caso de fases traslapadas, se debe establecer un punto deaprobación por parte de los patrocinadores del programa y del proyecto, para autorizar así el avance delproyecto.

P010.7 Plan integrado del proyectoEstablecer un plan integrado para el proyecto, aprobado y formal (que cubra los recursos de negocio y delos sistemas de información) para guiar la ejecución y el control del proyecto a lo largo de la vida del éste.Las actividades e interdependencias de múltiples proyectos dentro de un mismo programa se debenentender y documentar. El plan del proyecto se debe mantener a lo largo de la vida del mismo. El plan delproyecto, y las modificaciones a éste, se deben aprobar de acuerdo al marco de trabajo de gobierno delprograma y del proyecto.

P010.8 Recursos del proyectoDefinir las responsabilidades, relaciones, autoridades y criterios de desempeño de los miembros delequipo del proyecto y especificar las bases para adquirir y asignar a los miembros competentes del equipoy/o a los contratistas al proyecto. La obtención de productos y servicios requeridos para cada proyecto sedebe planear y administrar para alcanzar los objetivos del proyecto, usando las prácticas de adquisición dela organización.

P010.9 Administración de riesgos del proyectoEliminar o minimizar los riesgos específicos asociados con los proyectos individuales por medio de unproceso sistemático de planeación, identificación, análisis, respuestas, monitoreo y control de las áreas oeventos que tengan el potencial de ocasionar cambios no deseados. Los riesgos afrontados por el procesode administración de proyectos y el producto entregable del proyecto se deben establecer y registrar deforma central.

PO10.10 Plan de calidad del proyectoPreparar un plan de administración de la calidad que describa el sistema de calidad del proyecto ycómo será implantado. El plan debe ser revisado y acordado de manera formal por todas las partesinteresadas para luego ser incorporado en el plan integrado del proyecto.

PO10.11 Control de cambios del proyectoEstablecer un sistema de control de cambios para cada proyecto, de tal modo que todos los cambios a lalínea base del proyecto (ej. costos, cronograma, alcance y calidad) se revisen, aprueben e incorporen demanera apropiada al plan integrado del proyecto, de acuerdo al marco de trabajo de gobierno delprograma y del proyecto.

PO10.12 Planeación del proyecto y métodos de aseguramiento Identificar las tares deaseguramiento requeridas para apoyar la acreditación de sistemas nuevos o modificados durante laplaneación del proyecto e incluirlos en el plan integrado. Las tareas deben proporcionar la seguridad deque los controles internos y las características de seguridad satisfagan los requerimientos definidos.

PO10.13 Medición del desempeño, reportes y monitoreo del proyecto Medir el desempeño delproyecto contra los criterios clave del proyecto (ej. alcance, calendario, calidad, costos y riesgos);identificar las desviaciones con respecto al plan; evaluar su impacto sobre el proyecto y sobre elprograma global; reportar los resultados a los interesados clave; y recomendar, implantar y monitorear

APENDICE 2


las medidas correctivas, según sea requerido, de acuerdo con el marco de trabajo de gobierno delprograma y del proyecto.

PO10.14 Cierre del proyectoSolicitar que al finalizar cada proyecto, los interesados del proyecto se cercioren de que el proyectohaya proporcionado los resultados y los beneficios esperados. Identificar y comunicar cualquieractividad sobresaliente requerida para alcanzar los resultados planeados del proyecto y los beneficiosdel programa, e identificar y documentar las lecciones aprendidas a ser usadas en futuros proyectos yprogramas

APENDICE 2

I T G O V E R N A N C E I N S T I T U T E 30

Modelo de MadurezLa administración del proceso de Administrar proyectos que satisfaga el requisito de negocio de TIde entregar los resultados del proyecto en el tiempo, con el presupuesto y con la calidad acordados es:0 No existente cuando

Las técnicas de administración de proyectos no se usan y la organización no toma en cuenta losimpactos al negocio asociados con la mala administración de los proyectos y con las fallas dedesarrollo en el proyecto.

1 Inicial/Ad Hoc cuandoEl uso de técnicas y enfoques de administración de proyectos dentro de TI es una decisión individualque se deja a los gerentes de TI. Existe una carencia de compromiso por parte de la gerencia hacia lapropiedad de proyectos y hacia la administración de proyectos. Las decisiones críticas sobreadministración de proyectos se realizan sin la intervención de la gerencia usuaria ni del cliente. Haypoca o nula participación del cliente y del usuario para definir los proyectos de TI. No hay unaorganización clara dentro de TI para la administración de proyectos. Los roles y responsabilidadespara la administración de proyectos no están definidas. Los proyectos, calendarios y puntos claveestán definidos pobremente, si es que lo están. No se hace seguimiento al tiempo y a los gastos delequipo del proyecto y no se comparan con el presupuesto.

2 Repetible pero intuitiva cuandoLa alta dirección ha obtenido y comunicado la conciencia de la necesidad de una administración delos proyectos de TI. La organización está en proceso de desarrollar y utilizar algunas técnicas ymétodos de proyecto a proyecto. Los proyectos de TI han definido objetivos técnicos y de negocio demanera informal. Hay participación limitada de los interesados en la administración de los proyectosde TI. Las directrices iniciales se han elaborado para muchos aspectos de la administración deproyectos. La aplicación a proyectos de las directrices administrativas se deja a discreción del gerentede proyecto.

3 Proceso definido cuandoEl proceso y la metodología de administración de proyectos de TI han sido establecidos ycomunicados. Los proyectos de TI se definen con los objetivos técnicos y de negocio adecuados. Laalta dirección del negocio y de TI, empiezan a comprometerse y a participar en la administración delos proyectos de TI. Se ha establecido una oficina de administración de proyectos dentro de TI, conroles y responsabilidades iniciales definidas. Los proyectos de TI se monitorean, con puntos clave,calendarios y mediciones de presupuesto y desempeño definidos y actualizados. Existe entrenamientopara la administración de proyectos. El entrenamiento en administración de proyectos es un resultadoprincipalmente de las iniciativas individuales del equipo. Los procedimientos de aseguramiento decalidad y las actividades de implantación post-sistema han sido definidos, pero no se aplican demanera amplia por parte de los gerentes de TI. Los proyectos se empiezan a administrar comoportafolios.

4 Administrado y medible cuandoLa gerencia requiere que se revisen métricas y lecciones aprendidas estandarizadas y formalesdespués de terminar cada proyecto. La administración de proyectos se mide y evalúa a través de laorganización y no solo en TI. Las mejoras al proceso de administración de proyectos se formalizan ycomunican y los miembros del equipo reciben entrenamiento sobre estas mejoras. La gerencia de TIha implantado una estructura organizacional de proyectos con roles, responsabilidades y criterios dedesempeño documentados. Los criterios para evaluar el éxito en cada punto clave se han establecido.El valor y el riesgo se miden y se administran, antes, durante y al final de los proyectos. Cada vezmás, los proyectos abordan las metas organizacionales, en lugar de abordar solamente las específicasa TI. Existe un apoyo fuerte y activo a los proyectos por parte de los patrocinadores de la altadirección, así como de los interesados. El entrenamiento relevante sobre administración de proyectosse planea para el equipo en la oficina de proyectos y a lo largo de la función de TI.

5 Optimizado cuando

APENDICE 2

I T G O V E R N A N C E I N S T I T U T E 31

Se encuentra implantada una metodología comprobada de ciclo de vida de proyectos, la cual serefuerza y se integra en la cultura de la organización completa. Se ha implantado una iniciativacontinua para identificar e institucionalizar las mejores prácticas de administración de proyectos. Seha definido e implantado una estrategia de TI para contratar el desarrollo y los proyectos operativos.La oficina integrada de administración de proyectos es responsable de los proyectos y programasdesde su concepción hasta su post-implantación. La planeación de programas y proyectos en toda laorganización garantiza que los recursos de TI y del usuario se utilizan de la mejor manera para apoyar lasiniciativas estratégicas.

APENDICE 2


AI2 ADQUIRIR Y MANTENER SOFTWARE APLICATIVO

Descripción del ProcesoLas aplicaciones deben estar disponibles de acuerdo con los requerimientos del negocio. Este procesocubre el diseño de las aplicaciones, la inclusión apropiada de controles aplicativos y requerimientos deseguridad, y el desarrollo y la configuración en sí de acuerdo a los estándares. Esto permite a lasorganizaciones apoyar la operatividad del negocio de forma apropiada con las aplicaciones automatizadascorrectas.

AI2.1 Diseño de alto nivelTraducir los requerimientos del negocio a una especificación de diseño de alto nivel para desarrollo desoftware, tomando en cuenta las directivas tecnológicas y la arquitectura de información dentro de laorganización, y aprobar las especificaciones de diseño para garantizar que el diseño de alto nivel respondea los requerimientos.

AI2.2 Diseño detalladoPreparar el diseño detallado y los requerimientos técnicos del software de aplicación. Definir el criterio deaceptación de los requerimientos. Aprobar los requerimientos para garantizar que corresponden al diseñode alto nivel. Los conceptos a considerar incluyen, pero no se limitan a, definir y documentar losrequerimientos de entrada de datos, definir interfaces, la interface de usuario, el diseño para larecopilación de datos fuente, la especificación de programa, definir y documentar los requerimientos dearchivo, requerimientos de procesamiento, definir los requerimientos de salida, control y auditabilidad,seguridad y disponibilidad, y pruebas. Realizar una reevaluación para cuando se presenten discrepanciastécnicas o lógicas significativas durante el desarrollo o mantenimiento.

AI2.3 Control y auditabilidad de las aplicacionesAsegurar que los controles del negocio se traduzcan correctamente en controles de aplicación de maneraque el procesamiento sea exacto, completo, oportuno, aprobado y auditable. Los aspectos que seconsideran especialmente son: mecanismos de autorización, integridad de la información, control deacceso, respaldo y diseño de pistas de auditoría.

AI2.4 Seguridad y disponibilidad de las aplicaciones.Abordar la seguridad de las aplicaciones y los requerimientos de disponibilidad en respuesta a los riesgosidentificados, de acuerdo con la clasificación de datos, la arquitectura de seguridad en la información dela organización y el perfil de riesgo. Los asuntos a considerar incluyen derechos de acceso yadministración de privilegios, protección de información sensible en todas las etapas, autenticación eintegridad de las transacciones y recuperación automática. .

AI2.5 Configuración e implantación de software aplicativo adquiridoPersonalizar e implantar la funcionalidad automatizada adquirida con el uso de procedimientos deconfiguración, aceptación y prueba. Los aspectos a considerar incluyen la validación contra los términoscontractuales, la arquitectura de información de la organización, las aplicaciones existentes, lainteroperabilidad con las aplicaciones existentes y los sistemas de bases de datos, la eficiencia en eldesempeño del sistema, la documentación y los manuales de usuario, integración y planes de prueba delsistema.

AI2.6 Actualizaciones importantes en sistemas existentesSeguir un proceso de desarrollo similar al de desarrollo de sistemas nuevos en el caso que se presentenmodificaciones importantes en los sistemas existentes, que resulten en un cambio significativo de los

APENDICE 2


diseños y/o funcionalidad actuales. Los aspectos a considerar incluyen análisis de impacto, justificacióncosto/beneficio y administración de requerimientos.

AI2.7 Desarrollo de software aplicativoGarantizar que la funcionalidad de automatización se desarrolla de acuerdo con las especificaciones dediseño, los estándares de desarrollo y documentación y los requerimientos de calidad. Aprobar y autorizarcada etapa clave del proceso de desarrollo de software aplicativo, dando seguimiento a la terminaciónexitosa de revisiones de funcionalidad, desempeño y calidad. Los aspectos a considerar incluyen aprobarlas especificaciones de diseño que satisfacen los requerimientos de negocio, funcionales y técnicos;aprobar las solicitudes de cambio; y confirmación de que el software aplicativo es compatible con laproducción y está listo para su migración. Además, garantizar que se identifican y consideran todos losaspectos legales y contractuales para el software aplicativo que desarrollan terceros.

AI2.8 Aseguramiento de la Calidad del SoftwareDesarrollar, implantar los recursos y ejecutar un plan de aseguramiento de calidad del software, paraobtener la calidad que se especifica en la definición de los requerimientos y en las políticas yprocedimientos de calidad de la organización. Los asuntos a considerar en el plan de aseguramiento decalidad incluyen especificar el criterio de calidad y los procesos de validación y verificación, incluyendoinspección, revisión de algoritmos y código fuente y pruebas.

AI2.9 Administración de los requerimientos de aplicacionesGarantizar que durante el diseño, desarrollo e implantación, se da seguimiento al estatus de losrequerimientos particulares (incluyendo todos los requerimientos rechazados), y que las modificaciones alos requerimientos se aprueban a través de un proceso establecido de administración de cambios.

AI2.10 Mantenimiento de software aplicativoDesarrollar una estrategia y un plan para el mantenimiento y liberación de aplicaciones de software. Losasuntos a considerar incluyen liberación planeada y controlada, planeación de recursos, reparación dedefectos de programa y corrección de fallas, pequeñas mejoras, mantenimiento de documentación,cambios de emergencia, interdependencia con otras aplicaciones e infraestructura, estrategias deactualización, condiciones contractuales tales como aspectos de soporte y actualizaciones, revisiónperiódica de acuerdo a las necesidades del negocio, riegos y requerimientos de seguridad.

APENDICE 2


Modelo de MadurezLa administración del proceso de Adquirir y mantener software aplicativo que satisfaga el requisitode negocio de TI de hacer disponibles aplicaciones de acuerdo con los requerimientos del negocio, entiempo y a un costo razonable es:0 No existente cuando

No existe un proceso de diseño y especificación de aplicaciones. Típicamente, las aplicaciones seobtienen con base en ofertas de proveedores, en el reconocimiento de la marca o en la familiaridaddel personal de TI con productos específicos, considerando poco o nada los requerimientos actuales.

1 Inicial/Ad Hoc cuandoExiste conciencia de la necesidad de contar con un proceso de adquisición y mantenimiento deaplicaciones. Los enfoques para la adquisición y mantenimientos de software aplicativo varían de unproyecto a otro. Es probable que se hayan adquirido en forma independiente una variedad desoluciones individuales para requerimientos particulares del negocio, teniendo como resultadoineficiencias en el mantenimiento y soporte. Se tiene poca consideración hacia la seguridad ydisponibilidad de la aplicación en el diseño o adquisición de software aplicativo.

2 Repetible pero intuitiva cuandoExisten procesos de adquisición y mantenimiento de aplicaciones, con diferencias pero similares, enbase a la experiencia dentro de la operación de TI. El mantenimiento es a menudo problemático y seresiente cuando se pierde el conocimiento interno de la organización. Se tiene poca consideraciónhacia la seguridad y disponibilidad de la aplicación en el diseño o adquisición de software aplicativo.

3 Proceso definido cuandoExiste un proceso claro, definido y de comprensión general para la adquisición y mantenimiento desoftware aplicativo. Este proceso va de acuerdo con la estrategia de TI y del negocio. Se intentaaplicar los procesos de manera consistente a través de diferentes aplicaciones y proyectos. Lasmetodologías son por lo general, inflexibles y difíciles de aplicar en todos los casos, por lo que esmuy probable que se salten pasos. Las actividades de mantenimiento se planean, programan ycoordinan.

4 Administrado y medible cuandoExiste una metodología formal y bien comprendida que incluye un proceso de diseño yespecificación, un criterio de adquisición, un proceso de prueba y requerimientos para ladocumentación. Existen mecanismos de aprobación documentados y acordados, para garantizar quese sigan todos los pasos y se autoricen las excepciones. Han evolucionado prácticas y procedimientospara ajustarlos a la medida de la organización, los utilizan todo el personal y son apropiados para lamayoría de los requerimientos de aplicación.

5 Optimizado cuandoLas prácticas de adquisición y mantenimiento de software aplicativo se alinean con el procesodefinido. El enfoque es con base en componentes, con aplicaciones predefinidas y estandarizadas quecorresponden a las necesidades del negocio. El enfoque se extiende para toda la empresa. Lametodología de adquisición y mantenimiento presenta un buen avance y permite un posicionamientoestratégico rápido, que permite un alto grado de reacción y flexibilidad para responder arequerimientos cambiantes del negocio. La metodología de adquisición e implantación de softwareaplicativo ha sido sujeta a mejora continua y se soporta con bases de datos internas y externas quecontienen materiales de referencia y las mejores prácticas. La metodología produce documentacióndentro de una estructura predefinida que hace eficiente la producción y mantenimiento

APENDICE 2


DS2 ADMINISTRAR LOS SERVICIOS DE TERCEROS

Descripción del ProcesoLa necesidad de asegurar que los servicios provistos por terceros cumplan con los requerimientos delnegocio, requiere de un proceso efectivo de administración de terceros. Este proceso se logra por mediode una clara definición de roles, responsabilidades y expectativas en los acuerdos con los terceros, asícomo con la revisión y monitoreo de la efectividad y cumplimiento de dichos acuerdos. Una efectivaadministración de los servicios de terceros minimiza los riesgos del negocio asociados con proveedoresque no se desempeñan de forma adecuada.

DS2.1 Identificación de las relaciones con todos los proveedoresIdentificar todos los servicios de los proveedores y catalogarlos de acuerdo con el tipo de proveedor, laimportancia y la criticidad. Mantener documentación formal de las relaciones técnicas y organizacionalesincluyendo los roles y responsabilidades, metas, expectativas, entregables esperados y credenciales de losrepresentantes de estos proveedores.

DS2.2 Administración de las relaciones con los proveedoresFormalizar el proceso de administración de relaciones con proveedores por cada proveedor. Losresponsables de las relaciones deben coordinar a los proveedores y los clientes y asegurar la calidad de lasrelaciones con base en la confianza y la transparencia (por ejemplo, a través de acuerdos de niveles deservicio).

DS2.3 Administración de riesgos del proveedorIdentificar y mitigar los riesgos relacionados con la habilidad de los proveedores para mantener unaefectiva entrega de servicios de forma segura y eficiente sobre una base de continuidad. Asegurar que loscontratos están de acuerdo con los estándares universales del negocio de conformidad con losrequerimientos legales y regulatorios. La administración del riesgo debe considerar además acuerdos deconfidencialidad (NDAs), contratos de garantía, viabilidad de la continuidad del proveedor, conformidadcon los requerimientos de seguridad, proveedores alternativos, penalizaciones e incentivos, etc.

DS2.4 Monitoreo del desempeño del proveedorEstablecer un proceso para monitorear la prestación del servicio para asegurar que el proveedor estácumpliendo con los requerimientos del negocio actuales y que se apega de manera continua a los acuerdosdel contrato y a los convenios de niveles de servicio, y que el desempeño es competitivo respecto a losproveedores alternativos y a las condiciones del mercado

APENDICE 2


Modelo de MadurezLa administración del proceso de Administrar los servicios de terceros que satisfagan losrequerimientos de TI del negocio de brindar servicios de terceros satisfactorios siendo transparentesrespecto a los beneficios, costos y riesgos es:0 No existente cuando

Las responsabilidades y la rendición de cuentas no están definidas. No hay políticas y procedimientosformales respecto a la contratación con terceros. Los servicios de terceros no son ni aprobados nirevisados por la gerencia. No hay actividades de medición y los terceros no reportan. A falta de unaobligación contractual de reportar, la alta gerencia no está al tanto de la calidad del servicio prestado.

1 Inicial/Ad Ho cuandoLa gerencia está consciente de la importancia de la necesidad de tener políticas y procedimientosdocumentados para la administración de los servicios de terceros, incluyendo la firma de contratos.No hay condiciones estandarizadas para los convenios con los prestadores de servicios. La mediciónde los servicios prestados es informal y reactiva. Las prácticas dependen de la experiencia de losindividuos y del proveedor (por ejemplo, por demanda).

2 Repetible pero intuitiva cuandoEl proceso de supervisión de los proveedores de servicios de terceros, de los riesgos asociados y de laprestación de servicios es informal. Se utiliza un contrato pro-forma con términos y condicionesestándares del proveedor (por ejemplo, la descripción de servicios que se prestarán). Los reportessobre los servicios existen, pero no apoyan los objetivos del negocio.

3 Proceso definido cuandoHay procedimientos bien documentados para controlar los servicios de terceros con procesos clarospara tratar y negociar con los proveedores. Cuando se hace un acuerdo de prestación de servicios, larelación con el tercero es meramente contractual. La naturaleza de los servicios a prestar se detalla enel contrato e incluye requerimientos legales, operacionales y de control. Se asigna la responsabilidadde supervisar los servicios de terceros. Los términos contractuales se basan en formatosestandarizados. El riesgo del negocio asociado con los servicios del tercero está valorado y reportado.

4 Administrado y medible cuandoSe establecen criterios formales y estandarizados para definir los términos de un acuerdo, incluyendoalcance del trabajo, servicios/entregables a suministrar, suposiciones, calendario, costos, acuerdos defacturación y responsabilidades. Se asignan las responsabilidades para la administración del contratoy del proveedor. Las aptitudes, capacidades y riesgos del proveedor son verificadas de formacontinua. Los requerimientos del servicio están definidos y alineados con los objetivos del negocio.Existe un proceso para comparar el desempeño contra los términos contractuales, lo cual proporcionainformación para evaluar los servicios actuales y futuros del tercero. Se utilizan modelos de fijaciónde precios de transferencia en el proceso de adquisición. Todas las partes involucradas tienenconocimiento de las expectativas del servicio, de los costos y de las etapas. Se acordaron los KPIs yKGIs para la supervisión del servicio.

5 Optimizado cuandoLos contratos firmados con los terceros son revisados de forma periódica en intervalos predefinidos.La responsabilidad de administrar a los proveedores y la calidad de los servicios prestados estáasignada. Se monitorea el cumplimiento de las condiciones operacionales, legales y de control y seimplantan acciones correctivas. El tercero está sujeto a revisiones periódicas independientes y se leretroalimenta sobre su desempeño para mejorar la prestación del servicio. Las mediciones varíancomo respuesta a los cambios en las condiciones del negocio. Las mediciones ayudan a la deteccióntemprana de problemas potenciales con los servicios de terceros. La notificación completa y biendefinida del cumplimiento de los niveles de servicio, está asociada con la compensación del tercero.La gerencia ajusta el proceso de adquisición y monitoreo de servicios de terceros con base en losresultados de los KPIs y KGIs.

APENDICE 2


DS5 GARANTIZAR LA SEGURIDAD DE LOS SISTEMAS

Descripción del ProcesoLa necesidad de mantener la integridad de la información y de proteger los activos de TI, requiere de unproceso de administración de la seguridad. Este proceso incluye el establecimiento y mantenimiento deroles y responsabilidades de seguridad, políticas, estándares y procedimientos de TI. La administración dela seguridad también incluye la monitorización de la seguridad y pruebas periódicas así como realizaracciones correctivas sobre las debilidades o incidentes de seguridad identificados. Una efectivaadministración de la seguridad protege todos los activos de TI para minimizar el impacto en el negociocausado por vulnerabilidades o incidentes de seguridad.

DS5.1 Administración de la seguridad de TIAdministrar la seguridad de TI al nivel más apropiado dentro de la organización, de manera que lasacciones de administración de la seguridad estén en línea con los requerimientos del negocio.

DS5.2 Plan de seguridad de TITrasladar los requerimientos de información del negocio, la configuración de TI, los planes de acción delriesgo de la información y la cultura sobre la seguridad en la información a un plan global de seguridad deTI. El plan se implementa en políticas y procedimientos de seguridad en conjunto con inversionesapropiadas en servicios, personal, software y hardware. Las políticas y procedimientos de seguridad secomunican a los interesados y a los usuarios.

DS5.3 Administración de identidadTodos los usuarios (internos, externos y temporales) y su actividad en sistemas de TI (aplicación denegocio, operación del sistema, desarrollo y mantenimiento) deben ser identificables de manera única.Los derechos de acceso del usuario a sistemas y datos deben estar alineados con necesidades de negociodefinidas y documentadas y con requerimientos de trabajo. Los derechos de acceso del usuario sonsolicitados por la gerencia del usuario, aprobados por el responsable del sistema e implementado por lapersona responsable de la seguridad. Las identidades del usuario y los derechos de acceso se mantienenen un repositorio central. Se implementan y se mantienen actualizadas medidas técnicas y procedimientosrentables, para establecer la identificación del usuario, realizar la autenticación y habilitar los derechos deacceso.

DS5.4 Administración de cuentas del usuarioGarantizar que la solicitud, establecimiento, emisión, suspensión, modificación y cierre de cuentas deusuario y de los privilegios relacionados, sean tomados en cuenta por la gerencia de cuentas de usuario.Debe incluirse un procedimiento que describa al responsable de los datos o del sistema como otorgar losprivilegios de acceso. Estos procedimientos deben aplicar para todos los usuarios, incluyendoadministradores (usuarios privilegiados), usuarios externos e internos, para casos normales y deemergencia. Los derechos y obligaciones relacionados al acceso a los sistemas e información de laempresa son acordados contractualmente para todos los tipos de usuarios. La gerencia debe llevar a cabouna revisión regular de todas las cuentas y los privilegios asociados.

DS5.5 Pruebas, vigilancia y monitoreo de la seguridadGarantizar que la implementación de la seguridad en TI sea probada y monitoreada de forma pro-activa.La seguridad en TI debe ser reacreditada periódicamente para garantizar que se mantiene el nivelseguridad aprobado. Una función de ingreso al sistema (logging) y de monitoreo permite la detecciónoportuna de actividades inusuales o anormales que pueden requerir atención. El acceso a la informaciónde ingreso al sistema está alineado con los requerimientos del negocio en términos de requerimientos deretención y de derechos de acceso.

APENDICE 2


DS5.6 Definición de incidente de seguridadGarantizar que las características de los posibles incidentes de seguridad sean definidas y comunicadas deforma clara, de manera que los problemas de seguridad sean atendidos de forma apropiada por medio delproceso de administración de problemas o incidentes. Las características incluyen una descripción de loque se considera un incidente de seguridad y su nivel de impacto. Un número limitado de niveles deimpacto se definen para cada incidente, se identifican las acciones específicas requeridas y las personasque necesitan ser notificadas.

DS5.7 Protección de la tecnología de seguridadGarantizar que la tecnología importante relacionada con la seguridad no sea susceptible de sabotaje y quela documentación de seguridad no se divulgue de forma innecesaria, es decir, que mantenga un perfilbajo. Sin embargo no hay que hacer que la seguridad de los sistemas dependa de la confidencialidad delas especificaciones de seguridad.

DS5.8 Administración de llaves criptográficasDeterminar que las políticas y procedimientos para organizar la generación, cambio, revocación,destrucción, distribución, certificación, almacenamiento, captura, uso y archivo de llaves criptográficasestén implantadas, para garantizar la protección de las llaves contra modificaciones y divulgación noautorizadas.

DS5.9 Prevención, detección y corrección de software maliciosoGarantizar que se cuente con medidas de prevención, detección y corrección (en especial contar conparches de seguridad y control de virus actualizados) a lo largo de toda la organización para proteger a lossistemas de información y a la tecnología contra software malicioso (virus, gusanos, spyware, correobasura, software fraudulento desarrollado internamente, etc.).

DS5.10 Seguridad de la redGarantizar que se utilizan técnicas de seguridad y procedimientos de administración asociados (porejemplo, firewalls, dispositivos de seguridad, segmentación de redes, y detección de intrusos) paraautorizar acceso y controlar los flujos de información desde y hacia las redes.

DS5.11 Intercambio de datos sensitivosGarantizar que las transacciones de datos sensibles sean intercambiadas solamente a través de una ruta omedio confiable con controles para brindar autenticidad de contenido, prueba de envío, prueba derecepción y no rechazo del origen.

APENDICE 2


Modelo de MadurezLa administración del proceso de Garantizar la seguridad de los sistemas que satisfaga elrequerimiento de negocio de TI de mantener la integridad de la información y de la infraestructurade procesamiento y minimizar el impacto de vulnerabilidades e incidentes de seguridad es:0 No-existente cuando

La organización no reconoce la necesidad de la seguridad para TI. Las responsabilidades y larendición de cuentas no están asignadas para garantizar la seguridad. Las medidas para soportar laadministrar la seguridad de TI no están implementadas. No hay reportes de seguridad de TI ni unproceso de respuesta para resolver brechas de seguridad de TI. Hay una total falta de procesosreconocibles de administración de seguridad de sistemas.

1 Inicial/Ad Hoc cuandoLa organización reconoce la necesidad de seguridad para TI. La conciencia de la necesidad deseguridad depende principalmente del individuo. La seguridad de TI se lleva a cabo de formareactiva. No se mide la seguridad de TI. Las brechas de seguridad de TI ocasionan respuestas conacusaciones personales, debido a que las responsabilidades no son claras. Las respuestas a lasbrechas de seguridad de TI son impredecibles.

2 Repetible pero intuitivo cuandoLas responsabilidades y la rendición de cuentas sobre la seguridad, están asignadas a un coordinadorde seguridad de TI, pero la autoridad gerencial del coordinador es limitada. La conciencia sobre lanecesidad de la seguridad esta fraccionada y limitada. Aunque los sistemas producen informaciónrelevante respecto a la seguridad, ésta no se analiza. Los servicios de terceros pueden no cumplir conlos requerimientos específicos de seguridad de la empresa. Las políticas de seguridad se han estadodesarrollando, pero las herramientas y las habilidades son inadecuadas. Los reportes de la seguridadde TI son incompletos, engañosos o no aplicables. La capacitación sobre seguridad está disponiblepero depende principalmente de la iniciativa del individuo. La seguridad de TI es vistaprimordialmente como responsabilidad y disciplina de TI, y el negocio no ve la seguridad de TIcomo parte de su propia disciplina.

3 Proceso definido cuandoExiste conciencia sobre la seguridad y ésta es promovida por la gerencia. Los procedimientos deseguridad de TI están definidos y alineados con la política de seguridad de TI. Las responsabilidadesde la seguridad de TI están asignadas y entendidas, pero no continuamente implementadas. Existe unplan de seguridad de TI y existen soluciones de seguridad motivadas por un análisis de riesgo. Losreportes no contienen un enfoque claro de negocio. Se realizan pruebas de seguridad adecuadas (porejemplo, pruebas contra intrusos). Existe capacitación en seguridad para TI y para el negocio, pero seprograma y se comunica de manera informal.

4 Administrado y Medible cuandoLas responsabilidades sobre la seguridad de TI son asignadas, administradas e implementadas deforma clara. Regularmente se lleva a cabo un análisis de impacto y de riesgos de seguridad. Laspolíticas y prácticas de seguridad se complementan con referencias de seguridad específicas. Elcontacto con métodos para promover la conciencia de la seguridad es obligatorio. La identificación,autenticación y autorización de los usuarios está estandarizada. La certificación en seguridad esbuscada por parte del personal que es responsable de la auditoría y la administración de la seguridad.Las pruebas de seguridad se hacen utilizando procesos estándares y formales que llevan a mejorar losniveles de seguridad. Los procesos de seguridad de TI están coordinados con la función de seguridadde toda la organización. Los reportes de seguridad están ligados con los objetivos del negocio. Lacapacitación sobre seguridad se imparte tanto para TI como para el negocio. La capacitación sobreseguridad de TI se planea y se administra de manera que responda a las necesidades del negocio y alos perfiles de riesgo de seguridad. Los KGIs y KPIs ya están definidos pero no se miden aún.

5 Optimizado cuandoLa seguridad en TI es una responsabilidad conjunta del negocio y de la gerencia de TI y está

APENDICE 2


integrada con los objetivos de seguridad del negocio en la corporación. Los requerimientos deseguridad de TI están definidos de forma clara, optimizados e incluidos en un plan de seguridadaprobado. Los usuarios y los clientes se responsabilizan cada vez más de definir requerimientos deseguridad, y las funciones de seguridad están integradas con las aplicaciones en la fase de diseño.Los incidentes de seguridad son atendidos de forma inmediata con procedimientos formales derespuesta soportados por herramientas automatizadas. Se llevan a cabo valoraciones de seguridad deforma periódica para evaluar la efectividad de la implementación del plan de seguridad. Lainformación sobre amenazas y vulnerabilidades se recolecta y analiza de manera sistemática. Serecolectan e implementan de forma oportuna controles adecuados para mitigar riesgos. Se llevan acabo pruebas de seguridad, análisis de causa-efecto e identificación pro-activa de riesgos para lamejora continua de procesos. Los procesos de seguridad y la tecnología están integrados a lo largo detoda la organización. Los KGIs y KPIs para administración de seguridad son recopilados ycomunicados. La gerencia utiliza los KGIs y KPIs para ajustar el plan de seguridad en un proceso demejora continua.

APENDICE 2


DS6 IDENTICAR Y ASIGNAR COSTOS

Descripción del ProcesoLa necesidad de un sistema justo y equitativo para asignar costos de TI al negocio, requiere de unamedición precisa y un acuerdo con los usuarios del negocio sobre una asignación justa. Este procesoincluye la construcción y operación de una sistema para capturar, distribuir y reportar costos de TI a losusuarios de los servicios. Un sistema equitativo de costos permite al negocio tomar decisiones másinformadas respectos al uso de los servicios de TI.

DS6.1 Definición de serviciosIdentificar todos los costos de TI y equipararlos a los servicios de TI para soportar un modelo decostos transparente. Los servicios de TI deben vincularse a los procesos del negocio de forma que elnegocio pueda identificar los niveles de facturación de los servicios asociados.

DS6.2 Contabilización de TIRegistrar y asignar los costos actuales de acuerdo con el modelo de costos definido. Las variacionesentre los presupuestos y los costos actuales deben analizarse y reportarse de acuerdo con los sistemasde medición financiera de la empresa.

DS6.3 Modelación de costos y cargosCon base en la definición del servicio, definir un modelo de costos que incluya costos directos,indirectos y fijos de los servicios, y que ayude al cálculo de tarifas de reintegros de cobro porservicio. El modelo de costos debe estar alineado con los procedimientos de contabilización de costosde la empresa. El modelo de costos de TI debe garantizar que los cargos por servicios sonidentificables, medibles y predecibles por parte de los usuarios para propiciar el adecuado uso derecursos. La gerencia del usuario debe poder verificar el uso actual y los cargos de los servicios.

DS6.4 Mantenimiento del modelo de costosRevisar y comparar de forma regular lo apropiado del modelo de costos/recargos para mantener surelevancia para el negocio en evolución y para las actividades de TI.

APENDICE 2


Modelo de MadurezLa administración del proceso de Identificar y asignar costos que satisfagan los requerimientos delnegocio de TI de transparentar y entender los costos de TI y mejorar la relación costo-eficiencia pormedio del uso bien informado de servicios de TI es:0 No-existente cuando

Hay una completa falta de cualquier proceso reconocible de identificación y distribución de costos enrelación a los servicios de información brindados. La organización no reconoce incluso que hay unproblema que atender respecto a la contabilización de costos y que no hay comunicación respecto aeste asunto.

1 Inicial/Ad Hoc cuandoHay un entendimiento general de los costos globales de los servicios de información, pero no hay unadistribución de costos por usuario, cliente, departamento, grupos de usuarios, funciones de servicio,proyectos o entregables. Es casi nulo el monitoreo de los costos, sólo se reportan a la gerencia loscostos agregados. La distribución de costos de TI se hace como un costo fijo de operación. Al negociono se le brinda información sobre el costo o los beneficios de la prestación del servicio.

2 Repetible pero intuitivo cuandoHay conciencia general de la necesidad de identificar y asignar costos. La asignación de costos estábasada en suposiciones de costos informales o rudimentarios, por ejemplo, costos de hardware, yprácticamente no hay relación con los generadores de valor. Los procesos de asignación de costospueden repetirse. No hay capacitación o comunicación formal sobre la identificación de costosestándar y sobre los procedimientos de asignación. No está asignada la responsabilidad sobre larecopilación o la asignación de los costos.

3 Proceso definido cuandoHay un modelo definido y documentado de costos de servicios de información. Se ha definido unproceso para relacionar costos de TI con los servicios prestados a los usuarios. Existe un nivelapropiado de conciencia de los costos atribuibles a los servicios de información. Al negocio se lebrinda información muy básica sobre costos.

4 Administrado y Medible cuandoLas responsabilidades sobre la administración de costos de los servicios de información están biendefinidas y bien entendidas a todos los niveles, y son soportadas con capacitación formal. Los costosdirectos e indirectos están identificados y se reportan de forma oportuna y automatizada a la gerencia,a los propietarios de los procesos de negocio y a los usuarios. Por lo general, hay monitoreo yevaluación de costos, y se toman acciones cuando se detectan desviaciones de costos. El reporte delcosto de los servicios de información está ligado a los objetivos del negocio y los acuerdos de nivelesde servicio, y son vigilados por los propietarios de los procesos de negocio. Una función financierarevisa que el proceso de asignación de costos sea razonable. Existe un sistema automatizado dedistribución de costos, pero se enfoca principalmente en la función de los servicios de información envez de hacerlo en los procesos de negocio. Se acordaron los KPIs y KGIs para mediciones de costos,pero son medidos de manera inconsistente.

5 Optimizado cuandoLos costos de los servicios prestados se identifican, registran, resumen y reportan a la gerencia, a lospropietarios de los procesos de negocio y a los usuarios. Los costos se identifican como productoscobrables y pueden soportar un sistema de cobro que cargue a los usuarios por los servicios prestados,con base en la utilización. Los detalles de costos soportan los acuerdos de niveles de servicio. Elmonitoreo y la evaluación del costo de los servicios se utilizan para optimizar el costo de los recursosde TI. Las cifras obtenidas de los costos se usan para verificar la obtención de beneficios y para elproceso de presupuesto de la organización. Los reportes sobre el costo de los servicios de informaciónbrindan advertencias oportunas de cambios en los requerimientos del negocio, por medio del uso desistemas de reporte inteligentes. Se utiliza un modelo de costos variables, derivado de los volúmenesde datos procesados de cada servicio prestado. La administración de costos se ha llevado a un nivel de

APENDICE 2


práctica industrial, basada en el resultado de mejoras continuas y de comparación con otrasorganizaciones. La optimización de costos es un proceso constante. La gerencia revisa los KPIs yKGIs como parte de un proceso de mejora continua en el rediseño de los sistemas de medición decostos.

APENDICE2


ME1 MONITOREAR Y EVALUAR EL DESEMPEÑO DE TI

Descripción del ProcesoUna efectiva administración del desempeño de TI requiere un proceso de monitoreo. El proceso incluye ladefinición de indicadores de desempeño relevantes, reportes sistemáticos y oportunos de desempeño ytomar medidas expeditas cuando existan desviaciones. El monitoreo se requiere para garantizar que lascosas correctas se hagan y que estén de acuerdo con el conjunto de direcciones y políticas.

ME1.1 Enfoque del MonitoreoGarantizar que la gerencia establezca un marco de trabajo de monitoreo general y un enfoque que definanel alcance, la metodología y el proceso a seguir para monitorear la contribución de TI a los resultados delos procesos de administración de programas y de administración del portafolio empresarial y aquellosprocesos que son específicos para la entrega de la capacidad y los servicios de TI. El marco de trabajo sedebería integrar con el sistema de administración del desempeño corporativo.

ME1.2 Definición y recolección de datos de monitoreoGarantizar que la gerencia de TI, trabajando en conjunto con el negocio, defina un conjunto balanceadode objetivos, mediciones, metas y comparaciones de desempeño y que estas se encuentren acordadasformalmente con el negocio y otros interesados relevantes. Los indicadores de desempeño deberíanincluir: La contribución al negocio que incluya, pero que no se limite a, la información financiera Desempeño contra el plan estratégico del negocio y de TI Riesgo y cumplimiento de las regulaciones Satisfacción del usuario interno y externo Procesos clave de TI que incluyan desarrollo y entrega del servicio Actividades orientadas a futuro, por ejemplo, la tecnología emergente, la infraestructura re-utilizable,

habilidades del personal de TI y del negocio

Se deben establecer procesos para recolectar información oportuna y precisa para reportar el avancecontra las metas.

ME1.3 Método de monitoreoGarantizar que el proceso de monitoreo implante un método (ej. Balanced Scorecard), que brinde unavisión sucinta y desde todos los ángulos del desempeño de TI y que se adapte al sistema de monitoreo dela empresa.

ME1.4 Evaluación del desempeñoComparar de forma periódica el desempeño contra las metas, realizar análisis de la causa raíz e iniciarmedidas correctivas para resolver las causas subyacentes.

ME1.5 Reportes al consejo directivo y a ejecutivosProporcionar reportes administrativos para ser revisados por la alta dirección sobre el avance de laorganización hacia metas identificadas, específicamente en términos del desempeño del portafolioempresarial de programas de inversión habilitados por TI, niveles de servicio de programas individuales yla contribución de TI a ese desempeño. Los reportes de estatus deben incluir el grado en el que se hanalcanzado los objetivos planeados, los entregables obtenidos, las metas de desempeño alcanzadas y losriesgos mitigados. Durante la revisión, se debe identificar cualquier desviación respecto al desempeñoesperado y se deben iniciar y reportar las medidas administrativas adecuadas.

APENDICE2


ME1.6 Acciones correctivas Identificar e iniciar medidas correctivas basadas en el monitoreo deldesempeño, evaluación y reportes. Esto incluye el seguimiento de todo el monitoreo, de los reportes y delas evaluaciones con:• Revisión, negociación y establecimiento de respuestas administrativas• Asignación de responsabilidades por la corrección• Rastreo de los resultados de las acciones comprometidas

APENDICE 2


Modelo de MadurezLa administración del proceso de Monitorear y evaluar el desempeño de TI que satisfaga losrequerimientos de negocio para TI de transparencia y entendimiento de los costos, beneficios,estrategia, políticas y niveles de servicio de TI, de acuerdo con los requisitos de gobierno es:0 No existente cuando

La organización no cuenta con un proceso implantado de monitoreo. TI no lleva a cabo monitoreo deproyectos o procesos de forma independiente. No se cuenta con reportes útiles, oportunos y precisos.La necesidad de entender de forma clara los objetivos de los procesos no se reconoce.

1 Inicial/Ad Hoc cuandoLa gerencia reconoce una necesidad de recolectar y evaluar información sobre los procesos demonitoreo. No se han identificado procesos estándar de recolección y evaluación. El monitoreo seimplanta y las métricas se seleccionan de acuerdo a cada caso, de acuerdo a las necesidades deproyectos y procesos de TI específicos. El monitoreo por lo general se implanta de forma reactiva aalgún incidente que ha ocasionado alguna perdida o vergüenza a la organización. La función decontabilidad monitorea mediciones financieras básicas para TI.

2 Repetible pero intuitiva cuandoSe han identificado algunas mediciones básicas a ser monitoreadas. Los métodos y las técnicas derecolección y evaluación existen, pero los procesos no se han adoptado en toda la organización. Lainterpretación de los resultados del monitoreo se basa en la experiencia de individuos clave.Herramientas limitadas son seleccionadas y se implantan para recolectar información, pero estarecolección no se basa en un enfoque planeado.

3 Proceso definido cuandoLa gerencia ha comunicado e institucionalizado un procesos estándar de monitoreo. Se hanimplantado programas educacionales y de entrenamiento para el monitoreo. Se ha desarrollado unabase de conocimiento formalizada del desempeño histórico. Las evaluaciones todavía se realizan alnivel de procesos y proyectos individuales de TI y no están integradas a través de todos los procesos.Se han definido herramientas para monitorear los procesos y los niveles de servicio de TI. Lasmediciones de la contribución de la función de servicios de información al desempeño de laorganización se han definido, usando criterios financieros y operativos tradicionales. Las medicionesdel desempeño específicas de TI, las mediciones no financieras, las estratégicas, las de satisfaccióndel cliente y los niveles de servicio están definidas. Se ha definido un marco de trabajo para medir eldesempeño.

4 Administrado y medible cuandoLa gerencia ha definido las tolerancias bajo las cuales los procesos deben operar. Los reportes de losresultados del monitoreo están en proceso de estandarizarse y normalizarse. Hay una integración demétricas a lo largo de todos los proyectos y procesos de TI. Los sistemas de reporte de laadministración de TI están formalizados. Las herramientas automatizadas están integradas y seaprovechan en toda la organización para recolectar y monitorear la información operativa de lasaplicaciones, sistemas y procesos. La gerencia puede evaluar el desempeño con base en criteriosacordados y aprobados por las terceras partes interesadas. Las mediciones de la función de TI estánalienadas con las metas de toda la organización.

5 Optimizado cuandoUn proceso de mejora continua de la calidad se ha desarrollado para actualizar los estándares y laspolíticas de monitoreo a nivel organizacional incorporando mejores prácticas de la industria. Todoslos procesos de monitoreo están optimizados y dan soporte a los objetivos de toda la organización.Las métricas impulsadas por el negocio se usan de forma rutinaria para medir el desempeño, y estánintegradas en los marcos de trabajo estratégicos, tales como el Balanced Scorecard. El monitoreo delos procesos y el rediseño continuo son consistentes con los planes de mejora de los procesos denegocio en toda la organización. Benchmarks contra la industria y los competidores clave se hanformalizado, con criterios de comparación bien entendidos.

APENDICE 2


ME2 MONITOREAR Y EVALUAR EL CONTROL INTERNO

Descripción del ProcesoEstablecer un programa de control interno efectivo para TI requiere un proceso bien definido demonitoreo. Este proceso incluye el monitoreo y el reporte de las excepciones de control, resultados de lasauto-evaluaciones y revisiones por parte de terceros. Un beneficio clave del monitoreo del control internoes proporcionar seguridad respecto a las operaciones eficientes y efectivas y el cumplimiento de las leyesy regulaciones aplicables.

ME2.1 Monitorear el marco de trabajo de control internoMonitorear de forma continua el ambiente de control y el marco de control de TI. Se debe realizar laevaluación usando mejores prácticas de la industria y se debería utilizar benchmarking para mejorar elambiente y el marco de trabajo de control de TI.

ME2.2 Revisiones de AuditoríaMonitorear y reportar la efectividad de los controles internos sobre TI por medio de revisiones deauditoría incluyendo, por ejemplo, el cumplimiento de políticas y estándares, seguridad de la información,controles de cambios y controles establecidos en acuerdos de niveles de servicio.ME2.3 Excepciones de controlRegistrar la información referente a todas las excepciones de control y garantizar que esto conduzca alanálisis de las causas subyacentes y a la toma de acciones correctivas. La gerencia debería decidir cuálesexcepciones se deberían comunicar al individuo responsable de la función y cuáles excepciones deberíanser escaladas. La gerencia también es responsable de informar a las partes afectadas.ME2.4 Auto-evaluación de controlEvaluar la completitud y efectividad de los controles internos de la administración de los procesos,políticas y contratos de TI por medio de un programa continuo de auto-evaluación.ME2.5 Aseguramiento del control internoObtener, según sea necesario, aseguramiento adicional de la completitud y efectividad de los controlesinternos por medio de revisiones de terceros. Dichas revisiones pueden ser realizadas por la función decumplimiento corporativo o, a solicitud de la gerencia, por auditoría interna o por auditores y consultoresexternos o por organismos de certificación. Se deben verificar las aptitudes de los individuos que realicenla auditoria, por ej. Un Auditor de Sistemas de Información CertificadoTM (CISA® por sus siglas enInglés) debe asignarse.

ME2.6 Control interno para tercerosDeterminar el estado de los controles internos de cada proveedor externos de servicios. Confirmar que losproveedores externos de servicios cumplan con los requerimientos legales y regulatorios y con lasobligaciones contractuales. Esto puede ser provisto por una auditoría externa o se puede obtener de unarevisión por parte de auditoría interna y por los resultados de otras auditorias.

ME2.7 Acciones correctivasIdentificar e iniciar medidas correctivas basadas en las evaluaciones y en los reportes de control. Estoincluye el seguimiento de todas las evaluaciones y los reportes con: La revisión, negociación y establecimiento de respuestas administrativas La asignación de responsabilidades para corrección (puede incluir la aceptación de los riesgos) El rastreo de los resultados de las acciones comprometidas

APENDICE 2


Modelo de MadurezLa administración del proceso de Monitorear y evaluar el control interno que satisfaga el requisitode negocio de TI de proteger el logro de los objetivos de TI y cumplir con las leyes y regulacionesrelacionadas con TI es:0 No existente cuando

La organización carece de procedimientos para monitorear la efectividad de los controles internos.Los métodos de reporte de control interno gerenciales no existen. Existe una falta generalizada deconciencia sobre la seguridad operativa y el aseguramiento del control interno de TI. La gerencia ylos empleados no tienen conciencia general sobre el control interno.

1 Inicial/Ad Hoc cuandoLa gerencia reconoce la necesidad de administrar y asegurar el control de TI de forma regular. Laexperiencia individual para evaluar la suficiencia del control interno se aplica de forma ad hoc. Lagerencia de TI no ha asignado de manera formal las responsabilidades para monitorear la efectividadde los controles internos. Las evaluaciones de control interno de TI se realizan como parte de lasauditorías financieras tradicionales, con metodologías y habilidades que no reflejan las necesidadesde la función de los servicios de información.

2 Repetible pero intuitiva cuandoLa organización utiliza reportes de control informales para comenzar iniciativas de acción correctiva.La evaluación del control interno depende de las habilidades de individuos clave. La organizacióntiene una mayor conciencia sobre el monitoreo de los controles internos. La gerencia de servicios deinformación realiza monitoreo periódico sobre la efectividad de lo que considera controles internoscríticos. Se están empezando a usar metodologías y herramientas para monitorear los controlesinternos, aunque no se basan en un plan. Los factores de riesgo específicos del ambiente de TI seidentifican con base en las habilidades de individuos.

3 Proceso definido cuandoLa gerencia apoya y ha institucionalizado el monitoreo del control interno. Se han desarrolladopolíticas y procedimientos para evaluar y reportar las actividades de monitoreo del control interno.Se ha definido un programa de educación y entrenamiento para el monitoreo del control interno. Seha definido también un proceso para auto-evaluaciones y revisiones de aseguramiento del controlinterno, con roles definidos para los responsables de la administración del negocio y de TI. Se usanherramientas, aunque no necesariamente están integradas en todos los procesos. Las políticas deevaluación de riesgos de los procesos de TI se utilizan dentro de los marcos de trabajo desarrolladosde manera específica para la función de TI. Se han definido políticas para el manejo y mitigación deriesgos específicos de procesos.

4 Administrado y medible cuandoLa gerencia tiene implantado un marco de trabajo para el monitoreo del control interno de TI. Laorganización ha establecido niveles de tolerancia para el proceso de monitoreo del control interno. Sehan implantado herramientas para estandarizar evaluaciones y para detectar de forma automática lasexcepciones de control. Se ha establecido una función formal para el control interno de TI, conprofesionales especializados y certificados que utilizan un marco de trabajo de control formalavalado por la alta dirección. Un equipo calificado de TI participa de forma rutinaria en lasevaluaciones de control interno. Se ha establecido una base de datos de métricas para informaciónhistórica sobre el monitoreo del control interno. Se realizan revisiones entre pares para verificar elmonitoreo del control interno.

5 Optimizado cuandoLa gerencia ha implantado un programa de mejora continua en toda la organización que toma encuenta las lecciones aprendidas y las mejores prácticas de la industria para monitorear el controlinterno. La organización utiliza herramientas integradas y actualizadas, donde es apropiado, quepermiten una evaluación efectiva de los controles críticos de TI y una detección rápida de incidentesde control de TI. La compartición del conocimiento, específico de la función de servicios de

APENDICE 2


información, se encuentra implantada de manera formal. El benchmarking con los estándares de laindustria y las mejores prácticas está formalizado.

COBIT Y PRODUCTOS RELACIONADOS


El marco COBIT, a partir de la versión 4.0 y posteriores, incluye todo lo siguiente: Marco—Explica la forma en que COBIT organiza el Gobierno de TI, la administración y los objetivos de control y

buenas prácticas por dominios y procesos de TI, y su vinculación con los requerimientos del negocio Descripciones de Procesos —Incluye 34 procesos de TI que cubren las responsabilidades de TI de principio a

fin. Objetivos de Control—Provee mejores prácticas genéricas de gestión de objetivos para los procesos de TI. Directrices de Gestión—Ofrece herramientas para ayudar en la asignación de responsabilidades, la medición del

desempeño así como el benchmarking y la identificación de brechas de habilidades. Modelos de Madurez—Provee perfiles de los procesos de TI, describiendo estados actuales y futuros.

Desde sus principios, el contenido esencial de COBIT ha evolucionado y continúa haciéndolo, incrementando losproductos relacionados y derivados de COBIT: Informe al Consejo sobre el Gobierno de TI, 2da Edición—Diseñado para ayudar a la Dirección a entender

porqué el Gobierno de TI es importante y cuál es su responsabilidad en su gestión. COBIT® Online—Permite a los usuarios personalizar una versión COBIT para su empresa y luego almacenar y

actualizar dicha versión según sea necesario. Ofrece encuestas en línea y tiempo real, preguntas frecuentes,benchmarking y un foro de discusión para compartir experiencias y preguntas.

Prácticas de Control de COBIT®:: Guía para alcanzar los Objetivos de Control para un exitoso Gobierno deTI, 2da Edición—Provee una guía respecto de los riesgos a ser evitados y el valor a ser obtenido por laimplementación de un objetivo de control, así como instrucciones acerca de cómo implementar el objetivo. Serecomienda utilizar las Prácticas de Control con la Guía de Implementación de Gobierno de TI: UtilizandoCOBIT® and Val ITTM, 2da Edición.

Guía de Aseguramiento de TI: Utilizando COBIT®—Provee una guía sobre cómo utilizar COBIT como soportea una gran variedad de actividades de aseguramiento y también pruebas sugerida para todos los procesos de TIy los objetivos de control de COBIT. Reemplaza la información de las Directrices de Auditoría para auditoría yautoevaluación contra los objetivos de control de COBIT 4.1.

Objetivos de Control de TI para Sarbanes-Oxley: El Rol de TI en el Diseño e Implementación de ControlesInternos sobre el Reporting Financiero, 2da Edición—Guía sobre cómo asegurar el cumplimiento en el entorno deTI, basado en los objetivos de control de COBIT.

Guía de Implementación de Gobierno de TI: Utilizando COBIT® y Val ITTM, 2da Edición—Provee un mapa de rutagenérico para implementar el gobierno de TI utilizando los recursos de COBIT and Val IT y herramientas desoporte.

COBIT® Quickstart—Provee bases mínimas de control para organizaciones mas pequeñas y una posible etapainicial para las empresas mas grandes.

COBIT® Security Baseline—Centrada en pasos esenciales para implementar seguridad de la información dentrode la organización.

Mapas de COBIT—Actualmente disponibles en www.isaca.org/downloads:– Aligning COBIT®

, ITIL and ISO 17799 for Business Benefit– COBIT® Mapping: Overview of International IT Guidance, 2nd Edition– COBIT® Mapping: Mapping of CMMI® for Development V1.2 With COBIT® 4.0– COBIT® Mapping: Mapping of ISO/IEC 17799:2000 With COBIT®, 2nd Edition– COBIT® Mapping: Mapping of ISO/IEC 17799:2005 With COBIT® 4.0– COBIT® Mapping: Mapping of ITIL With COBIT® 4.0– COBIT® Mapping: Mapping of PMBOK With COBIT® 4.0– COBIT® Mapping: Mapping of PRINCE2 With COBIT® 4.0– COBIT® Mapping: Mapping of SEI’s CMM for Software With COBIT® 4.0– COBIT® Mapping: Mapping of TOGAF 8.1 for Software With COBIT® 4.0

Gobierno de la Seguridad de la Información: Guía para el Consejo de Administración y Gerencia Ejecutiva,2daEdición—Presenta la seguridad de la información en términos de negocio y contiene técnicas y herramientas deayuda para descubrir problemas relacionados con la seguridad.

Val IT es el término abarcativo utilizado para describir las publicaciones y futuros productos y actividades adicionalesrelacionados con el Marco Val IT.

COBIT Y PRODUCTOS RELACIONADOS


Las publicaciones vigentes relacionadas con Val IT son: Valor para la Empresa: Buen Gobierno para las Inversiones de TI—El Marco Val ITTM , que explica cómo una

empresa puede obtener el valor óptimo de las inversiones posibilitadas por TI y está basada en el marco COBIT.Está organizada en:– Tres procesos—Buen Gobierno del Valor, Gestión del Portafolio de Inversiones y Gestión de Inversiones– Prácticas clave de gestión de TI—Prácticas de gestión esenciales que influyen positivamente en el logro de

resultados o propósitos de una actividad en particular. Soportan los procesos de Val IT y cumplen agrandes ragos el mismo rol que los objetivos de control de COBIT.

Valor para la Empresa: Buen Gobierno para las Inversiones de TI—El Caso de Negocio, centrado enun elemento clave del procesos de gestión de inversiones

Valor para la Empresa: Buen Gobierno para las Inversiones de TI—El Caso de Estudio ING, describe cómouna empresa de servicios financieros globales gestiona un portafolio de inversiones de TI dentro del contexto delmarco Val IT.

Para una completa y actualizada información sobre COBIT, Val IT y productos relacionados, casos de estudio,oportunidades de formación, newsletters y otra información específica sobre marcos: www.itgi.org,www.isaca.org/cobit y www.isaca.org/valit.

GOBIERNODETIUTILIZANDO COBIT Y VAL IT - CAMPUS …€¦ · · 2013-05-15R econocimientos Page 6...

Documents

Transcript of GOBIERNODETIUTILIZANDO COBIT Y VAL IT - CAMPUS …€¦ · · 2013-05-15R econocimientos Page 6...