El documento trata sobre la importancia de los planes de contingencia y continuidad del negocio (BCP) en organizaciones, destacando su necesidad frente a diversas amenazas, incluyendo desastres naturales y situaciones de riesgo como el terrorismo. Se describe el ciclo de vida de estos planes, que incluye fases de análisis de riesgo, selección de estrategias y pruebas, así como subplanes específicos para respaldo, emergencia y recuperación. Además, se enfatiza la necesidad de mantener y revisar estos planes continuamente para asegurar la funcionalidad y resiliencia de la organización ante incidentes imprevistos.

1. PLAN DE CONTINGENCIAS Y OTROS FACTORES RELACIONADOS
Ms. Ing. Jairo E. Márquez D.
Introducción
En las últimas décadas, las entidades a nivel nacional, han concedido una importancia
creciente a la implementación de planes detallados y precisos que garanticen la continuidad
de sus procesos ante eventualidades de diversa índole que afecten la prestación de sus
servicios. Si en un principio los factores de riesgo estaban asociados principalmente a
contingencias de carácter natural y tecnológico, las consecuencias derivadas de sucesos
como el terrorismo, han mostrado la necesidad de incorporar nuevas amenazas en el
proceso de gestión del riesgo. Es así, que los denominados Planes de Continuidad del
negocio (BCP)1 buscan sostener los procesos críticos de una entidad durante y después de
una interrupción.
Plan de contingencias [1]
Un Plan de contingencias es un instrumento de gestión para el buen gobierno de las
Tecnologías de la Información y las Comunicaciones en el dominio del soporte y el
desempeño (delivery and support, véase ITIL).
Dicho plan contiene las medidas técnicas, humanas y organizativas necesarias para
garantizar la continuidad del negocio y las operaciones de una compañía. Un plan de
contingencias es un caso particular de plan de continuidad del negocio aplicado al
departamento de informática o tecnologías. Otros departamentos pueden tener planes de
continuidad que persiguen el mismo objetivo desde otro punto de vista. No obstante, dada
la importancia de las tecnologías en las organizaciones modernas, el plan de contingencias
es el más relevante.
Ciclo de vida
El plan de contingencias sigue el conocido ciclo de vida iterativo PDCA (plan-do-check-
act, es decir, planificar-hacer-comprobar-actuar). Nace de un análisis de riesgo donde, entre
otras amenazas, se identifican aquellas que afectan a la continuidad del negocio.
Sobre dicha base se seleccionan las contramedidas más adecuadas entre diferentes
alternativas, siendo plasmadas en el plan de contingencias junto con los recursos necesarios
para ponerlo en marcha.
El plan debe ser revisado periódicamente. Generalmente, la revisión será consecuencia de
un nuevo análisis de riesgo. En cualquier caso, el plan de contingencias siempre es
cuestionado cuando se materializa una amenaza, actuando de la siguiente manera:

2. - Si la amenaza estaba prevista y las contramedidas fueron eficaces: se corrigen
solamente aspectos menores del plan para mejorar la eficiencia.
- Si la amenaza estaba prevista pero las contramedidas fueron ineficaces: debe
analizarse la causa del fallo y proponer nuevas contramedidas.
- Si la amenaza no estaba prevista: debe promoverse un nuevo análisis de riesgos. Es
posible que las contramedidas adoptadas fueran eficaces para una amenaza no
prevista. No obstante, esto no es excusa para evitar el análisis de lo ocurrido.
Contenido
El plan de contingencias comprende tres subplanes. Cada plan determina las contramedidas
necesarias en cada momento del tiempo respecto a la materialización de cualquier amenaza:
- El plan de respaldo. Contempla las contramedidas preventivas antes de que se
materialice una amenaza. Su finalidad es evitar dicha materialización.
- El plan de emergencia. Contempla las contramedidas necesarias durante la
materialización de una amenaza, o inmediatamente después. Su finalidad es paliar
los efectos adversos de la amenaza.
- El plan de recuperación. Contempla las medidas necesarias después de
materializada y controlada la amenaza. Su finalidad es restaurar el estado de las
cosas tal y como se encontraban antes de la materialización de la amenaza.
Por otra parte, el plan de contingencias no debe limitarse a estas medidas organizativas.
También debe expresar claramente:

3. - Qué recursos materiales son necesarios.
- Qué personas están implicadas en el cumplimiento del plan.
- Cuáles son las responsabilidades concretas de esas personas y su rol dentro del plan.
- Qué protocolos de actuación deben seguir y cómo son.
Por ejemplo. Supongamos una pequeña compañía que se dedica a la producción de prendas
textiles. Un análisis de riesgos identificaría (entre otras cosas) lo siguiente:
Activos e interdependencias: Oficinas centrales → Centro de proceso de datos →
Computadoras y almacenamiento → Información de pedidos y facturación → Proceso de
negocio de ventas → Imagen corporativa.
Este análisis demuestra que una amenaza materializada en las oficinas centrales podría
llegar a afectar al proceso de negocio dedicado a la venta. Aunque esto no impida a la
compañía seguir comercializando productos, supondría una interrupción temporal de las
ventas. Además afectaría negativamente a la imagen corporativa provocando la pérdida de
clientes. Así, se evaluaría la siguiente amenaza y su impacto:
Amenaza: Incendio. (Los activos afectados son los
anteriores).
Impacto: (es un ejemplo ficticio)
- Perdida de un 10% de clientes.
- Imposibilidad de facturar durante un mes.
- Imposibilidad de admitir pedidos durante
un mes.
- Reconstrucción manual de pedidos y
facturas a partir de otras fuentes.
- Sanciones por accidente laboral.
- Inversiones en equipamiento y mobiliario.
- Rehabilitación del local.
Todas estas consecuencias pueden valorarse en términos monetarios, que junto a la
probabilidad de materialización ofrecen una estimación del riesgo.
El plan de contingencias contendría someramente las siguientes contramedidas:
- Medidas técnicas:
- Extintores contra incendios.
- Detectores de humo.
- Salidas de emergencia.
- Equipos informáticos de respaldo.
- Medidas organizativas:

4. - Seguro de incendios.
- Precontrato de alquiler de equipos informáticos y ubicación alternativa.
- Procedimiento de copia de respaldo.
- Procedimiento de actuación en caso de incendio.
- Contratación de un servicio de auditoría de riesgos laborales.
- Medidas humanas:
- Formación para actuar en caso de incendio.
- Designación de un responsable de sala.
- Asignación de roles y responsabilidades para la copia de respaldo.
- (Etc.)
Los subplanes contendrían las siguientes previsiones:
- Plan de respaldo:
- Revisión de extintores.
- Simulacros de incendio.
- Realización de copias de respaldo.
- Custodia de las copias de respaldo (por ejemplo, en la caja fuerte de un banco).
- Revisión de las copias de respaldo.
- Plan de emergencia:
- Activación del precontrato de alquiler de equipos informáticos.
- Restauración de las copias de respaldo.
- Reanudación de la actividad.
- Plan de recuperación:
- Evaluación de daños.
- Traslado de datos desde la ubicación de emergencia a la habitual.
- Reanudación de la actividad.
- Desactivación del precontrato de alquiler.
- Reclamaciones a la compañía de seguros.
Plan de continuidad del negocio [2]
La información es uno de los activos más
importantes para las organizaciones, donde los
sistemas de información y disponibilidad de
estos juegan un rol preponderante para la
continuidad de un negocio, por lo cual las
organizaciones desarrollan e implementan lo
que se conoce como BCP (Business Continuity
Plan), con el objetivo de mantener la

5. funcionalidad de una organización, a un nivel mínimo aceptable durante una contingencia.
Esto implica que un BCP debe contemplar todas las medidas preventivas y de recuperación
para cuando se produzca una contingencia que afecte al negocio.
Este documento trata la metodología ocupada en la Planificación de la Continuidad del
Negocio (BCP: Business Continuity Plannig).
El Plan de Continuidad del Negocio (BCP) es el resultado de la aplicación de una
metodología interdisciplinaria, llamada Cultura BCM, usada para crear y validar planes
logísticos para la práctica de cómo una organización debe recuperar y restaurar sus
funciones críticas parcial o totalmente interrumpidas dentro de un tiempo predeterminado
después de una interrupción no deseada o desastre. Estos planes son llamados Planes de
Continuidad del Negocio. El plan logístico que se denomina un Plan de Continuidad de
Negocios.
En lenguaje sencillo, BCP es el cómo una organización se prepara para futuros incidentes
que puedan poner en peligro la organización y su misión básica a largo plazo. Los
incidentes incluidos en la construcción de incidentes como incendios, terremotos incidentes
como regional, nacional o incidentes como pandemia de enfermedades.
Continuidad del Negocio es un concepto
que abarca tanto la Planeación para
Recuperación de Desastres (DRP) como la
Planeación para el Restablecimiento del
Negocio. Recuperación de Desastres es la
capacidad para responder a una interrupción
de los servicios mediante la implementación
de un plan para restablecer las funciones
críticas de la organización. Ambos se
diferencian de la Planeación de Prevención
de Pérdidas, la cual implica la
calendarización de actividades como respaldo de sistemas, autenticación y autorización
(seguridad), revisión de virus y monitoreo de la utilización de sistemas (principalmente
para verificaciones de capacidad). En esta ocasión hablaremos sobre la importancia de
contar con la capacidad para restablecer la infraestructura tecnológica de la organización en
caso de una disrupción severa.
Lo primero que se debe realizar es un Análisis de Impacto al Negocio (BIA). Éste es
básicamente un informe que nos muestra el coste ocasionado por la interrupción de los
procesos de negocio.
Una vez obtenido este informe, la compañía tiene la capacidad de clasificar los procesos de
negocio en función de su criticidad y lo que es más importante: establecer la prioridad de
recuperación (o su orden secuencial).

6. En el BIA se identifican los componentes claves requeridos para continuar con las
Operaciones de Negocio luego de un incidente, dentro de estos componentes se encuentran:
Personal requerido Areas de trabajo Registros vitales- Backups de información Aplicativos
Críticos Dependencias de otras áreas Dependencias con Terceras partes
Criticidad de los recursos de información
Participación del personal de Seguridad Informática y los usuarios
finales
Análisis de todos los tipos de recursos de información
Tres aspectos claves para el análisis:
Criticidad de los recursos de información relacionados con los procesos
críticos del negocio
Período de recuperación crítico antes de incurrir en pérdidas
significativas
Sistema de clasificación de riesgos
Una estrategia de Recuperación es una combinación de medidas preventivas, detectivas y
correctivas - Eliminar la amenaza completamente - Minimizar la probabilidad de que ocurra
- Minimizar el efecto Las interrupciones más prolongadas y más costosas, en particular los
desastres que afectan a las instalaciones, requieren recuperación (offsite).
Aplicación
El Plan de Continuidad de Negocio abarca todos los sectores de Negocio, dado con más
énfasis en aquéllos donde la Disponibilidad de la Información es su mayor activo. A partir
del 11 de Septiembre de 2001, los Planes de Continuidad de Negocio cobraron importancia
abarcando con mayor cobertura a Compañías del Sector Financiero y sus asociados, donde
hoy en día tiene su mayor aplicación. No hay importancia del tamaño de la empresa o
institución, un plan de continuidad puede ser aplicado tanto a empresas grandes, medianas,
pequeñas e incluso micro empresas. Como todo proceso, la aplicación de un plan de
continuidad involucra determinados pasos obligatorios para garantizar la funcionalidad del
mismo, estas fases son:
1. Fase de Análisis y Evaluación de Riesgos
2. Selección de Estrategias
3. Desarrollo del Plan
4. Pruebas y Mantenimiento del Plan.

