¿Por qué falla un Help Desk?

En muchos momentos los servicios que realiza un Help Desk no suelen ser valorados positivamente por parte de los usuarios del mismo. La mayoría de las veces, eso queda reflejado en las encuestas de satisfacción del servicio donde dichos usuarios manifiestan su descontento con el servicio que reciben. 

Para tratar de simplificar, esa falta de satisfacción puede tener su origen en tres tipos de carencias o problemas:

Problema en las expectativas del usuario respecto del servicio ofrecido por el Help Desk. Por ejemplo, las expectativas pueden ser muy elevadas respecto a la capacidad operativa del Help Desk o respecto a los niveles de cumplimiento o acuerdos de nivel de servicio establecidos. 

A modo de ejemplo recuerdo una anécdota de hace años cuando participé en la implantación de un Service Desk en una multinacional española. En los Acuerdos de Nivel de Servicio se definió un tiempo de respuesta para cada una de las posibles peticiones de servicio que se podían realizar. En concreto, la solicitud de un nuevo PC, porque por ejemplo se incorporaba un nuevo empleado, tenía un tiempo de respuesta de dos semanas. Se entendió que ese era el tiempo necesario para gestionar la compra. La realidad es que, para ofrecer un mejor servicio, gestionábamos un pequeño stock de PCs. De esta manera, la instalación de un nuevo equipo se realizaba en dos días. La opinión del usuario era que dos días era un tiempo excesivo. Sin embargo, cuando conocían que los acuerdos de nivel de servicio estipulados nos permitían poder hacerlo en dos semanas, su percepción de la calidad del servicio variaba enormemente. 

Problema en la atención que el personal del Help Desk presta a los usuarios. Falta de empatía, cortesía, habilidades de escucha, falta de una guía de atención al usuario, etc. 

Simplificando mucho también, podemos decir que hay dos tipos de opciones: a) poner en la primera línea técnicos primando así la eficacia en la resolución de las incidencias y b) poner en la primera fila personal “no técnico” con mayores dotes sociales primando así la calidad en la atención. 

A mí, personalmente, me gusta poner técnicos. Esto implica que es necesario enfatizarles la importancia de la atención al usuario, así como establecer sesiones o cursos de formación en habilidades sociales básicas asociadas al tratamiento, por ejemplo, de usuarios enojados o incluso poco educados. Muchas veces, la percepción que recibe el usuario del servicio que proporciona el Help Desk está relacionada con estos aspectos. 

Problema en la operativa y/o organización interna del Help Desk que hace que el servicio no sea eficiente (lo necesariamente rápido) ni eficaz (bueno). 

Podemos tener unos buenos acuerdos de nivel de servicio y, además, cumplirlos. Podemos también tener un personal preparado capaz de ser muy resolutivo y simpático. Si no tenemos unos buenos procedimientos de, por ejemplo, escalado, clasificación, priorización, seguimiento … de las incidencias, no seremos capaces de gestionar de forma adecuada dichas incidencias, así como quejas, consultas, peticiones de servicio, etc, que llegan al Help Desk. 

Todos estos procedimientos, asociados al proceso de gestión de incidencias, se deben definir y depurar hasta que sean ágiles y nos permitan cumplir con los acuerdos de nivel de servicio establecidos o, mucho mejor incluso, con las expectativas de los usuarios. 

En este punto me gustaría hacer hincapié en dos aspectos. El primero es el relativo a la base de datos de conocimiento. Es importante disponer de una en la que se documenten los errores conocidos, workarounds, etc, pero la primera base de datos de conocimiento es la base de datos de registro de incidencias. Si se documentan mínimamente bien, es posible atender a un usuario que nos llama diciendo que vuelve a tener un problema con la cola de impresión del AS/400 sin necesidad de ser un experto o tener conocimientos avanzados en dicho sistema. Es más, esta es una de las pruebas, intentar resolver incidencias en primera línea, que el responsable del Help Desk es aconsejable que realice de forma periódica. 

