2012_204info.pdf

INFORME DE AUDITORÍA
A Lic. Da. Mercedes Marcó del Pont
Presidente
Banco Central de la República Argentina
En uso de las facultades conferidas por el artículo 118 de la Ley 24.156, la AUDITORÍA
GENERAL DE LA NACIÓN procedió a efectuar un examen en el ámbito del Banco Central
de la República Argentina, con el objeto que se detalla en el apartado 1.
1.- Objeto de la auditoría
Auditoría de la gestión informática del Banco Central de la República Argentina con el objeto
de analizar la calidad de su información.
Período auditado: Julio 2010 a Junio 2011.
2.- Alcance del examen
2.1.- En la etapa de planificación, el equipo de auditoría identificó los temas más expuestos al
riesgo. Para ello:
 Relevó la documentación normativa del área de tecnología informática del Organismo.
 Relevó la infraestructura informática del Organismo.
 Relevó los sistemas existentes en producción y en desarrollo.
 Verificó la adecuación de los sistemas, la infraestructura existente y la planificación con
las que el Organismo se propone plasmar sus misiones, alcanzar sus metas y cumplir con
las leyes y decretos que regulan su actividad.
 Verificó el modelo de arquitectura de la información y su seguridad.
 Relevó y analizó el organigrama y el funcionamiento del área de tecnología informática.
 Analizó la administración de recursos humanos, la evaluación de riesgos, la
administración de proyectos, la administración de calidad y las prácticas de instalación y
acreditación de sistemas y de administración de cambios.
 Analizó:
1

la definición de los niveles de servicio,

la administración de los servicios prestados por terceros,

la administración de la capacidad y el desempeño,

los mecanismos que garantizan el servicio continuo y la seguridad de los sistemas,

la imputación de costos,

la educación y capacitación de los usuarios,

la asistencia a los usuarios de Tecnología de la Información,

la administración de la configuración de hardware y software,

la administración de problemas e incidentes,

la administración de datos, de instalaciones y de operaciones.
 Analizó el control de los procesos, la idoneidad del control interno y de su monitoreo.
2.2.- Para verificar el estado de utilización de la Tecnología Informática en el Banco Central
de la República Argentina, se obtuvo información de las siguientes fuentes:
 Entrevistas a los Gerentes de Sistemas y Organización, de Operaciones Informáticas, de
Seguridad de Información, de Desarrollo, de Análisis de Riesgo y de Infraestructura.
 Inspecciones directas efectuadas en el área informática del Banco.
2.3.- Limitaciones: No se evaluó el uso de la Tecnología Informática en las delegaciones del
Interior.
Las tareas de campo abarcaron desde abril hasta agosto de 2011.
2.4.- Metodología: La auditoría incluyó dos etapas: 1) planificación del análisis detallado; 2)
verificación de lo informado en la primera etapa por medio de pruebas sustantivas y de
cumplimiento.
La etapa de planificación incluyó las siguientes actividades:

Análisis del marco legal e institucional del funcionamiento del Banco.

Análisis de los informes de Auditoría Interna en temas informáticos.

Entrevistas con responsables de las Áreas Informática.
En la etapa de análisis detallado:

Se analizaron las minutas de reunión para determinar qué aspectos requerían un análisis
2
detallado.

Se determinaron las necesidades de verificación de las respuestas obtenidas.

Especialistas informáticos de la AGN realizaron inspecciones in situ y entrevistas con
personal subalterno.
En función de la información relevada y de la estimación de los niveles de riesgo, se
definieron los trabajos de campo para realizar las verificaciones necesarias.
Este informe es producto de la evaluación de la información recabada en las entrevistas y de
las observaciones realizadas en el trabajo de campo.
Se estableció el nivel de madurez de los Objetivos de Control definidos y se realizó un
análisis de los riesgos asociados a cada uno de ellos.
3.- Aclaraciones previas
3.1.- Marco legal e institucional
El Banco Central de la Republica Argentina constituye una entidad autárquica del Estado
Nacional. Por ley 25.780, promulgada parcialmente por Dto. 783/03, se reformó la Ley de
Entidades Financieras y la Carta Orgánica del Banco Central.
Son funciones del Banco entre otras, y conforme normativa vigente:

Vigilar el buen funcionamiento del mercado financiero y aplicar la Ley de Entidades
Financieras;

Ejecutar la política cambiaria en un todo de acuerdo con la legislación que sancione
el Honorable Congreso de la Nación;

Actuar como agente financiero del Gobierno Nacional;

Concentrar y administrar sus reservas de oro, divisas y otros activos externos, y
propender al desarrollo y fortalecimiento del mercado de capitales y ejecutar la
política cambiaria;

Emitir títulos o bonos así como también certificados de participación en los valores
que posea.
El Banco Central, se encuentra conducido por un Directorio integrado por un Presidente, un
Vicepresidente y ocho Directores. Todos son designados por el Poder Ejecutivo Nacional con
acuerdo del Senado de la Nación.
3
La supervisión de la actividad financiera y cambiaria es ejercida por intermedio de la
Superintendencia de Entidades Financieras y Cambiarias, dependiente directamente del
Presidente de la Institución. La Superintendencia es gobernada por uno de los Directores del
Banco quien cuenta con amplias facultades para la toma de decisiones.
El Banco Central en el año 2005 emite mediante la Comunicación “A” 4383, normas que
toman como estándares los principios del Marco de Recomendaciones del Grupo de Acción
Financiera Internacional (GAFI), donde se advierten políticas y estructuras sobre
“conocimiento de cliente”. Existen procesos diseñados para identificar a las personas que se
vinculan con las entidades financieras, las que están obligadas a registrar en una base de datos
la estadística correspondiente a las operaciones de cada cliente que se consideren
sospechosas.
4.- Comentarios y observaciones
Basamos nuestra tarea en la verificación de los Objetivos de Control establecidos por las
normas COBIT (Control OBjectives in Information Technologies) versión 4. Los Objetivos
de Control describen los resultados que debe alcanzar un organismo implantando
procedimientos de control, basados en las mejores prácticas aplicables, a los procesos de TI.
Para cada una de los Objetivos se menciona el nivel de madurez que le corresponde,
conforme al Modelo de Madurez de la Capacidad incluido en el Anexo I. Es de mencionar
que las “Observaciones” que figuran en cada Objetivo se incluyen para respaldar el nivel de
madurez asignado y pueden ser tanto una fortaleza como una debilidad del ente auditado.
En el punto 6, se encuentran las Recomendaciones para mejorar el ambiente de control y
reducir los riesgos.
Además, para cada uno de los Objetivos de Control, se indica qué requerimientos de la
información (detallados en el Anexo III) son afectados.
Se destaca que cada objetivo de control va acompañado de su nivel de riesgo genérico (alto,
medio o bajo) que le es propio, poniendo en evidencia el impacto provocado por su
incumplimiento y sin estar vinculado con la situación del organismo.
Ese nivel genérico es modificado por el índice de madurez correspondiente (dependiente de
4
las observaciones realizadas) para establecer el riesgo específico para ese objetivo, en el caso
particular. Puede observarse en los gráficos de los Anexos que un objetivo de control que
tiene implícito un riesgo genérico alto y fue calificado con un índice de madurez alto, genera
un riesgo específico menor que aquel que tenga un riesgo genérico medio o bajo y un índice
de madurez de bajo.
4.1.- Planear y Organizar
4.1.1.- Definir un plan estratégico para TI
Objetivo de control: Se requiere una planeación estratégica de Tecnología de la Información
(TI) para administrar y dirigir todos los recursos de TI de acuerdo con la estrategia y las
prioridades del Organismo. La gerencia informática y los participantes involucrados son
responsables de garantizar que se materialice el valor óptimo de los proyectos y servicios. El
plan estratégico debe mejorar el entendimiento de los interesados clave respecto a las
oportunidades y limitaciones de TI, evaluar el desempeño actual y aclarar el nivel de
inversión requerido. La estrategia y las prioridades se deben reflejar en los proyectos de
inversión y deben ser ejecutadas por los planes tácticos de TI, los cuales establecen objetivos,
planes y tareas específicas, entendidas y aceptadas tanto por el la conducción del Organismo
como por TI.
Este objetivo de control afecta, primariamente:

la efectividad
y en forma secundaria:

la eficiencia
Nivel de riesgo:
[X] Alto
[ ] Medio
[ ] Bajo
Nivel de Madurez: Inicial. La Gerencia de TI conoce la necesidad de una planeación
estratégica y la realiza según se necesite como respuesta a un requerimiento específico. La
alineación de los requerimientos de las aplicaciones y la tecnología se lleva a cabo de modo
reactivo en lugar de hacerlo por medio de una estrategia organizacional. La posición de
riesgo estratégico se identifica de manera informal proyecto por proyecto.
Observaciones: No existe un plan estratégico de TI. Como resultado de lo expresado, la
estrategia de la dirección tecnológica para adecuarse al alineamiento del ente es reactiva.
5
Cuestiones tales como evaluar el nivel de inversión requerido, evaluar el desempeño de TI o
establecer prioridades en función de su contribución a los objetivos del Organismo, se ven
limitados por su ausencia.
Al momento de esta auditoría la posición de Subgerente General de Sistemas y Organización
se encuentra cubierta transitoriamente por la Subgerente de Administración y Servicios
Centrales.
4.1.2.- Definir la arquitectura de información
Objetivo de control: La gerencia informática debe crear y actualizar de forma regular un
modelo de información del Organismo y definir los sistemas apropiados para optimizar el uso
de esta información. Esto incluye el desarrollo de un diccionario único de datos que contiene
las reglas de sintaxis de los datos de la organización, el esquema de clasificación de datos y
los niveles de seguridad. Este proceso mejora la calidad de la toma de decisiones gerenciales
asegurándose que se proporciona información confiable y segura, y permite racionalizar los
recursos de los sistemas de información para igualarse con las estrategias del ente. Este
proceso de TI también es necesario para incrementar la responsabilidad sobre la integridad y
seguridad de los datos y para mejorar la efectividad y control de la información compartida a
lo largo de las aplicaciones y de las entidades
Este objetivo de control afecta, primariamente:

la eficiencia

la integridad
y en forma secundaria:

la efectividad

la confidencialidad
Nivel de riesgo:
[X] Alto
[ ] Medio
[ ] Bajo
Nivel de Madurez: Inicial. La gerencia reconoce la necesidad de una arquitectura de
información. El desarrollo de algunos componentes de una arquitectura de información
ocurre de manera ad hoc. Existe una comunicación esporádica e inconsistente de la necesidad
de una arquitectura de información.
6
Observaciones: El desarrollo de sistemas estuvo descentralizado en las distintas gerencias.
Actualmente, se ha procedido a la centralización del desarrollo y mantenimiento, aunque los
enfoques para mejorar la integridad, se encuentran demorados.
El Organismo carece de un diccionario de datos, por lo que muchas tablas y entidades básicas
se encuentran replicadas o con información redundante. Se carece de la posición funcional
que lo administre.
4.1.3.- Determinar la dirección tecnológica
Objetivo de control: La gerencia informática debe determinar la dirección tecnológica para
dar soporte a la misión del Organismo. Esto requiere de la creación de un plan de
infraestructura tecnológica y de un consejo de arquitectura que establezca y administre
posibilidades realistas y claras de lo que la tecnología puede ofrecer en términos de
productos, servicios y mecanismos de aplicación. El plan se debe actualizar de forma regular
y abarca aspectos tales como arquitectura de sistemas, dirección tecnológica, planes de
adquisición, estándares, estrategias de migración y contingencias. Esto permite contar con
respuestas oportunas a cambios en el ambiente, economías de escala para consecución de
personal de sistemas de información e inversiones, así como una interoperabilidad mejorada
de las plataformas y de las aplicaciones.
Este objetivo de control afecta, primariamente:

la efectividad

la eficiencia
Nivel de riesgo:
[X] Alto
[ ] Medio
[ ] Bajo
Nivel de Madurez: Repetible. Se difunde la necesidad e importancia de la planeación
tecnológica. La planeación es táctica y se enfoca en generar soluciones técnicas a problemas
técnicos, en lugar de usar la tecnología para satisfacer la misión del ente. La evaluación de los
cambios tecnológicos se delega a individuos que siguen procesos intuitivos, aunque similares.
Las personas obtienen sus habilidades sobre planeación tecnológica a través de un
aprendizaje práctico y de una aplicación repetida de las técnicas. Están surgiendo técnicas y
estándares comunes para el desarrollo de componentes de la infraestructura.
7
Observaciones: La ausencia de planes estratégicos y tácticos de TI, de un modelo de
arquitectura de la información, del diccionario de datos y de informes de desempeño de la
infraestructura tecnológica, no permite establecer claramente la dirección tecnológica. Se
siguen procesos intuitivos y reactivos basados en un trabajo sobre tendencias del mercado y
necesidades de coyuntura, tanto para establecer el mantenimiento de la infraestructura como
su posible crecimiento.
4.1.4.- Definir los procesos, organización y relaciones de TI
Objetivo de control: Una organización de TI se debe definir tomando en cuenta los
requerimientos de personal, funciones, delegación, autoridad, roles, responsabilidades y
supervisión. La organización debiera estar inserta en un marco de trabajo de procesos de TI
que asegure la transparencia y el control, así como el involucramiento de los altos ejecutivos
y de la conducción del ente. Un comité estratégico debe garantizar la vigilancia del consejo
directivo sobre la TI, y uno ó más comités administrativos, en los cuales participan tanto la
dirección como TI, deben determinar las prioridades de los recursos de TI alineados con las
necesidades
del
Organismo.
Deben
existir
procesos,
políticas
administrativas
y
procedimientos para todas las funciones, con atención específica en el control, el
aseguramiento de la calidad, la administración de riesgos, la seguridad de la información, la
propiedad de datos y de sistemas y la segregación de tareas.
Para garantizar el soporte oportuno de los requerimientos de la misión, TI se debe involucrar
en los procesos importantes de decisión para poder realizar su aporte.
Este objetivo de control afecta, primariamente:

la efectividad

la eficiencia
Nivel de riesgo:
[X] Alto
[ ] Medio
[ ] Bajo
Nivel de Madurez: Repetible. La función de TI está organizada para responder de forma
táctica aunque inconsistente a las necesidades de los usuarios y a las relaciones con los
proveedores. La necesidad de contar con una organización estructurada y una administración
de proveedores se comunica, pero las decisiones todavía dependen del conocimiento y
8
habilidades de individuos clave. Surgen técnicas comunes para administrar la organización de
TI y las relaciones con los proveedores.
Observaciones: Existe una organización de TI con funciones, roles, delegaciones y
responsabilidades bien definidos. Sin embargo, varias posiciones se encuentran sin cubrir al
momento de esta auditoría, en particular la del responsable informático cuyas funciones son
cubiertas por la Subgerente de Administración y Servicios Centrales desde hace más de un
año. Existe un marco de trabajo con procesos y procedimientos formalizados para casi todas
las funciones, faltando las políticas que los avalen.
La ausencia de un Plan Estratégico y de Políticas de Calidad limita la cohesión de los equipos
de trabajo para un mejor aprovechamiento los recursos de TI en la consecución de los
objetivos.
4.1.5.- Administrar la inversión en TI
Objetivo de control: Establecer y mantener un marco de trabajo para administrar los
programas de inversión en TI que abarquen costos, beneficios, prioridades dentro del
presupuesto, un proceso presupuestal formal y administración contra ese presupuesto.
Trabajar con los interesados para identificar y controlar los costos y beneficios totales dentro
del contexto de los planes estratégicos y tácticos de TI, y tomar medidas correctivas según
sean necesarias. El proceso fomenta la sociedad entre TI y la conducción del ente, facilita el
uso efectivo y eficiente de recursos de TI, y brinda transparencia y responsabilidad sobre el
costo total de la inversión, la materialización de los beneficios y el retorno sobre las
inversiones en TI.
Este objetivo de control afecta, primariamente:

la efectividad

la eficiencia
y en forma secundaria:

la confiabilidad
Nivel de riesgo:
[X] Alto
[ ] Medio
[ ] Bajo
Nivel de Madurez: Repetible. Existe un entendimiento implícito de la necesidad de
seleccionar y presupuestar las inversiones en TI. La necesidad de un proceso de selección y
9
presupuesto se comunica. El cumplimiento depende de la iniciativa de individuos dentro de la
organización. Surgen técnicas comunes para desarrollar componentes del presupuesto de TI.
Se toman decisiones presupuestales reactivas y tácticas.
Observaciones: Elaboran un Plan Anual de Compras. No existe un marco de administración
financiera que permita establecer prioridades dentro del Presupuesto de los programas de TI,
ni la administración de costos (con sus posibles desviaciones), ni un proceso de monitoreo de
beneficios que permita evaluar la contribución esperada de TI al cumplimiento de la misión
del Organismo.
4.1.6.- Comunicar las aspiraciones y la dirección de la gerencia
Objetivo de control: La dirección debe elaborar un marco de trabajo de control para TI, y
definir y comunicar las políticas. Un programa de comunicación continua se debe implantar
para articular la misión, los objetivos de servicio, las políticas y procedimientos, etc.,
aprobados y apoyados por la dirección. La comunicación apoya el logro de los objetivos de
TI y asegura la concientización y el entendimiento de los riesgos generales y de TI. El
proceso debe garantizar el cumplimiento de las leyes y reglamentos relevantes.
Este objetivo de control afecta, primariamente:

la efectividad
y en forma secundaria:

el cumplimiento
Nivel de riesgo:
[ ] Alto
[X] Medio
[ ] Bajo
Nivel de Madurez: Repetible. La conducción tiene un entendimiento implícito de las
necesidades y de los requerimientos de un ambiente de control de información efectivo,
aunque las prácticas son en su mayoría informales. La gerencia ha comunicado la necesidad
de políticas, procedimientos y estándares de control, pero la elaboración se delega a la
discreción de gerentes y áreas de trabajo individuales. La calidad se reconoce como una
filosofía deseable a seguir, pero las prácticas se dejan a discreción de agentes individuales. El
entrenamiento se realiza de forma individual, según se requiera.
10
Observaciones: El aspecto formal de la comunicación se encuentra encuadrado a través de la
Instrucción de Procedimiento 550 aprobada por el Subgerente General de Reingeniería y
Organización con fecha 16/11/2006 mediante Actuación Nro. 222/257/2006.
Sin embargo, la ausencia de un Plan Estratégico de TI y de directrices de administración de
riesgos relativos a TI, imposibilitan comunicar las políticas de TI.
Las iniciativas de concientización de riesgos corporativos tales como los temas de Seguridad,
son aisladas y no enmarcadas en una política general del Organismo.
4.1.7.- Administrar los recursos humanos de TI
Objetivo de control: Adquirir, mantener y motivar una fuerza de trabajo para la creación y
entrega de servicios de TI para la organización. Esto se logra siguiendo prácticas definidas y
aprobadas que apoyan el reclutamiento, entrenamiento, la evaluación del desempeño y la
promoción. Este proceso es crítico, ya que las personas tienen participación directa en el
ambiente de gobierno y de control interno por lo que éste depende fuertemente de la
motivación y competencia del personal.
Este objetivo de control afecta, primariamente:

la efectividad

la eficiencia
Nivel de riesgo:
[X] Alto
[ ] Medio
[ ] Bajo
Nivel de Madurez: Repetible. Existe un enfoque táctico para contratar y administrar al
personal de TI, dirigido por necesidades específicas de proyectos, en lugar de hacerlo con
base en un equilibrio entendido de disponibilidad de personal calificado. Se imparte
entrenamiento informal al personal nuevo, quienes después reciben entrenamiento específico,
según sea necesario.
Observaciones: Los procedimientos de reclutamiento del personal de TI están de acuerdo a
las políticas y procedimientos generales de administración de personal de la Organización.
Los roles y responsabilidades están bien definidos y el personal tiene las habilidades para
cumplir con éstos, que se miden a través de una evaluación de desempeño que se lleva a cabo
periódicamente.
11
Se observa falta de personal en funciones claves tales como Desarrollo de Sistemas, Gestión
de Riesgos y Testing, donde para llevar a cabo buenas prácticas metodológicas, precisan una
dotación mayor. Algunas actividades como las relacionadas con la Gestión para el
Aseguramiento de la Calidad no han sido definidas.
El escalafón vigente y la carrera administrativa limitan la incorporación de profesionales del
mercado.
4.1.8.- Administrar la calidad
Objetivo de control: Se debe elaborar y mantener un sistema de administración de calidad,
el cual incluya procesos y estándares probados de desarrollo y de adquisición. Esto se facilita
por medio de la planeación, implantación y mantenimiento del sistema de administración de
calidad,
proporcionando
requerimientos,
procedimientos
y
políticas
claras.
Los
requerimientos de calidad se deben manifestar y documentar con indicadores cuantificables y
alcanzables. La mejora continua se logra por medio del constante monitoreo, corrección de
desviaciones y la comunicación de los resultados a los interesados. La administración de
calidad es esencial para garantizar que TI está dando valor al ente, mejora continua y
transparencia para los interesados.
Este objetivo de control afecta, primariamente:

la efectividad

la eficiencia
y en forma secundaria:

la integridad

la confiabilidad
Nivel de riesgo:
[X] Alto
[ ] Medio
[ ] Bajo
Nivel de Madurez: Inicial. Existe conciencia por parte de la dirección de la necesidad de un
Sistema de Administración de la Calidad. La conducción realiza juicios informales sobre la
calidad.
Observaciones: El organigrama del Organismo no contempla una Gerencia o una
Subgerencia General abocada a tal fin. Tampoco existe un Sistema de Administración de la
Calidad.
12
4.1.9.- Evaluar y administrar los riesgos de TI
Objetivo de control: Crear y dar mantenimiento a un marco de trabajo de administración de
riesgos. El marco de trabajo documenta un nivel común y acordado de riesgos de TI,
estrategias de mitigación y riesgos residuales acordados. Cualquier impacto potencial sobre
las metas de la organización, causado por algún evento no planeado se debe identificar,
analizar y evaluar. Se deben adoptar estrategias de mitigación de riesgos para minimizar los
riesgos residuales a un nivel aceptable. El resultado de la evaluación debe ser entendible para
los participantes y se debe expresar en términos financieros, para permitir a los participantes
alinear los riesgos a un nivel aceptable de tolerancia.
Este objetivo de control afecta, primariamente:

la confidencialidad

la integridad

la disponibilidad
y en forma secundaria:

la efectividad

la eficiencia

el cumplimiento

la confiabilidad
Nivel de riesgo:
[X] Alto
[ ] Medio
[ ] Bajo
Nivel de Madurez: Repetible. Existe un enfoque de evaluación de riesgos inmaduro y en
evolución. La administración de riesgos se da por lo general a altos niveles y se aplica de
manera típica solo a proyectos grandes o como respuesta a problemas. Los procesos de
mitigación de riesgos están en implantación donde se identifican riesgos.
Observaciones: Si bien se ha establecido una política de administración de riesgos para toda
la organización, la Gerencia fue creada en mayo del 2009 como recomendación del Acuerdo
de Capital de Basilea II
1
y contó con una dotación reducida hasta mayo del 2011, cuando
1
El Comité de Basilea es también conocido como el “Banco Central de los Bancos Centrales” porque está
integrado por representantes de los Bancos Centrales de más de 100 países miembros, entre ellos el Banco
Central de la República Argentina. Debe aclararse que Basilea emite recomendaciones que orientan pero que no
son mandatorias para los bancos centrales de cada país.
13
fueron incorporados tres recursos nuevos, uno de ellos, especializado en la gestión
informática. Al momento de esta auditoría, este recurso se encuentra actualmente subrogando
la posición ya que no ha sido nombrado formalmente.
Actualmente se encuentran abocados al proceso de identificación de los riesgos y en la
elaboración de una metodología de análisis y gestión de riesgos de los sistemas de
información basadas en la serie 800 del NIST (National Institute of Standards and
Technology2), relacionadas con la seguridad de la información y en la metodología
MAGERIT3.
Debido a la complejidad del ente y la diversidad de los riesgos, se considera que la dotación
del personal está por debajo de lo recomendable.
4.1.10.- Administrar proyectos
Objetivo de control: Establecer un programa y un marco de control administrativo de
proyectos para la administración de todos los proyectos de TI. El marco de trabajo debe
garantizar la correcta asignación de prioridades y la coordinación de todos los proyectos. El
marco de trabajo debe incluir un plan maestro, asignación de recursos, definición de
entregables, aprobación de los usuarios, un enfoque de entrega por fases, aseguramiento de la
calidad, un plan formal de pruebas, revisión de pruebas y revisión después de la implantación
para garantizar la administración de los riesgos del proyecto y la entrega de valor para
cumplir con los fines del ente. Este enfoque reduce el riesgo de costos inesperados y de
cancelación de proyectos, mejora la comunicación, permite que se involucren los usuarios
finales, asegura el valor y la calidad de los entregables de los proyectos, y maximiza su
contribución a los programas de inversión en TI.
2
El Instituto Nacional de Normas y Tecnología (NIST por sus siglas en inglés, National Institute of Standards
and Technology) es una agencia de la Administración de Tecnología del Departamento de Comercio de los
Estados Unidos. La misión de este instituto es promover la innovación y la competencia industrial en Estados
Unidos mediante avances en metrología, normas y tecnología.
Como parte de esta misión, los científicos e ingenieros del NIST continuamente refinan la ciencia de la
medición (metrología) creando una ingeniería precisa y una manufacturación requerida para la mayoría de los
avances tecnológicos actuales. También están directamente involucrados en el desarrollo y pruebas de normas
hechos por el sector privado y agencias de gobierno.
3
Magerit es una metodología de análisis y gestión de riesgos de los Sistemas de Información elaborada por el
Consejo Superior de Administración Electrónica de España para minimizar los riesgos de la implantación y uso
de las Tecnologías de la Información enfocada a las Administraciones Públicas.
14
Este objetivo de control afecta, primariamente:

la efectividad

la eficiencia
Nivel de riesgo:
[X] Alto
[ ] Medio
[ ] Bajo
Nivel de Madurez: Repetible. La alta dirección ha obtenido y comunicado la conciencia de
la necesidad de la administración de los proyectos de TI. La organización está en proceso de
desarrollar y utilizar algunas técnicas y métodos proyecto por proyecto. Los proyectos de TI
han definido objetivos técnicos y funcionales de manera informal. Hay participación limitada
de los interesados en la administración de los proyectos de TI. Las directrices iniciales se han
elaborado para muchos aspectos de la administración de proyectos. La aplicación a proyectos
de las directrices administrativas se deja a discreción de cada responsable de proyecto.
Observaciones: Todos los requerimientos que ingresan al sector ya sean internos o
provenientes de otras áreas, son asignados y priorizados y generan la especificación
correspondiente. Alguno de estos requerimientos, como producto de un análisis preliminar, y
dependiendo de su envergadura en caso de ser un cambio, genera un Proyecto. El proyecto le
es asignado a un Líder de Proyecto que cuenta con un equipo para administrarlo. Generan
documentación tales como: Cronogramas, Asignación de Recursos, Plan de Proyecto,
Minutas de reunión e Informes de avance.
No existe un aplicativo para administrar proyectos. Se definieron estándares para
documentación. Para generar la documentación se emplean herramientas de oficina de
Microsoft: Excel, Project y Word.
La calidad de la documentación en los proyectos varía dependiendo de la importancia de
éstos.
4.2.- Adquirir e implantar
4.2.1.- Identificar soluciones automatizadas
Objetivo de control: La necesidad de una nueva aplicación o función requiere de análisis
antes de la compra o desarrollo para garantizar que los requisitos funcionales se satisfacen
con un enfoque efectivo y eficiente. Este proceso cubre la definición de las necesidades,
considera las fuentes alternativas, realiza una revisión de la factibilidad tecnológica y
15
económica, ejecuta un análisis de riesgo y de costo-beneficio y concluye con una decisión
final de desarrollar o comprar. Todos estos pasos permiten a las organizaciones minimizar el
costo para adquirir e implantar soluciones, mientras que al mismo tiempo facilitan el logro de
los objetivos del ente.
Este objetivo de control afecta, primariamente:

la efectividad
y en forma secundaria:

la eficiencia
Nivel de riesgo:
[X] Alto
[ ] Medio
[ ] Bajo
Nivel de Madurez: Parcialmente Definido. Existen enfoques claros y estructurados para
determinar las soluciones de TI. El enfoque para la determinación de las soluciones de TI
requiere la consideración de alternativas evaluadas contra los requerimientos del las
necesidades funcionales o del usuario, las oportunidades tecnológicas, la factibilidad
económica, las evaluaciones de riesgo y otros factores. El proceso para determinar las
soluciones de TI se aplica para algunos proyectos con base en factores tales como las
decisiones tomadas por el personal involucrado, la cantidad de tiempo administrativo
dedicado, y el tamaño y prioridad del requerimiento original. Se usan enfoques estructurados
para definir requerimientos e identificar soluciones de TI.
Observaciones: Los requerimientos se cargan en una aplicación implementada en la Intranet
del Organismo, conocida como “Aplicaciones/Presupuesto”. Con la carga se genera un ticket
con una numeración que permite identificarlos unívocamente. El procedimiento está
formalizado mediante la Circular Interna Nro. 4456 del 16 de junio de 2009. Las etapas de
estudios de factibilidad, análisis de riesgo, definición de alcance y la asignación de un
patrocinador que apruebe y autorice los requisitos funcionales no se encuentran formalizados.
4.2.2.- Adquirir o desarrollar y mantener software aplicativo
Objetivo de control: Las aplicaciones deben estar disponibles de acuerdo con los
requerimientos del Organismo. Este proceso cubre el diseño de las aplicaciones, la inclusión
apropiada de controles aplicativos y requerimientos de seguridad, y el desarrollo y la
16
configuración en sí de acuerdo a los estándares. Esto permite a las organizaciones apoyar la
operatividad de forma apropiada con las aplicaciones automatizadas correctas.
Este objetivo de control afecta, primariamente:

la efectividad

la eficiencia
y en forma secundaria:

la integridad

la confiabilidad
Nivel de riesgo:
[X] Alto
[ ] Medio
[ ] Bajo
Nivel de Madurez: Inicial. Existe conciencia de la necesidad de contar con un proceso de
adquisición o desarrollo y mantenimiento de aplicaciones. Los enfoques para la adquisición o
desarrollo y mantenimientos de software aplicativo varían de un proyecto a otro. Es factible
que se adquiriera, en forma independiente, una variedad de soluciones individuales para
requerimientos particulares del ente, teniendo como resultado ineficiencias en el
mantenimiento y soporte. Se tiene poca consideración hacia la seguridad y disponibilidad de
la aplicación en el diseño o adquisición de software aplicativo.
Observaciones: Existe un borrador de una Metodología de Ciclo de Vida de Desarrollo de
Sistemas (CVDS) basada en la metodología “Métrica 3”4 avalado por el Instructivo Interno
725/00. Al momento de esta auditoría no se encuentra formalizado.
4
Métrica 3 es una Metodología de Planificación, Desarrollo y Mantenimiento de Sistemas de Información.
Puede ser utilizada libremente con la única restricción de citar la fuente de su propiedad intelectual: el
Ministerio de Administraciones Públicas de España. Este Ministerio, desde el Consejo Superior de Informática,
ofrece así un instrumento para la sistematización de las actividades que dan soporte al ciclo de vida del software
en el desarrollo de Sistemas de Información. Su aplicación pretende los siguientes objetivos:




Proporcionar o definir Sistemas de Información que ayuden a conseguir los fines de la Organización
mediante la definición de un marco estratégico para el desarrollo de los mismos.
Dotar a la Organización de productos software que satisfagan las necesidades de los usuarios dando
una mayor importancia al análisis de requisitos.
Mejorar la productividad de los departamentos de Sistemas y Tecnologías de la Información y las
Comunicaciones, permitiendo una mayor capacidad de adaptación a los cambios y teniendo en cuenta
la reutilización en la medida de lo posible.
Facilitar la comunicación y entendimiento entre los distintos participantes en la producción de software
a lo largo del ciclo de vida del proyecto, teniendo en cuenta su papel y responsabilidad, así como las
necesidades de todos y cada uno de ellos.
17
La documentación varía dependiendo del proyecto. Se hace una especificación del alcance
del requerimiento sólo en los casos considerados importantes. No es una documentación
estandarizada. Muchas veces se toma como documentación el intercambio de correos
electrónicos entre las partes o minutas de las distintas reuniones. No siempre se formaliza la
aprobación por parte del usuario. En las entrevistas, se acusó falta de recursos para hacerlo.
4.2.3.- Adquirir y mantener infraestructura tecnológica
Objetivo de control: Las organizaciones deben contar con procesos para adquirir, implantar
y actualizar la infraestructura tecnológica. Esto requiere de un enfoque planeado para
adquirir, mantener y proteger la infraestructura de acuerdo con las estrategias tecnológicas
convenidas y la disposición del ambiente de desarrollo y pruebas. Esto garantiza que exista
un soporte tecnológico continuo para las aplicaciones del Organismo.
Este objetivo de control afecta, primariamente:

la eficiencia
y en forma secundaria:

la efectividad

la integridad

la disponibilidad
Nivel de riesgo:
[X] Alto
[ ] Medio
[ ] Bajo
Nivel de Madurez: Repetible. La adquisición y mantenimiento de la infraestructura de TI no
se basa en una estrategia definida formalmente y no considera las necesidades de las
aplicaciones del ente que se deben respaldar. Se tiene la noción de que la infraestructura de
TI es importante, que se apoya en algunas prácticas formales. Para algunos sistemas, existe
un ambiente de prueba por separado.
Observaciones: Si bien se formalizaron los procesos de administración de cambios y existen
estudios de factibilidad de la viabilidad de los mismos así cómo un marco de directrices de
administración de proyectos, no hay un enfoque planeado para adquirir, producto de la
ausencia de planes estratégicos y tácticos de TI. Tampoco existen estándares de adquisición

Facilitar la operación, mantenimiento y uso de los productos software obtenidos.
18
porque no hay un plan de aseguramiento de la Calidad ni un plan de monitoreo de desempeño
y capacidad
4.2.4.- Facilitar la operación y el uso
Objetivo de control: El conocimiento sobre los nuevos sistemas debe estar disponible. Este
proceso requiere la generación de documentación y manuales para usuarios y para TI, y
proporcionar entrenamiento para garantizar el uso y la operación correctos de las aplicaciones
y la infraestructura.
Este objetivo de control afecta, primariamente:

la efectividad

la eficiencia
y en forma secundaria:

la integridad

la disponibilidad

el cumplimiento