7. 5. Pruebas y Aceptación en la Organización
Mantenimiento
Este plan es la respuesta prevista por la empresa ante aquellas situaciones de riesgo que le
pueden afectar de forma crítica .No importa el tamaño de la empresa o el coste de las
medidas de seguridad implantadas, toda organización necesita un Plan de continuidad de
negocio ya que tarde o temprano se encontrará con una incidencia de seguridad.
Este plan es la respuesta prevista por la empresa ante aquellas situaciones de riesgo que le
pueden afectar de forma crítica. No importa el tamaño de la empresa o el coste de las
medidas de seguridad implantadas, toda organización necesita un Plan de continuidad de
negocio ya que tarde o temprano se encontrara con una incidencia de seguridad.
“Cualquier organización, en algún instante de tiempo, se deberá
enfrentar a una situación anómala que amenace su actividad”.
Un Plan de Continuidad de Negocio tiene como objetivo el mantenimiento de estos
servicios y procesos críticos, así como la reducción de impactos ante imprevistos de
indisponibilidad o desastres para en un plazo razonable y con un coste acotado. Este
servicio está orientado a la obtención de un plan global que garantice la cobertura técnica y
organizativa adecuada de las áreas críticas de negocio.
Los objetivos del plan de continuidad de negocio son:
 Salvaguardar los intereses de sus clientes y socios además del negocio y la imagen de la
organización.
 Identificar los puntos débiles en los sistemas de la organización.
 Analizar las comunicaciones e infraestructuras.
 Conocer la logística para restablecer los servicios, independientemente de los sistemas.
 Ofrecer alternativas viables a todos los procesos críticos de negocio.
Como complemento a lo anterior, la incorporación del mantenimiento preventivo MP en
cualquier instalación, en particular para nuestro caso los centros informáticos o de datos,
juega un papel fundamental; lo cual radica en prever daños en los sistemas que son críticos
para la organización. Para ello puede tomarse como referente la información citada en la
tabla 1.1
1
NA.

8. Tabla 1 – Lista de muestra de condiciones ambientales para mantenimiento
preventivo [Tomado de Thierry Bayle. Estrategia de mantenimiento preventivo para
centros de datos. Informe interno N° 124. APC by Schneider Electric]
Planes Complementarios [3]
En la figura 1, tomada de la publicación especial SP800-342 del NIST, se observa una
versión holística de los diferentes tipos de planes relacionados con la atención de desastres,
incidentes y emergencias, y su interrelación con el Plan de Continuidad del Negocio.
De esta figura se desprende la conveniencia de que un plan de continuidad del Negocio se
complemente con dichos planes. Sin embargo, debido a la carencia de definiciones estándar

9. para estos tipos de planes, en algunos casos el alcance de los mismos puede variar entre las
diferentes organizaciones. Por tal motivo, cuando se hable de estos planes durante la
ejecución del proyecto, o a futuro se piense en complementar el Plan de Continuidad del
Negocio, es recomendable considerar las siguientes definiciones y conceptos según el
documento NIST SP800-34:
1. Plan de comunicación de crisis: documento que contiene los procedimientos
internos y externos que las organizaciones deben preparar ante un desastre. Este
plan debe estar coordinado con los demás planes para asegurar que sólo se
divulguen los comunicados aprobados y que solamente el personal autorizado sea
responsable de contestar las diferentes inquietudes y de diseminar los reportes de
estado al personal y al público.
2. Planes de evacuación por edificio: contiene los procedimientos que deben seguir
los ocupantes de una instalación o facilidad en el evento en que una situación se
convierta en una amenaza potencial a la salud y seguridad del personal, el ambiente
o la propiedad. Tales eventos podrían incluir fuego, terremoto, huracán, ataque
criminal o una emergencia médica.
Estos planes se desarrollan por cada instalación y son específicos a la localización
geográfica y al diseño estructural de la construcción.
3. Plan de continuidad de operaciones por sede o sitio (COOP por sus siglas en
inglés – Continuity of Operations Plan): orientado a restaurar las funciones
esenciales de una sede o sitio de la entidad en una sede alterna y realizar aquellas
funciones por un período máximo de 30 días antes de retornar a las operaciones
normales. Debido a que un COOP se enfoca en sedes o sitios, se debe desarrollar y
ejecutar de manera independiente del BCP. Las interrupciones menores que no
requieren reubicación en una sede alterna no se cubren en un COOP.
4. Plan de respuesta a ciber-incidentes: Establece procedimientos para responder a
los ataques en el ciberespacio contra un sistema de Tecnología Informática (TI) de
una entidad.
Estos procedimientos están diseñados para permitirle al personal de seguridad
identificar, mitigar y recuperarse de incidentes de cómputo maliciosos tales como
acceso no autorizado a un sistema o dato, negación de servicio, cambios no
autorizados a hardware, software o datos (lógica maliciosa, tales como virus,
gusanos o caballos de Troya).
5. Plan de contingencia de TI: orientado a ofrecer un método alterno de operación
para sistemas de soporte general y para aplicaciones críticos. Debido a que un plan
de contingencia de TI se debe desarrollar por cada sistema de soporte general y por
cada aplicación importante, existirán múltiples planes de contingencia.
6. Plan de recuperación de desastres (Disaster Recovery Plan, DRP): Orientado a
responder a eventos importantes, usualmente catastróficos que niegan el acceso a la

10. facilidad normal por un período extendido. Frecuentemente el DRP se refiere a un
plan enfocado a TI y diseñado para restaurar la operabilidad del sistema, aplicación
o facilidad de cómputo objetivo en un sitio alterno después de una emergencia. El
alcance de un DRP puede solaparse con el de un plan de contingencia de TI; sin
embargo, el DRP es más amplio en alcance y no cubre interrupciones menores que
no requieren reubicación. Dependiendo de las necesidades de la organización,
pueden existir varios DRP.
Plan de recuperación ante desastres [4]
Un plan de recuperación ante desastres (del
inglés Disaster Recovery Plan) es un proceso de
recuperación que cubre los datos, el hardware y
el software crítico, para que un negocio pueda
comenzar de nuevo sus operaciones en caso de
un desastre natural o causado por humanos. Esto
también debería incluir proyectos para
enfrentarse a la pérdida inesperada o repentina de
personal clave, aunque esto no sea cubierto en
este artículo, el propósito es la protección de
datos.
Con el crecimiento de la tecnología de información y la confianza sobre datos cruciales, el
panorama ha cambiado en años recientes a favor de la protección de datos irreemplazables.
Esto es evidente sobre todo en la tecnología de información; con los sistemas de
ordenadores más grandes que sostienen información digital para limitar pérdida de datos y
ayudar recuperación de datos.
Se cree que algunas empresas gastan hasta el 25 % de su presupuesto en proyectos de
recuperación de desastre, sin embargo, esto lo hacen para evitar pérdidas más grandes. De
las empresas que tenían una pérdida principal de registros automatizados el 43 % nunca
vuelve a abrir, el 51 % cierra en menos de dos años, y sólo el 6 % sobrevivirá el largo
plazo. [5]
El mercado de protección de datos existente es caracterizado por varios factores:
El permanente cambio de las necesidades de los clientes determinado por el crecimiento de
datos, asuntos regulatorios y la creciente importancia de tener rápido acceso a los datos
conservándolos en línea.
Respaldar los datos de vez en cuando teniendo tecnologías de cintas convencionales de
reservas.