El segundo es el relativo a las peticiones de servicio. Es necesario definir todas aquellas peticiones de servicio que pueden realizar los usuarios de cada uno de los servicios del catálogo. Es necesario definir el flujo de trabajo asociado a cada una de estas peticiones (qué, quién y en qué orden), y es necesario automatizar esos flujos en una herramienta de gestión a la que accedan todas las áreas o departamentos implicados. ¿Es un trabajo?. Sí. ¿Funciona?. Por supuesto.

Editada la nueva versión de la ISO20000:1-2011 en español

UNE-ISO/IEC 20000-1:2011 . Tecnología de la información. Gestión del Servicio. Parte 1: Requisitos del Sistema de Gestión del Servicio (SGS).

Finalmente, desde el día 21 de diciembre de 2011, es posible conseguir la nueva versión de la norma ISO20000-1 en su versión de 2011, ya traducida al español.(http://www.aenor.es/aenor/normas/normas/fichanorma.asp?tipo=N&codigo=N0048609&pdf).

La norma original ISO/IEC 20000-1:2011 se liberó en inglés en abril de 2011, y tras 8 meses, finalmente ha visto la luz su homónima en castellano.

Durante este tiempo hemos tenido que trabajar con la norma inglesa, puesto que a partir del 1 de julio de 2012 las nuevas certificaciones deben seguir esta nueva versión de la norma, y por tanto, ya hemos utilizado esta versión para todos los proyectos que hemos liderado. (Las certificaciones anteriores deberán adaptarse antes del 1 de junio de 2013).

Las novedades de esta norma ya se han ido explicando en varios foros, teniendo siempre en cuenta la norma en inglés, pero a partir de ahora ya todos tenemos la oportunidad de contrastar la antigua norma UNE-ISO/IEC 20000-1:2007 (Tecnología de la información. Gestión del servicio. Parte 1: Especificaciones. (ISO/IEC 20000-1:2005)), con la nueva versión de 2011.

Por poner un ejemplo de las diferencias entre ambas versiones: en la de 2007 se podía encontrar la palabra “debe” 183 veces, y en la nueva versión se repite en 257 ocasiones. Eso demuestra que se requerirá una madurez mayor para cumplir algunos aspectos, que deberán cumplir todas las empresas que quieran demostrar que siguen un Sistema de Gestión de Servicios (SGS) para proveer sus servicios de TI.

A modo anecdótico informar que la nueva versión cuesta 31,62€, y tiene en total 36 páginas (la versión del 2007 costaba 28,44 y tenía 21 páginas).

¿Cómo abordar un Plan de adecuación a los requerimientos del Esquema Nacional de Seguridad?

El año 2010 trajo consigo un nuevo referente en el marco regulatorio legal, el Real Decreto 3/2010, de 8 de enero (BOE de 29 de enero), por el que se regula el Esquema Nacional de Seguridad (en adelante ENS) en el ámbito de la administración de Acceso Electrónico a los Ciudadanos. Este Real Decreto supone, además, un nuevo marco legal para las Administraciones Públicas, que junto al estándar internacional ISO 27002 o el Real Decreto 1720/2007 de desarrollo de la LOPD, establecen una serie de medidas de seguridad a implantar en los sistemas de información. En el caso del ENS, el ámbito de aplicación abarca a aquellos sistemas que soportan los medios electrónicos de comunicación con los ciudadanos en los servicios públicos. Su objeto es establecer la política de seguridad en la utilización de medios electrónicos y está constituido por principios básicos y requisitos mínimos que permitan una protección adecuada de la información.

En el Esquema Nacional de Seguridad, se diferencian dos tipos de proyectos:
· Aquellos que se desarrollan después de la entrada en vigor.
· Los existentes con anterioridad a la publicación de la norma.

Los primeros deberán iniciarse bajo el paraguas de acción del ENS, sin embargo, en el caso de los segundos, se establece en un año el tiempo de adecuación para el cumplimiento de la normativa. Es precisamente en este momento, cuando cobra importancia el Plan de Adecuación ya que en el caso de que concurran circunstancias que impidan la plena aplicación de lo exigido, se puede disponer de un plan de este tipo que marque los plazos de ejecución. Estos plazos no podrán exceder los 48 meses, desde que entra en vigor el ENS, por tanto 2014.

Para las organizaciones a las cuales aplica este ENS, se aproxima la hora de “remangarse” y comenzar a realizar un Plan de Adecuación que programe la implantación de los requerimientos que específica antes de 2014. Pero llegado este momento, surge siempre la siguiente pregunta:

¿Por dónde empezar un Plan de Adecuación?

Abast Systems, con una dilatada experiencia en proyectos de seguridad de la información concibe un proyecto de adecuación al ENS en las siguientes fases:

Fase I: Política de Seguridad: Validar si la política existe y si cumple con los requisitos del Anexo II del ENS.

Fase II: Valoración de la Información: Valorar la información significa identificar los requisitos relevantes en las dimensiones de confidencialidad, integridad, autenticidad y trazabilidad.

Fase III: Valoración de los Servicios: Valorar los servicios significa identificar los requisitos relevantes en las dimensiones de confidencialidad, disponibilidad, autenticidad y trazabilidad.

Fase IV: Datos de Carácter Personal: En caso de que los sistemas gestionen datos de carácter personal se tendrán en cuenta los requerimientos del RD 1720/2007.

Fase V: Categorización de los sistemas: Se categorizarán los sistemas en base al Anexo I del ENS.Para ello Los niveles de seguridad determinados para la información se imputaran a todos los activos que manejen la información correspondiente. Los niveles de seguridad determinados para los servicios se imputaran a todos los activos que concurran para prestar el servicio correspondiente.

Fase VI: Declaración de aplicabilidad de las medidas del Anexo II del ENS: Se elaborará una relación de las medidas exigidas por el anexo II del ENS y que son de aplicación a los sistemas o subsistemas de la fase anterior. También se motivará la no-aplicabilidad de algunas de las medidas.

Fase VII: Análisis de Riesgos: En esta fase se realizará un análisis de riesgos en función de lo exigido por el Anexo II del ENS. Este análisis será diferente en función de las categorías de los sistemas:

Sistemas de Categoría Básica. Se realizará un análisis informal que:
- Identifique los activos más valiosos del sistema.
- Identifique las amenazas más probables.
- Identifique las salvaguardas que protegen dichas amenazas.
- Identifique los principales riesgos residuales.

Sistemas de Categoría Media. Se realizará un análisis semi-formal con un catálogo básico de amenazas y una semántica definida que:
- Identifique y valore cualitativamente los activos más valiosos del sistema.
- Identifique y cuantifique las amenazas más probables.
- Identifique y valore las salvaguardas que protegen dichas amenazas.
- Identifique y valore el riesgo residual.

Sistemas de Categoría Alta. Se realizará un análisis formal que:
- Identifique y valore cualitativamente los activos más valiosos del sistema.
- Identifique y cuantifique las amenazas posibles.
- Identifique las vulnerabilidades habilitantes de dichas amenazas.
- Identifique y valore las salvaguardas adecuadas.
- Identifique y valore el riesgo residual.

Fase VIII: Determinación de las carencias de los sistemas: En base al trabajo realizado en las fases anteriores se establecerá una relación de:
- Aquellas medidas de seguridad exigidas por el Anexo II que no se cumplen.
- Aquellas medidas de seguridad exigidas por el RD1720 para los datos de carácter personal, que no se cumplen.
- Aquellos riesgos no asumibles por la organización.

Fase IX: Plan de Mejora de la Seguridad: En el Plan de Mejora se detallan las actuaciones encaminadas a subsanar las deficiencias detectadas en la fase anterior. Cada acción correctiva se debe documentar mostrando las carencias que subsana, el plazo previsto de ejecución, y la estimación del esfuerzo económico que implica.

Por tanto, en base a nuestra experiencia y a nuestros casos de éxito, una adecuación al ENS debe realizarse por fases, implantando un sistema de gestión de seguridad de la información que permita garantizar la aplicación de las diferentes medidas (marco organizativo, marco operacional, medidas de protección) a los sistemas de acceso electrónico de los ciudadanos.
Un primer paso indispensable es el Plan de Adecuación y a dos años de 2014… ¿no os parece un buen momento para comenzarlo?

Gestión desde la nube

Los departamentos de TI afrontan el reto de reducir los costes, el retorno de las inversiones realizadas y la entrega de valor al negocio, ofreciendo a la organización servicios eficientes y de calidad. Teniendo en cuenta que las necesidades del negocio cambian constantemente, los departamentos de TI tienen que alinearse a ellas a fin de que el cumplimiento de las metas del departamento de TI permita cumplir las metas del negocio. Para ello es necesario implantar procesos TI que permitan por lo menos:

1.    Asegurar los servicios TI a sus usuarios para que estén disponibles, sean fiables y con buen rendimiento.

2.       Garantizar la mejora continua de los mismos.

3.       Reducir el coste total de provisión y soporte de los servicios TI.

4.       Gestionar el conocimiento de la empresa.

5.       Mejorar el flujo de información.

6.       Aumentar la satisfacción de los usuarios.

7.       Demostrar el valor y la aportación del departamento de TI.

Las incidencias y las peticiones que generan los usuarios al departamento de TI tienen un flujo de actividad que supone una importante carga, por ello, se debe poner énfasis en su automatización y optimizar su tratamiento en busca de altas cuotas de eficiencia.

La gestión de incidencias es el proceso que se ocupa del tratamiento de los sucesos que provocan la degradación o pérdida del funcionamiento normal de un servicio, con el objetivo fundamental de recuperar el servicio para el negocio lo más rápidamente posible. Se centra en restaurar el servicio cuanto antes, sin admitir dilaciones por investigaciones técnicas. Su objetivo es que todo servicio caído o degradado retorne cuanto antes a la normalidad. Mantener únicamente esta actividad frenética de “apaga fuegos” no es productivo.

Este proceso es el que más volumen de trabajo genera en TI. Además involucra a un número de actores bastante amplio, desde los teleoperadores, pasando por todas las áreas técnicas, hasta llegar a los desarrolladores de las aplicaciones. Hay que tener en cuenta que lo normal es atender ente 2 y 3 contactos por mes de cada usuario, relacionados a incidencias de servicio. Además hay que considerar que la tendencia es que este volumen de contactos se vaya incrementado, debido al aumento de la diversidad de dispositivos móviles y a la progresiva penetración de las TI en la actividad de la empresa. Por ello, es importante disponer de una organización perfectamente preparada y entrenada para su atención y resolución. Es necesario definir, en la actividad de clasificación, la prioridad con la que se debe tratar la incidencia. Igualmente ocurre a la hora de asignar un orden de resolución.

Actualmente el mercado ofrece muchas opciones para gestionar un departamento de TI y en concreto las incidencias y cambios. Muchos fabricantes de software disponen de herramientas con funcionalidades HelpDesk que permiten crear, gestionar y documentar todas las incidencias y problemas de una empresa. La implantación de una solución de este tipo requiere una mejora de los procesos que implica una mejora de conocimientos del personal y por supuesto una mejora en la tecnología. Una buena forma de mejora de procesos es la reingeniería de los mismos en base a las mejores prácticas (metodologías) existentes en el mercado. Esto implica una automatización y modernización de la infraestructura tecnológica así como un cambio en la manera de trabajar por parte de las personas implicadas. La adopción de todo ello no deja de ser un proceso complicado y en la mayoría de casos ligeramente largo. Sin embargo, la nube, el ya famoso y recurrente “cloud computing”, ofrece nuevas oportunidades de gestión TI. Adoptar una solución de gestión de TI basada en la nube, evita que tengamos que ampliar nuestra tecnología y la empresa se puede centrar en  mejorar los conocimientos del personal y adaptar los procesos a la nube sin que estos se vean afectados. Una puesta a punto rápida y sencilla, carente de licencias o agentes/clientes y una modalidad de pago fraccionada y correspondiente al uso que se da. Sin costes de mantenimiento y sin inversión en soporte.

1.    SaaS: modelo de distribución de software que proporciona a los clientes el acceso al mismo a través de la red, de manera que libera al cliente del mantenimiento de las aplicaciones, de operaciones técnicas y de soporte.

2.   Puesta en marcha: al no haber servicios de implantación ni formación en un tiempo muy reducido la herramienta está operativa.

3.     Disponibilidad: La modalidad de licenciamiento Saas ofrece un servicio continuo y accesible desde cualquier lugar y a cualquier hora, puesto que se ejecuta a través del navegador.  

4.       Ahorro: Una de las ventajas del cloud computing es el ahorro en tecnología ya que al estar en la nube no hay que comprar servidores o recursos. 

Service Desk: el Factor Humano

Como muchos otros, empecé mis pasos en el ámbito de las TI embarcando en una “galera”. Sí, una galera de combate. En ese momento –hace ya más de 10 años- el concepto de Service Desk no estaba tan extendido y era mucho más conocido y frecuente el término “Helpdesk”.

El volumen de llamadas entrantes era muy elevado y los SLA asociados a la gestión telefónica de la llamada, que por aquel entonces era la entrada principal de incidencias, peticiones, quejas, y preguntas varias, era bastante estricto en cuanto a los tiempos de respuesta y abandono.

El perfil de actividad de los usuarios y clientes que accedían al servicio de soporte era absolutamente típico, por este motivo en cuanto se abrían las líneas telefónicas, la ocupación de los agentes era inmediata y el colapso se producía acto seguido. Las llamadas entrantes, que no dejaban de fluir, entraban en el sistema, escuchaban las opciones y se distribuían en función de la lógica de saltos y grupos diseñada para el servicio en cuestión.

En pocos minutos, las colas empezaban a acumularse y el supervisor cual “cómitre” iniciaba la maniobra: ¡remo de combate!

En los supuestos 3 minutos de media que debía durar cada llamada para poder asimilar las colas en espera, se debía escuchar, entender, registrar, resolver y cerrar o escalar. El proceso de registro debía ser por otro lado completo y adecuado en cuanto a su descripción, categorización y priorización. Sólo puedo decir, que lo intentábamos.

Ahora los tiempos han cambiado y el usuario dispone de múltiples fórmulas para contactar con su Service Desk y existen muchos automatismos e integraciones que facilitan el proceso de registro. Ahora bien, dado su coste, no podemos afirmar aquí que la implantación de dichos automatismos esté muy extendida, por lo que las dificultades en el proceso de registro siguen estando patentes. El operador gestiona su tiempo para “procesar la información” según su criterio y según la presión que asimile.

¿De qué depende entonces? ¿Es un problema de falta de conocimientos? ¿De procedimientos? ¿De metodología de trabajo? En parte, y sólo en parte, ya que aunque existan, no se contempla el factor humano, y éste es, de momento, un elemento muy importante, tanto a la hora de proporcionar el soporte, como a la hora de efectuar el proceso de registro y aprender de él.

A mi entender, el problema guarda relación directa con los siguientes aspectos:

• El esfuerzo en cumplimentar los datos de registro correctamente todavía no se percibe como proporcional al valor intrínseco de la información que aportan. Por tanto, sigue faltando equilibrio entre el nivel de “detalle” requerido, su “valor” y el tiempo invertido en su tratamiento.

• Los procesos se ejecutan de forma intuitiva, y su recurrencia, más o menos continuada, establece las bases de trabajo.

De lo anteriormente descrito, algún lector podría desprender cierto grado de determinismo que le llevara a cuestionarse la utilidad de los estándares metodológicos y “best practices”. Pero no estoy hablando de determinismo, estoy hablando de aprendizaje.

“La capacidad de evaluar – el nivel más alto de la taxonomía cognitiva – se basa en el supuesto de que el estudiante, para ser capaz de evaluar, tiene que disponer de la información necesaria, comprender esa información, ser capaz de aplicarla, de analizarla, de sintetizarla y, finalmente, de evaluarla” (E.W. Eisner a propósito de B. Bloom. Perspectivas: revista trimestral de educación comparada (París. UNESCO: Oficina Internacional de Educación), vol. XXX, n° 3, septiembre 2000, págs. 423-432).

Así pues, el factor humano no es un elemento determinante, pero sí condicionante del contexto de la prestación del servicio, porque en ese proceso cognitivo de comprender, evaluar y aplicar la información participan aspectos como la inteligencia, el contexto social, la motivación, así como otros componentes emocionales del individuo.

Sin olvidar aspectos tan esenciales como disponer de un dimensionamiento correcto y de las herramientas necesarias, podemos afirmar que se requiere un cambio de enfoque, pero incluso antes de que le pongamos nombre (ITIL, ISO/IEC 20000, etc.) esta diversidad sólo podrá gestionarse con enfoques que aporten sistemática, es decir que:

X Jornada Internacional de Seguridad - ISMS

El martes 29 de Noviembre asistimos a la X Jornada Internacional de Seguridad de la Información organizada por el ISMS Forum Spain centrada en la CiberDefensa y CiberSeguridad.

El evento se celebró en la Ciudad de las Artes y las Ciencias de Valencia, un escenario que no conocíamos y que nos pareció idóneo para la jornada.

El congreso, que comenzó a las 9 y terminó pasadas las 18, contó con más de 20 ponentes de ámbitos distintos, desde expertos en seguridad, pasando por representantes de proveedores de seguridad hasta CISOs de importantes organizaciones.

Desde mi punto de vista (soy Consultor de Seguridad), las mejores ponencias fueron las posteriores al Coffee-break, concretamente :

• “La estrategia Española en materia de CiberSeguridad” de Javier Candau (Subdirector General Adjunto del Centro Criptológico Nacional, CCN)
• “Why security breaches are occurring? The Data Breach Investigations Report 2011” de Jelle Niemantsverdriet (Principal Consultant Forensics and Investigative Response), Verizon Business Security)

