2013_193info.pdf

INFORME DE AUDITORÍA
Al Dr. Ricardo Daniel Echegaray
Administrador Federal de Ingresos Públicos
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 Ministerio
de Economía y Finanzas, con el objeto que se detalla en el apartado 1.
1. Objeto de la auditoría
Evaluación de la Tecnología Informática de la Dirección General Impositiva en la
Administración Federal de Ingresos Públicos, organismo autárquico en la órbita del
Ministerio de Economía, con el objeto de determinar debilidades y fortalezas de la gestión
informática.
Período auditado: año 2011.
2. Alcance del examen
2.1. El equipo de auditoría en la etapa de planificación identificó los temas de mayor
exposición al riesgo y comprendió los siguientes ítems:
 Relevamiento de la documentación normativa del área de tecnología informática del
Organismo.
 Relevamiento de la infraestructura informática del Organismo.
 Relevamiento de los sistemas existentes en producción y desarrollo.
 Verificación de la existencia de la documentación recomendada por la Secretaría de la
Gestión Pública (SGP) y los estándares internacionales.
 Verificación de la adecuación de los sistemas, de la infraestructura existentes y de la
planificación a la misión y metas del Organismo y a las leyes y decretos que regulan su
actividad.
 Verificación del modelo de arquitectura de la información y su seguridad.
 Relevamiento y Análisis del organigrama del área de tecnología informática y su
1
funcionamiento.
 Relevamiento y Análisis del presupuesto operativo anual del área.
 Verificación del cumplimiento de la comunicación de los objetivos y las directivas de
la Gerencia.
 Análisis de 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.
 Análisis de:
 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 clientes de la 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.
 Análisis del monitoreo de los procesos, la idoneidad del control interno y la existencia
de auditoría interna.
2.2. La tarea abarcó la auditoría del estado de utilización de la Tecnología Informática en
la Sede Central de la Administración Federal de Ingresos Públicos, en base a la
información obtenida de las siguientes fuentes:
 Entrevistas realizadas con las principales autoridades de la Administración.
 Cuestionario para la determinación de las necesidades de análisis detallado.
 Cuestionarios para el análisis detallado de los temas que lo requerían.
 Manuales de Documentación de los Sistemas.
 Inspecciones directas efectuadas en el área de Sistemas de AFIP.
2.3. Limitaciones: No formó parte de la presente auditoría la evaluación del uso de la
Tecnología Informática en las delegaciones del interior del país, ni en otras dependencias
2
que no fuesen las instalaciones centrales.
Las tareas de campo abarcaron desde mayo 2012 hasta diciembre 2012.
2.4. Metodología: La auditoría incluyó dos etapas: la primera de planificación del análisis
detallado y la segunda de verificación del cumplimiento de lo informado en la primera
etapa.
La etapa de planificación incluyó las siguientes actividades:

Análisis del marco legal e institucional del funcionamiento de la Administración.

Análisis de los informes de Auditoría Interna en temas informáticos.

Entrevistas con los responsables de la Auditoría Interna y de cada una de las
Direcciones de la Administración Federal, en cuanto a la participación y experiencia
propia y de su personal en el uso de la Tecnología de la Información.

Entrevistas con el responsable del Área Informática de la Administración Federal de
Ingresos Públicos.
En la etapa de análisis detallado se ejecutó:

Análisis de las respuestas a los cuestionarios para determinación de las necesidades de
análisis detallado.

Determinación de las necesidades de verificación de las respuestas obtenidas.

Verificación mediante inspecciones in situ y entrevistas con personal subalterno,
realizada por especialistas en diversas ramas de la informática, a través del trabajo
directo en el campo.
En función de la información relevada y los niveles de riesgo estimados se definieron los
trabajos de campo convenientes para realizar las verificaciones necesarias.
Este informe es producto de la evaluación de la información recabada en las entrevistas
mantenidas y de las observaciones realizadas en el trabajo de campo.
Por otra parte se realizó un análisis de los riesgos asociados a los Objetivos de Control
definidos para cada uno de los procedimientos relevados.
Se han encontrado observaciones que se detallan por separado.
3
3. Aclaraciones previas
Por Dto. 1156/96, conforme art. 1º, se fusionó la Administración Nacional de Aduanas y la
Dirección General Impositiva, constituyendo la Administración Federal de Ingresos
Públicos, entendiendo que la citada Administración funcionará como ente autárquico en el
ámbito del entonces Ministerio de Economía y Obras y Servicios Públicos, asumiendo las
competencias, facultades, derechos y obligaciones de las entidades que se fusionan por ese
acto.
La DGRSS (Dirección General de los Recursos de la Seguridad Social) integra también la
Administración Federal de Ingresos Públicos, encargándose de la recaudación y
fiscalización de los fondos que financian las prestaciones de la Seguridad Social en la
República Argentina.
La Dirección General Impositiva (DGI) tiene a su cargo la aplicación, percepción,
recaudación y fiscalización de tributos interiores.
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 uno 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. 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 las observaciones
4
realizadas) para establecer el riesgo específico para ese objetivo, en el caso particular.
Puede observarse en los gráficos de los Anexos II y IV 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 bajo.
4.1. Planificar 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 los
objetivos estratégicos del Organismo y las prioridades. La función de TI y los participantes
del negocio son responsables de garantizar que se materialice el valor óptimo de los
proyectos y servicios. El plan estratégico debe mejorar el entendimiento de los interesados
clave respecto a las oportunidades y limitaciones de TI, evaluar el desempeño actual y
aclarar el nivel de inversión requerido. La estrategia de negocio y las prioridades se deben
reflejar en los 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 negocio 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: Repetible. La planeación estratégica de TI se comparte con la gerencia
correspondiente según se necesite. La actualización de los planes de TI ocurre como
respuesta a las solicitudes de la dirección. Las decisiones estratégicas se toman proyecto
por proyecto, sin ser consistentes con una estrategia global del Organismo. Los riesgos y
beneficios al usuario, resultado de decisiones estratégicas importantes, se reconocen de
forma intuitiva.
5
Observaciones: La normativa vigente (Anexo VI – Nota 1) exige la existencia de un Plan
de Gestión Anual que deberá cumplir el Administrador Federal de Ingresos Públicos.
Indicando además cómo y cuándo se controlará su cumplimiento y las penalidades para el
caso en que ello no ocurra.
Para el período analizado por esta auditoría, no existía un Plan Estratégico de TI
formalizado, alineado con el Plan Estratégico del Organismo aunque existen iniciativas,
relacionadas con la infraestructura, incluidas en este último.
Al cierre de los trabajos de campo está en etapa de revisión y aprobación final el Plan
Estratégico de TI del presente año.
4.1.2 Definir la arquitectura de información
Objetivo de control: La función de los sistemas de información debe crear y actualizar de
forma regular un modelo de información y definir los sistemas apropiados para optimizar
el uso de esta información. Esto incluye el desarrollo de un diccionario corporativo de
datos que contiene las reglas de sintaxis de los datos del Organismo, 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 Organismo. 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: Repetible. Existe un proceso de arquitectura de información y
procedimientos similares, aunque intuitivos e informales, que se siguen por distintos
6
individuos dentro de la organización. Las personas obtienen sus habilidades al construir la
arquitectura de información por medio de experiencia práctica y la aplicación repetida de
técnicas. Los requerimientos tácticos impulsan el desarrollo de los componentes de la
arquitectura de la información por parte de los individuos.
Observaciones: No existe 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 del Organismo. Queda a criterio de cada sector del Organismo la
administración de la información, por lo cual se es proclive a generar redundancia de datos.
No existe un esquema de clasificación de datos basado en la criticidad y sensibilidad la
información.
Se está trabajando en la homogeneización de los múltiples entornos de trabajo, producto de
la fusión de los distintos organismos originales en la actual AFIP.
Existen algunas iniciativas como el Padrón Único de Contribuyentes (PUC), el Sistema
Único de Parámetros de AFIP (SUPA), el Repositorio Único de Declaraciones Juradas
(RUCD) o Repositorio de Documentos Internos (RUCDI) que tienen un uso común para
todas las aplicaciones del Organismo.
4.1.3 Determinar la dirección tecnológica
Objetivo de control: La función de servicios de información debe determinar la dirección
tecnológica para dar soporte a los objetivos de la organización. Esto requiere de la creación
de un plan de infraestructura tecnológica y de un consejo de arquitectura que establezca y
administre expectativas 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 debe abarcar aspectos tales como arquitectura de sistemas, dirección tecnológica,
planes de adquisición, estándares, estrategias de migración y contingencias.
Esto permite mejorar los tiempos de reacción manteniendo entornos competitivos, mejorar
la economía de escala en los sistemas de información utilizados por el personal o para la
toma de decisiones, como también en interoperabilidad entre las plataformas y las
aplicaciones.
Este objetivo de control afecta, primariamente:

la efectividad
7

la eficiencia
Nivel de riesgo:
[X] Alto
[ ] Medio
[ ] Bajo
Nivel de Madurez: Definido. La gerencia está consciente de la importancia del plan de
infraestructura tecnológica. El proceso para su planificación es sólido. Existe un plan de
definido, documentado y bien difundido, aunque se aplica de forma inconsistente. La
orientación de la infraestructura tecnológica incluye el entendimiento con la alineación de
la estrategia del Organismo. Los proveedores clave se seleccionan en base a su
entendimiento de la tecnología a largo plazo y de los planes de desarrollo de productos, de
forma consistente con la dirección tecnológica del Organismo.
Observaciones: La Dirección de Infraestructura Tecnológica actualiza anualmente el Plan
de Infraestructura y ha desarrollado un sistema que permite el seguimiento de proyectos,
facilita la ejecución de los procesos y la realización de controles con el propósito de
optimizar la gestión del área. Sin embargo, la ausencia de planes estratégicos a nivel de la
Subdirección General de Sistemas y Telecomunicaciones, para el período auditado, no
permite establecer la dirección tecnológica. Se siguen procesos intuitivos y reactivos
basados en un trabajo sobre tendencias del mercado y posibles necesidades futuras, tanto
para establecer el mantenimiento de la infraestructura como su crecimiento.
Las áreas de desarrollo de sistemas están poco involucradas en la definición de la dirección
tecnológica.
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 estará inserta en un marco de trabajo de procesos de TI que
asegura la transparencia y el control, así como el involucramiento de los altos ejecutivos de
nivel decisorio. Un comité estratégico debe garantizar la vigilancia del consejo directivo
sobre TI, y uno o más comités administrativos, en los cuales participan tanto los sectores
operativos 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
8
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, TI se debe involucrar en los
procesos importantes de decisión.
Este objetivo de control afecta, primariamente:

la efectividad

la eficiencia
Nivel de riesgo:
[X] Alto
[ ] Medio
[ ] Bajo
Nivel de Madurez: Definido. Existen roles y responsabilidades definidos para la
organización de TI y para terceros. La organización de TI se desarrolla, documenta,
comunica y se alinea con la estrategia de TI. Se define el ambiente de control interno. Se
formulan las relaciones con terceros, incluyendo los comités de dirección, auditoría interna
y administración de proveedores. La organización de TI está funcionalmente completa.
Existen definiciones de las funciones a ser realizadas por parte del personal de TI y las que
deben realizar los usuarios. Los requerimientos esenciales de personal de TI y experiencia
están definidos y satisfechos. Existe una definición formal de las relaciones con los
usuarios y con terceros. La división de roles y responsabilidades está definida e
implantada.
Observaciones: Existe normativa que aprueba la estructura, define responsabilidades y
roles para cada perfil hasta el nivel de división. (Anexo VI – Nota 2)
Falta segregación de funciones a los niveles inferiores, lo que provoca que las definiciones
para el personal subalterno sean difusas y poco precisas. Se depende de individuos clave
para responsabilidades específicas.
Existe una matriz de perfiles de puestos, agrupados por cada especialización, con las
competencias técnicas requeridas para cubrirlo.
Algunas áreas como las relativas a la administración de riesgos y aseguramiento de la
calidad no se encuentran contempladas en el organigrama.
La política utilizada para la incorporación de personal provoca que en algunas áreas exista
dependencia crítica de individuos clave por falta de agentes especializados. Esto también
9
limita el intercambio de conocimientos, el planeamiento de la sucesión y la posibilidad de
respaldarse o reemplazarse mutuamente. A esto se agrega que existe personal contratado
realizando tareas relevantes.
La ubicación del Departamento de Seguridad Informática dependiendo de la Dirección de
Infraestructura no es la ideal, ya que debería encontrarse en un nivel superior.
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 y prioridades dentro del
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 los interesados, facilita el
uso efectivo y eficiente de recursos de TI, y brinda transparencia y responsabilidad dentro
del costo total de la propiedad, la materialización de los beneficios 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
presupuesto se da a conocer a los interesados. 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: Existe normativa (Anexo VI – Nota 3) que establece el marco general del
sistema presupuestario. Un área coordinadora elabora, con participación de las Áreas
10
Responsables, un anteproyecto de Plan de Gestión que contendrá las principales líneas de
acción y actividades previstas para el año siguiente sobre la base de los lineamientos del
Plan Estratégico de AFIP.
Además, la SDG SIT quedó comprendida por el Régimen Económico Financiero vigente
para las Direcciones Regionales Impositivas y Aduaneras, quedando en manos de la
Subdirección General de Administración Financiera la determinación de qué
contrataciones se efectuarán en forma centralizada. (Anexo VI – Nota 4)
No se ha establecido formalmente un marco de Administración Financiera de TI para
elaborar y administrar un presupuesto que refleje las prioridades establecidas en los
programas de inversión, la administración de costos y los beneficios esperados que permita
medir la contribución de TI a los objetivos estratégicos del Organismo.
Existen iniciativas aisladas en algunas direcciones pero no se ha formalizado un
procedimiento de trabajo común a toda la SDG SIT.
Las áreas de Desarrollo no contemplan en la metodología de ciclo de vida de desarrollo de
sistemas, un marco de administración presupuestaria que comprenda cálculos de costos y
beneficios esperados de los desarrollos, imputaciones por centro de costos y análisis
comparativo entre lo presupuestado y lo efectivamente gastado.
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
organizacional 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 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. 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
11
Nivel de Madurez: Repetible. La gerencia 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 individuales. La calidad se reconoce como una
filosofía deseable a seguir, pero las prácticas se dejan a discreción de los gerentes. El
entrenamiento se realiza de forma individual, según se lo requiera.
Observaciones: La Administración Federal de Ingresos Públicos, como entidad
autárquica, se encuentra facultada para reglamentar su funcionamiento interno, dictar
nomas reglamentarias e interpretativas de alcance general respecto de terceros y la de fijar
las políticas y criterios generales de conducción.
Existe normativa vigente (Anexo VI – Nota 5) por la cual se regulan los actos de carácter
individual y general, normativos o de ejecución, en el ámbito del Organismo, así como
también la competencia de los distintos funcionarios, ya sea originaria o delegada en que
se fundamenten los actos administrativos.
En el caso de la implantación y comunicación de políticas de TI, se implementan y/o
regulan a través de Disposiciones y/o Instrucciones Generales (Anexo VI – Nota 6). Las
mismas se encuentran disponibles para el personal del Organismo en su intranet.
Sin embargo, la ausencia de un Plan Estratégico de TI, hace difícil transmitir las políticas
de TI generales para la organización, salvo algunas iniciativas aisladas.
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 el negocio. Esto se logra siguiendo prácticas definidas y
aprobadas que apoyan el reclutamiento, entrenamiento, la evaluación del desempeño, la
promoción y la terminación. Este proceso es crítico, ya que las personas son activos
importantes, y el ambiente de gobierno y de control interno depende fuertemente de la
motivación y competencia del personal.
Este objetivo de control afecta, primariamente:

la efectividad
12

la eficiencia
Nivel de riesgo:
[X] Alto
[ ] Medio
[ ] Bajo
Nivel de Madurez: Parcialmente definido. Existe un proceso definido y documentado
para administrar los recursos humanos de TI. Existe un plan informal de administración de
recursos humanos. Existe un enfoque estratégico para la contratación y la administración
del personal de TI. El plan de entrenamiento formal está diseñado para satisfacer las
necesidades de los recursos humanos de TI. Está establecido un programa de rotación,
diseñado para expandir las habilidades gerenciales.
Observaciones: Existe normativa que regula la política de ingreso de personal, así como la
estructura organizativa de la Administración Federal de Ingresos Públicos hasta el nivel de
Subdirección General, inclusive. (Anexo VI – Nota 7)
También está definido el organigrama de la Subdirección con un detalle de los roles y
responsabilidades para cada perfil hasta nivel de división. (Anexo VI – Nota 8)
En relación a las competencias del personal, existe una matriz de perfiles de puestos,
agrupados por cada especialización, con las competencias técnicas requeridas para
cubrirlo. (Anexo VI – Nota 7)
Como resultado de un proceso de integración de distintos organismos (impositivo,
aduanero y seguridad social) persisten la convivencia de distintos convenios colectivos de
trabajo que generan asimetrías tanto administrativas como funcionales dentro de una
misma área de TI que brinda servicios a distintas Direcciones Generales.
La política restrictiva de incorporación de personal, provoca que:
 En algunas áreas existe dependencia crítica de individuos clave por falta de
personal especializado. Esto también limita el intercambio de conocimientos, el
planeamiento de la sucesión y la posibilidad de respaldarse o disponer una
adecuada rotación.
 Limita el establecimiento de un Plan de Carrera con movilidades ascendentes u
horizontales, que permitan a los individuos una perspectiva de desarrollo a largo
plazo. Existen concursos a niveles de jefaturas, pero no en los niveles inferiores.
13
También existe la posibilidad de ascender de categoría con la obtención de un título
universitario.
La política de retención del personal está basada en la estabilidad del empleo público y los
niveles salariales. Existe un riesgo latente de que si cambian estas condiciones, podría
originarse un éxodo de personal altamente especializado a otras organizaciones.
Se realizan evaluaciones de desempeño anuales, de cuyo resultado depende un incentivo
económico. El procedimiento, que está sistematizado, no contempla una evaluación de los
niveles inferiores hacia los niveles superiores. No existen mecanismos de autoevaluación.
En relación a la capacitación, el Organismo elabora un Plan de Capacitación en base a una
“Encuesta de necesidades de capacitación” que se incluyen en la confección del Plan de
Gestión Anual, no en función del Plan estratégico de la SDG SIT.
La capacitación se realiza en forma interna y externa.
Se cuenta con una herramienta de capacitación virtual denominada “Campus Virtual”
donde se deja a disposición del personal materiales referidos a distintas temáticas.
En relación a la capacitación de usuarios internos de las aplicaciones implantadas, las
denominadas “Pautas para el desarrollo y mantenimiento de sistemas informáticos en la
AFIP”, establecen los esquemas de documentación que son elaborados por las divisiones
de control de calidad de las áreas de desarrollo, que posteriormente quedan disponibles en
la página de la Dirección de Capacitación.
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 de calidad. Los requerimientos de calidad se deben manifestar y documentar con
indicadores cuantificables y alcanzables. La mejora continua se logra por medio del
constante monitoreo, corrección de desviaciones y la comunicación de los resultados a los
interesados. La administración de calidad es esencial para garantizar que TI está dando
valor a los objetivos de la organización, mejora continua y transparencia para los
interesados.
14
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 Calidad (SAC). La administración de la calidad es
impulsada por individuos cuando éste ocurre. La dirección realiza juicios informales sobre
la calidad.
Observaciones: Si bien en el Plan Estratégico del Organismo se plantea la necesidad de
establecer lineamientos para desarrollar procesos de calidad, no se evidenció al momento
de esta auditoría, la existencia de políticas de calidad, un plan de calidad y/o un sistema de
administración de la misma, ni a nivel de la organización ni en la SDG SIT. No está
definida en el organigrama el área correspondiente en la SDG SIT para llevarlo a cabo.
Hay iniciativas aisladas en las direcciones de Operaciones y de Infraestructura Tecnológica
para mantener la continuidad de los servicios a niveles razonables y en las áreas de
desarrollo en la fase de homologación de aplicaciones.
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 del Organismo, 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:
15

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: Parcialmente 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 sólo a proyectos grandes o como respuesta a problemas. Los
procesos de mitigación de riesgos están en implantación donde éstos se identifican.
Observaciones: No está definida la función correspondiente en el organigrama. Tampoco
se dispone de un marco de trabajo general de administración de riesgos de TI, integrado al
gobierno y el marco de control. Existen iniciativas aisladas en algunas direcciones o
departamentos que corresponden a las misiones y funciones que se fijaron para ellos.
El área de Auditoría Interna cuenta con un marco de administración de riesgos para poder
priorizar los procesos a controlar, ya que éste no es provisto por un área específica a tal fin.
El Organismo cuenta con una herramienta de Gobierno Corporativo, Administración de
Riesgos y Cumplimiento Regulatorio (GRC), pero sólo es utilizada por el área de Auditoría
Interna.
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 post-implantación
16
para garantizar la administración de los riesgos del proyecto y la entrega de valor para el
Organismo. Este enfoque reduce el riesgo de costos inesperados y de cancelación de
proyectos, mejora la comunicación y el involucramiento de los interesados y de los
usuarios finales, asegura el valor y la calidad de los entregables de los proyectos, y
maximiza su contribución a los programas de inversión en TI.
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 de negocio 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: No se ha normalizado un proceso de administración de proyectos que se
aplique a todas las áreas. Se utilizan distintas herramientas y distintos criterios para el
seguimiento de los proyectos, según sea el sector involucrado.
4.2. Adquirir e implementar
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 del proyecto 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
17
el costo para adquirir e implantar soluciones, mientras que al mismo tiempo facilitan el
logro de los objetivos del Organismo.
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 orientaciones claras y estructuradas
para determinar las soluciones de TI. El enfoque para la determinación de las soluciones de
TI requiere la consideración de alternativas evaluadas entre otros, contra los
requerimientos del proyecto o del usuario, las oportunidades tecnológicas, la factibilidad
económica y las evaluaciones de riesgo. El proceso para determinar las soluciones de TI se
aplica para algunos proyectos con base en factores tales como las decisiones tomadas por
el personal involucrado, la cantidad de tiempo administrativo dedicado, y el tamaño y
prioridad del requerimiento de proyecto original. Se usan enfoques estructurados para
definir requerimientos e identificar soluciones de TI.
Observaciones: Está definido el proceso de Ciclo de Vida de Desarrollo de Sistemas,
alineado a la política de seguridad, aprobada por normativa vigente. (Anexo VI – Nota 9)
Se establecen además procedimientos de interacción entre las áreas denominadas
“Definidoras” y las áreas de desarrollo de aplicaciones de la SDG SIT, cuya
documentación se encuentra formalizada en una serie de documentos entregables que
incluyen desde la definición del requerimiento de las necesidades funcionales,
determinación de los responsables tanto del área usuaria como del área informática, la
asignación de recursos y el cronograma estimado de trabajo.
Sin embargo, el procedimiento adolece de fuertes exclusiones, tales como:
a) La atención de requerimientos de mantenimiento de sistemas del tipo correctivo
originados debido a desvíos y/o errores en la programación.
b) Los desarrollos realizados para satisfacer requerimientos puntuales de información.
c) Los subcontratos o acuerdos de tercerización de software.
18
d) Los desarrollos realizados en carácter de pruebas de concepto como parte de tareas
de investigación.
Asimismo, la Subdirección General de Sistemas y Telecomunicaciones pueda autorizar la
no utilización de estas pautas para determinados casos.
Dada la ausencia de procedimientos para el tratamiento de situaciones de emergencia, en
estos casos se utilizan las excepciones antes mencionadas, y no contempla un
procedimiento de revisión de pistas de auditoría sobre las acciones tomadas.
Por otra parte, el procedimiento carece, en su etapa de evaluación preliminar, de
consideraciones relativas al análisis de factibilidad, análisis de riesgos y criterios
formalizados para la administración de prioridades, estimación de costos y beneficios
esperados que permitan la evaluación de cursos de acción alternativos, como la
tercerización del desarrollo.
Además, permite que la adopción de los documentos entregables sea a criterio de cada
división de desarrollo, mientras cumpla con los contenidos mínimos requeridos para cada
fase (definición, diseño, construcción e implementación) lo que genera que éstas hayan
adoptado un conjunto distinto de documentos. (Anexo VI – Nota 10)
En relación al entregable “REQ” (Requerimiento de Sistemas) no todas las áreas
definidoras formalizan su confección, por lo cual esta tarea suele ser hecha por las áreas de
desarrollo.
Al momento de esta auditoría se encuentra en elaboración una Instrucción General que
establecerá una nueva metodología de ciclo de vida de desarrollo de sistemas, que
reemplazará a la actual y que toma en consideración algunos aspectos aquí observados.
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 elegidos. Esto permite al Organismo
apoyar la operatividad de forma apropiada con las aplicaciones correctamente
automatizadas.
Este objetivo de control afecta, primariamente:
19

la efectividad

la eficiencia
y en forma secundaria:

la integridad