11. Como el mercado de recuperación de desastre sigue sufriendo cambios estructurales
significativos, este cambio presenta oportunidades para las empresas de la nueva
generación a que se especialicen en la planificación de continuidad de negocio y la
protección de datos fuera de sitio.
Razones para recurrir a un DRP
Existen diferentes riesgos que pueden impactar negativamente las operaciones normales de
una organización. Una evaluación de riesgo debería ser realizada para ver que constituye el
desastre y a que riesgos es susceptible una empresa específica, incluyendo:
- Catástrofes.
- Fuego.
- Fallos en el suministro eléctrico.
- Ataques terroristas.
- Interrupciones organizadas o deliberadas.
- Sistema y/o fallos del equipo.
- Error humano.
- Virus informáticos.
- Cuestiones legales.
- Huelgas de empleados.
Prevención ante los desastres
- Enviar respaldos fuera de sitio semanalmente para que en el peor de los casos no se
pierda más que los datos de una semana.
- Incluir el software así como toda la información de datos, para facilitar la
recuperación.

12. - Si es posible, usar una instalación remota de reserva para reducir al mínimo la
pérdida de datos.
- Redes de Área de Almacenamiento (SANs) en múltiples sitios son un reciente
desarrollo (desde 2003) que hace que los datos estén disponibles inmediatamente
sin la necesidad de recuperarlos o sincronizarlos.
- Protectores de línea para reducir al mínimo el efecto de oleadas sobre un delicado
equipo electrónico.
- El suministro de energía ininterrumpido (SAI).
- La prevención de incendios - más alarmas, extintores accesibles.
- El software del antivirus.
- El seguro en el hardware.
El plan
Para asegurar la continuidad del negocio, es recomendable partir de la siguiente premisa:
"Siempre desear lo mejor y planear para lo peor". En un buen plan existen diferentes
factores que hay que tomar en cuenta. Los más importantes son:
- El árbol telefónico: para notificar todo el personal clave del problema y asignarles
tareas enfocadas hacia el plan de recuperación.
- Reservas de memoria: si las cintas de reserva son tomadas fuera de sitio es
necesario grabarlas. Si se usan servicios remotos de reserva se requerirá una
conexión de red a la posición remota de reserva (o Internet).
- Clientes: la notificación de clientes sobre el problema reduce al mínimo el pánico.
- Instalaciones: teniendo sitios calientes o sitios fríos para empresas más grandes.
Instalaciones de recuperación móviles están también disponibles en muchos
proveedores.
- Trabajadores con conocimiento. Durante desastre a los empleados se les requiere
trabajar horas más largas y más agotadoras. Debe haber un sistema de apoyo para
aliviar un poco de tensión.
- La información de negocio. Las reservas deben estar almacenadas completamente
separadas de la empresa (Cummings, Haag y 2005 McCubbrey). La seguridad y la
fiabilidad de los datos es clave en ocasiones como estas.
Business Continuity Planning (BCP)
Continuidad del Negocio es un concepto que abarca tanto la Planeación para Recuperación
de Desastres (DRP) como la Planeación para el Restablecimiento del Negocio.
Recuperación de Desastres es la capacidad para responder a una interrupción de los
servicios mediante la implementación de un plan para restablecer las funciones críticas de
la organización (es decir la parte operativa del negocio). Ambos se diferencian de la

13. Planeación de Prevención de Pérdidas, la cual implica
la calendarización de actividades como respaldo de
sistemas, autenticación y autorización (seguridad),
revisión de virus y monitoreo de la utilización de
sistemas (principalmente para verificaciones de
capacidad). En esta ocasión hablaremos sobre la
importancia de contar con la capacidad para restablecer
la infraestructura tecnológica de la organización en
caso de una disrupción severa.
Constantemente se experimentan situaciones de
emergencia, directa o indirectamente, las cuales se manifiestan en respuestas equívocas
ocasionadas por el temor, miedo o un extremoso pánico aterrador.
Frecuentemente los administradores o responsables de los sistemas de cómputo empiezan a
tomar en cuenta la seguridad de su sistema después de haber sido objeto de un ataque,
dando como resultado la pérdida de información, horas de trabajo, incluso dinero. La
seguridad en el trabajo es uno de los factores más importantes que garantizan el crecimiento
de la productividad.
Velar por la seguridad física y lógica no es una tarea que se efectúe una sola vez y garantice
su eficiencia por siempre. Para mantener la seguridad se requiere realizar periódicamente
tareas preventivas.
El establecimiento de procedimientos y medidas de seguridad están destinados a
salvaguardar la unidad administrativa, el centro de cómputo su estructura física, al personal,
sus procedimientos operacionales, la información y documentación generada contra
cualquier evento natural o humano que de forma intencional o por accidente puedan
afectarlos.
Proceso de recuperación
- Comprar nuevo equipo (el hardware) o reparar o quitar virus, etc.
- Llamar el abastecedor de software e instalar de nuevo el software.
- Recuperar los discos de almacenaje que estén fuera de sitio.
- Reinstalar todos los datos de la fuente de respaldo.
- Volver a ingresar los datos de las pasadas semanas.
- Tener estrategias periódicas de respaldos de base de datos.
Tecnología
- Biblioteca de cinta virtual.
- Software de réplica sincrónico.