la confiabilidad
Nivel de riesgo:
[ ] Alto
[X] Medio
[ ] Bajo
Nivel de Madurez: Definido. Existe un esquema bien definido, aceptado y comprendido para
documentación del usuario, manuales de operación y materiales de entrenamiento. Se
guardan y se mantienen los procedimientos en una biblioteca formal y cualquiera que
necesite saber tiene acceso a ella. Las correcciones a la documentación y a los
procedimientos se realizan por reacción. Los procedimientos se encuentran disponibles fuera
de línea y se pueden acceder y mantener en caso de desastre. Existe un proceso que especifica
las actualizaciones de procedimientos y los materiales de entrenamiento para que sea un
entregable explícito de un proyecto de cambio. A pesar de la existencia de enfoques
definidos, el contenido actual varía debido a que no hay un control para reforzar el
cumplimiento de estándares. Los usuarios se involucran en los procesos informalmente. Cada
vez se utilizan más herramientas automatizadas en la generación y distribución de
procedimientos. Se planea y programa tanto el entrenamiento de la misión como de los
usuario.
19
Observaciones: Existe un marco normativo para la formalización de los procedimientos
basado en la Instrucción de Procedimiento Nro. 550. Su generación es precedida por un
marco de administración de proyectos y el conocimiento tanto de las aplicaciones como del
ente. La documentación se encuentra fácilmente accesible en la Intranet del Organismo.
No se cuenta con un esquema definido para el mantenimiento tanto de los procedimientos
como de los materiales de capacitación y entrenamiento. La documentación no se recopila y
se evalúa a posteriori como parte de un proceso de mejora continua.
4.2.5.- Adquirir recursos de TI
Objetivo de control: Se deben suministrar recursos TI, incluyendo personas, hardware,
software y servicios. Esto requiere de la definición y ejecución de los procedimientos de
adquisición, la selección de proveedores, el ajuste de arreglos contractuales y la adquisición
en sí. El hacerlo así garantiza que la organización tenga todos los recursos de TI que se
requieren de una manera oportuna y rentable.
Este objetivo de control afecta, primariamente:

la eficiencia
y en forma secundaria:

la efectividad

el cumplimiento
Nivel de riesgo:
[ ] Alto
[X] Medio
[ ] Bajo
Nivel de Madurez: Definido. La administración establece políticas y procedimientos para la
adquisición de TI. Las políticas y procedimientos toman como guía el proceso general de
adquisición de la organización. La adquisición de TI se integra en gran parte con los sistemas
generales de adquisición del Organismo. Existen estándares para la adquisición de recursos
de TI. Los proveedores de recursos de TI se integran dentro de los mecanismos de
administración de proyectos de la organización desde una perspectiva de administración de
contratos. La administración de TI comunica la necesidad de contar con una administración
adecuada de adquisiciones y contratos en toda la función.
20
Observaciones: Las adquisiciones se llevan a cabo en el marco de administración de
proyectos y siguiendo el marco normativo de compras del Estado por medio de políticas y
procedimientos formalmente definidos. Los procesos de adquisición son auditables.
La ausencia de un Plan Estratégico lleva a que las decisiones de adquisición sean reactivas a
las necesidades coyunturales. Tampoco existen políticas de calidad que permita establecer
estándares de acuerdos de niveles de servicio que puedan ser monitoreados y revisados a
posteriori para evaluar su desempeño.
4.2.6.- Administrar cambios
Objetivo de control: Todos los cambios, incluyendo el mantenimiento de emergencia y
correcciones, relacionados con la infraestructura y las aplicaciones dentro del ambiente de
producción, deben administrarse formalmente y controladamente. Los cambios (incluyendo
procedimientos, procesos, sistema y parámetros del servicio) se deben registrar, evaluar y
autorizar previo a la implantación y revisar contra los resultados planeados después de la
implantación. Esto garantiza la reducción de riesgos que impactan negativamente la
estabilidad o integridad del ambiente de producción.
Este objetivo de control afecta, primariamente:

la efectividad

la eficiencia

la integridad

la disponibilidad
y en forma secundaria:

la confiabilidad
Nivel de riesgo:
[X] Alto
[ ] Medio
[ ] Bajo
Nivel de Madurez: Definido. Existe un proceso formal definido para la administración del
cambio, que incluye la categorización, asignación de prioridades, procedimientos de
emergencia, autorización del cambio y administración de liberación, y va surgiendo el
cumplimiento. Se dan soluciones temporales a los problemas y los procesos a menudo se
omiten o se hacen a un lado. Aún pueden ocurrir errores y los cambios no autorizados
ocurren ocasionalmente. El análisis de impacto de los cambios de TI en operaciones de ente
21
se está volviendo formal, para apoyar la implantación planeada de nuevas aplicaciones y
tecnologías.
Observaciones: La Instrucción de Procedimiento Nro. 606 aprobada por el Sr. Gerente
General con fecha 03/09/2010 mediante Actuación Nro. 736/84/2010 norma la operatoria.
La Gerencia de Base de Datos y Sistemas Operativos (GBDySO) tiene un aplicativo para
dejar constancia de los cambios solicitados o proyectados, denominado “Registro de
Modificaciones”. Si la solicitud del cambio proviene de otra área, ésta es solicitada a la
GBDySO mediante un correo electrónico a una dirección destinada a tal fin.
La GBDySO planifica y coordina las acciones a seguir para la implementación del cambio.
Cuando el cambio pudiera afectar la seguridad de la infraestructura, existe una instancia de
interacción con la Gerencia de Seguridad Informática u otras dependencias técnicas.
Resta establecer un proceso para definir, plantear, evaluar y autorizar cambios de
emergencias que permita el seguimiento y la posterior auditabilidad, enmarcado en un
enfoque sistémico, o sea se debe formalizar un curso de acción tal que cuando se opta por el
procedimiento de emergencia exista una instancia obligatoria de revisión posterior por parte
de un tercero. Si bien existe una Instrucción de Procedimiento Nro. 571 para “Modificación
de datos de las bases por fuera de las aplicaciones”, este procedimiento adolece de la falta de
un monitoreo ex post sobre las acciones emprendidas.
4.2.7.- Instalar y acreditar soluciones y cambios
Objetivo de control: Los nuevos sistemas necesitan estar funcionales una vez que su
desarrollo se completa. Esto requiere pruebas adecuadas en un ambiente dedicado con datos
de prueba relevantes, definir la transición e instrucciones de migración, planear la liberación
y la transición en sí al ambiente de producción, y revisar la post-implantación. Esto garantiza
que los sistemas operacionales estén en línea con las expectativas convenidas y con los
resultados.
Este objetivo de control afecta, primariamente:

la efectividad
y en forma secundaria:

la eficiencia
22

la integridad

la disponibilidad
Nivel de riesgo:
[X] Alto
[ ] Medio
[ ] Bajo
Nivel de Madurez: Definido. Se cuenta con una metodología formal en relación con la
instalación, migración, conversión y aceptación. Los procesos de TI para instalación y
acreditación están integrados dentro del ciclo de vida del sistema y están automatizados hasta
cierto punto. El entrenamiento, pruebas y transición y acreditación a producción tienen muy
probablemente variaciones respecto al proceso definido, con base en las decisiones
individuales. La calidad de los sistemas que pasan a producción es inconsistente, y los nuevos
sistemas a menudo generan un nivel significativo de problemas posteriores a la implantación.
Observaciones: En el 2007 se creó la Subgerencia de Testing y Calidad. Llevan a cabo las
primeras instancias de pruebas en un entorno independiente de desarrollo y de producción. La
transferencia entre los distintos entornos la llevan a cabo a través de un producto denominado
Subversion5.
Interactúan con el área de Desarrollo en función de los resultados obtenidos de las pruebas.
Este procedimiento se repite tantas veces hasta que se considere la prueba aprobada como
para ser finalmente puesta a disposición del usuario final para su prueba definitiva. En caso
de que éste no dé su conformidad, el software se remite nuevamente a Desarrollo que llevará
a cabo las modificaciones correspondientes. Estas dos instancias de pruebas se repiten tantas
veces hasta que el usuario final da su aceptación. Con el consentimiento explícito de éste, la
subgerencia de Testing y Calidad solicita al sector “Bibliotecas” que pertenece a la Gerencia
Principal de Operaciones Informáticas para que planifique y lleve a cabo el pasaje a
producción.
Los casos de pruebas se documentan con formularios estándar.
También capacitan a los usuarios en el uso de los aplicativos.
5
Subversion, también conocido por SVN por ser el nombre de la herramienta utilizada en la línea de comandos,
es un software libre.
Una característica importante de Subversion es que, los archivos versionados no tienen cada uno un número de
revisión independiente, en cambio, todo el repositorio tiene un único número de versión que identifica un estado
común de todos los archivos del repositorio en un instante determinado
23
En algunas situaciones de emergencia, las aplicaciones no pasan por estas instancias. En estos
casos, el pasaje a producción se autoriza mediante un correo electrónico del Gerente Principal
de Desarrollo de Sistemas en acuerdo con la Instrucción de Procedimiento Nro. 571 para
“Modificación de datos de las bases por fuera de las aplicaciones” aprobada por el
Subgerente General de Reingeniería y Organización con fecha 20/06/2007, pese a que ésta
normativa no se ajusta a los casos de pasaje a producción en emergencia. Además este
procedimiento adolece de una falta de monitoreo ex post sobre las acciones emprendidas.
4.3.- Entregar y Dar Soporte
4.3.1.- Definir y Administrar los Niveles de Servicio
Objetivo de control: Contar con una definición documentada y un acuerdo de servicios de
TI y de niveles de servicio, hace posible una comunicación efectiva entre la gerencia de TI y
los usuarios respecto de los servicios requeridos. Este proceso también incluye el monitoreo y
la notificación oportuna a los interesados sobre el cumplimiento de los niveles de servicio.
Este proceso permite la alineación entre los servicios de TI y los requerimientos relacionados.
Este objetivo de control afecta los siguientes requerimientos de la información necesaria para
cumplir las misiones del Organismo, primariamente:

la efectividad

la eficiencia
y en forma secundaria:

la confidencialidad

la integridad

la disponibilidad

el cumplimiento

la confiabilidad
Nivel de riesgo:
[X] Alto
[ ] Medio
[ ] Bajo
Nivel de madurez: Inicial Hay conciencia de la necesidad de administrar los niveles de
servicio, pero el proceso es reactivo. La responsabilidad y la rendición de cuentas sobre la
definición y la administración no están definidas. Si existen las medidas para analizar el
24
desempeño son solamente cualitativas con metas definidas de forma imprecisa. La
presentación de informes es informal, infrecuente e inconsistente.
Observaciones: No existe una definición formal y precisa de servicios, ni hay formalización
de convenios internos que estén alineados con los requerimientos y capacidades de entrega. A
nivel externo solamente están definidos los acuerdos de nivel de servicio con los proveedores
de mantenimiento de hardware y de software. El contrato por el alquiler del espacio físico
para la instalación del Sitio Alternativo de Procesamiento (SAP) no tiene definido ningún
tipo de característica técnica que permita definir un acuerdo de niveles de servicio con la
Armada Argentina que es la propietaria del espacio.
4.3.2.- Administrar Servicios de Terceros.
Objetivo de control: La necesidad de asegurar que los servicios provistos por terceros
cumplan con las necesidades del Organismo, requiere de un proceso efectivo de
administración de terceros. Este proceso se logra por medio de 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 efectiva administración
de los servicios de terceros minimiza los riesgos del ente asociados con proveedores que no
se desempeñan de forma adecuada.
Este objetivo de control afecta los siguientes requerimientos de la información necesaria para
cumplir las misiones del Organismo, primariamente:

la efectividad

la eficiencia
y en forma secundaria:

la confidencialidad

la integridad

la disponibilidad

el cumplimiento

la confiabilidad
Nivel de riesgo:
[X] Alto
[ ] Medio
[ ] Bajo
25
Nivel de madurez: Definido. Existen procedimientos bien documentados para controlar los
servicios de terceros con procesos claros para tratar y negociar con los proveedores. Cuando
se hace un acuerdo de prestación de servicios la relación con el tercero es meramente
contractual. La naturaleza de los servicios a prestar se detalla en el contrato e incluye
requerimientos legales, operativos y de control. Se asigna la responsabilidad de supervisar los
servicios de terceros. Los términos contractuales se basan en formatos estandarizados. El
riesgo asociado con los servicios del tercero está valorado y reportado.
Observaciones: Los contratos de compras a terceros se encuentran formalizados. Dentro de
los contratos se incluyen acuerdos de confidencialidad, garantías, penalizaciones por
incumplimiento. Si bien en la mayoría de los contratos analizados se encuentran
mínimamente definido un acuerdo de nivel de servicio, esto no ocurre con el Convenio
Especifico ARA-BCRA - 1-1 en el cual no se incluye ningún tipo de cláusula que especifique
en forma clara y precisa las condiciones físicas y técnicas de las instalaciones a proveer por la
Armada Argentina para el procesamiento alternativo de emergencia.
4.3.3.- Administrar el Desempeño y la Capacidad
Objetivo de control: La necesidad de administrar el desempeño y la capacidad de los
recursos de TI requiere de un proceso para revisar periódicamente el desempeño actual y la
capacidad de los recursos de TI. Este proceso incluye el pronóstico de las necesidades
futuras, basadas en los requerimientos de carga de trabajo, almacenamiento y contingencias y
brinda la seguridad de que los recursos de información que soportan los requerimientos del
Organismo están disponibles de manera continua.
Este objetivo de control afecta los siguientes requerimientos de la información necesaria para
cumplir las misiones del Organismo, primariamente:

la efectividad

la eficiencia
y en forma secundaria:

la disponibilidad
Nivel de riesgo:
[X] Alto
[ ] Medio
[ ] Bajo
26
Nivel de madurez: Repetible. Los responsables del tema y la gerencia de TI están
conscientes del impacto de no administrar el desempeño y la capacidad. Las necesidades de
desempeño se logran por lo general con base en evaluaciones de sistemas individuales y el
conocimiento y soporte de equipos de proyecto. Algunas herramientas individuales pueden
utilizarse para diagnosticar problemas de desempeño y de capacidad, pero la consistencia de
los resultados depende de la experiencia de individuos clave. No hay una evaluación general
de la capacidad de desempeño de TI o consideración sobre situaciones de carga pico y peorescenario. Los problemas de disponibilidad son susceptibles de ocurrir de manera inesperada
y aleatoria. Cualquier medición de desempeño se basa primordialmente en las necesidades de
TI y no en las necesidades del usuario.
Observaciones: Según la información disponible no existen políticas y procedimientos
formales para la planificación de la capacidad. Se dispone de herramientas de monitoreo y
control como Nagios, HP Open View, Omnivista que dan alarmas ante distintas situaciones
pero no se lleva un registro de estos eventos, ni se realizan estadísticas que indiquen
tendencias para prever crecimiento a futuro.
4.3.4.- Garantizar la continuidad del servicio
Objetivo de control: La necesidad de brindar continuidad en los servicios de TI requiere
desarrollar, mantener y probar planes al respecto, almacenar respaldos fuera de las
instalaciones y entrenamiento periódico. Un proceso efectivo de continuidad de servicios,
minimiza la probabilidad y el impacto de las interrupciones mayores sobre funciones y
procesos claves
Este objetivo de control afecta los siguientes requerimientos de la información necesaria para
cumplir las misiones del Organismo, primariamente:

la efectividad

la disponibilidad
y en forma secundaria:

la eficiencia
Nivel de riesgo:
[X] Alto
[ ] Medio
[ ] Bajo
27
Nivel de madurez: Definido. La responsabilidad sobre la administración de la continuidad
del servicio es clara. Las responsabilidades de la planeación y de las pruebas de la
continuidad de los servicios están claramente asignadas y definidas. El plan de continuidad de
TI está documentado y basado en la criticidad de los sistemas y el impacto a las operaciones.
Hay reportes periódicos de las pruebas de continuidad. Los individuos toman la iniciativa
para seguir estándares y recibir capacitación para enfrentarse con incidentes mayores o
desastres. La gerencia comunica de forma regular la necesidad de planear el aseguramiento
de la continuidad del servicio. Se han aplicado componentes de alta disponibilidad y
redundancia. Se mantiene un inventario de sistemas y componentes críticos.
Observaciones: Existe y se encuentra formalizado un plan de continuidad del servicio. El
BCRA dispone de un Sitio Alternativo de Procesamiento, ubicado en el centro de cómputos
de la Armada Argentina, vinculado al centro de procesamiento principal mediante dos fibras
ópticas provistas por una empresa externa de telecomunicaciones
El plan de contingencia es manejado por la Gerencia Principal de Operaciones Informáticas.
Esta gerencia se ocupa además de manejar los robots que realizan las tareas de backup según
los procedimientos indicados por las Subgerencia de Administración de Bases de Datos y la
Subgerencia de Administración de Sistemas Operativos. La frecuencia de las tareas de
backup depende de las aplicaciones, de las bases de datos se realizan:

Diario full.

Semanal full.

Mensual full (se guarda por 10 años).
Además se registran y almacenan los registros de operación de los servidores críticos cada 15
minutos.
Se realizan pruebas parciales de los procedimientos de contingencia en forma periódica, la
última se realizó el 20 noviembre de 2010 que por ser un día sábado, en el que el sistema
bancario no funciona, no pudo incluir todos los procedimientos.
4.3.5.- Garantizar la Seguridad de los Sistemas
Objetivo de control: La necesidad de mantener la integridad de la información y de proteger
los activos de TI, requiere de un proceso de administración de la seguridad. Este proceso
28
incluye el establecimiento y mantenimiento de roles y responsabilidades, políticas, estándares
y procedimientos de TI. La administración de la seguridad también incluye realizar
monitoreos y pruebas periódicas así como acciones correctivas sobre las debilidades o
incidentes de identificados. Una efectiva administración de la seguridad protege todos los
activos de TI para minimizar el impacto causado por vulnerabilidades o incidentes de
seguridad
Este objetivo de control afecta los siguientes requerimientos de la información necesaria para
cumplir las misiones del Organismo, primariamente:

la confidencialidad

la integridad
y en forma secundaria:

la disponibilidad

el cumplimiento

la confiabilidad
Nivel de riesgo:
[X] Alto
[ ] Medio
[ ] Bajo
Nivel de madurez: Definido. Existe conciencia sobre la seguridad y ésta es promovida por la
gerencia. Los procedimientos están definidos y alineados con las políticas de seguridad de TI.
Las responsabilidades están asignadas, formalizadas, entendidas e implementadas. Existe un
plan de seguridad de TI formalmente definido. Se realizan pruebas adecuadas. Existe
capacitación en seguridad para TI y para el ente.
Observaciones: La Gerencia Principal de Seguridad de la Información es la responsable de
formular pautas, normas y estándares respecto de la seguridad información que se encuentra
en los sistemas del BCRA para garantizar su protección en los procesos de acceso,
procesamiento y transmisión. Elaboran normas tanto para el Organismo como para entidades
financieras. Dentro de la estructura de la Gerencia, se encuentra la Subgerencia de Normas de
Seguridad en Entidades que se dedica a la confección de normas para los bancos y entidades
del sistema financiero.
La Política de Seguridad de la Información está aprobada por el directorio del Banco. Se
formó un Comité de Seguridad de la Información presidido por un Director del Banco e
29
integrado por el Gerente General, Gerente de Seguridad Física y el Gerente de Seguridad de
la Información, entre otros. Existe un procedimiento formal para la aprobación de las normas
de seguridad.
La normativa sobre seguridad de la información está formalmente aprobada.
La defensa externa está compuesta por una estructura estándar, satisfactoria, que brinda
protección hacia el exterior
El BCRA está conectado con los bancos y entidades financieras por medio de una red privada
con líneas punto a punto entre el Organismo y cada una de las entidades. En ambos extremos
hay un encriptador provisto por el BCRA. Estas líneas están conectadas a un equipo
concentrador que es administrado por el banco, lo mismo que los certificados digitales de
estas conexiones.
No existe un procedimiento por el cual Recursos Humanos informe a Seguridad Informática
sobre licencias y ausencias para que esta última suspenda la posibilidad de acceso al sistema
de un empleado que se encuentre en tal situación.
El sistema de autenticación se encuentra sincronizado con el de control de accesos de forma
tal que solo puedan acceder al uso de los recursos de TI, a aquellos empleados que hayan
registrado su ingreso.
Para el control de la navegación de Internet, se dispone de un producto de filtrado de páginas
Web (IWSS).
4.3.6.- Identificar y Asignar Costos
Objetivo de control: La necesidad de un sistema justo y equitativo para asignar costos de TI,
requiere de una medición precisa y un acuerdo con los usuarios.
Este proceso incluye la construcción y operación de un sistema para capturar, distribuir y
reportar costos de TI a los usuarios de los servicios. Un sistema equitativo de costos permite
al ente tomar decisiones más informadas respectos al uso de los servicios de TI.
Este objetivo de control afecta los siguientes requerimientos de la información necesaria para
cumplir las misiones del Organismo, primariamente:

la eficiencia

la confiabilidad
30
Nivel de riesgo:
[X] Alto
[ ] Medio
[ ] Bajo
Nivel de madurez: Inicial. Hay un entendimiento general de los costos globales de los
servicios de información, pero no hay una distribución de costos por usuario, departamento,
grupos de usuarios, funciones de servicio, proyectos o entregables. Es casi nulo el monitoreo
de los costos. La distribución de costos de TI se hace como un costo fijo de operación
Observaciones: Las distintas áreas cargan su presupuesto anual en una aplicación a la que se
accede desde la Intranet que incluye solicitud de equipo informático y mejoras o nuevos
desarrollos. Se lleva un registro de los gastos realizados de soporte por cada Gerencia.
En la información recibida no se encontró documentación sobre el seguimiento de los gastos
presupuestados y si los gastos realizados fueron asignados a los sectores correspondientes.
4.3.7.- Educación y Capacitación de los Usuarios
Objetivo de control: Para una educación efectiva de todos los usuarios, incluyendo los
técnicos y profesionales de la materia, se requieren identificar las necesidades de
entrenamiento de cada grupo. Además de identificar las necesidades, este proceso incluye la
definición y ejecución de una estrategia para llevar a cabo un entrenamiento efectivo y para
medir los resultados. Un programa efectivo de entrenamiento incrementa el uso efectivo de la
tecnología al disminuir los errores, incrementando la productividad y el cumplimiento de los
controles clave tales como las medidas de seguridad de los usuarios.
Este objetivo de control afecta los siguientes requerimientos de la información necesaria para
cumplir las misiones del Organismo, primariamente:

la eficacia
y en forma secundaria:

la eficiencia
Nivel de riesgo:
[X] Alto
[ ] Medio
[ ] Bajo
Nivel de madurez: Repetible. Hay conciencia sobre la necesidad de un programa de
entrenamiento y educación, y sobre los procesos asociados a lo largo de toda la organización.
El entrenamiento está comenzando a identificarse en los planes de desempeño individuales de
los empleados. Los procesos se han desarrollado hasta la fase en la cual se imparte
entrenamiento informal por parte de diferentes instructores, cubriendo los mismos temas de
31
materias con diferentes puntos de vista. Algunas de las clases abordan los temas de conducta
ética y de conciencia sobre prácticas y actividades de seguridad en los sistemas. Hay una gran
dependencia del conocimiento de los individuos. Sin embargo, hay comunicación consistente
sobre los problemas globales y sobre la necesidad de atenderlos.
Observaciones: Si bien existe un Plan estratégico de capacitación, este no abarca cursos
específicos para el personal de TI. Para este personal, en general, las capacitaciones se
incluyen con la compra de nuevos productos o por solicitudes especificas realizadas por cada
gerente.
En materia de seguridad de la información se realizan campañas de concientización a los
usuarios sobre este tema. En la Intranet se encuentran publicadas las circulares internas y las
normas y procedimientos internos sobre Seguridad de la Información.
4.3.8.- Administrar la Mesa de Servicio y los Incidentes
Objetivo de control: Responder de manera oportuna y efectiva a las consultas de los
usuarios de TI, requiere de una mesa de servicio bien diseñada y ejecutada, y de un proceso
de administración de incidentes. Este proceso incluye la creación de una función de mesa de
servicio con registro, escalamiento de incidentes, análisis de tendencia, análisis causa-raíz y
resolución. Los beneficios incluyen el incremento en la productividad gracias a la resolución
rápida de consultas. Además, permite identificar la causa raíz (tales como un pobre
entrenamiento a los usuarios) a través de un proceso de reporte efectivo.
Este objetivo de control afecta los siguientes requerimientos de la información necesaria para
cumplir las misiones del Organismo, primariamente:

la efectividad

la eficacia
Nivel de riesgo:
[X] Alto
[ ] Medio
[ ] Bajo
Nivel de madurez: Administrado y Medible. En todos los niveles de la organización hay un
total entendimiento de los beneficios de un proceso de administración de incidentes y la
función de mesa de servicio se ha establecido en unidades organizaciones apropiadas. Las
herramientas y técnicas están automatizadas. El personal de la mesa de servicio interactúa
muy de cerca con el personal de administración de problemas. Las responsabilidades son
32
claras y se monitorea su efectividad. Los procedimientos para comunicar, escalar, y resolver
incidentes han sido establecidos y comunicados. El personal de mesa de servicio está
habilitado y los procesos se mejora a través de uso de software para tareas específicas.
Observaciones: La función de Mesa de Servicio es realizada por la Subgerencia de Atención
a Usuarios que dispone de operadores telefónicos, empleados que se ocupan de dar soporte de
primer nivel, de segundo nivel y de la gestión con las empresas de mantenimiento de equipos
y con las empresas con las que se tienen equipos en garantía.
Los incidentes quedan registrados en el SAU (Sistema de Atención a Usuarios), que es un
sistema de desarrollo propio que utiliza como motor de base de datos a SQL Server.
Este sistema no dispone de una base de conocimiento que permita al operador ver las
soluciones utilizadas para problemas similares.
El sistema permite realizar el seguimiento de cada uno de los incidentes para conocer cuál es
su estado o a quien fue derivado para su resolución.
4.3.9.- Administrar la Configuración
Objetivo de control: Garantizar la integridad de las configuraciones de hardware y software
requiere establecer y mantener un repositorio de configuraciones completo y preciso. Este
proceso incluye la recolección de información de la configuración inicial, el establecimiento
de normas, la verificación y auditoría de la información de la configuración y la actualización
del repositorio de configuración conforme se necesite. Una efectiva administración de la
configuración facilita una mayor disponibilidad, minimiza los problemas de producción y
resuelve los problemas más rápido.
Este objetivo de control afecta los siguientes requerimientos de la información necesaria para
cumplir las misiones del Organismo, primariamente:

la efectividad
y en forma secundaria:

la eficiencia

la disponibilidad

la confiabilidad
Nivel de riesgo:
[X] Alto
[ ] Medio
[ ] Bajo
33
Nivel de madurez: Administrado y Medible. En todos los niveles de la organización se
reconoce la necesidad de administrar la configuración y las buenas prácticas siguen
evolucionando. Los procedimientos y los estándares se comunican e incorporan a la
habilitación y las desviaciones son monitoreadas, rastreadas y reportadas. Se utilizan
herramientas automatizadas para fomentar el uso de estándares. Los sistemas de
administración de configuraciones cubren la mayoría de los activos de TI y permiten una
adecuada administración de liberaciones y control de distribución. Los análisis de
excepciones, así como las verificaciones físicas, se aplican de manera consistente y se
investigan las causas desde su raíz.
Observaciones: Los equipos de microinformática son entregados por la Subgerencia de
Instalaciones con una configuración de software y hardware definida según una circular
interna. Esta configuración no puede ser alterada por los usuarios porque la CPU viene con
un precinto de seguridad. Los usuarios no tienen privilegios de administración sobre el
sistema operativo.
Los servidores son controlados mediante una herramienta llamada OCS Inventory que
actualiza automáticamente cualquier cambio que se produzca tanto en hardware como en
software. Las actualizaciones de sistemas operativos de servidores se realizan siguiendo un
procedimiento formal.
4.3.10.- Administración de Problemas
Objetivo de control: Una efectiva administración de problemas requiere la identificación y
clasificación de problemas, el análisis de las causas desde su raíz y su resolución. El proceso
de administración de problemas también incluye la identificación de recomendaciones para la
mejora, el mantenimiento de registros y la revisión de estatus de las acciones correctivas. Un
efectivo proceso de administración de problemas mejora los niveles de servicio, reduce
costos y mejora la convivencia y satisfacción del usuario.
Este objetivo de control afecta los siguientes requerimientos de la información necesaria para
cumplir las misiones del Organismo, primariamente:

la eficacia

la eficiencia
34
y en forma secundaria:

la disponibilidad
Nivel de riesgo:
[X] Alto
[ ] Medio
[ ] Bajo
Nivel de madurez: Definido. Se acepta la necesidad de un sistema integrado de
administración de problemas y se evidencia con el apoyo de la gerencia y la asignación de
presupuesto para personal y habilitación. Se estandarizan los procesos de escalamiento y
resolución. El registro y rastreo de problemas y sus soluciones se dividen dentro del equipo
de respuesta utilizando las herramientas disponibles sin centralizar. Es poco probable detectar
las desviaciones de los estándares y de las normas establecidas. La información se comparte
entre el personal de manera formal y proactiva. La revisión de incidentes y los análisis son
limitados e informales.
Observaciones: Los problemas reportados por los usuarios se registran en el SAU y su
solución se va escalando según sea el inconveniente detectado y su grado de complejidad.
Los problemas que se presentan en los servidores ubicados tanto en el centro de cómputos
principal como en el sitio alternativo son derivados a las empresas contratadas para ese fin.
Si bien se llevan estadísticas de las tareas realizadas. No se encontró evidencia de la
existencia de una base de conocimiento centralizada que permita una resolución más
eficiente.
4.3.11.- Administración de Datos
Objetivo de control: Una efectiva administración requiere de la identificación del
requerimiento de datos. El proceso de administración de información también incluye el
establecimiento de procedimientos efectivos para administrar la librería de medios de soporte
para el respaldo y la recuperación de datos así como su eliminación apropiada. Una efectiva
administración de datos ayuda a garantizar la calidad, oportunidad y disponibilidad de la
información.
Este objetivo de control afecta los siguientes requerimientos de la información necesaria para
cumplir las misiones del Organismo, primariamente:

la integridad

la confiabilidad
35
Nivel de riesgo:
[X] Alto
[ ] Medio
[ ] Bajo
Nivel de madurez: Definido. Se entiende y acepta la necesidad de la administración de datos,
tanto dentro de TI como a lo largo de toda la organización. Se establece la responsabilidad
sobre su administración. Se asigna la propiedad sobre los datos a la parte responsable que
controla la integridad y la seguridad. Los procedimientos de administración se formalizan
dentro de TI y se utilizan algunas herramientas para su respaldo y recuperación. Se lleva a
cabo algún tipo de monitoreo sobre la administración. Se definen métricas básicas de
desempeño. Comienza a aparecer el entrenamiento sobre administración de información.
Observaciones: La propiedad de los datos está formalmente definida y existen
procedimientos para que los dueños de los mismos otorguen conformidad para los accesos.
Las bases de datos son mantenidas por la Subgerencia de Administración de Base de Datos,
el personal de la misma se ocupa de asignar los permisos a grupos o roles, asignar usuarios y
definir los procedimientos de backup de las bases de datos.
Existen contratos de soporte con todos los proveedores excepto con uno, encontrándose en
proceso de negociación.
No existe un diccionario de datos de la organización, se encuentra en proceso de compra la
adquisición de una herramienta de modelado de datos y procesos que permita la creación del
mismo.
La Subgerencia de Administración de Bases de Datos define una agenda de backup que
ejecuta el sector de operaciones. Estos procesos disponen de alarmas que se disparan en el
caso de producirse una cancelación y de pistas de auditoría para los finalizados
correctamente.
4.3.12.- Administración de Instalaciones
Objetivo de control: La protección del equipo de cómputo y del personal, requiere de
instalaciones bien diseñadas y administradas. El proceso de administrar el ambiente físico del
centro de datos, la selección de instalaciones apropiadas y el diseño de procesos efectivos
para monitorear factores ambientales y administrar el acceso físico. La administración
efectiva del ambiente físico reduce las interrupciones del servicio ocasionadas por daños al
equipo de cómputo y al personal.
36
Este objetivo de control afecta los siguientes requerimientos de la información necesaria para
cumplir las misiones del Organismo, primariamente:

la integridad

la disponibilidad
Nivel de riesgo:
[X] Alto
[ ] Medio
[ ] Bajo
Nivel de madurez: Repetible. Los controles ambientales se implementan y monitorean por
parte del personal de operaciones. La seguridad física es un proceso informal, realizado por
un pequeño grupo de empleados con alto nivel de preocupación por asegurar las instalaciones
físicas. Los procedimientos de mantenimiento de instalaciones no están bien documentados y
dependen de las buenas prácticas de unos cuantos individuos. Las metas de seguridad física
no se basan en estándares formales y la gerencia no se asegura de que se cumplan los
objetivos de seguridad.
Observaciones: El BCRA dispone de dos centros de procesamiento en distintos edificios; el
principal y un sitio de procesamiento alternativo (SAP) de la Armada Argentina.
Ambos centros están vinculados por medio de fibra óptica.
Actualmente está en etapa de proyecto la construcción de un nuevo edificio a donde está
previsto mudar el actual centro de procesamiento principal.
En el sitio de procesamiento principal tiene instalados 75 servidores físicos propios y equipos
pertenecientes al Mercado Abierto Electrónico (MAE), al Mercado de Futuros y Opciones de
Rosario (ROFEX). Además están instalados servidores de comunicaciones de las distintas
empresas de telecomunicaciones que vinculan al BCRA con los bancos y entidades
financieras.
En el sitio de procesamiento principal, si bien se controlan los parámetros ambientales se
observó que no es correcta la distribución de los equipos para una adecuada disipación de
calor. Se observaron racks abiertos con los cables a la vista, reparaciones de mampostería no
terminadas y cables sueltos en el piso
El sitio de procesamiento alternativo, tiene las mismas deficiencias que presenta el sitio
principal a lo que se agrega una inadecuada descarga del líquido de condensación de aire
37
acondicionado, matafuegos colocados en el piso, fuera de los soportes correspondientes y
conductos de cables sin sus correspondientes tapas.
4.3.13.- Administración de Operaciones
Objetivo de control: Un procesamiento completo y apropiado de la información requiere su
efectiva administración y el mantenimiento del hardware. Este proceso incluye la definición
de políticas y procedimientos de operación para una administración efectiva del
procesamiento programado, protección de datos de salida sensitivos, monitoreo de
infraestructura y mantenimiento preventivo de hardware. Una efectiva administración de
operaciones ayuda a mantener la integridad de los datos y reduce los retrasos en el trabajo y
los costos operativos de TI.
Este objetivo de control afecta los siguientes requerimientos de la información necesaria para
cumplir las misiones del Organismo, primariamente:

la efectividad

la eficiencia
y en forma secundaria:

la integridad