Javier Candau (cuyo apellido me pareció muy indicado para su profesión), comentó las distintas estrategias tomadas por otros países en cuanto a CiberSeguridad. Explicó las distintas amenazas a las que un país puede estar expuesto y de la importancia de proteger las infraestructuras críticas. Mencionó varios conceptos como el cibercrimen, el ciberespionaje, el hacktivismo o el ciberterrorismo. Dentro de la estrategia española, comentó la relevancia del Esquema Nacional de Seguridad (ENS).

Jelle Niemantsverdriet (@jelle_n) en una ponencia muy visual y llena de datos interesantes (se puede consultar aquí) remarcó la importancia de revisar los LOGS regularmente para conocer las intrusiones que las organizaciones sufren. Jelle en un baile de estadísticas de distintas fuentes, propone aprender de los errores de los demás. Comenta también que tal como ocurre en los accidentes de avión, las intrusiones no están normalmente producidas por un GRAN error, sino por la suma de pequeños errores que llevan a la catástrofe. El ponente mostró un gráfico con el descenso de brechas de información registradas en los dos últimos años. Su explicación a éste hecho es la mejora de los sistemas de seguridad, el incremento de la concienciación en seguridad de las organizaciones, el endurecimiento de la legislación y por tanto, que muchos crackers han sido detenidos con condenas severas. Otra de sus explicaciones al descenso es que las brechas de seguridad no se han producido en las grandes empresas, ya que estas han tomado mayor conciencia de la seguridad, sino que se dan en empresas mucho más pequeñas y que no detectan los ataques. En sus palabras, los crackers “ya no cazan elefantes, ahora cazan conejos”.