14. - Tecnología de almacenaje de réplica.
- Servicio telefónico virtual PBX/HOSTED.
- Backups remotos de reserva.
- Protector de datos continuo.
- Sistema para la administración de planes (Moebius).
Terminología:
Punto Objetivo de Recuperación (RPO, Recovery Point Objective) es cuando la
infraestructura, ya comenzada nuevamente, comenzará a hacerse evidente. Básicamente,
RPO significa lo que la organización está dispuesta a perder en cantidad de datos. Para
reducir un RPO es necesario aumentar el sincronismo de réplica de datos.
Tiempo Objetivo de Recuperación (RTO, Recovery Time Objective) es el tiempo que
pasará una infraestructura antes de estar disponible. Para reducir el RTO, se requiere que la
Infraestructura (Tecnológica, Logística, Física) esté disponible en el menor tiempo posible
pasado el evento de interrupción.
Cuando ocurre una pérdida de datos crítica, sin un plan de recuperación de desastre
preventivo, la única opción es salvar los datos.
ITIL (Information Technology Infrastructre Library)
La Biblioteca de Infraestructura de
Tecnologías de Información,
frecuentemente abreviada ITIL (del inglés
Information Technology Infrastructure
Library), es un conjunto de conceptos y
prácticas para la gestión de servicios de
tecnologías de la información, el desarrollo
de tecnologías de la información y las
operaciones relacionadas con la misma en
general. ITIL da descripciones detalladas
de un extenso conjunto de procedimientos de gestión ideados para ayudar a las
organizaciones a lograr calidad y eficiencia en las operaciones de TI. Estos procedimientos
son independientes del proveedor y han sido desarrollados para servir como guía que
abarque toda infraestructura, desarrollo y operaciones de TI.
ITIL es un conjunto de mejores prácticas agrupadas en libros; estas fueron desarrolladas
por el Gobierno Inglés en los años 80’s. Este conjunto de libros ha evolucionado a través de
los años y ahora está en la versión tres. El organismo encargado de regular esta práctica es
la OGC (Office of Governance Commerce), quien ha dado al APM Group la tarea de
administrar y autorizar licencias a los Institutos de exanimación (EI – Examination

15. Institute) y las tareas de acreditación de organizaciones proveedoras de servicios de
educación. Los EI aprueban a las organizaciones de entrenamiento ATO ( Acreditate
Trainning Organization) como Inteli para dar educación con base en los parámetros de
contenido del curso, una ruta oficial de capacitación, la revisión de materiales y procesos
para entregar cursos con un estándar de calidad internacional. [6]
Certificación
Los particulares pueden conseguir varias certificaciones oficiales ITIL. Los estándares de
calificación ITIL son gestionados por la ITIL Certification Management Board (ICMB) que
agrupa a la OGC, a itSMF International y a los dos Institutos Examinadores existentes:
EXIN (con sede en los Países Bajos) e ISEB (con sede en el Reino Unido).
Fig. Ruta de certificación.
Existen tres niveles de certificación ITIL para profesionales:
- Foundation Certificate (Certificado Básico): acredita un conocimiento básico de
ITIL en gestión de servicios de tecnologías de la información y la comprensión de la

16. terminología propia de ITIL. Está destinado a aquellas personas que deseen conocer
las buenas prácticas especificadas en ITIL.
- Practitioner's Certificate (Certificado de Responsable): destinado a quienes tienen
responsabilidad en el diseño de procesos de administración de departamentos de
tecnologías de la información y en la planificación de las actividades asociadas a los
procesos.
- Manager's Certificate (Certificado de Director): garantiza que quien lo posee
dispone de profundos conocimientos en todas las materias relacionadas con la
administración de departamentos de tecnologías de la información, y lo habilita para
dirigir la implantación de soluciones basadas en ITIL.
No es posible certificar una organización o sistema de gestión como «conforme a ITIL»,
pero una organización que haya implementado las guías de ITIL sobre Gestión de los
Servicios de TI puede lograr certificarse bajo la ISO/IEC 20000.
La versión 3 de ITIL, que apareció en junio de 2007, cambió ligeramente el esquema de
Certificaciones, existiendo certificaciones puentes, se definen 3 niveles:
- Basic Level (Equivalente a ITIL Foundation en v2)
- Management and Capability Level (Equivalente a los niveles Practitioner y
Manager en ITIL v2)
- Advanced Level (nuevo en v3)
Críticas a ITIL
ITIL ha recibido críticas de varios frentes. Entre ellas:
El hecho de que muchos defensores de ITIL parecen creer que es un marco holístico y
completo para el gobierno de TI.
Su tendencia a convertirla en una religión.
Como señala Jan van Bon (autor y editor de muchas publicaciones de Gestión de Servicios
de TI):
Hay mucha confusión sobre ITIL, procedente de todo tipo de malentendidos sobre su
naturaleza. ITIL, como afirma la OGC, es un conjunto de buenas prácticas. La OGC no
afirma que dichas mejores prácticas describan procesos puros, ni tampoco que ITIL sea un
marco diseñado como un modelo coherente. Eso es lo que la mayoría de sus usuarios hacen
de ella, probablemente porque tienen una gran necesidad de dicho modelo. [7]
El columnista CIO Magazine Dean Meyer también ha expuesto algunos puntos de vista
cautelosos sobre ITIL, [8] incluyendo cinco trampas típicas tales como «convertirse en
esclavo de definiciones desactualizadas» y «dejar que ITIL se convierta en religión». Como