la disponibilidad
Nivel de riesgo:
[X] Alto
[ ] Medio
[ ] Bajo
Nivel de madurez: Definido. Se entiende y acepta dentro de la organización la necesidad de
administrar las operaciones de cómputo. Se han asignado recursos y las funciones repetitivas
están definidas, estandarizadas, documentadas y comunicadas de manera formal. Los
resultados de las tareas completadas y de los eventos se registran, con reportes limitados
hacia la gerencia. Se introduce el uso de herramientas de programación automatizadas y de
otras herramientas para limitar la intervención del operador. Se introducen controles para
colocar nuevos trabajos en operación. Se desarrolla una política formal para reducir el
número de eventos no programados. Los acuerdos de servicio y mantenimiento con
proveedores siguen siendo de naturaleza informal.
Observaciones: De la operación el centro de cómputos se ocupa la Gerencia de Centros de
Procesamiento que depende de la Gerencia Principal de Operaciones Informáticas.
38
El sitio de procesamiento alternativo es administrado en forma remota.
El personal de operaciones se ocupa además de los robots que realizan los respaldos de
información de acuerdo a los procedimientos definidos formalmente por las áreas
correspondientes y de la digitalización, microfilmación y procesamiento de imágenes según
procedimientos formalmente definidos
4.4.- Monitorear y Evaluar
4.4.1.- Monitorear y Evaluar el Desempeño de TI
Objetivo de control: Una efectiva administración del desempeño de TI requiere un proceso
de monitoreo. El proceso incluye la definición de indicadores de desempeño relevantes,
reportes sistemáticos y oportunos de desempeño y tomar medidas expeditas cuando existan
desviaciones. El monitoreo se requiere para garantizar que las cosas correctas se hagan y que
estén de acuerdo con el conjunto de direcciones y políticas definidas formalmente.
Este objetivo de control afecta, primariamente:

la efectividad

la eficiencia
y en forma secundaria:

la confidencialidad

la integridad

la disponibilidad

el cumplimiento

la confiabilidad
Nivel de riesgo:
[X] Alto
[ ] Medio
[ ] Bajo
Nivel de Madurez: Inicial. La gerencia reconoce una necesidad de recolectar y evaluar
información sobre los procesos de monitoreo. No se han identificado procesos estándar de
recolección y evaluación. El monitoreo se implanta y las métricas se seleccionan de acuerdo a
cada caso, o a las necesidades de proyectos y procesos de TI específicos. El monitoreo por lo
general se implanta de forma reactiva a algún incidente. La función de contabilidad
monitorea mediciones financieras básicas para TI.
39
Observaciones: La conducción del área no ha institucionalizado un proceso estándar de
monitoreo. Se han implantado algunos esquemas en relación a la administración de proyectos
y sobre la infraestructura tecnológica, pero no se encuadra en un programa de monitoreo
institucional donde se pueda medir la calidad del servicio y el desempeño en general. Las
evaluaciones se realizan al nivel de procesos y proyectos individuales de TI, pero no están
integradas a través de todos los procesos.
No se ha desarrollado una base de conocimiento formalizada donde se pueda evaluar el
desempeño histórico. En el caso del monitoreo de la infraestructura tecnológica, tienen
alarmas pero no llevan estadísticas.
No existe un marco de administración financiera de los proyectos, ni la administración de
costos o beneficios que permita evaluar la contribución esperada de TI a los resultados del
Organismo.
4.4.2.- Monitorear y Evaluar el Control Interno
Objetivo de control: Establecer un programa de control interno efectivo para TI requiere un
proceso bien definido de monitoreo. Este proceso incluye el monitoreo y el reporte de las
excepciones de control, resultados de las auto-evaluaciones y revisiones por parte de terceros.
Un beneficio clave del monitoreo del control interno es proporcionar seguridad respecto a
que las operaciones sean eficientes y efectivas y el cumplimiento de las leyes y regulaciones
aplicables.
Este objetivo de control afecta, primariamente:

la efectividad

la eficiencia
y en forma secundaria:

la confidencialidad

la integridad

la disponibilidad

el cumplimiento

la confiabilidad
Nivel de riesgo:
[X] Alto
[ ] Medio
[ ] Bajo
40
Nivel de Madurez: Repetible. La 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ón tiene conciencia sobre el monitoreo de los
controles internos. La gerencia de servicios de información realiza monitoreo periódico sobre
la efectividad de lo que considera controles internos críticos. Se están empezando a usar
metodologías y herramientas para monitorear los controles internos, aunque no se basan en
un plan formal. Los factores de riesgo específicos del ambiente de TI se identifican con base
en las habilidades de individuos.
Observaciones: Existe un marco de trabajo para el monitoreo del control interno de TI,
basado en un Plan de Auditoría que se somete a la aprobación de un Comité de Auditoría.
Dicho plan se elabora en función de una evaluación de riesgos previa. Durante la ejecución
del mismo, se realizan informes trimestrales, semestrales y anuales. Algunos casos
considerados críticos, son elevados al Directorio del Organismo.
Este marco de control es limitado a algunos procesos que se consideran relevantes al
momento de la elaboración del plan.
Falta profundizar el alcance del control interno a procedimientos de uso frecuente como parte
de una acción de control preventivo. Faltan métricas de monitoreo del control interno.
4.4.3.- Garantizar el Cumplimiento con Requerimientos Externos
Objetivo de control: Una supervisión efectiva del cumplimiento de las regulaciones requiere
el establecimiento de un proceso independiente de revisión. Este proceso incluye la
definición de una declaración de auditoría, independencia de los auditores, ética y estándares
profesionales, planeación, desempeño del trabajo de auditoría y reportes y seguimiento a las
actividades de auditoría. El propósito de este proceso es proporcionar un aseguramiento
positivo relativo al cumplimiento de TI de las leyes y regulaciones.
Este objetivo de control afecta, primariamente:

el cumplimiento
y en forma secundaria:

la confiabilidad
Nivel de riesgo:
[X] Alto
[ ] Medio
[ ] Bajo
41
Nivel de Madurez: Proceso Definido. Se han desarrollado, documentado y comunicado
políticas, procedimientos y procesos, para garantizar el cumplimiento de los reglamentos y de
las obligaciones legales. Se brinda entrenamiento sobre requisitos legales y regulatorios
externos que afectan a la organización y se instruye respecto a los procesos de cumplimiento
definidos.
Observación: El Banco no ha implementado un sistema de medición del nivel de
incumplimiento de los requerimientos externos que genere informes periódicos a la
Dirección.
4.4.4.- Proporcionar Gobierno de TI
Objetivo de control: El establecimiento de un marco de trabajo para una administración
efectiva, incluye la definición de estructuras, procesos, liderazgo, roles y responsabilidades
organizacionales para garantizar así que las inversiones en TI estén alineadas y de acuerdo
con las estrategias y objetivos del Organismo.
Este objetivo de control afecta, primariamente:

la efectividad

la eficiencia
y en forma secundaria:

la confidencialidad

la integridad

la disponibilidad

el cumplimiento

la confiabilidad
Nivel de riesgo:
[X] Alto
[ ] Medio
[ ] Bajo
Nivel de Madurez: Inicial. Se reconoce que el tema del gobierno de TI existe y que debe ser
resuelto. Existen enfoques ad hoc aplicados individualmente o caso por caso. El enfoque de la
gerencia es reactivo y solamente existe una comunicación esporádica e inconsistente sobre
los temas y los enfoques para resolverlos. La gerencia solo cuenta con una indicación
aproximada de cómo TI contribuye al logro de los objetivos.
42
Observaciones: Existe una organización de TI con funciones, roles, delegaciones y
responsabilidades bien definidos. Sin embargo, varias posiciones se encuentran sin cubrir al
momento de esta auditoría. No existe un plan Estratégico, ni un marco de administración
financiera de TI, ni de evaluación de riesgos, ni gestión de aseguramiento de la calidad, ni de
monitoreo. Existe conciencia sobre los temas de gobierno de TI, pero faltan actividades e
indicadores de desempeño del gobierno de TI, los cuales incluyan planeamiento, producción
de información y supervisión.
5.- Comunicación del proyecto de informe y análisis de los descargos formulados por el
Organismo.
El Proyecto de Informe de auditoría fue enviado al Organismo auditado para que formule las
observaciones y/o comentarios que estime pertinentes, con fecha 19 de abril de 2012, por
Nota AGN N° 89/12-A02. Los mismos (Anexo VI) fueron remitidos por el Ente el 27 de
junio de 2012.
Como consecuencia del análisis del descargo presentado por el Organismo auditado (Anexo
V), se ratifican las observaciones oportunamente formuladas.
6.- Recomendaciones
Se detallan a continuación las buenas prácticas aconsejadas para cada uno de los procesos,
independientemente del hecho de que ya hayan sido parcialmente puestas en práctica.
6.1.- Planear y organizar
6.1.1.- Definir un plan estratégico para TI

Crear un Plan estratégico de TI: Crear un plan estratégico que defina, en cooperación
con los interesados relevantes, cómo la TI contribuirá a los objetivos estratégicos del
Organismo. Definir cómo se cumplirán y medirán los objetivos con la autorización
formal de los interesados. El plan estratégico de TI debe incluir el presupuesto de la
inversión/operativo, la estrategia de procuración, la estrategia de adquisición, y los
requerimientos legales y regulatorios. El plan estratégico debe ser lo suficientemente
detallado para permitir la definición de planes tácticos de TI.
43

Crear un conjunto de planes tácticos de TI que se deriven del plan estratégico: Estos
planes tácticos describen las iniciativas y los requerimientos de recursos requeridos
por TI, y cómo su uso y el logro de los beneficios serán monitoreados y
administrados. Los planes tácticos deben tener el detalle suficiente para permitir la
definición de los proyectos. Administrar de forma activa los planes tácticos y las
iniciativas de TI establecidas por medio del análisis de los proyectos y servicios. Esto
incluye el equilibrio de los requerimientos y recursos de forma regular,
comparándolos con el logro de metas estratégicas y tácticas y con los beneficios
esperados, y tomando las medidas necesarias en caso de desviaciones.

Administrar los programas de inversión de TI: Administrar de forma activa el
conjunto de programas de inversión de TI requerido para lograr los objetivos
estratégicos del Organismo por medio de la identificación, definición, evaluación,
asignación de prioridades, selección, inicio, administración y control de los
programas. Esto incluye clarificar los resultados deseados, garantizar que los
objetivos de los programas den soporte al logro de los resultados, entender el alcance
completo del esfuerzo requerido para lograr los resultados, definir una rendición de
cuentas clara con medidas de soporte, definir proyectos dentro del programa, asignar
recursos y financiamiento, delegar autoridad, y lanzar el programa junto con sus
proyectos requeridos.

Administrar el valor de TI: Garantizar que el grupo de inversiones de TI de la
organización contenga programas con casos de acción sólidos. Reconocer que existen
inversiones obligatorias, de sustento y discrecionales que difieren en complejidad y
grado de libertad en cuanto a la asignación de fondos. Los procesos de TI deben
proporcionar una entrega efectiva y eficiente de los componentes TI de los programas
y advertencias oportunas sobre las desviaciones del plan, incluyendo costo, calendario
o funcionalidad, que pudieran impactar los resultados esperados de los programas.
Los servicios de TI se deben ejecutar contra acuerdos de niveles de servicios
equitativos y exigibles. La rendición del logro de los beneficios y del control de los
costos debe ser claramente asignada y monitoreada. Establecer una evaluación de los
44
casos de acción que sea justa, transparente, repetible y comparable, incluyendo el
valor financiero, el riesgo de no cumplir con una capacidad y el riesgo de no
materializar los beneficios esperados.

Alinear a TI con los objetivos del Organismo: Educar a los ejecutivos sobre las
capacidades tecnológicas actuales y sobre el rumbo futuro, sobre las oportunidades
que ofrece TI, y sobre qué se debe hacer para capitalizar esas oportunidades.
Asegurarse de que el rumbo de los procesos a los cuales está alineado la TI está bien
entendido. Las estrategias deben estar integradas, relacionando de manera clara las
metas del Organismo y las metas de TI y reconociendo las oportunidades así como las
limitaciones en la capacidad actual, y se deben comunicar de manera amplia.
Identificar las áreas en que se depende de forma crítica de la TI, y mediar entre los
objetivos y la tecnología, de tal modo que se puedan establecer prioridades
concertadas.

Evaluar el desempeño actual: Evaluar el desempeño de los planes existentes y de los
sistemas de información en términos de su contribución a los objetivos del
Organismo, su funcionalidad, su estabilidad, su complejidad, sus costos, sus fortalezas
y debilidades.
6.1.2.- Definir la arquitectura de información

Establecer y mantener un modelo de información que facilite el desarrollo de
aplicaciones y las actividades de soporte a la toma de decisiones, consistente con los
planes de TI como se describen en Plan Estratégico. El modelo facilita la creación,
uso y compartición óptimas de la información de manera que se conservan la
integridad, flexibilidad, funcionalidad, y tolerancia a fallas.

Mantener un diccionario de datos de la organización que incluya las reglas de sintaxis
de datos. El diccionario facilita la compartición de elementos de datos entre las
aplicaciones y los sistemas, fomenta un entendimiento común de datos entre los
usuarios de TI, y previene la creación de elementos de datos incompatibles.

Establecer un esquema de clasificación de datos que aplique a todo el ente, basado en
la criticidad y sensibilidad de la información del Organismo. Este esquema incluye
45
detalles acerca de la propiedad de datos, la definición de niveles apropiados de
seguridad y de controles de protección, y una breve descripción de los requerimientos
para su retención y destrucción, además de qué tan críticos y sensibles son. Se usa
como base para aplicar controles para acceso, archivo o encriptación.

Definir e implantar procedimientos para garantizar la integridad y consistencia de
todos los datos almacenados en formato electrónico, tales como bases de datos,
depósitos de datos y archivos.
6.1.3.- Determinar la dirección tecnológica:

Planear la Dirección Tecnológica: Analizar las tecnologías existentes y emergentes y
planear cuál dirección tecnológica conviene tomar para materializar la estrategia de TI
y la arquitectura de sistemas. También identificar en el plan qué tecnologías tienen el
potencial de crear oportunidades para la acción del ente. El plan debe abarcar la
arquitectura de sistemas, la dirección tecnológica, las estrategias de migración y los
aspectos de contingencia de los componentes de la infraestructura.

Elaborar un Plan de infraestructura tecnológica: Crear y mantener un plan de
infraestructura tecnológica que esté de acuerdo con los planes estratégicos y tácticos
de TI. El plan debe basarse en la dirección tecnológica e incluir acuerdos para
contingencias y orientación para la adquisición de recursos tecnológicos. También
toma en cuenta la mejora en la interoperabilidad de las plataformas y las aplicaciones.

Monitorear tendencias y regulaciones futuras: Establecer un proceso para monitorear
las tendencias ambientales del sector, de infraestructura, legales y regulatorias. Incluir
las consecuencias de estas tendencias en el desarrollo del plan de infraestructura
tecnológica de TI.

Establecer
Estándares
tecnológicos:
Proporcionar
soluciones
tecnológicas
consistentes, efectivas y seguras para toda la organización, establecer un foro
tecnológico para brindar directrices, asesoría sobre los productos de la infraestructura
y guías sobre la selección de la tecnología, y medir el cumplimiento de estos
estándares y directrices. Este foro impulsa los estándares y las prácticas tecnológicas
46
con base en su importancia y riesgo para la acción del Organismo y en el
cumplimiento de requerimientos externos.

Establecer un consejo de arquitectura de TI: Proporcionar directrices sobre la
arquitectura y asesoría sobre su aplicación y que verifique el cumplimiento. Esta
entidad orienta el diseño de la arquitectura de TI garantizando que facilite la estrategia
del Organismo y tome en cuenta el cumplimiento regulatorio y los requerimientos de
continuidad. Estos aspectos se relacionan con la arquitectura de la información
6.1.4.- Definir los procesos, organización y relaciones de TI

Ubicación Organizacional de la Función de TI: Ubicar a la función de TI dentro de la
estructura general supeditado a la importancia de TI dentro del Organismo, en
especial en función de qué tan crítica es para la estrategia del ente y el nivel de
dependencia operativa sobre TI.

Estructura Organizacional: Establecer una estructura organizacional de TI que refleje
las necesidades del Organismo. Además implementar un proceso para revisar la
estructura organizacional de TI de forma periódica para ajustar los requerimientos de
personal y las estrategias internas para satisfacer los objetivos esperados y las
circunstancias cambiantes.

Establecimiento de Roles y Responsabilidades: Definir y comunicar los roles y las
responsabilidades para el personal de TI y delimitar la relación entre el personal de TI
y los usuarios finales, definiendo las responsabilidades y la rendición de lo actuado.

Responsabilidad de Aseguramiento de Calidad de TI: Asignar la responsabilidad para
el desempeño de la función de aseguramiento de calidad (QA). Asegurar que la
ubicación organizacional, las responsabilidades y el tamaño del grupo de QA
satisfagan los requerimientos de la organización.

Responsabilidad sobre el Riesgo, la Seguridad y el Cumplimiento: Establecer la
propiedad y la responsabilidad de los riesgos relacionados con TI a un nivel
apropiado. Definir y asignar roles críticos para administrar los riesgos de TI,
incluyendo la responsabilidad específica de la seguridad de la información, la
seguridad física y el cumplimiento. Puede ser necesario asignar responsabilidades
47
adicionales de administración de la seguridad a nivel de sistema. Obtener orientación
de la alta dirección con respecto al nivel de riesgo de TI dispuestos a aceptar y la
aprobación de cualquier riesgo residual.

Propiedad de Datos y de Sistemas: Desarrollar los procedimientos y herramientas que
permitan enfrentar las responsabilidades de propiedad sobre los datos y los sistemas
de información. Los dueños de los datos toman decisiones sobre la clasificación de la
información y de los sistemas y sobre cómo protegerlos de acuerdo a esta
clasificación.

Implantar prácticas adecuadas de supervisión dentro de la función de TI para
garantizar que los roles y las responsabilidades se ejerzan de forma apropiada, para
evaluar si todo el personal cuenta con la suficiente autoridad y recursos para ejecutar
sus roles y responsabilidades y para revisar en general los indicadores clave de
desempeño.

Implantar una división de roles y responsabilidades que reduzca la posibilidad de que
un solo individuo afecte negativamente un proceso crítico. La gerencia también se
debe asegurar de que el personal realice sólo las tareas autorizadas, relevantes a sus
puestos y posiciones respectivas.

Evaluar los requerimientos de personal de forma regular o cuando existan cambios
importantes en el ambiente operativo o de TI para garantizar que la función de TI
cuente con un número suficiente de personal competente. Se debe asegurar que exista
el entrenamiento cruzado-funcional y la rotación de puestos.

Definir e identificar al personal clave de TI y minimizar la dependencia excesiva en
ellos. Debe existir un plan para contactar al personal clave en caso de emergencia.

Políticas y procedimientos para personal contratado: Definir e implantar políticas y
procedimientos para controlar las actividades de los consultores u otro personal
contratado por TI para garantizar la protección de los activos de información de la
organización y satisfacer los requerimientos contractuales.

Establecer y mantener una estructura de enlace, comunicación y coordinación entre la
función de TI y otras funciones dentro y fuera de la función de TI, tales como el
48
consejo directivo, ejecutivos, usuarios individuales, proveedores, oficiales de
seguridad, gerentes de riesgo, el grupo de control de cumplimiento y los contratistas
externos.

Establecer un comité estratégico de TI que deberá asegurar que su gerenciamiento,
como parte del gerenciamiento general del ente, se maneja de forma adecuada,
asesora sobre la dirección estratégica y revisa las inversiones principales en nombre
de la conducción del Organismo.

Establecer un comité directivo de TI compuesto por la gerencia ejecutiva, del proceso
y de TI para:
o Determinar las prioridades de los programas de inversión de TI alineadas con
la estrategia y prioridades del Organismo.
o Dar seguimiento al estatus de los proyectos y resolver los conflictos de
recursos.
o Monitorear los niveles y las mejoras de servicio.
6.1.5.- Administrar la inversión en TI

Establecer un marco de Administración Financiera para TI que impulse el presupuesto
y el análisis por centro de costos. Dar mantenimiento a los programas de inversión de
TI, de servicios y de activos, los cuales forman la base para el presupuesto. Brindar
información de entrada hacia las nuevas inversiones, tomando en cuenta los activos
actuales y servicios de TI.

Implantar un proceso de toma de decisiones para dar prioridades a la asignación de
recursos a TI para operaciones, proyectos y mantenimiento, de manera tal de
maximizar la contribución de TI a los procesos.

Establecer un proceso para elaborar y administrar un presupuesto que refleje las
prioridades establecidas en los programas de inversión en TI, incluyendo los costos
recurrentes de operar y mantener la infraestructura actual. El proceso debe dar soporte
al desarrollo de un presupuesto general de TI así como al desarrollo de presupuestos
para programas individuales, con énfasis especial en los componentes de TI de esos
49
programas. El proceso debe permitir la revisión, el refinamiento y la aprobación
constantes del presupuesto general y de los presupuestos de programas individuales.

Implantar un proceso de administración de costos que compare los costos reales con
los presupuestados. Los costos se deben monitorear y reportar. Cuando existan
desviaciones, éstas se deben identificar de forma oportuna y el impacto de esas
desviaciones sobre los programas se debe evaluar y se deberán tomar las medidas
correctivas apropiadas.

Implantar un proceso de monitoreo y reporte de beneficios que permita medir la
contribución esperada de TI al cumplimiento de los objetivos del Organismo. Los
reportes se deben revisar y, donde existan oportunidades para mejorar la contribución
de TI, se deben definir y tomar las medidas apropiadas.
6.1.6.- Comunicar las aspiraciones y la dirección de la gerencia de TI

Comunicación de los objetivos y la dirección de TI: Asegurarse de que la conciencia y
el entendimiento de los objetivos de TI se comuniquen a toda la organización. La
información comunicada debe abarcar una misión claramente articulada, los objetivos
de servicio, la seguridad, los controles internos, la calidad, el código de ética y
conducta, políticas y procedimientos, etc., y se deben incluir dentro de un programa
de comunicación continua, apoyado por la conducción del Organismo con acciones y
palabras. La dirección debe dar especial atención a comunicar la conciencia sobre la
seguridad de TI y el mensaje de que la seguridad de TI es responsabilidad de todos.

Implantación de políticas de TI: Asegurarse de que las políticas de TI se implanten, se
comuniquen a todo el personal relevante y se refuercen, de tal forma que estén
incluidas y sean parte integral de las operaciones.

Riesgo y Marco de Referencia de Control Interno de TI: Elaborar y dar
mantenimiento a un marco de trabajo que establezca el enfoque general hacia los
riesgos y hacia el control interno para entregar valor mientras al mismo tiempo se
protegen los recursos y sistemas de TI. El marco de trabajo debe estar integrado por el
marco de procesos de TI y el sistema de administración de calidad, y debe cumplir los
objetivos generales del Organismo. Debe tener como meta minimizar los riesgos para
50
los activos de información por medio de medidas preventivas, la identificación
oportuna de irregularidades, la limitación de pérdidas y la oportuna recuperación de
activos.
6.1.7.- Administrar los recursos humanos de TI

Reclutamiento y Retención del Personal: Asegurarse que los procesos de
reclutamiento del personal de TI estén de acuerdo a las políticas y procedimientos
generales de personal de la organización. La conducción debe implementar procesos
para garantizar que la organización cuente con una fuerza de trabajo posicionada de
forma apropiada y que tenga las habilidades necesarias para alcanzar las metas
organizacionales.

Competencias del personal: Verificar de forma periódica que el personal tenga las
habilidades para cumplir sus roles con base en su educación, entrenamiento y/o
experiencia. Definir los requerimientos esenciales de habilidades para TI y verificar
que se les dé capacitación, usando programas de calificación y certificación según sea
el caso.

Asignación de roles: Definir, monitorear y supervisar los marcos de trabajo para los
roles, responsabilidades y compensación del personal, incluyendo el requisito de
adherirse a las políticas y procedimientos administrativos, así como al código de ética
y prácticas profesionales. Los términos y condiciones de empleo deben enfatizar la
responsabilidad del empleado respecto a la seguridad de la información, al control
interno y al cumplimiento regulatorio. El nivel de supervisión debe estar de acuerdo
con la sensibilidad del puesto y el grado de responsabilidades asignadas.

Entrenamiento del personal de TI: Proporcionar a los empleados de TI la orientación
necesaria al momento de la contratación y entrenamiento continuo para conservar su
conocimiento, aptitudes, habilidades, controles internos y conciencia sobre la
seguridad, al nivel requerido para alcanzar las metas organizacionales.

Dependencia sobre los individuos: Minimizar la exposición a dependencias críticas
sobre individuos clave por medio de la captura del conocimiento (documentación),
compartir el conocimiento, planeación de la sucesión y respaldos de personal.
51

Evaluación del desempeño del empleado: Es necesario que las evaluaciones de
desempeño se realicen periódicamente, comparando contra los objetivos individuales
derivados de las metas organizacionales, estándares establecidos y responsabilidades
específicas del puesto. Los empleados deben recibir adiestramiento sobre su
desempeño y conducta, según sea necesario.

Cambios y terminación de trabajo: Tomar medidas expeditas respecto a los cambios
en los puestos, en especial las terminaciones. Se debe realizar la transferencia del
conocimiento, reasignar responsabilidades y se deben eliminar los privilegios de
acceso, de tal modo que los riesgos se minimicen y se garantice la continuidad de la
función.
6.1.8.- Administrar la calidad

Se debe establecer un Sistema de Administración de la Calidad (SAC) que
proporcione un enfoque estándar, formal y continuo alineado con las necesidades del
ente. El SAC identifica los requerimientos y los criterios de calidad, los procesos
claves de TI, y su secuencia e interacción, así como las políticas, criterios y métodos
para definir, detectar, corregir y prever los desvíos. El SAC debe definir la estructura
organizacional para la administración de la calidad, cubriendo los roles, las tareas y
las responsabilidades. Todas las áreas clave desarrollan sus planes de calidad de
acuerdo a los criterios y políticas, y registran los datos. Se debe monitorear y medir la
efectividad y aceptación del SAC y mejorarla cuando sea necesario.

Se deben identificar y mantener estándares, procedimientos y prácticas para los
procesos clave de TI para orientar a la organización hacia el cumplimiento del SAC.

Se deben adoptar y mantener estándares para todo el desarrollo y adquisición que
siguen el ciclo de vida, hasta el último entregable e incluyen la aprobación en puntos
clave con base en criterios de aprobación acordados. Los temas a considerar incluyen
estándares de codificación de software, normas de nomenclatura; formatos de
archivos, estándares de diseño para esquemas y diccionario de datos; estándares para
la interfaz de usuario; inter-operabilidad; eficiencia de desempeño de sistemas;
52
escalabilidad; estándares para desarrollo y pruebas; validación contra requerimientos;
planes de pruebas; y pruebas unitarias, de regresión y de integración.

La administración de la calidad debe enfocarse a los usuarios, al determinar sus
requerimientos y alinearlos con los estándares y prácticas de TI. Se deben definir los
roles y responsabilidades respecto a la resolución de conflictos entre el usuario y la
organización de TI.

Se debe elaborar y comunicar un plan global de calidad que promueva la mejora
continua, de forma periódica a través de mediciones para monitorear el cumplimiento
continuo del SAC, así como el valor que SAC proporciona. La medición, el monitoreo
y el registro de la información deben ser usados por el dueño del proceso para tomar
las medidas correctivas y preventivas apropiadas.
6.1.9.- Evaluar y administrar los riesgos de TI

Se debe integrar el gobierno, la administración de riesgos y el marco de control de TI,
al marco de trabajo de administración de riesgos de la organización. Esto incluye la
alineación con el nivel de riesgo que el Organismo esté dispuesto a asumir y con el
nivel de tolerancia al riesgo de la organización.

Se debe establecer el contexto en el cual el marco de trabajo de evaluación de riesgos
se aplica para garantizar resultados apropiados. Esto incluye la determinación del
contexto interno y externo de cada evaluación de riesgos, la meta de la evaluación y
los criterios contra los cuales se evalúan los riesgos.

Se deben identificar todos aquellas amenazas y vulnerabilidades que tengan un
impacto potencial sobre las metas o las operaciones del Organismo, aspectos
regulatorios, legales, tecnológicos, de recursos humanos y operativos. Determinar la
naturaleza del impacto y dar mantenimiento a esta información.

Evaluar de forma recurrente la posibilidad e impacto de todos los riesgos
identificados, usando métodos cualitativos y cuantitativos. La posibilidad e impacto
asociados a los riesgos inherentes y residuales se debe determinar de forma
individual.
53

Identificar los propietarios de los riesgos y a los dueños de procesos afectados, y
elaborar y mantener respuestas a los riesgos que garanticen que los controles y las
medidas de seguridad mitigan la exposición de forma continua. La respuesta a los
riesgos debe identificar estrategias tales como evitar, reducir, compartir o aceptar. Al
elaborar la respuesta, considerar los costos y beneficios y seleccionar respuestas que
limiten los riesgos residuales dentro de los niveles de tolerancia de riesgos definidos.

Mantenimiento y monitoreo de un plan de acción de riesgos: Asignar prioridades y
planear las actividades de control a todos los niveles para implantar las respuestas a
los riesgos, identificadas como necesarias, incluyendo la identificación de costos,
beneficios y la responsabilidad de la ejecución. Buscar la aprobación para las acciones
recomendadas y la aceptación de cualquier riesgo residual, y asegurarse de que las
acciones comprometidas son propiedad del dueño o dueños de los procesos afectados.
Monitorear la ejecución de los planes y reportar cualquier desviación a la conducción
del ente.
6.1.10.- Administrar proyectos

Preparar un plan de administración de la calidad que describa el sistema de calidad del
proyecto y cómo será implantado. El plan debe ser revisado y acordado de manera
formal por todas las partes interesadas para luego ser incorporado en el plan integrado
del proyecto.

Establecer un sistema de control de cambios para cada proyecto, de tal modo que
todos los cambios a la línea base del proyecto, como por ejemplo costos, cronograma,
alcance y calidad, se revisen, aprueben e incorporen de manera apropiada al plan
integrado, de acuerdo al marco de trabajo de control del programa y del proyecto.

Identificar las tares de aseguramiento requeridas para apoyar la acreditación de
sistemas nuevos o modificados durante la planeación del proyecto e incluirlos en el
plan integrado. Las tareas deben proporcionar la seguridad de que los controles
internos y las características de seguridad satisfagan los requerimientos definidos.

Medir el desempeño del proyecto contra los criterios clave como el alcance, los
tiempos, la calidad, los costos o los riesgos; identificar las desviaciones con respecto
54
al plan; evaluar su impacto sobre el proyecto y sobre el programa global; reportar los
resultados a los interesados clave; y recomendar, implantar y monitorear las medidas
correctivas, según sea requerido, de acuerdo con el marco de trabajo de gobierno del
programa y del proyecto.

Solicitar que al finalizar cada proyecto, los interesados se cercioren de que el proyecto
haya proporcionado los resultados y los beneficios esperados. Identificar y comunicar
cualquier actividad sobresaliente requerida para alcanzar los resultados planeados del
proyecto y los beneficios del programa, e identificar y documentar las lecciones
aprendidas a ser usadas en futuros proyectos y programas.
6.2.- Adquirir e implementar
6.2.1.- Identificar soluciones automatizadas

Definir y mantener los requerimientos técnicos y funcionales del Organismo.
Establecer procesos para garantizar y administrar la integridad, exactitud y la validez
de los requerimientos de las necesidades funcionales del Organismo, como base para
el control de la adquisición y el desarrollo continuo de sistemas. Estos requerimientos
deben ser propiedad del patrocinador de la aplicación.

Estudio de factibilidad y formulación de cursos de acción alternativos: Desarrollar un
estudio de factibilidad que examine la posibilidad de implantar los requerimientos de
los usuarios. Debe identificar los cursos alternativos de acción para el software,
hardware, servicios y habilidades necesarios, tanto funcionales como técnicos, y
evaluar la factibilidad tecnológica y económica (costo potencial y análisis de
beneficios) de cada uno de los cursos de acción identificados en el contexto de
inversión en TI.

Requerimientos, decisión de factibilidad y aprobación: El patrocinador del requisito
aprueba y autoriza los requisitos del caso, tanto funcionales como técnicos, y los
reportes del estudio de factibilidad en las etapas clave predeterminadas. Cada
autorización va después de la terminación de las revisiones de calidad.
6.2.2.- Adquirir o desarrollar y mantener software aplicativo
Establecer una metodología de ciclo de vida de los sistemas que contemple:
55

Diseño de alto nivel: Traducir los requerimientos a una especificación de diseño de
alto nivel para desarrollo de software, tomando en cuenta las directivas tecnológicas y
la arquitectura de información dentro de la organización, y aprobar el diseño para
garantizar que responde a los requerimientos.

Diseño detallado: Preparar el diseño detallado y los requerimientos técnicos del
software de aplicación. Definir el criterio de aceptación de los requerimientos.
Aprobar los requerimientos para garantizar que corresponden al diseño de alto nivel.
Los conceptos a considerar incluyen, pero no se limitan a, definir y documentar los
requerimientos de entrada de datos, definir interfaces, la interface de usuario, el
diseño para la recopilación de datos fuente, la especificación de programa, definir y
documentar los requerimientos de archivo, requerimientos de procesamiento, definir
los requerimientos de salida, control y auditabilidad, seguridad, disponibilidad, y
pruebas. Realizar una reevaluación para cuando se presenten discrepancias técnicas o
lógicas significativas durante el desarrollo o mantenimiento.

Control y auditabilidad de las aplicaciones: Asegurar que los controles de los procesos
se traduzcan correctamente en controles de aplicación de manera que el
procesamiento sea exacto, completo, oportuno, aprobado y auditable. Los aspectos
que se consideran especialmente son: mecanismos de autorización, integridad de la
información, control de acceso, respaldo y diseño de pistas de auditoría.

Seguridad y disponibilidad de las aplicaciones: Abordar la seguridad de las
aplicaciones y los requerimientos de disponibilidad en respuesta a los riesgos
identificados, de acuerdo con la clasificación de datos, la arquitectura de seguridad en
la información de la organización y el perfil de riesgo. Los asuntos a considerar
incluyen derechos de acceso y administración de privilegios, protección de
información sensible en todas las etapas, autenticación e integridad de las
transacciones y recuperación automática.

Configuración e implantación de software aplicativo adquirido: Personalizar e
implantar la funcionalidad automatizada adquirida con el uso de procedimientos de
configuración, aceptación y prueba. Los aspectos a considerar incluyen la validación
56
contra los términos contractuales, la arquitectura de información de la organización,
las aplicaciones existentes, la interoperabilidad con las aplicaciones existentes y los
sistemas de bases de datos, la eficiencia en el desempeño del sistema, la
documentación y los manuales de usuario, integración y planes de prueba del sistema.

Actualizaciones importantes en sistemas existentes: Seguir un proceso de desarrollo
similar al de desarrollo de sistemas nuevos en el caso que se presenten modificaciones
importantes en los sistemas existentes, que resulten en un cambio significativo de los
diseños y/o funcionalidad actuales. Los aspectos a considerar incluyen análisis de
impacto, justificación, y administración de requerimientos.

Desarrollo de software aplicativo: Garantizar que la funcionalidad de automatización
se desarrolla de acuerdo con las especificaciones de diseño, los estándares de
desarrollo y documentación y los requerimientos de calidad. Aprobar y autorizar cada
etapa clave del proceso de desarrollo de software aplicativo. Los aspectos a considerar
incluyen aprobar las especificaciones de diseño, funcionales y técnicos; aprobar las
solicitudes de cambio; y confirmación de que el software aplicativo es compatible con
la producción y está listo para su migración. Además, garantizar que se identifican y
consideran todos los aspectos legales y contractuales para el software aplicativo que
desarrollan terceros.