Después de un abundante y delicioso almuerzo a base de pequeñas tapas, la tarde se dividió en:

• Mesa redonda: “La entrada en vigor de la normativa española en materia de infraestructuras críticas”
• Mesa redonda: "El nuevo panorama de ciberamenazas. Casos de éxito y buenas prácticas."
• “El headhunting de profesionales y directivos de la Seguridad ¿Qué está demandando el mercado?" de Miguel Portillo (Associate Director, Michael Page Executive Search)

Las dos mesas redondas fueron muy interesantes, aunque por mi vocación, encontré más interesante la segunda (sobre ciberamenazas y casos prácticos), que la primera (centrada en normativa e infraestructuras críticas).

Por último, la ponencia de Miguel Portillo de Michael Page fue muy interesante al tratar de un tema totalmente distinto a todos los tratados durante la jornada. Se hizo una muy buena contextualización del mercado laboral europeo y español. Se centró en la figura del CISO, tanto en sus características personales como lo que demanda el mercado.

En conclusión, la valoración del evento fue muy positiva y creo que el resto de asistentes coincidirán en ello, tanto por la organización como por el contenido de las charlas. Espero poder asistir al siguiente evento ya que fue una magnífica experiencia.

El error más común a la hora de Analizar y Gestionar los Riesgos Tecnológicos