la confiabilidad
Nivel de riesgo:
[X] Alto
[ ] Medio
[ ] Bajo
Nivel de Madurez: Parcialmente definido. Existe un proceso claro, definido y de
comprensión general para la adquisición y mantenimiento de software aplicativo. Este
proceso va de acuerdo con la estrategia de TI y de la organización. Se intenta aplicar los
procesos de manera consistente a través de diferentes aplicaciones y proyectos. Las
metodologías son, por lo general, inflexibles y difíciles de aplicar en todos los casos, por lo
que es muy probable que se salten pasos. Las actividades de mantenimiento se planean,
programan y coordinan.
Observaciones: La Subdirección General de Informática y Telecomunicaciones
implementó las “Pautas para el desarrollo y mantenimiento de Sistemas Informáticos en la
AFIP” (Anexo VI – Nota 9) donde se define el proceso de Ciclo de Vida de Desarrollo de
Sistemas (CVDS). Las Pautas, están alineadas a la política de seguridad, aprobada
mediante “Pautas y consideraciones de seguridad a tener en cuenta en el Ciclo de Vida del
Desarrollo y Mantenimiento de Sistemas en relación con la Seguridad de la Información”.
La misma contempla documentación, aprobaciones y escalamiento en las etapas relevantes
tales como el diseño de alto nivel, el diseño detallado, fase de construcción, pruebas,
implementación y el pase a producción de aplicaciones.
Las misiones y funciones de las divisiones de Control de Calidad de las áreas de desarrollo
contemplan la etapa de aseguramiento de la calidad del software enfocada a las pruebas y a
la calidad de la documentación.
Falta incluir en la metodología de CVDS un análisis de la calidad del desarrollo del
software (Anexo VI – Nota 11) aunque existen algunas iniciativas para los desarrollos de
servicios web.
20
La metodología de CVDS tampoco contempla consideraciones de costos ni la posibilidad
de tercerizar el desarrollo o el mantenimiento.
Al momento de esta auditoría se encuentra en elaboración una Instrucción General que
establecerá una nueva metodología de ciclo de vida para el desarrollo de sistemas, que
reemplazará a la actual, y que toma en consideración algunos aspectos aquí observados.
En algunos casos, la contratación de servicios externos de desarrollo de sistemas se efectúa
a través de contratos con universidades, en cuyas cláusulas contractuales se estipula la
entrega de todo el software y documentación necesaria que permite al Organismo la
independencia del proveedor en tareas de mantenimiento futuro.
4.2.3 Adquirir y mantener infraestructura tecnológica
Objetivo de control: El Organismo debe 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.
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: Parcialmente definido. Existe un claro, definido y generalmente
entendido proceso para adquirir y dar mantenimiento a la infraestructura de TI. El proceso
respalda las necesidades de las aplicaciones críticas de lo organización y concuerda con la
estrategia de TI, pero no se aplica en forma consistente. Se planea, programa y coordina el
mantenimiento. Existe un ambiente independiente para pruebas de factibilidad.
Observaciones: Por ser la AFIP un organismo que recibió los recursos informáticos de la
Dirección General Impositiva, la Dirección General de Aduanas y de Dirección de
21
Seguridad Social existe una gran diversidad de plataformas de software y de motores de
base de datos. Cuentan con algunos productos obsoletos, discontinuados por sus
fabricantes, lo que implica que carezcan de soporte.
No se encontró un plan formalmente definido para la integración efectiva de las áreas y
sistemas que permita reducir la cantidad de plataformas existentes en la actualidad.
No existe un plan de adquisición de infraestructura tecnológica formalmente definido y
aprobado. Las compras de equipamiento se realizan en función de las necesidades
detectadas y de las proyecciones a futuro de acuerdo a distintos parámetros obtenidos de
los sistemas de control instalados.
Existe la posibilidad que pueda producirse atraso tecnológico al momento de recepción de
equipos nuevos debido al excesivo tiempo que insume el proceso completo de compras,
desde la formulación del requerimiento hasta la recepción del producto solicitado, que
puede superar el año.
Si bien se realizan los mantenimientos adecuados a los servidores, equipos de
comunicaciones y estaciones de trabajo, no existe un procedimiento automatizado para la
instalación de actualizaciones en los sistemas operativos de computadoras personales por
carecer de una herramienta necesaria para la instalación de los mismos.
La falta de un plan de análisis de riesgo y evaluación de vulnerabilidades no permite
identificar los posibles problemas que la falta de actualización en los sistemas operativos
puedan producir.
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 TI, y
proporciona 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:
22

la integridad

la disponibilidad

el cumplimiento

la confiabilidad
Nivel de riesgo:
[X] Alto
[ ] Medio
[ ] Bajo
Nivel de Madurez: Repetible. Se utilizan enfoques similares para generar procedimientos
y documentación, pero no se basan en un enfoque estructural o marco de trabajo. No hay
un enfoque uniforme para el desarrollo de procedimientos de usuario y de operación.
Individuos o equipos de proyecto generan los materiales de entrenamiento, y la calidad
depende de los individuos que se involucran. Los procedimientos y la calidad del soporte
al usuario son variables, con insuficiente consistencia e integración a lo largo de la
organización. Se proporcionan o facilitan programas de entrenamiento para las áreas
decisorias y los usuarios, pero no hay un plan general para ofrecer o dar entrenamiento.
Observaciones: El Decreto 618 del 10 de julio de 1997 establece que, entre otras
facultades, que el Administrador Federal de Ingresos Públicos reglamenta el
funcionamiento interno. El artículo 4 del mismo decreto prevé la posibilidad de delegar
dichas potestades a favor de los Directores Generales y Subdirectores Generales. Estos
actos internos de carácter resolutivo son formalizados a través de la aprobación de
Resoluciones, Disposiciones o Instrucciones Generales.
La Subdirección General de Sistemas y Telecomunicaciones genera este acto
administrativo en cada política o procedimiento a aplicar. Dependiendo del alcance que se
le quiera dar, es aprobada por una jerarquía acorde.
En el caso de las áreas de desarrollo y mantenimiento de aplicaciones, las respectivas áreas
de Control de Calidad deben verificar que la documentación esté confeccionada de acuerdo
a los estándares establecidos. Sin embargo, su cumplimiento depende del criterio adoptado
por cada área.
Toda la documentación referida a disposiciones, resoluciones e instrucciones generales se
encuentra disponible para los agentes del Organismo en la intranet.
23
No existe un mecanismo formalmente definido para la delegación de la capacitación en las
aplicaciones a los usuarios finales, desde las áreas de desarrollo de software a la Dirección
de Capacitación.
4.2.5 Adquirir recursos de TI
Objetivo de control: Se deben suministrar recursos de 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 se tengan 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:
[X] Alto
[ ] Medio
[ ] Bajo
Nivel de Madurez: Definido. Existen políticas y procedimientos para la adquisición de TI,
éstas toman como guía el proceso general de adquisición de la organización. Las compras
de TI se integran en gran parte con los sistemas generales de adquisición del Organismo.
Existen estándares de TI para la adquisición de recursos de TI. La administración de TI
comunica la necesidad de contar con una administración adecuada de adquisiciones y
contratos en toda la función de TI.
Observaciones: Las adquisiciones se llevan a cabo en el marco de administración de
proyectos y siguiendo la normativa de compras del Estado. Los procedimientos 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.
Existen además normativas internas que rigen para todas las áreas de AFIP. (Anexo VI –
Nota 12)
24
De las órdenes de compras analizadas surge que se tuvieron en cuenta los aspectos legales
y técnicos para cada contratación tales como responsabilidades y obligaciones legales,
financieras, organizacionales, de seguridad y de protección de propiedad intelectual.
La contratación de servicios externos de desarrollo de sistemas se efectúa a través de:
 Contratos con universidades, en cuyas cláusulas se estipula la entrega de todo el
software y documentación necesaria que permite al Organismo la independencia
del proveedor en tareas de mantenimiento. En algunos casos, el mantenimiento de
estos sistemas, producen una sobrecarga de trabajo a la dotación existente que no
está en condiciones de absorberlo adecuadamente.
 Personal contratado a plazo fijo. Estos contratos tienen una vigencia de tres meses y
generalmente son renovables. El agente que trabaja más de cinco años en esta
modalidad, cambia la figura a contrato por tiempo indeterminado. Esta indefinición
provoca incertidumbre en la disponibilidad de recursos para proyectos a mediano y
largo plazo.
4.2.6 Administrar cambios
Objetivo de control: Todos los cambios, incluyendo el mantenimiento de emergencia y
actualizaciones, relacionados con la infraestructura y las aplicaciones dentro del ambiente
de producción, deben administrarse formal y controladamente. Los cambios (incluyendo
procedimientos, procesos, sistemas y parámetros del servicio) se deben registrar, evaluar y
autorizar previo a la implantación y contrastar contra los resultados planeados después de
la misma. Esto garantiza la reducción de riesgos que impactan negativamente en 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
25
Nivel de riesgo:
[X] Alto
[ ] Medio
[ ] Bajo
Nivel de Madurez: Parcialmente definido. Existe un proceso formal definido para la
administración de cambios, que incluye la autorización del cambio y la administración de
la liberación. Se dan soluciones temporales a los problemas y los procesos pero en
ocasiones no se cumplen. El análisis de impacto de los cambios de TI se está formalizando
para apoyar la implantación planeada de nuevas aplicaciones y tecnologías.
Observaciones: Existe una instrucción general que define el proceso de Ciclo de Vida de
Desarrollo de Sistemas para las aplicaciones desarrolladas por el Organismo (Anexo VI –
Nota 9). Esta, está alineada a la política de seguridad, y aprobada formalmente. (Anexo VI
– Nota 13)
Se contempla documentación, aprobaciones y escalamiento en las etapas relevantes tales
como el diseño de alto nivel, el diseño detallado, fase de construcción, aseguramiento de la
calidad, pruebas, implementación y liberación de aplicaciones de software.
La etapa de aseguramiento de la calidad de software está enfocada a las pruebas y a la
calidad de la documentación, no así a un análisis de la calidad del desarrollo del software.
Existen algunas iniciativas en este sentido para los desarrollos de servicios web (web
services).
Faltan procedimientos para el tratamiento de situaciones de cambios de emergencia, que
contemplen una etapa de revisión obligatoria de pistas de auditoría sobre las acciones
tomadas.
Se observa en la aplicación práctica de esta metodología, las mismas falencias que en los
desarrollos nuevos: falta de consideraciones de análisis de prioridades, factibilidad, riesgo,
costos y beneficios esperados. La gestión de aseguramiento de la calidad está enfocada
solamente a las pruebas.
Al momento de esta auditoría se encuentra en elaboración una Instrucción General que
establecerá una nueva metodología de ciclo de vida de desarrollo de sistemas, que toma en
consideración algunos aspectos aquí observados.
En relación a las actualizaciones de sistema operativo, existe un procedimiento formal para
su instalación.
26
Con respecto a las estaciones de trabajo nuevas, existe un procedimiento inicial por el cual
se entrega al proveedor el software de base (Windows XP service pack III, Zip central,
Adobe reader, Adobe Flash Player, Open Office, Antivirus Panda) para que instale una
imagen del mismo en las máquinas a entregar. Cualquier incidente posterior es canalizado
por la Mesa de Ayuda que escala el problema de acuerdo al procedimiento del Sistema de
Registración de Incidentes (SRI).
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
Nivel de riesgo:
[X] Alto
[ ] Medio
[ ] Bajo
Nivel de Madurez: Parcialmente 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 pase a
producción tienen, probablemente, variaciones respecto al proceso definido, con base en
decisiones individuales.
Observaciones: Existe una instrucción general que define las actividades a seguir para la
puesta efectiva en producción de las aplicaciones (Anexo VI – Nota 14), se incluye allí las
responsabilidades de las áreas involucradas (Control de Calidad, Soporte Técnico y Área
27
Definidora) y la documentación que debe generarse, con sus correspondientes
aprobaciones.
En relación a los desarrollos de servicios web, al momento de esta auditoría se encontraba
a la firma del Administrador Federal de Ingresos Públicos una resolución general que
establece los procedimientos que deben utilizar los desarrolladores de aplicaciones de uso
propio o de terceros y que además contempla la posibilidad de que los usuarios finales,
puedan acceder al entorno de prueba (testing) y pase a producción.
Resta incluir en la metodología general un procedimiento de emergencia que abarque las
actuales exclusiones que permite esta resolución, tales como:
 La atención de requerimientos de mantenimiento de sistemas del tipo correctivo
debidos a desvíos y/o errores en la programación.
 Los desarrollos realizados para satisfacer requerimientos puntuales de información.
 Los subcontratos o acuerdos de tercerización de software.
 Los desarrollos realizados en carácter de pruebas de concepto como parte de tareas
de investigación.
 Casos expresamente autorizados por la SDG SIT.
El pase de los aplicativos a producción los solicitan las áreas de Control de Calidad a las
áreas de Operaciones a través de aplicativos. Este paso contempla la aprobación de las
Áreas Definidoras, aunque no en todos los casos se cumple.
La documentación de la aprobación de las etapas de pruebas no es homogénea en todos los
departamentos de desarrollo.
4.3. Entregar y dar soporte
4.3.1 Definir y administrar los niveles de servicio
Objetivo de control: La máxima autoridad debe definir un marco que promueva el
establecimiento de acuerdos de nivel de servicio que formalicen los criterios de desempeño
en virtud de los cuales se medirá su cantidad y calidad.
Este objetivo de control afecta, primariamente:

la efectividad

la eficiencia
28
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. Los niveles de servicio están acordados pero no están
controlados. Los reportes de los niveles de servicio están incompletos y dependen, en
forma individual, de las habilidades y la iniciativa de los administradores. Están
designados responsables de niveles de servicio por cada acuerdo con atribuciones
definidas, pero con autoridad limitada. Si existe un proceso para el cumplimiento de los
acuerdos de niveles de servicio es voluntario y no está debidamente implementado.
Observaciones: De la documentación recibida surge que no existe un marco de trabajo
para la administración de niveles de servicio entre las áreas usuarias y el prestador del
servicio, en este caso la Dirección de Sistemas y Telecomunicaciones.
Los acuerdos entre AFIP y distintos organismos, que proveen y reciben datos del mismo,
carecen de definiciones técnicas precisas y de penalizaciones por incumplimiento.
No existen acuerdos formalizados sobre niveles de servicio entre la Dirección de Sistemas
y Telecomunicaciones y otras áreas de la AFIP, aunque en determinados casos existen
plazos de tiempo no formales para la realización de tareas.
4.3.2 Administrar servicios de terceros
Objetivo de control: La máxima autoridad debe implementar medidas de control
orientadas a la revisión y al monitoreo de los contratos y procedimientos existentes para
garantizar la eficacia y el cumplimiento de la política del Organismo.
Este objetivo de control afecta, primariamente:

la efectividad

la eficiencia
y en forma secundaria:
29

la confidencialidad

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, operacionales y de control. Se asigna la responsabilidad de
supervisar los servicios de terceros. Los términos contractuales se basan en formatos
estandarizados.
Observaciones: Los procesos de compras de bienes y servicios se realizan de acuerdo con
normativa vigente (Anexo V), y por las reglamentaciones emitidas por la ONTI y por
SIGEN.
Los servicios de los proveedores se encuentran identificados y formalizados por medio de
órdenes de compra.
No existe una calificación de los servicios que tome en cuenta su importancia y su
criticidad para la organización.
La documentación sobre las relaciones técnicas, que incluyen los roles, responsabilidades,
metas y entregables se encuentran definidas en los pliegos de compras.
Como no existe un plan de riesgos para la AFIP, no se encuentran identificados ni existen
planes de mitigación sobre los riesgos relacionados con los proveedores que garantice una
entrega segura que permita la continuidad de los servicios.
4.3.3 Administrar el desempeño y la capacidad
Objetivo de control: Se debe implementar un proceso de administración orientado a la
recopilación de datos, al análisis y a la generación de informes sobre el desempeño de los
recursos de Tecnología de la Información, la dimensión de los sistemas de aplicación y la
30
demanda de cargas de trabajo. Este proceso debe incluir el pronóstico de las necesidades
futuras, almacenamiento y contingencias, y garantizar que los recursos de información que
soportan los requerimientos del Organismo estén disponibles de manera continua.
Este objetivo de control afecta, primariamente:

la efectividad

la eficiencia
y en forma secundaria:

la disponibilidad
Nivel de riesgo:
[X] Alto
[ ] Medio
[ ] Bajo
Nivel de madurez: Administrado. Hay procesos y herramientas disponibles para medir el
uso del sistema, el desempeño y la capacidad, y los resultados se comparan con metas
definidas. Hay información actualizada disponible, que brinda estadísticas estandarizadas y
alerta sobre incidentes causados por falta de desempeño o de capacidad. Los problemas
que aparezcan se enfrentan de acuerdo con procedimientos definidos y estandarizados. Se
utilizan herramientas automatizadas para monitorear recursos específicos tales como
espacio en disco, servidores y la electrónica de las redes. Las estadísticas de desempeño y
capacidad son reportadas en términos de los procesos del Organismo.
Observaciones: Se realiza el monitoreo de parámetros tales como capacidad, desempeño,
ambientales del centro de cómputos y el funcionamiento del sistema de energía eléctrica,
estado de las UPS y del sistema de alarma contra incendios.
Los datos obtenidos de los sistemas de control alimentan dos herramientas (PATROL y
TMART) que permiten obtener estadísticas que se utilizan para prever las necesidades
futuras del Organismo la organización.
Los dispositivos de control informan automáticamente cualquier desviación no esperada
emitiendo alarmas a los operadores y enviando mensajes a los teléfonos celulares de los
responsables de las áreas involucradas.
Se almacenan los logs de todos los incidentes, y se confeccionan estadísticas de desempeño
semanal y mensual.
31
La seguridad de los sistemas del Organismo es controlada por la División Monitoreo y
Detección que depende Departamento de Seguridad Informática de la Dirección de
Infraestructura Tecnológica. Para ello se analizan los datos de las siguientes herramientas:
 Firewall Central de Red
 IPS (Intrusion Prevention Systems – Sistemas de prevención de intrusión)
 IDS (Intrusion Detection Systems – Sistemas de detección de intrusión)
 Proxy
 Firewalls Departamentales
 WAF (Detección en línea de intrusiones)
 Análisis de Aplicaciones WEB
Se emiten alertas según parámetros establecidos y se realizan reportes sobre la cantidad de
eventos que se producen.
El monitoreo de los sistemas de comunicaciones lo realiza la División Gestión de Redes
que se ocupa de controlar el tráfico de las redes LAN, MAN, WAN, satelital y WiFi. Este
control se realiza con herramientas propias y con aplicaciones suministradas por los
proveedores.
4.3.4 Garantizar la continuidad del servicio
Objetivo de control: Se requiere desarrollar, mantener y probar planes para asegurar la
continuidad de servicio. Al respecto, se debe almacenar respaldos fuera de las instalaciones
y brindar entrenamiento periódico.
Este objetivo de control afecta, primariamente:

la efectividad

la disponibilidad
y en forma secundaria:

la eficiencia
Nivel de riesgo:
[X] Alto
[ ] Medio
[ ] Bajo
Nivel de madurez: Repetible. Se asigna la responsabilidad para mantener la continuidad
del servicio. Los enfoques para asegurar la continuidad están fragmentados. No hay un
plan de continuidad de TI documentado, aunque hay compromiso para mantener disponible
32
la continuidad del servicio y sus principios más importantes se conocen. Existe un
inventario de sistemas y componentes críticos, pero puede no ser confiable. Las prácticas
de continuidad en los servicios emergen, pero el éxito depende de los individuos.
Observaciones: No existe un Plan de Continuidad de Servicios que contemple todos los
posibles escenarios que puedan presentarse. Actualmente se encuentra en proceso de
definición la realización de un estudio de análisis de riesgo que servirá como base para
redacción del Plan de Continuidad.
No existe un sitio alternativo de procesamiento.
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 la
implementación de los controles de acceso lógico que garantizan que el ingreso a los
sistemas, datos y programas está limitado a los usuarios autorizados, los monitoreos y
pruebas periódicas así como acciones correctivas sobre las debilidades o incidentes
identificados.
Este objetivo de control afecta, 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: Administrado. Las responsabilidades sobre la seguridad de TI son
asignadas, administradas e implementadas de forma clara. Regularmente se lleva a cabo un
análisis de impacto y de riesgos de seguridad. Las políticas y prácticas de seguridad se
complementan con referencias específicas de seguridad. El contacto con métodos para
33
promover la conciencia de la seguridad es obligatorio. La identificación, autenticación y
autorización de los usuarios está estandarizada. La certificación en seguridad es buscada
por parte del personal que es responsable de la auditoría y la administración de la
seguridad. Las pruebas de seguridad se hacen utilizando procesos estándares y formales
que llevan a mejorar los niveles de seguridad. Los procesos de seguridad de TI están
coordinados con la función de seguridad de toda la organización. Los reportes de seguridad
están ligados con los objetivos del Organismo.
La capacitación sobre seguridad de TI se planea, administra e imparte para todo el
Organismo de manera que responda a las necesidades del mismo y a los perfiles de riesgo
de seguridad.
Observaciones: La administración de la seguridad de los sistemas está a cargo del
Departamento de Seguridad Informática que depende de la Dirección de Infraestructura
Tecnológica. Este departamento está dividido en dos Divisiones:
 Monitoreo y Detección
 Administración de Accesos
No tiene bajo su responsabilidad la seguridad física de la sala cofre donde se encuentran
los servidores del Organismo.
Existe un Comité de Seguridad compuesto por los titulares de las direcciones interesadas y
presidido por la Subdirección General de Sistemas y Telecomunicaciones.
La posición actual del Departamento de Seguridad Informática no se considera la más
apropiada dentro de la organización porque depende de la Dirección de Infraestructura
Tecnológica y esta situación podría influir en un correcto impacto horizontal hacia todo el
Organismo de las decisiones tomadas por el citado departamento.
Existe un Manual aprobado de Políticas de Seguridad de la Información. Desde su
publicación no existieron revisiones ni modificaciones. Las actualizaciones o ampliaciones
de su contenido se realizan mediante Instrucciones Generales que son impulsadas y
aprobadas por el Comité de Seguridad de la Información.
Los usuarios acceden a las distintas aplicaciones a través del Sistema Único de
Autenticación, este es un sistema que permite que el usuario sólo necesite autenticarse una
34
vez para acceder a los sistemas que tiene autorizados. Este está vinculado con el sistema
SARHA de administración de RR.HH.
Se contemplan también las situaciones de baja de personal, licencias ordinarias y traslado
de dependencias.
4.3.6 Identificar y asignar costos
Objetivo de control: Se debe implementar un sistema de imputación de costos que
garantice que se registren, calculen y asignen los costos de acuerdo con el nivel de detalle
requerido y el ofrecimiento de servicio adecuado.
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.
Este objetivo de control afecta, primariamente:

la eficiencia

la confiabilidad
Nivel de riesgo:
[X] Alto
[ ] Medio
[ ] Bajo
Nivel de madurez: Repetible. Hay conciencia general de la necesidad de identificar y
asignar costos. La asignación de costos está basada en los del hardware. No hay
capacitación o comunicación formal sobre la identificación de costos estándar y sobre los
procedimientos de asignación. No está determinada la responsabilidad sobre la
recopilación o la asignación de los costos, particularmente del software desarrollado.
Observaciones: Los costos de TI asociados al desarrollo de sistemas no son identificados
para ser imputados a las áreas correspondientes.
Los costos de los servicios de TI no están vinculados a los procesos del Organismo, no
existe un modelo definido para la asignación de los mismos. Solamente se imputan a las
áreas respectivas aquellos vinculados a las compras de hardware que patrimonialmente
queden a su cargo.
4.3.7 Educación y capacitación de los usuarios
Objetivo de control: Se debe establecer y mantener un plan integral de capacitación y
desarrollo. Para ello, se requieren identificar las necesidades de entrenamiento de cada
35
grupo. Además, este proceso debe incluir la definición y ejecución de una estrategia para
llevar a cabo un entrenamiento efectivo y para medir los resultados.
Este objetivo de control afecta, primariamente:

la eficacia
y en forma secundaria:

la eficiencia
Nivel de riesgo:
[X] Alto
[ ] Medio
[ ] Bajo
Nivel de madurez: Definido. El programa de entrenamiento y educación se
institucionaliza y comunica, y los empleados y gerentes identifican y documentan las
necesidades de entrenamiento. Los procesos de entrenamiento y educación se estandarizan
y documentan. Para soportar el programa de entrenamiento y educación, se establecen
presupuestos, recursos, instructores e instalaciones. Se imparten clases formales sobre
conducta ética y sobre conciencia y prácticas de seguridad en los sistemas. La mayoría de
los procesos de entrenamiento y educación son monitoreados, pero no todas las
desviaciones son susceptibles de detección por parte de la gerencia. El análisis sobre
problemas de entrenamiento y educación sólo se aplica de forma ocasional.
Observaciones: El relevamiento de las necesidades de capacitación y de la organización
de los distintos cursos es responsabilidad de la Dirección de Capacitación.
La recolección de las necesidades de capacitación de las distintas áreas del Organismo se
realiza mediante encuestas automatizadas
Se otorgan becas para capacitar externamente a los agentes (el capacitado de dictar cursos
de lo aprendido a solicitud del Organismo), y se contratan cursos de capacitación con los
proveedores cuando se adquiere nueva infraestructura. La capacitación interna se realiza
con personal propio, y se dictan cursos por medio de procedimientos WEB utilizando una
herramienta llamada CAMPUS.
En las áreas de desarrollo se notó falta de cursos de alto nivel para los agentes con mayor
capacidad técnica. En estas mismas áreas la cantidad acotada de personal no permite que el
mismo pueda dedicar las horas necesarias para capacitación.
36
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 causaraí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, primariamente:

la efectividad

la eficacia
Nivel de riesgo:
[X] Alto
[ ] Medio
[ ] Bajo
Nivel de madurez: Definido. Se reconoce y se acepta la necesidad de contar con una
función de mesa de servicio y un proceso para la administración de incidentes. Los
procedimientos se estandarizan y documentan, pero se lleva acabo entrenamiento informal.
Se deja la responsabilidad al individuo de conseguir entrenamiento y de seguir los
estándares. Se desarrollan guías de usuario y preguntas frecuentes (FAQs), pero los
individuos deben encontrarlas y puede ser que no las sigan. Las consultas y los incidentes
se rastrean de forma manual y se monitorean de forma individual, pero no existe un
sistema formal de reporte. No se mide la respuesta oportuna a las consultas e incidentes.
Los usuarios han recibido indicaciones claras de dónde y cómo reportar problemas e
incidentes.
Observaciones: La función la realiza en su mayor parte la División Mesa de Ayuda que
depende del Departamento de Soporte Técnico.
Para el registro de los incidentes se utiliza una herramienta llamada Sistema de
Registración de Incidentes (SRI). Estos pueden llegar vía telefónica, o por correo
electrónico. En ambos casos el sistema genera un ticket con un número único para su
identificación.
37
Si es resuelto en el momento, el incidente es cerrado por el operador, si este no lo puede
resolver puede consultarlo al personal con mayor experiencia sobre el tema, y si aún así no
puede ser resuelto se deriva el mismo al área que corresponda. Al recibir la conformidad,
el operador cierra el ticket.
Si bien el sistema SRI puede discriminar cada ticket por importancia, esta clasificación no
es utilizada para asignar un orden en la resolución de incidentes, sino que son resueltos a
medida que ingresan al sistema.
En el sistema no queda almacenada la conformidad del usuario sobre la solución del
incidente.
El sistema almacena información sobre distintos parámetros que permiten realizar informes
sobre el desempeño de la Mesa de Ayuda, pero los mismos sólo se realizan si son
solicitados con algún fin específico.
No se realizan encuestas de satisfacción del usuario.
4.3.9 Administrar la configuración
Objetivo de control: Se deben implementar controles que identifiquen y registren todos
los bienes de Tecnología de la Información y su ubicación física, y un programa de
verificación regular que confirme su existencia. Este programa debe incluir 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.
Este objetivo de control afecta, primariamente:

la efectividad
y en forma secundaria:

la eficiencia

la disponibilidad

la confiabilidad
Nivel de riesgo:
[X] Alto
[ ] Medio
[ ] Bajo
Nivel de madurez: Definido. Los procedimientos y las prácticas de trabajo se han
documentado, estandarizado y comunicado, pero la capacitación y la aplicación de
38
estándares dependen del individuo. Además se han implementado herramientas de
administración de configuración entre plataformas. Es poco probable detectar las
desviaciones de los procedimientos y las verificaciones físicas se realizan de manera
inconsistente. Se lleva a cabo algún tipo de automatización para ayudar a rastrear cambios
en el software o en el hardware. La información de la configuración es utilizada por los
procesos interrelacionados.
Observaciones: Con respecto al parque informático de PC de usuarios, existen dos
ámbitos bien diferenciados, por un lado todos los equipos ingresados al dominio de la
AFIP (aproximadamente un 80%) y por otro los que están fuera de él ubicados
principalmente el edificio de Hipólito Yrigoyen (aproximadamente 370 equipos).
No existe una herramienta que permita monitorear cambios en el software instalado de las
estaciones de trabajo. Tampoco existe una herramienta que permita actualizar los sistemas
operativos de forma automática.
Los equipos nuevos son entregados con una configuración que le es entregada al proveedor
para que él mismo las instale. Si bien en la actualidad los usuarios de dominio no tienen
privilegios de administración de sus equipos, los que están fuera de él podrían tener estos
privilegios, lo que tendría como consecuencia la falta de control del software instalado en
los mismos.
No existen mecanismos físicos que impidan el reemplazo de componentes internos de las
estaciones de trabajo por personal no autorizado.
4.3.10 Administración de problemas
Objetivo de control: Se debe implementar un sistema de administración de problemas que
registre y de respuesta a todos los incidentes. El proceso 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.
Este objetivo de control afecta, primariamente:

la eficacia

la eficiencia
y en forma secundaria:
39

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 capacitación. Se estandarizan los procesos de escalamiento y
resolución de problemas. El registro y rastreo de problemas y de 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 de identificación y resolución de problemas son limitados e
informales.
Observaciones: Los problemas son reportados por los usuarios por medio de llamadas
telefónicas o a través de correos electrónicos a Mesa de Ayuda donde el operador genera
un ticket.
La División de Mesa de Ayuda no tiene un segundo nivel de escalamiento de problemas,
sino que cuenta con referentes. Los incidentes que pueden presentarse son derivados a las
áreas correspondientes cuando los operadores no pueden resolverlos. De esta forma se
recargan las tareas de sectores como los de desarrollos que deben dedicar personal y
recursos para actividades que no figuran en sus misiones y funciones.
La aceptación de la solución del problema la realiza el usuario por medio de un correo
electrónico no quedando dicha constancia en el SRI.
El cierre del ticket en el sistema lo realiza el operador en forma manual cuando recibe el
correo electrónico de parte del usuario con la aprobación de la solución brindada.
4.3.11 Administración de Datos
Objetivo de control: La máxima autoridad debe establecer y mantener una combinación
eficaz de controles generales y de aplicación sobre las operaciones de Tecnología de la
Información para asegurar que los datos permanezcan durante su entrada, actualización y
almacenamiento completos, precisos y válidos. El proceso de administración de
información también incluye el establecimiento de procedimientos efectivos para
40
administrar la librería de medios de soporte para el respaldo y la recuperación de datos, así
como su eliminación apropiada.
Este objetivo de control afecta, 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 la administración de los datos. Se asigna la propiedad sobre los datos
a la parte responsable que controla la integridad y la seguridad. Los procedimientos de
administración de datos se formalizan dentro de TI y se utilizan algunas herramientas para
respaldos/recuperación y desecho de equipo. Se lleva a cabo algún tipo de monitoreo sobre
la administración de datos. 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 internos esta formalmente asignada a las áreas
definidoras.
No existe un diccionario de datos del Organismo, ni están definidos sus niveles de
criticidad.
En los casos en que se verifica que los archivos de datos recibidos de otros organismos
contengan errores, se solicita que sean reenviados. En aquellos casos en que el archivo
reenviado tenga el mismo nombre que el recibido con errores, se guarda en el repositorio
agregándole un sufijo secuencial para diferenciarlo del primero. No está definido
formalmente el tiempo que dichos archivos con datos erróneos deben permanecer en el
repositorio.
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. Se deben instalar controles ambientales y
físicos adecuados cuya revisión se efectúe periódicamente a fin de determinar su correcto
funcionamiento.
41
Este objetivo de control afecta, primariamente:

la integridad

la disponibilidad
Nivel de riesgo:
[X] Alto
[ ] Medio
[ ] Bajo
Nivel de madurez: Definido. Se entiende y acepta a lo largo de todo el Organismo la
necesidad de mantener un ambiente de cómputo controlado. Los controles ambientales, el
mantenimiento preventivo y la seguridad física cuentan con presupuesto autorizado y
verificado por la gerencia. Se aplican restricciones de acceso, permitiendo el ingreso a las
instalaciones de cómputo sólo al personal autorizado. Los visitantes son acompañados. Las
instalaciones físicas mantienen un perfil bajo y no son reconocibles de manera sencilla. Las
autoridades monitorean el cumplimiento con los reglamentos de salud y seguridad.
Observaciones: La AFIP dispone de una sala cofre donde se almacenan los servidores y
equipos de comunicaciones principales. La misma se encuentra sellada y protege a todos
los equipos contra incendios, humo, gases corrosivos, interferencias electromagnéticas,
filtraciones, accesos indebidos, etc.
Si bien el acceso a la sala cofre se controla mediante el uso de una tarjeta magnética y un
dispositivo de lectura de huellas dactilares, no se observó la existencia de un registro de
visitantes al centro de cómputos.
El Organismo cuenta con 3 generadores autónomos y 2 sistemas de UPS independientes
que permiten el funcionamiento de todo el centro de cómputos en el caso de falta de
suministro de energía eléctrica.
Todos los parámetros físicos del centro de cómputos (energía, humedad, temperatura, etc.)
se encuentran monitoreados en forma permanente.
El Organismo no dispone de un sitio alternativo de procesamiento para el caso en que el
centro de cómputos deje de operar.
No existe un plan de contingencia que indique los procedimientos necesarios para los
distintos escenarios que puedan presentarse.
42
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 involucrado. 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.
Este objetivo de control afecta primariamente:

la efectividad

la eficiencia
y en forma secundaria:

la integridad

la disponibilidad
Nivel de riesgo:
[X] Alto
[ ] Medio
[ ] Bajo
Nivel de madurez: Administrado. Las operaciones de cómputo y las responsabilidades de
soporte están definidas de forma clara y la propiedad está asignada. Las operaciones se
soportan a través de presupuestos de recursos para gastos de capital y de recursos
humanos. La capacitación se formaliza y está en proceso. Las programaciones y las tareas
se documentan y comunican, tanto a la función interna de TI como a los usuarios. Es
posible medir y monitorear las actividades diarias con acuerdos estandarizados de
desempeño y de niveles de servicio establecidos. Cualquier desviación de las normas
establecidas es atendida y corregida de forma rápida. La gerencia monitorea el uso de los
recursos de cómputo y la terminación del trabajo o de las tareas asignadas. Existe un
esfuerzo permanente para incrementar el nivel de automatización de procesos como un
medio de mejora continua. Se establecen convenios formales de mantenimiento y servicio
con los proveedores. Hay una completa alineación con los procesos de administración de
problemas, capacidad y disponibilidad, soportados por un análisis de causas de errores y
fallas.
Observaciones: Las tareas que comprenden al procesamiento son realizadas por la
División de Operación de Sistemas que depende del Departamento de Operaciones.
43
Los procedimientos se encuentran definidos formalmente por una Instrucción General que
aprueba el Calendario Operativo de Gestión en el cual se establecen las frecuencias y
parámetros de las tareas a realizar.
Existen procedimientos formalmente definidos para el monitoreo de la infraestructura de
TI, y para el control de los eventos que se produzcan. Mediante herramientas de monitoreo
(PATROL y TMART) se controlan todos los parámetros necesarios (uso de memoria,
espacio en disco, servicios en línea, parámetros ambientales, sistema de energía, etc.) para
un correcto funcionamiento del centro de cómputos.
La División Control de Datos y Procesos se encarga del pase a producción de la
información recibida de organismos externos (ANSES, Banco Nación, etc.) controlando la
integridad de la información recibida y poniéndola disponible para su procesamiento.
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 definido formalmente. Éste debe incluir la definición de indicadores
de desempeño relevantes, reportes sistemáticos y oportunos y tomar medidas expeditivas
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.
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
44
Nivel de Madurez: Repetible. Se han identificado algunas mediciones básicas a ser
monitoreadas. Los métodos y las técnicas de recolección y evaluación existen, pero los
procesos no se han adoptado en todo el Organismo. La interpretación de los resultados del
monitoreo se basa en la experiencia de individuos clave. Herramientas limitadas son
seleccionadas y aplicadas en algunas áreas para recolectar información, pero esta
recolección no se basa en un enfoque planeado.
Observaciones: Existen diferencias en el monitoreo de TI según el sector de que se trate.
En las áreas de desarrollo y mantenimiento de software no se ha normalizado un proceso
de administración de proyectos que sea común a todas. Se utilizan distintas herramientas y
criterios para el seguimiento de los proyectos.
La metodología de Ciclo de Vida de Desarrollo de Sistemas vigente permite la adopción de
documentación entregable a criterio de cada área de desarrollo. Esto impide la uniformidad
de información, y la documentación realizada difiere en estructura y calidad, según el
sector de que se trate.
La ausencia de un marco de trabajo de aseguramiento de la calidad, basado en estándares
predefinidos, no permite mediciones de desempeño, que sean obtenidas mediante la
generación de indicadores, provenientes de diversos puntos de control interno, en los
procesos de desarrollo.
En las áreas dependientes de la Dirección de Infraestructura, se ha establecido un
monitoreo en tiempo real, con estándares de desempeño preestablecidos empleando
herramientas automáticas. Los resultados obtenidos se utilizan para tomar acciones
preventivas o correctivas según el caso.
Los niveles de servicios los ha definido la Subdirección General de Sistemas y
Telecomunicaciones. No se han formalizado acuerdos de niveles de servicio con los
usuarios internos.
Por otra parte, el monitoreo de la infraestructura para gestión de datos está a cargo de la
División de Monitoreo y Gestión del Servicio. Mediante el cumplimiento de un
procedimiento formalizado, procura la operación continua y la disponibilidad de todos los
servicios por ellos suministrados. Se emiten alertas cuando se producen variaciones con
respecto a los estándares fijados como óptimos. Cada incidente se identifica unívocamente.
45
Si bien el seguimiento del incidente está normado por un procedimiento formalizado, el
mismo es manual y el intercambio de información con las áreas responsables de solucionar
el problema se lleva a cabo mediante correos electrónicos o comunicaciones telefónicas. Al
no contar con una herramienta integrada que lo integre y que incluya el escalamiento y las
comunicaciones inter áreas, se dificulta el rastreo de información histórica para un análisis
posterior.
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 las operaciones 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
Nivel de Madurez: Administrado y medible. La gerencia tiene implantado un marco de
trabajo para el monitoreo del control interno de TI. La organización ha establecido niveles
de tolerancia para el proceso de monitoreo del control interno. Se han implantado
herramientas para estandarizar evaluaciones y para detectar de forma automática las
excepciones de control. Se ha establecido una función formal para el control interno de TI,
con profesionales especializados y certificados que utilizan un marco de trabajo de control
46
formal avalado por la alta dirección. Un equipo calificado de TI participa de forma
rutinaria en las evaluaciones de control interno. Se ha establecido una base de datos de
métricas para información histórica sobre el monitoreo del control interno. Se realizan
revisiones entre pares para verificar el monitoreo del control interno.
Observaciones: Hay normativa debidamente aprobada que determina las “Misiones y
funciones de la Unidad de Auditoría Interna”, del cual depende el Departamento de
Auditoría de Sistemas Informáticos.
Existe un marco de trabajo para el monitoreo del control interno de TI, siguiendo el
cumplimiento de la resolución de SIGEN 48/05 respecto a las Normas de Control Interno
para Tecnología de la Información y los lineamientos estratégicos dispuestos en el Anexo I
del decreto 378/2005 del Plan Nacional de Gobierno Electrónico.
La metodología está establecida por el Manual de Auditoría Interna de la Unidad de
Auditoría Interna de la Administración Federal de Ingresos Públicos de acuerdo con la
resolución de SIGEN 152/02 “Normas de Auditoría Interna Gubernamental” según en el
marco de la ley 24.156 de Administración Financiera y de los Sistemas de Control del
Sector Público Nacional.
El Organismo cuenta con un Departamento de Auditoria de Sistemas Informáticos,
dependiente de la Subdirección General de Auditoría Interna, que cuenta con profesionales
internacionalmente certificados en Auditoría de Sistemas (CISA) y Certificación de
Riesgos (CRISC).
Se ha adquirido una herramienta de Gobierno Corporativo, Administración de Riesgos y
Cumplimiento Regulatorio denominada GRC. A través de ésta, se lleva a cabo un análisis
de riesgo donde se identifican la mayoría de los procesos involucrados en la operatoria de
TI, la evaluación de los riesgos asociados a cada proceso (la magnitud de la pérdida o daño
posible y la probabilidad que dicha pérdida o daño llegue a ocurrir). En función de la
criticidad que refleje cada caso individual, se asigna prioridades en el Plan Ciclo de
Auditoría, donde se fija la frecuencia de la revisión y la carga de recursos a asignar
(principalmente, horas hombre). El Plan Ciclo de Auditoría contempla información
histórica de 5 (cinco) años hacia atrás del período presente y una proyección de 5 (cinco)
47
años hacia adelante. Están contempladas un promedio de 8.386 horas de auditoría para
cada año.
4.4.3 Garantizar el cumplimiento con requerimientos externos
Objetivo de control: Una supervisión efectiva del cumplimiento regulatorio requiere del
establecimiento de un proceso independiente de revisión para garantizar el cumplimiento
de las leyes y regulaciones. 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: Repetible. Existe el entendimiento de la necesidad de cumplir con los
requerimientos externos y la necesidad se comunica. En los casos en que el cumplimiento
es recurrente se han desarrollado procedimientos individuales al respecto. No existe un
enfoque estándar. Hay dependencia del conocimiento y responsabilidad de los individuos y
los errores son posibles. Se brinda entrenamiento informal respecto a los requerimientos
externos y a los temas de cumplimiento.
Observaciones: No se encontró un catálogo de requerimientos legales y regulatorios
relacionados con la prestación del servicio de TI ni un procedimiento formal para su
desarrollo. No existen informes sobre el cumplimiento de las actividades de TI con los
requerimientos externos legales y regulatorios.
4.4.4 Proporcionar gobierno de TI
Objetivo de control: El establecimiento de un marco de trabajo de gobierno efectivo,
incluye la definición de estructuras, procesos, liderazgo, roles y responsabilidades
48
organizacionales para garantizar 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: Repetible. Existe conciencia sobre los temas de gobierno de TI. Las
actividades y los indicadores de desempeño del gobierno de TI, los cuales incluyen
procesos planeación, entrega y supervisión de TI, están en desarrollo. Los procesos de TI
seleccionados se identifican para ser mejorados con base en decisiones individuales. Se
han identificado mediciones básicas para el gobierno de TI, así como métodos de
evaluación y técnicas; sin embargo, el proceso no ha sido adoptado a lo largo del
Organismo. La comunicación respecto a los estándares y responsabilidades de gobierno se
deja a los individuos. Los individuos impulsan los procesos de gobierno en varios
proyectos y procesos de TI. Los procesos, herramientas y métricas para medir el gobierno
de TI no abarcan la totalidad de la gestión de TI.
Observaciones: El marco de gobierno de TI es incompleto:
 Falta un Plan Estratégico de TI alineado con el plan Estratégico del Organismo, que
garantice un entendimiento compartido entre los objetivos y la función de TI.
 No se ha normalizado un proceso de administración de proyectos que se aplique a
todas las áreas. Se utilizan distintas herramientas y distintos criterios para los
aspectos considerados para el seguimiento.
49
 No se ha definido un programa de administración de la calidad, inserto en un
sistema donde se pueda evaluar el desempeño de la función de TI, su contribución a
los objetivos estratégicos del Organismo y que sirva como herramienta de toma de
decisiones ante posibles desvíos entre los resultados esperados y los reales.
 No existe un marco de administración presupuestaria que abarque todas las áreas de
TI, que contemple la contabilidad por centro de costos imputándolos a los
proyectos y calculándose los beneficios esperados y su contribución a las misiones
y funciones de la organización.
 Falta la definición y ejecución de un marco integral de administración de riesgos
que defina cuál es el nivel de riesgo aceptado por el Organismo y que, con prácticas
de administración de riesgo, se asegure que el mismo no exceda las pautas
establecidas.
5. Comunicación del proyecto de informe y análisis de los descargos formulados por
la Administración Federal de Ingresos Públicos
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 7 de mayo de 2013,
por Nota AGN N° 38/13-AG4. Las mismas fueron remitidas por el Ente el 27 de junio de
2013.
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. Planificar y organizar
6.1.1. Definir un plan estratégico para TI
Recomendaciones:

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
50
cumplirán y medirán esos objetivos y recibir una autorización formal de los
interesados. El plan estratégico de TI debe incluir: el presupuesto de la
inversión/operativo, las fuentes de financiamiento, la estrategia de procuración, la
estrategia de adquisición, y los requerimientos legales y regulatorios. Debe ser lo
suficientemente detallado para permitir la definición de planes tácticos de TI.

Crear un conjunto de planes tácticos de TI que se deriven del plan estratégico de TI.
Estos deben establecer las iniciativas y los requerimientos de recursos requeridos
por TI, y cómo el uso de los recursos 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 planes operativos. Administrar de forma activa los
planes tácticos y las iniciativas de TI establecidas por medio del análisis de la
cartera de proyectos y servicios. Esto requiere encontrar el equilibrio entre
requerimientos y recursos, comparándolos con el logro de metas estratégicas,
tácticas y los beneficios esperados, tomando las medidas necesarias en caso de
desviaciones.

Administrar el grupo de proyectos de TI de forma proactiva y el conjunto de
programas de inversión de TI requerido para lograr objetivos estratégicos y
específicos 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 para alcanzar las metas establecidas,
entender el alcance completo del esfuerzo requerido, definir una rendición de
cuentas clara, asignar recursos y financiamiento y delegar autoridad.

Administrar el valor de TI para garantizar que las inversiones en TI del Organismo
contenga programas con casos de negocio 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 servicios de TI se deben
ejecutar contra acuerdos de niveles de servicios equitativos y exigibles. La
51
rendición de cuentas del logro de los beneficios y del control de los costos debe ser
claramente asignada y monitoreada.

Identificar en el Organismo las áreas que dependen de forma crítica de la TI.
Mediar entre los imperativos de éstas y la tecnología, de tal modo que se puedan
establecer prioridades concertadas.

Evaluar el desempeño actual, el de los planes existentes y de los sistemas de
información en términos de su contribución a los objetivos estratégicos 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 el Plan Estratégico. El modelo facilita la
creación, uso y compartición óptimas de la información por parte del Organismo de
una manera que conserva la integridad y es flexible, funcional, rentable, oportuna,
segura y tolerante 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 del Organismo, y previene la creación de elementos de datos
incompatibles.

Establecer un esquema de clasificación de datos que aplique a todo el Organismo,
basado en la criticidad y sensibilidad de la información. Este esquema incluye
detalles acerca de la propiedad de datos, la definición de niveles apropiados de
seguridad y de controles de protección, como también una breve descripción de los
requerimientos de retención y destrucción de datos, además de qué tan críticos y
sensibles son. Se usa como base para aplicar controles como el control de acceso,
archivo o encripción.
52

Definir e implantar procedimientos para garantizar la integridad y consistencia de
todos los datos almacenados en formato electrónico, tales como bases 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 es la apropiada para materializar la estrategia
de TI y la arquitectura de sistemas del Organismo. También identificar en el plan,
qué tecnologías tienen el potencial de crear oportunidades de negocio. 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 se basa en la dirección tecnológica e incluye acuerdos para
contingencias y orientación para la adquisición de recursos tecnológicos. También
debe tomar en cuenta los cambios en el ambiente competitivo, las economías de
escala en la obtención de equipo de sistemas de información, y la mejora en la
interoperabilidad de las plataformas y las aplicaciones.

Monitorear tendencias y regulaciones futuras. Establecer un proceso para
monitorear las tendencias del sector/industria, tecnológicas, 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 tecnológicas, 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 con base a su importancia, riesgo y en el cumplimiento de
requerimientos externos.
53

Establecer un consejo de arquitectura de TI que proporcione 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 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 organizacional general con un modelo supeditado a su importancia
dentro del Organismo, en especial en función de la criticidad que representa para la
estrategia del Organismo y el nivel de dependencia operativa.

Estructura organizacional. Establecer una estructura organizacional de TI interna y
externa que refleje las necesidades de la Organización. 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 tanto los roles
como las responsabilidades para el personal de TI y los usuarios que delimiten la
autoridad entre el personal de TI y los usuarios finales. Definir las
responsabilidades y la rendición de cuentas para alcanzar los objetivos estratégicos
del Organismo.

Responsabilidad del aseguramiento de calidad (QA) de TI. Asignar la
responsabilidad para el desempeño de la función de QA. Asegurar que la ubicación
organizacional, las responsabilidades y el tamaño del grupo de QA satisfacen los
requerimientos del Organismo.

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. Establecer responsabilidades sobre la
54
administración del riesgo y la seguridad de toda la organización para manejar los
problemas a nivel de todo el Organismo. Puede ser necesario asignar
responsabilidades adicionales de administración de la seguridad a nivel de sistemas
específicos para manejar problemas relacionados con seguridad. Obtener la
posición de la alta dirección en relación a los niveles aceptables de riesgo de TI que
se quieren asumir y la aprobación de cualquier riesgo residual.

Propiedad de Datos y de Sistemas. Proporcionar al Organismo los procedimientos
y herramientas que le permitan asumir sus responsabilidades de propiedad sobre los
datos y los sistemas de información. Las áreas responsables, dueña de los datos y
sistemas, deberán tomar decisiones sobre la clasificación de la información y cómo
protegerlos.

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.
Evaluar si todo el personal cuenta con la suficiente autoridad para ejecutarlos 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 un proceso crítico. La gerencia 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 las necesidades estratégicas del Organismo, operativo o de TI para
garantizar que la función de TI cuente con un número suficiente de personal
competente, el entrenamiento cruzado-funcional, la rotación de puestos y las
oportunidades de personal externo.

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 la función de TI.
55

Establecer y mantener una estructura óptima de enlace, comunicación y
coordinación entre la función de TI y otras funciones dentro y fuera de ella, tales
como el consejo directivo, ejecutivos, usuarios individuales, proveedores, oficiales
de seguridad, gerentes de riesgo y los contratistas externos.

Definir un marco de trabajo para el proceso de TI para ejecutar el plan estratégico
de TI. Este marco incluye estructura y relaciones de procesos de TI, propiedad,
medición del desempeño, mejoras, cumplimiento, metas de calidad y planes para
alcanzarlas. Proporciona integración entre los procesos que son específicos para TI,
administración de la cartera de proyectos del Organismo, y procesos de cambios de
estrategia. El marco de trabajo de procesos de TI debe estar integrado en un sistema
de administración de calidad y en un marco de trabajo de control interno.

Establecer un comité estratégico de TI que deberá asegurar que el gobierno de TI,
como parte del gobierno del Organismo, se maneja de forma adecuada, asesora
sobre la dirección estratégica y revisa las inversiones principales.

Establecer un comité directivo de TI compuesto por la gerencia ejecutiva, del sector
interesado y de TI para:

Determinar las prioridades de los programas de inversión de TI alineadas
con la estrategia y prioridades de los objetivos estratégicos del Organismo.

Dar seguimiento de los proyectos y resolver los conflictos de recursos.

Monitorear los niveles y las mejoras del servicio.
6.1.5. Administrar la inversión en TI

Establecer un marco de Administración Financiera para TI que impulse la
presupuestación, con base en el grupo de proyectos de inversión en bienes y
servicios. Comunicar los aspectos de costo y beneficio en los procesos de
priorización de presupuestos y administración de costos.

Implantar un proceso de toma de decisiones para dar prioridades a la asignación de
recursos a TI contemplando operaciones, proyectos y mantenimiento, de manera tal
de maximizar la contribución de TI y optimizar el retorno de inversión de los
proyectos de inversión y otros servicios y activos de TI.
56

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. Este debe dar soporte al
desarrollo de un presupuesto general de TI y de presupuestos para programas
individuales, con énfasis especial en los componentes de TI de esos 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 evaluar el impacto.
Junto con el patrocinador del proyecto, se deberán tomar las medidas correctivas
apropiadas y, en caso de ser necesario, el programa de inversión se deberá
actualizar.

Implantar un proceso de monitoreo de beneficios que permita medir la contribución
esperada de TI a los resultados esperados, ya sea como un componente de
programas de inversión en TI o como parte de un soporte operativo regular, que
debe identificar, acordar, monitorear y reportar. Los reportes se deben revisar y, en
donde existan oportunidades para mejorar la contribución de TI, se deben definir y
tomar las medidas apropiadas. Siempre que los cambios en la contribución de TI
tengan impacto directo en el programa o a otros proyectos relacionados, el
programa de inversión deberá ser actualizado.

Desarrollar un presupuesto por centro de costos.
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. Asegurar que el conocimiento
y el entendimiento de los objetivos estratégicos del organismo y de TI se
comunican a toda la organización. La información comunicada debe poseer una
visión claramente articulada entre los objetivos de servicio, la seguridad, los
controles internos, la calidad, el código de ética y conducta, políticas y
procedimientos. Estos deben incluirse dentro de un programa de comunicación
57
continua, apoyado por la alta dirección con acciones. La dirección debe dar especial
atención a comunicar la conciencia sobre 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 implantan
y comunican a todo el personal relevante de tal forma que estén incluidas y sean
parte integral de las operaciones organizacionales.

