Migrar hacia la nueva ISO/IEC 27001:2013


Como muchos ya sabéis se ha publicado la nueva versión de la ISO/IEC 27001:2005 bajo el nombre ISO/IEC 27001:2013.

En esta revisión la norma ha sufrido grandes cambios destacando por ejemplo la flexibilidad a la hora de elegir metodologías de análisis de riesgos o mejora continua, la estructura de documentación, nuevos controles, nuevos conceptos, etc. pero sobre todo en su estructura pasando a utilizar el modelo del “anexo SL” del que ya habló nuestro compañero Alberto Olmos en estas entradas: Sistemas de Gestión Integrados: anexo SL (I), Sistemas de Gestión Integrados: anexo SL (II).

Una vez publicada la nueva norma, se ha abierto un periodo (presumiblemente de dos años) durante el cual las organizaciones que deseen seguir certificadas deberán adecuar sus SGSI a la nueva versión. Esta “actualización” podrá consolidarse durante una auditoría de seguimiento, de recertificación, o incluso mediante una auditoría extraordinaria si se considera oportuno.

Muchos se preguntan qué va a suponer este proceso de actualización y si van a tener que rehacer todo el sistema de gestión. La respuesta no es sencilla: depende (si no esté post no sería tan largo). Si bien a nivel técnico no parece que la actualización vaya a suponer ningún trauma, en lo que respecta a la organización del SGSI sí que existen muchas consideraciones a tener en cuenta por lo que analicémoslo por partes.

Aunque no se trate de un cambio excesivamente relevante, empezaremos diciendo que el único documento que pasa a ser obligatorio es la declaración de aplicabilidad, aunque evidentemente todo el SGSI deberá estar correctamente documentado. Esto hace que quien ya tenga un SGSI funcionando pueda quedarse más o menos con la estructura actual de documentos, pero es de esperar que a medio plazo esta estructura vaya cambiando para tomar la forma del anexo SL, especialmente si se dispone de más de un sistema de gestión. Como ya comentó Alberto Olmos en los posts mencionados, ya era posible utilizar un modelo escalable y común a varias normas, pero no solía ser la opción más común, siendo el formato “un procedimiento por objetivo de control + manual de seguridad + política + indicadores” lo que más frecuentemente encontramos. Así pues, aunque nada obligará a quien ya tenga un SGSI a plantearse la reestructuración completa de la documentación, es un buen momento para abordar esta tarea (con el consiguiente coste, evidentemente).

Algo similar ocurre con la mejora continua y el proceso de análisis de riesgos. Se han suavizado mucho los requisitos para estos dos apartados, permitiendo otras formas más allá del PDCA, y no obligando a tener que identificar activos, amenazas y salvaguardas. Para muchos las alternativas a estas metodologías son terrenos poco explorados ya que hasta ahora andábamos ciegamente por el camino marcado, y ahora que tenemos alternativas tendremos que valorar si creemos que estos procesos pueden mejorarse, o si nos quedamos como estamos.

Otro apartado que llama especialmente nuestra atención es que se ha “movido” parte del peso que tenía el anexo A a la propia norma, pasando la norma a tener 130 requisitos (frente a los 102 previos) y quedándose el anexo A con 114 controles de los 133 que tenía. Estos movimientos, además de dar más peso a la norma (de la cual recordemos, no se pueden excluir requisitos), seguramente harán que gran parte de las medidas de seguridad que tradicionalmente se documentaban en los procedimientos se muevan al manual del SGSI o se redistribuyan en otros documentos de más alto nivel. Una vez más, podremos optar por hacer los menos cambios posibles, ya que lo importante es que esté documentado, pero puede acabar siendo un parche que haga que tanto requisitos de la norma como controles queden repartidos en documentos sin un orden claro dificultando su búsqueda y facilitando que controles periódicos se olviden o caigan en terreno de nadie. Parece pues obvio que lo ideal es dedicar tiempo y esfuerzos a redistribuir requisitos y controles de forma general, creando y destruyendo los procedimientos necesarios y asegurándonos de que no queden controles mal referenciados. En definitiva, un faenón, pero que a la larga será necesario hacer.