17. Meyer señala, ITIL «no describe el abanico completo de procesos necesarios para ser
líderes. Se centra en [...] gestionar servicios actuales.»
La calidad de los volúmenes de la biblioteca se considera desigual. Por ejemplo, van
Herwaarden y Grift señalan que «la consistencia que caracterizaba los procesos de soporte
al servicio [...] se pierde en gran medida en los libros de entrega de servicio.» [9]
Todas estas manifestaciones acerca de ITIL provienen de compañias que en un momento
dado han logrado entender que `para alcanzar objetivos de manera clara es necesario
practicar ciertas prácticas que cumplan con ese objetivo y los resultados demostrados son
benéficos para quien los desarrolla y para quien hace uso de este entorno.
ITIL v3 [10]
En ITIL v3 reestructura el manejo de los temas para consolidar el modelo de "ciclo de vida
del servicio" separando y ampliando algunos subprocesos hasta convertirlos en procesos
especializados. Esta modificación responde a un enfoque empresarial para grandes
corporaciones que utilizan ampliamente ITIL en sus operaciones y aspira a consolidar el
modelo para conseguir aún mejores resultados.
Es por ello que los especialistas recomiendan que empresas emergentes o medianas no
utilicen ITIL v3 si no cuentan con un modelo ITIL consolidado y aspiran a una expansión a
muy largo plazo. ITIL v3 consta de 5 libros basados en el ciclo de vida del servicio:

18. 1. Estrategia del Servicio
2. Diseño del Servicio
3. Transición del Servicio
4. Operación del Servicio
5. Mejora Continua del Servicio
Estrategia del Servicio
Se enfoca en el estudio de mercado y posibilidades mediante la búsqueda de servicios
innovadores que satisfagan al cliente tomando en cuenta la real factibilidad de su puesta en
marcha. Asi mismo se analizan posibles mejoras para servicios ya existentes. Se verifican
los contratos con base en las nuevas ofertas de proveedores antiguos y posibles nuevos
proveedores, lo que incluye la renovación o revocación de los contratos vigentes.
Procesos
- Gestión Financiera
- Gestión del Portafolio
- Gestión de la Demanda
Cambios en la versión 2011
Los conceptos dentro de la publicación se han aclarado, sin necesidad de cambiar el
mensaje general. La publicación actualizada incluye una orientación más práctica y con
más ejemplos.
Financial Management for IT services (Gestión Financiera de TI)
La gestión financiera de TI ha ampliado para incluir algunos de los elementos clave de la
ITIL publicaciones anteriores que habían sido excluidos en la edición 2007 de la Estrategia
del Servicio – tales como contabilidad, elaboración de presupuestos y de cargos.
Business Relationship Management (Gestión de Relaciones del Negocio)
Este es un nuevo proceso que se asemeja al existente en la ISO 20.000. Se hace una
diferenciación para los distintos proveedores de servicio: tipo I, II y III. Se brinda una
explicación diferente para cada tipo de proveedor.
Governance (Gobierno)

19. Ahora hay más detalles sobre el concepto de Gobierno, incluida una definición más
completa de su significado, la diferencia entre el gobierno y gestión, un marco de gobierno,
y cómo la gestión del servicio se relaciona con el gobierno.
Cloud Computing (Computación en la nube)
Se ha incluido en qué forma la gestión de servicios se ve afectada por la aparición de la
computación en la nube. Se agregó un nuevo apéndice que cubre específicamente la
estrategia de servicio y la nube: características, tipos, tipos de servicio, y los componentes
de la arquitectura de nube. [11]
Diseño del Servicio
Una vez identificado un posible servicio el siguiente paso consiste en analizar su viabilidad.
Para ello se toman factores tales como infraestructura disponible, capacitación del personal
y se planifican aspectos como seguridad y prevención ante desastres. Para la puesta en
marcha se toman en consideración la reasignación de cargos (contratación, despidos,
ascensos, jubilaciones, etc.), la infraestructura y software a implementar.
Procesos
- Gestión del Catálogo de Servicios
- Gestión de Niveles de Servicio
- Gestión de la Disponibilidad
- Gestión de la Capacidad
- Gestión de la Continuidad de los Servicios de TI
- Gestión de Proveedores
- Gestión de la Seguridad de Información
- Coordinación del Diseño (nuevo en la versión 2011)
Cambios en la versión 2011
Las principales modificaciones del libro de ITIL V3 Diseño del Servicio en su versión 2011
incluye: un cambio a los denominados 5 aspectos del diseño y primordialmente la inclusión
de un nuevo proceso de Coordinación del Diseño. De esta manera esta fase incluye ahora 8
procesos, en lugar de 7.
Nuevo Proceso ITIL V3 2011: Coordinación del Diseño (Design Coordination Process)
[12]
Se adicionó este proceso para hacer más claro el flujo de actividades en el ciclo de vida del
diseño. El propósito del proceso de Coordinación del Diseño es garantizar que las metas y
los objetivos de la etapa de diseño del servicio entregando y manteniendo un punto único

20. de coordinación y control de todas las actividades y procesos dentro de esta etapa del ciclo
de vida de servicio. Las salidas del proceso de coordinación del diseño son potencialmente:
- Diseño de servicios integrado y consistente a través del SDP (paquete de diseño del
servicio)
- Revisión de la arquitectura empresarial
- Revisión del sistema de gestión
- Revisión de las métricas y métodos de medición
- Revisión de procesos
- Actualización del Portafolio de Servicios
- Actualización de los registros de cambios
Transición del Servicio
Antes de poner en marcha el servicio se deben realizar pruebas. Para ello se analiza la
información disponible acerca del nivel real de capacitación de los usuarios, estado de la
infraestructura, recursos IT disponibles, entre otros. Luego se prepara un escenario para
realizar pruebas; se replican las bases de datos, se preparan planes de rollback (reversión) y
se realizan las pruebas. Luego de ello se limpia el escenario hasta el punto de partida y se
analizan los resultados, de los cuales dependerá la implementación del servicio. En la
evaluación se comparan las expectativas con los resultados reales.
Procesos
- Gestión de la Configuración y Activos
- Gestión del Cambio
- Gestión del Conocimiento
- Planificación y Apoyo a la Transición
- Gestión de Release y Despliegue
- Gestión Validación y Pruebas
- Evaluación (Evaluación del cambio)
Cambios en la versión 2011 [13]
En la edición ITIL V3 2011 del libro de Transición del Servicio, se realizaron
modificaciones y aclaraciones, a efectos de mejorar el entendimiento de los conceptos.
Se aclaró la estructura, el contenido y las relaciones entre el Sistema de Gestión de
Configuraciones (CMS) y el Sistema de Gestión del Conocimiento del Servicio (SKMS)
para hacer más entendibles los conceptos.
Se incorporó un nuevo contenido relacionado con la forma que que debe ser usado un
Requerimiento de Cambio (RFC).

21. El proceso de Evaluación (que no se ve en fundamentos sino en el Intermediate RCV) fue
renombrado como Evaluación del cambio. Se modificó su propósito y alcance, a efectos de
clarificar cuando debe ser usado.
El proceso de Gestión de Activos y Configuraciones del Servicio tiene información
adicional y se mejoraron los flujos de interacción con otros procesos, incluidos Gestión de
Cambio, Gestión de Versiones y Entrega, y Evaluación del Cambio.
Por último se mejoraron las descripciones de los Elementos de Configuración (CI) ,
Sistema de Gestión de Configuraciones (CMS) y el Sistema de Gestión del Conocimiento
del Servicio (SKMS)
Operación del Servicio
En este punto se monitoriza activa y pasivamente el funcionamiento del servicio, se
registran eventos, incidencias, problemas, peticiones y accesos al servicio.
Procesos
- Gestión de Incidentes
- Gestión de Problemas
- Cumplimiento de Solicitudes
- Gestión de Eventos
- Gestión de Accesos
Mejora Continua del Servicio
Se utilizan herramientas de medición y feedback para documentar la información referente
al funcionamiento del servicio, los resultados obtenidos, problemas ocasionados, soluciones
implementadas, etc. Para ello se debe verificar el nivel de conocimiento de los usuarios
respecto al nuevo servicio, fomentar el registro e investigación referentes al servicio y
disponer de la información al resto de los usuarios.
Gestión de incidentes [14]
La gestión de incidentes es un área de procesos perteneciente a la Gestión de Servicio TI.
El primer objetivo de la gestión de incidentes es recuperar el nivel habitual de
funcionamiento del servicio y minimizar en todo lo posible el impacto negativo en la
organización de forma que la calidad del servicio y la disponibilidad se mantengan.
Los incidentes que no pueden ser resueltos rápidamente por el equipo de ayuda al usuario,
son asignados a un especialista del equipo de soporte técnico. La resolución del incidente
debe ser ejecutada lo antes posible para restaurar el servicio rápidamente.
La terminología ITIL define un incidente como:

22. Cualquier evento que no forma parte del desarrollo habitual del servicio y que causa, o
puede causar una interrupción del mismo o una reducción de la calidad de dicho servicio.
El objetivo de ITIL es reiniciar el funcionamiento normal tan rápido como sea posible con
el menor impacto para el negocio y el usuario con el menor coste posible.
Incidentes, Problemas y Errores Conocidos
Un incidente puede coincidir con un “Problema conocido” (fallo sin un origen conocido) o
con un “Error conocido” (fallo con origen conocido) bajo el control de la gestión de
problemas y registrado en la base de datos de errores conocidos.
En el caso de que se hayan determinado algunas estrategias de resolución de problemas, el
acceso a ellas por parte del servicio técnico permitirá una mayor velocidad a la hora de
resolverlas. Cuando un incidente no es el resultado de un problema conocido o un error
conocido, puede ser un fallo puntual o puede ser necesario comenzar una gestión de
problemas, de forma que este incidente quede registrado para futuras referencias.
Incidentes y Cambios
Los incidentes son el resultado de fallos o errores en la infraestructura TI. La causa de los
incidentes puede ser aparente y puede ser solucionada sin necesidad de inversiones futuras,
mediante una reparación o una petición de cambio para solventar el error.
Cuando un incidente es considerado como grave, o se observan múltiples casos de
incidentes similares, puede crearse el registro de un problema (el problema puede no ser
registrado hasta que se haya repetido varias veces el mismo incidente). La gestión de un
problema es diferente a la gestión de incidentes, se desarrolla en otro equipo de trabajo y se
controla mediante la gestión de problemas. Cuando un problema se ha identificado y se
conoce la solución, el problema se convierte en un “problema conocido”. Tras identificar la
causa del problema, este pasa a ser un “error conocido”. Finalmente una petición de cambio
puede ser realizada para solventar el error. A partir de este punto, el proyecto es
competencia de la gestión del cambio.

23. Una petición de un nuevo servicio no se clasifica como incidente, si no como una petición
de cambio.
Procesos de gestión de incidentes
El proceso habitual de gestión de incidentes es el siguiente:
- Detección y registro del incidente.
- Clasificación y soporte inicial.
- Investigación y diagnóstico.
- Resolución y recuperación.
- Cierre del incidente.
- Monitorización, seguimiento y comunicación del incidente.
Ejemplos
Los incidentes deben clasificarse a medida que son reportados. Algunos ejemplos de
incidentes según su clasificación son los siguientes:
- Aplicaciones
- Servicio no disponible
- Fallo de la aplicación
- Capacidad del disco duro excedida
- Hardware
- Caída del sistema
- Alerta automática
- Impresora que no imprime
ITIL Gestión de Incidentes [15]
Definición del "mundo real" de la Gestión de
Incidentes: es la forma en que el Centro de
Servicio saca los 'incendios diarios.
Un "incidente" es cualquier evento que no es
parte de la operación estándar del servicio y que
causa, o puede causar, una interrupción o una
reducción de la calidad del servicio.
El objetivo de la Gestión de Incidentes es
restaurar las operaciones normales tan pronto como sea posible con el menor impacto
posible en cualquiera de los negocios o el usuario, a un precio rentable.
Las entradas para el Manejo de Incidentes en su mayoría provienen de los usuarios, pero
puede tener otras fuentes, así como la gestión de la información o los sistemas de detección.

24. Los resultados del proceso son los RFC (Solicitudes de Cambios), resuelto e Incidentes
cerrados, gestión de la información y la comunicación al cliente.
Actividades del Incidente proceso de Gestión:
- Incidente de detección y registro
- Clasificación y soporte inicial
- Investigación y diagnóstico
- Resolución y recuperación
- Incidente cierre
- Propiedad de incidentes, monitoreo, rastreo y comunicación
- Estos elementos proporciona una línea de base para la revisión por la dirección.
Incidentes Introducción a la administración rápida
Declaración de la Misión
Restaurar normales estado en el que las operaciones de servicio tan pronto como sea
posible para minimizar el impacto adverso en las operaciones comerciales.
Objetivo Proceso de lograr la misión proceso de aplicación:
• ITIL alineados Políticas de Gestión de Incidentes, Procesos y Procedimientos
• Las normas de la escalada de incidentes
• Gestión de Incidentes dedicado Proceso Propietario
• Las categorías de clasificación de incidentes
• Los informes de incidentes
• Comunicaciones de Incidentes y educación para el personal de TI
Factores Críticos de Éxito (FCE)
Los factores críticos de éxito son:
• Mantenimiento de la calidad del servicio
• Mantenimiento de Satisfacción del Cliente
• Los incidentes se resuelven dentro de tiempos de servicios establecidos
Actividades principales Las actividades principales de este proceso son:
o Detectar y denunciar los incidentes
o Clasificar los incidentes
o Proporcionar apoyo incidente inicial
o Dar prioridad a los incidentes en función del impacto y la urgencia
o Investigar y diagnosticar los incidentes
o Resolver los incidentes y recuperarse de servicio por niveles de servicio
acordados

25. o Incidentes Cerrar
o Mantener la propiedad, la supervisión, el seguimiento y las comunicaciones
sobre incidentes
o Proporcionar información acerca de la gestión de calidad Gestión de
incidentes y operaciones.
Indicadores clave de rendimiento (KPIs) Ejemplos de indicadores de procesos clave de
rendimiento (KPI) se muestran en la siguiente lista. Cada uno de ellos está asignado a un
Factor Clave de Éxito (CSF).
El mantenimiento de la calidad del servicio
• Número de incidentes de gravedad 1 (total y por categoría)
• Número de incidentes de gravedad 2 (total y por categoría)
• Número de otros incidentes (total y por categoría)
• Número de incidentes clasificados incorrectamente
• Número de incidentes se intensificaron incorrectamente
• Número de incidentes sin pasar Service Desk
• Número de incidentes no se cierra / resueltos con soluciones
• Número de incidentes resueltos antes de notar los clientes
• Número de incidentes reabiertos
El mantenimiento de Satisfacción del Cliente
• Número de Encuestas a los usuarios / clientes enviados
• Número de Encuestas a los usuarios / clientes respondieron a
• Promedio de usuario / cliente encuesta puntuación (total y por categoría de pregunta)
• Tiempo medio de espera de cola de respuesta a incidentes
Resolución de Incidentes dentro de los tiempos de servicios establecidos
• Número de incidentes registrados
• Número de incidentes resueltos por Service Desk
• Número de incidentes se intensificaron por Service Desk
• Tiempo promedio para restablecer el servicio desde el punto de la primera llamada
• Tiempo medio para restaurar la severidad 1 incidentes
• Tiempo promedio para restaurar Gravedad 2 incidentes
La diferencia entre Gestión de Incidentes y Gestión de Problemas
Los incidentes y solicitudes de servicio se gestionan a través formalmente un proceso por
etapas hasta su conclusión. Este proceso se conoce como el "Incidente Lifecycle
Management". El objetivo del ciclo de vida de la Gestión de Incidentes es restaurar el

26. servicio tan pronto como sea posible para cumplir con los Acuerdos de Nivel de Servicio.
El proceso está dirigido principalmente a nivel de usuario.
Problema ofertas de gestión con la resolución de la causa subyacente de uno o más
incidentes. El enfoque de la Gestión de Problemas es resolver la causa raíz de los errores y
encontrar soluciones permanentes. Aunque se hará todo lo posible para resolver el
problema lo antes posible este proceso se centra en la resolución del problema y no de la
velocidad de la resolución. Este proceso trata a nivel de empresa.
Tarea.
1. Desarrollar el curso de ITIL en la página http://itilv3.osiatis.es/
2. Realizar un resumen del curso y de su importancia en su rama profesional.
3. Establezca un plan de continuidad de negocios para una empresa pequeña.
Referencias
[1] Plan de contingencias. Recuperado el 2 de enero de 2013.
http://es.wikipedia.org/wiki/Plan_de_Contingencias
[2] Plan de continuidad del negocio. Recuperado el 2 de enero de 2013.
http://es.wikipedia.org/wiki/Plan_de_continuidad_del_negocio
[3] Plan de Continuidad de Negocio BCP. Recuperado el 6 de enero de 2013.
http://www.acis.org.co/index.php?id=1706
[4] Plan de recuperación ante desastres. Recuperado el 2 de enero de 2013.
http://es.wikipedia.org/wiki/Plan_de_Recuperaci%C3%B3n_ante_Desastres
[5] Jim Hoffer, "Backing Up Business - Industry Trend or Event", Health Management
Technology, january 2001
[6] ¿Qué es ITIL? Recuperado el 2 de enero de 2013.
http://www.inteli.com.mx/portal/index.php?option=com_content&view=article&id=12
[7] van Bon, J., ed (2002). The guide to IT service management. Addison Wesley. ISBN 0-
201-73792-2.
[8] Meyer, Dean, 2005. «Beneath the Buzz: ITIL», CIO Magazine, 31 de marzo de 2005.
[9] Van Herwaarden, H. y F. Grift (2002). "IPW(tm) and the IPW Stadia Model(tm)
(IPWSM)". The guide to IT service management. J. Van Bon. Londres, Addison-Wesley:
97-115.
[10] Federico, Ricardo. «Actualizacion ITIL V3 2011: Estrategia del Servicio» (en
español). BITCompany. Consultado el 09/10/2011.

27. [11] Federico, Ricardo. «Actualización ITIL V3 2011: Diseño del Servicio» (en español).
BITCompany. Consultado el 28/10/2011.
[12] ibid.
[13] Gestión de incidentes. Recuperado el 2 de enero de 2013.
http://es.wikipedia.org/wiki/Gesti%C3%B3n_de_incidentes
[14] ITIL Gestión de Incidentes. Recuperado el 2 de enero de 2013.
http://www.itlibrary.org/index.php?page=Incident_Management
[15] Ibid.