Ambiente de políticas y de control. Definir los elementos de un ambiente de control
para TI incluyendo las expectativas/requerimientos respecto a la entrega de valor
proveniente de las inversiones en TI, el nivel de tolerancia aceptado al riesgo, la
integridad, los valores éticos, la competencia del personal, la rendición de cuentas y
la responsabilidad. El ambiente de control se basa en una cultura que apoya la
entrega de valor, mientras que al mismo tiempo administra riesgos significativos,
fomenta la colaboración entre distintas áreas y el trabajo en equipo, promueve el
cumplimiento y la mejora continua de procesos, y maneja las desviaciones
(incluyendo las fallas) de forma adecuada.

Riesgo Corporativo y Marco de Referencia de Control Interno de TI. Elaborar y dar
mantenimiento a un marco de trabajo que establezca el enfoque de la organización
hacia los riesgos y hacia el control interno. Este debe estar integrado por el marco
de procesos de TI, el sistema de administración de calidad y debe cumplir los
objetivos generales del Organismo. Debe tener como meta maximizar el éxito de la
entrega de valor mientras minimiza los riesgos para los activos de información por
medio de medidas preventivas, la identificación oportuna de irregularidades, la
limitación de pérdidas y la recuperación oportuna de activos.

Administración de políticas para TI. Elaborar y dar mantenimiento a un conjunto
de políticas que apoyen la estrategia de TI. Estas políticas deben incluir el
propósito, los roles y responsabilidades, los procesos de excepción y referencias a
procedimientos, estándares y directrices. Las políticas deben incluir temas clave
como calidad, seguridad, confidencialidad, controles internos y propiedad
intelectual. Se deben revisar regularmente.
58
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 del personal. La gerencia debe implementar procesos para garantizar que
el Organismo cuente con una fuerza de trabajo posicionada de forma apropiada y
que tenga las habilidades necesarias para alcanzar las metas del Organismo.

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 proporcione actualizaciones, 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 retribuciones 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 de la organización.

Dependencia sobre los individuos. Minimizar la exposición de dependencias
críticas sobre individuos clave por medio de la documentación y divulgación del
conocimiento, como también la planeación de la sucesión y rotación de personal.

Incluir verificaciones de antecedentes en el proceso de reclutamiento de TI para el
personal que cubra funciones críticas. Este criterio también debe aplicarse a los
contratistas y proveedores.
59

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 del Organismo, estándares establecidos y
responsabilidades
específicas
del
puesto.
Los
empleados
deben
recibir
adiestramiento sobre cómo desempeñarse y conducirse, según sea necesario.

Cambios y culminación de trabajo. Tomar medidas respecto a los cambios en los
puestos, en especial las culminaciones sea por renuncia o despido. Se debe realizar
la transferencia del conocimiento, reasignar responsabilidades y 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, con respecto a la
administración de la calidad, que esté alineado con los objetivos estratégicos del
Organismo. 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 las no conformidades. El SAC
debe definir la estructura del Organismo para la administración de la calidad,
cubriendo los roles, las tareas y las responsabilidades. Todas las áreas clave deben
desarrollar sus planes de calidad de acuerdo a los criterios y políticas, y registran
los datos. Los datos del SAC deben ser monitoreados y medidos para medir la
efectividad y mejorarla cuando sea necesario.

Se deben identificar y mantener estándares, procedimientos y prácticas para los
procesos clave de TI de manera tal de orientar a la organización hacia el
cumplimiento del SAC. Se deben usar las mejores prácticas como referencia al
optimizar y adaptar las prácticas de calidad. del Organismo.

Se deben adoptar y mantener estándares para todo desarrollo y adquisición que
sigue el ciclo de vida de las aplicaciones, hasta el último entregable. Esto debe
incluir la documentación de hitos clave con base en criterios de aprobación
60
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; interoperabilidad
(posibilidad de que los módulos de un sistema puedan ser reutilizados por otros);
eficiencia de desempeño de sistemas; 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 en 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/cliente y área 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 el 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 del Organismo. Esto incluye la
alineación con el nivel de tolerancia al riesgo del Organismo.

Se debe establecer el contexto en el cual el marco de trabajo de evaluación de
riesgos se aplique 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 éstos se evalúan.

Se deben identificar todos aquellas amenazas y vulnerabilidades que tengan un
impacto potencial sobre las metas o las operaciones del Organismo, aspectos de
estratégicos, regulatorios, legales, tecnológicos, de recursos humanos y operativos.
Determinar la naturaleza del impacto y dar mantenimiento a esta información.
61

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.

Identificar los propietarios de los riesgos y a los dueños de procesos afectados, y
elaborar y mantener respuestas 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 aquellas que limiten los
riesgos residuales dentro de los niveles de tolerancia 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 determinació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
alta dirección.
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 uno de ellos, de tal modo
que todas las modificaciones a la línea base o indicadores al inicio 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 gobierno del programa y del proyecto.
62

Identificar las tareas 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 tales como el alcance,
los tiempos, la calidad, los costos o los riesgos; identificar las desviaciones con
respecto al plan; evaluar su impacto; 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 se hayan
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

Se deben definir, identificar, dar prioridades, especificar, acordar y planificar el
mantenimiento de los requerimientos técnicos y funcionales, de manera tal que se
cubra el alcance completo de todas las iniciativas requeridas. Definir también los
criterios de aceptación.

Estas iniciativas deben incluir todos los cambios requeridos, dada la naturaleza del
Organismo, de los procesos, de las aptitudes y habilidades del personal, su
estructura organizacional y la tecnología de apoyo. Además debe contemplar las
necesidades funcionales, la dirección tecnológica, el desempeño, el costo, la
confiabilidad, la compatibilidad, la auditoría, la disponibilidad y continuidad, la
ergonomía, la funcionalidad, la seguridad y la legislación vigente.

Establecer procesos para garantizar y administrar la integridad, exactitud y la
validez de los requerimientos, como base para el control de la adquisición y el
63
desarrollo continuo de sistemas. Estos requerimientos deben ser propiedad del
patrocinador del proyecto.

Reporte de análisis de riesgos. Identificar, documentar y analizar los riesgos
asociados con los procesos como parte de los procesos de la Organización para el
desarrollo de los requerimientos. Los riesgos incluyen las amenazas a la integridad,
seguridad, disponibilidad y privacidad de los datos, así como el cumplimiento de
las leyes y reglamentos.

Estudio de factibilidad y formulación de cursos de acción alternativos. Desarrollar
un estudio de factibilidad que examine la posibilidad de implementar los
requerimientos. Debe identificar los cursos alternativos de acción para el software,
hardware, servicios y habilidades que satisfagan los requerimientos establecidos,
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. Se debe asignar un
patrocinador del proyecto que apruebe y autorice los requisitos tanto funcionales
como técnicos, y los reportes del estudio de factibilidad en las etapas clave
predeterminadas. El patrocinador del proyecto debería tener la decisión final con
respecto a la elección de la solución y al enfoque de adquisición.
6.2.2. Adquirir o desarrollar y mantener software aplicativo
Establecer una metodología de Ciclo de Vida de Desarrollo de Sistemas (CVDS) que
contemple:

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
las especificaciones para garantizar que el diseño de alto nivel 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 para
64
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 y 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 se
traduzcan correctamente 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 aspectos 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 el
cumplimiento de los términos contractuales, la arquitectura de información del
Organismo, las aplicaciones existentes y su interoperabilidad con estas, 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.

Actualizaciones importantes en sistemas existentes. Seguir un proceso de desarrollo
similar al de desarrollo de sistemas nuevos en el caso que se presenten
65
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, relación costo/beneficio 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,
verificando la finalización de las revisiones de funcionalidad, desempeño y calidad.
Los aspectos a considerar incluyen aprobar las especificaciones de diseño que
satisfacen los requerimientos funcionales y técnicos, y las solicitudes de cambio;
verificar la compatibilidad con los sistemas existentes.
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 la calidad del software, para cumplir con los
estándares especificados en la definición de los requerimientos y en las políticas y
procedimientos de calidad del Organismo. Los aspectos a considerar incluyen
especificar el criterio de calidad y los procesos de validación y verificació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 estado de los requerimientos
particulares (incluyendo todos los requerimientos rechazados), y que las
modificaciones se aprueban a través de un proceso establecido de administración de
cambios.

Mantenimiento de software aplicativo. Desarrollar una estrategia y un plan para el
mantenimiento y pase a producción de software de aplicaciones. Los aspectos a
considerar incluyen implantación planeada y controlada, planeación de recursos,
reparación de defectos de programa y corrección de fallas, pequeñas mejoras,
66
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
de acuerdo a las necesidades del Organismo, 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
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. Evaluar los costos, la viabilidad del proveedor y del
producto al añadir nueva capacidad técnica.

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 la infraestructura para proteger los
recursos y garantizar su disponibilidad e integridad. Se deben definir y comprender
claramente las responsabilidades al utilizar componentes de infraestructura
sensitivos por todos aquellos que los desarrollan e integran. 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. Incluir una revisión
periódica contra las necesidades del Organismo, administración de parches y
estrategias
de
actualización,
riesgos,
evaluación
de
vulnerabilidades
y
requerimientos de seguridad.

Ambiente de prueba de factibilidad. Establecer el ambiente de desarrollo y de
pruebas para soportar la efectividad y eficiencia de las pruebas de factibilidad e
integración de aplicaciones e infraestructura, en las primeras fases del proceso de
adquisición y desarrollo. Se debe considerar la funcionalidad, la configuración de
67
hardware y software, pruebas de integración y desempeño, migración entre
ambientes, control de la versiones, datos y herramientas de prueba y seguridad.
6.2.4. Facilitar la operación y el uso

Marco para la documentación de sistemas. 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 elaborar
procedimientos de administración, de usuario y de operación. Este marco debe
aplicarse cada vez que se produzca una actualización de aplicaciones y/o
infraestructura.

Transferencia de conocimiento. Transferir el conocimiento a niveles gerenciales
para permitirles tomar posesión del sistema y los datos, ejercer la responsabilidad
por la entrega y calidad del servicio, del control interno y de los procesos
administrativos de la aplicación. La transferencia de 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. Transferencia de conocimientos
para permitir que los usuarios finales utilicen con efectividad y eficiencia la
aplicación como apoyo a los procesos del Organismo. La transferencia de
conocimiento incluye el desarrollo de un plan de capacitación que abarque al
entrenamiento inicial y al continuo, así como el desarrollo de habilidades, 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 de manera efectiva y eficiente de acuerdo a los niveles de servicio
requeridos. La transferencia del conocimiento debe incluir al entrenamiento inicial
68
y continuo, al desarrollo de las habilidades, los manuales de operación, los
manuales de procedimientos y escenarios de atención al usuario.
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 y la estrategia de adquisiciones de la
organización, para garantizar que la compra 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.
Debe cubrir, como mínimo, responsabilidades y obligaciones legales, financieras,
organizacionales, documentales, de desempeño, de seguridad de propiedad
intelectual y de conclusión, así como obligaciones y cláusulas de penalización por
incumplimiento cuando no cumplan los acuerdos de niveles de servicios
previamente establecidos. Todos los contratos y las modificaciones a contratos las
deben revisar asesores legales.

Selección de proveedores. Seleccionar proveedores mediante una práctica justa y
formal para garantizar la elección del mejor basado en los requerimientos que se
han desarrollado.

Adquisición de software. Garantizar que se protegen los intereses del Organismo en
todos los acuerdos contractuales de adquisición. Incluir y 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. Garantizar la protección de los intereses de
la organización en todos los acuerdos contractuales de adquisición. Incluir y hacer
cumplir los derechos y obligaciones de todas las partes en los términos
69
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, su correspondiente revisión, 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 los niveles de servicio, procedimientos de
mantenimiento, controles de acceso, seguridad, revisión de desempeño, términos de
pago y procedimientos de arbitraje.
6.2.6. Administrar cambios

Establecer procedimientos de administración de cambios formales para manejar de
manera estándar todas las solicitudes (incluyendo mantenimiento y actualizaciones)
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 una manera estructurada en cuanto a impactos
en los sistemas y su funcionalidad. Esta evaluación deberá incluir categorización y
priorización.
Previo
a
la
migración
hacia
producción,
los
interesados
correspondientes deberán establecer autorizaciones formales.

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 podrán realizarse, después de la
implantación del cambio. En todos los casos, se deberán dejar pistas de auditoría
para su posterior revisión.
70

Seguimiento y reporte del estado del cambio. Establecer un sistema de seguimiento
y reporte para mantener actualizados a los solicitantes y a los interesados relevantes
del cambio, acerca del estado del mismo.

Cierre y documentación del cambio. Siempre que se implantan cambios al sistema,
actualizar el o los sistemas asociados, la documentación de usuario y
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.

Plan de pruebas. Establecer un plan de pruebas y obtener la aprobación de los
principales involucrados. Dicho plan se debe basar en los estándares de toda la
organización y definir roles, responsabilidades y criterios de éxito. Debe
considerar: requerimientos de entrenamiento, instalación o actualización de un
ambiente de pruebas definido, definir tipos de prueba, los casos de prueba, manejo
y corrección de errores y aprobación formal.

Plan de implantación. Establecer un plan de implantación y obtener la aprobación
de los principales involucrados. Debe definir el diseño de versiones,
procedimientos de instalación, manejo de incidentes, controles de distribución,
almacenamiento de software, revisión de la versión y documentación de cambios.
Deberá también incluir medidas de respaldo y vuelta atrás.

Ambiente de prueba. Establecer un ambiente de prueba independiente. Este
ambiente debe asemejarse al ambiente de producción para permitir pruebas
acertadas. Se deben tener presentes los procedimientos para garantizar que los datos
utilizados en el ambiente de prueba sean representativos. Proporcionar medidas
adecuadas para prevenir la divulgación de datos sensibles. La documentación de los
resultados de las pruebas se debe archivar.
71

Conversión de sistema y datos. Garantizar que los métodos de desarrollo del
Organismo contemplen para todos los proyectos de desarrollo, implantación o
modificación, todos los elementos necesarios, tales como hardware, software, datos
de transacciones, archivos maestros, interfases con otros sistemas, procedimientos,
documentación de sistemas, etc., y sean convertidos del viejo al nuevo sistema de
acuerdo con un plan preestablecido. Se debe desarrollar y mantener pistas de
auditoría de los resultados previos y posteriores a la conversión. Los propietarios
del sistema deben verificar detalladamente la transición exitosa.

Prueba de cambios. Garantizar que se prueban los cambios de acuerdo con un plan
de aceptación definido y en base en una evaluación de impacto y de recursos que
incluya el dimensionamiento del desempeño en un ambiente separado de prueba,
por parte de un grupo de prueba independiente de los desarrolladores 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 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 del pasaje al entorno de producción.
72

Liberación de software. Garantizar que la liberación del software se regula con
procedimientos formales que aseguren la autorización, acondicionamiento, pruebas
de regresión, distribución, transferencia de control, seguimiento, 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. Monitorear los cambios a sistemas aplicativos,
procedimientos, procesos, sistemas y a las plataformas.

Revisión posterior a la implantación. Establecer procedimientos una revisión
posterior a la implantación del sistema para evaluar y reportar si el cambio satisfizo
los requerimientos del usuario y entregó los beneficios esperados.
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, definiciones, acuerdos de
niveles de servicio, de niveles de operación y sus correspondientes 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 de manera centralizada la definición base de los servicios de
TI dependiendo de sus características y de los requerimientos del caso, por medio
de la implantación de un enfoque de catálogo de servicios.

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 de TI. Deben
73
incluir los compromisos del usuario, los requerimientos de soporte, 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 los
niveles pactados de manera óptima.

Monitorear continuamente los criterios de desempeño especificados para el nivel de
servicio.

Emitir reportes periódicos 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 los
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
uno de ellos.
74

Debe existir un responsable que coordine la relación entre los proveedores y los
usuarios para asegurar la calidad 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 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 actuales del Organismo
apegándose de manera continua a los acuerdos del contrato y a los convenios de
niveles de servicio. Verificando 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, que asegure su disponibilidad, 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.
75

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 consideren 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 al Organismo la disponibilidad 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 los servicios a
lo largo de toda la organización. El objetivo de este marco es identificar las
debilidades en la infraestructura de TI, y guiar el desarrollo de los planes de
recuperación de desastres y de contingencias. Debe tomar en cuenta la estructura
del Organismo, 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ñados
para reducir el impacto de una interrupción mayor de las funciones y los procesos
clave del Organismo. Estos deben considerar requerimientos de resistencia a los
76
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 fortalecerlos y establecer prioridades en situaciones de
recuperación.

Evitar las demoras para recuperar los puntos menos críticos y asegurar que la
respuesta y la recuperación están alineadas con las necesidades prioritarias del
Organismo, verificando 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
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 estos, 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 pudieran estar implicados.

Asegurar que todas las partes involucradas reciban sesiones de capacitación de
forma regular respecto a los procesos, sus roles y responsabilidades en caso de
77
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. 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 se 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 del Organismo.

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.
78

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 actualizarlo en consecuencia.

La dirección del Organismo debe entender y aprobar los riesgos aceptados.
6.3.5. Garantizar la Seguridad de los Sistemas

Administrar la seguridad de TI al nivel más apropiado dentro del Organismo, 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 Organismo, 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, documentados y con
requerimientos de trabajo.

Los derechos de acceso del usuario deben ser solicitados por su gerencia,
aprobados por el responsable del sistema e implementado por la persona
responsable de la seguridad.

Las identidades del usuario y los derechos de acceso deben mantenerse en un
repositorio central.
79

Se debe implementar, mantener y actualizar medidas técnicas y procedimientos,
para establecer la identificación, realizar la autenticación y habilitar los derechos de
acceso de los usuarios.

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 del
Organismo deben acordarse contractualmente y en forma fehaciente 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 de seguridad aprobado. Debe existir una función de ingreso al
sistema y de monitoreo que permita 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.

Incluir una descripción de lo que se considera un incidente de seguridad y su nivel
de impacto. Definir un número limitado de niveles de impacto para cada incidente,
e identificar las acciones específicas requeridas y las personas que necesitan ser
notificadas.
80

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.

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 su
protección 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.

Deberá procurarse la protección de los datos sensibles, incluso frente a los
administradores de las bases de datos.
6.3.6. Identificar y asignar costos

Desarrollar un modelo orientado a los centros de costos.

Identificar todos los costos de TI para soportar un modelo de costos transparente.

Vincular los servicios de TI a los procesos del Organismo 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 del Organismo.
81

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 la
organización.

El modelo de costos de TI debe garantizar que los cargos por servicios sean
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 Formas de capacitación (por ejemplo, aula, web), tamaño del grupo
objetivo, accesibilidad y tiempo.

Identificar, en base en las necesidades de entrenamiento: a los grupos objetivo y a
sus miembros, a los mecanismos de capacitación más 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.
82

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 a la definición futura de
los planes de estudio y de las sesiones de entrenamiento.
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.
83

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 tendencias de problemas recurrentes de manera 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 registrar todos los activos y sus cambios.

Mantener una línea base de los elementos de la configuración para todos los
sistemas y servicios como punto de comprobación al cual volver tras un cambio.

Establecer procedimientos para soportar la gestión que permitan seguir el rastro de
todos los cambios al repositorio de configuración.

Revisar periódicamente los datos de configuración para verificar y confirmar su
integridad 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.

Incorporar todo los equipos al dominio de la AFIP.
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
84
coincidir con las responsabilidades organizacionales o con los grupos 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.
o Errores conocidos y probables.
o Seguimiento de las tendencias de los problemas.

Identificar e iniciar soluciones sostenibles indicando la causa raíz.

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 correctos, 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 tal que estos 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.
85

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
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 los equipos de TI que
soportan 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, implementar y monitorear procedimientos para otorgar, limitar, registrar 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.

Disponer un sitio alternativo de procesamiento.

Llevar control de las visitas a la sala cofre.
86

Incorporar a un plan de contingencia los procedimientos que mitiguen los daños
que puedan presentarse en situaciones de exposición al riesgo
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.

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
vinculadas a estas.

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
disminución del desempeño.
6.4. Monitorear y evaluar
6.4.1. Monitorear y evaluar el desempeño de TI

Enfoque del Monitoreo. Establecer un marco de trabajo de monitoreo general que
abarque a todas las áreas 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. Monitorear
87
la contribución de TI a los objetivos estratégicos del Organismo. Integrar el marco
de trabajo con el sistema de administración del desempeño organizacional.

Definición y recolección de datos de monitoreo. Trabajar con las áreas decisorias
para definir un conjunto de objetivos de desempeño. Definir referencias con las que
comparar los objetivos, e identificar datos disponibles a recolectar para medirlos.
Se deben establecer procesos para recolectar información oportuna y precisa para
reportar el avance contra las metas.

Método de monitoreo. Implantar un método de monitoreo que brinde una visión
sucinta y completa del desempeño de TI, acorde al sistema de monitoreo del
Organismo.

Evaluación del desempeño. Comparar en 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 cuando hay desvíos.

Reportes al consejo directivo y a ejecutivos. 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. Éstos deben
incluir el grado en el que se han alcanzado los objetivos planeados, los resultados
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 e
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.
88
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 del Organismo.

Monitorear y evaluar la eficiencia y efectividad de los controles internos de
revisión de la gerencia de TI.

Identificar las excepciones de control, y analizar e identificar sus causas raíz
subyacentes. Escalar las excepciones de control y reportar a los interesados
apropiadamente. Establecer acciones correctivas necesarias.

Control de auto-evaluación. Evaluar la completitud y efectividad de los controles
de gerencia 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, regulaciones, y otros
requerimientos externos que se deben de cumplir para incorporar 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.
89

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.

Reportes integrados. Integrar los reportes de TI sobre requerimientos legales,
regulatorios y contractuales con documentos 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
Corporativo. Basar el marco de trabajo en un adecuado proceso de TI y modelo de
control. Proporcionar la rendición de cuentas y prácticas inequívocas para evitar la
pérdida del control interno. Confirmar que el marco de gobierno de TI asegura el
cumplimiento de las leyes y regulaciones y que está alineado a la estrategia y
objetivos del Organismo. Informar del estado y cuestiones de gobierno de TI.

Alineamiento estratégico. Facilitar el entendimiento de la alta gerencia 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 las altas
gerencias y la función de TI sobre la contribución potencial de TI a los objetivos
estratégicos del Organismo. Trabajar con el consejo directivo para definir e
implementar organismos de gobierno, tales como un comité estratégico de TI, para
brindar una orientación a la gerencia respecto a TI, garantizando así que tanto la
estrategia como los objetivos se distribuyan hacia las unidades operativas y hacia
las unidades de TI.
90

Entrega de valor. Administrar los programas de inversión con TI, así como otros
activos y servicios de TI, para asegurar que ofrezcan el mayor valor posible para
apoyar la estrategia y los objetivos del Organismo. Asegurarse de que los
resultados esperados de las inversiones habilitadas por TI y el alcance completo del
esfuerzo requerido para lograr esos resultados esté bien entendido y que los
aprueben los interesados, que los activos y las inversiones se administren a lo largo
del ciclo de vida económico, y que se lleve a cabo una administración activa del
logro de los beneficios, tales como la contribución a nuevos servicios, ganancias de
eficiencia y un mejor grado de reacción a los requerimientos. Implementar un
enfoque disciplinado de la administración de los programas de inversión.

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 para
asegurar recursos y alineamiento apropiados con los objetivos estratégicos y los
imperativos actuales y futuros.

Administración de riesgos. Trabajar con el máximo nivel para definir el nivel de
riesgo de TI aceptable por el Organismo y obtener garantía razonable 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 aceptado por la dirección. Introducir las
responsabilidades de administración de riesgos en la organización, asegurando que
el desarrollo de proyectos y TI regularmente evalúan y reportan riesgos
relacionados con TI y su impacto y que la posición de los riesgos de TI del
Organismo es entendida por los interesados.

Medición del desempeño. Confirmar que los objetivos de TI 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. Informar a dirección los grupos de proyectos
relevantes, programas y desempeños de TI, soportados por informes para permitir a
la alta dirección revisar el progreso de la empresa hacia las metas identificadas.
91

Aseguramiento independiente. Garantizar de forma independiente (interna o
externa) la conformidad de TI con la legislación y regulación relevante; las
políticas del Organismo, estándares y procedimientos; prácticas generalmente
aceptadas; y la efectividad y eficiencia del desempeño de TI.
7. Conclusiones
El proyecto de auditoría estuvo enfocado en el área correspondiente a la Dirección General
Impositiva, por lo que el presente proyecto no fue una auditoría de seguimiento al
aprobado por Resolución 165 del 2004.
De todas maneras, dada la existencia de sectores que proveen servicios informáticos tanto a
la dirección auditada como a la Dirección General de Aduana y a la Dirección Nacional de
Seguridad Social, quedaron pocas áreas sin relevar.
En este contexto pudo observarse una evolución del Organismo en lo atinente a tecnología
de la información en sintonía con las recomendaciones que figuran en el informe del año
2004. Para el estudio realizado la madurez de la TI en el Organismo se encuentra entre los
niveles Repetible y Proceso definido.(ver Anexo I)
Se evidencia que el proceso de integración de las tres Direcciones Generales sustantivas
(Impositiva, Aduana y Seguridad Social), se encuentra todavía inconcluso, por lo que se
presentan los siguientes inconvenientes:
 Convivencia de distintas modalidades de contratación y convenios colectivos de
trabajo, generando inconvenientes administrativos y funcionales en las áreas de TI
que prestan servicios a distintas Direcciones Generales.
 Casos en que se depende de individuos claves en tareas sensitivas.

Variedad de plataformas de hardware y software que generan redundancia de
información y exceso de carga para su mantenimiento y actualización.
Además, la gestión de TI carece de una visión general e integradora, que se evidencia con
la ausencia de:
 Un plan estratégico de TI, con sus correspondientes planes tácticos, alineados con
el Plan Estratégico de la Organización.
92
 Un plan de Aseguramiento de la Calidad, que permita medir la eficacia y la
eficiencia de los servicios brindados por TI a los objetivos estratégicos del
Organismo.
 Un marco de trabajo de Administración de Proyectos centralizado que permita
administrar el conjunto de proyectos vigentes y futuros en un ambiente controlado.
 Un marco de trabajo de Administración de Riesgos, que permita gestionarlos con su
correspondiente formalización del curso de acción a tomar en caso de presencia de
cada evento, el riesgo residual o el riesgo asumido, si lo hubiere.
 Integración entre las Direcciones de Capacitación y las Direcciones de TI.
 Un plan de Contingencia que garantice la continuidad del servicio. Es necesario que
existan alternativas de procesamiento para el caso de colapso del centro de
cómputos principal.
 Un diccionario de datos único para todo el Organismo.
 Acuerdos de nivel de servicio definidos para los convenios que implican