El hablar de los controles del anexo nos lleva directamente a otro de los grandes cambios, al menos en cuanto a la teoría, de la nueva versión: la forma de crear la declaración de aplicabilidad. Hasta ahora lo común era elegir los controles del anexo A que aplican al SGSI con su justificación, además de añadir los propios que se consideren necesarios, pero con la nueva versión el planteamiento es distinto. Ahora deberemos, a partir de un análisis de riesgos, determinar qué controles necesitamos, para después comparar esta lista con el anexo A asegurándonos de que no nos hemos dejado ninguno aplicable. Si bien el planteamiento es bastante más “idílico”, en la práctica estamos seguros de que habrá quien opte por seguir haciendo la declaración de aplicabilidad a la antigua usanza diciendo que sus controles derivan de un análisis de riesgos. Ya que el proceso de análisis de riesgos se debe hacer de todas formas, la nueva versión de la norma solo supondrá un cambio de planteamiento, pero dudo que suponga ningún dolor de cabeza para actualizarse.

Habrá también muchos cambios menores que hacer, aunque generalmente serán pequeñas tareas que habrá que hacer una única vez y revisar periódicamente. Es el caso de requisitos como hablar del contexto de la organización para poder determinar si el alcance es relevante, hacer énfasis en objetivos y medidas de rendimiento, o demostrar una mayor implicación de la dirección, pero como ya hemos dicho, no supondrán un cambio profundo en el planteamiento del SGSI.

Tras repasar los cambios principales, supongo que todos llegamos a la misma conclusión: para actualizarse habrá que replantearse muchas cosas. No tiene por qué ser un cambio traumático siempre y cuando se haga para mejorar, y aunque podamos parchear el SGSI para que parezca que cumple con la nueva versión, aquí lo de “más vale malo conocido que bueno por conocer” no debe de ser la forma de actuar.

Para quienes no acaben de convencerse del cambio, aquí les dejamos una dosis de motivación.

Más información:
https://bsiedge.bsi-global.com/iso27001fdis/
http://www.bsigroup.es/es/certificacion-y-auditoria/Sistemas-de-gestion/Novedades/Noticias-2013/LD-News-Source-/210957/

Comments

  1. pREGUNTA:

    Cuando dices “el único documento que pasa a ser obligatorio es la declaración de aplicabilidad, aunque evidentemente todo el SGSI deberá estar correctamente documentado” ¿a que te refieres? Porque me choca que solo un documento sea obligatorio y que a la vez todo tenga que estar documentado.

    ¿Y que se considera documentado? Por ejemplo, si tengo un procedimiento para dar de alta a un usuario en una aplicación modelado en una HelpDesk, y en la propia helpdesk se puede ver el flujo de tareas y grupos que las resuelven, ¿es suficiente para considerar el procedimiento como “documentado”?

    Saludos!

  2. Usuario Pirri, entiendo que el concepto sea confuso: se deberá tener un documento con la declaración de aplicabilidad o SOA(como hasta ahora), pero el resto de cosas que deben estar documentadas podrán estructurarse como más cómodo os resulte. Esto podría servir, por ejemplo, para en lugar de tener un documento con una política de seguridad, otra de calidad, otra medioambiental, etc. se podrá tener un documento que las englobe a todas, ya que lo relevante es que esté documentado, pero el como y donde será menos restrictivo que hasta ahora.

    Sobre lo que se considera tenerlo documentado, en la versión de 2005 tienes todo el apartado 4.3 que explica los requisitos para la documentación. A grandes rasgos, para que se considere documentado tiene que estar aprobado por quien corresponda, garantizar que se revisa periódicamente y que está actualizado, tener un control de cambios sobre el documento, que esté disponible para quien lo necesite, que se gestione de acuerdo con el procedimiento de control de documentación y marcar correctamente las versiones obsoletas del procedimiento(hay algún requisito más, pero estos son los principales). Si con la estructura que planteas puedes asegurar que se da cumplimiento a todos estos puntos, entonces se puede considerar documentado. Si no fuese así, lo más común es plasmar todo el procedimiento en un documento.

    Un saludo.

  3. Ok, entendido!

  4. Entiendo, después de leer tu post, por qué ofrecen 2 años para adaptarse a la norma…puede ser un follón en función de la base de que se dispone.

  5. Hola a todos

    ¿Hay una guía documentada para poder realizar la transición de la ISO27001-2005 a la ISO 27001-2013?

    Gracias por su respuesta.

  6. Hola Otoniel,

    aquí tienes la guia que publicó BSI (de momento en ingles): http://www.bsigroup.com/LocalFiles/en-GB/iso-iec-27001/resources/BSI-ISO27001-transition-guide-UK-EN-pdf.pdf