Aseguramiento de la Calidad del Software: Desarrollar, implantar los recursos y
ejecutar un plan de aseguramiento de calidad del software, para obtener la calidad que
se especifica en la definición de los requerimientos y en las políticas y procedimientos
de calidad de la organización. Los asuntos a considerar en el plan de aseguramiento
de calidad incluyen especificar el criterio de calidad y los procesos de validación y
verificación, incluyendo inspección, revisión de algoritmos, código fuente y pruebas.

Administración de los requerimientos de aplicaciones: Garantizar que durante el
diseño, desarrollo e implantación, se da seguimiento al estatus de los requerimientos
particulares (incluyendo todos los requerimientos rechazados), y que las
modificaciones a los requerimientos se aprueban a través de un proceso establecido de
administración de cambios.
57

Mantenimiento de software aplicativo: Desarrollar una estrategia y un plan para el
mantenimiento y liberación de aplicaciones de software. Los asuntos a considerar
incluyen liberación planeada y controlada, planeación de recursos, reparación de
defectos de programa y corrección de fallas, pequeñas mejoras, mantenimiento de
documentación, cambios de emergencia, interdependencia con otras aplicaciones e
infraestructura, estrategias de actualización, condiciones contractuales tales como
aspectos de soporte y actualizaciones, revisión periódica, riegos y requerimientos de
seguridad.
6.2.3.- Adquirir y mantener infraestructura tecnológica

Plan de adquisición de infraestructura tecnológica: Generar un plan para adquirir,
implantar y mantener la infraestructura tecnológica que satisfaga los requerimientos
establecidos funcionales y técnicos, y que esté de acuerdo con la dirección
tecnológica de la organización. El plan debe considerar extensiones futuras para
adiciones de capacidad, costos de transición, riesgos tecnológicos y vida útil de la
inversión para actualizaciones de tecnología.

Protección y disponibilidad del recurso de infraestructura: Implantar medidas de
control interno, seguridad y auditabilidad durante la configuración, integración y
mantenimiento del hardware y del software de base para proteger los recursos y
garantizar su disponibilidad e integridad. Se deben definir y comprender claramente
las responsabilidades al utilizar componentes de infraestructura sensitivos por todos
aquellos que desarrollan e integran los componentes de infraestructura. Se debe
monitorear y evaluar su uso.

Mantenimiento de la Infraestructura: Desarrollar una estrategia y un plan de
mantenimiento de la infraestructura y garantizar que se controlan los cambios, de
acuerdo con el procedimiento de administración de cambios de la organización.
Incluir una revisión periódica contra las necesidades de los procesos, administración y
estrategias de actualización, riesgos, evaluación de vulnerabilidades y requerimientos
de seguridad.
58
6.2.4.- Facilitar la operación y el uso

Plan para soluciones de operación: Desarrollar un plan para identificar y documentar
todos los aspectos técnicos, la capacidad de operación y los niveles de servicio
requeridos, de manera que todos los interesados puedan tomar la responsabilidad
oportunamente por la producción de procedimientos de administración, de usuario y
operacionales, como resultado de la introducción o actualización de sistemas
automatizados o de infraestructura.

Transferencia de conocimiento a la gerencia responsable del proceso: Transferir el
conocimiento a los responsables para permitirles tomar posesión del sistema y de los
datos y ejercer la responsabilidad por la entrega y calidad del servicio, del control
interno, y de los procesos de la aplicación. La transferencia de conocimiento incluye
la aprobación de acceso, administración de privilegios, segregación de tareas,
controles automatizados, respaldo/recuperación, seguridad física y archivo de la
documentación fuente.

Transferencia de conocimiento a usuarios finales: Transferir conocimiento y
habilidades para permitir que los usuarios finales utilicen con efectividad y eficiencia
los sistemas. La transferencia de conocimiento incluye el desarrollo de un plan de
entrenamiento que aborde al entrenamiento inicial y al continuo, así como el
desarrollo de habilidades, materiales de entrenamiento, manuales de usuario,
manuales de procedimiento, ayuda en línea, asistencia a usuarios, identificación del
usuario clave y evaluación.

Transferencia de conocimiento al personal de operaciones y soporte: Transferir el
conocimiento y las habilidades para permitir al personal de soporte técnico y de
operaciones que entregue, apoye y mantenga la aplicación y la infraestructura
asociada realice la tarea de manera efectiva y eficiente de acuerdo a los niveles de
servicio requeridos. La transferencia del conocimiento debe incluir al entrenamiento
inicial y continuo, el desarrollo de las habilidades, los materiales de entrenamiento,
los manuales de operación, los manuales de procedimientos y escenarios de atención
al usuario.
59
6.2.5.- Adquirir recursos de TI

Control de adquisición: Desarrollar y seguir un conjunto de procedimientos y
estándares consistente con el proceso general de adquisiciones de la organización y
con la estrategia de adquisición, para garantizar que la adquisición de infraestructura,
instalaciones, hardware, software y servicios relacionados con TI, satisfagan los
requerimientos del Organismo.

Administración de contratos con proveedores: Formular un procedimiento para
establecer, modificar y concluir contratos que apliquen a todos los proveedores. El
procedimiento debe cubrir, al mínimo, responsabilidades y obligaciones legales,
financieras, organizacionales, documentales, de desempeño, de seguridad de
propiedad intelectual, de conclusión y cláusulas de penalización.

Adquisición de software: Reforzar los derechos y obligaciones de todas las partes en
los términos contractuales para la adquisición de software. Estos derechos y
obligaciones pueden incluir la propiedad y licencia de propiedad intelectual,
mantenimiento, garantías, procedimientos de arbitraje, condiciones para la
actualización y aspectos de conveniencia que incluyen seguridad, custodia y derechos
de acceso.

Adquisición de recursos de desarrollo: Incluir y hacer cumplir los derechos y
obligaciones de todas las partes en los términos contractuales para la adquisición de
recursos de desarrollo. Estos derechos y obligaciones pueden incluir la propiedad y
licenciamiento de propiedad intelectual, aspectos de conveniencia incluyendo
metodologías de desarrollo, lenguajes, pruebas, procesos de administración de calidad
que comprenden los criterios de desempeño requeridos, revisión de desempeño,
términos de pago, garantías, procedimientos de arbitraje, administración de recursos
humanos y cumplimiento con las políticas de la organización.

Adquisición de infraestructura, instalaciones y servicios relacionados. Incluir y hacer
cumplir los derechos y obligaciones de todas las partes en los términos contractuales,
que comprendan los criterios de aceptación, para la adquisición de infraestructura,
instalaciones y servicios relacionados. Estos derechos y obligaciones pueden abarcar
60
los niveles de servicio, procedimientos de mantenimiento, controles de acceso,
seguridad, revisión de desempeño y procedimientos de arbitraje.
6.2.6.- Administrar cambios

Establecer procedimientos de administración de cambio formales para manejar de
manera estándar todas las solicitudes (incluyendo mantenimiento y parches) para
cambios a aplicaciones, procedimientos, procesos, parámetros de sistema y servicio, y
las plataformas fundamentales.

Evaluación de impacto, priorización y autorización: Garantizar que todas las
solicitudes de cambio se evalúan de manera estructurada en cuanto a impactos en el
sistema operacional y su funcionalidad. Esta evaluación deberá incluir categorización
y priorización de los cambios. Previo a la migración hacia producción, los interesados
correspondientes deben autorizar los cambios.

Cambios de emergencia: Establecer un proceso para definir, plantear, evaluar y
autorizar los cambios de emergencia que no sigan el proceso de cambio establecido.
La documentación y pruebas se realizan después de la implantación del cambio de
emergencia.

Seguimiento y reporte del estatus de cambio: Establecer un sistema de seguimiento y
reporte para mantener actualizados a los solicitantes de cambio y a los interesados
relevantes, acerca del estatus del cambio a las aplicaciones, a los procedimientos, a los
procesos, parámetros del sistema y del servicio y las plataformas fundamentales.

Cierre y documentación del cambio: Siempre que se implantan cambios al sistema, a
la documentación de usuario o a los procedimientos correspondientes. Establecer un
proceso de revisión para garantizar su implantación completa.
6.2.7.- Instalar y acreditar soluciones y cambios

Entrenamiento: Entrenar al personal de los departamentos de usuario afectados y al
grupo de operaciones de la función de TI de acuerdo con el plan definido de
entrenamiento e implantación y a los materiales asociados, como parte de cada
proyecto de desarrollo, implantación o modificación de sistemas de información.
61

Plan de prueba: Establecer un plan de pruebas y obtener la aprobación de las partes
relevantes. El plan se debe basar en los estándares de toda la organización y definir
roles, responsabilidades y criterios de éxito. El plan debe considerar la preparación de
pruebas (incluye la preparación del sitio), requerimientos de entrenamiento,
instalación o actualización de un ambiente de pruebas definido, planear/ejecutar/
documentar/archivar casos de prueba, manejo y corrección de errores y aprobación
formal. Con base en la evaluación de riesgos de fallas en el sistema y en la
implantación, el plan deberá incluir los requerimientos de prueba de desempeño, de
usabilidad, piloto y de seguridad.

Plan de implantación: Establecer un plan de implantación y obtener la aprobación de
las partes relevantes. El plan define el diseño de versiones, construcción de paquetes
de versiones, procedimientos de implantación/instalación, manejo de incidentes,
controles de distribución (incluye herramientas), almacenamiento de software,
revisión de la versión y documentación de cambios. El plan deberá también incluir
medidas de respaldo/vuelta atrás.

Ambiente de prueba: Establecer un ambiente de prueba separado del de producción.
Este ambiente debe reflejar el ambiente futuro de operaciones (por ejemplo, seguridad
similar, controles internos y cargas de trabajo) para permitir pruebas acertadas. Se
deben tener presentes los procedimientos para garantizar que los datos utilizados en el
ambiente de prueba sean representativos de los datos que se utilizarán eventualmente
en el ambiente de operación. Proporcionar medidas adecuadas para prevenir la
divulgación de datos sensibles. La documentación de los resultados de las pruebas se
debe archivar.

Conversión de sistema y datos: Garantizar que los métodos de desarrollo de la
organización, contemplen para todos los proyectos de desarrollo, implantación o
modificación, que todos los elementos necesarios, tales como hardware, software,
datos de transacciones, archivos maestros, respaldos y archivos, interfaces con otros
sistemas, procedimientos, documentación de sistemas, etc., sean convertidos del viejo
al nuevo sistema de acuerdo con un plan preestablecido. Se desarrolla y mantiene una
62
pista de auditoría de los resultados previos y posteriores a la conversión. Los
propietarios del sistema deben llevar a cabo una verificación detallada del proceso
inicial del nuevo sistema para confirmar una transición exitosa.

Prueba de cambios: Garantizar que se prueban los cambios de acuerdo con el plan de
aceptación definido y en base en una evaluación de impacto y recursos que incluye el
dimensionamiento del desempeño en un ambiente separado de prueba, por parte de un
grupo de prueba independiente (de los constructores) antes de comenzar su uso en el
ambiente de operación regular. Las pruebas paralelas o piloto se consideran parte del
plan. Los controles de seguridad se prueban y evalúan antes de la liberación, de
manera que se pueda certificar la efectividad de la seguridad. Los planes de
respaldo/vuelta atrás se deben desarrollar y probar antes de transferir el cambio a
producción.

Prueba final de aceptación: Garantizar que los procedimientos proporcionan, como
parte de la aceptación final o prueba de aseguramientos de la calidad de los sistemas
de información nuevos o modificados, una evaluación formal y la aprobación de los
resultados de prueba por parte de la gerencia de los departamentos afectados del
usuario y la función de TI. Las pruebas deberán cubrir todos los componentes del
sistema de información (ejemplo, software aplicativo, instalaciones, procedimientos
de tecnología y usuario) y garantizar que los requerimientos de seguridad de la
información se satisfacen para todos los componentes. Los datos de prueba se deben
salvar para propósitos de pistas de auditoría y para pruebas futuras.

Transferencia a producción: Implantar procedimientos formales para controlar la
transferencia del sistema desde el ambiente de desarrollo al de pruebas, de acuerdo
con el plan de implantación. La gerencia debe requerir que se obtenga la autorización
del propietario del sistema antes de que se mueva un nuevo sistema a producción y
que, antes de que se descontinúe el viejo sistema, el nuevo haya operado exitosamente
a través de ciclos de producción diarios, mensuales, trimestrales y de fin de año.

Liberación de software: Garantizar que la liberación del software se regula con
procedimientos formales que aseguren la autorización, acondicionamiento, pruebas de
63
regresión, distribución, transferencia de control, rastreo de estatus, procedimientos de
respaldo y notificación de usuario.

Distribución del sistema: Establecer procedimientos de control para asegurar la
distribución oportuna y correcta, y la actualización de los componentes aprobados de
la configuración. Esto implica controles de integridad; segregación de funciones entre
los que construyen, prueban y operan; y adecuadas pistas de auditoría de todas las
actividades.

Registro y rastreo de cambios: Automatizar el sistema utilizado para monitorear
cambios a sistemas aplicativos para soportar el registro y rastreo de cambios hechos
en aplicaciones, procedimientos, procesos, sistemas y parámetros de servicio, y a las
plataformas subyacentes.

Revisión posterior a la implantación: Establecer procedimientos de acuerdo con los
estándares de desarrollo y de cambios del Organismo, que requieren una revisión
posterior a la implantación del sistema de información en operación para evaluar y
reportar si el cambio satisfizo los requerimientos del usuario y entregó los beneficios
visualizados, de la forma más rentable.
6.3.- Entregar y dar soporte
6.3.1.- Definir y Administrar los Niveles de Servicio

Definir un marco de trabajo que brinde un proceso formal de administración de
niveles de servicio entre el usuario y el prestador de servicio. Este marco debe incluir
procesos para la creación de requerimientos de servicio, definiciones de servicio,
acuerdos de niveles de servicio, acuerdos de niveles de operación y las fuentes de
financiamiento.

Definir la estructura organizacional para la administración del nivel de servicio,
incluyendo los roles, tareas y responsabilidades de los proveedores externos e internos
y de los usuarios.

Organizar y almacenar la definición base de los servicios de TI sobre las
características del servicio y los requerimientos del caso de manera centralizada por
medio de la implantación de un enfoque de catálogo de servicios.
64

Definir y acordar convenios de niveles de servicio para todos los procesos críticos de
TI con base en los requerimientos del usuario y las capacidades en TI. Deben incluir
los compromisos del usuario, los requerimientos de soporte para el servicio, métricas
cualitativas y cuantitativas para la medición del servicio firmado por los interesados,
en caso de aplicar, los arreglos comerciales y de financiamiento, y los roles y
responsabilidades, incluyendo la revisión del acuerdo. Los puntos a considerar son
disponibilidad, confiabilidad, desempeño, capacidad de crecimiento, niveles de
soporte, planeación de continuidad, seguridad y restricciones de demanda.

Asegurar que los acuerdos de niveles de operación expliquen cómo serán entregados
técnicamente los servicios para soportar el (los) acuerdo(s) de nivel de servicio de
manera óptima.

Monitorear continuamente los criterios de desempeño especificados para el nivel de
servicio.

Emitir los reportes sobre el cumplimiento de los niveles de servicio en un formato que
sea entendible para los interesados.

Analizar las estadísticas de monitoreo para identificar tendencias positivas y negativas
tanto de servicios individuales como de los servicios en conjunto.

Revisar regularmente con los proveedores internos y externos los acuerdos de niveles
de servicio y los contratos de apoyo, para asegurar que son efectivos, que están
actualizados y que se han tomado en cuenta los cambios en requerimientos.
6.3.2.- Administrar Servicios de Terceros

Identificar todos los servicios de los proveedores y catalogarlos de acuerdo con el tipo
de proveedor, la importancia y la criticidad.

Mantener documentación formal de las relaciones técnicas y organizacionales
incluyendo los roles y responsabilidades, metas, expectativas, entregables esperados y
credenciales de los representantes de estos proveedores.

Formalizar el proceso de administración de relaciones con proveedores por cada
proveedor.
65

Los responsables de las relaciones deben coordinar a los proveedores y los usuarios y
asegurar la calidad de las relaciones con base en la confianza y la transparencia (por
ejemplo, a través de acuerdos de niveles de servicio).

Identificar y mitigar los riesgos relacionados con la habilidad de los proveedores para
mantener una efectiva entrega de servicios de forma segura y eficiente sobre una base
de continuidad.

Asegurar que los contratos están de acuerdo con los estándares universales del tema y
de conformidad con los requerimientos legales y regulatorios.

Establecer un proceso para monitorear la prestación del servicio para asegurar que el
proveedor está cumpliendo con los requerimientos del ente actuales y que se apega de
manera continua a los acuerdos del contrato y a los convenios de niveles de servicio, y
que el desempeño es competitivo respecto a los proveedores alternativos y a las
condiciones del mercado.
6.3.3.- Administrar el Desempeño y la Capacidad

Establecer un proceso de planeación para la revisión del desempeño y la capacidad de
los recursos de TI, para asegurar la disponibilidad de la capacidad y del desempeño,
con costos justificables, para procesar las cargas de trabajo acordadas tal como se
determina en los acuerdos de nivel de servicio.

Revisar la capacidad y desempeño actual de los recursos de TI en intervalos regulares
para determinar si existe suficiente capacidad y desempeño para prestar los servicios
con base en los niveles de servicio acordados.

Llevar a cabo un pronóstico de desempeño y capacidad de los recursos de TI en
intervalos regulares para minimizar el riesgo de interrupciones del servicio originadas
por falta de capacidad o degradación del desempeño.

Identificar el exceso de capacidad para una posible redistribución.

Identificar las tendencias de las cargas de trabajo y determinar los pronósticos que
serán parte de los planes de capacidad y de desempeño.
66

Brindar la capacidad y desempeño requeridos tomando en cuenta aspectos como
cargas de trabajo normales, contingencias, requerimientos de almacenamiento y ciclos
de vida de los recursos de TI.

La gerencia de TI debe garantizar que los planes de contingencia consideran de forma
apropiada la disponibilidad, capacidad y desempeño de los recursos individuales de
TI.

Monitorear continuamente el desempeño y la capacidad de los recursos de TI.

Mantener y poner a punto el desempeño actual dentro de TI y atender temas como
elasticidad, contingencia, cargas de trabajo actuales y proyectadas, planes de
almacenamiento y adquisición de recursos.

Reportar la disponibilidad hacia el ente del servicio prestado como se requiere en los
acuerdos de nivel de servicio.

Acompañar todos los reportes de excepción con recomendaciones para llevar a cabo
acciones correctivas.
6.3.4.- Garantizar la continuidad del servicio

Desarrollar un marco de trabajo de continuidad de TI para soportar la continuidad de
la misión con un proceso consistente a lo largo de toda la organización. El objetivo
del marco de trabajo es ayudar en la determinación de la resistencia seguridad
requerida de la infraestructura y de guiar el desarrollo de los planes de recuperación
de desastres y de contingencias. El marco de trabajo debe tomar en cuenta la
estructura organizacional para administrar la continuidad, la cobertura de roles, las
tareas y las responsabilidades de los proveedores de servicios internos y externos, su
administración y sus usuarios; así como las reglas y estructuras para documentar,
probar y ejecutar la recuperación de desastres y los planes de contingencia de TI. El
plan debe también considerar puntos tales como la identificación de recursos críticos,
el monitoreo y reporte de la disponibilidad de recursos críticos, el procesamiento
alternativo y los principios de respaldo y recuperación.

Desarrollar planes de continuidad de TI con base en el marco de trabajo, diseñado
para reducir el impacto de una interrupción mayor de las funciones y los procesos
67
clave del ente. Los planes deben considerar requerimientos de resistencia a los
incidentes, procesamiento alternativo, y capacidad de recuperación de todos los
servicios críticos de TI. También deben cubrir los lineamientos de uso, los roles y
responsabilidades, los procedimientos, los procesos de comunicación y el enfoque de
pruebas.

Centrar la atención en los puntos determinados como los más críticos en el plan de
continuidad de TI, para construir resistencia y establecer prioridades en situaciones de
recuperación.

Evitar la distracción de recuperar los puntos menos críticos y asegurarse de que la
respuesta y la recuperación están alineadas con las necesidades prioritarias del
Organismo, asegurándose también que los costos se mantienen a un nivel aceptable y
se cumple con los requerimientos regulatorios y contractuales.

Considerar los requerimientos de resistencia, respuesta y recuperación para diferentes
niveles de prioridad, por ejemplo, de una a cuatro horas, de cuatro a 24 horas, más de
24 horas y para periodos críticos de operación del ente.

La gerencia de TI debe definir y ejecutar procedimientos de control de cambios, para
asegurar que el plan de continuidad de TI se mantenga actualizado y que refleje de
manera continua los requerimientos actuales del Organismo. Es esencial que los
cambios en los procedimientos y las responsabilidades sean comunicados de forma
clara y oportuna.

Probar el plan de continuidad de TI de forma regular para asegurar que los sistemas
de TI pueden ser recuperados de forma efectiva, que las deficiencias son atendidas y
que el plan permanece aplicable. Preparar en forma cuidadosa documentación, reporte
de los resultados de las pruebas y, de acuerdo con los resultados, la implementación
de un plan de acción.

Considerar el alcance de las pruebas de recuperación en aplicaciones individuales, en
escenarios de pruebas integrados, en pruebas de punta a punta y en pruebas integradas
con el o los proveedores que pusiesen estar implicados.
68

Asegurar que todas las partes involucradas reciban sesiones de capacitación de forma
regular respecto a los procesos y sus roles y responsabilidades en caso de incidente o
desastre. Verificar e incrementar el entrenamiento de acuerdo con los resultados de las
pruebas de contingencia.

Determinar que existe una estrategia de distribución definida y administrada para
asegurar que los planes se distribuyan de manera apropiada y segura y que estén
disponibles entre las partes involucradas y autorizadas cuando y donde se requiera. Se
debe prestar atención en hacerlos accesibles bajo cualquier escenario de desastre.

Planear las acciones a tomar durante el período en que TI está recuperando y
reanudando los servicios. Esto puede representar la activación de sitios de respaldo, el
inicio de procesamiento alternativo, la comunicación a usuarios y a los interesados,
realizar procedimientos de reanudación, etc.

Asegurar que los responsables entienden los tiempos de recuperación de TI y las
inversiones necesarias en tecnología para soportar las necesidades de recuperación y
reanudación del servicio.

Almacenar fuera de las instalaciones todos los medios de respaldo, documentación y
otros recursos de TI críticos, necesarios para la recuperación de TI y para los planes
de continuidad.

El contenido de los respaldos a almacenar debe determinarse en conjunto entre los
responsables de los procesos sustantivos y el personal de TI.

La administración del sitio de almacenamiento externo a las instalaciones, debe
apegarse a la política de clasificación de datos y a las prácticas de almacenamiento de
datos de la organización.

La gerencia de TI debe asegurar que los acuerdos con sitios externos sean evaluados
periódicamente, al menos una vez por año, respecto al contenido, a la protección
ambiental y a la seguridad.

Asegurarse de la compatibilidad del hardware y del software para poder recuperar los
datos archivados.

Periódicamente probar y renovar los datos archivados.
69

Una vez lograda una exitosa reanudación de las funciones de TI después de un
desastre, determinar si la gerencia de TI ha establecido procedimientos para valorar lo
adecuado del plan y actualizar el plan en consecuencia.
6.3.5.- Garantizar la Seguridad de los Sistemas

Administrar la seguridad de TI al nivel más apropiado dentro de la organización, de
manera que las acciones de administración de la seguridad estén en línea con los
requerimientos de la organización.

Trasladar los requerimientos de información del ente, la configuración de TI, los
planes de acción del riesgo de la información y la cultura sobre la seguridad en la
información a un plan global de seguridad de TI.

Implementar el plan global de seguridad de TI mediante políticas y procedimientos de
seguridad en conjunto con inversiones apropiadas en servicios, personal, software y
hardware.

Comunicar las políticas y procedimientos de seguridad a los interesados y a los
usuarios.