intercambio de datos con otros organismos.
Finalmente, existe un problema funcional con áreas que prestan servicios de TI en forma
transversal a distintas direcciones y que tienen el mismo nivel que las áreas usuarias,
dificultando, por lo tanto, la aplicación de las directivas que generan.
8. LUGAR Y FECHA
BUENOS AIRES, Marzo 2013
9. FIRMA
93
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. El organismo 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 otros organismos. 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.
94
ANEXO II
Gráficos de brecha para los niveles de madurez de los objetivos de control
considerados.
95
96
Nivel de madurez promedio en Planear y Organizar: 2.10
97
Nivel de madurez en Adquirir e Implementar: 2.50
98
Nivel de madurez promedio en Entregar y Dar Soporte: 3.00
99
Nivel de madurez promedio en Monitorear y Evaluar: 2.50
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.
100

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).
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:
101
Tabla de incidencia de los criterios de la información en cada uno de los procesos
analizados (P: primaria, S: secundaria)
102
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.
103
104
105
106
107
108
109
110
111
ANEXO V - Análisis de la Vista
4.1. Planificar 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 los
objetivos estratégicos del Organismo y las prioridades. La función de TI y los participantes
del negocio son responsables de garantizar que se materialice el valor óptimo de los
proyectos y servicios. El plan estratégico debe mejorar el entendimiento de los interesados
clave respecto a las oportunidades y limitaciones de TI, evaluar el desempeño actual y
aclarar el nivel de inversión requerido. La estrategia de negocio y las prioridades se deben
reflejar en los 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 negocio 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: Repetible. La planeación estratégica de TI se comparte con la gerencia
correspondiente según se necesite. La actualización de los planes de TI ocurre como
respuesta a las solicitudes de la dirección. Las decisiones estratégicas se toman proyecto
por proyecto, sin ser consistentes con una estrategia global del Organismo. Los riesgos y
beneficios al usuario, resultado de decisiones estratégicas importantes, se reconocen de
forma intuitiva.
Observaciones: La normativa vigente (Anexo VI – Nota 1) exige la existencia de un Plan
de Gestión Anual que deberá cumplir el Administrador Federal de Ingresos Públicos.
Indicando además cómo y cuándo se controlará su cumplimiento y las penalidades para el
caso en que ello no ocurra.
112
Para el período analizado por esta auditoría, no existía un Plan Estratégico de TI
formalizado, alineado con el Plan Estratégico del Organismo aunque existen iniciativas,
relacionadas con la infraestructura, incluidas en este último.
Al cierre de los trabajos de campo está en etapa de revisión y aprobación final el Plan
Estratégico de TI del presente año.
Aclaraciones y/o comentarios del área responsable: Se comparte parcialmente lo
observado. La Subdirección General de Planificación ha revisado el proyecto de Plan
Estratégico de TI que fuera conocido por la AGN, señalando que el Plan Estratégico es
Institucional. Por lo tanto sugirió que, alineado con el mismo, se apruebe un Plan Táctico
de TI, el que cubre desde el año 2012 hasta el año 2015. El mismo ha sido enviado a la
citada Subdirección General para la formalización final de su aprobación.
Comentario de AGN: Tal como se menciona en la respuesta del organismo, el Plan
Estratégico de TI y los planes tácticos que lo sustentan, no se encontraba formalmente
aprobado al momento de la auditoria. Por lo tanto se mantienen las observaciones previas.
Las mejoras a realizar se evaluarán en una próxima auditoría.
4.1.2 Definir la arquitectura de información
Objetivo de control: La función de los sistemas de información debe crear y actualizar de
forma regular un modelo de información y definir los sistemas apropiados para optimizar
el uso de esta información. Esto incluye el desarrollo de un diccionario corporativo de
datos que contiene las reglas de sintaxis de los datos del Organismo, 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 Organismo. 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
113
y en forma secundaria:

la efectividad

la confidencialidad
Nivel de riesgo:
[X] Alto
[ ] Medio
[ ] Bajo
Nivel de Madurez: Repetible. Existe un proceso de arquitectura de información y
procedimientos similares, aunque intuitivos e informales, que se siguen por distintos
individuos dentro de la organización. Las personas obtienen sus habilidades al construir la
arquitectura de información por medio de experiencia práctica y la aplicación repetida de
técnicas. Los requerimientos tácticos impulsan el desarrollo de los componentes de la
arquitectura de la información por parte de los individuos.
Observaciones: No existe 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 del Organismo. Queda a criterio de cada sector del Organismo la
administración de la información, por lo cual se es proclive a generar redundancia de datos.
No existe un esquema de clasificación de datos basado en la criticidad y sensibilidad la
información.
Se está trabajando en la homogeneización de los múltiples entornos de trabajo, producto de
la fusión de los distintos organismos originales en la actual AFIP.
Existen algunas iniciativas como el Padrón Único de Contribuyentes (PUC), el Sistema
Único de Parámetros de AFIP (SUPA), el Repositorio Único de Declaraciones Juradas
(RUCD) o Repositorio de Documentos Internos (RUCDI) que tienen un uso común para
todas las aplicaciones del Organismo.
Aclaraciones y/o comentarios del área responsable: Si bien en el momento de la
Auditoria se mencionó que se encontraba en homologación un sistema que actúa como
diccionario de datos, el 1 ° de enero de 2013 se puso en producción un servicio
interactivo, al que se accede a través del SUA (Sistema Único de Autenticación),
denominado Clasidat cuyo objetivo es la documentación, descripción y clasificación de la
Información estructurada en bases de datos.
Este servicio fue desarrollado para cumplir con la IG N° 5/12 (AFIP) la cual trata sobre
114
la Clasificación de la Información
Tal como norma la mencionada IG, las áreas definidoras de sistemas y procesos de
información -en forma conjunta con las áreas que desarrollan los mismos-, utilizarán
Clasidat para identificar cada instancia de base de datos, las tablas que las componen y
sus campos, indicando tanto su descripción como su criticidad.
Comentario de AGN: Se mantienen las observaciones. Para el período auditado, no se
encontraba vigente la IG N° 5/12 (AFIP) ni la implementación del sistema “Clasidat”. Las
mejoras expresadas se evaluarán en una próxima auditoría.
4.1.3 Determinar la dirección tecnológica
Objetivo de control: La función de servicios de información debe determinar la dirección
tecnológica para dar soporte a los objetivos de la organización. Esto requiere de la creación
de un plan de infraestructura tecnológica y de un consejo de arquitectura que establezca y
administre expectativas 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 debe abarcar aspectos tales como arquitectura de sistemas, dirección tecnológica,
planes de adquisición, estándares, estrategias de migración y contingencias.
Esto permite mejorar los tiempos de reacción manteniendo entornos competitivos, mejorar
la economía de escala en los sistemas de información utilizados por el personal o para la
toma de decisiones, como también en interoperabilidad entre las plataformas y las
aplicaciones.
Este objetivo de control afecta, primariamente:

la efectividad

la eficiencia
Nivel de riesgo:
[X] Alto
[ ] Medio
[ ] Bajo
Nivel de Madurez: Definido. La gerencia está consciente de la importancia del plan de
infraestructura tecnológica. El proceso para su planificación es sólido. Existe un plan de
definido, documentado y bien difundido, aunque se aplica de forma inconsistente. La
orientación de la infraestructura tecnológica incluye el entendimiento con la alineación de
la estrategia del Organismo. Los proveedores clave se seleccionan en base a su
115
entendimiento de la tecnología a largo plazo y de los planes de desarrollo de productos, de
forma consistente con la dirección tecnológica del Organismo.
Observaciones: La Dirección de Infraestructura Tecnológica actualiza anualmente el Plan
de Infraestructura y ha desarrollado un sistema que permite el seguimiento de proyectos,
facilita la ejecución de los procesos y la realización de controles con el propósito de
optimizar la gestión del área. Sin embargo, la ausencia de planes estratégicos a nivel de la
Subdirección General de Sistemas y Telecomunicaciones, para el período auditado, no
permite establecer la dirección tecnológica. Se siguen procesos intuitivos y reactivos
basados en un trabajo sobre tendencias del mercado y posibles necesidades futuras, tanto
para establecer el mantenimiento de la infraestructura como su crecimiento.
Las áreas de desarrollo de sistemas están poco involucradas en la definición de la dirección
tecnológica.
Aclaraciones y/o comentarios del área responsable: No se comparte la observación ya
que la dirección tecnológica de la AFIP ha sido señalada en los respectivos planes
estratégicos. Desde hace años la estrategia está planteada hacia sistemas abiertos,
basados en servicios WEB, interactivos con los contribuyentes y usuarios internos.
La Estructura Orgánico Funcional de la Subdirección General de Sistemas y
Telecomunicaciones cuenta con un área de TI denominada Dirección de Infraestructura
Tecnológica que atiende los aspectos inherentes en la materia.
Las áreas de desarrollo van adecuando y migrando los sistemas en uso en la medida de las
respectivas posibilidades, lo que origina un diferente grado de madurez en este aspecto.
Comentario de AGN: Se mantiene la observación. Los planes de gestión anuales,
pertenecen a la Dirección de Infraestructura tecnológica. Falta un plan del más alto nivel
que defina los objetivos estratégicos de TI que involucre a todas las direcciones.
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 estará inserta en un marco de trabajo de procesos de TI que
asegura la transparencia y el control, así como el involucramiento de los altos ejecutivos de
nivel decisorio. Un comité estratégico debe garantizar la vigilancia del consejo directivo
116
sobre TI, y uno o más comités administrativos, en los cuales participan tanto los sectores
operativos 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, TI se debe involucrar en los
procesos importantes de decisión.
Este objetivo de control afecta, primariamente:

la efectividad

la eficiencia
Nivel de riesgo:
[X] Alto
[ ] Medio
[ ] Bajo
Nivel de Madurez: Definido. Existen roles y responsabilidades definidos para la
organización de TI y para terceros. La organización de TI se desarrolla, documenta,
comunica y se alinea con la estrategia de TI. Se define el ambiente de control interno. Se
formulan las relaciones con terceros, incluyendo los comités de dirección, auditoría interna
y administración de proveedores. La organización de TI está funcionalmente completa.
Existen definiciones de las funciones a ser realizadas por parte del personal de TI y las que
deben realizar los usuarios. Los requerimientos esenciales de personal de TI y experiencia
están definidos y satisfechos. Existe una definición formal de las relaciones con los
usuarios y con terceros. La división de roles y responsabilidades está definida e
implantada.
Observaciones: Existe normativa que aprueba la estructura, define responsabilidades y
roles para cada perfil hasta el nivel de división. (Anexo VI – Nota 2)
Falta segregación de funciones a los niveles inferiores, lo que provoca que las definiciones
para el personal subalterno sean difusas y poco precisas. Se depende de individuos clave
para responsabilidades específicas.
Existe una matriz de perfiles de puestos, agrupados por cada especialización, con las
competencias técnicas requeridas para cubrirlo.
117
Algunas áreas como las relativas a la administración de riesgos y aseguramiento de la
calidad no se encuentran contempladas en el organigrama.
La política utilizada para la incorporación de personal provoca que en algunas áreas exista
dependencia crítica de individuos clave por falta de agentes especializados. Esto también
limita el intercambio de conocimientos, el planeamiento de la sucesión y la posibilidad de
respaldarse o reemplazarse mutuamente. A esto se agrega que existe personal contratado
realizando tareas relevantes.
La ubicación del Departamento de Seguridad Informática dependiendo de la Dirección de
Infraestructura no es la ideal, ya que debería encontrarse en un nivel superior.
Aclaraciones y/o comentarios del área responsable: No se comparte lo observado en
cuanto a que falta segregación de funciones a los niveles inferiores, lo que provoca que las
definiciones para el personal subalterno sean difusas y poco precisas, toda vez que existen
secciones y oficinas debajo de las Divisiones con acciones y tareas definidas por
Disposiciones emitidas por el Subdirector General de Sistemas y Telecomunicaciones.
Se comparte parcialmente la observación referida a la inexistencia de un área encargada
del aseguramiento de la calidad. Al respecto se informa que cada área de desarrollo que
depende de esta Subdirección General tiene expresas funciones de control de calidad y se
encuentra reflejada estructuralmente.
Comentario de AGN: Se mantiene la observación. Se han detectado casos de falta de
segregación de funciones, entre ellos, las áreas de desarrollo, donde faltan definir niveles
inferiores de la estructura actual para permitir una mejor separación de roles y
responsabilidades.
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 y prioridades dentro del
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 los interesados, facilita el
uso efectivo y eficiente de recursos de TI, y brinda transparencia y responsabilidad dentro
118
del costo total de la propiedad, 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
presupuesto se da a conocer a los interesados. 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: Existe normativa (Anexo VI – Nota 3) que establece el marco general del
sistema presupuestario. Un área coordinadora elabora, con participación de las Áreas
Responsables, un anteproyecto de Plan de Gestión que contendrá las principales líneas de
acción y actividades previstas para el año siguiente sobre la base de los lineamientos del
Plan Estratégico de AFIP.
Además, la SDG SIT quedó comprendida por el Régimen Económico Financiero vigente
para las Direcciones Regionales Impositivas y Aduaneras, quedando en manos de la
Subdirección General de Administración Financiera la determinación de qué
contrataciones se efectuarán en forma centralizada. (Anexo VI – Nota 4)
No se ha establecido formalmente un marco de Administración Financiera de TI para
elaborar y administrar un presupuesto que refleje las prioridades establecidas en los
programas de inversión, la administración de costos
y los beneficios esperados que
permita medir la contribución de TI a los objetivos estratégicos del Organismo.
Existen iniciativas aisladas en algunas direcciones pero no se ha formalizado un
procedimiento de trabajo común a toda la SDG SIT.
119
Las áreas de Desarrollo no contemplan en la metodología de ciclo de vida de desarrollo de
sistemas, un marco de administración presupuestaria que comprenda cálculos de costos y
beneficios esperados de los desarrollos, imputaciones por centro de costos y análisis
comparativo entre lo presupuestado y lo efectivamente gastado.
Aclaraciones y/o comentarios del área responsable: Se comparte la observación
referida a que las áreas de desarrollo no contemplan en la metodología de ciclo de vida de
desarrollo de sistemas, un marco de administración presupuestaria que comprenda
cálculos de costos y beneficios esperados de los desarrollos. Al respecto se informa que se
analizará la manera de implementar la asignación de costos en las áreas de desarrollo.
No se comparte la observación referida a que no se ha establecido formalmente un marco
de administración financiera de TI para elaborar y administrar un presupuesto que refleje
las prioridades establecidas en los programas de inversión, la administración de costos y
los beneficios esperados. Al respecto se informa que anualmente se confecciona una
solicitud de presupuesto, el cual es asignado total o parcialmente de acuerdo a las
políticas y prioridades establecidas por la Administración Federal, con independencia de
atender los imprevistos y urgencias propios de la gestión del año.
Comentario de AGN: Se mantienen las observaciones. De acuerdo con la información
suministrada a esta auditoría, se reconoce la existencia de un marco de administración
financiera del organismo, pero en relación a la SDG-SIT, éste es incompleto, ya que sólo
cubre temas de infraestructura. La falta del marco presupuestario (incluyendo cálculo de
costos y beneficios esperados) de las áreas de desarrollo y mantenimiento de aplicaciones,
puede impactar en las planificaciones referidas a toda la subdirecció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
organizacional 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 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. El
proceso debe garantizar el cumplimiento de las leyes y reglamentos relevantes.
Este objetivo de control afecta, primariamente
120

la efectividad
y en forma secundaria:

el cumplimiento
Nivel de riesgo:
[ ] Alto
[X] Medio
[ ] Bajo
Nivel de Madurez: Repetible. La gerencia 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 individuales. La calidad se reconoce como una
filosofía deseable a seguir, pero las prácticas se dejan a discreción de los gerentes. El
entrenamiento se realiza de forma individual, según se lo requiera.
Observaciones: La Administración Federal de Ingresos Públicos, como entidad
autárquica, se encuentra facultada para reglamentar su funcionamiento interno, dictar
nomas reglamentarias e interpretativas de alcance general respecto de terceros y la de fijar
las políticas y criterios generales de conducción.
Existe normativa vigente (Anexo VI – Nota 5) por la cual se regulan los actos de carácter
individual y general, normativos o de ejecución, en el ámbito del Organismo, así como
también la competencia de los distintos funcionarios, ya sea originaria o delegada en que
se fundamenten los actos administrativos.
En el caso de la implantación y comunicación de políticas de TI, se implementan y/o
regulan a través de Disposiciones y/o Instrucciones Generales (Anexo VI – Nota 6). Las
mismas se encuentran disponibles para el personal del Organismo en su intranet.
Sin embargo, la ausencia de un Plan Estratégico de TI, hace difícil transmitir las políticas
de TI generales para la organización, salvo algunas iniciativas aisladas.
Aclaraciones y/o comentarios del área responsable: No hay comentarios del Organismo.
Comentario de AGN: El Organismo no realiza comentarios, por lo que se mantiene la
observación realizada.
121
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 el negocio. Esto se logra siguiendo prácticas definidas y
aprobadas que apoyan el reclutamiento, entrenamiento, la evaluación del desempeño, la
promoción y la terminación. Este proceso es crítico, ya que las personas son activos
importantes, y el ambiente de gobierno y de control interno 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: Parcialmente definido. Existe un proceso definido y documentado
para administrar los recursos humanos de TI. Existe un plan informal de administración de
recursos humanos. Existe un enfoque estratégico para la contratación y la administración
del personal de TI. El plan de entrenamiento formal está diseñado para satisfacer las
necesidades de los recursos humanos de TI. Está establecido un programa de rotación,
diseñado para expandir las habilidades gerenciales.
Observaciones: Existe normativa que regula la política de ingreso de personal, así como la
estructura organizativa de la Administración Federal de Ingresos Públicos hasta el nivel de
Subdirección General, inclusive. (Anexo VI – Nota 7)
También está definido el organigrama de la Subdirección con un detalle de los roles y
responsabilidades para cada perfil hasta nivel de división. (Anexo VI – Nota 8)
En relación a las competencias del personal, existe una matriz de perfiles de puestos,
agrupados por cada especialización, con las competencias técnicas requeridas para
cubrirlo. (Anexo VI – Nota 7)
Como resultado de un proceso de integración de distintos organismos (impositivo,
aduanero y seguridad social) persisten la convivencia de distintos convenios colectivos de
trabajo que generan asimetrías tanto administrativas como funcionales dentro de una
misma área de TI que brinda servicios a distintas Direcciones Generales.
122
La política restrictiva de incorporación de personal, provoca que:
 En algunas áreas existe dependencia crítica de individuos clave por falta de
personal especializado. Esto también limita el intercambio de conocimientos, el
planeamiento de la sucesión y la posibilidad de respaldarse o disponer una
adecuada rotación.
 Limita el establecimiento de un Plan de Carrera con movilidades ascendentes u
horizontales, que permitan a los individuos una perspectiva de desarrollo a largo
plazo. Existen concursos a niveles de jefaturas, pero no en los niveles inferiores.
También existe la posibilidad de ascender de categoría con la obtención de un título
universitario.
La política de retención del personal está basada en la estabilidad del empleo público y los
niveles salariales. Existe un riesgo latente de que si cambian estas condiciones, podría
originarse un éxodo de personal altamente especializado a otras organizaciones.
Se realizan evaluaciones de desempeño anuales, de cuyo resultado depende un incentivo
económico. El procedimiento, que está sistematizado, no contempla una evaluación de los
niveles inferiores hacia los niveles superiores. No existen mecanismos de autoevaluación.
En relación a la capacitación, el Organismo elabora un Plan de Capacitación en base a una
“Encuesta de necesidades de capacitación” que se incluyen en la confección del Plan de
Gestión Anual, no en función del Plan estratégico de la SDG SIT.
La capacitación se realiza en forma interna y externa.
Se cuenta con una herramienta de capacitación virtual denominada “Campus Virtual”
donde se deja a disposición del personal materiales referidos a distintas temáticas.
En relación a la capacitación de usuarios internos de las aplicaciones implantadas, las
denominadas “Pautas para el desarrollo y mantenimiento de sistemas informáticos en la
AFIP”, establecen los esquemas de documentación que son elaborados por las divisiones
de control de calidad de las áreas de desarrollo, que posteriormente quedan disponibles en
la página de la Dirección de Capacitación.
Aclaraciones y/o comentarios del área responsable: Se comparte parcialmente la
observación. Recientemente se han efectuado convocatorias internas para reforzar las
123
áreas de sistemas, las cuales han resultado fallidas, razón por la que se efectuó el
requerimiento de personal al área de Recursos Humanos.
No obstante lo expuesto, se ha acordado con las áreas operativas establecer en el corto
plazo la modalidad de teletrabajo para los informáticos que revistan en dichas
dependencias, quienes realizarán tareas propias de esta Subdirección General, bajo
supervisión de esta Instancia.
Comentario de AGN: Se mantienen las observaciones. Las mejoras 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 de calidad. Los requerimientos de calidad se deben manifestar y documentar con
indicadores cuantificables y alcanzables. La mejora continua se logra por medio del
constante monitoreo, corrección de desviaciones y la comunicación de los resultados a los
interesados. La administración de calidad es esencial para garantizar que TI está dando
valor a los objetivos de la organización, 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 Calidad (SAC). La administración de la calidad es
124
impulsada por individuos cuando éste ocurre. La dirección realiza juicios informales sobre
la calidad.
Observaciones: Si bien en el Plan Estratégico del Organismo se plantea la necesidad de
establecer lineamientos para desarrollar procesos de calidad, no se evidenció al momento
de esta auditoría, la existencia de políticas de calidad, un plan de calidad y/o un sistema de
administración de la misma, ni a nivel de la organización ni en la SDG SIT. No está
definida en el organigrama el área correspondiente en la SDG SIT para llevarlo a cabo.
Hay iniciativas aisladas en las direcciones de Operaciones y de Infraestructura Tecnológica
para mantener la continuidad de los servicios a niveles razonables y en las áreas de
desarrollo en la fase de homologación de aplicaciones.
Aclaraciones y/o comentarios del área responsable: Se comparte parcialmente la
observación referida a la inexistencia de un área encargada del aseguramiento de la
calidad. Al respecto se informa que cada área de desarrollo que depende de esta
Subdirección General tiene expresas funciones de control de calidad lo cual se encuentra
reflejado estructuralmente.
Comentario de AGN: Se mantienen las observaciones. Si bien existen las funciones
referidas a aseguramiento de calidad, en las áreas de desarrollo, su alcance es limitado.
Falta establecer y mantener un sistema de Administración de la Calidad que se aplique a
toda la organización de TI. El cual proporcione un enfoque estándar, formal y continuo.
Este debe incluir, entre otros:
 estándares de
o codificación de software
o normas de nomenclatura
o formatos de archivos
o diseño
o para desarrollo y pruebas.
 diccionario de datos
 interfaces de usuario
 indicadores de eficiencia y de desempeño
125
También debe contemplar la definición de las mediciones para monitorear el cumplimiento
que puedan ser usadas posteriormente por el dueño del proceso para tomar posibles
medidas correctivas.
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 del Organismo, 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: Parcialmente 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 sólo a proyectos grandes o como respuesta a problemas. Los
procesos de mitigación de riesgos están en implantación donde éstos se identifican.
Observaciones: No está definida la función correspondiente en el organigrama. Tampoco
se dispone de un marco de trabajo general de administración de riesgos de TI, integrado al
126
gobierno y el marco de control. Existen iniciativas aisladas en algunas direcciones o
departamentos que corresponden a las misiones y funciones que se fijaron para ellos.
El área de Auditoría Interna cuenta con un marco de administración de riesgos para poder
priorizar los procesos a controlar, ya que éste no es provisto por un área específica a tal fin.
El Organismo cuenta con una herramienta de Gobierno Corporativo, Administración de
Riesgos y Cumplimiento Regulatorio (GRC), pero sólo es utilizada por el área de Auditoría
Interna.
Aclaraciones y/o comentarios del área responsable: No hay comentarios del Organismo.
Comentario de AGN: El Organismo no realiza comentarios, por lo que se mantiene la
observación realizada.
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 post-implantación
para garantizar la administración de los riesgos del proyecto y la entrega de valor para el
Organismo. Este enfoque reduce el riesgo de costos inesperados y de cancelación de
proyectos, mejora la comunicación y el involucramiento de los interesados y de los
usuarios finales, asegura el valor y la calidad de los entregables de los proyectos, y
maximiza su contribución a los programas de inversión en TI.
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
127
proyectos de TI han definido objetivos técnicos y de negocio 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: No se ha normalizado un proceso de administración de proyectos que se
aplique a todas las áreas. Se utilizan distintas herramientas y distintos criterios para el
seguimiento de los proyectos, según sea el sector involucrado.
Aclaraciones y/o comentarios del área responsable: Se comparte parcialmente la
observación. Cada área de desarrollo administra sus proyectos. Se analizará la
factibilidad de la normalización de un proceso de administración de proyectos que se
aplique a todas las áreas.
Comentario de AGN: El comentario del organismo, no contradice lo expuesto en las
observaciones, por lo tanto, se mantienen las mismas. Las mejoras a realizar se evaluarán
en una próxima auditoría.
4.2. Adquirir e implementar
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 del proyecto 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 Organismo.
Este objetivo de control afecta, primariamente:

la efectividad
y en forma secundaria:

la eficiencia
128
Nivel de riesgo:
[X] Alto
[ ] Medio
[ ] Bajo
Nivel de Madurez: Parcialmente definido. Existen orientaciones claras y estructuradas
para determinar las soluciones de TI. El enfoque para la determinación de las soluciones de
TI requiere la consideración de alternativas evaluadas entre otros, contra los
requerimientos del proyecto o del usuario, las oportunidades tecnológicas, la factibilidad
económica y las evaluaciones de riesgo. El proceso para determinar las soluciones de TI se
aplica para algunos proyectos con base en factores tales como las decisiones tomadas por
el personal involucrado, la cantidad de tiempo administrativo dedicado, y el tamaño y
prioridad del requerimiento de proyecto original. Se usan enfoques estructurados para
definir requerimientos e identificar soluciones de TI.
Observaciones: Está definido el proceso de Ciclo de Vida de Desarrollo de Sistemas,
alineado a la política de seguridad, aprobada por normativa vigente. (Anexo VI – Nota 9)
Se establecen además procedimientos de interacción entre las áreas denominadas
“Definidoras” y las áreas de desarrollo de aplicaciones de la SDG SIT, cuya
documentación se encuentra formalizada en una serie de documentos entregables que
incluyen desde la definición del requerimiento de las necesidades funcionales,
determinación de los responsables tanto del área usuaria como del área informática, la
asignación de recursos y el cronograma estimado de trabajo.
Sin embargo, el procedimiento adolece de fuertes exclusiones, tales como:
e) La atención de requerimientos de mantenimiento de sistemas del tipo correctivo
originados debido a desvíos y/o errores en la programación.
f) Los desarrollos realizados para satisfacer requerimientos puntuales de información.
g) Los subcontratos o acuerdos de tercerización de software.
h) Los desarrollos realizados en carácter de pruebas de concepto como parte de tareas
de investigación.
Asimismo, la Subdirección General de Sistemas y Telecomunicaciones pueda autorizar la
no utilización de estas pautas para determinados casos.
Dada la ausencia de procedimientos para el tratamiento de situaciones de emergencia, en
estos casos se utilizan las excepciones antes mencionadas, y no contempla un
procedimiento de revisión de pistas de auditoría sobre las acciones tomadas.
129
Por otra parte, el procedimiento carece, en su etapa de evaluación preliminar, de
consideraciones relativas al análisis de factibilidad, análisis de riesgos y criterios
formalizados para la administración de prioridades, estimación de costos y beneficios
esperados que permitan la evaluación de cursos de acción alternativos, como la
tercerización del desarrollo.
Además, permite que la adopción de los documentos entregables sea a criterio de cada
división de desarrollo, mientras cumpla con los contenidos mínimos requeridos para cada
fase (definición, diseño, construcción e implementación) lo que genera que éstas hayan
adoptado un conjunto distinto de documentos. (Anexo VI – Nota 10)
En relación al entregable “REQ” (Requerimiento de Sistemas) no todas las áreas
definidoras formalizan su confección, por lo cual esta tarea suele ser hecha por las áreas de
desarrollo.
Al momento de esta auditoría se encuentra en elaboración una Instrucción General que
establecerá una nueva metodología de ciclo de vida de desarrollo de sistemas, que
reemplazará a la actual y que toma en consideración algunos aspectos aquí observados.
Aclaraciones y/o comentarios del área responsable: La IG 02/05 (SDG SIT) fue
reemplazada por la IG 05/12 (SDG SIT), la cual contempla los siguientes puntos
abarcados por la auditoría:
a) La atención de requerimientos de mantenimiento de sistemas del tipo correctivo
originados por desvíos y/o errores en la programación.
b) Los desarrollos realizados para satisfacer requerimientos puntuales de información.
d) Los desarrollos realizados en carácter de pruebas de concepto como parte de tareas de
investigación.
En el caso del punto c) “Los subcontratos o acuerdos de tercerización de software”, el
tema no es contemplado debido a que esta Administración Federal no realiza tercerización
del desarrollo.
Asimismo la IG 5/12 (SDG SIT) ahora contempla la posibilidad que la Subdirección
General de Sistemas y Telecomunicaciones pueda autorizar diferir la confección de la
documentación indicada en las pautas para casos de urgencia.
130
También en la nueva normativa, se incluye un formulario para el análisis de factibilidad y
riesgo del desarrollo.
Comentario de AGN: Durante los trabajos de campo la disposición vigente fue la IG 2/05
no así la 5/12. Por lo tanto se mantienen las observaciones realizadas. Las mejoras
planteadas en la IG 05/12 se evaluarán en una próxima auditoría.
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 elegidos. Esto permite al Organismo
apoyar la operatividad de forma apropiada con las aplicaciones correctamente
automatizadas.
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: Parcialmente definido. Existe un proceso claro, definido y de
comprensión general para la adquisición y mantenimiento de software aplicativo. Este
proceso va de acuerdo con la estrategia de TI y de la organización. Se intenta aplicar los
procesos de manera consistente a través de diferentes aplicaciones y proyectos. Las
metodologías son, por lo general, inflexibles y difíciles de aplicar en todos los casos, por lo
que es muy probable que se salten pasos. Las actividades de mantenimiento se planean,
programan y coordinan.
Observaciones: La Subdirección General de Informática y Telecomunicaciones
implementó las “Pautas para el desarrollo y mantenimiento de Sistemas Informáticos en la
AFIP” (Anexo VI – Nota 9) donde se define el proceso de Ciclo de Vida de Desarrollo de
131
Sistemas (CVDS). Las Pautas, están alineadas a la política de seguridad, aprobada
mediante “Pautas y consideraciones de seguridad a tener en cuenta en el Ciclo de Vida del
Desarrollo y Mantenimiento de Sistemas en relación con la Seguridad de la Información”.
La misma contempla documentación, aprobaciones y escalamiento en las etapas relevantes
tales como el diseño de alto nivel, el diseño detallado, fase de construcción, pruebas,
implementación y el pase a producción de aplicaciones.
Las misiones y funciones de las divisiones de Control de Calidad de las áreas de desarrollo
contemplan la etapa de aseguramiento de la calidad del software enfocada a las pruebas y a
la calidad de la documentación.
Falta incluir en la metodología de CVDS un análisis de la calidad del desarrollo del
software (Anexo VI – Nota 11) aunque existen algunas iniciativas para los desarrollos de
servicios web.
La metodología de CVDS tampoco contempla consideraciones de costos ni la posibilidad
de tercerizar el desarrollo o el mantenimiento.
Al momento de esta auditoría se encuentra en elaboración una Instrucción General que
establecerá una nueva metodología de ciclo de vida para el desarrollo de sistemas, que
reemplazará a la actual, y que toma en consideración algunos aspectos aquí observados.
En algunos casos, la contratación de servicios externos de desarrollo de sistemas se efectúa
a través de contratos con universidades, en cuyas cláusulas contractuales se estipula la
entrega de todo el software y documentación necesaria que permite al Organismo la
independencia del proveedor en tareas de mantenimiento futuro.
Aclaraciones y/o comentarios del área responsable: En la IG 5/12 (SDG SIT) se incluye
el Anexo 11, “PROCEDIMIENTO PARA EL CONTROL DE CALIDAD DE LA
DOCUMENTACIÓN DE LOS PROYECTOS DE DESARROLLO, MANTENIMIENTO Y
DISCONTINUIDAD DE SISTEMAS INFORMÁTICOS”.
Comentario de AGN: Durante los trabajos de campo la disposición vigente fue la IG 2/05
no así la 5/12. Por lo tanto se mantienen las observaciones realizadas. Las mejoras
planteadas en la IG 05/12 se evaluarán en una próxima auditoría.
132
4.2.3 Adquirir y mantener infraestructura tecnológica
Objetivo de control: El Organismo debe 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.
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: Parcialmente definido. Existe un claro, definido y generalmente
entendido proceso para adquirir y dar mantenimiento a la infraestructura de TI. El proceso
respalda las necesidades de las aplicaciones críticas de lo organización y concuerda con la
estrategia de TI, pero no se aplica en forma consistente. Se planea, programa y coordina el
mantenimiento. Existe un ambiente independiente para pruebas de factibilidad.
Observaciones: Por ser la AFIP un organismo que recibió los recursos informáticos de la
Dirección General Impositiva, la Dirección General de Aduanas y de Dirección de
Seguridad Social existe una gran diversidad de plataformas de software y de motores de
base de datos. Cuentan con algunos productos obsoletos, discontinuados por sus
fabricantes, lo que implica que carezcan de soporte.
No se encontró un plan formalmente definido para la integración efectiva de las áreas y
sistemas que permita reducir la cantidad de plataformas existentes en la actualidad.
No existe un plan de adquisición de infraestructura tecnológica formalmente definido y
aprobado. Las compras de equipamiento se realizan en función de las necesidades
detectadas y de las proyecciones a futuro de acuerdo a distintos parámetros obtenidos de
los sistemas de control instalados.
133
Existe la posibilidad que pueda producirse atraso tecnológico al momento de recepción de
equipos nuevos debido al excesivo tiempo que insume el proceso completo de compras,
desde la formulación del requerimiento hasta la recepción del producto solicitado, que
puede superar el año.
Si bien se realizan los mantenimientos adecuados a los servidores, equipos de
comunicaciones y estaciones de trabajo, no existe un procedimiento automatizado para la
instalación de actualizaciones en los sistemas operativos de computadoras personales por
carecer de una herramienta necesaria para la instalación de los mismos.
La falta de un plan de análisis de riesgo y evaluación de vulnerabilidades no permite
identificar los posibles problemas que la falta de actualización en los sistemas operativos
puedan producir.
Aclaraciones y/o comentarios del área responsable: Se comparte parcialmente lo
observado en cuanto a que no se encontró un plan formalmente definido para la
integración efectiva de las áreas y sistemas que permita reducir la cantidad de
plataformas existentes en la actualidad.
Desde el año 2011 se encuentra como una de las iniciativas del Plan de Gestión de la
AFIP, la migración de los Sistemas de la Seguridad Social, por lo cual los principales
módulos y aplicaciones de dicho ámbito, residentes en el Mainframe IBM (base de datos
D82), se ejecutarán en forma operativa en el SUN/Solaris (base de datos de la base
ORACLE).
No se comparte la observación acerca de la inexistencia de un plan de adquisición de
infraestructura tecnológica formalmente definido y aprobado, ya que existe un plan de
adquisiciones formalmente definido y en dichas compras se prevé las proyecciones a
futuro durante el periodo de vigencia de la orden de compra.
Producto de esta política, la AFIP cuenta con un centro de cómputos con la tecnología de
vanguardia, capaz de satisfacer las necesidades propias de esta Administración Federal y
de varios Organismos del estado nacional.
Se comparte parcialmente la observación referida a la posibilidad de que pueda
producirse atraso tecnológico al momento de recepción de equipos nuevos debido al
excesivo tiempo que insume el proceso completo de compras, ya que en caso de
134
obsolescencia tecnológica entre el momento de la definición del pliego y la entrega del
equipo el oferente está obligado por el pliego de bases y condiciones a entregar un
equipamiento sustituto que lo reemplaza.
Las actualizaciones de los distintos upgrade de SO o IOS, están contemplados en los
pliegos de contratación, pero su actualización es analizada caso por caso sobre todo
teniendo en cuenta el impacto en la infraestructura.
En relación a que no existe un procedimiento automatizado para la instalación de
actualizaciones en los sistemas operativos de computadoras personales, se comparte
parcialmente la observación ya que, independientemente de la compra del software de
administración de la infraestructura de Estaciones de Trabajo distribuidas en AFIP, desde
hace aproximadamente dos años se está utilizando la herramienta WSUS en alrededor de
10.000 equipos (56% del parque) para la distribución de parches de seguridad en las
estaciones de trabajo.
Comentario de AGN: El plan de Infraestructura solo contempla la sala cofre. Durante las
tareas de campo no se encontró por ejemplo un plan de renovación de PCs que asegure que
todo el parque informático se encuentre dentro de la vida útil del mismo. En consecuencia
se mantiene la observación. Las mejoras a realizar se evaluarán en una próxima auditoría.
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 TI, y
proporciona 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
135

la confiabilidad
Nivel de riesgo:
[X] Alto
[ ] Medio
[ ] Bajo
Nivel de Madurez: Repetible. Se utilizan enfoques similares para generar procedimientos
y documentación, pero no se basan en un enfoque estructural o marco de trabajo. No hay
un enfoque uniforme para el desarrollo de procedimientos de usuario y de operación.
Individuos o equipos de proyecto generan los materiales de entrenamiento, y la calidad
depende de los individuos que se involucran. Los procedimientos y la calidad del soporte
al usuario son variables, con insuficiente consistencia e integración a lo largo de la
organización. Se proporcionan o facilitan programas de entrenamiento para las áreas
decisorias y los usuarios, pero no hay un plan general para ofrecer o dar entrenamiento.
Observaciones: El Decreto 618 del 10 de julio de 1997 establece que, entre otras
facultades, que el Administrador Federal de Ingresos Públicos reglamenta el
funcionamiento interno. El artículo 4 del mismo decreto prevé la posibilidad de delegar
dichas potestades a favor de los Directores Generales y Subdirectores Generales. Estos
actos internos de carácter resolutivo son formalizados a través de la aprobación de
Resoluciones, Disposiciones o Instrucciones Generales.
La Subdirección General de Sistemas y Telecomunicaciones genera este acto
administrativo en cada política o procedimiento a aplicar. Dependiendo del alcance que se
le quiera dar, es aprobada por una jerarquía acorde.
En el caso de las áreas de desarrollo y mantenimiento de aplicaciones, las respectivas áreas
de Control de Calidad deben verificar que la documentación esté confeccionada de acuerdo
a los estándares establecidos. Sin embargo, su cumplimiento depende del criterio adoptado
por cada área.
Toda la documentación referida a disposiciones, resoluciones e instrucciones generales se
encuentra disponible para los agentes del Organismo en la intranet.
No existe un mecanismo formalmente definido para la delegación de la capacitación en las
aplicaciones a los usuarios finales, desde las áreas de desarrollo de software a la Dirección
de Capacitación.
Aclaraciones y/o comentarios del área responsable: Se comparte parcialmente la
observación, en cuanto a que la calidad de los materiales de entrenamiento depende de los
136
individuos que se involucren. En las adquisiciones de hardware y/o software se solicita
capacitación, más allá de las necesidades que cada área puede plantear.
Comentario de AGN: El organismo acepta las observaciones realizadas por lo tanto se
mantienen las mismas.
4.2.5 Adquirir recursos de TI
Objetivo de control: Se deben suministrar recursos de 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 se tengan 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:
[X] Alto
[ ] Medio
[ ] Bajo
Nivel de Madurez: Definido. Existen políticas y procedimientos para la adquisición de TI,
éstas toman como guía el proceso general de adquisición de la organización. Las compras
de TI se integran en gran parte con los sistemas generales de adquisición del Organismo.
Existen estándares de TI para la adquisición de recursos de TI. La administración de TI
comunica la necesidad de contar con una administración adecuada de adquisiciones y
contratos en toda la función de TI.
Observaciones: Las adquisiciones se llevan a cabo en el marco de administración de
proyectos y siguiendo la normativa de compras del Estado. Los procedimientos 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.
Existen además normativas internas que rigen para todas las áreas de AFIP. (Anexo VI –
Nota 12)
137
De las órdenes de compras analizadas surge que se tuvieron en cuenta los aspectos legales
y técnicos para cada contratación tales como responsabilidades y obligaciones legales,
financieras, organizacionales, de seguridad y de protección de propiedad intelectual.
La contratación de servicios externos de desarrollo de sistemas se efectúa a través de:
 Contratos con universidades, en cuyas cláusulas se estipula la entrega de todo el
software y documentación necesaria que permite al Organismo la independencia
del proveedor en tareas de mantenimiento. En algunos casos, el mantenimiento de
estos sistemas, producen una sobrecarga de trabajo a la dotación existente que no
está en condiciones de absorberlo adecuadamente.
 Personal contratado a plazo fijo. Estos contratos tienen una vigencia de tres meses y
generalmente son renovables. El agente que trabaja más de cinco años en esta
modalidad, cambia la figura a contrato por tiempo indeterminado. Esta indefinición
provoca incertidumbre en la disponibilidad de recursos para proyectos a mediano y
largo plazo.
Aclaraciones y/o comentarios del área responsable: La Subdirección General de
Planificación de la AFIP ha revisado el proyecto de Plan Estratégico de TI que fuera
conocido por esa AGN, señalando que el Plan Estratégico es Institucional. Por lo tanto
sugirió que, alineado con el mismo, se apruebe un Plan Táctico de TI, el que cubre desde
el año 2012 hasta el año 2015. El mismo ha sido enviado a la citada Subdirección General
para la formalización final de su aprobación.
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.6 Administrar cambios
Objetivo de control: Todos los cambios, incluyendo el mantenimiento de emergencia y
actualizaciones, relacionados con la infraestructura y las aplicaciones dentro del ambiente
de producción, deben administrarse formal y controladamente. Los cambios (incluyendo
procedimientos, procesos, sistemas y parámetros del servicio) se deben registrar, evaluar y
autorizar previo a la implantación y contrastar contra los resultados planeados después de
138
la misma. Esto garantiza la reducción de riesgos que impactan negativamente en 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: Parcialmente definido. Existe un proceso formal definido para la
administración de cambios, que incluye la autorización del cambio y la administración de
la liberación. Se dan soluciones temporales a los problemas y los procesos pero en
ocasiones no se cumplen. El análisis de impacto de los cambios de TI se está formalizando
para apoyar la implantación planeada de nuevas aplicaciones y tecnologías.
Observaciones: Existe una instrucción general que define el proceso de Ciclo de Vida de
Desarrollo de Sistemas para las aplicaciones desarrolladas por el Organismo (Anexo VI –
Nota 9). Esta, está alineada a la política de seguridad, y aprobada formalmente. (Anexo VI
– Nota 13)
Se contempla documentación, aprobaciones y escalamiento en las etapas relevantes tales
como el diseño de alto nivel, el diseño detallado, fase de construcción, aseguramiento de la
calidad, pruebas, implementación y liberación de aplicaciones de software.
La etapa de aseguramiento de la calidad de software está enfocada a las pruebas y a la
calidad de la documentación, no así a un análisis de la calidad del desarrollo del software.
Existen algunas iniciativas en este sentido para los desarrollos de servicios web (web
services).
Faltan procedimientos para el tratamiento de situaciones de cambios de emergencia, que
contemplen una etapa de revisión obligatoria de pistas de auditoría sobre las acciones
tomadas.
139
Se observa en la aplicación práctica de esta metodología, las mismas falencias que en los
desarrollos nuevos: falta de consideraciones de análisis de prioridades, factibilidad, riesgo,
costos y beneficios esperados. La gestión de aseguramiento de la calidad está enfocada
solamente a las pruebas.
Al momento de esta auditoría se encuentra en elaboración una Instrucción General que
establecerá una nueva metodología de ciclo de vida de desarrollo de sistemas, que toma en
consideración algunos aspectos aquí observados.
En relación a las actualizaciones de sistema operativo, existe un procedimiento formal para
su instalación.
Con respecto a las estaciones de trabajo nuevas, existe un procedimiento inicial por el cual
se entrega al proveedor el software de base (Windows XP Service Pack III, Zip central,
Adobe Reader, Adobe Flash Player, OpenOffice, Antivirus Panda) para que instale una
imagen del mismo en las máquinas a entregar. Cualquier incidente posterior es canalizado
por la Mesa de Ayuda que escala el problema de acuerdo al procedimiento del Sistema de
Registración de Incidentes (SRI).
Aclaraciones y/o comentarios del área responsable: La IG 5/12 (SDG SIT), que
reemplaza a la IG 2/05 (SDG SIT), contempla la posibilidad que la Subdirección General
de Sistemas y Telecomunicaciones pueda autorizar diferir la confección de la
documentación indicada en las pautas para casos de urgencia.
También en la nueva normativa, se incluye un formulario para el análisis de factibilidad y
riesgo del desarrollo.
Comentario de AGN: Durante los trabajos de campo la disposición vigente fue la IG 2/05
no así la 5/12. Por lo tanto se mantienen las observaciones realizadas. Las mejoras
planteadas en la IG 05/12 se evaluarán en una próxima auditoría.
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.
140
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
Nivel de riesgo:
[X] Alto
[ ] Medio
[ ] Bajo
Nivel de Madurez: Parcialmente 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 pase a
producción tienen, probablemente, variaciones respecto al proceso definido, con base en
decisiones individuales.
Observaciones: Existe una instrucción general que define las actividades a seguir para la
puesta efectiva en producción de las aplicaciones (Anexo VI – Nota 14), se incluye allí las
responsabilidades de las áreas involucradas (Control de Calidad, Soporte Técnico y Área
Definidora) y la documentación que debe generarse, con sus correspondientes
aprobaciones.
En relación a los desarrollos de servicios Web, al momento de esta auditoría se encontraba
a la firma del Administrador Federal de Ingresos Públicos una resolución general que
establece los procedimientos que deben utilizar los desarrolladores de aplicaciones de uso
propio o de terceros y que además contempla la posibilidad de que los usuarios finales,
puedan acceder al entorno de prueba (testing) y pase a producción.
Resta incluir en la metodología general un procedimiento de emergencia que abarque las
actuales exclusiones que permite esta resolución, tales como:
 La atención de requerimientos de mantenimiento de sistemas del tipo correctivo
debidos a desvíos y/o errores en la programación.
141
 Los desarrollos realizados para satisfacer requerimientos puntuales de información.
 Los subcontratos o acuerdos de tercerización de software.
 Los desarrollos realizados en carácter de pruebas de concepto como parte de tareas
de investigación.
 Casos expresamente autorizados por la SDG SIT.
El pase de los aplicativos a producción los solicitan las áreas de Control de Calidad a las
áreas de Operaciones a través de aplicativos. Este paso contempla la aprobación de las
Áreas Definidoras, aunque no en todos los casos se cumple.
La documentación de la aprobación de las etapas de pruebas no es homogénea en todos los
departamentos de desarrollo.
Aclaraciones y/o comentarios del área responsable: La IG 02/05 (SDG SIT) fue
reemplazada por la IG 05/12 (SDG SIT). La cuál contempla los siguientes puntos
abarcados por la auditoría:
- La atención de requerimientos de mantenimiento de sistemas del tipo correctivo debidos
a desvíos y/o errores en la programación.
- Los desarrollos realizados para satisfacer requerimientos puntuales de información.
- Los desarrollos realizados en carácter de pruebas de concepto como parte de tareas de
investigación.
- Casos expresamente autorizados por la SDG SIT.
Los subcontratos o acuerdos de tercerización de software no es contemplado ya que esta
Administración no contempla la contratación de servicios de desarrollo de software.
Comentario de AGN: Durante los trabajos de campo la disposición vigente fue la IG 2/05
no así la 5/12. Por lo tanto se mantienen las observaciones realizadas. Las mejoras
planteadas en la IG 05/12 se evaluarán en una próxima auditoría.
4.3. Entregar y dar soporte
4.3.1 Definir y administrar los niveles de servicio
Objetivo de control: La máxima autoridad debe definir un marco que promueva el
establecimiento de acuerdos de nivel de servicio que formalicen los criterios de desempeño
en virtud de los cuales se medirá su cantidad y calidad.
142
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: Repetible. Los niveles de servicio están acordados pero no están
controlados. Los reportes de los niveles de servicio están incompletos y dependen, en
forma individual, de las habilidades y la iniciativa de los administradores. Están
designados responsables de niveles de servicio por cada acuerdo con atribuciones
definidas, pero con autoridad limitada. Si existe un proceso para el cumplimiento de los
acuerdos de niveles de servicio es voluntario y no está debidamente implementado.
Observaciones: De la documentación recibida surge que no existe un marco de trabajo
para la administración de niveles de servicio entre las áreas usuarias y el prestador del
servicio, en este caso la Dirección de Sistemas y Telecomunicaciones.
Los acuerdos entre AFIP y distintos organismos, que proveen y reciben datos del mismo,
carecen de definiciones técnicas precisas y de penalizaciones por incumplimiento.
No existen acuerdos formalizados sobre niveles de servicio entre la Dirección de Sistemas
y Telecomunicaciones y otras áreas de la AFIP, aunque en determinados casos existen
plazos de tiempo no formales para la realización de tareas.
Aclaraciones y/o comentarios del área responsable: De acuerdo con la observación.
Comentario de AGN: El organismo acepta la observaciones realizadas por lo tanto se
mantienen las mismas.
143
4.3.2 Administrar servicios de terceros
Objetivo de control: La máxima autoridad debe implementar medidas de control
orientadas a la revisión y al monitoreo de los contratos y procedimientos existentes para
garantizar la eficacia y el cumplimiento de la política 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: 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, operacionales y de control. Se asigna la responsabilidad de
supervisar los servicios de terceros. Los términos contractuales se basan en formatos
estandarizados.
Observaciones: Los procesos de compras de bienes y servicios se realizan de acuerdo con
normativa vigente (ANEXO VI), y por las reglamentaciones emitidas por la ONTI y por
SIGEN.
Los servicios de los proveedores se encuentran identificados y formalizados por medio de
órdenes de compra.
No existe una calificación de los servicios que tome en cuenta su importancia y su
criticidad para la organización.
144
La documentación sobre las relaciones técnicas, que incluyen los roles, responsabilidades,
metas y entregables se encuentran definidas en los pliegos de compras.
Como no existe un plan de riesgos para la AFIP, no se encuentran identificados ni existen
planes de mitigación sobre los riesgos relacionados con los proveedores que garantice una
entrega segura que permita la continuidad de los servicios.
Aclaraciones y/o comentarios del área responsable: No se comparte la observación que
indica la inexistencia de una calificación de los servicios que tome en cuenta su
importancia y su criticidad para la Organización. Los Servicios de Infraestructura que
soportan el normal funcionamiento del Centro de Cómputos de esta Subdirección General
de Sistemas y Telecomunicaciones son considerados todos de alta criticidad. No obstante
los servicios se encuentran debidamente identificados y en algunos casos con rutinas de
mantenimiento planificadas desde el momento de la concepción del pliego técnico.
Para los casos de mantenimiento preventivo, cada servicio crítico posee su Planilla de
Trabajos Programados. Para los demás casos donde corresponde el mantenimiento
correctivo (equipos High End), la criticidad se indica en el establecimiento de un SLA
estricto en cuanto a los tiempos de atención y reparación.
No se comparte lo observado en cuanto a que no existe un plan de riesgos para la AFIP, ni
se encuentran identificados ni existen planes de mitigación sobre los riesgos relacionados
con los proveedores de manera que garantice una entrega segura que permita la
continuidad de los servicios.
Ello es así, ya que debido a que el proveedor del servicio de mantenimiento es asignado en
forma exclusiva por el fabricante del equipo o software, el mismo no podrá alegar
inconvenientes para la obtención del servicio mencionado, debiendo garantizar en toda
circunstancia la posibilidad de escalamiento de los eventos o la provisión de las partes de
reemplazo. En tal sentido resulta impracticable contar con prestadores alternativos y las
contrataciones se realizan en forma directa “por exclusividad” de acuerdo a lo
establecido en la Disposición N°297/03 (AFIP).
Asimismo se le exige mediante condiciones expresas en la contratación del servicio que el
personal asignado deberá ser calificado, con experiencia y conocimientos sobre el equipo,
siendo requisito además que el mismo este certificado.
145
Además, en caso que el proveedor no pudiera concretar la reparación dentro de los plazos
estipulados deberá solucionar el inconveniente mediante el reemplazo de la referida
unidad por otra en condiciones de buen funcionamiento, sin que esto implique costo
alguno para el Comprador.
Por último, cabe señalar que históricamente no ha habido inconvenientes de importancia
que hayan afectado a la totalidad de los servicios esenciales de la AFIP.
Comentario de AGN: La observación hace referencia a la inexistencia de una Evaluación
de Riesgos de la AFIP, que sumado a la falta de un Plan de Contingencia (observado en el
punto 4.3.4) no queda definido explícitamente el grado de criticidad de cada uno de los
proveedores.
Las iniciativas son independientes por falta de un plan global que contemple todos los
posibles escenarios que puedan presentarse. En consecuencia se mantiene la observación.
4.3.3 Administrar el desempeño y la capacidad
Objetivo de control: Se debe implementar un proceso de administración orientado a la
recopilación de datos, al análisis y a la generación de informes sobre el desempeño de los
recursos de Tecnología de la Información, la dimensión de los sistemas de aplicación y la
demanda de cargas de trabajo. Este proceso debe incluir el pronóstico de las necesidades
futuras, almacenamiento y contingencias, y garantizar que los recursos de información que
soportan los requerimientos del Organismo estén disponibles de manera continua.
Este objetivo de control afecta, primariamente:

la efectividad

la eficiencia
y en forma secundaria:

la disponibilidad
Nivel de riesgo:
[X] Alto
[ ] Medio
[ ] Bajo
Nivel de madurez: Administrado. Hay procesos y herramientas disponibles para medir el
uso del sistema, el desempeño y la capacidad, y los resultados se comparan con metas
definidas. Hay información actualizada disponible, que brinda estadísticas estandarizadas y
alerta sobre incidentes causados por falta de desempeño o de capacidad. Los problemas
146
que aparezcan se enfrentan de acuerdo con procedimientos definidos y estandarizados. Se
utilizan herramientas automatizadas para monitorear recursos específicos tales como
espacio en disco, servidores y la electrónica de las redes. Las estadísticas de desempeño y
capacidad son reportadas en términos de los procesos del Organismo.
Observaciones: Se realiza el monitoreo de parámetros tales como capacidad, desempeño,
ambientales del centro de cómputos y el funcionamiento del sistema de energía eléctrica,
estado de las UPS y del sistema de alarma contra incendios.
Los datos obtenidos de los sistemas de control alimentan dos herramientas (PATROL y
TMART) que permiten obtener estadísticas que se utilizan para prever las necesidades
futuras del Organismo la organización.
Los dispositivos de control informan automáticamente cualquier desviación no esperada
emitiendo alarmas a los operadores y enviando mensajes a los teléfonos celulares de los
responsables de las áreas involucradas.
Se almacenan los logs de todos los incidentes, y se confeccionan estadísticas de desempeño
semanal y mensual.
La seguridad de los sistemas del Organismo es controlada por la División Monitoreo y
Detección que depende Departamento de Seguridad Informática de la Dirección de
Infraestructura Tecnológica. Para ello se analizan los datos de las siguientes herramientas:
 Firewall Central de Red
 IPS (Intrusion Prevention Systems – Sistemas de prevención de intrusión)
 IDS (Intrusion Detection Systems – Sistemas de detección de intrusión)
 Proxy
 Firewalls Departamentales
 WAF (Detección en línea de intrusiones)
 Análisis de Aplicaciones WEB
Se emiten alertas según parámetros establecidos y se realizan reportes sobre la cantidad de
eventos que se producen.
El monitoreo de los sistemas de comunicaciones lo realiza la División Gestión de Redes
que se ocupa de controlar el tráfico de las redes LAN, MAN, WAN, satelital y WiFi. Este
147
control se realiza con herramientas propias y con aplicaciones suministradas por los
proveedores.
Aclaraciones y/o comentarios del área responsable: De acuerdo con lo observado.
Comentario de AGN: El organismo acepta las observaciones realizadas por lo tanto se
mantienen las mismas.
4.3.4 Garantizar la continuidad del servicio
Objetivo de control: Se requiere desarrollar, mantener y probar planes para asegurar la
continuidad de servicio. Al respecto, se debe almacenar respaldos fuera de las instalaciones
y brindar entrenamiento periódico.
Este objetivo de control afecta, primariamente:

la efectividad

la disponibilidad
y en forma secundaria:

la eficiencia
Nivel de riesgo:
[X] Alto
[ ] Medio
[ ] Bajo
Nivel de madurez: Repetible. Se asigna la responsabilidad para mantener la continuidad
del servicio. Los enfoques para asegurar la continuidad están fragmentados. No hay un
plan de continuidad de TI documentado, aunque hay compromiso para mantener disponible
la continuidad del servicio y sus principios más importantes se conocen. Existe un
inventario de sistemas y componentes críticos, pero puede no ser confiable. Las prácticas
de continuidad en los servicios emergen, pero el éxito depende de los individuos.
Observaciones: No existe un Plan de Continuidad de Servicios que contemple todos los
posibles escenarios que puedan presentarse. Actualmente se encuentra en proceso de
definición la realización de un estudio de análisis de riesgo que servirá como base para
redacción del Plan de Continuidad.
No existe un sitio alternativo de procesamiento.
Aclaraciones y/o comentarios del área responsable: Se comparte parcialmente lo
observado.
En los últimos años la Subdirección General de Sistemas y Telecomunicaciones ha
148
desarrollado una importante cantidad de medidas y proyectos tendientes a garantizar la
continuidad de los servicios Informáticos de la AFIP, minimizando los riesgos producidos
por factores externos o del contexto inherentes a los sistemas informáticos, entre los que
se incluye la implementación de la sala Cofre, la instalación de motogeneradores, de
equipos de provisión de energía ininterrumpida, de sistemas de video vigilancia, etc.
Todas ellas resultan soluciones necesarias para enfrentar distintos tipos de eventos como
por ejemplo falta de suministro eléctrico, incendios, humedad, ataques por
radiofrecuencia, magnetismo, etc.,
Realizar estas actividades significó haber avanzado fuertemente en la prevención y
mitigación de incidentes de bajo impacto operativo pero de una probabilidad de
ocurrencia muy alta. Por ejemplo, en caso de una falta de suministro eléctrico prolongado
el Sistema es capaz de mantener operativo el Centro de Cómputos por 18 horas a plena
carga y hasta 36hs con las actuales condiciones de consumo. No obstante con un
suministro continuo de combustible, la operatoria puede considerarse ininterrumpible.
En el último trimestre del año 2012, mediante la Disposición N° 186/12, se creó una
Comisión dependiente de esta Subdirección General para redactar un informe que
considere los factores que intervendrían para dar continuidad a la operación de los
servicios informáticos ante un eventual colapso total o parcial de la operatoria.
Para la elaboración de dicho informe la Comisión ha considerado los diversos
antecedentes y documentos confeccionados en esta Subdirección General relacionados
con el tema, Informes de la Dirección de Infraestructura Tecnológica y también se ha
seguido la Guía de Desarrollo del Plan de Continuidad de Negocio presentada como tesis
en la Escuela Universitaria de Informática de la Universidad Politécnica de Madrid. En
todos esos documentos se recomienda que el desarrollo del Plan de la AFIP debería ser
concretado en un Plan de Gestión plurianual, estimando su realización en 4 fases:
1.- Análisis de impacto y de riesgos.
11.- Selección de la estrategia.
111.- Desarrollo del plan para la continuidad de operación de los servicios.
IV.- Pruebas y mantenimiento del plan.
149
Comentario de AGN: El organismo reconoce la falta de un Plan de Continuidad de
Servicios con la creación de una Comisión (mediante la disposición 186/12) que se
ocupará de redactar un informe que analice los factores intervinientes.
La creación de la mencionada comisión es posterior al periodo auditado y su trabajo será
motivo de una posterior auditoria.
En consecuencia se mantiene la observación.
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 la
implementación de los controles de acceso lógico que garantizan que el ingreso a los
sistemas, datos y programas está limitado a los usuarios autorizados, los monitoreos y
pruebas periódicas así como acciones correctivas sobre las debilidades o incidentes
identificados.
Este objetivo de control afecta, 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: Administrado. Las responsabilidades sobre la seguridad de TI son
asignadas, administradas e implementadas de forma clara. Regularmente se lleva a cabo un
análisis de impacto y de riesgos de seguridad. Las políticas y prácticas de seguridad se
complementan con referencias específicas de seguridad. El contacto con métodos para
promover la conciencia de la seguridad es obligatorio. La identificación, autenticación y
autorización de los usuarios está estandarizada. La certificación en seguridad es buscada
150
por parte del personal que es responsable de la auditoría y la administración de la
seguridad. Las pruebas de seguridad se hacen utilizando procesos estándares y formales
que llevan a mejorar los niveles de seguridad. Los procesos de seguridad de TI están
coordinados con la función de seguridad de toda la organización. Los reportes de seguridad
están ligados con los objetivos del Organismo.
La capacitación sobre seguridad de TI se planea, administra e imparte para todo el
Organismo de manera que responda a las necesidades del mismo y a los perfiles de riesgo
de seguridad.
Observaciones: La administración de la seguridad de los sistemas está a cargo del
Departamento de Seguridad Informática que depende de la Dirección de Infraestructura
Tecnológica. Este departamento está dividido en dos Divisiones:
 Monitoreo y Detección
 Administración de Accesos
No tiene bajo su responsabilidad la seguridad física de la sala cofre donde se encuentran
los servidores del Organismo.
Existe un Comité de Seguridad compuesto por los titulares de las direcciones interesadas y
presidido por la Subdirección General de Sistemas y Telecomunicaciones.
La posición actual del Departamento de Seguridad Informática no se considera la más
apropiada dentro de la organización porque depende de la Dirección de Infraestructura
Tecnológica y esta situación podría influir en un correcto impacto horizontal hacia todo el
Organismo de las decisiones tomadas por el citado departamento.
Existe un Manual aprobado de Políticas de Seguridad de la Información. Desde su
publicación no existieron revisiones ni modificaciones. Las actualizaciones o ampliaciones
de su contenido se realizan mediante Instrucciones Generales que son impulsadas y
aprobadas por el Comité de Seguridad de la Información.
Los usuarios acceden a las distintas aplicaciones a través del Sistema Único de
Autenticación, este es un sistema que permite que el usuario sólo necesite autenticarse una
vez para acceder a los sistemas que tiene autorizados. Este está vinculado con el sistema
SARHA de administración de RR HH.
151
Se contemplan también las situaciones de baja de personal, licencias ordinarias y traslado
de dependencias.
Aclaraciones y/o comentarios del área responsable: Existen revisiones de las Políticas
de Seguridad de la Información que son las que originan las actualizaciones o
ampliaciones de su contenido, concretadas a través de Instrucciones Generales.
Con respecto a la seguridad física de la sala cofre, el Departamento Seguridad
Informática administra los accesos, mientras que por cuestiones operativas, la seguridad
física de la Sala es administrada por la Dirección de Operaciones Informáticas. Personal
dependiente de esta Dirección trabaja físicamente en modalidad 7x24 en el área contigua
a la Sala Cofre, y realiza el monitoreo en tiempo real de la Sala y de su infraestructura.
Comentario de AGN: La respuesta del organismo no modifica las observaciones
realizadas, por lo tanto se mantienen las mismas.
4.3.6 Identificar y asignar costos
Objetivo de control: Se debe implementar un sistema de imputación de costos que
garantice que se registren, calculen y asignen los costos de acuerdo con el nivel de detalle
requerido y el ofrecimiento de servicio adecuado.
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.
Este objetivo de control afecta, primariamente:

la eficiencia

la confiabilidad
Nivel de riesgo:
[X] Alto
[ ] Medio
[ ] Bajo
Nivel de madurez: Repetible. Hay conciencia general de la necesidad de identificar y
asignar costos. La asignación de costos está basada en los del hardware. No hay
capacitación o comunicación formal sobre la identificación de costos estándar y sobre los
procedimientos de asignación. No está determinada la responsabilidad sobre la
recopilación o la asignación de los costos, particularmente del software desarrollado.
Observaciones: Los costos de TI asociados al desarrollo de sistemas no son identificados
para ser imputados a las áreas correspondientes.
152
Los costos de los servicios de TI no están vinculados a los procesos del Organismo, no
existe un modelo definido para la asignación de los mismos. Solamente se imputan a las
áreas respectivas aquellos vinculados a las compras de hardware que patrimonialmente
queden a su cargo.
Aclaraciones y/o comentarios del área responsable: Se comparte la observación. Se
analizará la manera de presupuestar los costos de desarrollo
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.3.7 Educación y capacitación de los usuarios
Objetivo de control: Se debe establecer y mantener un plan integral de capacitación y
desarrollo. Para ello, se requieren identificar las necesidades de entrenamiento de cada
grupo. Además, este proceso debe incluir la definición y ejecución de una estrategia para
llevar a cabo un entrenamiento efectivo y para medir los resultados.
Este objetivo de control afecta, primariamente:

la eficacia
y en forma secundaria:

la eficiencia
Nivel de riesgo:
[X] Alto
[ ] Medio
[ ] Bajo
Nivel de madurez: Definido. El programa de entrenamiento y educación se
institucionaliza y comunica, y los empleados y gerentes identifican y documentan las
necesidades de entrenamiento. Los procesos de entrenamiento y educación se estandarizan
y documentan. Para soportar el programa de entrenamiento y educación, se establecen
presupuestos, recursos, instructores e instalaciones. Se imparten clases formales sobre
conducta ética y sobre conciencia y prácticas de seguridad en los sistemas. La mayoría de
los procesos de entrenamiento y educación son monitoreados, pero no todas las
desviaciones son susceptibles de detección por parte de la gerencia. El análisis sobre
problemas de entrenamiento y educación sólo se aplica de forma ocasional.
Observaciones: El relevamiento de las necesidades de capacitación y de la organización
de los distintos cursos es responsabilidad de la Dirección de Capacitación.
153
La recolección de las necesidades de capacitación de las distintas áreas del Organismo se
realiza mediante encuestas automatizadas
Se otorgan becas para capacitar externamente a los agentes (el capacitado de dictar cursos
de lo aprendido a solicitud del Organismo), y se contratan cursos de capacitación con los
proveedores cuando se adquiere nueva infraestructura. La capacitación interna se realiza
con personal propio, y se dictan cursos por medio de procedimientos WEB utilizando una
herramienta llamada CAMPUS.
En las áreas de desarrollo se notó falta de cursos de alto nivel para los agentes con mayor
capacidad técnica. En estas mismas áreas la cantidad acotada de personal no permite que el
mismo pueda dedicar las horas necesarias para capacitación.
Aclaraciones y/o comentarios del área responsable: No se comparte lo observado. En
los pliegos de compra de software está prevista la capacitación para el personal de esta
Subdirección General.
Asimismo las necesidades de capacitación de las distintas áreas de esta Subdirección
General son canalizadas a través de la Dirección de Infraestructura Tecnológica, quien se
encarga de adquirir la capacitación acorde a las necesidades funcionales.
Comentario de AGN: Si bien en los pliegos de compra de software está prevista la
capacitación, no existen ni se planifican capacitaciones posteriores que permitan mantener
o aumentar las competencias del personal.
En consecuencia se mantiene las observaciones.
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 causaraí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, primariamente:
154

la efectividad

la eficacia
Nivel de riesgo:
[X] Alto
[ ] Medio
[ ] Bajo
Nivel de madurez: Definido. Se reconoce y se acepta la necesidad de contar con una
función de mesa de servicio y un proceso para la administración de incidentes. Los
procedimientos se estandarizan y documentan, pero se lleva acabo entrenamiento informal.
Se deja la responsabilidad al individuo de conseguir entrenamiento y de seguir los
estándares. Se desarrollan guías de usuario y preguntas frecuentes (FAQs), pero los
individuos deben encontrarlas y puede ser que no las sigan. Las consultas y los incidentes
se rastrean de forma manual y se monitorean de forma individual, pero no existe un
sistema formal de reporte. No se mide la respuesta oportuna a las consultas e incidentes.
Los usuarios han recibido indicaciones claras de dónde y cómo reportar problemas e
incidentes.
Observaciones: La función la realiza en su mayor parte la División Mesa de Ayuda que
depende del Departamento de Soporte Técnico.
Para el registro de los incidentes se utiliza una herramienta llamada Sistema de
Registración de Incidentes (SRI). Estos pueden llegar vía telefónica, o por correo
electrónico. En ambos casos el sistema genera un ticket con un número único para su
identificación.
Si es resuelto en el momento, el incidente es cerrado por el operador, si este no lo puede
resolver puede consultarlo al personal con mayor experiencia sobre el tema, y si aún así no
puede ser resuelto se deriva el mismo al área que corresponda. Al recibir la conformidad,
el operador cierra el ticket.
Si bien el sistema SRI puede discriminar cada ticket por importancia, esta clasificación no
es utilizada para asignar un orden en la resolución de incidentes, sino que son resueltos a
medida que ingresan al sistema.
En el sistema no queda almacenada la conformidad del usuario sobre la solución del
incidente.
155
El sistema almacena información sobre distintos parámetros que permiten realizar informes
sobre el desempeño de la Mesa de Ayuda, pero los mismos sólo se realizan si son
solicitados con algún fin específico.
No se realizan encuestas de satisfacción del usuario.
Aclaraciones y/o comentarios del área responsable: Se comparte parcialmente lo
observado en cuanto a que si bien el sistema SRI puede discriminar cada ticket por
importancia, esta clasificación no es utilizada para asignar un orden en la resolución de
incidentes, sino que son resueltos a medida que ingresan al sistema.
Se posee una clasificación de los eventos críticos los cuales tienen prioridad de resolución
(ej. Virus, Factura Electrónica, Osiris), utilizándose dicha prioridad para el tratamiento
de los incidentes.
Además, se consideran los eventos repetitivos que aluden a un único inconveniente
producido por la salida de servicios de un sistema. Los mismos son cerrados en forma
general al solucionarse el inconveniente.
También se comparte parcialmente lo observado en relación a que en el sistema no queda
almacenada la conformidad del usuario sobre la solución del incidente.
No está como condición obligatoria previa al cierre del ticket la conformidad del usuario,
ya que ante eventos generales de alta repetición, se consulta una muestra de casos y se
procede al cierre del resto. En la mayoría de los casos relacionados a eventos
particulares, la conformidad queda en la interacción con los usuarios. Por último, la Mesa
de Ayuda realiza un chequeo de los tickets que aun no fueron cerrados por los usuarios
solicitando su conformidad para el cierre.
En caso de no recibir respuesta se procede a cerrarlos de oficio pasados los 90 días.
No se comparte lo observado en cuanto a que el sistema almacena información sobre
distintos parámetros que permiten realizar informes sobre el desempeño de la Mesa de
Ayuda, pero los mismos sólo se realizan si son solicitados con algún fin específico.
Los informes estadísticos gerenciales sobre el desempeño de la Mesa de Ayuda, se
encuentran disponibles en forma on-line para nivel de Departamento y de Dirección. Cabe
156
señalar que, este método reemplazó a los informes en papel que eran emitidos de manera
periódica.
Comentario de AGN: El organismo acepta que no utiliza la discriminación de cada ticket
según la clasificación disponible en el SRI. Durante las tareas de campo no se encontró
evidencia de un procedimiento formal de asignación de prioridad de solicitudes. Reconoce
además que para el cierre del ticket no es condición necesaria la aprobación del usuario
sobre la resolución del mismo.
En consecuencia se mantiene la observación.
4.3.9 Administrar la configuración
Objetivo de control: Se deben implementar controles que identifiquen y registren todos
los bienes de Tecnología de la Información y su ubicación física, y un programa de
verificación regular que confirme su existencia. Este programa debe incluir 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.
Este objetivo de control afecta, primariamente:

la efectividad
y en forma secundaria:

la eficiencia

la disponibilidad

la confiabilidad
Nivel de riesgo:
[X] Alto
[ ] Medio
[ ] Bajo
Nivel de madurez: Definido. Los procedimientos y las prácticas de trabajo se han
documentado, estandarizado y comunicado, pero la capacitación y la aplicación de
estándares dependen del individuo. Además se han implementado herramientas de
administración de configuración entre plataformas. Es poco probable detectar las
desviaciones de los procedimientos y las verificaciones físicas se realizan de manera
inconsistente. Se lleva a cabo algún tipo de automatización para ayudar a rastrear cambios
157
en el software o en el hardware. La información de la configuración es utilizada por los
procesos interrelacionados.
Observaciones: Con respecto al parque informático de PC de usuarios, existen dos
ámbitos bien diferenciados, por un lado todos los equipos ingresados al dominio de la
AFIP (aproximadamente un 80%) y por otro los que están fuera de él ubicados
principalmente el edificio de Hipólito Yrigoyen (aproximadamente 370 equipos).
No existe una herramienta que permita monitorear cambios en el software instalado de las
estaciones de trabajo. Tampoco existe una herramienta que permita actualizar los sistemas
operativos de forma automática.
Los equipos nuevos son entregados con una configuración que le es entregada al proveedor
para que él mismo las instale. Si bien en la actualidad los usuarios de dominio no tienen
privilegios de administración de sus equipos, los que están fuera de él podrían tener estos
privilegios, lo que tendría como consecuencia la falta de control del software instalado en
los mismos.
No existen mecanismos físicos que impidan el reemplazo de componentes internos de las
estaciones de trabajo por personal no autorizado.
Aclaraciones y/o comentarios del área responsable: Se comparte parcialmente lo
observado en cuanto a que en relación al parque informático de PCs de usuarios, existen
dos ámbitos bien diferenciados, por un lado todos los equipos ingresados al dominio de la
AFIP (aproximadamente un 80%) y por otro los que están fuera de él ubicados
principalmente en el edificio de Hipólito Irigoyen (aproximadamente 370 equipos).
Actualmente el parque de equipamiento ingresado a dominio alcanza al 86%. En cuanto a
los equipos que están ubicados en el Edificio de Hipólito Yrigoyen (370 equipos),
entendemos que se trata de un error de tipeo (Hipólito Yrigoyen 370 es la dirección del
edificio central).
También se comparte parcialmente lo observado en relación a:
- Inexistencia de una herramienta que permita monitorear cambios en el software
instalado de las estaciones de trabajo
- Inexistencia de una herramienta que permita actualizar los sistemas operativos de forma
automática.
158
- Los equipos nuevos son entregados con una configuración que le es entregada al
proveedor para que él mismo las instale. Si bien en la actualidad los usuarios de dominio
no tienen privilegios de administración de sus equipos, los que están fuera de él podrían
tener estos privilegios, lo que tendría como consecuencia la falta de control del software
instalado en los mismos.
Desde hace dos años se está utilizando la herramienta WSUS en aproximadamente 10.000
equipos (56% del parque) para la distribución de parches de seguridad en las estaciones
de trabajo.
Por otra parte se encuentra en proceso de adquisición el software de administración de la
infraestructura de estaciones de trabajo distribuidas en AFIP. Una vez implementada, y en
conjunto con la disponibilidad de dominio en la totalidad de los equipos AFIP, se podrá
realizar la instalación de software en forma centralizada aplicando políticas comunes.
El mismo software permitirá registrar cualquier cambio o modificación de componentes
de HW realizado en el equipo.
Comentario de AGN: Si bien AFIP está trabajando en la regularización de la situación del
parque informático, hay un porcentaje alto de equipos que todavía no cuentan con las
herramientas mencionadas. En consecuencia se mantiene la observación. Las mejoras a
realizar se evaluarán en una próxima auditoría.
4.3.10 Administración de problemas
Objetivo de control: Se debe implementar un sistema de administración de problemas que
registre y de respuesta a todos los incidentes. El proceso 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.
Este objetivo de control afecta, primariamente:

la eficacia

la eficiencia
y en forma secundaria:

la disponibilidad
Nivel de riesgo:
[X] Alto
[ ] Medio
[ ] Bajo
159
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 capacitación. Se estandarizan los procesos de escalamiento y
resolución de problemas. El registro y rastreo de problemas y de 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 de identificación y resolución de problemas son limitados e
informales.
Observaciones: Los problemas son reportados por los usuarios por medio de llamadas
telefónicas o a través de correos electrónicos a Mesa de Ayuda donde el operador genera
un ticket.
La División de Mesa de Ayuda no tiene un segundo nivel de escalamiento de problemas,
sino que cuenta con referentes. Los incidentes que pueden presentarse son derivados a las
áreas correspondientes cuando los operadores no pueden resolverlos. De esta forma se
recargan las tareas de sectores como los de desarrollos que deben dedicar personal y
recursos para actividades que no figuran en sus misiones y funciones.
La aceptación de la solución del problema la realiza el usuario por medio de un correo
electrónico no quedando dicha constancia en el SRI.
El cierre del ticket en el sistema lo realiza el operador en forma manual cuando recibe el
correo electrónico de parte del usuario con la aprobación de la solución brindada.
Aclaraciones y/o comentarios del área responsable: Se comparte parcialmente lo
observado en cuanto a que los problemas son reportados por los usuarios por medio de
llamadas telefónicas o a través de correos electrónicos a Mesa de Ayuda donde el
operador genera un ticket. Si el usuario llama por teléfono es el operador quien genera el
ticket; en el caso en que envíen un correo electrónico a la cuenta [email protected] es el
propio sistema SRI el que genera el ticket en forma automática.
También se comparte parcialmente lo observado en relación a que la División de Mesa de
Ayuda no tiene un segundo nivel de escalamiento de problemas, sino que cuenta con
referentes; y que los incidentes que pueden presentarse son derivados a las áreas
160
correspondientes cuando los operadores no pueden resolverlos, recargando las tareas de
sectores como los de desarrollo que deben dedicar personal y recursos para actividades
que no figuran en sus misiones y funciones.
Al respecto se aclara que la División Mesa de Ayuda tiene segundo nivel de escalamiento
de problemas. Asimismo, el Organismo se encuentra en un proceso de madurez que
permitirá a la Mesa de Ayuda reducir el escalamiento de eventos, lo que se lograría
manteniendo actualizada la base de conocimientos, por parte de las distintas áreas de
servicio y manteniendo capacitados a los agentes de la citada Mesa de Ayuda con los
nuevos proyectos, sistemas o normativas.
No se comparte lo observado en cuanto a que la aceptación de la solución del problema la
realiza el usuario por medio de un correo electrónico no quedando dicha constancia en el
SRI.
Todos los usuarios tienen habilitado por default el sistema SRI, por lo que cada uno de
ellos puede crear o cerrar un evento dentro del mismo. Asimismo, el usuario puede cerrar
el evento enviando una respuesta indicando en el asunto el nro. de ticket, el cual es
tomado por el sistema, registrando el cierre en forma manual. En ambas situaciones, la
aceptación de la solución del problema queda registrada en el SRI.
Comentario de AGN: El organismo reconoce en su respuesta al punto 4.3.8 que “No está
como condición obligatoria previa al cierre del ticket la conformidad del usuario…”. Por lo
tanto se mantienen las observaciones.
4.3.11 Administración de Datos
Objetivo de control: La máxima autoridad debe establecer y mantener una combinación
eficaz de controles generales y de aplicación sobre las operaciones de Tecnología de la
Información para asegurar que los datos permanezcan durante su entrada, actualización y
almacenamiento completos, precisos y válidos. 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.
Este objetivo de control afecta, primariamente:
161

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 la administración de los datos. Se asigna la propiedad sobre los datos
a la parte responsable que controla la integridad y la seguridad. Los procedimientos de
administración de datos se formalizan dentro de TI y se utilizan algunas herramientas para
respaldos/recuperación y desecho de equipo. Se lleva a cabo algún tipo de monitoreo sobre
la administración de datos. 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 internos esta formalmente asignada a las áreas
definidoras
No existe un diccionario de datos del Organismo, ni están definidos sus niveles de
criticidad.
En los casos en que se verifica que los archivos de datos recibidos de otros organismos
contengan errores, se solicita que sean reenviados. En aquellos casos en que el archivo
reenviado tenga el mismo nombre que el recibido con errores, se guarda en el repositorio
agregándole un sufijo secuencial para diferenciarlo del primero. No está definido
formalmente el tiempo que dichos archivos con datos erróneos deben permanecer en el
repositorio.
Aclaraciones y/o comentarios del área responsable: El 10 de enero de 2013 se puso en
producción un servicio interactivo, al que se accede a través del SUA (Sistema Único de
Autenticación), denominado Clasidat cuyo objetivo es la documentación, descripción y
clasificación de la Información estructurada en bases de datos.
Este servicio fue desarrollado para cumplir con la IG N° 5/12 (AFIP) de Clasificación de
la Información.
Tal como se indica en la mencionada IG, las áreas definidoras de sistemas y procesos de
información en conjunto con las áreas que desarrollan los mismos, utilizarán Clasidat
162
para identificar cada instancia de base de datos, las tablas que las componen y sus
campos, indicando tanto su descripción como su criticidad.
Comentario de AGN: Se mantienen las observaciones. Para el período auditado, no se
encontraba vigente la IG N° 5/12 (AFIP) ni la implementación del sistema “Clasidat”. Las
mejoras expresadas se evaluarán en una próxima auditoría.
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. Se deben instalar controles ambientales y
físicos adecuados cuya revisión se efectúe periódicamente a fin de determinar su correcto
funcionamiento.
Este objetivo de control afecta, primariamente:

la integridad

la disponibilidad
Nivel de riesgo:
[X] Alto
[ ] Medio
[ ] Bajo
Nivel de madurez: Definido. Se entiende y acepta a lo largo de todo el Organismo la
necesidad de mantener un ambiente de cómputo controlado. Los controles ambientales, el
mantenimiento preventivo y la seguridad física cuentan con presupuesto autorizado y
verificado por la gerencia. Se aplican restricciones de acceso, permitiendo el ingreso a las
instalaciones de cómputo sólo al personal autorizado. Los visitantes son acompañados. Las
instalaciones físicas mantienen un perfil bajo y no son reconocibles de manera sencilla. Las
autoridades monitorean el cumplimiento con los reglamentos de salud y seguridad.
Observaciones: La AFIP dispone de una sala cofre donde se almacenan los servidores y
equipos de comunicaciones principales. La misma se encuentra sellada y protege a todos
los equipos contra incendios, humo, gases corrosivos, interferencias electromagnéticas,
filtraciones, accesos indebidos, etc.
Si bien el acceso a la sala cofre se controla mediante el uso de una tarjeta magnética y un
dispositivo de lectura de huellas dactilares, no se observó la existencia de un registro de
visitantes al centro de cómputos.
163
El Organismo cuenta con 3 generadores autónomos y 2 sistemas de UPS independientes
que permiten el funcionamiento de todo el centro de cómputos en el caso de falta de
suministro de energía eléctrica.
Todos los parámetros físicos del centro de cómputos (energía, humedad, temperatura, etc.)
se encuentran monitoreados en forma permanente.
El Organismo no dispone de un sitio alternativo de procesamiento para el caso en que el
centro de cómputos deje de operar.
No existe un plan de contingencia que indique los procedimientos necesarios para los
distintos escenarios que puedan presentarse.
Aclaraciones y/o comentarios del área responsable: Si bien al momento de la auditoría
no existía un registro de visitantes al Centro de Cómputos, se ha elaborado un instructivo
que se encuentra a la firma y contempla la registración de las personas que visitan el Data
Center.
En cuanto a lo observado en relación al sitio alternativo y al Plan de Contingencia, se
remite a lo informado en el punto 4.3.4 precedente.
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.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 involucrado. 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.
Este objetivo de control afecta primariamente:

la efectividad

la eficiencia
y en forma secundaria:

la integridad

la disponibilidad
164
Nivel de riesgo:
[X] Alto
[ ] Medio
[ ] Bajo
Nivel de madurez: Administrado. Las operaciones de cómputo y las responsabilidades de
soporte están definidas de forma clara y la propiedad está asignada. Las operaciones se
soportan a través de presupuestos de recursos para gastos de capital y de recursos
humanos. La capacitación se formaliza y está en proceso. Las programaciones y las tareas
se documentan y comunican, tanto a la función interna de TI como a los usuarios. Es
posible medir y monitorear las actividades diarias con acuerdos estandarizados de
desempeño y de niveles de servicio establecidos. Cualquier desviación de las normas
establecidas es atendida y corregida de forma rápida. La gerencia monitorea el uso de los
recursos de cómputo y la terminación del trabajo o de las tareas asignadas. Existe un
esfuerzo permanente para incrementar el nivel de automatización de procesos como un
medio de mejora continua. Se establecen convenios formales de mantenimiento y servicio
con los proveedores. Hay una completa alineación con los procesos de administración de
problemas, capacidad y disponibilidad, soportados por un análisis de causas de errores y
fallas.
Observaciones: Las tareas que comprenden al procesamiento son realizadas por la
División de Operación de Sistemas que depende del Departamento de Operaciones.
Los procedimientos se encuentran definidos formalmente por una Instrucción General que
aprueba el Calendario Operativo de Gestión en el cual se establecen las frecuencias y
parámetros de las tareas a realizar.
Existen procedimientos formalmente definidos para el monitoreo de la infraestructura de
TI, y para el control de los eventos que se produzcan. Mediante herramientas de monitoreo
(PATROL y TMART) se controlan todos los parámetros necesarios (uso de memoria,
espacio en disco, servicios en línea, parámetros ambientales, sistema de energía, etc.) para
un correcto funcionamiento del centro de cómputos.
La División Control de Datos y Procesos se encarga del pase a producción de la
información recibida de organismos externos (ANSES, Banco Nación, etc.) controlando la
integridad de la información recibida y poniéndola disponible para su procesamiento.
Aclaraciones y/o comentarios del área responsable: De acuerdo con lo observado.
165
Comentario de AGN: El organismo acepta las observaciones realizadas por lo tanto se
mantienen las mismas.
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 definido formalmente. Éste debe incluir la definición de indicadores
de desempeño relevantes, reportes sistemáticos y oportunos y tomar medidas expeditivas
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.
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: Repetible. Se han identificado algunas mediciones básicas a ser
monitoreadas. Los métodos y las técnicas de recolección y evaluación existen, pero los
procesos no se han adoptado en todo el Organismo. La interpretación de los resultados del
monitoreo se basa en la experiencia de individuos clave. Herramientas limitadas son
seleccionadas y aplicadas en algunas áreas para recolectar información, pero esta
recolección no se basa en un enfoque planeado.
Observaciones: Existen diferencias en el monitoreo de TI según el sector de que se trate.
En las áreas de desarrollo y mantenimiento de software no se ha normalizado un proceso
de administración de proyectos que sea común a todas. Se utilizan distintas herramientas y
criterios para el seguimiento de los proyectos.
166
La metodología de Ciclo de Vida de Desarrollo de Sistemas vigente permite la adopción de
documentación entregable a criterio de cada área de desarrollo. Esto impide la uniformidad
de información, y la documentación realizada difiere en estructura y calidad, según el
sector de que se trate.
La ausencia de un marco de trabajo de aseguramiento de la calidad, basado en estándares
predefinidos, no permite mediciones de desempeño, que sean obtenidas mediante la
generación de indicadores, provenientes de diversos puntos de control interno, en los
procesos de desarrollo.
En las áreas dependientes de la Dirección de Infraestructura, se ha establecido un
monitoreo en tiempo real, con estándares de desempeño preestablecidos empleando
herramientas automáticas. Los resultados obtenidos se utilizan para tomar acciones
preventivas o correctivas según el caso.
Los niveles de servicios los ha definido la Subdirección General de Sistemas y
Telecomunicaciones. No se han formalizado acuerdos de niveles de servicio con los
usuarios internos.
Por otra parte, el monitoreo de la infraestructura para gestión de datos está a cargo de la
División de Monitoreo y Gestión del Servicio. Mediante el cumplimiento de un
procedimiento formalizado, procura la operación continua y la disponibilidad de todos los
servicios por ellos suministrados. Se emiten alertas cuando se producen variaciones con
respecto a los estándares fijados como óptimos. Cada incidente se identifica unívocamente.
Si bien el seguimiento del incidente está normado por un procedimiento formalizado, el
mismo es manual y el intercambio de información con las áreas responsables de solucionar
el problema se lleva a cabo mediante correos electrónicos o comunicaciones telefónicas. Al
no contar con una herramienta integrada que lo integre y que incluya el escalamiento y las
comunicaciones inter áreas, se dificulta el rastreo de información histórica para un análisis
posterior.
Aclaraciones y/o comentarios del área responsable: No se comparte lo observado en
cuanto a que si bien el seguimiento del incidente está normado por un procedimiento
formalizado, el mismo es manual y el intercambio de información con las áreas
responsables de solucionar el problema se lleva a cabo mediante correos electrónicos o
167
comunicaciones telefónicas. Además se observa que por no contar con una herramienta
integrada que lo integre y que incluya el escalamiento y las comunicaciones inter áreas, se
dificulta el rastreo de información histórica para un análisis posterior.
Al respecto se aclara que toda la información del evento (seguimiento del incidente) se
guarda de forma estructurada, permitiendo el acceso y búsqueda de datos para análisis
posteriores.
Además de registrar todo lo expuesto por las áreas de soporte se complementa con
reportes de monitoreo.
Se cuenta con una herramienta para la generación, administración, comunicación y
seguimiento de los eventos por incidencias y/o problemas. Estos eventos alimentan una
base de conocimiento, cuya información se encuentra disponible en forma en-line.
Se utiliza también un tablero de disponibilidad de sistemas que se actualiza con la
información de estos eventos, y permite ver en forma instantánea los sistemas afectados y
los ya tratados.
Dicha herramienta hace uso del correo electrónico para la comunicación de los eventos
con el objeto de evitar la dependencia de una interface web, permitiendo a cualquier
destinatario tomar conocimiento y acceder a toda la información del mismo, incluso desde
las terminales blackberry utilizadas por la Organización.
Adicionalmente, se utiliza comunicación telefónica para los casos de los eventos críticos
que necesiten de una intervención urgente por parte de las áreas de Soporte Técnico.
Si bien existen los sistemas de reporte de Monitoreo, el SRI, RFC y el SPP como
herramientas de registro de eventos y acciones, cabe señalar que el mail y el teléfono se
siguen utilizando como un método ampliatorio insustituible.
Por todo lo expuesto y a modo de ejemplo, se informa lo registrado en el año 2012, en los
siguientes sistemas:
a) SRI: un total de 55.046 tickets, siendo solucionados en 1er. Nivel de
servicio 27.364 (49.71%) Y en 2do. Nivel de servicio 27.682 (50.29%).
b) RFC: 11.804 requerimientos de cambios.
c) SPP: un total de 333.373 solicitudes de ejecución, de las cuales 29.046 fueron dadas de
168
alta en dicho período.
d) Reporte de monitoreo: 3.501 tickets. De los cuales 3340 eran para áreas internas de
AFIP (Áreas de Soporte de Hardware, de Base, de Desarrollo, de Seguridad Informática,
etc.) y 161 para Organismos Externos (ANSES, Entidades de Pago, Red Link, Banelco,
etc.).
Comentario de AGN: Se mantiene la observación. El marco de monitoreo es limitado a la
infraestructura tecnológica. No abarca lo relativo a desarrollo y mantenimiento de
aplicaciones. Faltan políticas y procedimientos de administración de proyectos y un marco
de aseguramiento de la calidad que abarquen a todos los proyectos de la organización de
TI.
En relación al marco de monitoreo de la infraestructura, se verificaron procesos manuales
para poder integrar los sistemas funcionalmente.
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 las operaciones 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
169
Nivel de Madurez: Administrado y medible. La gerencia tiene implantado un marco de
trabajo para el monitoreo del control interno de TI. La organización ha establecido niveles
de tolerancia para el proceso de monitoreo del control interno. Se han implantado
herramientas para estandarizar evaluaciones y para detectar de forma automática las
excepciones de control. Se ha establecido una función formal para el control interno de TI,
con profesionales especializados y certificados que utilizan un marco de trabajo de control
formal avalado por la alta dirección. Un equipo calificado de TI participa de forma
rutinaria en las evaluaciones de control interno. Se ha establecido una base de datos de
métricas para información histórica sobre el monitoreo del control interno. Se realizan
revisiones entre pares para verificar el monitoreo del control interno.
Observaciones: Hay normativa debidamente aprobada que determina las “Misiones y
funciones de la Unidad de Auditoría Interna”, del cual depende el Departamento de
Auditoría de Sistemas Informáticos.
Existe un marco de trabajo para el monitoreo del control interno de TI, siguiendo el
cumplimiento de la resolución de SIGEN 48/05 respecto a las Normas de Control Interno
para Tecnología de la Información y los lineamientos estratégicos dispuestos en el Anexo I
del decreto 378/2005 del Plan Nacional de Gobierno Electrónico.
La metodología está establecida por el Manual de Auditoría Interna de la Unidad de
Auditoría Interna de la Administración Federal de Ingresos Públicos de acuerdo con la
resolución de SIGEN 152/02 “Normas de Auditoría Interna Gubernamental” según en el
marco de la ley 24.156 de Administración Financiera y de los Sistemas de Control del
Sector Público Nacional.
El Organismo cuenta con un Departamento de Auditoria de Sistemas Informáticos,
dependiente de la Subdirección General de Auditoría Interna, que cuenta con profesionales
internacionalmente certificados en Auditoría de Sistemas (CISA) y Certificación de
Riesgos (CRISC).
Se ha adquirido una herramienta de Gobierno Corporativo, Administración de Riesgos y
Cumplimiento Regulatorio denominada GRC. A través de ésta, se lleva a cabo un análisis
de riesgo donde se identifican la mayoría de los procesos involucrados en la operatoria de
170
TI, la evaluación de los riesgos asociados a cada proceso (la magnitud de la pérdida o daño
posible y la probabilidad que dicha pérdida o daño llegue a ocurrir). En función de la
criticidad que refleje cada caso individual, se asigna prioridades en el Plan Ciclo de
Auditoría, donde se fija la frecuencia de la revisión y la carga de recursos a asignar
(principalmente, horas hombre). El Plan Ciclo de Auditoría contempla información
histórica de 5 (cinco) años hacia atrás del período presente y una proyección de 5 (cinco)
años hacia adelante. Están contempladas un promedio de 8.386 horas de auditoría para
cada año.
Aclaraciones y/o comentarios del área responsable: No hay comentarios del Organismo.
Comentario de AGN: Ante la ausencia de comentario se considera que se acepta la
observación.
4.4.3 Garantizar el cumplimiento con requerimientos externos
Objetivo de control: Una supervisión efectiva del cumplimiento regulatorio requiere del
establecimiento de un proceso independiente de revisión para garantizar el cumplimiento
de las leyes y regulaciones. 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: Repetible. Existe el entendimiento de la necesidad de cumplir con los
requerimientos externos y la necesidad se comunica. En los casos en que el cumplimiento
es recurrente se han desarrollado procedimientos individuales al respecto. No existe un
enfoque estándar. Hay dependencia del conocimiento y responsabilidad de los individuos y
171
los errores son posibles. Se brinda entrenamiento informal respecto a los requerimientos
externos y a los temas de cumplimiento.
Observaciones: No se encontró un catálogo de requerimientos legales y regulatorios
relacionados con la prestación del servicio de TI ni un procedimiento formal para su
desarrollo. No existen informes sobre el cumplimiento de las actividades de TI con los
requerimientos externos legales y regulatorios.
Aclaraciones y/o comentarios del área responsable: A raíz de una observación
practicada por la Unidad de Auditoría Interna, personal de la Dirección de
Infraestructura Tecnológica se encuentra analizando el tema.
Comentario de AGN: La respuesta del organismo no modifica las observaciones
realizadas, por lo tanto se mantienen las mismas.
4.4.4 Proporcionar gobierno de TI
Objetivo de control: El establecimiento de un marco de trabajo de gobierno efectivo,
incluye la definición de estructuras, procesos, liderazgo, roles y responsabilidades
organizacionales para garantizar 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: Repetible. Existe conciencia sobre los temas de gobierno de TI. Las
actividades y los indicadores de desempeño del gobierno de TI, los cuales incluyen
procesos planeación, entrega y supervisión de TI, están en desarrollo. Los procesos de TI
172
seleccionados se identifican para ser mejorados con base en decisiones individuales. Se
han identificado mediciones básicas para el gobierno de TI, así como métodos de
evaluación y técnicas; sin embargo, el proceso no ha sido adoptado a lo largo del
Organismo. La comunicación respecto a los estándares y responsabilidades de gobierno se
deja a los individuos. Los individuos impulsan los procesos de gobierno en varios
proyectos y procesos de TI. Los procesos, herramientas y métricas para medir el gobierno
de TI no abarcan la totalidad de la gestión de TI.
Observaciones: El marco de gobierno de TI es incompleto:
 Falta un Plan Estratégico de TI alineado con el plan Estratégico del Organismo, que
garantice un entendimiento compartido entre los objetivos y la función de TI.
 No se ha normalizado un proceso de administración de proyectos que se aplique a
todas las áreas. Se utilizan distintas herramientas y distintos criterios para los
aspectos considerados para el seguimiento.
 No se ha definido un programa de administración de la calidad, inserto en un
sistema donde se pueda evaluar el desempeño de la función de TI, su contribución a
los objetivos estratégicos del Organismo y que sirva como herramienta de toma de
decisiones ante posibles desvíos entre los resultados esperados y los reales.
 No existe un marco de administración presupuestaria que abarque todas las áreas de
TI, que contemple la contabilidad por centro de costos imputándolos a los proyectos
y calculándose los beneficios esperados y su contribución a las misiones y
funciones de la organización.
 Falta la definición y ejecución de un marco integral de administración de riesgos
que defina cuál es el nivel de riesgo aceptado por el Organismo y que, con prácticas
de administración de riesgo, se asegure que el mismo no exceda las pautas
establecidas.
Aclaraciones y/o comentarios del área responsable: En cuanto a lo observado en
relación a la falta de un plan estratégico de TI alineado con el plan estratégico del
organismo, se remite a lo informado en el punto 4.1.1 precedente.
En relación a que no se ha normalizado un proceso de administración de proyectos que se
173
aplique a todas las áreas, se remite a lo informado en el punto 4.1.10 precedente.
En lo referente a la inexistencia de un marco de administración presupuestaria que
abarque todas las áreas de TI que contemple la contabilidad por centro de costos,
imputándolos a los proyectos y calculándose los beneficios esperados y su contribución a
las misiones y funciones de la organización, se remite a lo informado en el punto 4.1.5
precedente.
Comentario de AGN: La respuesta del organismo no modifica las observaciones
realizadas, por lo tanto se mantienen las mismas. Las mejoras a realizar se evaluarán en
una próxima auditoría.
174
ANEXO VI – NOTAS
(1) El Decreto Nro 1.399/01, de fecha 4 de noviembre de 2001, en su artículo 9
establece que el Plan de Gestión Anual que deberá cumplir el Administrador Federal
de Ingresos Públicos será elaborado por la Jefatura de Gabinete de Ministros con
arreglo al sistema reglado por la Ley N° 25.152 y el Decreto N° 103/01. Dicho plan,
de acuerdo con el artículo 10 del decreto, será controlado y evaluado trimestralmente
por un Consejo Asesor formado por: el Secretario de Ingresos Públicos del
Ministerio de Economía, un representante del Presidente del Banco Central de la
República Argentina, los Presidentes de las Comisiones de Presupuesto y Hacienda
de la Honorable Cámara de Diputados de la Nación y del Honorable Senado de la
Nación, o los legisladores que ellos designen, el Director Ejecutivo de la
Administración Nacional de la Seguridad Social, dos expertos de reconocida
trayectoria en materia tributaria o de gestión pública y un representante de las
Provincias a propuesta del Consejo Federal de Inversiones. El Consejo Asesor no
tendrá funciones ejecutivas en la gestión de la AFIP, pero puede efectuar
recomendaciones y sugerencias al Administrador Federal de Ingresos Públicos.
El artículo 7 del decreto mencionado, establece que el Poder Ejecutivo Nacional
puede remover al Administrador Federal de Ingresos Públicos en caso de
incumplimiento sustancial del Plan de Gestión Anual durante dos años consecutivos,
teniendo en consideración la evaluación realizada por el Consejo Asesor.
La Disposición Nro 672/04 AFIP de fecha 29 de octubre de 2004, en su artículo 11
establece que las áreas responsables de la fijación de metas que eventualmente se
incluirán en los proyectos de Plan de Gestión deberán arbitrar los medios necesarios
para disponer de los mismos durante el mes de agosto de cada año.
Consecuentemente con el Plan de Gestión se elaboran planes estratégicos del
organismo que abarcan períodos de cuatro o cinco años.
(2) El decreto 898/05 aprueba la estructura organizativa de la Administración Federal de
Ingresos Públicos hasta el nivel de Subdirección General, inclusive.
175
La responsabilidad primaria de la Subdirección General de Sistemas y
Telecomunicaciones aprobada por el citado decreto es asistir al Administrador
Federal de Ingresos Públicos en todo lo relativo al diseño, desarrollo, operación y
coordinación de los sistemas informáticos y de telecomunicaciones requeridos para
la operación de la Administración Federal de Ingresos Públicos, en concordancia con
las políticas, planes, programas y criterios dictados por el mismo.
Posteriormente, con la disposición 65/08 y 428/09 de AFIP y sus anexos, se definió
el organigrama de la Subdirección con un detalle de los roles y responsabilidades
para cada perfil hasta nivel de división.
(3) Disposición 672/04 AFIP de fecha 29 de octubre de 2004.
(4) La Disposición 538/05 AFIP del 19 de septiembre del 2005 en su artículo 1 establece
que la SDG SIT queda comprendida por el Régimen Económico Financiero vigente
para las Direcciones Regionales Impositivas y Aduaneras a partir del 1 de octubre del
2005, quedando en manos de la Subdirección General de Administración Financiera
la determinación de qué contrataciones se efectuarán en forma centralizada.
(5) Disposición Nro 446/2009.
(6) De acuerdo al inciso c) “Actos Internos de Carácter Resolutivo” del Anexo I de la
Disposición 446/2009, las Disposiciones son normas de aspecto administrativo y de
organización interna, de cumplimiento obligatorio para todas las jefaturas de
dependencia y personal de la Administración Federal de Ingresos Públicos, en el
marco de las facultades de los Artículos 4to y 6to del Decreto Nro 618/97, sus
modificatorios y sus complementarios, y demás normas vigentes relativas a la
organización, competencia y funcionamiento del Organismo. Las Instrucciones son
normas de procedimiento o trámite, de cumplimiento obligatorio para las jefaturas de
dependencia y personal definido en las mismas para el desarrollo de las tareas o
funciones que les fueran asignadas. También son de orden interno y de carácter
resolutivo.
(7) La política de ingreso de personal está regida por las disposiciones 437/05 y 543/08.
El decreto 898/05 aprueba la estructura organizativa de la Administración Federal de
Ingresos Públicos hasta el nivel de Subdirección General, inclusive.
176
(8) La disposición 65/08 y 428/09 de AFIP y sus anexos, se definió el organigrama de la
Subdirección con un detalle de los roles y responsabilidades para cada perfil hasta
nivel de división.
(9) A través de la Instrucción General Nro 2/2005 de la Subdirección General de
Informática y Telecomunicaciones “Pautas para el desarrollo y mantenimiento de
Sistemas Informáticos en la AFIP” del 30 de noviembre de 2005 se define el proceso
de Ciclo de Vida de Desarrollo de Sistemas. Esta instrucción general, está alineada a
la política de seguridad, aprobada mediante la Disposición 76/05 de AFIP y la
disposición 42/2011 “Pautas y consideraciones de seguridad a tener en cuenta en el
Ciclo de Vida del Desarrollo y Mantenimiento de Sistemas en relación con la
Seguridad de la Información”.
(10) El punto 7.1 de la resolución 02/2005 permite que la adopción de los documentos
entregables sea a criterio de cada división de desarrollo, mientras cumpla con los
contenidos mínimos requeridos para cada fase (definición, diseño, construcción e
implementación) lo que genera que éstas hayan adoptado un conjunto distinto de
documentos.
(11) Análisis de Caja Blanca.
(12) Las compras de TI se realizan de acuerdo a la Disposición 74/2002 que rige para
todas las áreas de la AFIP, teniendo en cuenta las normativas emitida por la ONTI y
por la SIGEN.
(13) Disposición 76/05 de AFIP y la disposición 42/2011 “Pautas y consideraciones de
seguridad a tener en cuenta en el Ciclo de Vida del Desarrollo y Mantenimiento de
Sistemas en relación con la Seguridad de la Información”.
(14) Punto 11 del Anexo I define las actividades a seguir para la puesta efectiva en
producción de las aplicaciones La resolución General Nro 2/2005 SDG SIT que
establece las “Pautas para el Desarrollo y Mantenimiento de Sistemas Informáticos
de
la
AFIP”.
177
ANEXO VII – DESCARGO DEL ORGANISMO
178
179
180
181
182
183
184
185
186
187
188
189
190
191