Adaptando a la ISO 27001:2013 – Declaración de aplicabilidad

En octubre de 2013, hace poco más de un año y medio, se publicaba la nueva versión de la ISO/IEC 27001:2013.

Mucha era la expectación que se había creado en torno a esta nueva versión y los análisis empezaban a inundar las páginas web del sector y los grupos de LinkedIn. A los pocos días de la publicación en inglés de la norma, publicamos un exhaustivo análisis sobre los cambios que a priori se esbozaban del estándar.

La traducción al castellano, UNE-ISO/IEC 27001:2014, llegó más de un año más tarde, dejando poco margen a las organizaciones que habían estado esperando a la norma en castellano para su adaptación. Recordemos que el plazo que daban desde ISO (International Organization for Standardization) era de dos años desde su publicación en octubre de 2013. Esta situación habrá supuesto un reto para muchas organizaciones.

La adaptación se esbozaba tranquila, pero es durante el proceso de adecuación cuando realmente se pueden comprender los cambios y ha sido cuando han surgido algunas cuestiones o puntos de controversia. No voy a entrar, de momento, en todos los detalles de la adaptación pero sí me voy a centrar en uno de esos aspectos relevantes y que todo auditor pide prácticamente nada más entrar por la puerta: la declaración de aplicabilidad.

La declaración de aplicabilidad surge del tratamiento del riesgo y define los controles que debe implementar la organización para tratar los riesgos. Estos controles pueden venir definidos por requisitos contractuales, legales, si fuese el caso, o por otros casos como vamos a ver en este post. La declaración de aplicabilidad es esa gran conocida por todos y que no muchos entienden. Algunos se preguntan o nos hemos preguntado en alguna ocasión: ¿por qué tengo que justificar los controles que implanto? ¿De qué me sirve tener un listado completo de los controles? ¿Qué tengo que añadir en esta declaración?

Cuando empezamos a trabajar en el nuevo SoA (Statement of Applicability), y después de leer y analizar el apartado 6.1.3 del estándar, se nos planteó la cuestión sobre qué controles realizarlo. En el sub-apartado b) indica que: se deben determinar todos los controles que sean necesarios para implementar las opciones de tratamiento de riesgos de seguridad de la información.

Además hay una NOTA que indica que las organizaciones pueden diseñar controles según sea necesario, o identificarlos a partir de cualquier fuente. Esto, a mi entender, nos indica que no podemos quedarnos solo con el anexo sino que la norma requiere que vayamos más allá y hagamos un ejercicio de análisis exhaustivo de tal manera que identifiquemos todos los controles que la organización pueda necesitar para posteriormente comparar estos con los del anexo y ver que no nos hemos dejado ninguno.

¿Cómo lo hemos hecho? Como hacer ese ejercicio y sacar de la manga controles a cascoporro es un ejercicio un poco marciano, decidimos apoyarnos en fuentes ya definidas. Según el caso podemos utilizar unas u otras. Por ejemplo, en el caso de una entidad bancaria se pueden aplicar los controles definidos por la LOPD (según el nivel de los datos), por el Anexo A de la propia ISO 27001 y probablemente los definidos por la ley de seguridad privada. En otros organismos podrían utilizarse los de otras normas o leyes como pueden ser las medidas del Anexo II del Esquema Nacional de Seguridad u otros controles concretos definidos por la organización. En definitiva, el SoA debe contener aquellos controles necesarios para poder llevar a cabo el tratamiento de riesgos; ya sean controles definidos por fuentes con las que de algún modo deba cumplir la organización o establecidos directamente por esta.

Para llevar a cabo el SoA, una posibilidad es utilizar PILAR, una vieja conocida de todos los que en este mundillo hemos tenido que realizar un análisis de riesgos y que nos permite establecer los controles derivados de la LOPD, del Anexo II del ENS y Anexo A de la ISO 27001.

Para identificar los controles y justificar la inclusión y la exclusión (en el caso del Anexo A), debemos ir a E.Perfiles de seguridad y en cada uno de los perfiles indicar aquellos controles que aplican.

Por ejemplo, podría ser que aplicasen los controles LOPD de nivel básico, [mp] Medidas de protección del ENS y todos los controles del Anexo A de la ISO 27001:2013 a excepción del 6.2.2, teletrabajo. En ese caso deberíamos justificar la exclusión de este último y la inclusión del resto de controles seleccionados. Para generar el SoA desde cada uno de los perfiles podemos exportarlos desde la aplicación, donde aparecerán los controles y las justificaciones que hayamos introducido.

Por último, los controles seleccionados llevan consigo unas salvaguardas que habrá que identificar y valorar según el estado de la organización ya que éstas mitigan el riesgo. Para ello en la pestaña A.3.Salvaguardas > Identificación, al seleccionar el botón “sólo si…“ podemos elegir aquellos perfiles de seguridad que hayamos utilizado como fuente y que nos permitirá valorar las salvaguardas recomendadas en cada uno de ellos.

Algunos os habréis preguntado… ¿puedo poner en la declaración de aplicabilidad solo los controles que tengo implantados? ¿Podría certificarme si en la organización solo tenemos un porcentaje muy bajo de controles implantados? Pues contestando a esas preguntas, el SoA debe contener los controles necesarios, entre los que deben estar todos los del anexo A, estén implantados o no.

Además, para los del anexo se deben justificar tanto las inclusiones como las exclusiones. Respecto a qué cantidad de controles es necesario tener implantados para poder certificarse no hay nada establecido ya que dependerá de la organización, del estado de madurez, del tamaño… y esto queda, a mi entender, “a criterio del auditor”, siendo posible certificar SGSIs que a pesar de no tener todos los controles implantados, tengan una buena justificación o planificación para implantarlos.

Conclusión: el cambio de la declaración de aplicabilidad de no seleccionar los controles del Anexo A directamente, sino tener que determinar los controles necesarios como parte del tratamiento de riesgos y, posteriormente, comparar con la 27001:2013, parece un cambio menor pero que a más de uno nos ha supuesto un quebradero de cabeza dar con la forma adecuada para llevarlo a cabo.

Espero que este pequeño análisis sobre la declaración de aplicabilidad y el cambio producido en esta nueva versión de la norma os ayude a hacer lo propio en vuestras organizaciones o a entender este requisito que en ocasiones no se llega a comprender. Cualquier duda o comentario podéis dejarlo en, valga la redundancia, los comentarios.