El análisis de riesgos tecnológicos es la piedra angular utilizada por el CISO para gestionar la seguridad de los sistemas de información. Consiste en un estudio pormenorizado de las amenazas y eventos a los que están expuestos los activos de información que conforman los servicios tecnológicos, y los impactos que se provocarían en el negocio en caso de que estas se materialicen.

Existen multitud de metodologías y de enfoques, pero a menudo, y sobre todo, cuando se decide abordar por primera vez un análisis de este tipo, se cometen errores de base que pueden comprometer el éxito del proyecto.

El análisis debe surgir con un doble objetivo, por un lado estudiar los riesgos asociados a los sistemas de información y su entorno, y por otro, aplicar las medidas necesarias para conocer, prevenir, impedir, reducir o controlar los riesgos estudiados hasta niveles aceptables por la organización.

Sin embargo, a pesar de que los objetivos suelen estar claros, no siempre se consiguen, ya que las organizaciones han elevado el grado de exigencia, como consecuencia tanto del aumento acelerado del volumen y dependencia de las tecnologías de la información, como de los nuevos escenarios (nuevas amenazas, tecnologías novedosas, vulnerabilidades escondidas, nuevas salvaguardas…) a los que nos enfrentamos.

Por tanto para conseguir gestionar los riesgos con éxito en este nuevo entorno más complejo, es necesario tener un equipo experto que plantee el análisis y gestión de riesgos como un conjunto de iteraciones, en las cuales, en cada una de ellas, se analice el escenario actual y se amplíe el nivel de detalle en función de las necesidades del negocio.

En ocasiones las organizaciones incurren en el error de plantear un análisis estático con un principio y un fin, al que no se le da continuidad en el futuro y donde se intenta analizar de golpe el todo. La clave, desde nuestro punto de vista, a la hora de abordar un proyecto de este tipo, es plantear el análisis en fases, en modo dinámico de gestión continua de tratamiento de riesgos, en la cual en las diferentes iteraciones del estudio se vayan incorporando nuevos servicios, aumentando el catálogo de amenazas, contando con nuevas salvaguardas. La gestión de riesgos consistirá en ir viendo cómo evoluciona el riesgo en cada iteración, implantando controles, actualizando el escenario tecnológico, garantizando que se toman decisiones para mitigar, transferir o asumir el riesgo hasta los niveles que la Alta Dirección considera como “aceptables”, creando a su vez valor al negocio mediante:

• Integración con los procesos organizacionales

• Forma parte de la toma de decisiones

• Atiende explícitamente los aspectos de incertidumbre

• Es sistemática, estructurada y oportuna

• Está alineada con el contexto externo e interno de la organización

• Es dinámica, iterativa y responde a los cambios

• Facilita la mejora continua en las organizaciones