Todos los usuarios (internos, externos y temporales) y su actividad en sistemas de TI
(aplicación, 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 los procesos del Organismo, definidos y documentados y con
requerimientos de trabajo.

Los derechos de acceso del usuario son solicitados por la gerencia del usuario,
aprobados por el responsable del sistema e implementado por la persona responsable
de la seguridad.

Las identidades del usuario y los derechos de acceso se mantienen en un repositorio
central.

Se implementan y se mantienen actualizadas medidas técnicas y procedimientos
rentables, para establecer la identificación del usuario, realizar la autenticación y
habilitar los derechos de acceso.
70

Garantizar que la solicitud, establecimiento, emisión, suspensión, modificación y
cierre de cuentas de usuario y de los privilegios relacionados, sean tomados en cuenta
por el sector responsable de las cuentas de los usuarios.

Debe incluirse un procedimiento que describa al responsable de los datos o del
sistema para que otorgue los privilegios de acceso. Estos procedimientos deben
aplicar para todos los usuarios, incluyendo administradores (usuarios privilegiados),
usuarios externos e internos, para casos normales y de emergencia.

Los derechos y obligaciones relacionados al acceso a los sistemas e información de la
organización son acordados contractualmente fehacientemente para todos los tipos de
usuarios. La gerencia debe llevar a cabo una revisión regular de todas las cuentas y los
privilegios asociados.

Garantizar que la implementación de la seguridad en TI sea probada y monitoreada de
forma proactiva.

La seguridad en TI debe ser acreditada periódicamente para garantizar que se
mantiene el nivel seguridad aprobado. Una función de ingreso al sistema y de
monitoreo permite la detección oportuna de actividades inusuales o anormales que
pueden requerir atención.

Garantizar que las características de los posibles incidentes de seguridad sean
definidas y comunicadas de forma clara, de manera que los problemas de seguridad
sean atendidos de forma apropiada por medio del proceso de administración de
problemas o incidentes.

Las características incluyen una descripción de lo que se considera un incidente de
seguridad y su nivel de impacto. Un número limitado de niveles de impacto se definen
para cada incidente, se identifican las acciones específicas requeridas y las personas
que necesitan ser notificadas.

Garantizar que la tecnología importante relacionada con la seguridad no sea
susceptible de sabotaje y que la documentación de seguridad no se divulgue de forma
innecesaria.
71

Determinar 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áficas estén implantadas, para garantizar la protección de las
llaves contra modificaciones y divulgación no autorizadas.

Garantizar que se cuente con medidas de prevención, detección y corrección (en
especial contar con parches de seguridad y control de virus actualizados) a lo largo de
toda la organización para proteger a los sistemas de información y a la tecnología
contra software malicioso (virus, gusanos, spyware, correo basura, software
fraudulento desarrollado internamente, etc.).

Garantizar que se utilizan técnicas de seguridad y procedimientos de administración
asociados (por ejemplo, firewalls, dispositivos de seguridad, segmentación de redes, y
detección de intrusos) para autorizar acceso y controlar los flujos de información
desde y hacia las redes.

Garantizar que las transacciones de datos sensibles sean intercambiadas solamente a
través de una ruta o medio confiable con controles para brindar autenticidad de
contenido, prueba de envío y recepción, y no repudio del origen.
6.3.6.- Identificar y Asignar Costos

Identificar todos los costos de TI para soportar un modelo de costos transparente.

Vincular los servicios de TI a los procesos del ente de forma que cada temática pueda
identificar los niveles de costo de los servicios asociados.

Registrar y asignar los costos actuales de acuerdo con el modelo de costos definido.

Analizar y reportar las variaciones entre los presupuestos y los costos actuales de
acuerdo con los sistemas de medición financiera de la organización.

Definir, con base en la característica del servicio, un modelo de costos que incluya
costos directos, indirectos y fijos de los servicios., y que ayude al cálculo de montos
de reintegros por servicio.

Alinear el modelo de costos con los procedimientos de contabilización de costos de la
organización.
72

El modelo de costos de TI debe garantizar que los cargos por servicios son
identificables, medibles y predecibles por parte de los usuarios para propiciar el
adecuado uso de recursos.

La gerencia del usuario debe poder verificar el uso actual y los cargos de los servicios.

Revisar y comparar de forma regular lo apropiado del modelo de costos/recargos para
mantener su relevancia para el tema en evolución y para las actividades de TI.
6.3.7.- Educación y Capacitación de los Usuarios

Establecer y actualizar de forma regular un programa de entrenamiento para cada
grupo objetivo de empleados, que incluya:
o Estrategias y requerimientos actuales y futuros del ente.
o Valores corporativos (valores éticos, cultura de control y seguridad, etc.)
o Implementación de nuevo software e infraestructura de TI (paquetes y
aplicaciones)
o Habilidades, perfiles de competencias y certificaciones actuales y/o
credenciales necesarias.
o Métodos de impartición (por ejemplo, aula, web), tamaño del grupo objetivo,
accesibilidad y tiempo.

Identificar, con base en las necesidades de entrenamiento identificadas: a los grupos
objetivo y a sus miembros, a los mecanismos de impartición eficientes, a maestros,
instructores y consejeros.

Designar instructores y organizar el entrenamiento con tiempo suficiente.

Debe tomarse nota del registro (incluyendo los prerrequisitos), la asistencia, y las
evaluaciones de desempeño.

Al finalizar el entrenamiento, evaluar el contenido del entrenamiento respecto a la
relevancia, calidad, efectividad, percepción y retención del conocimiento, costo y
valor. Los resultados de esta evaluación deben contribuir en la definición futura de los
planes de estudio y de las sesiones de entrenamiento.
73
6.3.8.- Administrar la Mesa de Servicio y los Incidentes

Establecer la función de mesa de servicio, la cual es la conexión del usuario con TI,
para registrar, comunicar, atender y analizar todas las llamadas, incidentes reportados,
requerimientos de servicio y solicitudes de información.

Establecer procedimientos de monitoreo y escalamiento basados en los niveles de
servicio acordados, que permitan clasificar y priorizar cualquier problema reportado
como incidente, solicitud de servicio o solicitud de información.

Medir la satisfacción del usuario final respecto a la calidad de la mesa de servicios y
de los servicios de TI.

Establecer una función y sistema que permita el registro y rastreo de llamadas,
incidentes, solicitudes de servicio y necesidades de información. Debe trabajar
estrechamente con los procesos de administración de incidentes, administración de
problemas, administración de cambios, administración de capacidad y administración
de disponibilidad.

Clasificar los incidentes de acuerdo al tema y a la prioridad del servicio, derivarlo al
equipo de administración de problemas apropiado y mantener informados a los
usuarios sobre el estado de sus consultas.

Establecer procedimientos de mesa de servicios de manera que los incidentes que no
puedan resolverse de forma inmediata sean escalados apropiadamente de acuerdo con
los límites acordados en el acuerdo de nivel de servicios y, si es adecuado, brindar
soluciones alternas.

Garantizar que la asignación de incidentes y el monitoreo del ciclo de vida
permanecen en la mesa de servicios, independientemente de qué grupo de TI esté
trabajando en las actividades de resolución.

Establecer procedimientos para el monitoreo puntual de la resolución de consultas de
los usuarios. Cuando se resuelve el incidente la mesa de servicios debe registrar la
causa raíz, si la conoce, y confirmar que la acción tomada fue acordada con el usuario.

Emitir reportes de la actividad de la mesa de servicios para permitir a la gerencia
medir el desempeño del servicio y los tiempos de respuesta, así como para identificar
74
tendencias de problemas recurrentes de forma que el servicio pueda mejorarse de
forma continua.
6.3.9.- Administrar la Configuración

Establecer una herramienta de soporte y un repositorio central que contenga toda la
información relevante sobre los elementos de configuración.

Monitorear y grabar todos los activos y los cambios a los activos.

Mantener una línea base de los elementos de la configuración para todos los sistemas
y servicios como punto de comprobación al que volver tras el cambio.

Establecer procedimientos de configuración para soportar la gestión y rastro de todos
los cambios al repositorio de configuración.

Revisar periódicamente los datos de configuración para verificar y confirmar la
integridad de la configuración actual e histórica.

Revisar periódicamente si el software instalado está de acuerdo con la política de uso
de software para identificar software personal o no licenciado o cualquier otra
instancia de software en exceso del contrato de licenciamiento actual.

Reportar, actuar y corregir errores y desviaciones.
6.3.10.- Administración de Problemas

Garantizar una adecuada administración de problemas e incidentes

Implementar procesos para reportar y clasificar problemas que han sido identificados
como parte de la administración de incidentes.

Categorizar los problemas de manera apropiada en grupos o dominios relacionados
(por ejemplo, hardware, software, software de soporte). Estos grupos pueden
coincidir con las responsabilidades organizacionales o con la base de usuarios y son
la base para asignar los problemas al personal de soporte.

El sistema de administración de problemas debe mantener pistas de auditoría
adecuadas que permitan rastrear, analizar y determinar la causa raíz de todos los
problemas reportados considerando:
o Todos los elementos de configuración asociados.
o Problemas e incidentes sobresalientes.
75
o Errores conocidos y sospechados.
o Seguimiento de las tendencias de los problemas.

Identificar e iniciar soluciones sostenibles indicando la causa raíz, incrementando las
solicitudes de cambio por medio del proceso de administración de cambios
establecido.

Disponer de un procedimiento para cerrar registros de problemas ya sea después de
confirmar la eliminación exitosa del error conocido o después de acordar con el
responsable del tema cómo manejar el problema de manera alternativa.
6.3.11.- Administración de Datos

Establecer mecanismos para garantizar que el proceso reciba los documentos
originales que espera, que se procese toda la información recibida, que se preparen y
entreguen todos los reportes de salida requeridos y que las necesidades de reinicio y
reproceso estén soportadas.

Definir e implementar procedimientos para el archivo y almacenamiento de los datos,
de manera que los datos permanezcan accesibles y utilizables.

Definir e implementar procedimientos para mantener un inventario de medios de
almacenamiento en sitio y garantizar su integridad y su uso.

Definir e implementar procedimientos para prevenir el acceso a datos sensitivos y al
software desde equipos o medios una vez que son eliminados o transferidos para otro
uso.

Definir e implementar procedimientos de respaldo y restauración de los sistemas,
datos y configuraciones que estén alineados con los requerimientos de la misión y con
el plan de continuidad.

Verificar el cumplimiento de los procedimientos de respaldo y verificar la capacidad y
el tiempo requerido para tener una restauración completa y exitosa.

Probar los medios de respaldo y el proceso de restauración.

Establecer mecanismos para identificar y aplicar requerimientos de seguridad
aplicables a la recepción, procesamiento, almacenamiento físico y entrega de
76
información y de mensajes sensitivos que incluyen registros físicos, transmisiones de
datos y cualquier información almacenada fuera del sitio.
6.3.12.- Administración de Instalaciones

Definir y seleccionar los centros de datos físicos para el equipo de TI para soportar la
estrategia de tecnología ligada a la estrategia del Organismo. Debe tomar en cuenta el
riesgo asociado con desastres naturales y causados por el hombre, considerando las
leyes y regulaciones correspondientes.

Definir e implementar medidas de seguridad físicas alineadas con los requerimientos
del ente.

Establecer las responsabilidades sobre el monitoreo y los procedimientos de reporte y
de resolución de incidentes de seguridad física.

Definir e implementar procedimientos para otorgar, limitar y revocar el acceso a
locales, edificios y áreas de acuerdo con las necesidades del Organismo, incluyendo
las emergencias.

Diseñar e implementar medidas de protección contra factores ambientales. Deben
instalarse dispositivos y equipo especializado para monitorear y controlar el ambiente.

Administrar las instalaciones, incluyendo el equipo de comunicaciones y de
suministro de energía, de acuerdo con las leyes y los reglamentos, los requerimientos
técnicos y del ente, las especificaciones del proveedor y los lineamientos de seguridad
y salud.
6.3.13.- Administración de Operaciones

Definir, implementar y mantener procedimientos estándar para operaciones de TI y
garantizar que el personal de operaciones está familiarizado con todas las tareas de
operación relativas a ellos.

Organizar la programación de trabajos, procesos y tareas en la secuencia más
eficiente, maximizando el desempeño y la utilización para cumplir con los
requerimientos del tema.

Implementar procedimientos para identificar, investigar y aprobar las salidas de los
programas estándar establecidos
77

Definir e implementar procedimientos para monitorear la infraestructura de TI y los
eventos relacionados.

Garantizar que en los registros de operación se almacena suficiente información
cronológica para permitir la reconstrucción, revisión y análisis de las secuencias de
tiempo de las operaciones y de las otras actividades que soportan o que están
alrededor de las operaciones.

Establecer resguardos físicos, prácticas de registro y administración de inventarios
adecuados sobre los activos de TI más sensitivos tales como formularios, impresoras
de uso especial o dispositivos de seguridad.

Definir e implementar procedimientos para garantizar el mantenimiento oportuno de
la infraestructura para reducir la frecuencia y el impacto de las fallas o de la
disminución del desempeño.
6.4.1.- Monitorear y Evaluar el Desempeño de TI

Enfoque del Monitoreo: Establecer un marco de trabajo para el monitoreo general y
un enfoque que definan el alcance, la metodología y el proceso a seguir para medir la
entrega de servicios de TI, y monitorear su contribución al cumplimiento de la misión
del Organismo. Integrar el marco de trabajo con el sistema de administración del
desempeño general.

Definición y Recolección de Datos de Monitoreo: Trabajar con el Organismo para
definir un conjunto balanceado de objetivos de desempeño y tenerlos aprobados por la
conducción y otros interesados relevantes. Definir referencias con las que comparar
los objetivos, e identificar datos disponibles a recolectar para medir los objetivos. Se
deben establecer procesos para recolectar información oportuna y precisa para
reportar el avance contra las metas.

Método de Monitoreo: Garantizar que el proceso de monitoreo instaure un método
que brinde una visión sucinta y desde todos los ángulos del desempeño de TI y que se
adapte al sistema de monitoreo del Organismo.
78

Evaluación del Desempeño: Comparar de forma periódica el desempeño contra las
metas, realizar análisis de la causa raíz e iniciar medidas correctivas para resolver las
causas subyacentes.

Reportes a la conducción del ente: Proporcionar reportes administrativos para ser
revisados por la alta dirección sobre el avance de la organización hacia metas
identificadas, específicamente en términos del desempeño del conjunto de programas
de inversión habilitados por TI, niveles de servicio de programas individuales y la
contribución de TI a ese desempeño. Los reportes de estado deben incluir el grado en
el que se han alcanzado los objetivos planeados, los entregables obtenidos, las metas
de desempeño alcanzadas y los riesgos mitigados. Durante la revisión, se debe
identificar cualquier desviación respecto al desempeño esperado y se deben iniciar y
reportar las medidas de administración adecuadas.

Acciones Correctivas: Identificar e iniciar medidas correctivas basadas en el
monitoreo del desempeño, evaluación y reportes. Esto incluye el seguimiento de todo
el monitoreo, de los reportes y de las evaluaciones con:
o Revisión, negociación y establecimiento de respuestas de administración
o Asignación de responsabilidades por la corrección
o Rastreo de los resultados de las acciones comprometidas.
6.4.2.- Monitorear y Evaluar el Control Interno

Monitoreo del Marco de Trabajo de Control Interno: Monitorear de forma continua,
comparar y mejorar el ambiente de control de TI y el marco de trabajo de control de
TI para satisfacer los objetivos organizacionales.

Monitorear y evaluar la eficiencia y efectividad de los controles internos de revisión
de la administración de TI.

Identificar las excepciones de control, y analizar e identificar en cada caso su causa
raíz subyacente. Escalar las excepciones de control y reportar a los interesados
apropiadamente. Establecer acciones correctivas necesarias.
79

Control de Auto Evaluación: Evaluar la completitud y efectividad de los controles
sobre los procesos, políticas y contratos de TI por medio de un programa continuo de
auto-evaluación.

Aseguramiento del Control Interno: Obtener, según sea necesario, aseguramiento
adicional de la completitud y efectividad de los controles internos por medio de
revisiones de terceros.

Control Interno para Terceros: Evaluar el estado de los controles internos de los
proveedores de servicios externos. Confirmar que los proveedores de servicios
externos cumplen con los requerimientos legales y regulatorios y obligaciones
contractuales.

Acciones Correctivas: Identificar, iniciar, rastrear e implementar acciones correctivas
derivadas de los controles de evaluación y los informes.
6.4.3.- Garantizar el Cumplimiento con Requerimientos Externos

Identificar los Requerimientos de las Leyes, Regulaciones y Cumplimientos
Contractuales: Identificar, sobre una base continua, leyes locales e internacionales,
regulaciones, y otros requerimientos externos que deben cumplirse para incorporarlos
en las políticas, estándares, procedimientos y metodologías de TI de la organización.

Optimizar la Respuesta a Requerimientos Externos: Revisar y ajustar las políticas,
estándares, procedimientos y metodologías de TI para garantizar que los requisitos
legales, regulatorios y contractuales son direccionados y comunicados.

Evaluación del Cumplimiento con Requerimientos Externos: Confirmar el
cumplimiento de políticas, estándares, procedimientos y metodologías de TI con
requerimientos legales y regulatorios.

Aseguramiento Positivo del Cumplimiento: Obtener y reportar garantía de
cumplimiento y adhesión a todas las políticas internas derivadas de directivas internas
o requerimientos legales externos, regulatorios o contractuales, confirmando que se ha
tomado cualquier acción correctiva para resolver cualquier brecha de cumplimiento
por el dueño responsable del proceso de forma oportuna.
80

Reportes Integrados: Integrar los reportes de TI sobre requerimientos legales,
regulatorios y contractuales con las salidas similares provenientes de otras funciones
del Organismo.
6.4.4.- Proporcionar Gobierno de TI

Establecimiento de un Marco de Gobierno de TI: Definir, establecer y alinear el
marco de gobierno de TI con la visión completa del entorno de control y gobierno del
ente. Basar el marco de trabajo en un adecuado proceso de TI y modelo de control y
proporcionar la rendición de cuentas y prácticas inequívocas para evitar una falla en el
control interno y la revisión. Confirmar que el marco de gobierno de TI asegura el
cumplimiento con las leyes y regulaciones y que está alineado con la estrategia y
objetivos organizacionales. Informa del estado y cuestiones de gobierno de TI.

Alineamiento Estratégico: Facilitar el entendimiento del consejo directivo y de los
ejecutivos sobre temas estratégicos de TI tales como el rol de TI, características
propias y capacidades de la tecnología. Garantizar que existe un entendimiento
compartido entre el Organismo y la función de TI sobre su contribución potencial a la
estrategia del ente. Trabajar con el consejo directivo para definir e implementar
organismos de administración, tales como un comité estratégico de TI, para brindar
una orientación estratégica a la gerencia respecto a TI.

Entrega de Valor: Administrar los programas de inversión asignados a TI, así como
otros activos y servicios de TI, para asegurar que ofrezcan el mayor valor posible para
apoyar la estrategia y los objetivos organizacionales.

Administración de Recursos: Revisar inversión, uso y asignación de los activos de TI
por medio de evaluaciones periódicas de las iniciativas y operaciones de TI para
asegurar recursos y alineamiento apropiados con los objetivos estratégicos y los
imperativos actuales y futuros de la misión del ente.

Administración de Riesgos: Trabajar con el consejo directivo para definir el nivel de
riesgo de TI aceptable por el ente y obtener garantía razonable de que las prácticas de
administración de riesgos de TI son apropiadas para asegurar que el riesgo actual de
TI no excede el riesgo aceptable. Introducir las responsabilidades de administración
81
de riesgos en la organización, asegurando que regularmente los responsables del tema
y TI evalúan y reportan los riesgos relacionados con TI y su impacto.

Medición del Desempeño: Confirmar que los objetivos de TI confirmados se han
conseguido o excedido, o que el progreso hacia las metas de TI cumple las
expectativas. Donde los objetivos confirmados no se han alcanzado o el progreso no
es el esperado, revisar las acciones correctivas de gerencia. Informar a la dirección los
casos relevantes, programas y desempeños de TI, soportados por informes para
permitir a la conducción revisar el progreso del ente hacia las metas identificadas.

Aseguramiento Independiente: Garantizar de forma independiente (interna o externa)
la conformidad de TI con la legislación y regulación relevante; las políticas de la
organización, estándares y procedimientos; prácticas generalmente aceptadas; y la
efectividad y eficiencia del desempeño de TI.
7.- Conclusiones
El análisis de los siete requerimientos (eficacia, eficiencia, confidencialidad, integridad,
disponibilidad, cumplimiento y confiabilidad) que debería satisfacer la información provista
por el área de TI, revela (ver Anexo IV) un riesgo superior al recomendable.
El Modelo Genérico de Madurez aplicado en esta auditoría y los niveles de madurez
detectados, representados gráficamente en el Anexo II, indican que los distintos procesos de
la gestión de la tecnología informática en el Banco Central de la República Argentina se
encuentran entre “Inicial (Nivel 1)” y “Medible (Nivel 4)”, con un nivel promedio de 2,2
(sobre una escala del 0 al 5) para los 34 objetivos de control considerados.
Para optimizar el gerenciamiento, se debe mejorar principalmente:

La planificación estratégica

La arquitectura de la información

La administración de calidad

La adquisición y el mantenimiento del software de aplicación

La definición y administración de los niveles de servicio

La identificación y asignación de costos
82

El monitoreo y la evaluación del desempeño
En general y teniendo en cuenta que se trata de una entidad bancaria rectora, debe trabajarse
para que el nivel de madurez promedio para todos los procesos tienda a Administrado y
Medible.
8. - LUGAR Y FECHA
BUENOS AIRES, AGOSTO DE 2012
9. - FIRMA
83
ANEXO I
Niveles del Modelo Genérico de Madurez
0 – No conforma. Falta total de procesos reconocibles. La organización no reconoce que
existe un tema a ser tenido en cuenta.
1 – Inicial. La organización reconoce la existencia del tema y la necesidad de atenderlo. Sin
embargo, no existen procesos estandarizados sino aproximaciones ad hoc que suelen ser
aplicadas sobre una base individual o caso por caso. La administración aparece como
desorganizada.
2 – Repetible. Los procesos han evolucionado hasta la etapa en la cual procedimientos
similares son ejecutados por distintas personas que desarrollan las mismas tareas. No hay
entrenamiento formal ni comunicación de procedimientos estándar y la responsabilidad es
asumida por cada individuo. Hay un alto grado de confianza en el conocimiento de los
individuos y los errores son probables.
3 – Proceso definido. Los procedimientos han sido estandarizados, documentados y
comunicados vía entrenamiento. Sin embargo, es responsabilidad de los individuos cumplir
con estos procesos y es improbable que se detecten las desviaciones. Los procedimientos en
sí mismos no son sofisticados pero son la formalización de prácticas existentes.
4 – Administrado. Es posible monitorear y medir el cumplimiento de los procedimientos y
accionar cuando los procesos parecen no estar trabajando adecuadamente. Los procesos están
bajo mejora constante y proveen una práctica correcta. El uso de herramientas y de
automatización es limitado o fragmentario.
5 – Optimizado. Los procesos han sido corregidos al nivel de la mejor práctica, en base a los
resultados de la mejora continua y de la movilización con otras organizaciones. La TI es
usada de forma integrada para automatizar el flujo de trabajo, proveer herramientas para
mejorar la calidad y la eficacia y hacer que la organización se adapte rápidamente a los
cambios.
84
ANEXO II
Gráficos de brecha para los niveles de madurez de los objetivos de control considerados.
85
86
1 Inicial
2 Repetible
0
1
2
3
4
3 Estandar Aceptable
Nivel de Madurez año 2011
4.1.5 Administrar la Inversión en TI
4.1.4 Definir los Procesos, Organización y Relaciones de T
4.1.3 Determinar la Dirección Tecnológica
4.1.2 Definir la Arquitectura de la Información
4.1.6 Comunicar las Aspiraciones y la Dirección de la
Gerencia
4.1.7 Administrar Recursos Humanos de TI
4.1.8 Administrar la Calidad
4.1.9 Evaluar y Administrar los Riesgos de TI
4.1.10 Administrar Proyectos
4.1.1 Definir un Plan Estratégico de TI
5
Diagrama de Brecha
Planear y Organizar
87
1 Inicial
2 Repetible
4.2.5 Adquirir Recursos de TI
4.2.6 Administrar Cambios
4.2.7 Instalar y Acreditar soluciones y Cambios
4.2.3 Adquirir y Mantener Infraestructura Tecnológica
4.2.2 Adquirir y Mantener Software Aplicativo
"Nivel de Madurez año 2011"
4.2.4 Facilitar la Operación y el Uso
3 Estandar Aceptable
0
1
2
3
4
4.2.1 Identificar Soluciones Automatizadas
5
Diagrama de Brecha
Adquirir e Implementar
88
1 Inicial
2 Repetible
4.3.8 Administrar la Mesa de Servicio y los Incidentes
4.3.9 Administrar la Configuración
4.3.10 Administrar los Problemas
4.3.11 Administrar los Datos
4.3.12 Administrar el Ambiente Físico
4.3.13 Administrar las Operaciones
0
1
2
3
4
3 Estandar Aceptable
Nivel de Madurez año 2011
4.3.7 Educar y Entrenarn a los Usuarios
4.3.6 Identificar y Asignar Costos
4.3.5 Garantizar la Seguridad de los Sistemas
4.3.4 Garantizar la Continuidad del Servicio
4.3.3 Administrar el Desempeño y la Capacidad
4.3.2 Administrar los Servicios de Terceros
4.3.1 Definir y Administrar los Niveles de Servicio
5
Diagrama de Brecha
Entregar y Dar Soporte
89
1 Inicial
2 Repetible
4.4.4 Proporcionar Gobierno de TI
3 Estandar Aceptable
4.4.3 Garantizar el Cumplimiento Regulatorio
0
1
2
3
4
4.4.1 Monitorear y Evaluar el Desempeño de TI
5
Diagrama de Brecha
Monitorear y Evaluar
Nivel de Madurez año 2011
4.4.2 Monitorear y Evaluar el Control Interno
ANEXO III
Estimación de los Niveles de Riesgo para los requerimientos de la información según los
procesos informáticos considerados
Los veloces cambios que caracterizan a la tecnología informática obligan a optimizar la
gestión de los riesgos inherentes. Las misiones y funciones críticas de los organismos
dependen en forma creciente de los sistemas de tecnología de la información, un ambiente
donde también aumentan las noticias sobre fraudes y desastres informáticos. En la actualidad
se entiende que la gestión de riesgos relacionados con la TI es un elemento esencial de la
administración del Estado Nacional.
En esta auditoría se trabajó sobre 34 objetivos de control, cada uno de los cuales se
corresponde con un proceso de tecnología informática.
Cada proceso hace a uno o más de los siguientes requerimientos que debe satisfacer la
información dentro de un organismo para permitirle cumplir con sus misiones y funciones:

Eficacia: Que la información sea relevante y pertinente para la misión del ente, así
como a que su entrega sea oportuna, correcta, consistente y utilizable.

Eficiencia: La provisión de información a través de la utilización óptima (más
productiva y económica) de recursos.

Confidencialidad: La protección de información sensible contra divulgación no
autorizada.

Integridad: La precisión y suficiencia de la información, así como a su validez de
acuerdo con los valores y expectativas del organismo.

Disponibilidad: La disponibilidad de la información cuando ésta es requerida para
cumplir con las misiones del organismo, ahora y en el futuro. También se refiere a la
salvaguarda de los recursos necesarios y capacidades asociadas.
90

Cumplimiento:
Cumplimiento
de
aquellas
leyes,
regulaciones
y
acuerdos
contractuales a los que el organismo está sujeto.

Confiabilidad: La provisión de información apropiada a la administración para operar
la entidad y para ejercer sus responsabilidades de reportes financieros y de
cumplimiento.
En los 34 casos se indica dentro de las observaciones qué requerimientos son afectados en
forma primaria y secundaria por el objetivo de control (ver tabla en página 93).
El objeto de este anexo es brindar parámetros cuantificables que permitan establecer un
Tablero de Control para conocer los problemas con mayor riesgo y al mismo tiempo controlar
las mejoras futuras en forma explícita.
Se entiende como riesgo de un requerimiento a un valor que simboliza la probabilidad de que
la información carezca del mencionado requisito. Este valor fluctúa entre 0 y 1 (0 representa
la situación más segura y 1, la más insegura).
El proceso de cálculo parte de la base de que el riesgo es directamente proporcional al
impacto (definido como el peligro de incumplimiento de las misiones y funciones del
organismo, para los procesos involucrados en el objetivo de control), y a la probabilidad de
ocurrencia del evento.
Para cada uno de los procesos se definió el impacto como alto (99%), medio (66%) o bajo
(33%).
La probabilidad de ocurrencia está directamente vinculada a la calidad del control que se
realiza, y este es evaluado en el informe a través del nivel alcanzado según el modelo de
madurez. A cada nivel se le asignó un coeficiente según el siguiente detalle:
Nivel de Madurez
Coeficiente
No conforma
1,00
Inicial
0,80
Repetible
0,50
Proceso Definido
0,30
91
Administrado
0,20
Optimizado
0,10
92
Monitorear y
Evaluar
Entregar y Dar Soporte
Adquirir e Implementar
S
P
4.1.3 Determinar la Dirección Tecnológica
4.1.4 Definir los Procesos, Organización y
Relaciones de TI
P
P
P
P
4.1.5 Administrar la Inversión en TI
4.1.6 Comunicar las Aspiraciones y la Dirección
de la Gerencia
P
P
4.1.7 Administrar Recursos Humanos de TI
P
S
P
Confiabilidad
4.1.2 Definir la Arquitectura de la Información
Cumplimiento
S
Disponibilidad
P
Integridad
4.1.1 Definir un Plan Estratégico de TI
Confidencialidad
Criterios de Información
Eficiencia
Proceso
Efectividad
Planear y Organizar
Dominio
S
P
S
P
4.1.8 Administrar la Calidad
P
P
4.1.9 Evaluar y Administrar los Riesgos de TI
S
S
S
4.1.10 Administrar Proyectos
P
P
4.2.1 Identificar Soluciones Automatizadas
P
S
4.2.2 Adquirir y Mantener Software Aplicativo
4.2.3 Adquirir y Mantener Infraestructura
Tecnológica
P
P
S
S
P
S
S
S
S
P
P
S
P
S
S
S
4.2.4 Facilitar la Operación y el Uso
P
P
4.2.5 Adquirir Recursos de TI
S
P
4.2.6 Administrar Cambios
P
P
P
P
4.2.7 Instalar y Acreditar soluciones y Cambios
P
S
S
S
4.3.1 Definir y Administrar los Niveles de Servicio
4.3.2 Administrar los Servicios de Terceros
4.3.3 Administrar el Desempeño y la Capacidad
4.3.4 Garantizar la Continuidad del Servicio
4.3.5 Garantizar la Seguridad de los Sistemas
4.3.6 Identificar y Asignar Costos
4.3.7 Educar y Entrenar a los Usuarios
4.3.8 Administrar la Mesa de Servicio y los
Incidentes
4.3.9 Administrar la Configuración
4.3.10 Administrar los Problemas
4.3.11 Administrar los Datos
4.3.12 Administrar el Ambiente Físico
4.3.13 Administrar las Operaciones
P
P
P
P
P
P
P
S
S
S
S
S
S
S
S
S
S
P
S
S
S
P
P
P
S
P
P
P
P
S
P
P
P
4.4.1 Monitorear y Evaluar el Desempeño de TI
P
P
4.4.2 Monitorear y Evaluar el Control Interno
P
P
S
S
P
P
P
P
S
S
S
S
S
P
P
S
P
P
S
S
S
S
S
S
S
S
S
S
S
P
S
S
S
4.4.3 Garantizar el Cumplimiento Regulatorio
4.4.4 Proporcionar Gobierno de TI
S
S
S
S
S
93
ANEXO IV
Gráficos de los niveles de riesgo de cada uno de los requerimientos de la información
para los 34 objetivos de control considerados y su promedio general.
94
0
0,1
0,2
0,3
0,4
0,5
0,6
0,7
0,8
0,9
1
Niveles de Riesgo para la Efectividad
Riesgos Primarios
Riesgos Secundarios
Objetivo de Control
Riesgo Aceptable
4
3
2
1
9
5
7
6
8
2
4
3
1
5
2
7
4
1
6
3
7
9
8
6
3
5
2
4
1
3
2
1
0
0
4.
4.
4.
4.
3.
3.
3.
2.
3.
2.
3.
3.
3.
1.
3.
3.
2.
1.
1.
2.
2.
2.
2.
1.
1.
1.
1.
1.
1.
.1
.1
.1
.1
.1
4.
4.
4.
4.
4.
4. 4.3 4.3 4.3 4.3
4.
4.
4.
4.
4.
4.
4.
4.
4.
4.
4.
4.
4.
4.
4. 4.1
4.
4.
4.
4.
4.
4.
4.
4.
95
0
0,1
0,2
0,3
0,4
0,5
0,6
0,7
0,8
0,9
1
Niveles de Riesgo para la Eficiencia
Riesgos Primarios
Riesgos Secundarios
Objetivo de Control
Riesgo Aceptable
1
3
4
5
7
8
2
6
9
12
13 .4.1 .4.2 .4.3 .4.4
10 .2.1 .2.2 .2.3 .2.4 .2.5 .2.6 .2.7 .3.1 .3.2 .3.3 .3.4 .3.5 .3.6 .3.7 .3.8 .3.9
10
11
1.
1.
1.
1.
1.
1.
1.
1.
1.
3.
3.
1.
3.
3.
4.
4.
4.
4.
4.
4.
4.
4.
4.
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4.
4.
4.
4.
4.
96
Niveles de Riesgo para la Confidencialidad
Riesgo Primario
Riesgo Secundario
Objetivo de Control
Riesgo Aceptable
4
5
0
6
7
2
2
0
5
8
1
2
7
3
3
4
5
1
7
8
9
1
2
3
4
9
3
1
4
6
2
6
1
3
1. 1. 1. 1. 1. 1. 1. 1. 1. .1 2. 2. 2. 2. 2. 2. 2. 3. 3. 3. 3. 3. 3. 3. 3. 3. .1 .1 .1 .1 4. 4. 4. 4.
4. 4. 4. 4. 4. 4. 4. 4. 4. 4.1 4. 4. 4. 4. 4. 4. 4. 4. 4. 4. 4. 4. 4. 4. 4. 4. 4.3 4.3 4.3 4.3 4. 4. 4. 4.
0
0,1
0,2
0,3
0,4
0,5
0,6
0,7
0,8
0,9
1
97
0
0,1
0,2
0,3
0,4
0,5
0,6
0,7
0,8
0,9
1
Niveles de Riesgo para la Integridad
Riesgos Primarios
Riesgos Secundarios
Objetivos de Control
Riesgo Aceptable
4
6
8
3
5
7
9
1
2
13 .4.1 .4.2 .4.3 .4.4
12
10 .2.1 .2.2 .2.3 .2.4 .2.5 .2.6 .2.7 .3.1 .3.2 .3.3 .3.4 .3.5 .3.6 .3.7 .3.8 .3.9
10
11
1.
1.
1.
1.
1.
1.
1.
1.
1.
3.
3.
3.
1.
3.
4
4
4
4
4.
4.
4.
4.
4.
4.
4.
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4.
4.
4.
4.
4.
4.
4.
98
0
0,1
0,2
0,3
0,4
0,5
0,6
0,7
0,8
0,9
1
Nivles de Riesgo para la Disponibilidad
Riesgos Primarios
Riesgos Secundarios
Obejetivo de control
Riesgo Aceptable
6
7
8
1
2
3
9
4
5
13 .4.1 .4.2 .4.3 .4.4
10
10 .2.1 .2.2 .2.3 .2.4 .2.5 .2.6 .2.7 .3.1 .3.2 .3.3 .3.4 .3.5 .3.6 .3.7 .3.8 .3.9
11
12
1.
1.
1.
1.
1.
1.
1.
1.
1.
3.
3.
1.
3.
3.
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4.
4.
4.
4.
4.
4.
4.
4.
4.
4.
4.
4.
4.
4.
99
0
0,1
0,2
0,3
0,4
0,5
0,6
0,7
0,8
0,9
1
Niveles de Riesgo para el cumplimiento
Riesgos Primarios
Riesgos Secundarios
Objetivos de Control
Riesgo Aceptable
8
9
6
4
5
7
1
2
3
10
11
12
10 .2.1 .2.2 .2.3 .2.4 .2.5 .2.6 .2.7 .3.1 .3.2 .3.3 .3.4 .3.5 .3.6 .3.7 .3.8 .3.9
13 .4.1 .4.2 .4.3 .4.4
1.
1.
1.
1.
1.
1.
1.
1.
1.
3.
3.
3.
3.
1.
4
4
4
4
4
4
4
4.
4
4.
4
4.
4
4.
4
4.
4
4
4.
4
4
4.
4
4
4.
4
4
4.
4
4.
4.
4.
4.
4.
100
0
0,1
0,2
0,3
0,4
0,5
0,6
0,7
0,8
0,9
1
1
4.
.1
4.
2
1.
4.
3
1.
101
1
4.
.4
4.
5
1.
.6
1
4.
.7
4.
8
1.
1
4.
.9
1.
4.
10
Riesgos Primarios
1
4.
2
4.
.1
2
4.
.2
4.
3
2.
2
4.
.4
2
4.
.5
6
2.
2
4.
.7
3
4.
.1
4.
2
3.
3
4.
.3
4.
4
3.
Riesgos Secundarios
Objetivo de Control
4.
4.
5
3.
3
4.
Niveles de Riesgo para la Confiabilidad
.6
4.
7
3.
3
4.
.8
Riesgo Aceptable
9
11
12
10
13 .4.1 .4.2 .4.3 .4.4
3.
3.
3.
3.
3.
4.
4
4
4
4
4.
4.
4.
4.
0,00
0,10
0,20
0,30
0,40
0,50
0,60
0,70
0,80
0,90
1,00
102
Efectividad
Eficiencia
Integridad
Disponibilidad
Riesgos Promedio
Riesgo Aceptable
Requerimiento de la información
Confidencialidad
Cumplimiento
Niveles promedio de riesgo para cada atributo de la información
Confiabilidad
ANEXO V
Análisis de la Vista
103
4.1.- Planear y Organizar
4.1.1.- Definir un plan estratégico para TI
Objetivo de control: Se requiere una planeación estratégica de Tecnología de la Información
(TI) para administrar y dirigir todos los recursos de TI de acuerdo con la estrategia y las
prioridades del Organismo. La gerencia informática y los participantes involucrados son
responsables de garantizar que se materialice el valor óptimo de los proyectos y servicios. El
plan estratégico debe mejorar el entendimiento de los interesados clave respecto a las
oportunidades y limitaciones de TI, evaluar el desempeño actual y aclarar el nivel de
inversión requerido. La estrategia y las prioridades se deben reflejar en los proyectos de
inversión y deben ser ejecutadas por los planes tácticos de TI, los cuales establecen objetivos,
planes y tareas específicas, entendidas y aceptadas tanto por ella conducción del Organismo
como por TI.
Este objetivo de control afecta, primariamente:

la efectividad
y en forma secundaria:

la eficiencia
Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo
Nivel de Madurez: Inicial. La Gerencia de TI conoce la necesidad de una planeación
estratégica y la realiza según se necesite como respuesta a un requerimiento específico. La
alineación de los requerimientos de las aplicaciones y la tecnología se lleva a cabo de modo
reactivo en lugar de hacerla por medio de una estrategia organizacional. La posición de riesgo
estratégico se identifica de manera informal proyecto por proyecto.
Observaciones: No existe un plan estratégico de TI. Como resultado de lo expresado, la
estrategia de la dirección tecnológica para adecuarse al alineamiento del ente es reactiva.
Cuestiones tales como evaluar el nivel de inversión requerido, evaluar el desempeño de TI o
establecer prioridades en función de su contribución a los objetivos del Organismo, se ven
limitados por su ausencia.
Al momento de esta auditoría la posición de Subgerente General de Sistemas y Organización
104
se encuentra cubierta transitoriamente por la Subgerente de Administración y Servicios
Centrales.
Aclaraciones y/o comentarios del área responsable:
Con fecha 29-07-2011 bajo la actuación 735/17/2011 fue elevado a consideración del Sr.
Gerente General la actualización del Plan estratégico de la Subgerencia General de
Sistemas y Organización. Dada la aprobación de una nueva Carta Orgánica dicho Plan ha
sido revisado, ajustado y elevado nuevamente a consideración superior (Informe N°
735/04/12 - 06/06/12). El plan trianual 2012-2014 queda a disposición de esa Auditoría.
Comentario de AGN: Al momento de esta auditoría, no existía un Plan Estratégico de TI por
lo tanto se mantiene la observación. La evaluación de la documentación mencionada se
realizará en una próxima auditoría.
4.1.2.- Definir la arquitectura de información
Objetivo de control: La gerencia informática debe crear y actualizar de forma regular un
modelo de información del Organismo y definir los sistemas apropiados para optimizar el uso
de esta información. Esto incluye el desarrollo de un diccionario único de datos que contiene
las reglas de sintaxis de los datos de la organización, el esquema de clasificación de datos y
los niveles de seguridad. Este proceso mejora la calidad de la toma de decisiones gerenciales
asegurándose que se proporciona información confiable y segura, y permite racionalizar los
recursos de los sistemas de información para igualarse con las estrategias del ente. Este
proceso de TI también es necesario para incrementar la responsabilidad sobre la integridad y
seguridad de los datos y para mejorar la efectividad y control de la información compartida a
lo largo de las aplicaciones y de las entidades.
Este objetivo de control afecta, primariamente:

la eficiencia

la integridad
y en forma secundaria:
 la efectividad
 la confidencialidad
105
Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo
Nivel de Madurez: Inicial. La gerencia reconoce la necesidad de una arquitectura de
información. El desarrollo de algunos componentes de una arquitectura de información
ocurre de manera ad hoc. Existe una comunicación esporádica e inconsistente de la necesidad
de una arquitectura de información.
Observaciones: El desarrollo de sistemas estuvo descentralizado en las distintas gerencias.
Actualmente, se ha procedido a la centralización del desarrollo y mantenimiento, aunque los
enfoques para mejorar la integridad, se encuentran demorados.
El Organismo carece de un diccionario de datos, por lo que muchas tablas y entidades básicas
se encuentran replicadas o con información redundante. Se carece de la posición funcional
que lo administre.
Aclaraciones y/o comentarios del área responsable:
La Gerencia de Bases de Datos y Sistemas Operativos del BCRA es el área encargada de
realizar el mantenimiento del Diccionario de Datos de los distintos sistemas informáticos en
servicio, y al momento de realizarse las entrevistas de la AGN el Diccionario de Datos
contemplaba los modelos de datamart de las aplicaciones SIABAN y SICOPRE sobre un
formato básico de hoja de cálculo. Recientemente BCRA ha adquirido la herramienta ER
Studio de Embarcadero Technologies e iniciado la actualización del mencionado
Diccionario de Datos tendiente a incorporar en el mediano plazo a los principales sistemas
de la Institución. Esta herramienta permite la diagramación de estructura de datos y el
manejo de Maestros de Datos, facilitando su consulta a través de un portal web, y en
conjunto con herramientas ETL como Integration Services de Microsoft actualmente
contribuyen a asegurar la integridad de datos del BCRA.
Comentario de AGN: Al momento de esta auditoría, no existía un diccionario de datos de la
organización ni un procedimiento formalizado que obligue a la progresiva constitución del
mismo. Tampoco existe un modelo de datos de la organización. Queda a criterio de cada
unidad de negocio la administración de la información, lo cual es proclive a generar
redundancia de datos. No existe un esquema de clasificación de datos basado en la criticidad
106
y sensibilidad la información. Se mantiene la observación. Las mejoras mencionadas se
evaluarán en una próxima auditoría.
4.1.3.- Determinar la dirección tecnológica
Objetivo de control: La gerencia informática debe determinar la dirección tecnológica para
dar soporte a la misión del Organismo. Esto requiere de la creación de un plan de
infraestructura tecnológica y de un consejo de arquitectura que establezca y administre
posibilidades realistas y claras de lo que la tecnología puede ofrecer en términos de
productos, servicios y mecanismos de aplicación. El plan se debe actualizar de forma regular
y abarca aspectos tales como arquitectura de sistemas, dirección tecnológica, planes de
adquisición, estándares, estrategias de migración y contingencias. Esto permite contar con
respuestas oportunas a cambios en el ambiente, economías de escala para consecución de
personal de sistemas de información e inversiones, así como una interoperabilidad mejorada
de las plataformas y de las aplicaciones.
Este objetivo de control afecta, primariamente:

la efectividad

la eficiencia
Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo
Nivel de Madurez: Repetible. Se difunde la necesidad e importancia de la planeación
tecnológica. La planeación es táctica y se enfoca en generar soluciones técnicas a problemas
técnicos, en lugar de usar la tecnología para satisfacer la misión del ente. La evaluación de los
cambios tecnológicos se delega a individuos que siguen procesos intuitivos, aunque similares.
Las personas obtienen sus habilidades sobre planeación tecnológica a través de un
aprendizaje práctico y de una aplicación repetida de las técnicas. Están surgiendo técnicas y
estándares comunes para el desarrollo de componentes de la infraestructura.
Observaciones: La ausencia de planes estratégicos y tácticos de TI, de un modelo de
arquitectura de la información, del diccionario de datos y de informes de desempeño de la
infraestructura tecnológica, no permite establecer claramente la dirección tecnológica. Se
siguen procesos intuitivos y reactivos basados en un trabajo sobre tendencias del mercado y
107
necesidades de coyuntura, tanto para establecer el mantenimiento de la infraestructura como
su posible crecimiento.
Aclaraciones y/o comentarios del área responsable:
En relación a establecer la dirección tecnológica, la Gerencia de Tecnología no fue
entrevistada por esa Auditoría por lo cual aclaramos que existe un trabajo formalizado por
la misma en informes 701-04-2011 y 701-12-2011, que tiene por objeto plantear elementos
de diseño de todas las infraestructuras y su organización, orientadas a la proyección de las
Tecnologías a implementar en lo sucesivo y establecer una arquitectura consensuada entre
las diferentes Gerencias Principales. Conceptualmente, se plantea en este trabajo el diseño
de Centros de Datos que soporten crecimientos de los servicios con factores acordes a las
expectativas de crecimiento.
Asimismo, es un objetivo el facilitar el despliegue de aplicaciones de clase empresarial, es
decir, Centros de Datos capaces de incorporar sistemas de tipo ERP, CRM, BP M, etc. sin
multiplicar infraestructuras informáticas y de gestión. En concreto, se proponen una serie de
elementos que coadyuven a la escalabilidad y a la disponibilidad y demás elementos de
seguridad por diseño, considerando la importante y creciente necesidad de capacidad de
reacción ante demandas no planeadas, esto último como elemento del contexto real de la
Organización. El trabajo incluye también, como elemento singular, aplicar técnicas de
análisis de riesgo en las fases de diseño.
Por otra parte, independientemente del nivel de planificación natural a toda área de TI. Es
requisito de la Subgerencia General de Sistemas y Organización del BCRA contar con
capacidad reactiva suficiente para atender rápidamente las necesidades propias de la
naturaleza operativa de la institución.
Comentario AGN: Tanto los informes mencionados, como las incorporaciones de sistemas
son posteriores al periodo auditado, por lo tanto serán considerados en una próxima auditoría.
En consecuencia se mantiene la observación.
4.1.4.- Definir los procesos, organización y relaciones de TI
Objetivo de control: Una organización de TI se debe definir tomando en cuenta los
108
requerimientos de personal, funciones, delegación, autoridad, roles, responsabilidades y
supervisión. La organización debiera estar inserta en un marco de trabajo de procesos de TI
que asegure la transparencia y el control, así como el involucramiento de los altos ejecutivos
y de la conducción del ente. Un comité estratégico debe garantizar la vigilancia del consejo
directivo sobre la TI, y uno ó más comités administrativos, en los cuales participan tanto la
dirección como TI, deben determinar las prioridades de los recursos de TI alineados con las
necesidades del Organismo. Deben existir procesos, políticas administrativas y
procedimientos para todas las funciones, con atención específica en el control, el
aseguramiento de la calidad, la administración de riesgos, la seguridad de la información, la
propiedad de datos y de sistemas y la segregación de tareas.
Para garantizar el soporte oportuno de los requerimientos de la misión, TI se debe involucrar
en los procesos importantes de decisión para poder realizar su aporte.
Este objetivo de control afecta, primariamente:
 la efectividad
 la eficiencia
Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo
Nivel de Madurez: Repetible. La función de TI está organizada para responder de forma
táctica aunque inconsistente a las necesidades de los usuarios y a las relaciones con los
proveedores. La necesidad de contar con una organización estructurada y una administración
de proveedores se comunica, pero las decisiones todavía dependen del conocimiento y
habilidades de individuos clave. Surgen técnicas comunes para administrar la organización
de TI y las relaciones con los proveedores.
Observaciones: Existe una organización de TI con funciones, roles, delegaciones y
responsabilidades bien definidos. Sin embargo, varias posiciones se encuentran sin cubrir al
momento de esta auditoría, en particular la del responsable informático cuyas funciones son
cubiertas por la Subgerente de Administración y Servicios Centrales desde hace más de un
año. Existe un marco de trabajo con procesos y procedimientos formalizados para casi todas
las funciones, faltando las políticas que los avalen.
109
La ausencia de un Plan Estratégico y de Políticas de Calidad limita la cohesión de los
equipos de trabajo para un mejor aprovechamiento los recursos de TI en la consecución de
los objetivos.
Aclaraciones y/o comentarios del área responsable:
El Directorio, como órgano de gobierno de la Institución (Art. 15° C. 0.), es quien fija las
políticas y establece a través de la Estructura Orgánica y Funcional, donde se detallan
funciones, roles, delegaciones y responsabilidades inherentes al área la organización de la
Subgerencia General de Sistemas y Organización.
En el punto 4.1.1 se da respuesta a la observación sobre el plan estratégico.
Comentario AGN: La falta de políticas que avalen los procedimientos, la cobertura de la
posición de Subgerente General de Sistemas y Organización por la Subgerente de
Administración y Servicios Centrales y la ausencia de un Plan estratégico, impiden la
definición correcta de los procesos, organización y relaciones de TI. El organismo en su
respuesta no contradice esta observación, en consecuencia se mantiene la misma.
4.1.5.- Administrar la inversión en TI
Objetivo de control: Establecer y mantener un marco de trabajo para administrar los
programas de inversión en TI que abarquen costos, beneficios, prioridades dentro del
presupuesto, un proceso presupuestal formal y administración contra ese presupuesto.
Trabajar con los interesados para identificar y controlar los costos y beneficios totales dentro
del contexto de los planes estratégicos y tácticos de TI, y tomar medidas correctivas según
sean necesarias. El proceso fomenta la sociedad entre TI y la conducción del ente, facilita el
uso efectivo y eficiente de recursos de TI, y brinda transparencia y responsabilidad sobre el
costo total de la inversión, la materialización de los beneficios y el retorno sobre las
inversiones en TI.
Este objetivo de control afecta, primariamente:

la efectividad

la eficiencia
y en forma secundaria:
110

la confiabilidad
Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo
Nivel de Madurez: Repetible. Existe un entendimiento implícito de la necesidad de
seleccionar y presupuestar las inversiones en TI. La necesidad de un proceso de selección y
presupuesto se comunica. El cumplimiento depende de la iniciativa de individuos dentro de
la organización. Surgen técnicas comunes para desarrollar componentes del presupuesto de
TI. Se toman decisiones presupuestales reactivas y tácticas.
Observaciones: Elaboran un Plan Anual de Compras. No existe un marco de administración
financiera que permita establecer prioridades dentro del Presupuesto de los programas de TI,
ni la administración de costos (con sus posibles desviaciones), ni un proceso de monitoreo de
beneficios que permita evaluar la contribución esperada de TI al cumplimiento de la misión
del Organismo.
Aclaraciones y/o comentarios del área responsable:
Existe en Intranet un sitio llamado “Aplicaciones/Presupuesto” donde las áreas del Banco
formulan sus demandas de software y hardware microinformático, que son evaluadas en el
marco de la política institucional, y según se resuelva, se incorporan en el Presupuesto
Anual de la Institución bajo su identificación en distintos proyectos de acuerdo a su
naturaleza y alcance, cuantificando los costos estimados. Sobre este particular el Banco
Central, aplica para elaborar su Presupuesto la técnica “Programa” - “Proyecto”,
cuantificando las actividades que conllevan a nivel de Inciso-Partida-Previsión de acuerdo a
sus estimaciones. Su inicio administrativo, adjudicación y ejecución son reflejados en el
Sistema de Control Presupuestario (SICOPRE) de acuerdo a las etapas cumplidas y al
momento que le es informada a ésta.
Además, a fin de dar cumplimiento a lo instruido por el Directorio, en su Sesión N° 2289 del
27.04.2006, anualmente se confecciona el Plan de Compras que es presentado a esa
instancia para su aprobación y posteriormente, en forma trimestral para su actualización y
seguimiento. Este plan se elabora teniendo en cuenta ciertas pautas metodológicas
establecidas por la Gerencia de Contrataciones.
111
Comentario AGN: De los trabajos de campo realizados no se encontró evidencia de la
existencia de una evaluación de las inversiones en el marco de una política institucional que
defina prioridades, administre costos, ni un proceso de monitoreo posterior. En consecuencia
se mantiene la observación.
4.1.6.- Comunicar las aspiraciones y la dirección de la gerencia
Objetivo de control: La dirección debe elaborar un marco de trabajo de control para TI, y
definir y comunicar las políticas. Un programa de comunicación continua se debe implantar
para articular la misión, los objetivos de servicio, las políticas y procedimientos, etc.,
aprobados y apoyados por la dirección. La comunicación apoya el logro de los objetivos de
TI y asegura la concientización y el entendimiento de los riesgos generales y de TI. El
proceso debe garantizar el cumplimiento de las leyes y reglamentos relevantes.
Este objetivo de control afecta, primariamente:

la efectividad
y en forma secundaria:

el cumplimiento
Nivel de riesgo: [ ] Alto [X] Medio [ ] Bajo
Nivel de Madurez: Repetible. La conducción tiene un entendimiento implícito de las
necesidades y de los requerimientos de un ambiente de control de información efectivo,
aunque las prácticas son en su mayoría informales. La gerencia ha comunicado la necesidad
de políticas, procedimientos y estándares de control, pero la elaboración se delega a la
discreción de gerentes y áreas de trabajo individuales. La calidad se reconoce como una
filosofía deseable a seguir, pero las prácticas se dejan a discreción de agentes individuales.
El entrenamiento se realiza de forma individual, según se requiera.
Observaciones: El aspecto formal de la comunicación se encuentra encuadrado a través de la
Instrucción de Procedimiento 550 aprobada por el Subgerente General de Reingeniería y
Organización con fecha 16/11/2006 mediante Actuación Nro. 222/257/2006.
Sin embargo, la ausencia de un Plan Estratégico de TI y de directrices de administración de
riesgos relativos a TI, imposibilitan comunicar las políticas de TI.
112
Las iniciativas de concientización de riesgos corporativos tales como los temas de Seguridad,
son aisladas y no enmarcadas en una política general del Organismo.
Aclaraciones y/o comentarios del área responsable:
En el punto 4.1.1 se da respuesta a la observación sobre el plan estratégico.
En cuanto a la comunicación de las políticas de TI, se informa que es el Directorio, como
órgano de gobierno de la Institución (Art. 15° C. 0.), quien fija las políticas. Efectivamente y
tal lo expresado por esa Auditoría, la Instrucción de Procedimiento N° 550 “Trámite de
aprobación de Instrucciones de Procedimiento” regula el trámite a seguir para la emisión de
este tipo de norma, se refiera o no a procesos de sistemas y estipula que todo proyecto
normativo propuesto es sometido a análisis y opinión de la Gerencia Principal de
Organización quien elabora un informe dirigido a la Auditoría General solicitando su
opinión sobre su consideración como proyecto definitivo. Con la opinión favorable de las
partes intervinientes, el proyecto es elevado y una vez obtenida su aprobación, es divulgado
mediante informe a las dependencias intervinientes o a través de la emisión de una Circular
Interna pertinente -según sea el caso-, además de su divulgación a través de la intranet
corporativa quedando a disposición de los usuarios en forma permanente.
Cabe aclarar además, que las normas vigentes inherentes a la Subgerencia General de
Sistemas y Organización, resultan de obligatorio conocimiento y cumplimiento por parte de
los integrantes de la Institución.
El detalle de las Instrucciones de Procedimiento, Instructivos Internos, Instructivos Básicos.
Normas de Seguridad queda a disposición de esa Auditoría y es el siguiente:
700- Subgerencia General de Sistemas y Organización

IP 589: Trámite de aprobación de Normas y Estándares de Seguridad Informática
705- Gerencia Principal de Operaciones Informáticas
706- Gerencia de Centros de Procesamiento

IP 555: Atención de Peritos Externos

IP 581: Cheques Rechazados - Recepción y validación de la información remitida en
113
disquetes por las Entidades Financieras

IP 596: Traslado de soportes magnéticos entre Centros de Procesamiento

IP 603: Alta de equipamiento en los Centros de Cómputos - provisión de información
previa a su ingreso

IP 606: Plataformas informáticas del BCRA -Implementación de CambiosNode 1

IB 032: Habilitación de acceso a áreas restringidas a través del Sistema Biométrico

IB 076: Resguardo de bases de datos

IB 098: Presentación de regímenes informativos vía internet

II 706/01: Descripción general del funcionamiento del esquema de Mensajería

NSI7001F: Norma de Seguridad Informática para el Desarrollo y Mantenimiento de
sistemas de Aplicación Críticos
717- Gerencia de Servicios Informáticos

IP 519: Adquisición, asignación e instalación de Bienes Informáticos

IP 621: Adquisición de Bienes Informáticos
715- Gerencia Principal de Infraestructura Informática
718- Gerencia de Comunicaciones y Telefonía

IP 568: Norma de funcionamiento de la Grabadora de Comunicaciones

IP 603: Alta de equipamiento en los Centros de Cómputos - provisión de información
previa a su ingreso

IP 606: Plataformas informáticas del BCRA -Implementación de CambiosNode 1

IP 609: Certificación, liquidación y pago de Bienes y Servicios

IP 620: Desbloqueo de accesos en Agencias Regionales

IB 060: Control de materiales para mantenimiento de redes de datos y telefonía
746- Gerencia de Base de Datos v Sistemas Operativos

IP 571: Modificación de datos de las bases por fuera de las aplicaciones

IP 603: Alta de equipamiento en los Centros de Cómputos - provisión de información
previa a su ingreso

IP 606: Plataformas informáticas del BCRA -Implementación de CambiosNode 1
114

IP 618: Actualización de usuarios y asignación de perfiles

IB 076: Resguardo de bases de datos

NSI7001F: Norma de Seguridad Informática para el Desarrollo y Mantenimiento de
sistemas de Aplicación Críticos

NSI2001A: Norma de Seguridad Informática para la Clasificación de la Información
Sistematizada y de los Activos Informáticos Relacionados
725- Gerencia Principal de Desarrollo de Sistemas
726- Gerencia de Aplicaciones Corporativas

IP 519: Adquisición, asignación e instalación de Bienes Informáticos

IP 571: Modificación de datos de las bases por fuera de las aplicaciones

IP 572: Relevamiento de Expectativas de Mercado (REM)

IP 606: Plataformas informáticas del BCRA -Implementación de CambiosNode 1

IP 617: Informe al Honorable Congreso de la Nación Argentina

IP 621: Adquisición de Bienes Informáticos

NSI7001F: Norma de Seguridad Informática para el Desarrollo y Mantenimiento de
sistemas de Aplicación Críticos

NSI2001A: Norma de Seguridad Informática para la Clasificación de la Información
Sistematizada y de los Activos Informáticos Relacionados
727- Gerencia de Aplicaciones Banca Central

IP 571: Modificación de datos de las bases por fuera de las aplicaciones

IP 606: Plataformas informáticas del BCRA -Implementación de CambiosNode 1

NSI7001F: Norma de Seguridad Informática para el Desarrollo y Mantenimiento de
sistemas de Aplicación Críticos

NSI2001A: Norma de Seguridad Informática para la Clasificación de la Información
Sistematizada y de los Activos Informáticos Relacionados
735- Gerencia Principal de Organización
707- Gerencia de Asistencia Administrativa Informática

IP 519: Adquisición, asignación e instalación de Bienes Informáticos
115

IP 621: Adquisición de Bienes Informáticos

IB 064: Desafectación de equipamiento informático para su donación, venta al
personal o desguace

IB 098: Presentación de regímenes informativos vía internet
736- Gerencia de Normas y Procedimientos

IP 550: Trámite de aprobación de Normas de Procedimiento

IP 593: Trámite para la aprobación de Instructivos Internos

IP 618: Actualización de usuarios y asignación de perfiles

IP 621: Adquisición de Bienes Informáticos

II 736/01: Publicación de Circulares Internas

II 736/02:Divulgación de Instrucciones de Procedimientos

II 736/03: Sistema de Seguimiento de Actuaciones: Recaudos e indicaciones para la
corrección de errores en el SISA

NSI7001F: Norma de Seguridad Informática para el Desarrollo y Mantenimiento de
sistemas de Aplicación Críticos
El detalle de las Circulares Internas es el siguiente (a disposición de esa Auditoría):

Solicitud, Previsión y Provisión
CI 4211: Computadores Personales Portátiles.
CI 4233: Provisión de Bienes con Cargo Personal.
CI 4236: Notebooks. Asignación con Cargo Personal.
CI 4331: Estándar Básico Informático por Puesto Funcional.
CI 4411: Política de Asignación y Uso de Celulares y Telefonía Inteligente.
CI 4621: Previsiones Presupuestarias Lineamientos para formular requerimientos
informáticos
CI 4655: Adquisición de bienes informáticos

Correo Electrónico
CI 3889: Deshabilitación de Tablones de Anuncios de ccmail. Publicación de
116
Circulares Internas en la Intranet de la Institución.
CI 4005: Recomendación para usuarios de correo electrónico (e-mail)
CI 4203: Recomendaciones para prevenir usurpación de datos personales.
CI 4281: Correo Electrónico Institucional.

Internet e Intranet
CI 3570: Procedimiento para la Remisión de Información a Rublicar en Internet.
CI 3577: Accesos a Internet a través de la Conexión Corporativa Contratada.
CI 3643: Elaboración de Textos Ordenados y su Divulgación por Internet.
CI 3889: Deshabilitación de Tablones de Anuncios de ccmail. Publicación de
Circulares Internas en la Intranet de la Institución.
CI 4281: Correo Electrónico Institucional.
CI 4387: Normativa Interna - su Divulgación.

Sistemas: SWIFT/TELEX/STAF/ECyC
CI 3931: Sistemas de Envío de Comunicados y Comunicaciones.
CI 3966: Sistemas de Envío de Comunicados y Comunicaciones (ECyC).
CI 4260: Sistemas de Envío de Comunicados y Comunicaciones.

Telefonía
CI 3400: Puesta en Marcha del Nuevo conmutador Telefónico.
CI 4411: Política de Asignación y Uso de Celulares y Telefonía Inteligente.

Aplicaciones
CI 3143: Computadores Personales. Utilización de Programas - Productos No
Autorizados.
CI 3549: Distribución de Espacios en Servidores de la Red Informática del Banco.
CI 3558: Accesos a la Red, al Host ya sus Aplicaciones.
CI 3683: Computadores Personales. Utilización de Programas - Productos No
Autorizados. Recordatorio de la Circular Interna N° 3143.
CI 3692: Computadores Personales. Utilización de Software Oficial del Banco.
CI 3849: Computadores Personales. Utilización de Software sin su Correspondiente
Licencia de Uso.
117
CI 4073: Registro y Seguimiento de Oficios Judiciales. Implementación de una
Nueva Aplicación.
CI 4135: Implementación del Sistema de Seguimiento de Actuaciones (SISA) en la
SEFyC.
CI 4614: Instrucciones y Recomendaciones de Seguridad Informática
CI 4621: Previsiones Presupuestarias requerimientos informáticos
CI 4638: Actualización de usuarios y asignación de perfiles
CI 4655: Adquisición de bienes informáticos

Base de Datos
CI 3518: Metodología para Requerimientos de Recursos en Bases de Datos.
CI 3712: Normalización de los Nombres de los Servidores de Bases de Datos.
CI 4269: Modificación de Datos de las Bases por Fuera de las Aplicaciones.

Equipamiento
CI 2928: Computadores Personales. Normas Generales.
CI 3090: Incorporación de Elementos Informáticos. Pedidos de Reparación y
Traslado.
CI 3320: Política de Instalación Máquinas Fax.
CI 3545: Egreso de Computadoras Portátiles.
CI 3689: PC's Portátiles. Su Cuidado y Conservación.
CI 4211: Computadores Personales Portátiles.
CI 4233: Provisión de Bienes con Cargo Personal.
CI 4236: Notebooks. Asignación con Cargo Personal.
CI 4331: Estándar Básico Informático por Puesto Funcional.
CI 4505: Provisión de Bienes
CI 4614: Instrucciones y Recomendaciones de Seguridad Informática
CI 4621: Previsiones Presupuestarias - Lineamientos para formular requerimientos
informáticos
CI 4655: Adquisición de bienes informáticos
Con respecto a las directrices de administración de riesgos relativos a sistemas, se informa
118
que se tramita la modificación de estructura de la actual Gerencia Principal de Riesgo, en la
que se formaliza su competencia en la elaboración y actualización de la metodología de
evaluación de riesgos y del Manual de Continuidad de Negocio. Su implementación
conllevará la incorporación de recursos humanos.
Comentario de AGN: A pesar de la cantidad vigente de Instrucciones de Procedimiento,
Instructivos Internos, Instructivos Básicos, Circulares Internas y Normas de Seguridad no se
ha verificado la existencia de un programa de comunicación continua para articular la misión,
los objetivos de servicio, las políticas y los procedimientos. Sumado ello a las debilidades
encontradas en planificación estratégica, administración de riesgos y aseguramiento de la
calidad hace que se mantenga la observación.
4.1.7.- Administrar los recursos humanos de TI
Objetivo de control: Adquirir, mantener y motivar una fuerza de trabajo para la creación y
entrega de servicios de TI para la organización. Esto se logra siguiendo prácticas definidas y
aprobadas que apoyan el reclutamiento, entrenamiento, la evaluación del desempeño y la
promoción. Este proceso es crítico, ya que las personas tienen participación directa en el
ambiente de gobierno y de control interno por lo que éste depende fuertemente de la
motivación y competencia del personal.
Este objetivo de control afecta, primariamente:
 la efectividad
 la eficiencia
Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo
Nivel de Madurez: Repetible. Existe un enfoque táctico para contratar y administrar al
personal de TI, dirigido por necesidades específicas de proyectos, en lugar de hacerlo con
base en un equilibrio entendido de disponibilidad de personal calificado. Se imparte
entrenamiento informal al personal nuevo, quienes después reciben entrenamiento específico,
según sea necesario.
Observaciones: Los procedimientos de reclutamiento del personal de TI están de acuerdo a
las políticas y procedimientos generales de administración de personal de la Organización.
119
Los roles y responsabilidades están bien definidas y el personal tiene las habilidades para
cumplir con éstos, que se miden a través de una evaluación de desempeño que se lleva a cabo
periódicamente.
Se observa falta de personal en funciones claves tales como Desarrollo de Sistemas, Gestión
de Riesgos y Testing, donde para llevar a cabo buenas prácticas metodológicas, precisan una
dotación mayor. Algunas actividades como las relacionadas con la Gestión para el
Aseguramiento de la Calidad no han sido definidas.
El escalafón vigente y la carrera administrativa limitan la incorporación de profesionales del
mercado.
Aclaraciones y/o comentarios del área responsable:
En la actualización del Plan Estratégico elevado se ha indicado que se propenderá a la
resolución de los temas de falta de personal. Con respecto a la Gestión para el
Aseguramiento de la Calidad, se identificarán los procesos cuyo tratamiento se encarará en
una primera etapa.
Comentario de AGN: El organismo acepta las observaciones realizadas por lo tanto se
mantienen las mismas. Las mejoras a realizar se evaluarán en una próxima auditoría.
4.1.8.- Administrar la calidad
Objetivo de control: Se debe elaborar y mantener un sistema de administración de calidad,
el cual incluya procesos y estándares probados de desarrollo y de adquisición. Esto se facilita
por medio de la planeación, implantación y mantenimiento del sistema de administración de
calidad,
proporcionando
requerimientos,
procedimientos
y
políticas
claras.
Los
requerimientos de calidad se deben manifestar y documentar con indicadores cuantificables y
alcanzables. La mejora continua se logra por medio del constante monitoreo, corrección de
desviaciones y la comunicación de los resultados a los interesados. La administración de
calidad es esencial para garantizar que TI está dando valor al ente, mejora continua y
transparencia para los interesados.
Este objetivo de control afecta, primariamente:

la efectividad
120

la eficiencia
y en forma secundaria:

la integridad

la confiabilidad
Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo
Nivel de Madurez: Inicial. Existe conciencia por parte de la dirección de la necesidad de un
Sistema de Administración de la Calidad. La conducción realiza juicios informales sobre la
calidad.
Observaciones: El organigrama del Organismo no contempla una Gerencia o una
Subgerencia General abocada a tal fin. Tampoco existe un Sistema de Administración de la
Calidad.
Aclaraciones y/o comentarios del área responsable:
Con respecto a la calidad, se analizarán los puntos de mayor relevancia en los procesos de
sistemas a efectos de iniciar la definición de controles a incorporar en los mismos,
orientados a mejorar la calidad de los servicios.
Comentario de AGN: El organismo acepta las observaciones realizadas por lo tanto se
mantienen las mismas. Las mejoras a realizar se evaluarán en una próxima auditoría.
4.1.9.- Evaluar y administrar los riesgos de TI
Objetivo de control: Crear y dar mantenimiento a un marco de trabajo de administración de
riesgos. El marco de trabajo documenta un nivel común y acordado de riesgos de TI,
estrategias de mitigación y riesgos residuales acordados. Cualquier impacto potencial sobre
las metas de la organización, causado por algún evento no planeado se debe identificar,
analizar y evaluar. Se deben adoptar estrategias de mitigación de riesgos para minimizar los
riesgos residuales a un nivel aceptable. El resultado de la evaluación debe ser entendible para
los participantes y se debe expresar en términos financieros, para permitir a los participantes
alinear los riesgos a un nivel aceptable de tolerancia.
Este objetivo de control afecta, primariamente:

la confidencialidad
121

la integridad

la disponibilidad
y en forma secundaria:

la efectividad

la eficiencia

el cumplimiento

la confiabilidad
Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo
Nivel de Madurez: Repetible. Existe un enfoque de evaluación de riesgos inmaduro y en
evolución. La administración de riesgos se da por lo general a altos niveles y se aplica de
manera típica solo a proyectos grandes o como respuesta a problemas. Los procesos de
mitigación de riesgos están en implantación donde se identifican riesgos.
Observaciones: Si bien se ha establecido una política de administración de riesgos para toda
la organización, la Gerencia fue creada en mayo del 2009 como recomendación del Acuerdo
de Capital de Basilea II6 Y contó con una dotación reducida hasta mayo del 2011, cuando
fueron incorporados tres recursos nuevos, uno de ellos, especializado en la gestión
informática. Al momento de esta auditoría, este recurso se encuentra actualmente subrogando
la posición ya que no ha sido nombrado formalmente.
Actualmente se encuentran abocados al proceso de identificación de los riesgos y en la
elaboración de una metodología de análisis y gestión de riesgos de los sistemas de
información basadas en la serie 800 del NIST7, (National Institute of Standards and
6
El Comité de Basilea es también conocido como el “Banco Central de los Bancos Centrales” porque está
integrado por representantes de los Bancos Centrales de más de 100 países miembros, entre ellos el Banco
Central de la República Argentina. Debe aclararse que Basilea emite recomendaciones que orientan pero que no
son mandatorias para los bancos centrales de cada país.
7
El Instituto Nacional de Normas y Tecnología (NIST por sus siglas en ingles, National Institute of Standards
aud Technology) es una agencia de la Administración de Tecnología del Departamento de Comercio de los
Estados Unidos. La misión de este instituto es promover la innovación y la competencia industrial en Estados
Unidos mediante avances en metrología, normas y tecnología.
122
Technologya), relacionadas con la seguridad de la información y en la metodología
MAGERIT8.
Debido a la complejidad del ente y la diversidad de los riesgos, se considera que la dotación
del personal está por debajo de lo recomendable.
Aclaraciones y/o comentarios del área responsable:
Se tramita la modificación de la estructura de la actual Gerencia Principal de Riesgo, en la
que se formaliza su competencia en la elaboración y actualización de la metodología de
evaluación de riesgos y del Manual de Continuidad de Negocio. Su implementación
conllevará la incorporación de recursos humanos.
Por otra parte, se completó la versión inicial de la metodología de evaluación de riesgo y se
desarrolló el soporte informático necesario para realizar el relevamiento inicial de las áreas
de la Subgerencia General de Sistemas y Organización. Se está desarrollando un calendario
de entrevistas con los responsables de las diferentes áreas a efectos de presentar la
metodología de análisis y establecer los contactos necesarios para iniciar el relevamiento en
el corto plazo.
Comentario de AGN: El organismo acepta las observaciones realizadas por lo tanto se
mantienen las mismas. Las mejoras a realizar se evaluarán en una próxima auditoría.
4.1.10.- Administrar proyectos:
Objetivo de control: Establecer un programa y un marco de control administrativo de
proyectos para la administración de todos los proyectos de TI. El marco de trabajo debe
garantizar la correcta asignación de prioridades y la coordinación de todos los proyectos. El
Como parte de esta misión, los científicos e ingenieros del NIST continuamente refinan la ciencia de la
medición (metrología) creando una ingeniería precisa y una manufacturación requerida para la mayoría de los
avances tecnológicos actuales. También están directamente involucrados en el desarrollo y pruebas de normas
hechos por el sector privado y agencias de gobierno.
8
Magerit es una metodología de análisis y gestión de riesgos de los Sistemas de Información elaborada por el
Consejo Superior de Administración Electrónica de España para minimizar los riesgos de la implantación y uso
de las Tecnologías de la Información enfocada a las Administraciones Públicas.
123
marco de trabajo debe incluir un plan maestro, asignación de recursos, definición de
entregables, aprobación de los usuarios, un enfoque de entrega por fases, aseguramiento de la
calidad, un plan formal de pruebas, revisión de pruebas y revisión después de la implantación
para garantizar la administración de los riesgos del proyecto y la entrega de valor para
cumplir con los fines del ente. Este enfoque reduce el riesgo de costos inesperados y de
cancelación de proyectos, mejora la comunicación, permite que se involucren los usuarios
finales, asegura el valor y la calidad de los entregables de los proyectos, y maximiza su
contribución a los programas de inversión en TI.
Este objetivo de control afecta, primariamente:

la efectividad

la eficiencia
Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo
Nivel de Madurez: Repetible. La alta dirección ha obtenido y comunicado la conciencia de
la necesidad de la administración de los proyectos de TI. La organización está en proceso de
desarrollar y utilizar algunas técnicas y métodos proyecto por proyecto. Los proyectos de TI
han definido objetivos técnicos y funcionales de manera informal. Hay participación limitada
de los interesados en la administración de los proyectos de TI. Las directrices iniciales se han
elaborado para muchos aspectos de la administración de proyectos. La aplicación a proyectos
de las directrices administrativas se deja a discreción de cada responsable de proyecto.
Observaciones: Todos los requerimientos que ingresan al sector ya sean internos o
provenientes de otras áreas, son asignados y priorizados y generan la especificación
correspondiente. Alguno de estos requerimientos, como producto de un análisis preliminar, y
dependiendo de su envergadura en caso de ser un cambio, genera un Proyecto. El proyecto le
es asignado a un Líder de Proyecto que cuenta con un equipo para administrarlo. Generan
documentación tales como: Cronogramas, Asignación de Recursos, Plan de Proyecto,
Minutas de reunión e Informes de avance.
No existe un aplicativo para administrar proyectos. Se definieron estándares para
documentación. Para generar la documentación se emplean herramientas de oficina de
124
Microsoft: Excel, Project y Word.
La calidad de la documentación en los proyectos varía dependiendo de la importancia de
éstos.
Aclaraciones y/o comentarios del área responsable:
Se propenderá a estandarizar la metodología para administrar los proyectos.
Comentario de AGN: El organismo acepta las observaciones realizadas por lo tanto se
mantienen las mismas. Las mejoras a realizar se evaluarán en una próxima auditoría.
4.2.- Adquirir e implantar
4.2.1.- Identificar soluciones automatizadas
Objetivo de control: La necesidad de una nueva aplicación o función requiere de análisis
antes de la compra o desarrollo para garantizar que los requisitos funcionales se satisfacen
con un enfoque efectivo y eficiente. Este proceso cubre la definición de las necesidades,
considera las fuentes alternativas, realiza una revisión de la factibilidad tecnológica y
económica, ejecuta un análisis de riesgo y de costo-beneficio y concluye con una decisión
final de desarrollar o comprar. Todos estos pasos permiten a las organizaciones minimizar el
costo para adquirir e implantar soluciones, mientras que al mismo tiempo facilitan el logro de
los objetivos del ente.
Este objetivo de control afecta, primariamente:

la efectividad
y en forma secundaria:

la eficiencia
Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo
Nivel de Madurez: Parcialmente Definido. Existen enfoques claros y estructurados para
determinar las soluciones de TI. El enfoque para la determinación de las soluciones de TI
requiere la consideración de alternativas evaluadas contra los requerimientos del las
necesidades funcionales o del usuario, las oportunidades tecnológicas, la factibilidad
económica, las evaluaciones de riesgo y otros factores. El proceso para determinar las
soluciones de TI se aplica para algunos proyectos con base en factores tales como las
125
decisiones tomadas por el personal involucrado, la cantidad de tiempo administrativo
dedicado, y el tamaño y prioridad del requerimiento original. Se usan enfoques estructurados
para definir requerimientos e identificar soluciones de TI.
Observaciones: Los requerimientos se cargan en una aplicación implementada en la Intranet
del Organismo, conocida como “Aplicaciones/Presupuesto”. Con la carga se genera un ticket
con una numeración que permite identificarlos unívocamente. El procedimiento está
formalizado mediante la Circular Interna Nro. 4456 del 16 de junio de 2009. Las etapas de
estudios de factibilidad, análisis de riesgo, definición de alcance y la asignación de un
patrocinador que apruebe y autorice los requisitos funcionales no se encuentran formalizados.
Aclaraciones y/o comentarios del área responsable:
El procedimiento entre la Subgerencia General de Sistemas y Organización y los usuarios
para la compra de soluciones está formalizado por CI N° 4621 Y el proceso que se genera a
partir del requerimiento hasta su inclusión en el presupuesto (incluye factibilidad y
evaluación funcional) se prevé en la Instrucción de Procedimiento N° 621 -Solicitud de
bienes informáticos y confirmación de requerimientos. La CI 4621 y la IP 621 a quedan a
disposición de esa Auditoría.
Comentario AGN: Las circulares mencionadas no fueron entregadas oportunamente pese a
la solicitud realizada. Por lo tanto, no fue factible verificar su contenido ni fu fecha de
formalización. Por otra parte de acuerdo a lo que manifiesta el organismo, ambas están
referidas al proceso de compra de soluciones siendo el propósito de este objetivo de control,
la identificación de nuevas aplicaciones o funciones. Por lo tanto se mantiene la observación.
4.2.2.- Adquirir o desarrollar y mantener software aplicativo
Objetivo de control: Las aplicaciones deben estar disponibles de acuerdo con los
requerimientos del Organismo. Este proceso cubre el diseño de las aplicaciones, la inclusión
apropiada de controles aplicativos y requerimientos de seguridad, y el desarrollo y la
configuración en sí de acuerdo a los estándares. Esto permite a las organizaciones apoyar la
operatividad de forma apropiada con las aplicaciones automatizadas correctas.
Este objetivo de control afecta, primariamente:
126
 la efectividad
 la eficiencia
y en forma secundaria:

la integridad

la confiabilidad
Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo
Nivel de Madurez: Inicial. Existe conciencia de la necesidad de contar con un proceso de
adquisición o desarrollo y mantenimiento de aplicaciones. Los enfoques para la adquisición o
desarrollo y mantenimientos de software aplicativo varían de un proyecto a otro. Es factible
que se adquiriera, en forma independiente, una variedad de soluciones individuales para
requerimientos particulares del ente, teniendo como resultado ineficiencias en el
mantenimiento y soporte. Se tiene poca consideración hacia la seguridad y disponibilidad de
la aplicación en el diseño o adquisición de software aplicativo.
Observaciones: Existe un borrador de una Metodología de Ciclo de Vida de Desarrollo de
Sistemas (CVDS) basada en la metodología “Métrica 3”9 avalado por el Instructivo Interno
9
4.- Métrica 3 es una Metodología de Planificación, Desarrollo y Mantenimiento de Sistemas de lnformación.
Puede ser utilizada libremente con la única restricción de citar la fuente de su propiedad intelectual: el
Ministerio de Administraciones Públicas de España. Este Ministerio, desde el Consejo Superior de Informática,
ofrece así un instrumento para la sistematización de las actividades que dan soporte al ciclo de vida del software
en el desarrollo de Sistemas de Información. Su aplicación pretende los siguientes objetivos:

Proporcionar o definir Sistemas de Información que ayuden a conseguir los fines de la Organización
mediante la definición de un marco estratégico para el desarrollo de los mismos.

Dotar a la Organización de productos software que satisfagan las necesidades de los usuarios dando
una mayor importancia al análisis de requisitos.

Mejorar la productividad de los departamentos de Sistemas y Tecnologías de la Información y las
Comunicaciones permitiendo una mayor capacidad de adaptación a los cambios y teniendo en cuenta la
reutilización en la medida de lo posible.

Facilitar la comunicación y entendimiento entre los distintos participantes en la producción de software
a lo largo del ciclo de vida del proyecto, teniendo en cuenta su papel y responsabilidad, así como las
127
725/00. Al momento de esta auditoría no se encuentra formalizado.
La documentación varía dependiendo del proyecto. Se hace una especificación del alcance
del requerimiento sólo en los casos considerados importantes. No es una documentación
estandarizada. Muchas veces se toma como documentación el intercambio de correos
electrónicos entre las partes o minutas de las distintas reuniones. No siempre se formaliza la
aprobación por parte del usuario. En las entrevistas, se acusó falta de recursos para hacerlo.
Aclaraciones y/o comentarios del área responsable:
Los enfoques para la adquisición o desarrollo y mantenimiento de software aplicativo no
varían de un proyecto a otro.
La adquisición o desarrollo de software, así como su mantenimiento, es responsabilidad de
la Gerencia Principal de Desarrollo de Sistemas. Los requerimientos son considerados
conjuntamente con los proyectos y desarrollos en curso y el plan de adquisición y
mantenimiento de software comercial.
Mediante Circulares Internas N° 4331(2008), 4456 (2009), 4555 (2010) y 4621 (2011) (a
disposición de esa Auditoría), se definió el estándar del software básico y de aplicaciones a
ser instalado en cada unidad operativa de la Institución y se comunicó el procedimiento a
seguir para los requerimientos de adquisición o desarrollo y mantenimiento de software.
Software comercial específico:
Los servicios de mantenimiento se encuentran vigentes y en cuanto a nuevos requerimientos,
el proceso contempla la definición funcional por parte del usuario, y la participación de las
áreas de Tecnología y de Seguridad de la Información, durante la etapa de evaluación del
software y confección de pliego de condiciones. A la fecha, sobre la totalidad de
requerimientos de nuevo software para el período 2012, se ha adquirido el 20%, el 50% se
encuentra en proceso de contratación (publicación y/o evaluación de ofertas), y el 30%
restante en la etapa de confección de pliego.
Gran parte de las condiciones técnicas a incluir en los pliegos, así como las condiciones de
necesidades de todos y cada uno de ellos.

Facilitar la operación, mantenimiento y uso de los productos software obtenidos.
128
soporte y mantenimiento son estándar, basadas en especificaciones fijadas por la ONTI.
Todas las adquisiciones deben ser sometidas a opinión de la ONTl, quien emite Dictamen
sobre sus recomendaciones al respecto.
Desarrollo o mantenimiento de aplicaciones
 Deben ser requeridos por las áreas usuarias especificando (de acuerdo a las CI
nombradas precedentemente):
o Síntesis del requerimiento
o Usuario principal
o Áreas del BCRA afectadas
o Origen de los datos
o Operaciones con los datos (carga/modificación/consulta/análisis/ migraciones)
o Requerimientos de seguridad, acorde a las pautas
 Son evaluados por las Gerencias de Aplicaciones Corporativas o de Aplicaciones de
Banca Central y, en caso de ser factibles, se incorporan al plan de ejecución del área.
 Las nuevas aplicaciones utilizan un único framework que cumple con las pautas de
seguridad informática, diseño gráfico, navegabilidad, trazas de auditoría y mensajes de
error estandarizados.
 Para la implementación de aplicaciones de explotación de datos, se encuentra vigente
una Instrucción de Procedimiento elaborada por la Gerencia Principal de Desarrollo de
Sistemas.
 Para la actualización de sitios web, existe una metodología utilizada por la Gerencia de
Aplicaciones Corporativas.
 Para la implementación de aplicaciones, las áreas de desarrollo generan la
documentación de forma estandarizada, tanto para ambientes de homologación como de
producción, con los requerimientos de configuración, instructivos de instalación,
permisos de acceso a recursos, modelo de datos, etc.
 Todo el proceso de pasaje a testing y producción está basado en la implementación
129
hecha por el área de desarrollo sobre el producto SVN (Subversión)
 Los pliegos orientados a la contratación de servicios de desarrollo, se confeccionan en
base a un modelo estándar que incluye especificaciones respecto al uso de marcos de
trabajo (framework) que resume los aspectos de seguridad informática, diseño gráfico y
navegabilidad.
 La aceptación del área usuaria es realizada en forma previa a su pasaje a producción, y
la obtiene el área de testing. En los casos en que el pasaje a producción deba realizarse
sin intervención de la mencionada área, sea por razones operativas o falta de recursos,
debe ser autorizada por el Gerente Principal de Desarrollo de Sistemas.
 Sobre la implementación de una metodología para la administración del ciclo de vida de
las aplicaciones, la Gerencia Principal de Desarrollo de Sistemas se encuentra
trabajando en la formalización de la misma, basada en Métrica 3, elaborada por el
Ministerio de Administraciones Públicas de España. Actualmente está siendo
complementada con la estandarización de la documentación necesaria para dar soporte
a su implementación:
 Descripción de tareas
 Uso de técnicas
 Pautas sobre imagen institucional
 Componentes de trazabilidad
Seguridad aplicada a los desarrollos y la adquisición de software
Se considera la seguridad y disponibilidad de la aplicación en el diseño o adquisición de
software aplicativo. Los desarrollos y adquisiciones de software consideran específicamente
los aspectos de seguridad (NSI7001 F), tales como:

Esquema único de autenticación y asignación de roles desarrollado con participación
del área de seguridad informática, basado en usuarios del Active Directory, con
directivas de seguridad administradas por el área competente.

Procesos de intercambio de información con entidades financieras y otros organismos,
con encripción y firma basados en certificados digitales emitidos por el área de
130
Seguridad informática, utilizando una red con encriptadores y autenticación bajo Active
Directory administrado por el área de seguridad informática.
 Monitoreo de los sitios web internos y externos en búsqueda de posibles riesgos.

Participación de las áreas de Seguridad de la información y Tecnología en el proceso de
análisis de todo software a incorporar.

Verificación de presencia física del usuario para acceso a aplicaciones.
Comentario AGN: Al momento de esta auditoría, el organismo admite la ausencia de un
procedimiento del Ciclo de vida de Desarrollo de Sistemas en el párrafo “…Sobre la
implementación de una metodología para la administración del ciclo de vida de las
aplicaciones, la Gerencia Principal de Desarrollo de Sistemas se encuentra trabajando en la
formalización de la misma…”.
De la documentación de los sistemas SISA, SEPAIMPO y Sistema de Gestión de
Desempeño, no surge la existencia de una documentación estandarizada.
Las circulares internas 4555 (2010) y 4621 (2011), no fueron recibidas. Se evaluarán en una
próxima auditoría.
En relación a la definición de los requerimientos informáticos de la circular interna 4456, se
observa que las etapas de estudios de factibilidad, análisis de riesgo, definición de alcance y
la asignación de un patrocinador que apruebe y autorice los requisitos funcionales no se
encuentran formalizados.
Se mantiene la observación.
4.2.3.- Adquirir y mantener infraestructura tecnológica
Objetivo de control: Las organizaciones deben contar con procesos para adquirir, implantar
y actualizar la infraestructura tecnológica. Esto requiere de un enfoque planeado para
adquirir, mantener y proteger la infraestructura de acuerdo con las estrategias tecnológicas
convenidas y la disposición del ambiente de desarrollo y pruebas. Esto garantiza que exista
un soporte tecnológico continuo para las aplicaciones del Organismo.
Este objetivo de control afecta, primariamente:

la eficiencia
131
y en forma secundaria:

la efectividad

la integridad

la disponibilidad
Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo
Nivel de Madurez: Repetible. La adquisición y mantenimiento de la infraestructura de TI no
se basa en una estrategia definida formalmente y no considera las necesidades de las
aplicaciones del ente que se deben respaldar. Se tiene la noción de que la infraestructura de
TI es importante, que se apoya en algunas prácticas formales. Para algunos sistemas, existe
un ambiente de prueba por separado.
Observaciones: Si bien se formalizaron los procesos de administración de cambios y existen
estudios de factibilidad de la viabilidad de los mismos así cómo un marco de directrices de
administración de proyectos, no hay un enfoque planeado para adquirir, producto de la
ausencia de planes estratégicos y tácticos de TI. Tampoco existen estándares de adquisición
porque no hay un plan de aseguramiento de la Calidad ni un plan de monitoreo de desempeño
y capacidad.
Aclaraciones y/o comentarios del área responsable:
En el punto 4.1.1 se da respuesta a la observación sobre el plan estratégico.
Con respecto al enfoque planeado para adquirir, la Subgerencia General de Sistemas y
Organización, todos los años, actualiza un Presupuesto Trianual en el que se reflejan los
distintos proyectos de adquisición de bienes y servicios del área, basado en las necesidades
de servicio actuales y previstas del BCRA, bajo estándares formales ETAP de la ONTI y
procesos asociados.
Existe además en Intranet un sitio llamado “Aplicaciones/Presupuesto” y una aprobación y
seguimiento del Plan Anual de Compras por parte del Directorio, tal lo descripto en la
respuesta del punto 4.1.5. “Administrar la inversión en TI”
Por otra parte, con referencia a la separación de ambientes, los distintos sistemas de negocio
del BCRA definidos como de alta criticidad según la norma NSI2001A: Norma de Seguridad
132
Informática para la Clasificación de la Información Sistematizada y de los Activos
Informáticos Relacionado de clasificación de la información, cuentan con ambientes de
desarrollo, homologación y producción, tendientes a asegurar la correcta y oportuna
prestación de cada servicio.
Comentario AGN: No se ha verificado la existencia de un procedimiento formal
planeado para adquirir, mantener y proteger la infraestructura de acuerdo con las estrategias
tecnológicas convenidas y la disposición del ambiente de desarrollo y pruebas.
La necesidad de ambiente de prueba se refiere a poder probar la infraestructura (sistemas
operativos, motores de base de datos, etc.), adquirida o actualizada, en un ambiente separado
del de producción. En consecuencia se mantiene la observación.
4.2.4.- Facilitar la operación y el uso
Objetivo de control: El conocimiento sobre los nuevos sistemas debe estar disponible. Este
proceso requiere la generación de documentación y manuales para usuarios y para TI, y
proporcionar entrenamiento para garantizar el uso y la operación correctos de las aplicaciones
y la infraestructura.
Este objetivo de control afecta, primariamente:

la efectividad

la eficiencia
y en forma secundaria:

la integridad

la disponibilidad

el cumplimiento

la confiabilidad
Nivel de riesgo: [ ] Alto [X] Medio [ ] Bajo
Nivel de Madurez: Definido. Existe un esquema bien definido, aceptado y comprendido para
documentación del usuario, manuales de operación y materiales de entrenamiento. Se
guardan y se mantienen los procedimientos en una biblioteca formal y cualquiera que
necesite saber tiene acceso a ella. Las correcciones a la documentación y a los
133
procedimientos se realizan por reacción. Los procedimientos se encuentran disponibles fuera
de línea y se pueden acceder y mantener en caso de desastre. Existe un proceso que especifica
las actualizaciones de procedimientos y los materiales de entrenamiento para que sea un
entregable explícito de un proyecto de cambio. A pesar de la existencia de enfoques
definidos, el contenido actual varía debido a que no hay un control para reforzar el
cumplimiento de estándares. Los usuarios se involucran en los procesos informalmente. Cada
vez se utilizan más herramientas automatizadas en la generación y distribución de
procedimientos. Se planea y programa tanto el entrenamiento de la misión como de los
usuario.
Observaciones: Existe un marco normativo para la formalización de los procedimientos
basado en la Instrucción de Procedimiento Nro. 550. Su generación es precedida por un
marco de administración de proyectos y el conocimiento tanto de las aplicaciones como del
ente. La documentación se encuentra fácilmente accesible en la Intranet del Organismo.
No se cuenta con un esquema definido para el mantenimiento tanto de los procedimientos
como de los materiales de capacitación y entrenamiento. La documentación no se recopila y
se evalúa a posteriori como parte de un proceso de mejora continua.
Aclaraciones y/o comentarios del área responsable:
Comentario AGN: En ausencia de respuesta por parte del organismo se considera que el
mismo acepta la observación.
4.2.5.- Adquirir recursos de TI
Objetivo de control: Se deben suministrar recursos TI, incluyendo personas, hardware,
software y servicios. Esto requiere de la definición y ejecución de los procedimientos de
adquisición, la selección de proveedores, el ajuste de arreglos contractuales y la adquisición
en sí. El hacerlo así garantiza que la organización tenga todos los recursos de TI que se
requieren de una manera oportuna y rentable.
Este objetivo de control afecta, primariamente:

la eficiencia
134
y en forma secundaria:

la efectividad

el cumplimiento
Nivel de riesgo: [ ] Alto [X] Medio [ ] Bajo
Nivel de Madurez: Definido. La administración establece políticas y procedimientos para la
adquisición de TI. Las políticas y procedimientos toman como guía el proceso general de
adquisición de la organización. La adquisición de TI se integra en gran parte con los sistemas
generales de adquisición del Organismo. Existen estándares para la adquisición de recursos
de TI. Los proveedores de recursos de TI se integran dentro de los mecanismos de
administración de proyectos de la organización desde una perspectiva de administración de
contratos. La administración de TI comunica la necesidad de contar con una administración
adecuada de adquisiciones y contratos en toda la función.
Observaciones: Las adquisiciones se llevan a cabo en el marco de administración de
proyectos y siguiendo el marco normativo de compras del Estado por medio de políticas y
procedimientos formalmente definidos. Los procesos de adquisición son auditables.
La ausencia de un Plan Estratégico lleva a que las decisiones de adquisición sean reactivas a
las necesidades coyunturales. Tampoco existen políticas de calidad que permita establecer
estándares de acuerdos de niveles de servicio que puedan ser monitoreados y revisados a
posteriori para evaluar su desempeño.
Aclaraciones y/o comentarios del área responsable:
Las contrataciones de bienes y servicios de la Subgerencia General de Sistemas y
Organización establecen distintos parámetros de evaluación y cumplimiento de estándares y
grados de servicio requeridos al proveedor, permitiendo a posteriori la evaluación de su
provisión y desempeño con distintas acciones punitorias previstas ante incumplimiento en los
casos que correspondiere.
Comentario AGN: La observación realizada refleja la falta de métricas dentro de
una política global para poder controlar la calidad de los servicios de adquisición de recursos.
Por lo tanto, se mantiene la misma.
135
4.2.6.- Administrar cambios
Objetivo de control: Todos los cambios, incluyendo el mantenimiento de emergencia y
correcciones, relacionados con la infraestructura y las aplicaciones dentro del ambiente de
producción, deben administrarse formalmente y controladamente. Los cambios (incluyendo
procedimientos, procesos, sistema y parámetros del servicio) se deben registrar, evaluar y
autorizar previo a la implantación y revisar contra los resultados planeados después de la
implantación. Esto garantiza la reducción de riesgos que impactan negativamente la
estabilidad o integridad del ambiente de producción.
Este objetivo de control afecta, primariamente:

la efectividad

la eficiencia

la integridad

la disponibilidad
y en forma secundaria:

la confiabilidad
Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo
Nivel de Madurez: Definido. Existe un proceso formal definido para la administración del
cambio, que incluye la categorización, asignación de prioridades, procedimientos de
emergencia, autorización del cambio y administración de liberación, y va surgiendo el
cumplimiento. Se dan soluciones temporales a los problemas y los procesos a menudo se
omiten o se hacen a un lado. Aún pueden ocurrir errores y los cambios no autorizados
ocurren ocasionalmente. El análisis de impacto de los cambios de TI en operaciones de ente
se está volviendo formal, para apoyar la implantación planeada de nuevas aplicaciones y
tecnologías.
Observaciones: La Instrucción de Procedimiento Nro. 606 aprobada por el Sr. Gerente
General con fecha 03/09/2010 mediante Actuación Nro. 736/84/2010 norma la operatoria.
La Gerencia de Base de Datos y Sistemas Operativo s (GBDySO) tiene un aplicativo para
dejar constancia de los cambios solicitados o proyectados, denominado “Registro de
136
Modificaciones”. Si la solicitud del cambio proviene de otra área, ésta es solicitada a la
GBDySO mediante un correo electrónico a una dirección destinada a tal fin.
La GBDySO planifica y coordina las acciones a seguir para la implementación del cambio.
Cuando el cambio pudiera afectar la seguridad de la infraestructura, existe una instancia de
interacción con la Gerencia de Seguridad Informática u otras dependencias técnicas.
Resta establecer un proceso para definir, plantear, evaluar y autorizar cambios de
emergencias que permita el seguimiento y la posterior auditabilidad, enmarcado en un
enfoque sistémico, o sea se debe formalizar un curso de acción tal que cuando se opta por el
procedimiento de emergencia exista una instancia obligatoria de revisión posterior por parte
de un tercero. Si bien existe una Instrucción de Procedimiento Nro. 571 para “Modificación
de datos de las bases por fuera de las aplicaciones”, este procedimiento adolece de la falta de
un monitoreo ex post sobre las acciones emprendidas.
Aclaraciones y/o comentarios del área responsable:
La IP N° 606 detalla: “De presentarse situaciones de emergencia que requieran efectuar un
cambio en forma inmediata, en horarios donde no se encuentra disponible el personal de las
restantes dependencias técnicas y ante la imposibilidad de tomar contacto con los
responsables de las mismas (celular, blackberry, etc.), el Gerente de Base de Datos y
Sistemas Operativos (o en su defecto el Subgerente de la especialidad competente) instruirá
la efectivizacián de la modificación emitiéndose. en forma inmediata, un mensaje de correo
electrónico a la Gerencia de Seguridad Informática y demás dependencias vinculadas con el
tema, por el que se comunicará las acciones llevadas a cabo y el motivo de su ejecución. “
Se analizará la posibilidad de aclarar expresamente que la comunicación detallada implica
el control de lo realizado por parte de todos los involucrados.
La IP 571 detalla: “Si la solicitud de la dependencia responsable de la aplicación amerita
tratamiento urgente a .fin de garantizar la continuidad operativa de la Institución, el
responsable de la unidad orgánica podrá adelantar la solicitud a través de mensaje de
correo electrónico en el que planteará el inconveniente expresando, asimismo, su
compromiso de efectuar la correspondiente formalización del requerimiento a la brevedad.
En el caso de incumplimiento la Gerencia de Infraestructura dará intervención a la
137
Auditoría General mediante informe en el que expondrá la situación planteada.” En relación
a la IP 571 Y respecto al monitoreo ex post de las acciones realizadas, se destaca que la
Gerencia de Seguridad Informática como parte de sus actividades de control, lleva el
registro de las acciones realizadas y efectúa la constatación de las mismas en base a las
acciones informadas vía correo electrónico. Por informe N° 626/86/2012 se solicitó
intervención en el circuito de la IP571 y actualmente está en Gcia. de Normas y
Procedimientos para su formalización.
Comentario AGN: La aclaración realizada en el párrafo “Se analizará la posibilidad
de aclarar expresamente que la comunicación detallada implica el control de lo realizado por
parte de todos los involucrados”, demuestra la inexistencia del control observado. En relación
a la IP 571 “Modificación de datos de las bases por fuera de las aplicaciones”, el organismo
admite que por el informe N° 626/86/2012 se solicitó la incorporación de un monitoreo ex
post por parte de la Gerencia de Seguridad Informática en el procedimiento a la gerencia
correspondiente.
Se mantiene la observación.
4.2.7.- Instalar y acreditar soluciones y cambios
Objetivo de control: Los nuevos sistemas necesitan estar funcionales una vez que su
desarrollo se completa. Esto requiere pruebas adecuadas en un ambiente dedicado con datos
de prueba relevantes, definir la transición e instrucciones de migración, planear la liberación
y la transición en sí al ambiente de producción, y revisar la post-implantación. Esto garantiza
que los sistemas operacionales estén en línea con las expectativas convenidas y con los
resultados.
Este objetivo de control afecta, primariamente:

la efectividad
y en forma secundaria:

la eficiencia

la integridad

la disponibilidad
138
Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo
Nivel de Madurez: Definido. Se cuenta con una metodología formal en relación con la
instalación, migración, conversión y aceptación. Los procesos de TI para instalación y
acreditación están integrados dentro del ciclo de vida del sistema y están automatizados hasta
cierto punto. El entrenamiento, pruebas y transición y acreditación a producción tienen muy
probablemente variaciones respecto al proceso definido, con base en las decisiones
individuales. La calidad de los sistemas que pasan a producción es inconsistente, y los nuevos
sistemas a menudo generan un nivel significativo de problemas posteriores a la implantación.
Observaciones: En el 2007 se creó la Subgerencia de Testing y Calidad. Llevan a cabo las
primeras instancias de pruebas en un entorno independiente de desarrollo y de producción.
La transferencia entre los distintos entornos la llevan a cabo a través de un producto
denominado Subversions10.
Interactúan con el área de Desarrollo en función de los resultados obtenidos de las pruebas.
Este procedimiento se repite tantas veces hasta que se considere la prueba aprobada como
para ser finalmente puesta a disposición del usuario final para su prueba definitiva. En caso
de que éste no dé su conformidad, el software se remite nuevamente a Desarrollo que llevará
a cabo las modificaciones correspondientes. Estas dos instancias de pruebas se repiten tantas
veces hasta que el usuario final da su aceptación. Con el consentimiento explícito de éste, la
subgerencia de Testing y Calidad solicita al sector “Bibliotecas” que pertenece a la Gerencia
Principal de Operaciones Informáticas para que planifique y lleve a cabo el pasaje a
producción.
Los casos de pruebas se documentan con formularios estándar. También capacitan a los
usuarios en el uso de los aplicativos.
En algunas situaciones de emergencia, las aplicaciones no pasan por estas instancias. En
estos casos, el pasaje a producción se autoriza mediante un correo electrónico del Gerente
10
5 Subversion, también conocido por SVN por ser el nombre de la herramienta utilizada en la línea de
comandos, es un software libre. Una característica importante de Subversion es que, los archivos versionados no
tienen cada uno un número de revisión independiente, en cambio, todo el repositorio tiene un único número de
versión que identifica un estado común de todos los archivos del repositorio en un instante determinado.
139
Principal de Desarrollo de Sistemas en acuerdo con la Instrucción de Procedimiento Nro. 571
para “Modificación de datos de las bases por fuera de las aplicaciones” aprobada por el
Subgerente General de Reingeniería y Organización con fecha 20/06/2007, pese a que ésta
normativa no se ajusta a los casos de pasaje a producción en emergencia. Además este
procedimiento adolece de una falta de monitoreo ex post sobre las acciones emprendidas.
Aclaraciones y/o comentarios del área responsable:
Se deja en claro que no existen inconsistencias en los sistemas que pasan al ambiente de
Producción, toda vez que los mismos son sometidos a los procedimientos de prueba definidos
y aprobados por el/los usuario/s correspondientes.
Respecto a los casos de pasaje a producción en situación de emergencia, la Instrucción de
Procedimiento N° 571 indica “Si la solicitud de la dependencia responsable de la aplicación
amerita tratamiento urgente a .fin de garantizar la continuidad operativa de la Institución, el
responsable de la unidad orgánica podrá adelantar la solicitud a través de mensaje de
correo electrónico en el que planteará el inconveniente, expresando. Asimismo, su
compromiso de efectuar la correspondiente formalización del requerimiento a la brevedad.
En el caso de incumplimiento la Gerencia de Infraestructura dará intervención a la
Auditoría General mediante informe en el que expondrá la situación planteada.” - el
monitoreo ex post lo efectuará la Auditoría General.
Respecto de “Implementación de Sistemas en Entorno de Producción “. el procedimiento se
encuentra normado en el proyecto de instructivo interno cuyo trámite se gestiona por
actuación N° 706/10/08. Se considerará la incorporación en el mismo de aspectos
vinculados a los trámites de emergencia.
Queda a disposición de esa auditoría la documentación mencionada.
Comentario AGN: En relación a la IP 571 “Modificación de datos de las bases por fuera de
las aplicaciones”, el organismo admite que por el informe N° 626/86/2012 se solicitó la
incorporación de un monitoreo ex post en el procedimiento a la Gcia de Normas y
Procedimientos.
Se mantiene la observación.
140
4.3. -Entregar y Dar Soporte
4.3.1.- Definir y Administrar los Niveles de Servicio
Objetivo de control: Contar con una definición documentada y un acuerdo de servicios de
TI y de niveles de servicio, hace posible una comunicación efectiva entre la gerencia de TI y
los usuarios respecto de los servicios requeridos. Este proceso también incluye el monitoreo
y la notificación oportuna a los interesados sobre el cumplimiento de los niveles de servicio.
Este proceso permite la alineación entre los servicios de TI y los requerimientos
relacionados.
Este objetivo de control afecta los siguientes requerimientos de la información necesaria para
cumplir las misiones del Organismo, primariamente:

la efectividad

la eficiencia
y en forma secundaria:

la confidencialidad

la integridad

la disponibilidad

el cumplimiento

la confiabilidad
Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo
Nivel de madurez: Inicial Hay conciencia de la necesidad de administrar los niveles de
servicio, pero el proceso es reactivo. La responsabilidad y la rendición de cuentas sobre la
definición y la administración no están definidas. Si existen las medidas para analizar el
desempeño son solamente cualitativas con metas definidas de forma imprecisa. La
presentación de informes es informal, infrecuente e inconsistente.
Observaciones: No existe una definición formal y precisa de servicios, ni hay formalización
de convenios internos que estén alineados con los requerimientos y capacidades de entrega. A
nivel externo solamente están definidos los acuerdos de nivel de servicio con los proveedores
de mantenimiento de hardware y de software. El contrato por el alquiler del espacio físico
141
para la instalación del Sitio Alternativo de Procesamiento (SAP) no tiene definido ningún
tipo de característica técnica que permita definir un acuerdo de niveles de servicio con la
Armada Argentina que es la propietaria del espacio.
Aclaraciones y/o comentarios del área responsable:
Progresivamente se irán formalizando acuerdos de nivel de servicio con los usuarios
internos en las distintas áreas de la Subgerencia General. En lo que respecta al contrato con
la Armada Argentina, en su nueva versión se ha avanzado en la especificación del nivel de
servicios mínimo que dicha Institución debe proveerle a este Banco Central.
Por otra parte, independientemente del nivel de planificación, natural a toda área de
sistemas, cabe aclarar que es requisito de la Subgerencia General de Sistemas y
Organización del BCRA contar con capacidad re activa suficiente para atender rápidamente
las necesidades propias de la naturaleza operativa de la institución.
Comentario AGN: De acuerdo a lo manifestado por el organismo, se mantiene la
observación.
4.3.2.- Administrar Servicios de Terceros
Objetivo de control: La necesidad de asegurar que los servicios provistos por terceros
cumplan con las necesidades del Organismo, requiere de un proceso efectivo de
administración de terceros. Este proceso se logra por medio de 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 efectiva administración
de los servicios de terceros minimiza los riesgos del ente asociados con proveedores que no
se desempeñan de forma adecuada.
Este objetivo de control afecta los siguientes requerimientos de la información necesaria para
cumplir las misiones del Organismo, primariamente:

la efectividad

la eficiencia
y en forma secundaria:

la confidencialidad
142

la integridad

la disponibilidad

el cumplimiento

la confiabilidad
Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo
Nivel de madurez: Definido. Existen procedimientos bien documentados para controlar los
servicios de terceros con procesos claros para tratar y negociar con los proveedores. Cuando
se hace un acuerdo de prestación de servicios la relación con el tercero es meramente
contractual. La naturaleza de los servicios a prestar se detalla en el contrato e incluye
requerimientos legales, operativo s y de control. Se asigna la responsabilidad de supervisar
los servicios de terceros. Los términos contractuales se basan en formatos estandarizados. El
riesgo asociado con los servicios del tercero está valorado y reportado.
Observaciones: Los contratos de compras a terceros se encuentran formalizados. Dentro de
los contratos se incluyen acuerdos de confidencialidad, garantías, penalizaciones por
incumplimiento. Si bien en la mayoría de los contratos analizados se encuentran
mínimamente definido un acuerdo de nivel de servicio, esto no ocurre con el Convenio
Especifico ARA-BCRA - 1-1 en el cual no se incluye ningún tipo de cláusula que especifique
en forma clara y precisa las condiciones físicas y técnicas de las instalaciones a proveer por la
Armada Argentina para el procesamiento alternativo de emergencia.
Aclaraciones y/o comentarios del área responsable:
En línea con lo informado en el punto anterior, la nueva versión del contrato con la Armada
Argentina relativo al alquiler de las instalaciones para el centro de cómputos, incorpora un
conjunto de prestaciones a ser cumplidas y tiempos en los que deben ser suministradas al
BCRA.
Comentario AGN: De acuerdo lo manifestado por el organismo, se mantiene la observación.
4.3.3.- Administrar el Desempeño y la Capacidad
Objetivo de control: La necesidad de administrar el desempeño y la capacidad de los
recursos de TI requiere de un proceso para revisar periódicamente el desempeño actual y la
143
capacidad de los recursos de TI. Este proceso incluye el pronóstico de las necesidades
futuras, basadas en los requerimientos de carga de trabajo, almacenamiento y contingencias y
brinda la seguridad de que los recursos de información que soportan los requerimientos del
Organismo están disponibles de manera continua.
Este objetivo de control afecta los siguientes requerimientos de la información necesaria para
cumplir las misiones del Organismo, primariamente:

la efectividad

la eficiencia
y en forma secundaria:

la disponibilidad
Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo
Nivel de madurez: Repetible. Los responsables del tema y la gerencia de TI están
conscientes del impacto de no administrar el desempeño y la capacidad. Las necesidades de
desempeño se logran por lo general con base en evaluaciones de sistemas individuales y el
conocimiento y soporte de equipos de proyecto. Algunas herramientas individuales pueden
utilizarse para diagnosticar problemas de desempeño y de capacidad, pero la consistencia de
los resultados depende de la experiencia de individuos clave. No hay una evaluación general
de la capacidad de desempeño de TI o consideración sobre situaciones de carga pico y peor
escenario. Los problemas de disponibilidad son susceptibles de ocurrir de manera inesperada
y aleatoria. Cualquier medición de desempeño se basa primordialmente en las necesidades de
TI y no en las necesidades del usuario.
Observaciones: Según la información disponible no existen políticas y procedimientos
formales para la planificación de la capacidad. Se dispone de herramientas de monitoreo y
control como Nagios, HP Open View, Omnivista que dan alarmas ante distintas situaciones
pero no se lleva un registro de estos eventos, ni se realizan estadísticas que indiquen
tendencias para prever crecimiento a futuro.
Aclaraciones y/o comentarios del área responsable:
La disponibilidad de los distintos sistemas informáticos de negocio del BCRA es monitoreada
144
en forma permanente, así como distintos parámetros de capacidad y desempeño del
equipamiento que los soportan, que son considerados a la hora del diseño de soluciones de
reemplazo o ampliación de capacidad de los sistemas en servicio.
Asimismo, corresponde señalar que existen estadísticas sobre incidentes y eventos.
Se encuentra en elaboración una política formal de administración del desempeño y la
capacidad de servidores, en relación con el proceso de adquisición de equipamiento
informático necesario.
Comentario AGN: De acuerdo a lo manifestado por el organismo, se mantiene la
observación.
4.3.4.- Garantizar la continuidad del servicio
Objetivo de control: La necesidad de brindar continuidad en los servicios de TI requiere
desarrollar, mantener y probar planes al respecto, almacenar respaldos fuera de las
instalaciones y entrenamiento periódico. Un proceso efectivo de continuidad de servicios,
minimiza la probabilidad y el impacto de las interrupciones mayores sobre funciones y
procesos claves.
Este objetivo de control afecta los siguientes requerimientos de la información necesaria para
cumplir las misiones del Organismo, primariamente:

la efectividad

la disponibilidad
y en forma secundaria:

la eficiencia
Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo
Nivel de madurez: Definido. La responsabilidad sobre la administración de la continuidad
del servicio es clara. Las responsabilidades de la planeación y de las pruebas de la
continuidad de los servicios están claramente asignadas y definidas. El plan de continuidad de
TI está documentado y basado en la criticidad de los sistemas y el impacto a las operaciones.
Hay reportes periódicos de las pruebas de continuidad. Los individuos toman la iniciativa
para seguir estándares y recibir capacitación para enfrentarse con incidentes mayores o
145
desastres. La gerencia comunica de forma regular la necesidad de planear el aseguramiento
de la continuidad del servicio. Se han aplicado componentes de alta disponibilidad y
redundancia. Se mantiene un inventario de sistemas y componentes críticos.
Observaciones: Existe y se encuentra formalizado un plan de continuidad del servicio. El
BCRA dispone de un Sitio Alternativo de Procesamiento, ubicado en el centro de cómputos
de la Armada Argentina, vinculado al centro de procesamiento principal mediante dos fibras
ópticas provistas por una empresa externa de telecomunicaciones
El plan de contingencia es manejado por la Gerencia Principal de Operaciones Informáticas.
Esta gerencia se ocupa además de manejar los robots que realizan las tareas de backup según
los procedimientos indicados por las Subgerencia de Administración de Bases de Datos y la
Subgerencia de Administración de Sistemas Operativos. La frecuencia de las tareas de
backup depende de las aplicaciones, de las bases de datos se realizan:

Diario full.

Semanal full.

Mensual full (se guarda por 10 años).
Además se registran y almacenan los registros de operación de los servidores críticos cada 15
minutos.
Se realizan pruebas parciales de los procedimientos de contingencia en forma periódica, la
última se realizó el 20 noviembre de 2010 que por ser un día sábado, en el que el sistema
bancario no funciona, no pudo incluir todos los procedimientos.
Aclaraciones y/o comentarios del área responsable:
A partir del año 2011, las pruebas del Plan de Contingencia Informática y Operación
Crítica, se desarrollan durante días hábiles bancarios en forma totalmente transparente para
los usuarios. Así sucedió con la prueba realizada el día 8 de julio de 2011, y se repitió según
se encuentra previsto el 15 de junio del presente año de manera exitosa.
Comentario AGN: Las pruebas mencionadas se realizaron fuera del periodo auditado, en
consecuencia se mantiene la observación, y las mejoras mencionadas se evaluaran en una
próxima auditoría.
146
4.3.5.- Garantizar la Seguridad de los Sistemas
Objetivo de control: La necesidad de mantener la integridad de la información y de proteger
los activos de TI, requiere de un proceso de administración de la seguridad. Este proceso
incluye el establecimiento y mantenimiento de roles y responsabilidades, políticas, estándares
y procedimientos de TI. La administración de la seguridad también incluye realizar
monitoreos y pruebas periódicas así como acciones correctivas sobre las debilidades o
incidentes de identificados. Una efectiva administración de la seguridad protege todos los
activos de TI para minimizar el impacto causado por vulnerabilidades o incidentes de
seguridad
Este objetivo de control afecta los siguientes requerimientos de la información necesaria para
cumplir las misiones del Organismo, primariamente:

la confidencialidad

la integridad
y en forma secundaria:

la disponibilidad

el cumplimiento

la confiabilidad
Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo
Nivel de madurez: Definido. Existe conciencia sobre la seguridad y ésta es promovida por la
gerencia. Los procedimientos están definidos y alineados con las políticas de seguridad de TI.
Las responsabilidades están asignadas, formalizadas, entendidas e implementadas. Existe un
plan de seguridad de TI formalmente definido. Se realizan pruebas adecuadas. Existe
capacitación en seguridad para TI y para el ente.
Observaciones: La Gerencia Principal de Seguridad de la Información es la responsable de
formular pautas, normas y estándares respecto de la seguridad información que se encuentra
en los sistemas del BCRA para garantizar su protección en los procesos de acceso,
procesamiento y transmisión. Elaboran normas tanto para el Organismo como para entidades
financieras. Dentro de la estructura de la Gerencia, se encuentra la Subgerencia de Normas de
147
Seguridad en Entidades que se dedica a la confección de normas para los bancos y entidades
del sistema financiero.
La Política de Seguridad de la Información está aprobada por el directorio del Banco. Se
formó un Comité de Seguridad de la Información presidido por un Director del Banco e
integrado por el Gerente General, Gerente de Seguridad Física y el Gerente de Seguridad de
la Información, entre otros. Existe un procedimiento formal para la aprobación de las normas
de seguridad.
La normativa sobre seguridad de la información está formalmente aprobada.
La defensa externa está compuesta por una estructura estándar, satisfactoria, que brinda
protección hacia el exterior
El BCRA está conectado con los bancos y entidades financieras por medio de una red privada
con líneas punto a punto entre el Organismo y cada una de las entidades. En ambos extremos
hay un encriptador provisto por el BCRA. Estas líneas están conectadas a un equipo
concentrador que es administrado por el banco, lo mismo que los certificados digitales de
estas conexiones.
No existe un procedimiento por el cual Recursos Humanos informe a Seguridad Informática
sobre licencias y ausencias para que esta última suspenda la posibilidad de acceso al sistema
de un empleado que se encuentre en tal situación.
El sistema de autenticación se encuentra sincronizado con el de control de accesos de forma
tal que solo puedan acceder al uso de los recursos de TI, a aquellos empleados que hayan
registrado su ingreso.
Para el control de la navegación de Internet, se dispone de un producto de filtrado de páginas
Web (IWSS).
Aclaraciones y/o comentarios del área responsable:
Se toma conocimiento de los comentarios. Cabe destacar que en relación a la información
sobre las licencias del personal, que debe proveer el área de Recursos Humanos, se
implementó la IP 618 por el cual mensualmente el área mencionada informa, entre otras, a
la Gerencia Principal de Seguridad de la Información el estado de situación del personal a
cierta fecha.
148
A partir del mes 04/2011 el sistema de autenticación a las aplicaciones de Banca central se
encuentra sincronizado con el sistema de control de accesos al edificio de forma tal que solo
puedan acceder a las mismas, aquellos empleados que se encuentren presentes.
Comentario AGN: De acuerdo a lo manifestado por el organismo, se mantiene la
observación y las mejoras mencionadas se evaluarán en una próxima auditoría.
4.3.6.- Identificar y Asignar Costos
Objetivo de control: La necesidad de un sistema justo y equitativo para asignar costos de TI,
requiere de una medición precisa y un acuerdo con los usuarios.
Este proceso incluye la construcción y operación de un sistema para capturar, distribuir y
reportar costos de TI a los usuarios de los servicios. Un sistema equitativo de costos permite
al ente tomar decisiones más informadas respectos al uso de los servicios de TI.
Este objetivo de control afecta los siguientes requerimientos de la información necesaria para
cumplir las misiones del Organismo, primariamente:

la eficiencia

la confiabilidad
Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo
Nivel de madurez: Inicial. Hay un entendimiento general de los costos globales de los
servicios de información, pero no hay una distribución de costos por usuario, departamento,
grupos de usuarios, funciones de servicio, proyectos o entregables. Es casi nulo el monitoreo
de los costos. La distribución de costos de TI se hace como un costo fijo de operación
Observaciones: Las distintas áreas cargan su presupuesto anual en una aplicación a la que se
accede desde la Intranet que incluye solicitud de equipo informático y mejoras o nuevos
desarrollos. Se lleva un registro de los gastos realizados de soporte por cada Gerencia.
En la información recibida no se encontró documentación sobre el seguimiento de los gastos
presupuestados y si los gastos realizados fueron asignados a los sectores correspondientes.
Aclaraciones y/o comentarios del área responsable:
Para la identificación de los costos globales del servicio, el Sistema de Control
Presupuestario (SICOPRE) cuenta en su diseño con la provisión de información por
149
“Centros de Costo”. Éste puede reflejar el gasto incurrido con cargo a la dependencia
receptora del servicio o bien, independientemente del “Centro de Resultado” que lo
administró para su compra o prestación.
Comentario AGN: Faltan políticas formalmente definidas que sustenten la asignación y
definición de centros de costos así como de documentación de seguimiento de los gastos
presupuestados y su asignación real. Por lo tanto, se mantiene la observación.
4.3.7.- Educación y Capacitación de los Usuarios
Objetivo de control: Para una educación efectiva de todos los usuarios, incluyendo los
técnicos y profesionales de la materia, se requieren identificar las necesidades de
entrenamiento de cada grupo. Además de identificar las necesidades, este proceso incluye la
definición y ejecución de una estrategia para llevar a cabo un entrenamiento efectivo y para
medir los resultados. Un programa efectivo de entrenamiento incrementa el uso efectivo de la
tecnología al disminuir los errores, incrementando la productividad y el cumplimiento de los
controles clave tales como las medidas de seguridad de los usuarios.
Este objetivo de control afecta los siguientes requerimientos de la información necesaria para
cumplir las misiones del Organismo, primariamente:

la eficacia
y en forma secundaria:

la eficiencia
Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo
Nivel de madurez: Repetible. Hay conciencia sobre la necesidad de un programa de
entrenamiento y educación, y sobre los procesos asociados a lo largo de toda la organización.
El entrenamiento está comenzando a identificarse en los planes de desempeño individuales de
los empleados. Los procesos se han desarrollado hasta la fase en la cual se imparte
entrenamiento informal por parte de diferentes instructores, cubriendo los mismos temas de
materias con diferentes puntos de vista. Algunas de las clases abordan los temas de conducta
ética y de conciencia sobre prácticas y actividades de seguridad en los sistemas. Hay una
gran dependencia del conocimiento de los individuos. Sin embargo, hay comunicación
150
consistente sobre los problemas globales y sobre la necesidad de atenderlos.
Observaciones: Si bien existe un Plan estratégico de capacitación, este no abarca cursos
específicos para el personal de TI. Para este personal, en general, las capacitaciones se
incluyen con la compra de nuevos productos o por solicitudes especificas realizadas por cada
gerente.
En materia de seguridad de la información se realizan campañas de concientización a los
usuarios sobre este tema. En la Intranet se encuentran publicadas las circulares internas y las
normas y procedimientos internos sobre Seguridad de la Información.
Aclaraciones y/o comentarios del área responsable:
Las necesidades de formación de cada año, ya sea para la competencia de Capacidad
Técnica y Profesional como para las restantes competencias, son registradas por cada
dependencia en el Sistema de Gestión de Desempeño (SGD) que es administrado por el área
de Capacitación del BCRA, quien realiza un análisis de las mismas y de ser pertinente
gestiona las actividades solicitadas.
Comentario AGN: No existe una planificación estratégica ni política de capacitación de TI.
Por lo tanto, se mantiene la observación.
4.3.8.- Administrar la Mesa de Servicio y los Incidentes
Objetivo de control: Responder de manera oportuna y efectiva a las consultas de los
usuarios de TI, requiere de una mesa de servicio bien diseñada y ejecutada, y de un proceso
de administración de incidentes. Este proceso incluye la creación de una función de mesa de
servicio con registro, escalamiento de incidentes, análisis de tendencia, análisis causa-raíz y
resolución. Los beneficios incluyen el incremento en la productividad gracias a la resolución
rápida de consultas. Además, permite identificar la causa raíz (tales como un pobre
entrenamiento a los usuarios) a través de un proceso de reporte efectivo.
Este objetivo de control afecta los siguientes requerimientos de la información necesaria para
cumplir las misiones del Organismo, primariamente:

la efectividad

la eficacia
151
Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo
Nivel de madurez: Administrado y Medible. En todos los niveles de la organización hay un
total entendimiento de los beneficios de un proceso de administración de incidentes y la
función de mesa de servicio se ha establecido en unidades organizaciones apropiadas. Las
herramientas y técnicas están automatizadas. El personal de la mesa de servicio interactúa
muy de cerca con el personal de administración de problemas. Las responsabilidades son
claras y se monitorea su efectividad. Los procedimientos para comunicar, escalar, y resolver
incidentes han sido establecidos y comunicados. El personal de mesa de servicio está
habilitado y los procesos se mejora a través de uso de software para tareas específicas.
Observaciones: La función de Mesa de Servicio es realizada por la Subgerencia de
Atención a Usuarios que dispone de operadores telefónicos, empleados que se ocupan de dar
soporte de primer nivel, de segundo nivel y de la gestión con las empresas de mantenimiento
de equipos y con las empresas con las que se tienen equipos en garantía.
Los incidentes quedan registrados en el SAU (Sistema de Atención a Usuarios), que es un
sistema de desarrollo propio que utiliza como motor de base de datos a SQL Server.
Este sistema no dispone de una base de conocimiento que permita al operador ver las
soluciones utilizadas para problemas similares.
El sistema permite realizar el seguimiento de cada uno de los incidentes para conocer cuál es
su estado o a quien fue derivado para su resolución.
Aclaraciones y/o comentarios del área responsable:
Comentario AGN: Ante la falta de respuesta del organismo, se considera que se acepta
observación.
4.3.9.- Administrar la Configuración
Objetivo de control: Garantizar la integridad de las configuraciones de hardware y software
requiere establecer y mantener un repositorio de configuraciones completo y preciso. Este
proceso incluye la recolección de información de la configuración inicial, el establecimiento
de normas, la verificación y auditoría de la información de la configuración y la actualización
152
del repositorio de configuración conforme se necesite. Una efectiva administración de la
configuración facilita una mayor disponibilidad, minimiza los problemas de producción y
resuelve los problemas más rápido.
Este objetivo de control afecta los siguientes requerimientos de la información necesaria para
cumplir las misiones del Organismo, primariamente:

la efectividad
y en forma secundaria:

la eficiencia

la disponibilidad

la confiabilidad
Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo
Nivel de madurez: Administrado y Medible. En todos los niveles de la organización se
reconoce la necesidad de administrar la configuración y las buenas prácticas siguen
evolucionando. Los procedimientos y los estándares se comunican e incorporan a la
habilitación y las desviaciones son monitoreadas, rastreadas y reportadas. Se utilizan
herramientas automatizadas para fomentar el uso de estándares. Los sistemas de
administración de configuraciones cubren la mayoría de los activos de TI y permiten una
adecuada administración de liberaciones y control de distribución. Los análisis de
excepciones, así como las verificaciones físicas, se aplican de manera consistente y se
investigan las causas desde su raíz.
Observaciones: Los equipos de microinformática son entregados por la Subgerencia de
Instalaciones con una configuración de software y hardware definida según una circular
interna. Esta configuración no puede ser alterada por los usuarios porque la CPU viene con
un precinto de seguridad. Los usuarios no tienen privilegios de administración sobre el
sistema operativo.
Los servidores son controlados mediante una herramienta llamada OCS Inventory que
actualiza automáticamente cualquier cambio que se produzca tanto en hardware como en
software. Las actualizaciones de sistemas operativos de servidores se realizan siguiendo un
153
procedimiento formal.
Aclaraciones y/o comentarios del área responsable:
Comentario AGN: Ante la falta de respuesta del organismo, se considera que se acepta
observación.
4.3.10.- Administración de Problemas
Objetivo de control: Una efectiva administración de problemas requiere la identificación y
clasificación de problemas, el análisis de las causas desde su raíz y su resolución. El proceso
de administración de problemas también incluye la identificación de recomendaciones para la
mejora, el mantenimiento de registros y la revisión de estatus de las acciones correctivas. Un
efectivo proceso de administración de problemas mejora los niveles de servicio, reduce
costos y mejora la convivencia y satisfacción del usuario.
Este objetivo de control afecta los siguientes requerimientos de la información necesaria para
cumplir las misiones del Organismo, primariamente:

la eficacia

la eficiencia
y en forma secundaria:

la disponibilidad
Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo
Nivel de madurez: Definido. Se acepta la necesidad de un sistema integrado de
administración de problemas y se evidencia con el apoyo de la gerencia y la asignación de
presupuesto para personal y habilitación. Se estandarizan los procesos de escalamiento y
resolución. El registro y rastreo de problemas y sus soluciones se dividen dentro del equipo
de respuesta utilizando las herramientas disponibles sin centralizar. Es poco probable
detectar las desviaciones de los estándares y de las normas establecidas. La información se
comparte entre el personal de manera formal y pro activa. La revisión de incidentes y los
análisis son limitados e informales.
Observaciones: Los problemas reportados por los usuarios se registran en el SAU y su
154
solución se va escalando según sea el inconveniente detectado y su grado de complejidad.
Los problemas que se presentan en los servidores ubicados tanto en el centro de cómputos
principal como en el sitio alternativo son derivados a las empresas contratadas para ese fin. Si
bien se llevan estadísticas de las tareas realizadas. No se encontró evidencia de la existencia
de una base de conocimiento centralizada que permita una resolución más eficiente.
Aclaraciones y/o comentarios del área responsable:
Respecto a la observación que no encontró evidencia de la existencia de una base de
conocimiento centralizada que permita una resolución más eficiente, informamos que se
encuentra en trámite de contratación (Licitación Pública 05/11. Expediente 101.622/10), una
herramienta de software que permita efectuar un seguimiento de todos los pedidos de
servicio, su naturaleza y la forma de resolución de los mismos.
Por otra parte y en relación a problemas relacionados con la implementación, operación y
seguimiento de proyectos, en el año 2010 se implemento un sistema de registro de incidentes
y monitoreo de carácter general (Código de Sistemas asignado: IG) disponible en la intranet
Institucional. el cual originalmente fue planteado para el uso del área de Seguridad Interna
y que, posteriormente, fue escalado para ser usado durante la puesta en marcha del proyecto
para la nueva red de comunicaciones con el Sistema Financiero. Este sistema se halla en
fase de evaluación por parte de otras áreas, tanto de la Subgerencia General de Sistemas y
Organización como de la Gerencia Principal Seguridad de la Información. Dicha facilidad
contó con actividades de capacitación interna.
Comentario AGN: De acuerdo a lo manifestado por el organismo. Se mantiene la
observación. Las mejoras a realizar serán objeto de una próxima auditoría.
4.3.11.- Administración de Datos
Objetivo de control: Una efectiva administración requiere de la identificación del
requerimiento de datos. El proceso de administración de información también incluye el
establecimiento de procedimientos efectivos para administrar la librería de medios de soporte
para el respaldo y la recuperación de datos así como su eliminación apropiada. Una efectiva
administración de datos ayuda a garantizar la calidad, oportunidad y disponibilidad de la
155
información.
Este objetivo de control afecta los siguientes requerimientos de la información necesaria para
cumplir las misiones del Organismo, primariamente:

la integridad

la confiabilidad
Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo
Nivel de madurez: Definido. Se entiende y acepta la necesidad de la administración de
datos, tanto dentro de TI como a lo largo de toda la organización. Se establece la
responsabilidad sobre su administración. Se asigna la propiedad sobre los datos a la parte
responsable que controla la integridad y la seguridad. Los procedimientos de administración
se formalizan dentro de TI y se utilizan algunas herramientas para su respaldo y recuperación.
Se lleva a cabo algún tipo de monitoreo sobre la administración. Se definen métricas básicas
de desempeño. Comienza a aparecer el entrenamiento sobre administración de información.
Observaciones: La propiedad de los datos está formalmente definida y existen
procedimientos para que los dueños de los mismos otorguen conformidad para los accesos.
Las bases de datos son mantenidas por la Subgerencia de Administración de Base de Datos,
el personal de la misma se ocupa de asignar los permisos a grupos o roles, asignar usuarios y
definir los procedimientos de backup de las bases de datos.
Existen contratos de soporte con todos los proveedores excepto con uno, encontrándose en
proceso de negociación.
No existe un diccionario de datos de la organización, se encuentra en proceso de compra la
adquisición de una herramienta de modelado de datos y procesos que permita la creación del
mismo.
La Subgerencia de Administración de Bases de Datos define una agenda de backup que
ejecuta el sector de operaciones. Estos procesos disponen de alarmas que se disparan en el
caso de producirse una cancelación y de pistas de auditoría para los finalizados
correctamente.
Aclaraciones y/o comentarios del área responsable:
156
En el punto 4.1.2. “Definir la Arquitectura de Información” se ha respondido con respecto al
Diccionario de Datos.
Comentario AGN: Respondido en el Comentario AGN del punto 4.1.2. Se mantiene la
observación.
4.3.12.- Administración de Instalaciones
Objetivo de control: La protección del equipo de cómputo y del personal, requiere de
instalaciones bien diseñadas y administradas. El proceso de administrar el ambiente físico del
centro de datos, la selección de instalaciones apropiadas y el diseño de procesos efectivos
para monitorear factores ambientales y administrar el acceso físico. La administración
efectiva del ambiente físico reduce las interrupciones del servicio ocasionadas por daños al
equipo de cómputo y al personal.
Este objetivo de control afecta los siguientes requerimientos de la información necesaria para
cumplir las misiones del Organismo, primariamente:

la integridad

la disponibilidad
Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo
Nivel de madurez: Repetible. Los controles ambientales se implementan y monitorean por
parte del personal de operaciones. La seguridad física es un proceso informal, realizado por
un pequeño grupo de empleados con alto nivel de preocupación por asegurar las instalaciones
físicas. Los procedimientos de mantenimiento de instalaciones no están bien documentados y
dependen de las buenas prácticas de unos cuantos individuos. Las metas de seguridad física
no se basan en estándares formales y la gerencia no se asegura de que se cumplan los
objetivos de seguridad.
Observaciones: El BCRA dispone de dos centros de procesamiento en distintos edificios; el
principal y un sitio de procesamiento alternativo (SAP) de la Armada Argentina.
Ambos centros están vinculados por medio de fibra óptica.
Actualmente está en etapa de proyecto la construcción de un nuevo edificio a donde está
previsto mudar el actual centro de procesamiento principal.
157
En el sitio de procesamiento principal tiene instalados 75 servidores físicos propios y equipos
pertenecientes al Mercado Abierto Electrónico (MAE), al Mercado de Futuros y Opciones de
Rosario (ROFEX). Además están instalados servidores de comunicaciones de las distintas
empresas de telecomunicaciones que vinculan al BCRA con los bancos y entidades
financieras.
En el sitio de procesamiento principal, si bien se controlan los parámetros ambientales se
observó que no es correcta la distribución de los equipos para una adecuada disipación de
calor. Se observaron racks abiertos con los cables a la vista, reparaciones de mampostería no
terminadas y cables sueltos en el piso
El sitio de procesamiento alternativo, tiene las mismas deficiencias que presenta el sitio
principal a lo que se agrega una inadecuada descarga del líquido de condensación de aire
acondicionado, matafuegos colocados en el piso, fuera de los soportes correspondientes y
conductos de cables sin sus correspondientes tapas.
Aclaraciones y/o comentarios del área responsable:
Si bien en la actualidad, nos encontramos en proceso de adaptar las instalaciones a la
norma de seguridad física (NSI4001) recientemente emanada de la Gerencia Principal de
Seguridad de la Información, corresponde señalar que, independientemente de las acciones
informales, se encuentran disponibles distintos documentos que evidencian la preocupación
de la Gerencia por el cumplimiento de los objetivos de seguridad.
Asimismo, entre otras medidas tales como la disponibilidad de un bombero de la Policía
Federal las 24 hs. los 365 días del año, sistemas de detección y extinción de incendios, el
BCRA también cuenta con un Sistema de Control de Accesos y un Sistema de CCTV como
herramientas para facilitar la adecuada gestión de la seguridad física de sus instalaciones,
que es llevada a cabo por el área interna correspondiente de acuerdo a políticas y
procedimientos establecidos al efecto.
En cuanto a la distribución de los equipos en nuestro centro de cómputos principal, es la
adecuada para permitir su normal funcionamiento, tal como queda evidenciado en el
prácticamente nulo reporte de incidentes, en tanto que a la fecha, no existen cables sueltos
por el piso. ni otros aspectos que afecten la calidad del servicio.
158
Ahora bien, con respecto a las instalaciones físicas de los data centers en general, el Banco
se encuentra involucrado en una estrategia de sensible mejora de las mismas, estableciendo
un nuevo centro de cómputos principal en el edifico a construir en la calle Perón 461
ajustado a las normativas y disposiciones vigentes para este tipo de facilidades y migrando
el centro de cómputos secundario a una instalación certificada TIER III, tema éste que se
encuentra en un avanzado nivel de análisis de factibilidad.
Comentario AGN: Las observaciones corresponden a las visitas realizadas oportunamente.
Las mejoras que se hayan realizado serán objeto de una futura auditoría. En consecuencia se
mantiene la observación.
4.3.13.- Administración de Operaciones
Objetivo de control: Un procesamiento completo y apropiado de la información requiere su
efectiva administración y el mantenimiento del hardware. Este proceso incluye la definición
de políticas y procedimientos de operación para una administración efectiva del
procesamiento programado, protección de datos de salida sensitivos, monitoreo de
infraestructura y mantenimiento preventivo de hardware. Una efectiva administración de
operaciones ayuda a mantener la integridad de los datos y reduce los retrasos en el trabajo y
los costos operativos de TI.
Este objetivo de control afecta los siguientes requerimientos de la información necesaria para
cumplir las misiones del Organismo, primariamente:

la efectividad

la eficiencia
y en forma secundaria:

la integridad

la disponibilidad
Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo
Nivel de madurez: Definido. Se entiende y acepta dentro de la organización la necesidad de
administrar las operaciones de cómputo. Se han asignado recursos y las funciones repetitivas
están definidas, estandarizadas, documentadas y comunicadas de manera formal. Los
159
resultados de las tareas completadas y de los eventos se registran, con reportes limitados
hacia la gerencia. Se introduce el uso de herramientas de programación automatizadas y de
otras herramientas para limitar la intervención del operador. Se introducen controles para
colocar nuevos trabajos en operación. Se desarrolla una política formal para reducir el
número de eventos no programados. Los acuerdos de servicio y mantenimiento con
proveedores siguen siendo de naturaleza informal.
Observaciones: De la operación el centro de cómputos se ocupa la Gerencia de Centros de
Procesamiento que depende de la Gerencia Principal de Operaciones Informáticas.
El sitio de procesamiento alternativo es administrado en forma remota.
El personal de operaciones se ocupa además de los robots que realizan los respaldos de
información de acuerdo a los procedimientos definidos formalmente por las áreas
correspondientes y de la digitalización, microfilmación y procesamiento de imágenes según
procedimientos formalmente definidos
Aclaraciones y/o comentarios del área responsable:
Comentario AGN: Ante la ausencia de comentario se considera que se acepta la
observación.
4.4.- Monitorear y Evaluar
4.4.1.- Monitorear y Evaluar el Desempeño de TI
Objetivo de control: Una efectiva administración del desempeño de TI requiere un proceso
de monitoreo. El proceso incluye la definición de indicadores de desempeño relevantes,
reportes sistemáticos y oportunos de desempeño y tomar medidas expeditas cuando existan
desviaciones. El monitoreo se requiere para garantizar que las cosas correctas se hagan y que
estén de acuerdo con el conjunto de direcciones y políticas definidas formalmente.
Este objetivo de control afecta, primariamente:

la efectividad

la eficiencia
y en forma secundaria:
160

la confidencialidad

la integridad

la disponibilidad

el cumplimiento

la confiabilidad
Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo
Nivel de Madurez: Inicial. La gerencia reconoce una necesidad de recolectar y evaluar
información sobre los procesos de monitoreo. No se han identificado procesos estándar de
recolección y evaluación. El monitoreo se implanta y las métricas se seleccionan de acuerdo
a cada caso, o a las necesidades de proyectos y procesos de TI específicos. El monitoreo por
lo general se implanta de forma reactiva a algún incidente. La función de contabilidad
monitorea mediciones financieras básicas para TI.
Observaciones: La conducción del área no ha institucionalizado un proceso estándar de
monitoreo. Se han implantado algunos esquemas en relación a la administración de proyectos
y sobre la infraestructura tecnológica, pero no se encuadra en un programa de monitoreo
institucional donde se pueda medir la calidad del servicio y el desempeño en general. Las
evaluaciones se realizan al nivel de procesos y proyectos individuales de TI, pero no están
integradas a través de todos los procesos.
No se ha desarrollado una base de conocimiento formalizada donde se pueda evaluar el
desempeño histórico. En el caso del monitoreo de la infraestructura tecnológica, tienen
alarmas pero no llevan estadísticas.
No existe un marco de administración financiera de los proyectos, ni la administración de
costos o beneficios que permita evaluar la contribución esperada de TI a los resultados del
Organismo.
Aclaraciones y/o comentarios del área responsable:
La administración del desempeño de la Subgerencia General de Sistemas y Organización es
fijada por el Directorio a través de la Estructura Orgánica y Funcional (funciones, roles,
delegaciones y responsabilidades)
161
El desempeño de la Subgerencia General de Sistemas y Organización incluye el monitoreo,
reportes y acciones correctivas en caso de necesidades a futuro o eventuales.
Analizar las estadísticas sobre el comportamiento de todo el equipamiento, servicios y
espacio físico, evaluando la necesidad de efectuar ampliaciones o mejoras, así como
promover cambios necesarios en coordinación con las áreas involucradas está definido y,
consecuentemente, reflejado en el presupuesto plurianual.
La definición de indicadores de desempeño, así como la promoción de cambios tanto en
estrategias de infraestructura, desarrollo y organización para el ajuste a mejores prácticas y
el uso de una única herramienta para la gestión de todas las administraciones están
propuestos en informe 701-12-11, más concretamente, lo relacionado con la Gestión de la
Disponibilidad con indicadores de Disponibilidad, Fiabilidad y Capacidad de servicio.
Comentario AGN: La información recibida no permite inferir las afirmaciones realizadas
por el organismo en relación a este objetivo de control. El informe 701-12-11 se encuentra
fuera del período auditado.
Se debe establecer un marco de trabajo de monitoreo general y un enfoque que definan el
alcance, la metodología y el proceso a seguir para medir la solución y la entrega de servicios
de TI y para monitorear la contribución de TI a los objetivos estratégicos del organismo. Se
debe integrar este marco de trabajo con el sistema de administración del desempeño
corporativo.
Las mejoras realizadas serán objeto de una próxima auditoría. Se mantiene la observación.
4.4.2.- Monitorear y Evaluar el Control Interno
Objetivo de control: Establecer un programa de control interno efectivo para TI requiere un
proceso bien definido de monitoreo. Este proceso incluye el monitoreo y el reporte de las
excepciones de control, resultados de las auto-evaluaciones y revisiones por parte de terceros.
Un beneficio clave del monitoreo del control interno es proporcionar seguridad respecto a
que las operaciones sean eficientes y efectivas y el cumplimiento de las leyes y regulaciones
aplicables.
Este objetivo de control afecta, primariamente:
162

la efectividad

la eficiencia
y en forma secundaria:

la confidencialidad

la integridad

la disponibilidad

el cumplimiento

la confiabilidad
Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo
Nivel de Madurez: Repetible. La 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ón tiene conciencia sobre el monitoreo de los
controles internos. La gerencia de servicios de información realiza monitoreo periódico sobre
la efectividad de lo que considera controles internos críticos. Se están empezando a usar
metodologías y herramientas para monitorear los controles internos, aunque no se basan en
un plan formal. Los factores de riesgo específicos del ambiente de TI se identifican con base
en las habilidades de individuos.
Observaciones: Existe un marco de trabajo para el monitoreo del control interno de TI,
basado en un Plan de Auditoría que se somete a la aprobación de un Comité de Auditoría.
Dicho plan se elabora en función de una evaluación de riesgos previa. Durante la ejecución
del mismo, se realizan informes trimestrales, semestrales y anuales. Algunos casos
considerados críticos, son elevados al Directorio del Organismo.
Este marco de control es limitado a algunos procesos que se consideran relevantes al
momento de la elaboración del plan.
Falta profundizar el alcance del control interno a procedimientos de uso frecuente como parte
de una acción de control preventivo. Faltan métricas de monitoreo del control interno.
Aclaraciones y/o comentarios del área responsable:
El marco de control no es limitado a algunos procesos por cuanto la Auditoría Interna
163
evalúa anualmente la totalidad de los Objetivos de Control para la Información y la
Tecnología Relacionada (COBIT). Se aplican técnicas de monitoreo continuo para la
evaluación de controles preventivos. Se calculan métricas sobre observaciones de control
interno, las cuales son puestas en conocimiento del Comité de Auditoría en forma trimestral.
Comentario de AGN: De los informes de auditoría recibidos, no se verifica la evaluación de
la totalidad de los objetivos de control de COBIT, suponiendo que este fuese el marco de
trabajo, el cual no fue especificado formalmente. Tampoco se observan la utilización de
métricas, que deberían ser parte de un proceso de aseguramiento de la calidad de la gestión de
TI. Se mantiene la observación.
4.4.3.- Garantizar el Cumplimiento con Requerimientos Externos
Objetivo de control: Una supervisión efectiva del cumplimiento de las regulaciones requiere
el establecimiento de un proceso independiente de revisión. Este proceso incluye la
definición de una declaración de auditoría, independencia de los auditores, ética y estándares
profesionales, planeación, desempeño del trabajo de auditoría y reportes y seguimiento a las
actividades de auditoría. El propósito de este proceso es proporcionar un aseguramiento
positivo relativo al cumplimiento de TI de las leyes y regulaciones.
Este objetivo de control afecta, primariamente:

el cumplimiento
y en forma secundaria:

la confiabilidad
Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo
Nivel de Madurez: Proceso Definido. Se han desarrollado, documentado y comunicado
políticas, procedimientos y procesos, para garantizar el cumplimiento de los reglamentos y de
las obligaciones legales. Se brinda entrenamiento sobre requisitos legales y regulatorios
externos que afectan a la organización y se instruye respecto a los procesos de cumplimiento
definidos.
Observación: El Banco no ha implementado un sistema de medición del nivel de
incumplimiento de los requerimientos externos que genere informes periódicos a la
164
Dirección.
Aclaraciones y/o comentarios del área responsable:
La actividad de Auditoría Interna adhiere a los Estándares Internacionales de Auditoría
Interna en virtud de los cuales se ha elaborado el Manual de Auditoría Interna, el Estatuto y
el código de ética de la Auditoría Interna. Se efectúan planificaciones anuales en base a
riesgo, se aplican controles de calidad de auditoría interna y se efectúan informe de
seguimiento de la actividad de auditoría interna.
La medición del nivel de incumplimiento de los requerimientos externos se efectúa a través
del sistema de calificación del nivel de riesgo de las observaciones, incluido en los reportes
periódicos a la Dirección.
Comentario de AGN: De la información recibida y de las entrevistas realizadas, no se
infiere que se haya establecido un sistema de aseguramiento de la calidad donde se
formalicen métricas contra las cuales comparar y establecer posibles desvíos, en relación al
nivel de incumplimiento de los requerimientos externos. Se mantiene la observación.
4.4.4.- Proporcionar Gobierno de TI
Objetivo de control: El establecimiento de un marco de trabajo para una administración
efectiva, incluye la definición de estructuras, procesos, liderazgo, roles y responsabilidades
organizacionales para garantizar así que las inversiones en TI estén alineadas y de acuerdo
con las estrategias y objetivos del Organismo.
Este objetivo de control afecta, primariamente:

la efectividad

la eficiencia
y en forma secundaria:

la confidencialidad

la integridad

la disponibilidad

el cumplimiento

la confiabilidad
165
Nivel de riesgo: [X] Alto [ ] Medio [ ] Bajo
Nivel de Madurez: Inicial. Se reconoce que el tema del gobierno de TI existe y que debe ser
resuelto. Existen enfoques ad hoc aplicados individualmente o caso por caso. El enfoque de
la gerencia es reactivo y solamente existe una comunicación esporádica e inconsistente sobre
los temas y los enfoques para resolverlos. La gerencia solo cuenta con una indicación
aproximada de cómo TI contribuye al logro de los objetivos. La gerencia solo responde de
forma reactiva a los incidentes que hayan causado pérdidas a la organización.
Observaciones: Existe una organización de TI con funciones, roles, delegaciones y
responsabilidades bien definidos. Sin embargo, varias posiciones se encuentran sin cubrir al
momento de esta auditoría. No existe un plan Estratégico, ni un marco de administración
financiera de TI, ni de evaluación de riesgos, ni gestión de aseguramiento de la calidad, ni de
monitoreo. Existe conciencia sobre los temas de gobierno de TI, pero faltan actividades e
indicadores de desempeño del gobierno de TI, los cuales incluyan planeamiento, producción
de información y supervisión.
Aclaraciones y/o comentarios del área responsable:
Teniendo en cuenta la situación actual, el gobierno de las acciones de Sistemas y
Organización se encuentra focalizado en las distintas Gerencias Principales del Área.
Cada una de ellas aporta su planeamiento ajustado a la visión común plasmada en las
versiones pasadas y presente del Plan Estratégico de Sistemas y Organización y su enfoque
solo es reactivo en las situaciones que así lo amerita, toda vez que la propia naturaleza de la
actividad del BCRA, requiere de la atención de algunas necesidades no planificadas con
anterioridad. Asimismo, corresponde señalar la reciente elevación de la actualización del
Plan Estratégico .a consideración de las Autoridades del Banco, como así también la
consecuente actualización del Plan Operativo.
Otro aspecto de particular significación es el relativo a lo informado en el sentido que “La
gerencia solo responde de forma reactiva a los incidentes que hayan causado pérdidas a la
organización.”. Al respecto, los hechos desmienten esta afirmación. Partiendo de la base que
no hay registrados incidentes informáticos que objetivamente le hayan causado pérdidas al
BCRA y/o al Sistema Financiero Argentino, existen actividades pro activas como la señalada
166
en el punto “4.3.4. Garantizar la continuidad del Servicio”, que son demostrativas de la
anticipación a eventuales incidentes que pudieran perjudicar al BCRA, basado en la previa
evaluación de riesgos.
Comentario de AGN: Se retira del informe final de auditoría la oración “La gerencia sólo
responde de forma reactiva a los incidentes que hayan causado pérdidas a la organización”.
El resto de las observaciones se mantiene.
167
ANEXO VI
RESPUESTA DEL ORGANISMO
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204