Seguro & Simple - Una Guia para La Pequeña Empresa para La Implementación de La Iso 27001 Con Medios Propios

1
2
Seguro & Simple:
Una guía para la pequeña empresa para la implementación
de la ISO 27001 con medios propios
3
También de Dejan Kosutic:
Ciberseguridad en 9 pasos El manual sobre seguridad

de la información para el gerente
Becoming Resilient: The Definitive Guide to ISO 22301

Implementation
4
Dejan Kosutic
Seguro & Simple:

Una guía para la pequeña empresa para la implementación
de la ISO 27001 con medios propios
El manual, con un idioma plano, paso a paso, para

los profesionales de seguridad de la información
Advisera Expert Solutions Ltd

Zagreb, Croatia
5
Copyright ©2016 by Dejan Kosutic
Todos los derechos reservados. Ninguna parte de este libro puede ser
reproducida, almacenada en un sistema de recuperación, o transmitida
en cualquier forma o por cualquier medio, electrónico, mecánico, fo-
tocopia, grabación u otro tipo, sin el permiso escrito del autor, excep-
tuando la inclusión de breves citas en un informe.
Límite de responsabilidad / exención de garantía: Aunque que el edi-

tor y el autor han utilizado sus mejores esfuerzos en la preparación de
este libro, no hacen ninguna representación o garantía con respecto a
la exactitud o la exhaustividad de los contenidos de este libro, y espe-
cíficamente niegan cualquier garantía implícita de comerciabilidad o
idoneidad para un propósito en particular. Este libro no contiene toda
la información disponible sobre el tema. Este libro no ha sido creado
para ser específico para cualquier individuo, o para situaciones o nece-
sidades específicas de una organización. Usted debe consultar con un
profesional para cada caso. El autor y el editor no tendrán ninguna obli-
gación o responsabilidad de cualquier persona o entidad con respecto
a cualquier pérdida o daño incurrido, o alegado de haber incurrido,
directa o indirectamente, por la información contenida en este libro.
Publicado por primera vez por Advisera Expert Solutions Ltd

Zavizanska 12, 10000 Zagreb
Croatia
Unión Europea
http://advisera.com
ISBN: 978-953-57452-7-3
Primera edición, 2016
Título original: “Secure & Simple: A Small-Business Guide to Implemen-

ting ISO 27001 On Your Own”
Traducido del Inglés por Antonio José Segovia
6
A mi esposa, que me ha hecho sentirme seguro;
y que ha hecho que todo lo demás sea posible.
7
SOBRE EL AUTOR
Dejan Kosutic es autor de numerosos artículos, video tutoriales, plan-

tillas de documentos, webinars y cursos sobre gestión de seguridad de
la información, y sobre gestión de continuidad del negocio. Él también
es el autor del blog líder sobre ISO 27001 & ISO 22301, y ha ayudado
a varias organizaciones, incluyendo instituciones financieras, agencias
gubernamentales, y empresas de TI, a implementar la gestión de la se-
guridad de la información según estos estándares.
Click aquí para ver su perfil de LinkedIn profile.
8
TABLA DE CONTENIDOS
SOBRE EL AUTOR............................................................................................8
LISTADO DE FIGURAS....................................................................................15
1 INTRODUCCIÓN..........................................................................................17
1.1 ¿Por qué la seguridad de la información? ¿Por qué ISO 27001?..............17
1.2 Principios básicos de seguridad de la información ..................................19
1.3 ISO 27001 lo une todo...........................................................................20
1.4 ¿Quién debería leer este libro?...............................................................21
1.5 Cómo leer este libro...............................................................................22
1.6 Lo que no es este libro............................................................................23
1.7 Recursos adicionales...............................................................................24
2 ¿QUÉ ES EXACTAMENTE LA ISO 27001?...................................................26

2.1 El estándar más popular de seguridad de la información.........................26
2.2 Seguridad de la información vs. Seguridad TI..........................................28
2.3 Cómo funciona la ISO 27001.................................................................29
2.4 L o que no es la ISO 27001 – Los 7 mitos más comunes...........................31
2.5 ¿A qué pertenece la seguridad de la información? ...................................... 33
2.6 Para qué tipo de empresa y tamaño está pensada la ISO 27001.................... 35
2.7 Breve historia de la ISO 27001....................................................................... 37
2.8 ¿Cuál es el aspecto del estándar? Su estructura y cláusulas principales.......... 39
2.9 Introducción al Sistema de Gestión de Seguridad de la Información.............. 41
3O
BTENER LA PARTICIPACIÓN DE LA ALTA DIRECCIÓN
Y OTROS EMPLEADOS ..............................................................................44
3.1 Cómo convencer a la alta dirección para implementar la ISO 27001.............. 44
3.2 Cómo presentar los beneficios a la alta dirección........................................... 47
3.3 ¿Es posible calcular el Retorno de la Inversión en Seguridad (RIS)?................. 48
3.4 Tratar con la línea de responsables y otros empleados................................... 50
3.5 Cerrar la brecha entre TI y el negocio............................................................. 51
3.6 Factores de éxito............................................................................................ 53
4 PREPARACIÓN PARA LA IMPLEMENTACIÓN.............................................54

4.1 Estrategia ISO 27001: Tres opciones para la implementación......................... 54
4.2 Cómo seleccionar un consultor...................................................................... 57
4.3 ¿Debería usar un análisis de brecha?............................................................. 58
4.4 Secuencia para la implementación de la ISO 27001 &
relación con el ciclo PDCA.............................................................................59
4.5 Estableciendo un proyecto para la implementación de la ISO 27001............. 60
9
4.6 Quién debería ser el responsable de proyecto ............................................... 62
4.7 ¿Cuánto puede durar?.................................................................................. 64
4.8 ¿Cuánto puede costar? ............................................................................... 65
4.9 Usar herramientas y plantillas ....................................................................... 68
4.10 Decida su estrategia de documentación...................................................... 70
4.11 Factores de éxito.......................................................................................... 72
5 PRIMEROS PASOS EN EL PROYECTO........................................................ 73
5.1 Comprender el contexto de su organización (cláusula 4.1)............................ 73
5.2 Listado de partes interesadas y sus requerimientos (cláusula 4.2)................... 76
5.3 Definición del alcance del SGSI (cláusula 4.3)................................................. 78
5.4 Qué se le requiere a la alta dirección (cláusula 5.1)........................................ 82
5.5 Escribir la política de seguridad de la información (cláusula 5.2)..................... 83
5.6 Definir los objetivos del SGSI de alto nivel (cláusulas 5.2 b y 6.2)................... 86
5.7 Roles y responsabilidades, y cómo documentarlas (cláusula 5.3).................... 88
5.8 Factores de éxito............................................................................................ 90
6 CUESTIONES NO RELACIONADAS CON LA SEGURIDAD,
NECESARIAS PARA GESTIONAR LA SEGURIDAD..................................... 91
6.1 Gestionar documentos y registros (cláusula 7.5)............................................ 91
6.2 Proporcionar recursos para el SGSI (cláusula 7.1)........................................... 94
6.3 Proporcionar formación en seguridad (cláusula 7.2)....................................... 95
6.4 Concienciar a tu gente en por qué es importante la seguridad
de la información (cláusula 7.3).....................................................................97
6.5 Cómo comunicar y con quien (cláusula 7.4).................................................. 99
6.6 Factores de éxito.......................................................................................... 101
7 GESTIÓN DE RIESGOS............................................................................. 102
7.1 Abordar riesgos y oportunidades (cláusula 6.1.1)........................................ 102
7.2 Cinco pasos en el proceso de gestión de riesgos (cláusula 6.1)................... 103
7.3 Escribir la metodología de análisis de riesgos (cláusula 6.1.2)...................... 105
7.4 Análisis de riesgos parte I: Identificando riesgos (cláusulas 6.1.2 y 8.2) ...... 109
7.5 Análisis de riesgos parte II: Analizando y evaluando riesgos
(cláusulas 6.1.2 y 8.2) ................................................................................ 112
7.6 Realizando el tratamiento de riesgos (cláusulas 6.1.3 y 8.3)........................ 115
7.7 Declaración de aplicabilidad: El documento central de todo el SGSI
(cláusula 6.1.3 d)........................................................................................ 119
7.8 Desarrollando el Plan de tratamiento de riesgos (cláusulas 6.1.3, 6.2, y 8.3)... 122
7.9 Factores de éxito......................................................................................... 125
8 IMPLEMENTANDO CONTROLES DE SEGURIDAD;

CONTROL Y PLANIFICACIÓN OPERACIONAL ....................................... 127
8.1 Establecimiento de objetivos para controles de seguridad y procesos
(cláusula 6.2)..............................................................................................128
8.2 Por dónde empezar con la documentación.................................................130
10
8.3 Decidir qué políticas y procedimientos escribir........................................... 131
8.4 Escribir la documentación que será aceptada por todos los empleados...... 133
8.5 Operar el SGSI con una periodicidad diaria (cláusula 8.1)........................... 136
8.6 Gestionar cambios en el SGSI (cláusula 8.1)............................................... 137
8.7 Mantenimiento de la documentación (cláusula 7.5.2)................................ 138
8.8 Gestión de servicios externalizados (cláusula 8.1)....................................... 139
8.9 Revisión periódica del análisis y tratamiento de riesgos (cláusula 8.2)......... 141
8.10 Factores de éxito...................................................................................... 142
9 RESUMEN DE LOS CONTROLES DEL ANEXO A......................................144

9.1 Introducción al Anexo A de la ISO 27001...................................................144
9.2 Estructura del Anexo A...............................................................................145
9.3 Estructurar la documentación para el Anexo A...........................................147
9.4 Política de seguridad de la información (A.5)..............................................149
9.5 Organización de la seguridad de la información (A.6).................................150
9.6 Seguridad relativa a los recursos humanos (A.7).........................................152
9.7 Gestión de activos (A.8)..............................................................................153
9.8 Control de acceso (A.9)..............................................................................155
9.9 Criptografía (A.10)......................................................................................157
9.10 Seguridad física y del entorno (A.11)........................................................158
9.11 Seguridad de las operaciones (A.12).........................................................160
9.12 Seguridad de las comunicaciones (A.13)...................................................163
9.13 Adquisición, desarrollo y mantenimiento de los
sistemas de información (A.14).................................................................165
9.14 Relación con proveedores (A.15).............................................................. 168
9.15 Gestión de incidentes de seguridad de la información (A.16)....................169
9.16 Aspectos de seguridad de la información para la gestión de la
continuidad del negocio (A.17)............................................................... 172
9.17 Cumplimiento (A.18)...............................................................................174
9.18 Factores de éxito......................................................................................176
10 ASEGÚRESE DE QUE EL SGSI FUNCIONA SEGÚN LO ESPERADO...... 177

10.1 Monitorizar, medir, analizar y evaluar el SGSI (cláusula 9.1)...................... 177
10.2 Auditoría interna parte I: Preparación (cláusula 9.2)................................. 180
10.3 Auditoría interna parte II: Pasos en la auditoría & preparación
de la lista de verificación ......................................................................... 183
10.4 Revisión por dirección que tenga sentido (cláusula 9.3)........................... 186
10.5 Uso práctico de las no conformidades y acciones correctivas
(cláusula 10.1)......................................................................................... 188
10.6 Mejora constante del SGSI (cláusula 10.2)................................................191
10.7 Factores de éxito.......................................................................................192
11
11 ASEGURAR QUE SU COMPAÑÍA PASA LA CERTIFICACIÓN..................193
11.1 ¿Realmente necesita el certificado?...........................................................193
11.2 Certificación vs. registro vs. acreditación....................................................194
11.3 Últimos preparativos antes de la certificación.............................................198
11.4 Cómo seleccionar una entidad certificadora..............................................200
11.5 Pasos en la certificación de la compañía y cómo prepararse.......................201
11.6 ¿Qué cuestiones le preguntará el auditor de certificación ISO 27001?.......203
11.7 Cómo hablar con los auditores para beneficiarse de la auditoría................206
11.8 Qué puede hacer y qué no puede hacer un auditor...................................207
11.9 No conformidades y cómo resolverlas........................................................209
11.10 Factores de éxito......................................................................................212
12 CAPÍTULO EXTRA I: OPORTUNIDADES DE CARRERA EN ISO 27001....213

12.1 Cursos más populares a los que asistir.......................................................214
12.2 ¿En qué se parece el Curso de Auditor Jefe y el Curso de
Implementador Jefe?.................................................................................215
12.3 Cómo convertirse en un auditor de certificación........................................216
12.4 Cómo convertirse en consultor..................................................................217
13 CAPÍTULO EXTRA II: ESTÁNDARES RELACIONADOS,

CONCEPTOS, Y MARCOS DE TRABAJO.................................................221
13.1 Los estándares más importantes de la serie ISO 27k.................................. 221
13.2 ISO 27001 vs. ISO 27002........................................................................... 223
13.3 ISO 27001 vs. ISO 27005 vs. ISO 31000 ................................................... 224
13.4 ISO 27001 vs. ISO 27017 vs. Seguridad en la nube.................................... 226
13.5 ISO 27001 vs. ISO 27018 vs. Privacidad en la nube.................................... 228
13.6 ISO 27001 vs. ISO 27032 vs. ciberseguridad.............................................. 231
13.7 Relación entre ISO 22301, ISO 20000, ISO 9001, ISO 14001 e ISO 45001...233
13.8 Usar la ISO 22301 para la implementación de la continuidad de
negocio en ISO 27001 ..............................................................................235
13.9 ISO 27001 y COBIT, PCI DSS, NIST SP800, NIST
Cybersecurity Framework e ITIL..................................................................237
13.10 ISO 27001 como plataforma de cumplimiento para varios
marcos de trabajo....................................................................................238
14 CAPÍTULO EXTRA III: MINI CASOS DE ESTUDIO DE ISO 27001........... 240

14.1 Definir un alcance de SGSI para un pequeño proveedor
de servicios en la nube............................................................................... 240
14.2 Aplicar principios de ingeniería seguros en una empresa de
desarrollo de software............................................................................... 242
14.3 Concientización en una agencia del gobierno............................................ 243
14.4 Obtener el apoyo de la alta dirección en una compañía de
propiedad estatal.......................................................................................245
14.5 Listar las partes interesadas y sus relaciones en un banco Europeo.............246
12
14.6 Escribir las políticas de seguridad de la
información en una compañía de manufacturación...................................248
14.7 Preparar una compañía de telecomunicaciones para la certificación..........249
14.8 Realizar el análisis de riesgos en un pequeño
hospital......................................................................................................251
14.9 Establecer objetivos de seguridad y mediciones en una
compañía de servicios................................................................................253
14.10 Implementando ISO 27001 en Centros de Procesamiento
de Datos – Una entrevista........................................................................255
15 ¡BUENA SUERTE!....................................................................................264
APÉNDICE A – LISTA DE VERIFICACIÓN DE LA DOCUMENTACIÓN

OBLIGATORIA DE LA ISO 27001:2013................................265
APÉNDICE B – DIAGRAMA DE IMPLEMENTACIÓN

DE LA ISO 27001:2013.........................................................273
APÉNDICE C – APLICABILIDAD DE LA ISO 27001 DIVIDIDO

POR INDUSTRIA...................................................................275
APÉNDICE D – INFOGRAFÍA: ISO 27001 (REVISIÓN 2013) –

¿QUÉ HA CAMBIADO?........................................................278
APÉNDICE E – MATRIZ ISO 27001 VS ISO 20000........................................282
APÉNDICE F – PLANTILLA PROPUESTA PROYECTO PARA LA

IMPLEMENTACIÓN DE LA ISO 27001 .................................292
APÉNDICE G – LISTA DE VERIFICACIÓN PARA LA IMPLEMENTACIÓN

DE LA ISO 27001 ................................................................299
APÉNDICE H – PLAN DE PROYECTO PARA LA IMPLEMENTACIÓN

DE LA ISO 27001 ................................................................303
APÉNDICE I – LISTA DE PREGUNTAS PARA HACERLE A SU

CONSULTOR ISO 27001........................................................311
APÉNDICE J – LISTA DE PREGUNTAS PARA HACERLE A UNA

ENTIDAD CERTIFICADORA DE ISO 27001...........................314
APÉNDICE K – INFOGRAFÍA: EL CEREBRO DE UN AUDITOR ISO – QUÉ

ESPERAR DE UNA AUDITORÍA DE CERTIFICACIÓN...........317
13
APÉNDICE L – ¿CUÁL ES EL TRABAJO DEL RESPONSABLE DE
SEGURIDAD (CHIEF INFORMATION SECURITY
OFFICER -CISO) EN ISO 27001?.......................................... 321
APPENDIX M – CATÁLOGO DE AMENAZAS Y VULNERABILIDADES....... 325
GLOSARIO.................................................................................................. 330
BIBLIOGRAFÍA............................................................................................ 332
ÍNDICE........................................................................................................ 334
LISTADO DE FIGURAS
FIGURA 1: NÚMERO DE CERTIFICADOS ISO 27001
(FUENTE: ENCUESTA ISO).............................................................. 27
FIGURA 2: RELACIÓN ENTRE SEGURIDAD DE LA INFORMACIÓN,

GESTIÓN DE RIESGOS, CONTINUIDAD DE NEGOCIO,
TI Y CYBER-SEGURIDAD................................................................ 34
FIGURA 3: PALABRAS A EVITAR Y PALABRAS A USAR CUANDO

SE PRESENTA LA SEGURIDAD DE LA INFORMACIÓN...................... 48
FIGURA 4: GRÁFICO DE LOS PROCESOS DEL SGSI INDICADOS

EN EL ALCANCE DEL SGSI............................................................. 80
FIGURA 5: CINCO PASOS EN EL PROCESO DE GESTIÓN DEL RIESGO............ 103
FIGURA 6: EJEMPLO DE TABLA DE EVALUACIÓN DE RIESGOS

CON RIESGOS IDENTIFICADOS.................................................... 112
FIGURA 7: EJEMPLO DE TABLA DE EVALUACIÓN DE RIESGOS...................... 114
FIGURA 8: EJEMPLO DE TABLA DE TRATAMIENTO DE RIESGOS.................... 118
FIGURA 9: EJEMPLO DE DECLARACIÓN DE APLICABILIDAD ........................ 121
FIGURA 10: EJEMPLO DE PLAN DE TRATAMIENTO DE RIESGOS.................... 124
FIGURA 11: EJEMPLO DE LISTA DE VERIFICACIÓN PARA

LA AUDITORÍA INTERNA............................................................ 185
14
AGRADECIMIENTOS
Agradecimiento especial a Ana Meskovska, quien me ayudó a escribir

el capítulo sobre el Anexo A de controles, y el capítulo sobre el control
y la planificación operacional; también un agradecimiento especial a
Antonio Segovia, quien me ayudó con las secciones sobre la ISO 27032,
y las cuestiones relativas al auditor de certificación.
Agradezco también a Rhand Leal y Buddhika De Alwis, por revisar el

libro - sus valiosos comentarios me han ayudado a hacer mejoras en
este libro.
Un agradecimiento final a mi equipo de Marketing - Ziółkowski y Vinko

Prelac, quienes me han ayudado a crear un producto atractivo con este
libro.
15
PREFACIO
Veo miles de visitantes leyendo diariamente mis artículos en el blog ISO

27001 Blog, y aunque muchos de ellos están agradecidos, algunos se
quejan un poco – dicen “Sí, sus artículos son útiles, pero hay muchos, y
simplemente no se por donde empezar y donde terminar.” Y en efecto
– en el momento de escribir este libro, había casi 200 artículos publica-
dos en 27001Academy; por tanto, tienen razón, es difícil usar todo este
conocimiento de una manera sistemática.
Por esta razón me decidí a escribir este libro – quería proporcionar a guía
completa, paso a paso, para la ISO 27001, escrita en un lenguaje sencillo,
que pueda ser entendido por principiantes sin conocimientos previos de
este estándar, escrito de una forma estructurada para que sepa dónde
comenzar y cómo terminar la implementación de la ISO 27001 de una
manera exitosa.
Y sí, lo admito – muchos de los contenidos de este libro están tomados de los
artículos más populares del blog, de mi libro Becoming Resilient, de nuestros
cursos online, y de otros materiales, porque pensé que un libro que presente
estos materiales de una manera estructurada, proporcionaría un buen valor.
Pero lo que creo que más le gustará de este libro es que le doy respues-
tas prácticas a situaciones de la vida real, a la hora de implementar la
ISO 27001. Estos consejos vienen principalmente de mi interacción con
muchas personas que están haciéndome preguntas diariamente – Fui lo
suficientemente afortunado para impartir muchos cursos presenciales, y
webinars online, y contestar miles de preguntas a través de foros, llevar
a cabo muchos trabajos de consultoría, y hablar en una serie de confe-
rencias. En todas estas ocasiones me vi obligado a pensar en muchas
cuestiones relacionadas con la ISO 27001, y a proporcionar las mejores
prácticas sobre cómo manejarlas.
Por lo tanto, después de leer este libro, usted será capaz de implementar
el estándar, ya que le proporcionará suficientes conocimientos y consejos
para implementar el estándar en una pequeña o mediana empresa.
Espero haber tenido éxito en esto. ¡Disfrute su libro!
16
1
INTRODUCCIÓN
¿Por qué su organización necesitaría tener su información a salvo?

¿Cómo puede la ISO 27001 ayudarle a conseguir la seguridad de la
información? ¿Este libro es la mejor opción para ti?
1.1 ¿Por qué la seguridad de la información? ¿Por qué ISO 27001?

La seguridad de la información, la cyberseguridad, o la protección de
datos no son cosas que estén reservadas sólo para expertos de TI, esto
es algo que concierne a prácticamente cualquier persona en este pla-
neta, así como a cualquier empresa.
Si usted fuera un ejecutivo de una organización de hace diez años, pro-

bablemente no estaría tan preocupado con cualquiera de estas cosas.
Hoy en día, está en la segunda década del tercer milenio y no puede
ignorar las amenazas a sus datos. Además, en el futuro tendrá más
protección. ¿Por qué? Porque la mayoría de organizaciones está ahora
en el negocio de procesamiento de información.
La mayoría de nosotros imagina que un banco maneja grandes cantida-

des de dinero en efectivo todos los días. Y aunque los bancos todavía
manejan muchas transacciones de dinero en efectivo, la realidad actual
es que las transacciones de dinero electrónicas superan las transaccio-
nes de efectivo – en algunos casos por más de 1 millón a uno. Por lo
tanto, esto significa que un banco típico está en el negocio de proce-
samiento de la información – es una gran fábrica de información. Y
adivinen qué; desde hace algún tiempo hasta la fecha robar un banco
hackeando los sistemas informáticos es mucho más rentable que cami-
nar con una máscara sobre el rostro y robar físicamente los cajeros. El
hacking es mucho menos arriesgado, demasiado.
17
SEGURO & SIMPLE
Piense en su negocio; ¿es una fábrica de información, también? Es pro-
bable que su negocio, si no totalmente, entonces parcialmente esté ba-
sado en el procesamiento de información. Esto significa que su negocio
es más vulnerable. Su información, su conocimiento, su know-how y
la propiedad intelectual están en riesgo. Y ahora la pregunta del millón
de dólares, o si estás en un negocio más grande esta podría ser una
pregunta de mil millones de dólares: ¿Qué necesita hacer para proteger
la información de su empresa?, y ¿por dónde comenzar?
El problema es que en la actualidad hay una abundante información so-

bre seguridad de la información; probablemente sea bombardeado con
información sobre nuevo cortafuegos, software antivirus, frameworks,
metodologías, legislación y así sucesivamente. Muchas empresas ofre-
cen servicios que pretenden ser la solución a todos sus problemas de
seguridad. Sin embargo, estas soluciones individuales no van a prote-
gerle completamente. Por ejemplo, no puede resolver el problema de
un empleado disgustado con un firewall, de la misma manera que no
puede resolver el problema de un hacker solo por cumplir con una ley.
Por lo tanto, es obvio que necesita algo más, algo integral. Pero el de-
safío es cómo comenzar, qué pasos tiene que seguir para proteger de
la mejor manera su negocio.
Aquí es donde ISO 27001 entra – como se explica a lo largo de este

libro, ofrece un marco integral que le ayudará con este proceso crucial.
Le da la orientación necesaria y los cimientos para proteger su empresa.
ISO 27001 le indica por dónde empezar, cómo ejecutar su proyecto,
cómo adaptar la seguridad a las cuestiones específicas de su empresa,
cómo controlar lo que hacen los expertos de seguridad y de TI, y mucho
más.
Por lo tanto, lo principal es – ISO 27001 no tiene que ser un trabajo de

cumplimiento burocrático – si se aplica correctamente, puede ser una
herramienta muy eficiente no sólo para proteger su empresa, sino tam-
bién para obtener algunos beneficios.
18
Introducción
1.2 Principios básicos de seguridad de la información

Primero definamos qué es información. La información es un activo de
la organización, que tiene valor para la organización y debe ser prote-
gido adecuadamente. La información puede tener diversas formas y se
puede almacenar en diferentes medios.
Por otra parte, la seguridad de la información se puede definir como la

protección de la confidencialidad, la integridad y la disponibilidad de la
información en diversas formas, tales como escrita, hablada, impresa,
electrónica y así sucesivamente.
Veamos las definiciones oficiales de estos términos en ISO 27000: con-

fidencialidad es “propiedad que hace que la información no esté dispo-
nible o sea revelada a individuos no autorizados, entidades o procesos”,
integridad es “propiedad de exactitud e integridad”, y la disponibilidad
es “propiedad de ser accesible y usable bajo demanda por una entidad
autorizada”.
Sí, a veces es difícil entender esta terminología de la ISO, así que aquí
está una explicación fácil de estos conceptos básicos: si llego a un ban-
co y hago un depósito de $10.000, en primer lugar no quiero que nadie
sepa nada sobre este dinero excepto el Banco y yo. (Esto es confiden-
cialidad).
Dentro de unos meses cuando vuelva a retirar mi depósito, quiero la

cantidad de $10.000 más los intereses; No quiero que la cantidad sea
$1000 porque alguien ha jugado con mi cuenta. (Esto es integridad).
Por último, si quiero retirar mi dinero no quiero que el empleado del

banco me diga que los sistemas del Banco están sin funcionar y que
tengo que volver mañana. (Esto es la disponibilidad.)
ISO 27001 tiene exactamente el mismo enfoque – la protección de la

confidencialidad, integridad y disponibilidad (también conocido como
las 3 dimensiones CID); pero además va un paso más allá, explica cómo
hacerlo sistemáticamente en una empresa de cualquier tipo.
19
SEGURO & SIMPLE
1.3 ISO 27001 lo une todo

Lo que me gusta de ISO 27001 es que lo que tiene es comprensible, y al
mismo tiempo, tiene un enfoque equilibrado para construir un sistema
de gestión de seguridad de información (SGSI) – no sólo proporciona
un perfecto equilibrio entre la parte de TI y el negocio de la organiza-
ción, también requiere la participación directa de la alta dirección en la
implementación de la seguridad de información, asegurando que dicho
proyecto no sólo tiene todos los recursos necesarios, sino que además
es compatible con los objetivos estratégicos de la empresa.
ISO 27001 explica cómo estructurar la documentación de la seguridad

de la información, y también cómo aplicar solamente aquellos contro-
les de seguridad (salvaguardas) que son realmente necesarios para la
empresa. Te da las herramientas para revisar permanentemente todo el
sistema y mejorarlo siempre que sea posible; le proporciona un sistema
que capacita a sus empleados para que sean conscientes de la impor-
tancia de la seguridad de la información; esto incluye los requisitos
sobre cómo planificar los recursos, incluyendo los recursos financieros.
Como explicaré más adelante en mayor detalle, ofrece un camino de

implementación perfecta – está escrito de manera secuencial, de mane-
ra que sólo tiene que seguir la estructura de la norma para implementar
su SGSI de la manera más lógica.
Finalmente, ofrece un marco de gestión sobre cómo evaluar si la

seguridad de la información ha logrado algún valor para el negocio –
estableciendo objetivos y midiendo si se cumplen estos objetivos. Se
puede sorprender, pero me gusta mucho esta parte, porque si la direc-
ción ve beneficios concretos de la inversión en seguridad de informa-
ción, puede ser la mejor manera para asegurar una larga y exitosa vida
del SGSI en su empresa.
20
Introducción
1.4 ¿Quién debería leer este libro?

Este libro está escrito principalmente para los principiantes en este cam-
po y para las personas con un conocimiento moderado sobre ISO 27001
– estructuré este libro de tal manera que alguien sin experiencia previa
ni conocimientos sobre seguridad de la información pueda comprender
rápidamente de lo que trata y cómo implementar todo el proyecto; sin
embargo, si tiene experiencia con el estándar, y siente todavía que tiene
lagunas en su conocimiento, también encontrará este libro muy útil.
Este libro ofrece ejemplos de la implementación de la norma en or-

ganizaciones pequeñas y medianas (es decir, empresas con hasta 500
empleados.) Todos los principios aquí descritos también son aplicables
a organizaciones más grandes, así que si trabaja para una empresa
grande puede encontrar este libro útil; sin embargo tenga en cuenta
que en algunos casos las soluciones tendrán que ser más complejas que
las descritas en este libro – por ejemplo, puede utilizar una metodología
de análisis de riesgo más compleja que la que se sugiere en el capítulo
7 Gestión del riesgo.
Así que si usted es un administrador de TI, un profesional de seguridad

de la información, un jefe de departamento o jefe de proyecto con la
tarea de implementar ISO 27001 en una empresa pequeña o mediana,
este libro es perfecto para usted.
Creo que este libro también será muy útil para consultores – siendo
también consultor hice un esfuerzo para presentar en este libro el ca-
mino más lógico para implementar un sistema de gestión de seguridad
de información (SGSI), así que leyendo con cuidado este libro obtendrá
los conocimientos para sus futuros contratos de consultoría.
Este libro no está escrito como una guía para la realización de audito-
rías, pero podría ser útil para los auditores internos o incluso auditores
de certificación, porque les ayudará a comprender todos los requisitos
de la norma y también presentará la mejor práctica para la implemen-
tación, esto será útil cuando el auditor deba proporcionar algunas re-
comendaciones en su informe de auditoría.
21
SEGURO & SIMPLE
Por último, creo que este libro puede ser una especie de lista de veri-
ficación para los profesionales de seguridad de la información experi-
mentados – lo digo porque he tenido muchos de esos profesionales en
mis cursos de ISO 27001, y aunque no aprenden nada especialmente
nuevo, agradecen el obtener una visión completa y estructurada de
cómo debería implementarse la seguridad de la información.
Y así es exactamente cómo está escrito este libro - da una imagen sis-
temática sobre todo lo que es la ISO 27001, y le ayuda a asegurarse de
que no se olvida nada. Realmente no importa si su empresa va a por
la certificación o no - este libro le explicará cómo utilizar ISO 27001
como marco de trabajo, y cómo llegar a cumplir totalmente con este
estándar.
1.5 Cómo leer este libro

Este libro está escrito como una guía de implementación paso a paso, y
la forma es leer los capítulos 3 al 11 en el orden en el que están escritos,
porque esta secuencia representa la forma más óptima de implemen-
tación de la norma.
Aquí también tiene algunas otras características de este libro que le

harán más fácil leerlo y utilizarlo en la práctica:
● Cuando ciertas secciones de este libro estén relacionadas con una

cláusula específica del estándar, entonces la cláusula del estándar
estará escrita en el título de la sección.
● Dado que los capítulos del 5 al 8 y 10 describen la implementación

de cláusulas particulares del estándar, cada sección tiene estos ele-
mentos:
○ Propósito – describe brevemente por qué existe la cláusula y

cómo puede utilizarse para su SGSI
○
Entradas – qué insumos necesita tener para poder implemen-
tar el requisito
22
Introducción
○ Opciones
– qué opciones debe de considerar a la hora de
implementar el requisito
○ Decisiones – qué decisiones necesita tomar para avanzar
○ Documentación – describe cómo documentar los requisitos

de la ISO 27001
○ Truco de documentación – resume brevemente los docu-

mentos que necesita para cada requisito
● Algunas secciones contienen consejos de herramientas libres, que

le permitirán implementar la norma de una manera más fácil – por
ejemplo, en el apartado 3.3, se habla de convencer a la alta direc-
ción, y encontrará un enlace a una herramienta gratuita de cálculo
del retorno de la inversión en seguridad.
● Al final de los capítulos más importantes verá una sección llamada
Factores de éxito, que hará hincapié en lo que necesita centrarse.
● Al final del libro, en el capítulo 14 verá un par de pequeños casos

de estudio que explican cómo determinados elementos del están-
dar ISO 27001 se implementan en situaciones reales.
● Encontrará mucha información útil en los apéndices - glosario,

diagrama de implementación, lista de verificación de la docu-
mentación obligatoria, matrices de comparación, plantillas para
planificación de proyectos, etc.
1.6 Lo que no es este libro

Este libro se centra en la gestión de la seguridad, en la gestión de pro-
yectos, la documentación, cómo conseguir el apoyo para su proyecto,
etc., pero no se centra en la tecnología. Este libro no explica qué tipo de
sistemas de backup necesita comprar, qué tecnologías de comunicación
se deben utilizar, o qué tipo de firewall debe instalar. Sin embargo, este
libro le dará una metodología sobre cómo conseguir las entradas para
23
SEGURO & SIMPLE
que puedan tomar decisiones relevantes sobre la tecnología, cómo de-
terminar qué datos sensibles tiene compartiendo con sus colegas desde
el lado del negocio, y cómo asegurarse de que está respaldada regular-
mente, qué información necesita comunicar y a quién, cuáles son las
amenazas a los sistemas que su firewall debe proteger, etc.
Este libro no le dará las plantillas finales para todas las políticas, procedi-
mientos y planes; sin embargo, este libro le explicará cómo estructurar
todos los documentos requeridos por el estándar ISO 27001, qué op-
ciones tiene para escribir dichos documentos, quienes deberían par-
ticipar en la elaboración y toma de decisiones relacionados con cada
documento, dónde se encuentra los insumos, etc.
Este libro no es una copia del estándar ISO 27001 – no puede reem-
plazar el estándar mediante la lectura de este libro. Este libro pretende
explicar cómo interpretar el estándar (ya que el estándar está escrito de
una manera bastante antipática) y cómo implementar cada elemento
del estándar utilizando mejores prácticas basadas en la experiencia; sin
embargo, este libro no es un reemplazo de la ISO 27001 en sí mismo.
Por lo tanto, por favor, no caiga en el error de empezar la implementa-

ción del estándar sin antes leerlo – Creo que encontrará el estándar ISO
27001 y este libro, como la perfecta combinación para su futuro traba-
jo. Puede comprar el estándar en el sitio oficial de ISO, existe también
una alternativa económica en website de ANSI.
1.7 Recursos adicionales

Aquí tiene algunos recursos que le ayudarán, junto con este libro, a
aprender todo sobre cómo implementar ISO 27001:
1) ISO 27001 online courses – cursos online gratuitos que le enseña-

rán las bases de ISO 27001, cómo implementar el estándar, cómo
realizar una auditoría, etc.
2) ISO 27001 Descargas gratuitas – colección de documentos, listas

de chequeo, diagramas, plantillas, etc.
24
Introducción
3) Herramientas ISO 27001 – par de herramientas gratuitas como la
Calculadora de Inversión en Seguridad, la Calculadora de la Dura-
ción de la implementación y la herramienta de Análisis de brecha.
4) Conformio – sistema de gestión de documentos basado en la

nube (DMS), y herramienta de gestión de proyectos enfocada en
estándares ISO.
5) ISO 27001 Paquete de documentos – Conjunto de todas las plan-

tillas de documentos requeridas por ISO 27001, incluyendo su-
porte de expertos para la implementación.
6) El sitio oficial de ISO sobre ISO 27001 – aquí puede comprar una
versión oficial del estándar ISO 27001.
¿Le interesó? Bien, vamos a ver más de cerca todo lo que es la ISO
27001.
25
2
¿QUÉ ES EXACTAMENTE LA ISO 27001?
Como veremos más adelante, hay muchos mitos sobre ISO 27001 – al
menos la mitad de estos mitos han sucedido porque muchas de las per-
sonas que hablan sobre este estándar no lo han leído nunca. Y la otra
mitad de los mitos han sucedido por miedo a agobiarse con las políticas
y procedimientos.
2.1 El estándar más popular de seguridad de la información

ISO 27001 es un estándar internacional publicado por la Organización
Internacional de Normalización (ISO), y su nombre oficial es ISO/IEC
27001:2013 Tecnología de la información – Técnicas de seguridad –
Sistemas de gestión de seguridad de información - Requisitos. Ser un
estándar ISO implica que ha tenido que pasar por un proceso de vota-
ción - los miembros de la ISO son organismos de normalización nacio-
nal, y para la publicación de un estándar la mayoría de los miembros
tuvieron que votar para esta norma. En efecto, esto significa que la
mayoría de los países del mundo han aceptado este estándar como el
líder a nivel internacional.
Esto es particularmente evidente con respecto a la BS 7799-2 – este

estándar Británico fue un precursor de la norma ISO 27001, y cuando
la ISO 27001 fue publicada por primera vez en 2005, el British Stan-
dards Institution (BSI) retiró la BS 7799-2 y aceptó la ISO 27001 como
estándar Británico, por lo que en el Reino Unido ahora se llama BS ISO/
IEC 27001. Siguiendo el ejemplo de BSI, la mayoría de los países han
aceptado ISO 27001 como su estándar nacional para la gestión de se-
guridad de la información.
También es bueno saber cómo se desarrolló este estándar: ISO 27001

(así como otros estándares ISO) fue escrito por expertos en este campo
26
¿Qué es exactamente la ISO 27001?
- se podría considerar que es un consenso de las principales prácticas
de seguridad de información; por lo tanto, no es un producto único de
un sólo autor.
Una de las características que diferencia a esta norma de otros marcos

de trabajo/normas de seguridad de información es que una organiza-
ción puede ser certificada por un organismo de certificación acredi-
tado, y por lo tanto será capaz de demostrar su cumplimiento a sus
clientes, socios, propietarios y otros interesados. Muchas empresas ya
se han certificado – aquí puede ver el número de certificados en los
últimos años:
30000
25000
20000
15000
10000
5000
0
2011 2012 2013 2014
Can�dad de cer�ﬁcados
Figura 1: Número de certificados ISO 27001 (fuente: encuesta ISO)
Para concluir, no hay duda de que ISO 27001 se ha convertido ya en

el marco de trabajo número uno en todo el mundo para la gestión de
seguridad de la información, muy similar a ISO 9001 en la gestión de
la calidad.
 Herramienta libre: Este ISO 27001 Foundations Course le expli-
cará las bases del estándar.
27
SEGURO & SIMPLE
2.2 Seguridad de la información vs. Seguridad TI

Uno podría pensar que la seguridad informática y la seguridad de la
información son sinónimos – después de todo, ¿No es seguridad de la
información todo lo relativo a computadoras?
No realmente. La cuestión básica es esta – puede tener unas medidas
de seguridad de TI perfectas, pero sólo uno malévolo acto hecho por,
por ejemplo, un administrador de sistemas, puede derrumbar todo el
sistema de TI. Este riesgo no tiene nada que ver con computadoras,
tiene que ver con personas, procesos, supervisión, etc..
Además, la información importante no existe sólo en formato digital,
también puede estar en formato papel, por ejemplo, un importante con-
trato firmado con el cliente más importante, notas personales en un bloc
de notas de papel del director general, o la impresión de las contraseñas
del administrador de sistemas almacenadas en un lugar seguro.
Por lo tanto, siempre me gusta decir a mis clientes – la seguridad infor-
mática sólo es la mitad de la seguridad de la información, porque la se-
guridad de la información también incluye la seguridad física, la gestión
de recursos humanos, la protección legal, la organización, los procesos,
etc. El propósito de seguridad de la información es construir un siste-
ma que tenga en cuenta todos los posibles riesgos para la seguridad
de información (relacionados o no relacionados con TI) e implementar
controles integrales que reduzcan todo tipo de riesgos inaceptables.
ISO 27001 permite este enfoque integrado de la seguridad de la infor-
mación: esto requiere que la evaluación del riesgo sea realizada sobre
todos los activos de la organización - incluyendo hardware, software,
documentación, personas, proveedores, socios etc., y elegir los con-
troles aplicables para disminuir esos riesgos. Al analizar el anexo A de
la ISO 27001 (este anexo es básicamente un catálogo de controles de
seguridad), resulta que sólo son el 37% de los controles están relacio-
nados con TI, el resto son controles no relacionados con TI.
¿Qué significa todo esto en términos de seguridad de la información / im-
plementación de la ISO 27001? Este tipo de proyectos no debe verse como
un proyecto de TI, porque como tal es probable que no todas las partes de
28
la organización estén dispuestas a participar en él. Debe ser visto como un
proyecto de toda la empresa, donde personajes relevantes de todas las uni-
dades del negocio deben participar – alta dirección, personal de TI, expertos
jurídicos, gerentes de recursos humanos, personal de seguridad física, el lado
del negocio de la organización etc. Sin este enfoque terminará trabajando
en la seguridad informática, y esto no le protegerá de los mayores riesgos.
2.3 Cómo funciona la ISO 27001

Al hablar con alguien nuevo en ISO 27001, muy a menudo me en-
cuentro con el mismo problema: esta persona piensa que el estándar
describe en detalle todo lo que necesitan hacer – por ejemplo, con
qué frecuencia necesitará realizar las copias de seguridad, qué distancia
debe tener su sitio de recuperación ante desastres, o peor aún, qué tipo
de tecnología debe utilizar para la protección de la red o cómo se ha de
configurar el router.
Pero el hecho es que ISO 27001 no describe estas cuestiones; funciona

de una manera completamente diferente.
¿Por qué la ISO 27001 no es descriptiva? Imaginemos que el estándar

describe que debe realizar una copia de seguridad cada 24 horas –
¿esta es la medida correcta para usted? Podría ser, pero créame, mu-
chas empresas hoy en día encuentran esta frecuencia insuficiente - la
tasa de cambio de sus datos es tan rápida que necesitan hacer copias
de seguridad en tiempo real, o por lo menos cada hora. Por otra parte,
también hay algunas empresas que encontrarían excesivo la copia de
seguridad diaria – su tasa de cambio es muy lenta, y realizar copias de
seguridad con tanta frecuencia sería improductivo.
El punto es - si este estándar se desarrolla para adaptarse a cualquier tipo

de empresa, entonces no es posible un enfoque descriptivo. Por tanto, es
simplemente imposible definir la frecuencia de las copias de seguridad,
la tecnología específica a utilizar, cómo configurar cada dispositivo, etc.
Por cierto, esta percepción de que en la ISO 27001 se describe todo,

es el mayor generador de mitos sobre ISO 27001 – encontrarás estos
mitos en la siguiente sección.
29
SEGURO & SIMPLE
Por lo tanto, usted podría preguntarse, “¿por qué necesito un estándar
que no me dice nada concreto?” Porque ISO 27001 le da un marco de
trabajo para decidir sobre la protección adecuada. Del mismo modo,
por ejemplo, que no puede copiar una campaña de marketing de una
empresa para que usted la utilice en la suya, este mismo principio es
válido para la seguridad de la información - necesita adaptarla a sus
necesidades específicas.
La gestión de riesgos es la idea central de la ISO 27001. Y lo que

ISO 27001 le dice es que para lograr esta medida tiene que realizar la
evaluación del riesgo y el tratamiento de riesgos. Esto no es más que
una descripción sistemática de las cosas malas que le pueden pasar (eva-
luar los riesgos), y luego decidir qué medidas de seguridad tendrá que
implementar para evitar que las cosas malas sucedan (tratamiento de
los riesgos).
Requisitos de las partes interesadas. Estos requisitos son una segun-

da entrada crucial a la hora de seleccionar las medidas de protección.
Como veremos más adelante en la sección 5.2, las partes interesadas
podrían ser organismos gubernamentales, sus clientes, socios, etc. -
todos ellos probablemente esperan una protección de la información,
y esto se refleja en las leyes y los contratos que tiene con ellos. Por lo
tanto, sus controles de seguridad tienen que cumplir con todos estos
requisitos.
La idea aquí es que se deben implementar sólo las salvaguardas (con-

troles) que son necesarias debido a los riesgos y requisitos de las partes
interesadas, no los que les apetezca a una persona; pero esta lógica
también significa que deben implementar todos los controles que son
necesarios debido a los riesgos o debido a estos requisitos, y que no
puede excluir algunos simplemente porque no les gustan.
TI sola no es suficiente para proteger la información. Si trabaja en el

Departamento de IT, usted sea probablemente consciente de que la ma-
yoría de los incidentes que ocurren no se deben a que las computadoras
se rompen, sino a que los usuarios desde el lado del negocio de la organi-
zación están utilizando los sistemas de información de forma incorrecta.
30
Y estos errores no se pueden prevenir sólo con salvaguardas técnicas –
lo que se necesita también son claras políticas y procedimientos, capa-
citación y concientización, protección jurídica, medidas disciplinarias,
etc. La experiencia de la vida real ha demostrado que aplicando salva-
guardias diversas, se logra el mayor nivel de seguridad.
Y cuando usted tiene en cuenta que no toda la información sensible

puede estar en formato digital (probablemente todavía tiene papeles
con información confidencial sobre ellos), la conclusión es que las sal-
vaguardas técnicas no son suficientes, y que el Departamento de TI,
aunque sea muy importante en un proyecto de seguridad de la infor-
mación, no puede ejecutar este tipo de proyecto de manera autónoma.
Este hecho de que la seguridad informática no es suficiente para implemen-

tar la seguridad de la información es reconocido en la norma ISO 27001 –
este estándar explica cómo ejecutar la implementación de la seguridad de
la información como un proyecto de empresa donde no sólo TI, también el
lado del negocio de la organización, deben tomar parte del mismo.
2.4 Lo que no es la ISO 27001 – Los 7 mitos más

comunes
Hay muchos conceptos erróneos sobre la ISO 27001 que muy a menu-
do dificultan que conozca y considere este estándar, y que usted con-
sidere una implementación real del estándar. En realidad, podríamos
decir que estos mitos son el mayor enemigo de la ISO 27001.
Esto es lo que oigo muy a menudo:
“El estándar requiere xyz”
“El estándar requiere que las contraseñas se cambien cada 3 meses”.

“Este estándar requiere que deben existir varios proveedores”. “El estándar
requiere que el sitio de recuperación ante desastres esté por lo menos 50 km
desde la oficina principal”. ¿De verdad? El estándar no dice nada de esto.
Lamentablemente, escucho bastante a menudo este tipo de información fal-
sa – las personas generalmente confunden las mejores prácticas con requi-
31
SEGURO & SIMPLE
sitos del estándar, pero el problema es que no todas las reglas de seguridad
son aplicables a todo tipo de organizaciones. Y las personas que dicen
que esto es descrito por el estándar probablemente nunca han leído el
estándar.
“Bien, dejaremos al departamento de TI manejarlo”
Esta es la favorita de la dirección, “la seguridad de la información es

todo sobre TI, ¿no?” Bueno, no realmente – los aspectos más impor-
tantes de seguridad de la información no sólo incluyen salvaguardas
técnicas, también incluyen cuestiones de organización y gestión de re-
cursos humanos, que suelen estar fuera del alcance del departamento
de TI. La verdad es que la implementación de la ISO 27001 es más un
proyecto del negocio que un proyecto de TI, como he explicado en la
sección 2.2.
“Bien, lo implementaremos en un par de meses”
Usted podría implementar la ISO 27001 en 2 ó 3 meses, pero no fun-

cionará - sólo obtendrá un montón de políticas y procedimientos de las
que nadie se preocupará. La implementación de la seguridad de la in-
formación significa que tiene que implementar cambios, y toma tiempo
que estos cambios sean aceptados por sus empleados.
Sin dejar de mencionar que debe implementar sólo los controles de

seguridad que realmente se necesitan, y el análisis de lo que se necesita
realmente lleva tiempo - esto se llama evaluación del riesgo y trata-
miento de riesgos.
“Este estándar es todo sobre documentación”
La documentación es una parte importante de la implementación del

estándar ISO 27001, pero la documentación no es un fin en sí mismo.
El punto principal del estándar ISO 27001 es que los empleados realicen
sus actividades de forma segura, y la documentación está para ayudarle
a hacer esto. Además, los registros que se generen le ayudarán a medir
si usted alcanza sus metas de seguridad de la información, y permitirá
corregir aquellas actividades que no se han realizado.
32
Así podría considerar la documentación sólo como una herramienta
para lograr mayor seguridad.
“Sólo es necesario un documento – la política de seguridad de la

información”
La política de seguridad de la información realmente es un documento

obligatorio, pero hay una docena de otros documentos que también
son obligatorios, como el alcance del SGSI, la evaluación del riesgo, etc.
Todos ellos figuran en el Apéndice A de este libro.
“El único beneficio del estándar es marketing”
“Estamos haciendo esto sólo para obtener el certificado, ¿no?” Bien,

(por desgracia) es la manera de pensar del 80 por ciento de las empre-
sas. No estoy tratando de argumentar aquí que ISO 27001 no debe
ser utilizado para propósitos promocionales y de ventas, pero también
puede obtener otros beneficios muy importantes, los principales bene-
ficios se enumeran en la sección 3.1.
“Necesitamos una herramienta GRC para implementar ISO 27001”
Las herramientas de gobernanza, riesgo y cumplimiento pueden ser

útiles, sin embargo no son requeridas de ninguna manera para la im-
plementación de la ISO 27001. Usted puede albergar toda su docu-
mentación en un servidor existente, o en algún servicio en la nube
como Dropbox, o en su computadora; deben mantenerse registros au-
tomáticos en los sistemas que los creó.
El punto aquí es – Lea primero ISO 27001 antes de tener una opinión
sobre esto; o, si el estándar es demasiado aburrido para leer (que ad-
mito que lo es), con este libro puede ver lo que es y lo que no es cierto.
2.5 ¿A qué pertenece la seguridad de la información?

Esencialmente, la seguridad de la información es parte de la gestión
integral del riesgo en una empresa, con áreas que se solapan como la
ciberseguridad, la gestión de continuidad del negocio y la gestión de TI.
33
SEGURO & SIMPLE
Gestión de riesgos
Seguridad de
la información
Continuidad Cyber-seguridad
de negocio
Tecnologías de la información
Figura 2: Relación entre seguridad de la información, gestión de riesgos, continuidad de

negocio, TI y cyber-seguridad
La ciberseguridad es básicamente un subconjunto de la seguridad de

la información, porque se centra en la protección de la información
en formato digital, mientras que la seguridad de la información es
un concepto un poco más amplio porque protege la información en
cualquier medio. El compromiso con la continuidad del negocio existe
porque su propósito es permitir la disponibilidad de la información,
que es también una de las funciones clave de la seguridad de la in-
formación. Naturalmente, la tecnología de la información juega un
34
papel muy importante en la seguridad de la información; por lo tanto,
consecuentemente, existe también un área de solapamiento.
Pero, lo más importante es que la seguridad de la información, la ciberse-

guridad y la continuidad del negocio tienen el mismo objetivo: disminuir
los riesgos para las operaciones del negocio. No puede llamarlo una ges-
tión de riesgos como tal, pero básicamente es lo que hace la seguridad
de la información – evaluar qué problemas potenciales pueden ocurrir y
luego aplicar varias salvaguardas o controles para disminuir esos riesgos.
Algunas industrias han reconocido formalmente la seguridad de la in-

formación como parte de la gestión del riesgo – por ejemplo, en el
mundo de la banca, la seguridad de la información pertenece a menu-
do a la gestión del riesgo operacional. Mi conjetura es que en el futuro
veremos más y más profesionales de la seguridad de información en la
parte de gestión de riesgo de sus organizaciones, y la seguridad de la
información tenderá a fusionarse con la continuidad del negocio.
Hablaré más sobre cómo organizar un proyecto de seguridad de la

información desde la perspectiva de estas relaciones en el capítulo 4.
2.6 Para qué tipo de empresa y tamaño está pensada

la ISO 27001
Una empresa grande o pequeña, local o internacional, o un hospital, un
gobierno o una entidad privada – no importa en qué tipo de empresa
trabaja, porque ISO 27001 puede implementarse en cualquier sector.
Con respecto a la geografía, la situación es muy similar: el estándar es

adoptado en todo el mundo. Como de costumbre, Reino Unido y Japón
son los que lideran el camino, con China, India, Europa occidental y
América del norte siguiéndole los pasos de cerca.
Vamos a ver qué sectores más típicamente están implementando esta norma.
Compañías TI. Empresas de desarrollo software, de servicios en la

nube, y de soporte TI son sólo algunos ejemplos de empresas que
35
SEGURO & SIMPLE
implementan ISO 27001 – por lo general, lo hacen porque quieren
obtener nuevos clientes demostrándoles con un certificado de que
son capaces de proteger su información de la mejor manera posible;
algunas compañías también usan ISO 27001 para cumplir con los
requisitos de seguridad contractual de sus principales clientes, o con
ANS (Acuerdos de Nivel de Servicio). En algunos casos, las empresas
que crecen rápido usan ISO 27001 como una forma de resolver pro-
blemas en sus operaciones, porque este estándar obliga a las empre-
sas a definir quién es responsable de qué y qué pasos deben seguirse
en los procesos más importantes, que muy a menudo no se define en
empresas que están creciendo demasiado rápido.
Industria financiera. Bancos, aseguradoras, casas de corretaje y

otras instituciones financieras suelen ir a por la ISO 27001 cuando
quieren cumplir con numerosas leyes y reglamentos. La legislación
de protección de datos es la más estrictas para la industria financie-
ra, y por suerte, los legisladores han basado sus leyes sobre todo en
ISO 27001. Esto significa que la ISO 27001 es una metodología ideal
para lograr el cumplimiento, que hace muy fácil presentar un proyec-
to a los ejecutivos. La segunda razón por la que este tipo de orga-
nizaciones implantan ISO 27001 son los costes – quieren evitar que
sucedan incidentes, que es, por supuesto, mucho más barato que
tratar un incidente cuando ya se ha producido. Este enfoque es típi-
co de la industria financiera, porque las empresas de este sector son
generalmente más avanzadas cuando se trata de gestión de riesgos.
Telecomunicaciones. Empresas de telecomunicaciones, incluyendo

proveedores de Internet, están muy interesadas en la protección de la
gran cantidad de datos que manejan, y también de reducir el número
de interrupciones, por tanto naturalmente ven ISO 27001 como un
marco de trabajo que les ayuda a hacerlo. Además, al igual que en
el sector financiero, hay un número creciente de leyes y regulaciones
para las telecomunicaciones, donde es muy útil el cumplimiento de ISO
27001.
Agencias gubernamentales. Por lo general, los órganos de gobierno

manejen datos muy sensibles – en algunos organismos estos datos son
36
confidenciales, y en todas las agencias la protección de la integridad y
la disponibilidad de sus datos es de suma importancia. El hecho de que
ISO 27001 fue diseñado para satisfacer las tres dimensiones (la famosa
tríada de C-I-D) es una metodología ideal para disminuir el número
de incidentes al mínimo posible. Y, siendo un estándar internacional
reconocido por organismos de normalización de cada país, ISO 27001
es un marco de trabajo perfecto con un reconocimiento oficial de cada
gobierno.
Otras organizaciones. Esta lista podría continuar – por ejemplo, las

organizaciones de salud quieren proteger los datos de sus pacientes, las
compañías farmacéuticas quieren proteger sus datos de desarrollo y sus
fórmulas, las empresas de procesamiento de alimentos quieren prote-
ger sus recetas especiales, las empresas de fabricación quieren proteger
sus conocimientos sobre cómo se producen ciertas partes, etc.
Básicamente, cualquier empresa que tenga información sensible puede

encontrar útil ISO 27001. Puede ver también el Apéndice C de este
libro para obtener una lista de las industrias y beneficios que puede
proporcionar ISO 27001.
2.7 Breve historia de la ISO 27001

BS 7799. El predecesor de ISO 27001 fue una serie de estándares de
seguridad de la información llamados BS 7799 (BS significa “British
Standard”), publicados en 1995 por BSI. BS 7799 tuvo sus orígenes en
algunos marcos de trabajo en entornos militares y de inteligencia, pero
prácticamente fue el primer estándar que era aplicable a cualquier tipo
de organización.
Con el avance de la tecnología de la información, y el desarrollo de la

sociedad de la información en general, hubo necesidad de crear un
estándar internacional que ayudase a las empresas en todo el mundo
a proteger su información. Dado que BS 7799 fue el mejor marco de
trabajo en su tiempo, ISO ha utilizado este estándar para desarrollar la
primera versión de la ISO 27001, que fue publicada en 2005.
37
SEGURO & SIMPLE
Revisión 2013 de la ISO 27001. ISO 27001 fue revisada en 2013, por lo
tanto, la versión actual es la ISO/IEC 27001:2013. Los cambios más impor-
tantes en la revisión del 2013 están relacionados con la estructura de la par-
te principal del estándar, las partes interesadas, los objetivos, el seguimiento
y la medición; Además, el Anexo A ha reducido el número de controles de
133 a 114, y aumentó el número de secciones de 11 a 14. Por otra parte,
se eliminaron algunos requisitos en la revisión de 2013, como las acciones
preventivas y el requisito de documentar ciertos procedimientos.
Usted podrá leer más sobre todos estos elementos en los capítulos 5 al
10, mientras que en el Anexo D encontrará una infografía que muestra
las diferencias entre las revisiones del 2005 y 2013 del estándar.
Todos estos cambios en la revisión de 2013 no cambian la idea prin-

cipal del estándar – su filosofía principal sigue siendo la evaluación y
tratamiento de riesgos, y siguen existiendo las mismas fases del ciclo
Plan-Do-Check-Act. Esta nueva revisión del estándar es más fácil de leer
y entender, y es mucho más fácil de integrar con otros estándares de
gestión como ISO 9001, ISO 22301, etc.
2.8 ¿Cuál es el aspecto del estándar?

Su estructura y cláusulas principales
Cuando usted compre la ISO 27001, se dará cuenta de que este es un
documento PDF, con una longitud aproximada de unas 20 páginas. Se
divide en 11 secciones, además del Anexo A. Las secciones de la 0 a la 3
son introductorias (y no es obligatorio su implementación), mientras que
las secciones de la 4 a la 10 son obligatorias - lo que significa que todos
sus requisitos se deben implementar en una organización si quiere cum-
plir con el estándar. Los controles del Anexo A deben implementarse sólo
si se declara como aplicable en la Declaración de Aplicabilidad.
De acuerdo al Anexo SL de las Directrices ISO/IEC de la Organización

Internacional de Normalización, los títulos de las secciones en ISO 27001
son los mismos que en ISO 22301:2012, en ISO 9001:2015 y otros están-
dares de gestión, permitiendo una integración fácil de estos estándares.
38
● Apartado 0: Introducción – explica el propósito de la ISO 27001
y su compatibilidad con otros estándares de gestión.
● Apartado 1: Alcance – explica que este estándar es aplicable a
cualquier tipo de organización.
● Apartado 2: Normativas de referencia – referencia a ISO 27000
como un estándar donde se dan términos y definiciones.
● Apartado 3: Términos y definiciones – de nuevo referencia a
ISO 27000.
● Apartado 4: Contexto de la organización – Esta sección es par-
te de la fase de Planificar del ciclo PDCA, y define los requerimien-
tos para entender las cuestiones internas y externas, las partes
interesadas y sus necesidades, y definir el alcance del SGSI.
● Apartado 5: Liderazgo – Esta sección es parte de la fase de
Planificar del ciclo PDCA y define las responsabilidades de la alta
dirección, el establecimiento de roles y responsabilidades, y el con-
tenido de la política de seguridad de la información de alto nivel.
● Apartado 6: Planificación – Esta sección es parte de la fase de
Planificación del ciclo PDCA y define los requerimientos para la
evaluación de riesgos, el tratamiento de riesgos, la declaración de
aplicabilidad, el plan de tratamiento del riesgo y el establecimiento
de los objetivos de seguridad de la información.
● Apartado 7: Soporte – Esta sección es parte de la fase de Planifi-
cación del ciclo PDCA y define los requerimientos para la disponi-
bilidad de recursos, competencias, conocimiento, comunicación y
control de documentos y registros.
● Apartado 8: Operación – Esta sección es parte de la fase Hacer
en el ciclo PDCA y define la implementación de la evaluación y tra-
tamiento del riesgo, así como los controles y otros procesos nece-
sarios para conseguir los objetivos de seguridad de la información.
● Apartado 9: Evaluación del desempeño – Esta sección es parte
de la fase de Verificación en el ciclo PDCA y define los requeri-
39
SEGURO & SIMPLE
mientos para el monitoreo, la medición, el análisis, la evaluación,
la auditoría interna y la revisión por dirección.
● Apartado 10: Mejora – Esta sección es parte de la fase de Actuar
en el ciclo PDCA y define los requerimientos para las no conformida-
des, las correcciones, las acciones correctivas y la mejora continua.
● Anexo A – este anexo proporciona un catálogo de 114 controles (sal-

vaguardas) localizadas en 14 secciones (secciones de la A.5 a la A.18).
Como se puede concluir de esta estructura, para lograr la seguridad de

la información, no basta con implementar sólo las salvaguardias – pri-
mero tiene que saber lo que quiere lograr, tiene que crear un entorno
adecuado para el proyecto, y una vez implementados los controles de
seguridad, se debe cuidar que se mantengan y se mejoren.
En otras palabras, dejar alguno de estos requisitos fuera, implicará que

usted tendrá una seguridad de la información que no funciona. Por
ejemplo, ¿se imagina la seguridad de la información sin el apoyo real
de la dirección? O ¿qué hubiera pasado si no tuviese reglas claras sobre
quién puede aprobar documentos, cómo cada documento es distribui-
do y protegido, y cómo se mantienen? O ¿si a sus empleados no les
preocupan realmente las políticas de seguridad y los procedimientos?
Si no lo tiene sería un caos, ciertamente sólo tendría un manojo de do-
cumentos que no le ayudarían.
Por esta razón el estándar requiere implementar todos los requisitos de

las cláusulas 4 a la 10 si usted quiere conseguir la certificación - a dife-
rencia de en ISO 9001, no son posibles exclusiones en la parte principal
de la norma. Como veremos más adelante en la sección 9.1, las exclu-
siones son posibles sólo para los controles de seguridad del Anexo A.
Cubriré la implementación de las cláusulas de la 4 a la 10 en detalle en

este libro, y daré un resumen de los controles del Anexo. No obstante,
este podría ser un buen momento para que usted comience a leer el es-
tándar – a medida que avancemos en este libro con la implementación
de cada cláusula, usted debe leer primero la cláusula correspondiente
del estándar y luego la sección correspondiente de este libro.
40
2.9 Introducción al Sistema de Gestión de Seguridad

de la Información
ISO 27001 básicamente describe cómo desarrollar un sistema de ges-
tión de seguridad de información o SGSI - se puede considerar este SGSI
como un enfoque sistemático para gestionar y proteger la información
de la empresa. Un SGSI representa un conjunto de políticas, procedi-
mientos y otros controles que establecen unas reglas de seguridad de la
información en una organización. Como se mencionó antes, el tipo de
control de seguridad de la información que será implementado en una
empresa se decide en base a los resultados de la evaluación del riesgo y
los requerimientos de las partes interesadas. Para cada riesgo que ten-
ga que ser tratado, se implementarán una combinación de diferentes
tipos de controles.
Supongamos que deja su portátil con frecuencia en su coche, así que

es probable que, más pronto o más tarde, se lo roben ¿Qué puede ha-
cer para disminuir el riesgo a su información? Hay que aplicar algunos
controles. En primer lugar usted puede escribir un procedimiento que
defina que no puede dejar el portátil en el coche, también puede prote-
ger su portátil con una contraseña, de esta manera, si se lo roban será
más difícil que alguien pueda acceder a su información, también puede
cifrar el disco duro. Y esto es incluso superior a su información, pero
también puede pedirle a sus empleados que firmen una declaración
donde obligue a pagar todos los daños que puedan ocurrir si ocurre un
incidente, pero también tiene que entrenar y hacer que sus empleados
sean conscientes de que existen riesgos si dejan su ordenador portátil
en el coche.
Ahora proteger este portátil puede sonar simple, pero el problema vie-
ne cuando tiene cientos de portátiles, decenas de servidores, multitud
de bases de datos, muchos empleados, etc. Con tanta información sen-
sible en muchos activos diferentes, muy rápidamente se producen un
gran número de medidas de seguridad que no están relacionadas y que
por lo tanto serían muy difícil de manejar.
41
SEGURO & SIMPLE
La única manera de gestionar todas estas salvaguardas es establecer
responsabilidades y procesos de seguridad claros. Esto se denomina
“enfoque de procesos” en estándares ISO de gestión - en ISO 27001,
pero también en ISO 9001, ISO 20000 y otros estándares. Si tomamos
ISO 9001 para hacer una analogía, la idea es la siguiente: no se puede
esperar producir un coche de alta calidad realizando sólo una verifica-
ción de la calidad al final de la línea de producción, lo que se necesita es
diseñar un proceso de producción que incluya la filosofía de calidad en
cada paso, en cada detalle, desde la selección de proveedores de alta
calidad, la formación de los empleados , para abordar con eficacia los
productos no conformes.
Asimismo, el enfoque de procesos es crucial para hacer esta conexión

entre responsabilidades y controles técnicos – sólo si sabe lo que tiene
que hacer y cuando, tendrá una base para hacer que sus controles de
seguridad funcionen.
Así que ¿qué podemos aprender de estos puntos? En primer lugar, los
controles de seguridad de la información no son sólo técnicos, o rela-
cionados con TI. Son una combinación de diferentes tipos de controles:
documentar un procedimiento es un control organizacional; implemen-
tar una herramienta software es un control de TI y la formación de
personas es un control de recursos humanos.
En segundo lugar, sin el uso de algún tipo de marco de trabajo, la se-

guridad de la información se convierte en inmanejable – aquí es donde
encaja ISO 27001 – cuando usted construya su SGSI, lo que implica el
desarrollo de un conjunto de reglas de seguridad de la información,
responsabilidades y controles, entonces este marco de trabajo le permi-
tirá ser capaz de administrar un sistema tan complejo.
Finalmente, un SGSI no es nada más que varios procesos de seguridad

unidos – mientras mejor se definan estos procesos, y mientras más in-
terrelacionados estén estos procesos, menos incidentes tendrá.
42
En próximos capítulos explicaré cómo desarrollar el Sistema de Gestión

de Seguridad de la Información en su empresa, pero primero vamos a
ver el lado humano de este tipo de proyectos.
43
3
OBTENER LA PARTICIPACIÓN
DE LA ALTA DIRECCIÓN Y OTROS
EMPLEADOS
Los profesionales de seguridad de la información destacan una razón

principal como la responsable del fracaso de sus proyectos: la falta de
comprensión de la alta dirección y, en consecuencia, la falta de su apo-
yo continuo.
Sin embargo, la alta dirección no es el único problema. Muy a menudo,
los profesionales de seguridad de información son, si no totalmente in-
comprendidos, al menos evitados por otros empleados en una empresa.
¿La solución a este problema? A usted probablemente no le va a gustar
esto: tiene que ser una combinación de una persona diplomática y un
vendedor: va a tener que vender la idea de seguridad de la información
a su dirección, a sus empleados y a sus socios, y usted tendrá que usar
todo su poder de persuasión para convencerlos. Y no, su trabajo como
profesional de seguridad de la información no es sólo sobre medidas de
seguridad o procesos de seguridad: sobre todo su trabajo en este sentido
será sobre psicología y sobre ser convincente con la gente de su alrededor.
Este capítulo le mostrará cómo hacerlo.
3.1 Cómo convencer a la alta dirección para

implementar la ISO 27001
Si usted piensa que a su dirección le encanta conocer cuál es su gran idea
sobre un nuevo firewall, o la herramienta perfecta que has descubierto
para el manejo de incidentes, te equivocas, simplemente no les importa.
Lo que la dirección quiere escuchar (y entender) son beneficios, cuota de
mercado, satisfacción del cliente, disminución de costes, estrategias de ne-
44
Obtener la participación de la alta dirección y otros empleados
gocio, y riesgos empresariales. Y no les puede culpar – después de todo,
este es su trabajo.
Por lo tanto, si usted no puede cambiar esto, tendrá que cambiarse a si
mismo. Desde el principio, si quiere que le escuchen, tiene que empe-
zar a hablar un idioma que entiendan - y ellos le entenderán solamente
si presentan cuales son los beneficios para el negocio de la implemen-
tación de la seguridad de la información.
En mi experiencia, hay cuatro beneficios potenciales que usted debe
considerar:
1. Cumplimiento. Cada vez existen más y más leyes y reglamentos en
casi todos los países que requieren la implementación de la seguri-
dad de la información (por ejemplo, protección de datos personales,
protección de información clasificada por el gobierno, etc.); pero lo
que es aún más interesante, es que hay un creciente número de
clientes (por ejemplo, instituciones financieras) que requieren a sus
proveedores y socios implementar procedimientos de seguridad de
la información. La buena noticia es que la ISO 27001 es el marco de
trabajo perfecto para cumplir con todos estos requisitos, en parte
porque este estándar fue un modelo cuando se desarrollaron esas
leyes y reglamentos. Esto significa por una parte menos esfuerzo
en el proceso de cumplimiento, y por otra parte, menos sanciones
a pagar. (Aquí puede encontrar una lista de legislación mundial de
seguridad de la información.)
2. Ventaja competitiva. Si su empresa tiene el certificado ISO 27001
y sus competidores no, y sus clientes están confiando en su em-
presa la gestión de información sensible, en realidad podría ganar
a nuevos clientes porque usted será capaz de convencer a los po-
tenciales clientes que puede proteger su información mejor que sus
competidores. Esto significa mayor mercado y mayores ganancias.
3. Reducción de gastos. La seguridad de la información se considera
generalmente como un coste con ninguna ganancia financiera pal-
pable. Sin embargo, hay beneficios financieros si usted reduce sus
gastos ocasionados por sucesos. Usted probablemente tiene inte-
rrupciones en el servicio, o fugas ocasionales de datos o empleados
45
SEGURO & SIMPLE
descontentos. O ex-empleados descontentos. Es verdad, es difícil
de calcular cuánto dinero podría ahorrar si usted previene estos
incidentes - pero siempre suena bien si atraes la atención de la di-
rección exponiendo estos casos. (Más adelante en este capítulo voy
a explicar cómo calcular la cantidad de ahorros, en la sección 3.3.)
4. Optimización de procesos de negocio. Este es probablemente el
más subestimado – si usted es una empresa que ha ido creciendo con-
siderablemente en los últimos años, es posible que experimente pro-
blemas como quién tiene que decidir qué, quién es responsable de
ciertos activos, quién tiene que autorizar el acceso a los sistemas de
información. ISO 27001 es particularmente bueno en arreglar estas co-
sas, ya que le obliga a definir con mucha precisión los roles y responsa-
bilidades, lo que le puede ayudar a fortalecer su organización interna.
No estoy diciendo que estos cuatro beneficios puedan ser aplicables
a su organización, pero lo más probable es que encuentre al menos
dos que sean realmente relevantes para su organización. Y tiene que
consultar a sus colegas de empresa, porque en definitiva tiene que ave-
riguar cuál de estos beneficios son los más interesantes para la alta
dirección de su empresa, y para aquellos que apoyan su estrategia. La
mejor manera de hacer esto podría ser realizar una lluvia de ideas de
estos beneficios con sus colegas desde el lado del negocio de la orga-
nización, y con aquellas funciones corporativas.
Por supuesto, también tendrá que encontrar los caminos de cómo usted
puede relacionar la seguridad de la información con la estrategia de nego-
cio de la empresa. Aquí tiene un ejemplo: digamos que su empresa quiere
comenzar a ofrecer servicios en la nube, lo que significa que la información
sensible del cliente necesita ser protegida; Si comienza a implementar ISO
27001, no sólo disminuirá la probabilidad de que algunos datos se puedan
revelar, también disminuirá la indisponibilidad del servicio, por lo tanto,
este proyecto apoyará el paso estratégico que su empresa decidió tomar.
Vea también este mini caso de estudio en el capítulo 14: Obtener el
apoyo de la alta dirección en una compañía de propiedad estatal.
El siguiente paso es averiguar cómo llegar a la mente de su dirección.
46
3.2 Cómo presentar los beneficios a la alta dirección

No espere que su dirección pueda captar todos los beneficios después
de una reunión de 20 minutos, no importa lo bonito que se vea su
presentación de PowerPoint. Por desgracia, a su dirección le tomará
tiempo entenderlo.
Aquí tiene algunas técnicas que puede utilizar para presentar su caso
de forma más efectiva:
Discurso motivador. Es probable que usted logre mucho más en oca-
siones informales que en reuniones formales - por ejemplo, cuando
accidentalmente tropieza con su CEO en una cafetería, un ascensor,
o similar. Si no están preparados para esta ocasión, probablemente
conseguirá confundir, por lo tanto, tiene que preparar un supuesto dis-
curso de ascensor, un discurso de 30 a 60 segundos donde presente in-
tensamente su caso. Si usted ensaya bien, sonará seguro y convincente.
Por ejemplo, mi discurso de ascensor (como consultor tratando de ven-
der mis servicios): la inversión en ISO 27001 será rentable si usted evita
solamente un incidente mediano, sin mencionar los grandes incidentes.
Encontrar un aliado. Usted necesita encontrar personas que estén
cerca de su CEO y que naturalmente estén interesadas en lo que está
haciendo - por ejemplo, su director financiero podría ver la seguridad
de la información como una forma de disminuir el riesgo financiero de
la compañía, así que esta persona puede decidir apoyar su esfuerzo;
el director de cumplimiento podría ver su proyecto como una forma
de aliviar una parte de su carga de trabajo, mientras que los chicos de
marketing podrían ver esto como un punto de venta clave adicional. En
cualquier caso, haga su tarea e investigue quién estaría interesado en
las ventajas de la seguridad de la información.
Estas personas no sólo darán una percepción adicional sobre cómo la
seguridad de la información ayudará a la empresa, también hará más
fácil llegar a la agenda de la alta dirección más rápidamente.
Regla 30-20-10. Cuando hagas tu presentación en PowerPoint, olvídate
de todas esas estadísticas de lujo que has encontrado, y las cientos de dia-
47
SEGURO & SIMPLE
positivas que usted preparó. En su lugar, use la regla 30-20-10: use fuen-
tes tamaño 30, máximo 20 minutos, y hasta 10 diapositivas. Y céntrese en
los beneficios – este es el mensaje principal que usted necesita dar. (Vea
también el Apéndice F para una plantilla de propuesta de proyecto.)
Cuidado con las palabras. Recuerde, su grupo objetivo son directivos
que no entienden o no les gusta sus expresiones friki. Por ejemplo:
En lugar de: Use esto:

Backup, sistema de extinción de
Prevención (Nos evitará...)
incendios (y otras salvaguardas)
Inversión (Invirtiendo en ...,
Coste
ahorraremos xyz dólares...)
Probabilidad Riesgo (Reduciremos el riesgo de...)
Daño (Reduciremos el daño
Incidente
implementando...)
Pérdida/tiempo de inactividad
Desastre (Perderemos xyz dólares; nuestro
tiempo previsto de inactividad durará...)
Figura 3: Palabras a evitar y palabras a usar cuando se presenta la seguridad

de la información
Y, sobre todo, sea paciente y persistente - compórtese como un vende-

dor real. Después de un tiempo, usted seguramente empiece a notar
algunos progresos – quizás no en el primer par de días o incluso en los
primeros meses, pero no deje que esto le desaliente.
3.3 ¿Es posible calcular el Retorno de la Inversión en

Seguridad (RIS)?
Muy a menudo le preguntarán, “Si invertimos xyz dólares en la seguri-
dad de la información, ¿cuánto ganaremos? ¿Cuál es el RIS?”
En lugar de mostrar una teoría profunda sobre cómo calcular el RIS (o

ROSI por sus iniciales en inglés Return On Security Investment), déjeme
darle un ejemplo sencillo.
48
Digamos que usted tiene un servidor que, si es destruido, el daño (tanto
en hardware, datos y tiempo de inactividad) sería de $100.000 – esto
también se denomina como Expectativa de Pérdida Simple, o en inglés
Single Lost Expectancy (SLE). Digamos que tienes una amenaza de incen-
dio, y que tal incidente puede suceder una vez en 20 años - esto significa
que la tasa anualizada de ocurrencia (ARO) sería 5%. Por lo tanto, aho-
ra tiene que calcular el valor del riesgo (o, utilizando esta terminología
complicada – Expectativa de Pérdida Anual, o en inglés Annualized Lost
Expectancy ALE) que se calcula multiplicando el SLE por el ARO.
Esto significa que el riesgo tiene un valor de $5.000 anualmente.
¿Qué significa esto? Esto significa que mientras usted invierta menos
de $5.000 en los sistemas de prevención de incendios y extinción de
incendios, hará que esto sea un beneficio. Por lo tanto, digamos que
invierte $4.000 en esos sistemas al año, lo cual significa que obtendrá
un beneficio de $1,000 cada año. Esta es la cantidad de dinero que ha
ahorrado su empresa en promedio, por año, porque con esos sistemas
nunca debe producirse un fuego (es decir, ha eliminado el riesgo).
Si obtuvo un beneficio de $1,000 en una inversión de $4.000, esto

significa que su RIS es 25% – bastante bueno, ¿no?
Sin embargo, es cierto: sí, es difícil calcular el daño que ocurriría; sí, no
hay estadísticas fiables sobre la frecuencia de estos incidentes. Pero,
con esfuerzo, se puede calcular el daño con una relativa exactitud y
puede hacer una suposición inteligente con la frecuencia – y sí, podría
perder 50 ó 70 por ciento, que es todavía mucho mejor que una pura
conjetura, por lo que puede perder 50 ó 70 veces.
Por lo tanto, el punto principal aquí es – a no ser que como mínimo de

alguna estimación a su dirección, no tendrán la menor idea acerca de
los beneficios de la seguridad de la información en términos económi-
cos. Y si usted habla con dólares y porcentajes, este es el lenguaje que
entiende la dirección, y eso hará que comiencen a escuchar.
Sin embargo, la inexactitud en estos cálculos no es el único problema

- otro problema es que toma tiempo y mucho esfuerzo. Por esta razón
49
SEGURO & SIMPLE
le recomiendo usar este cálculo de retorno de la inversión sólo si están
proponiendo inversiones grandes (por ejemplo, la compra de algunos
equipos caros) – en este caso, tiene sentido, para demostrar a su direc-
ción la lógica de los números.
 Herramienta libre: Esta calculadora para el Retorno de la Inversión

(Return on Security Investment) le da la fórmula para calcular el
daño de un incidente, y le ayuda a calcular el RIS total.
3.4 Tratar con la línea de responsables y otros empleados

La mayoría de los empleados de su empresa serán bastante escépticos
acerca de lo que hace, así que tiene que vender mucho la idea sobre ISO
27001. Y la buena noticia es – conseguirlo no es muy diferente de obte-
ner el compromiso de alta dirección. Otra vez, tiene que encontrar benefi-
cios que sean relevantes a los departamentos, o a las personas de manera
independiente, y presentar los beneficios de una manera convincente.
Por ejemplo, si el jefe del Departamento de ventas considera que la

seguridad de la información es absolutamente innecesaria, pregúntele
lo siguiente: “¿Qué habría sucedido durante el proceso de licitación si
filtra los datos de su propuesta a sus competidores”? Probablemente
le contestarían: “esto nunca ha sucedido hasta ahora, confío en mi
gente”. Pero luego puede proporcionarle ejemplos de cómo esto ha
sucedido por ejemplo a otras empresas de su industria, o tal vez como
datos de su empresa se han filtrado a algún otro departamento.
Usted puede seguir la conversación con un dato más. Digamos que su

Departamento de ventas desea enviar una propuesta a un concurso a
través del cual adquiriría el cliente más grande de los últimos 3 años.
¿Qué pasa si la revelación de datos ocurre en medio de este proceso?
Una vez que pueda abrir una ventana de oportunidad, tiene que ex-
plicar qué es lo que puede hacer para él y para su Departamento: se
puede definir exactamente quién puede acceder a los datos, dónde se
almacenan los datos, y cómo se transmiten - el punto es, con relativa-
mente poco esfuerzo se puede prevenir un gran incidente.
50
Y así es como lo puede hacer con cualquier departamento, con cual-
quier persona - desde mi experiencia, hasta el momento, no he encon-
trado ningún departamento de cualquier empresa que no se beneficie
de la seguridad de la información.
Así que, ¿qué significa esto para usted? Haga su tarea primero. Estudie
sus procesos de negocio, sus productos principales, lo que es crítico en
todos los departamentos, las fechas importantes, etc. Una vez esté ar-
mado con este conocimiento, usted será capaz de conseguir convencer
a casi cualquier persona.
Por supuesto, tiene que seguir repitiendo estas actividades de convenci-

miento de una manera sistemática - esto normalmente se hace a través
de un programa de desarrollo de concienciación, como analizaremos
en la secci 6.4.
3.5 Cerrar la brecha entre TI y el negocio

Como se mencionó antes, en general está muy extendido el mito de
que el Departamento de TI se encargará de la ISO 27001 o de la segu-
ridad de la información - por lo tanto, como ya señalé, es muy impor-
tante explicar a todos que las computadoras no pueden hacer todo el
trabajo. Generalmente, las empresas ya tienen toda la tecnología que
necesitan, sólo necesitan empezar a utilizarla de forma segura.
Esto también trae otra perspectiva – el proyecto de seguridad de la in-

formación no debe ser tratado como un proyecto de TI, y un responsa-
ble de proyecto debe ser alguien que tenga un perfil tanto del negocio
como de TI.
Por tanto, qué hacer cuando escuche de administradores de sistemas,

responsables de TI y otro personal, quejas del tipo, “Oh no, ahora nos va-
mos a inundar de un montón de documentos,” y “Genial, ahora vamos
a tener que trabajar horas extras”, etc. Usted debe explicarles que ISO
27001 puede facilitarles su trabajo si ellos saben cómo obtener beneficios
de ella; Si ellos lo enfocan como algo negativo, entonces está claro - la
documentación será una sobrecarga, y trabajarán más horas.
51
SEGURO & SIMPLE
En mi experiencia, aquí están las cuatro principales áreas donde el per-
sonal de TI puede beneficiarse más de un proyecto de ISO 27001:
Ahorrar tiempo. ¿Sabe qué tipo de solicitudes de apoyo son las que
llegan con más frecuencia al Departamento de TI? Las que los usua-
rios de un sistema de información han cometido algún tipo de error
(no usar una palabra pesada aquí), por lo que el personal de TI tiene
que pasar interminables horas en corregirlos. Bien, ISO 27001 trata de
definir reglas claras – quién puede hacer qué, cómo, y quién es el res-
ponsable. Sí, va a tener que invertir tiempo en establecer estas reglas
correctamente, pero una vez que estén establecidas conseguirá que sus
usuarios creen menos problemas.
Captar la atención de la alta dirección. Los empleados de TI muy a

menudo se encuentran en la situación de proponer algunos cambios
en su trabajo, o proponer alguna nueva tecnología para aumentar el
nivel de seguridad. Muy a menudo la respuesta a este tipo de iniciativas
es “¿Esto es realmente necesario?” Si se inicia la implementación de
ISO 27001, una de las cosas que necesita hacer es lo que se denomina
como la evaluación del riesgo – esto significa básicamente que tendrá
que ir sistemáticamente a través de todos los posibles problemas, y ele-
gir cuáles pueden ser más probables, y cuáles podrían herir su empresa
con mayor gravedad. Luego puede presentar estos resultados para con-
vencer a la dirección de que algunos temas tienen una prioridad alta.
Proteger el personal de TI. Cuando se produce un incidente de segu-

ridad, normalmente el Departamento de TI tiene la culpa: “¿por qué no
previniste esto?” o “¿por qué no reaccionaste más rápidamente?” En
primer lugar, con la implementación de ISO 27001 usted define roles
y responsabilidades claramente – por lo tanto, si alguien ha cometido
un error porque no ha cumplido con la adecuada ejecución de los pro-
cedimientos, la dirección no podrá culpar al Departamento de TI. En
segundo lugar, durante este tipo de proyectos el Departamento TI ten-
drá que proponer cambios a su dirección de una manera formal - si se
rechazan, entonces tendrá una evidencia documentada de que usted
hizo su trabajo para evitar incidentes.
52
Mejorar las perspectivas de carrera. Los empleados de TI pueden
considerar la seguridad de la información como un lastre, pero el he-
cho es – la industria de la seguridad está creciendo muy rápidamente,
incluso más rápido que la industria de TI. Por lo tanto, con experiencia
en TI y en seguridad de la información, los empleados de TI pueden
crecer incluso más rápido. (El capítulo 12 habla sobre las oportunidades
de carrera en este sector).
Por lo tanto, utilice estos cuatro argumentos cuando presente el caso

de ISO 27001 a su Departamento de TI.
3.6 Factores de éxito

● En Resumen, para obtener el compromiso de sus directivos y sus
colegas, usted debe hacer lo siguiente:
● Empiece a pensar desde la perspectiva de beneficios, no desde la

perspectiva técnica
● Encuentre 2 ó 3 beneficios relevantes para el negocio que se pro-

duzcan gracias a la implementación de la ISO 27001 y preséntelos a
la alta dirección
● El trabajo de conseguir el compromiso es extensa, e incluye una gran

cantidad de actividades diplomáticas y de ventas
● Si la inversión en seguridad es necesaria, trate de calcular el RIS
● Trate de encontrar beneficios personales y departamentales al hablar

con la línea de responsables y otros empleados
● Utilice la implementación de ISO 27001 como un método para eli-

minar la brecha entre TI y el negocio
En el siguiente capítulo le mostraré cómo organizar su proyecto para

que sea exitoso.
53
4
PREPARACIÓN PARA
LA IMPLEMENTACIÓN
¿La razón número dos por la que falla la ISO 27001? Por no tratar la
implementación como un proyecto con un responsable y otros recursos
dedicados. El enfoque de dar todo este trabajo a un administrador de
TI, diciéndole: “OK, de ahora en adelante toma todo el control de la
seguridad de la información,” simplemente no funcionará.
No funcionará no porque esta persona no tenga el conocimiento; no

funcionará porque esta persona no tiene suficiente tiempo y suficiente
autoridad para implementar un proyecto tan complejo. Por lo tanto,
necesita establecer una fase inicial del proyecto correctamente.
Este probablemente es un buen momento para destacar que la imple-

mentación del proyecto de manera exitosa, no es suficiente para ase-
gurar que la seguridad de la información también sea exitosa - una vez
finalizado el proyecto, se debe mantener la documentación, se necesitan
aprender las lecciones, etc. Por tanto, en los capítulos del 5 al 9, hablaré
sobre cómo implementar los elementos del SGSI utilizando un enfoque
de proyecto (proyecto con un claro comienzo y final), mientras que en el
capítulo 10, voy a explicar cómo mantener la seguridad de la información
actualizada y con un uso diario. El funcionamiento de acuerdo a todas las
reglas de seguridad de la información que se han establecido, será una
actividad periódica que debe hacerse después de que finalice su proyecto.
4.1 Estrategia ISO 27001: Tres opciones para

la implementación
Al inicio de la implementación del estándar ISO 27001, probablemente
esté abrumado con diversos enfoques sobre cómo empezar y terminar
con éxito este proyecto. En mi opinión, hay básicamente tres opciones
54
Preparación para la implementación
para implementar este estándar: (1) hacerlo completamente con sus
propios empleados, (2) Utilizar un consultor, o (3) (término medio) im-
plementar el estándar con un enfoque de hacerlo usted mismo con sus
recursos, pero aprovechando conocimientos de expertos externos.
Pero, no todos estos métodos son aplicables a todo el mundo – aquí
hay una explicación de cada una de estas opciones, y en qué situacio-
nes son adecuadas.
1) Implementar el estándar usando personal propio de la orga-
nización. Esto es cuando usted decide implementar el estándar sin
ayuda externa, utilizando solamente el conocimiento y la capacidad de
sus propios empleados. En esta opción, sus empleados hacen todos los
análisis, realizan todas las entrevistas, redactan la documentación, etc.
Pros. Esta es probablemente la opción más barata, porque usted no
paga un servicio externo; Usted también está evitando que cualquier
persona externa pueda aprender algo acerca de sus procesos internos
o su documentación; por último, si escribe su propia documentación
aumenta el compromiso de sus empleados hacia los cambios que se
puedan requerir.
Contras. Esta es probablemente la opción más lenta porque lo hace
todo por su cuenta; Si sus empleados no son experimentados o lo su-
ficientemente expertos, esta podría ser la opción más costosa debido a
los errores que podrían producirse.
2) Usar un consultor. Con esta opción usted contrata a un experto ex-
terno (normalmente es un consultor local) que tiene experiencia con la
implementación de la norma - esta persona entonces realiza el análisis
de su empresa, hace las entrevistas, escribe la documentación y todo lo
demás – básicamente, implementa todo el estándar para usted.
Pros. Esta es sin duda la forma más rápida de implementar el están-
dar – si contrata a un buen consultor, este tendrá mucha experiencia
y sabrá cómo organizar el proyecto para terminarlo rápidamente; Esta
es también la mejor manera si sus empleados no tienen tiempo para
dedicar a este proyecto.
55
SEGURO & SIMPLE
Contras. Los consultores obviamente cuestan dinero, así que esta es la
opción más costosa; Además, de esta manera da acceso a casi todos los
secretos de su empresa a un externo (por ejemplo, cómo está organizada
la empresa, sus principales procesos y ventajas competitivas clave, quienes
son las personas más importantes, etc.); Finalmente, cuando un externo
escribe la documentación, los empleados pueden sentir que se les impo-
nen políticas y procedimientos, y a menudo buscarán maneras de eludirlos.
En la siguiente sección verá un par de sugerencias sobre cómo elegir a
un consultor.
3) Implementar el estándar con un enfoque HUM (Hacerlo Usted
Mismo) y usando conocimiento externo. Esta opción se convirtió en
muy popular en los últimos años, y básicamente es un término medio
entre las dos primeras opciones. Aquí es donde sus empleados hacen la
implementación completa, pero obtienen el conocimiento, la documenta-
ción y el apoyo de una parte externa.
Pros. Esta opción no es tan cara como la de los consultores, y tiene
todos los conocimientos necesarios y el apoyo; Además, no da acceso a
su información confidencial a ninguna persona externa. Por otra parte,
dado que sus empleados escriben la documentación, el compromiso de
seguir las nuevas reglas será probablemente mucho mayor.
Contras. Sus empleados tendrán que aprender sobre la implementa-
ción, así que esta no es la forma más rápida de implementar el están-
dar; Además, esta opción no resuelve el problema si sus empleados es-
tán completamente abrumados con otros proyectos y no tienen tiempo
para otra cosa.
Por lo tanto, ¿qué opción elegir? Debería implementar el estándar con
sus propios empleados si tiene empleados que ya tienen experiencia en
la implementación, si usted tiene datos muy confidenciales, y si su presu-
puesto es muy bajo. Por otro lado, si usted tiene prisa y no tiene miedo
de que algunos de los secretos de la compañía pueden estar expuestos
a personal externo, deberá utilizar a un consultor; por supuesto, usted
necesitará un buen presupuesto para esta opción. Finalmente, puede
escoger la opción del enfoque Hacerlo-Usted-Mismo si desea que sus
empleados aprendan cómo se hace, no tiene demasiada prisa, y su res-
56
ponsable de proyecto puede dedicar un par de horas por día para este
proyecto; y, por supuesto, si tu presupuesto no es demasiado alto.
4.2 Cómo seleccionar un consultor

Si usted decide utilizar un consultor, asegúrese cuidadosamente de que lo
selecciona – aquí tiene algunas cosas en las que debería prestar atención:
Experiencia & habilidades. Haga una investigación, no sólo sobre la

empresa, sino también sobre la persona que haría el trabajo de con-
sultoría - ¿tiene certificados como el del Curso de Auditor Jefe ISO
27001 o el de Implementador Jefe ISO 27001? ¿Cuántos trabajos ha
realizado?, y ¿cuánto tiempo lleva en este negocio? ¿Para qué tipo de
empresas trabaja? Por ejemplo, si sólo ha trabajado para los bancos, no
sería una buena elección para una empresa de TI.
Reputación. De lejos, la mejor manera de conocer la reputación del

consultor es llamar a los clientes con los que afirma que ha trabajado –
muy a menudo usted se sorprenderá de que el alcance del trabajo que
estaba realizando era mucho más pequeño de lo que parecía, y a veces
los clientes no hablan favorablemente sobre el servicio que recibieron. Si
un consultor ha publicado algunos libros o artículos sobre un tema, si es
un orador frecuente en conferencias, o si está ofreciendo cursos sobre
el estándar ISO 27001, entonces probablemente sea una buena opción.
Servicio personalizado. Evite los consultores del tipo “copiar-pegar”,

ya que implicará que tendrá que terminar de completar plantillas y no
le aportarán nada nuevo. En realidad, usted aprenderá mucho sobre la
voluntad de un consultor de adaptar el servicio a sus necesidades durante
el período de negociación. Si usted siente que no es lo suficientemente
adaptable, o no le gusta su estilo de comunicación, huya de este acuerdo.
Lenguaje. Elegir un consultor que no habla su idioma local (o lo ha-

bla mal) probablemente le puede llevar al desastre. No espere que un
traductor le ayude con este problema, el trabajo de un consultor es
entender todos los matices de sus operaciones, y no puede hacerse a
través de una tercera persona.
57
SEGURO & SIMPLE
Conflicto de intereses. Contratar a un consultor que vende sólo
esto – servicios de consultoría. Evite aquellos que ofrecen, por ejem-
plo, herramientas de software, a menos que quiera convertirse en un
objetivo de ventas.
Hay una buena razón por la que creo que los precios deben ser uno
de los criterios a utilizar - muchas veces he visto a empresas selec-
cionar el consultor más barato, y más tarde han descubierto que era
realmente la opción más cara. Los consultores más baratos general-
mente no tienen mucho trabajo, por eso ofrecen los precios más ba-
jos – quieren sobrevivir en el mercado. Pero, la pregunta importante
aquí es: ¿porqué no tienen suficiente trabajo? ¿Porque son nuevos
en este mercado y no tienen suficiente experiencia? ¿O porque no
tienen una buena reputación, y muchos clientes prefieren evitarlos?
Piense en todo esto cuando usted tome su decisión.
Por supuesto el precio es importante, pero tiene que calcular el precio total
del proyecto – y generalmente el precio extra que paga por un buen con-
sultor le costará mucho menos que los ahorros que le de otro consultor.
Vea también el Apéndice I para una lista detallada de las preguntas que
debe hacer a posibles consultores.
4.3 ¿Debería usar un análisis de brecha?

El análisis de brechas no es nada más que leer cada cláusula del están-
dar ISO 27001 y analizar si cada requisito ya está implementado en la
empresa. Cuando lo haga, usted puede decir Sí o No, o puede utilizar
una escala similar a esta:
● 0 – requisito no implementado ni planificado;
● 1 – requisito planificado pero no implementado;
● 2 – el requisito está implementado sólo parcialmente, por lo que
no se pueden esperar un efecto completo;
● 3 – el requisito está implementado, pero no es medido, revisado y
mejorado; y
58
● 4 – el requisito es implementado y medido, revisado y mejorado
regularmente.
El análisis de brecha es obligatorio en el estándar ISO 27001, pero sólo
en el desarrollo de la Declaración de Aplicabilidad – la cláusula 6.1.3 d)
dice que es necesario determinar “... Si [los controles necesarios] están
implementados o no.”
Por lo tanto, el estándar no requiere que realice el análisis de las cláusu-

las 4 a la 10 de la parte principal de la norma – tiene que hacerlo sólo
para los controles del anexo A. Además, no necesita realizar el análisis
de brecha antes del inicio de la implementación de la ISO 27001 – debe
hacerlo solamente después de la evaluación y tratamiento del riesgo.
Sin embargo, muchas empresas realizan el análisis de brecha del están-

dar ISO 27001 antes de iniciar la implementación, sólo para obtener
una sensación de cómo están en comparación con los requisitos del
estándar, así que si tiene tiempo y si cree que puede ser beneficioso,
también puede probarlo.
 Herramienta libre: Este recurso gratuito Herramientas ISO 27001
le ayudará a realizar el análisis de brecha.
4.4 Secuencia para la implementación de la ISO 27001

& relación con el ciclo PDCA
La buena noticia es: ISO 27001 le hace más fácil la implementación del
estándar, proporcionarle los pasos a seguir en la implementación.
ISO 27001 está escrito de forma clara y secuencial, por tanto, básica-
mente los pasos de su implementación deben seguir casi exactamente
la misma secuencia que el orden en el que está escrito el estándar. O,
para ser más precisos, sus pasos en el plan de proyecto deben parecerse
a las cláusulas 4 a la 10 del estándar, en el orden que están escritos,
esto es exactamente lo que describiré en los capítulos de 5 al 10 de este
libro. Hay algunas raras excepciones a esta regla, en las que también
haré hincapié en los siguientes capítulos.
59
SEGURO & SIMPLE
Esta secuencialidad es una consecuencia del estándar está escrito de acuerdo
al ciclo Plan-Do-Check-Act (PDCA), que dice que, para tener un sistema de
gestión eficaz, primero es necesario planificar lo que quieres hacer (incluyen-
do los objetivos), después tienes que implementar (fase Do) lo que ha pla-
neado, a continuación, usted tiene que comprobar si su implementación ha
logrado los resultados previstos, y finalmente tiene que llenar el vacío (fase
Act) entre lo que usted consigue y lo que usted planeó conseguir. Puesto que
las cláusulas de la 4 a la 10 siguen exactamente esta lógica, es por esto que
se debe seguir en este orden a la hora de la implementación del estándar.
Por favor, tenga en cuenta que cuando se utiliza la palabra implemen-
tación a lo largo de este libro no significa necesariamente sólo la fase
de implementación (Do) en el ciclo PDCA – por implementación me re-
fiero a las medidas que sean necesarias para aplicar los requisitos de la
ISO 27001, no importa en la fase del ciclo PDCA a la que pertenezcan.
En el Apéndice B de este libro encontrará un diagrama de implementa-
ción que muestra todos los pasos según los requisitos de la ISO 27001.
Este diagrama incluye todas las fases del ciclo PDCA, pero sólo desde la
perspectiva de la implementación inicial del estándar.
El resultado en la mayoría de los pasos mencionados en este diagrama
son varios documentos – cubriré la documentación que será elaborada
en los siguientes capítulos, y también puede ver la lista de documenta-
ción obligatoria de la ISO 27001 en el Apéndice A de este libro.
 Herramienta libre: Conformio es una herramienta online que cu-

bre todos los pasos del ciclo PDCA, y también incluye guías para la
implementación de todos los pasos.
4.5 Estableciendo un proyecto para

la implementación de la ISO 27001
No importa la opción de implementación que elija, usted tendrá que
configurar su gestión de proyectos. La gestión de proyectos es un tema
que puede abordar un libro entero, pero voy a dar aquí sólo un resu-
men de los elementos básicos de gestión de proyectos:
60
Plan de proyecto. Es necesario definir lo que quiere lograr con su
proyecto y quién es responsable de las cosas; describa los roles del
responsable de proyecto, los miembros del equipo de proyecto y el pa-
trocinador; y haga una lista de los pasos del proyecto y sus entregables,
hitos y plazos. (Vea también el Apéndice G para una plantilla con una
lista de verificación del proyecto y el Apéndice H para una plantilla para
el plan de proyecto.)
Responsable de proyecto. Esta es la persona que coordinará todos

los esfuerzos y será responsable de la sincronización del proyecto y los
resultados. En la mayoría de los casos, el responsable de proyecto será
la persona responsable de la seguridad de la información – por ejem-
plo, el Responsable de Seguridad de la Información, el Coordinador de
Seguridad de Información, el Oficial de Seguridad de la Información, el
Jefe de Seguridad de la Información o similar. (A lo largo de este libro,
usaré el término Chief Information Security Officer o CISO (Responsa-
ble de Seguridad de la Información) para referirme a la persona que
está a cargo de la seguridad de la información.)
Patrocinador del proyecto. Es una persona de la alta dirección que

interviene cuando el proyecto se detiene (y créame, va a suceder muy
a menudo). El mejor enfoque sería tener a una persona que realmente
entienda lo que está tratando de lograr, pero al mismo tiempo tenga
suficiente capacidad como para empujar el proyecto, por esta razón esta
persona tiene que pertenecer a la parte superior de su organización.
Equipo de proyecto. A menos que sea una pequeña organización, debe

formar un equipo de proyecto compuesto por entre cinco y siete personas
de diferentes unidades organizativas - idealmente, usted tendría que tener
una persona del Departamento de TI, y el resto de otros departamentos
importantes o unidades de negocio. El propósito de este equipo es ayudar
a coordinar el proyecto a través de diferentes unidades organizativas y en
algunos casos, para tomar decisiones en lugar de la alta dirección.
Otros empleados. Es un mito común que sólo el CISO escriba todos los
documentos - la realidad no puede ser más diferente. Aunque el CISO
escribirá numerosos documentos, algunos de estos – por ejemplo, los
procedimientos operativos detallados – los escribirán los empleados de los
61
SEGURO & SIMPLE
departamentos que correspondan. Por lo tanto, es importante establecer
al menos un representante de cada departamento que dedicará un par de
días a este proyecto. Por supuesto, si usted ya tiene representantes de los
departamentos en un equipo de proyecto, no necesita gente adicional.
Herramientas para la gestión del proyecto. Para facilitar la imple-
mentación de su proyecto, puede usar algunas herramientas que van
desde un simple diagrama de Gantt hasta software de gestión de pro-
yectos, que puede utilizar para la comunicación y colaboración entre los
miembros del equipo de proyecto, registrar todas las tareas, realizar re-
portes, gestión de archivos, etc.
 Herramienta libre: Conformio es una herramienta online que pro-
porciona todas las herramientas para la gestión del proyecto ISO
27001 – tareas, colaboración, gestión documental, etc.
4.6 Quién debería ser el responsable de proyecto

Competencias generales. Dado que la ISO 27001 está estrechamen-
te relacionada con la tecnología de la información, el responsable del
proyecto debe tener como mínimo conocimientos básicos de TI; sin em-
bargo, dado que este proyecto no debe ser tratado como un proyecto
de TI, sería mejor si no tiene a alguien del departamento de TI que li-
dere este tipo de proyecto - de esta manera evitará tratar este proyecto
como un proyecto sólo de TI.
Lo que necesita es a alguien con un conocimiento equilibrado de TI y
de los procesos de negocio de su empresa, porque gestionar la seguri-
dad de la información, en la mayoría de los casos, está relacionado con
cuestiones organizativas, lo que significa ocuparse de políticas y proce-
dimientos, definir responsabilidades y gestionar cambios, etc. Además,
dado el responsable de este tipo de proyectos a menudo tendrá la opo-
sición de algunos de sus colegas, esta persona debe tener suficiente
autoridad ya sea por posición o por respeto de sus colegas.
Una vez que este proyecto finaliza, esta persona es el candidato idóneo
para convertirse en su CISO. Más adelante en la sección 5.7 hablaré
sobre las responsabilidades del CISO.
62
Habilidades necesarias & disponibilidad. Sería perfecto si su respon-
sable de proyecto tuviera experiencia con la implementación de ISO
27001, pero encontrar este tipo de personas es muy raro. En la mayoría
de los casos, esta persona obtendrá estos conocimientos asistiendo a
cursos – el mejor el curso de Auditor Jefe y el de Implementador Jefe.
Voy a explicar en detalle estos cursos más adelante en la sección 12.1.
Con respecto al tiempo necesario, para una compañía pequeña el res-

ponsable de proyecto tendrá que dedicar sobre 1 ó 2 horas por día
para este tipo de proyecto; para una empresa con un par de miles de
empleados, este tipo de proyecto consumirá a esta persona el 100%
del tiempo a lo largo de la duración del proyecto.
¿De la empresa o externalizado? No hay duda sobre esto - el respon-

sable de proyecto debe ser alguien de dentro de su empresa – esto es
necesario porque un externo no puede conocer todos los detalles y las
cuestiones culturales de su empresa. Cuando las cosas se ponen difí-
ciles (que sin duda lo harán durante este tipo de proyecto), necesita a
alguien que sepa a quién dirigirse, qué tipo de enfoque aceptarán unos
empleados y evitarán otros.
No me malinterpreten – debe recibir ayuda externa para obtener el co-

nocimiento, pero un consultor no puede liderar su proyecto.
¿Qué tipo de autoridad? Esta es probablemente la pregunta más difícil

– por un lado, el responsable de proyecto tiene sólo un rol temporal, y
por otro lado, esta persona tiene que cambiar cómo se hacen las cosas
en su empresa. Así que teóricamente hablando, esta persona debe te-
ner una autoridad formal para implementar cualquier cambio necesario
como parte de este proyecto.
Pero, en realidad, estas dos características son mucho más importantes

que la autoridad formal:
Hasta qué punto el responsable del proyecto se coordina con el pro-

motor del proyecto - porque cada vez que el responsable del proyecto
golpea una pared, será el patrocinador el que le proporcionará una
manera de quitar el muro.
63
SEGURO & SIMPLE
El nivel de habilidades “diplomáticas” del responsable del proyecto – dado
que el promotor del proyecto no entrará en todos los detalles, el respons-
able del proyecto tendrá que encontrar maneras de pasar este muro.
Por lo tanto, el punto es – el responsable del proyecto es una figura

central en la implementación, y el éxito del proyecto depende mucho
de esta persona, mas de lo que usted cree. Por lo tanto, para poder
triunfar, encuentre a una persona adecuada, proporciónele las habilida-
des necesarias y dele un buen patrocinador. La alternativa es tener uno
de esos proyectos que nunca tienen un final.
4.7 ¿Cuánto puede durar?

La mayoría de las personas suelen tener expectativas equivocadas sobre
cuánto tiempo durará implementar el estándar, como por ejemplo “nos
llevará un mes o dos.” Esto no es realista - la realidad se acerca a un año.
Por supuesto, puede elaborar 50 documentos en pocos días, afirmando

que cumple con ISO 27001, pero esto no es de lo que estoy hablando
aquí. Estoy hablando de una implementación que tenga sentido, es decir,
que produzca resultados – un menor número de incidentes, una mayor
eficiencia, ahorros en costes, etc.; Si vas con el enfoque de “rápido y abun-
dante”, probablemente no conseguirá nada, ni siquiera la certificación.
Su mayor esfuerzo en la implementación lo empleará en las fases Plan

y Do, es decir, las dos primeras fases del ciclo PDCA, en las cuales se
realiza la evaluación del riesgo, y se implementan todos los controles
aplicables. Esta es básicamente la duración de su proyecto de implanta-
ción de ISO 27001 – después de ese tiempo, el sistema debe estar listo,
y usted podrá ir a por la certificación. (Vea también el capítulo 11 para
ver lo que usted necesita para prepararse para la certificación.)
La duración de la implementación de estas dos fases depende principal-

mente del tamaño de la organización:
● Organizaciones pequeñas (hasta 50 empleados) generalmente im-

plementan el estándar en 8 meses
64
● Organizaciones de tamaño mediano (hasta 500 empleados) gene-
ralmente necesitan entre 8 y 12 meses para implementar el estándar
● Grandes organizaciones (más de 500 empleados) – la implementa-

ción generalmente suele durar entre 12 y 15 meses
Una nota aquí - en mi experiencia, las empresas que arrastran este tipo
de proyectos durante un periodo demasiado largo (por ejemplo, pe-
queñas empresas que emplean más de 12 meses), generalmente nunca
terminan el proyecto – en estas organizaciones nunca es suficiente el
reconocimiento de la importancia de la ISO 27001, así que nunca tienen
suficientes recursos humanos o financieros, dedicados a este proyecto.
Tenga en cuenta que trabajar en el estándar ISO 27001 no se detiene

con las fases Plan y Do – estos sistemas de gestión tienen que ser man-
tenidos y mejorados (fases Check y Act), lo que significa que el trabajo
sobre la seguridad de la información no se para, es continuo – hablaré
sobre esto en el capítulo 10.
 Herramienta libre: Utilice este recurso Calculador gratuito del

tiempo de implementacion para iso 27001 para estimar el tiempo
de implementación en su compañía.
4.8 ¿Cuánto puede costar?

Una vez que sabe cómo estructurar el proyecto, es hora de obtener
el presupuesto, por favor no omita este paso, porque sin dinero este
proyecto simplemente no funcionará. Y su dirección se pondrá muy
seria cuando se hable de dinero, así que tiene que prepararse adecua-
damente.
El proceso de aprobación del presupuesto debe ser compatible con su

proceso de aprobación establecido, en las grandes empresas tiende a
ser muy formal, mientras que en compañías más pequeñas general-
mente es informal. En cualquier caso, tiene que saber esto antes de
empezar a escribir números.
65
SEGURO & SIMPLE
Cualquiera que sea el proceso, probablemente deberá hacer lo siguiente:
1) Distinguir entre costes de una sola vez, como por ejemplo costes
iniciales de la implementación (costes de proyecto), y costes dia-
rios de la gestión de la seguridad de la información una vez que el
proyecto ha finalizado (costes de funcionamiento).
2) S
ea concreto – averigüe exactamente cuánto son los costes, por-
que a la dirección no le gusta perder su tiempo con vagas figuras.
3) Antes de enviar estos costes para su aprobación, consulte infor-

malmente con alguien que conozca cómo funciona este proceso
– un patrocinador del proyecto sin duda sería una buena persona
para esto, pero también su director financiero o tal vez su jefe de
departamento.
Ahora, vamos a ver para lo que debe de hacer planes – por desgracia,
no puedo darle las cantidades exactas, porque difiere mucho de gran-
des a pequeñas empresas y de una parte del mundo a otro, pero al
menos puedo decirle los costes que tendrá su presupuesto:
Costes del proyecto. El problema aquí es que no sabrá por adelanta-

do todos los gastos - algunos de los costes serán evidentes solamente
una vez que su tratamiento de riesgo haya finalizado (explicado en el
capítulo 7), porque sólo entonces sabrá qué tipo de controles técnicos y
otras medidas de seguridad necesitará. Sin embargo, su dirección pro-
bablemente utiliza este tipo de proyectos donde el análisis viene prime-
ro, y sólo después del análisis en una segunda fase muestra los costes
para las opciones de implementación decididas – no tenga miedo de
proponer el presupuesto de su proyecto en un enfoque de dos fases.
De todos modos, el proyecto probablemente incurrirá en los siguientes

costes:
● Trabajadores – en primer lugar, usted tendrá el coste de su res-

ponsable de proyecto, pero también de otros empleados impli-
cados en el proyecto; incluso si ya están en nómina, tendrán que
pasar tiempo con el estándar ISO 27001 en lugar de trabajar en
otra cosa. Este es normalmente el mayor coste en el proyecto.
66
● Tecnología – Esto podría ir desde la compra de un nuevo software
hasta suscribirse a alguna herramienta online. Estos costes son gene-
ralmente más bajos que el coste de empleado puesto que las empre-
sas generalmente ya tienen la mayoría de las tecnologías necesarias
para el proyecto.
● Literatura y formación – varios libros y/o cursos.
● Asistencia externa – si decide usar un consultor o algún tipo de
soporte online.
● Herramientas y plantillas de documentos – si decide ejecutar
el proyecto sin un consultor.
● Entidad certificadora – si decide ir a por la certificación.
Costes de funcionamiento. Presupuestar para esto será muy pareci-
do a su proceso normal de presupuestos – usted tendrá que planificar
los costes que normalmente tiene para otras operaciones, por ejemplo:
● Salarios de trabajadores – El CISO y demás personal que trabaja
en seguridad de la información; desde mi experiencia, no habrá el
tiempo adicional necesario para que otros empleados puedan eje-
cutar los controles de seguridad – si las políticas y procedimientos
se escriben en una forma razonable, entonces estas actividades
entrarán en una dinámica de trabajo de funcionamiento normal.
● Costes de oficina donde trabajan los empleados (alquiler, electri-
cidad, teléfono e Internet, computadoras, etc.)
Sin embargo, también tiene que planificar algunos otros costes de fun-
cionamiento que su empresa probablemente no tenía antes:
● Formación y concienciación, costes directamente relacionados
con la seguridad de la información
● Auditorías internas (si contrata una persona o empresa externa
para hacer esto)
● Visitas de seguimiento de la entidad certificadora y re-certificación
● Uso de herramientas de seguridad de la información
67
SEGURO & SIMPLE
Y este nivel de detalle será suficiente – si usted realmente lista todos
estos elementos, sus ejecutivos estarán probablemente impresionados
por su minuciosidad.
4.9 Usar herramientas y plantillas

Cuando comience a implementar un complejo estándar como ISO 27001,
probablemente necesite buscar una manera de facilitar el trabajo. ¿Quién
no? Después de todo, reinventar la rueda no es un trabajo muy interesante.
Pero tenga cuidado cuando empiece a buscar esas herramientas – no

todas las herramientas le ayudarán: podría terminar con una rueda de
carro que no encaja en el coche que usted está conduciendo.
Tipos de herramientas. Vamos a empezar primero con qué tipos de

herramientas se encontrará en el mercado, y que están hechas especí-
ficamente para ISO 27001:
a)
Herramientas para automatizar actividades – Estas herra-
mientas le ayudan a semi-automatizar parte de los procesos – por
ejemplo, la gestión del proyecto, la realización de la evaluación
del riesgo, el almacenamiento y aprobación de la documentación,
gestión de incidentes, asistencia en las mediciones, etc.
b) Herramientas para escribir documentación – Estas herramien-

tas le ayudan a desarrollar las políticas y los procedimientos, ge-
neralmente, incluyen plantillas de documentación, tutoriales para
escribir documentación, etc.
Pros y contras de herramientas para automatizar. La idea básica de

las herramientas de automatización es eliminar el tiempo que consumen
actividades como el uso de hojas de cálculo para la evaluación de riesgo
en varios de sus departamentos – una herramienta inteligente le ayudará
a combinar estos resultados; las herramientas de automatización deben
también de ayudarle a manejar el proyecto ISO 27001, sugiriendo qué
pasos necesita tomar, quién es responsable de qué cosas, qué documen-
tos tienen que ser elaborados y aprobados, por quién, etc.
68
El mayor problema de las herramientas de automatización es que la ma-
yoría está hecha para grandes empresas: la mayoría de estas herramientas
no tienen en mente un precio para las empresas más pequeñas, y peor
aún – tienen multitud de funciones que implica que se tenga que formar
a los empleados para que sepan cómo utilizarlas, lo que puede llevar de-
masiado tiempo. Por lo tanto, usted debe definitivamente tener en cuen-
ta la facilidad de uso, así como los precios, antes de tomar una decisión.
¿Se puede automatizar todo? Se debe acentuar un hecho importante

aquí: las herramientas de automatización no pueden ayudarle a gestio-
nar su seguridad de la información. Por ejemplo, no pueden automatizar
su política de control de acceso – para finalizar un documento de este
tipo, necesita coordinar su CISO, con el departamento TI y la parte del
negocio de la organización, y sólo después de alcanzar un acuerdo podrá
escribir esta política. La automatización no puede hacer esto por usted.
Sí, se puede semi-automatizar la medición exitosa de controles particu-

lares, pero de nuevo los humanos tienen que interpretar estos resulta-
dos para comprender por qué el control está bien o mal – esta parte del
proceso no se puede automatizar, y tampoco puede automatizarse la
decisión sobre qué acciones correctivas o preventivas deben adoptarse
como resultado de la información adquirida.
Herramientas para escribir documentación. Probablemente no ne-

cesitará herramientas para escribir sus políticas, procedimientos y pla-
nes si usted desarrolló ya su documentación basándose en un marco de
trabajo similar a ISO 27001 – por ejemplo COBIT. Por otra parte, tam-
bién, si usted contrató a un consultor, entonces será su deber redactar
todos los documentos.
En otros casos encontrará las herramientas de documentación escrita (es

decir, plantillas de documentación) muy útiles porque se puede acelerar el
desarrollo de sus políticas y procedimientos. La pregunta principal aquí es
cómo elegir las herramientas adecuadas – aquí tiene un par de consejos:
● ¿Son apropiadas para el tamaño de su empresa? Si eres una pe-

queña empresa y las plantillas se hacen para grandes empresas,
serán un sobre esfuerzo para usted, y viceversa.
69
SEGURO & SIMPLE
● ¿Qué tipo de ayuda recibe para escribir los documentos? ¿Existe
alguna directriz, tutoriales, ayuda o cualquier cosa similar que ven-
ga con las plantillas?
● ¿Experiencia de los autores? Sería mejor si el autor tiene experien-

cia en consultoría y auditoría, para que las plantillas sean prácticas
para las operaciones diarias, pero también aceptables para la au-
ditoría de certificación.
Debo admitir que estoy bastante prejuiciado cuando se trata de herramien-

tas, ya que soy el autor del Paquete de Documentos de ISO 27001 y coau-
tor de Conformio, la herramienta de estándares ISO basada en la nube.
Pero, no puedo evitarlo - creo que, si elige la herramienta adecuada, puede
acelerar su implementación y facilitar el mantenimiento de su sistema.
 Herramienta libre: Conformio es una herramienta online que pro-

porciona todas las herramientas para proyectos ISO 27001, tareas,
colaboración, gestión documental, etc.
4.10 Decida su estrategia de documentación

Otra cosa a tener en cuenta si desea que la documentación trabaje para
usted y no al revés: es crucial producir documentación que esté optimi-
zada para el tamaño y la complejidad de su empresa.
Número y complejidad de documentos. Básicamente, usted tiene

que tomar estas decisiones antes de empezar su proyecto: (1) quiere
un mayor o menor número de documentos, y (2) quiere documentos
detallados o más breves. Mientras tenga más documentos y sean más
detallados, más difícil será mantenerlos y que sus empleados los utili-
cen. Por otra parte, un menor número de documentos y que sean muy
breves, también pueden describir exactamente lo que necesita hacer.
Como regla general, recomiendo a mis clientes no llegar a ser dema-

siado ambicioso - si no hay absoluta necesidad de crear un nuevo do-
cumento, no lo haga; Si no hay necesidad de describir algún proceso
con gran detalle, hágalo más corto. Por supuesto, si algunos riesgos
70
importantes requieren documentos detallados, probablemente tendrá
que entrar en detalles, pero esto no significa que el resto de documen-
tos deban ser también detallados.
Documentos obligatorios. Por supuesto, deberá escribir todos los do-

cumentos obligatorios, cada cláusula del estándar especifica si el requisito
de esa cláusula debe estar documentado o no. Por tanto, lo primero que
creo que necesita hacer es comprobar si un documento es requerido por
el estándar ISO 27001. Si el documento es obligatorio, no hay nada que
pensar – debe escribirlo si quiere cumplir con este estándar. ISO 27001
establece muy claramente lo que debe ser documentado simplemente
diciendo “la organización deberá mantener información documentada
de...” por ejemplo los resultados de la evaluación del riesgo.
En el Apéndice A de este libro usted encontrará una lista de todos los

documentos obligatorios requeridos por ISO 27001, y a lo largo de este
libro explicaré todos y cada uno de estos documentos.
Documentos no obligatorios. Sin embargo, aún cuando el están-

dar no requiere explícitamente tener algo documentado, podría ser útil
para su empresa tener algunas políticas y procedimientos adicionales
documentados. Por lo tanto, si el documento no es obligatorio, se pue-
de encontrar perplejo sobre si usted necesita escribir un documento ¿o
no? Aquí tiene varios criterios que le pueden ayudar a decidir:
● Riesgos – Compruebe los resultados de la evaluación del riesgo

para ver si existe necesidad de algún control. Si no hay ningún
riesgo, entonces ciertamente no necesita un documento para él.
● Tamaño de la empresa – Las empresas más pequeñas tienden a

tener menos documentos, por lo que en este caso se debe intentar
evitar escribir un procedimiento para cada pequeño proceso – por
ejemplo, si usted tiene 20 empleados no necesita 50 documentos
del SGSI. Por supuesto, si usted es una organización multinacional
con 10.000 empleados, podrá escribir políticas donde cada polí-
tica podría tener un par de procedimientos relacionados y luego
para cada procedimiento un par de instrucciones de trabajo - este
enfoque tiene sentido.
71
SEGURO & SIMPLE
● Importancia y complejidad – Mientras más importante y com-
plejo sea un proceso o actividad, más probable será que quiera
escribir una política o un procedimiento para describirlo - esto es
porque usted querrá asegurarse de que todo el mundo entiende
cómo realizar dicho proceso o actividad para evitar interrupciones
en sus operaciones.

Resumiendo, para evitar errores comunes y trampas en su proyecto,
por favor siga los consejos descritos en este capítulo y en los anteriores:
● Consiga un apoyo (real) de la dirección
● Decida cuál es la opción de implementación más adecuada para

su organización
● Trate toda la implementación como un proyecto, y no salte los

pasos
● Seleccione el responsable de proyecto más adecuado para esta

tarea
● Decida si necesita alguna herramienta para la implementación, y si

es así – seleccione la más apropiada para su organización
● Sea realista con su tiempo y presupuesto
● No sea demasiado ambicioso a la hora de escribir su documentación
OK, ahora que ya conoce cómo preparar el proyecto, vamos a empezar

a rodarlo
72
5
PRIMEROS PASOS EN EL PROYECTO
Probablemente haya tenido esta experiencia en su vida privada – si us-

ted empezó a hacer algo sin tener una visión clara de por qué hacerlo,
y no puso las cosas bien desde el principio, probablemente lo paso mal
teniendo que corregirlo todo más tarde.
Ocurre algo similar con ISO 27001 – a menos que establezca expectati-
vas claras para la seguridad de la información desde el principio, conse-
guirá algo totalmente inadecuado. Además, si no establece unas reglas
claras para el sistema entero desde el principio, lo más probable es que
tenga un desastre incluso antes de que un hacker le pueda golpear.
Por lo tanto, vamos a ver cómo puede establecer unos objetivos para
la seguridad de la información, para saber hacia donde va, y también
veremos cómo establecer un marco de trabajo básico para que todo el
mundo también sepa hacia donde va.
Nota: en cada subtítulo escribiré la cláusula relacionada de la ISO 27001.
Usted notará que salto algunas cláusulas del estándar, puesto que no
tienen importancia o están cubiertas junto con otras cláusulas.
5.1 Comprender el contexto de su organización

(cláusula 4.1)
Propósito. Aunque la cláusula 4.1 del estándar ISO 27001 genera mucha
confusión, en realidad me gusta – obliga a profesionales de seguridad de
la información que miren más allá de cuestiones meramente de seguridad
de la información, por lo que en realidad esta cláusula facilita una unión
más cercana entre el negocio y la seguridad de la información. El punto
principal de esta cláusula es encontrar cuestiones específicas para su em-
presa, por lo que podrá construir un SGSI que cubra sus circunstancias es-
pecíficas. En otras palabras, no es posible construir exactamente el mismo
SGSI en todas las empresas.
73
SEGURO & SIMPLE
Entradas. ISO 27001 dice muy brevemente que es necesario identifi-
car todas las cuestiones internas y externas que podrían influir en su
sistema de gestión de seguridad de información (SGSI). También hace
referencia a la cláusula 5.3 del estándar ISO 31000 para una explica-
ción más detallada. ISO 31000 es un estándar que proporciona una
guía de buenas prácticas para la gestión de riesgos, y esto es lo que
sugiere que podría ser incluido a la hora de identificar las cuestiones
internas y externas (por cierto, los mismos elementos aparecen en la
ISO 27004:2009):
● En resumen, para el contexto interno podría considerar la estruc-

tura organizacional, las funciones y responsabilidades, la estrategia
de negocio y los objetivos, las capacidades y recursos, la cultura
organizacional, los sistemas de información y procesos, relaciones
contractuales, etc.
● Para el contexto externo, lo más importante son las partes intere-

sadas y sus requerimientos; pero también se puede considerar el
entorno político, económico, cultural, tecnológico y competitivo,
así como las tendencias que podrían tener un impacto en su em-
presa.
Tenga en cuenta que ISO 31000 proporciona sólo una guía de buenas
prácticas; por lo tanto, no es obligatoria.
Decisiones. Para las cuestiones internas, esto es lo que debe hacer:
● Asegúrese de que sus objetivos de seguridad de la información están

alineados con la estrategia del negocio (ISO 27001 cláusula 5.1 a).
● Realice la evaluación del riesgo, incluyendo la identificación de siste-

mas de información y relaciones contractuales (cláusulas 6.1.2 y 8.2).
● Determine los recursos (cláusula 7.1).
● Determine los roles de seguridad de la información y sus respon-

sabilidades (cláusula 5.3).
● Determine las capacidades (cláusula 7.2).
74
Primeros pasos en el proyecto
Por lo tanto, el punto es, no necesita crear pasos adicionales para la
identificación de cuestiones internas sobre lo que ya tiene que hacer
debido a las cláusulas mencionadas arriba del estándar ISO 27001 –
esto significa que mediante la implementación de estas cláusulas iden-
tificará todas las cuestiones internas.
Para las cuestiones externas, lo primero es cumplir con la cláusula 4.2

de la ISO 27001 (entendiendo las necesidades y expectativas de las par-
tes interesadas) - esto se explica en la siguiente sección.
Opciones. Si quiere crear un paso adicional en la identificación del

contexto interno, podría realizar el análisis de acuerdo al marco de tra-
bajo denominado 7S - este incluye la evaluación de: la estrategia, la
estructura, los sistemas, los valores compartidos, los conocimientos, el
estilo y el personal.
Para pasos adicionales a la hora de identificar el contexto externo, po-

dría realizar el llamado Análisis PEST, que identifica temas políticos, eco-
nómicos, sociales y tecnológicos en el entorno de su empresa.
Documentación. Para las cuestiones internas, debe documentar sus

objetivos de seguridad de la información y los resultados de la evalua-
ción del riesgo, y mantener los registros de competencia de sus em-
pleados. Debido al control A.18.1.1, es obligatorio tener una lista de
requisitos legales, estatutarias, reglamentarias y contractuales relevan-
tes; Esta lista le puede ayudar con las regulaciones y leyes de seguridad
de la información.
No es obligatorio documentar su Análisis PEST o 7S, pero las grandes

empresas normalmente crean estos documentos a la hora de revisar
sus estrategias de negocio; las empresas más pequeñas normalmente
no los tienen, pero estoy seguro de que la mayoría de los propietarios/
directores de negocio consideran todas estas cuestiones a la hora de
ingeniárselas para competir en el mercado. Por lo tanto, si trabaja para
una empresa grande, simplemente pida a su oficina corporativa estos
documentos; en compañías más pequeñas, asegúrese de que hable
con su director.
75
SEGURO & SIMPLE
Consejo de documentación: (obligatorio) Objetivos de seguridad de

información, resultados de la evaluación del riesgo (generalmente bajo
la forma de un informe de evaluación de riesgos), los registros de com-
petencia del empleado (generalmente en forma de certificados) y lista
de disposiciones legales, estatutarias, reglamentarias y contractuales.
(no obligatorio) Análisis PEST y marco de trabajo 7S.
5.2 Listado de partes interesadas y sus requerimientos

(cláusula 4.2)
Propósito. La idea de esta cláusula es, una vez que sepa qué es lo que
hace su empresa, saber lo que se espera – dado que su SGSI debe sa-
tisfacer a todas las partes interesadas pertinentes.
Documentación. Si lo desea, puede escribir un procedimiento que de-

fina quién es el encargado de identificar todas las partes interesadas y
sus requisitos legales, reglamentarios, y sus intereses.
Entonces tiene que actuar de acuerdo a este procedimiento: el primer

paso es enumerar todas las partes interesadas – estas son todas las
organizaciones e individuos que podrían influir directamente en su se-
guridad de la información, o si está en peligro su seguridad de la infor-
mación, también podría influirles a estas partes interesadas.
Por ejemplo, las partes interesadas normalmente incluyen:
● trabajadores
● accionistas/propietarios del negocio
● agencias/reguladores gubernamentales
● clientes
● medios
76
● socios y proveedores
● etc.
El segundo paso es identificar lo que cada uno de ellos requiere de us-

ted, por ejemplo, los accionistas quieren seguridad en la inversión y un
buen retorno, los clientes desean que cumpla con los contratos que ha
firmado con ellos, las agencias de gobierno desean que cumpla con las
leyes y los reglamentos, los medios de comunicación quieren noticias
rápidas y precisas, etc. Sin embargo, tiene que ser más específico que
esto - tiene que especificar exactamente las leyes y reglamentos, las
cláusulas en los contratos, y así sucesivamente.
Entradas. Puede encontrar toda esta información leyendo documenta-

ción ya existente, y también hablando con los directores de los diferen-
tes departamentos de su compañía – legal, producción, desarrollo, TI,
marketing, finanzas, logística, recursos humanos, etc.
Opciones. Puede encontrar toda esta información leyendo documen-

tación existente, pero también hablando con los jefes de los diferentes
departamentos de su empresa - legal, producción, desarrollo, TI, mar-
keting, finanzas, logística, recursos humanos, etc.
Decisiones. Debe enviar esta lista de partes interesadas y sus necesida-

des a todos los jefes de Departamento para su aprobación; Si usted tiene
algo así como un oficial de cumplimiento corporativo, inclúyalo también.
Vea también este mini caso de estudio en el capítulo 14: Listar las par-
tes interesadas y sus requerimientos en un banco Europeo.
Consejo de documentación: (no obligatorio) Un procedimiento do-

cumentado generalmente denominado Procedimiento para la iden-
tificación de requisitos o procedimiento de Cumplimiento.
(obligatorio) Un documento que enumera todas las partes interesa-

das así como sus requisitos. Esto generalmente se denomina Lista
de requisitos regulatorios, contractuales y otros requisitos, o simple-
mente Lista de Cumplimiento.
77
SEGURO & SIMPLE
5.3 Definición del alcance del SGSI (cláusula 4.3)

Propósito. El principal propósito de establecer el alcance del SGSI es
definir qué información va a proteger. Por lo tanto, no importa si esta
información se almacena dentro de las oficinas de su empresa, o en al-
gún lugar en la nube; no importa si esta información es accesible desde
su red local o a través de acceso remoto. El punto es que usted será
responsable de proteger esta información sin importar dónde, cómo y
quienes tendrán acceso a esta información.
Así, por ejemplo, si sus empleados tienen computadoras portátiles que
se llevan fuera de su oficina, esto no significa que estos portátiles estén
fuera de su alcance - deben ser incluidos en su alcance si a través de
estos portátiles los empleados pueden acceder a su red local y a toda la
información sensible y servicios que pueda tener.
Por supuesto, el alcance también es importante si usted va a por la
certificación - el auditor de certificación comprobará que todos los ele-
mentos del SGSI funcionan bien dentro de su alcance; él no comproba-
rá los departamentos o sistemas que no están incluidos en su alcance.
Opciones. A la hora de decidir que cubrirá su alcance, tiene que tener
en cuenta estas cosas:
● Los requerimientos de partes interesadas – Si la ley le requiere
implementar la seguridad de la información en toda su compañía,
entonces tiene resuelto el dilema.
● Tamaño de su empresa – Si su empresa tiene 50 empleados en un
solo lugar, entonces su alcance debería ser su compañía entera; sin
embargo, si usted tiene una gran empresa internacional con oficinas
en 100 países, entonces sería mejor establecer primero el alcance
sólo en un país o una unidad de negocio, y luego aumentar gradual-
mente el alcance a medida que la curva de aprendizaje aumenta.
● Presupuesto – Si el dinero que tiene es realmente pequeño, usted
debe ir hacia un alcance más pequeño. (O incluso mejor – salir de
ese proyecto porque lo más probable es que su dirección no entien-
da nada).
78
● Fecha de finalización deseada – Si tiene un plazo de tiempo cor-
to (por ejemplo, tiene que conseguir el certificado para la próxima
licitación), usted debería apuntar a un alcance más pequeño.
Si me pide un alcance de SGSI que no cubra toda la empresa (o al me-
nos sus procesos principales) no tendrá mucho sentido - digamos que
ha implementado la ISO 27001 sólo en su departamento de TI, pero no
en el núcleo de la planta de fabricación. Esto significa que por ejemplo
los datos cruciales sobre su diseño del producto no están protegidos
ya que se almacenan en computadoras locales en el Departamento de
fabricación, lo que significa que realmente no se centrará en su infor-
mación más importante.
Si, por alguna razón, se ven obligados a ir a un alcance más peque-
ño, su plan a largo plazo debe apuntar hacia un alcance completo en
la empresa. Como se señaló anteriormente, un alcance más pequeño
puede ser muy bueno para aprender – una vez que está seguro de que
lo hizo todo bien en una unidad organizativa, lo puede ampliar todo.
Decisiones. La mejor manera de determinar un alcance es organizar una
reunión con su patrocinador y/o equipo de proyecto – esto es realmente
una decisión estratégica, y no lo puede hacer solamente el director.
Sólo mencionar aquí que si elige que el alcance del SGSI sólo incluya
una parte de su organización, entonces la “alta dirección” no va a ser
su ejecutivo, pero sí el responsable superior en el departamento, o uni-
dad de negocio que corresponda. Por lo tanto, cuando utilizo la frase
de la alta dirección en este libro, me refiero a los responsables con una
posición más alta dentro del alcance del SGSI.
Entradas. ISO 27001 dice que tiene que hacer lo siguiente a la hora de
definir el alcance:
● Tener en cuenta las cuestiones internas y externas definidas en la
cláusula 4.1
● Tener en cuenta todos los requerimientos definidos en la cláusula 4.2
● Considerar las interfaces y dependencias entre lo que está suce-
diendo dentro del alcance del SGSI y el mundo exterior.
79
SEGURO & SIMPLE
Probablemente sea más fácil describir las dependencias gráficamente,
aunque tenga en cuenta que estas dependencias no tienen que estar
documentadas. Puede dibujar en un círculo los procesos que se inclu-
yen en el alcance del SGSI y luego fuera de este círculo dibujar los pro-
cesos que están fuera de su alcance. Por procesos, no me refiero solo a
procesos de seguridad o TI – me refiero a los procesos de negocio den-
tro de su alcance; Si ya ha implementado la ISO 9001, probablemente
tenga un gráfico de procesos similares. Aquí tiene un ejemplo:
Compañía A
Proceso central #1
Proceso central #2
Alcance
del SGSI Proceso central #3
Proceso de
Proceso de
Proceso de
apoyo #1
apoyo #2
apoyo #3
Desarrollo
y manten- Servicios
imiento de contables
software Servicios Servicios de
legales limpieza
Figura 4: Gráfico de los procesos del SGSI indicados en el alcance del SGSI
Una vez que conoce las dependencias, usted debe identificar las inter-
faces. Es importante para una empresa comprender los límites del SGSI
y conocer qué entradas y salidas tendrán estas interfaces, para de esta
manera protegerlas mejor.
80
Un par de enfoques para determinar interfaces:
● Usted puede tratar de identificar todos los puntos finales que con-
trola – por ejemplo, en su red local podría ser el router (porque
después de ese punto generalmente no tiene control del enlace
– lo tiene la empresa de telecomunicaciones), para sus oficinas la
interfaz podría ser la puerta de entrada, etc.
● Probablemente un mejor enfoque podría ser definir las característi-

cas de alto nivel de las interfaces a través de estos tres factores: (1)
personas, (2) procesos y (3) tecnología. Así, en el ejemplo mostrado
en el diagrama anterior, las personas en la empresa A serían todos
los usuarios del software, mientras que la compañía que propor-
ciona el desarrollo y mantenimiento del software, sería el principal
desarrollador de software; los procesos serían el soporte (resolver
los problemas de los errores de software) y el desarrollo de nuevas
funcionalidades del software; la tecnología sería la herramienta de
escritorio de soporte, el correo electrónico, una VPN, FTP, etc.
Documentación. El documento del alcance debe incluir también las

ubicaciones físicas que forman parte del alcance (podría utilizar planos
para describir el perímetro), unidades organizativas (por ejemplo puede
usar organigramas funcionales), pero también los productos y servicios
que está proporcionando, las actividades y procesos, y los requisitos
que son relevantes para definir el alcance. Todo este contenido no es
estrictamente exigido por el estándar, pero a los auditores de certifica-
ción le gustará ver esta información.
Vea también este mini caso de estudio en el capítulo 14: Definir un

alcance de SGSI para un pequeño proveedor de servicios en la nube.
Consejo de documentación: (obligatorio) Un documento que des-

cribe el alcance de su SGSI – como un documento separado (gene-
ralmente llamado Alcance del SGSI) o como parte de la Política de
seguridad de la información.
81
SEGURO & SIMPLE
5.4 Qué se le requiere a la alta dirección (cláusula 5.1)

Propósito. Como se mencionó anteriormente, el liderazgo y el com-
promiso de dirección son muy importantes ya que son cruciales para el
éxito del SGSI en una empresa. Sin el liderazgo y el compromiso de la
dirección, el proyecto de implementación del SGSI fallará.
Decisiones. De acuerdo a la ISO 27001, las responsabilidades de la alta

dirección son las siguientes:
● Publicar la política de alto nivel – la alta dirección debe publi-

car la política de seguridad de la información, en la que se define
la intención principal de la seguridad de la información.
● Determinar los objetivos – a través de los objetivos, la alta dirección

define en qué dirección tiene que ser dirigido el SGSI, y los objetivos
también proporcionan una medida clara de si el SGSI es un éxito.
● Determinar las principales responsabilidades – la alta direc-

ción debe definir quién está a cargo de diversos elementos rela-
cionados con la implantación y operación del SGSI – en la mayoría
de los casos, nombrará al Director General de la seguridad de la
información, pero la alta dirección también debe asignar otras res-
ponsabilidades; la alta dirección debe apoyar todos los responsa-
bles, y en última instancia, asegurar de que han hecho su trabajo.
● Comunicar la importancia – dado que los ejecutivos son los que

tienen la mayor influencia en una organización, si no explican a todos
los empleados por qué el SGSI es importante, entonces nadie podrá
creer que tiene que hacer cosas al respecto, especialmente si los altos
directivos no “dan ejemplo” es decir, si no cumplen con las reglas de
seguridad ellos mismos.
● Proporcionar todos los recursos necesarios – sin dinero y sin

tiempo suficiente por parte de los empleados, el proyecto de ISO
27001 fracasará – aquí es donde el apoyo de la alta dirección debe
ser muy real y tangible. Desde mi experiencia, este es exactamente
el punto donde generalmente falla la dirección – suelen re-direc-
cionar los recursos a otros proyectos.
82
● Realizar la revisión por dirección – Aquí es donde la alta dirección
debe revisar todo lo que ha sucedido dentro del SGSI, siendo una
de las tareas principales concluir si se han alcanzado los objetivos.
Entradas. Para determinar los objetivos (ver sección 5.6), sus ejecutivos
necesitan saber cuáles son los beneficios de la implementación de la
ISO 27001 (ver sección 3.1) - los objetivos suelen reflejar esos benefi-
cios. Una vez que tiene claros objetivos de seguridad de la información,
serán una medida clave para todo lo demás – midiendo si esos objeti-
vos se logran, usted sabrá qué tan bien está funcionando su SGSI.
Opciones. Aunque los requisitos son bastante claros, su alta dirección,

todavía tiene la opción de elegir cuánto desean involucrarse en la ges-
tión de la seguridad – por ejemplo, pueden realizar la revisión por direc-
ción una vez al año (es decir, el mínimo permitido por los auditores de
certificación), o pueden tener esas reuniones mensualmente.
Documentación. No existe un documento único que cubra esta cláu-

sula del estándar – dependiendo de las actividades que realiza la alta
dirección, se tendrán que producir diferentes documentos.
Consejo de documentación: (obligatorio) Un documento de ni-
vel superior generalmente denominado Política de Seguridad de la
Información, objetivos de seguridad de la información (como una
parte de la Política de Seguridad de la Información, o como un do-
cumento separado), resultados de la revisión por dirección (general-
mente en forma de minutas de la Revisión por dirección).
5.5 Escribir la política de seguridad de la información

(cláusula 5.2)
Propósito. ¿Por qué necesita una política además de la política de
control de acceso, de la política de clasificación y la política de uso
aceptable? Esta es la razón: dado que en muchos casos los ejecutivos
no tienen idea de cómo la seguridad de la información puede ayudar
83
SEGURO & SIMPLE
a su organización, el propósito principal de la política es que la alta
dirección defina lo que quiere lograr con la seguridad de la información.
El segundo propósito es crear un documento que los ejecutivos en-

cuentren fácil de entender, y con el que serán capaces de controlar
todo lo que está sucediendo dentro del SGSI - no necesitan saber los
detalles, digamos, de la evaluación de riesgo, pero ellos necesitan saber
quién es responsable del SGSI y qué puede esperar de él.
Básicamente, la política de seguridad de la información realmente debe

servir como vínculo principal entre la alta dirección y las actividades de
seguridad de información, sobre todo porque la ISO 27001 requiere la
dirección asegure que el SGSI y sus objetivos son compatibles con la
dirección estratégica de la empresa (cláusula 5.2). La política es proba-
blemente la mejor manera de hacerlo.
Una nota importante aquí: por lo general, una política de seguridad de

la información no es un documento donde se escriba toda la informa-
ción sobre reglas de seguridad – para las reglas detalladas, usted debe
utilizar otras políticas de seguridad detalladas, por ejemplo la política
de copias de seguridad.
Documentación. ISO 27001 no dice mucho acerca de la política, pero

dice lo siguiente:
● La política tiene que adaptarse a la organización - esto significa

que no puede simplemente copiar la política de una compañía de
fabricación grande y usarla en una pequeña empresa.
● Es necesario definir el marco de trabajo para el establecimiento de

objetivos de seguridad de la información – básicamente, la política
debe definir cómo se proponen los objetivos, cómo se aprueban y
cómo son revisados.
● La política debe demostrar el compromiso de la alta dirección para

cumplir con los requisitos de todas las partes interesadas y mejorar
continuamente el SGSI – esto se hace normalmente a través de
una declaración dentro de la política.
84
● La política deberá ser comunicada dentro de la empresa, pero tam-
bién – cuando corresponda - a las partes interesadas; la mejor
práctica es definir quién es responsable de tal comunicación, y en-
tonces esta persona será responsable de hacerlo continuamente.
La política debe ser revisada regularmente – debe definirse un dueño de
la política, y esta persona será responsable de mantener al día la política.
Así que, como puede ver, la política no tiene que ser un documento
muy extenso.
● Opciones. Aunque no es obligatorio, si eres una pequeña empresa
también puede incluir lo siguiente (para las grandes empresas, es-
tas cuestiones están generalmente en documentadas separados):
● El alcance del SGSI – de esta manera el alcance no tiene que
existir como un documento separado.
● Responsabilidades para las piezas clave del SGSI – por ejemplo,
quién es responsable de las operaciones diarias y la coordinación,
quién es responsable en el nivel ejecutivo, quién es responsable
de la evaluación de riesgos, de los incidentes, de las auditorías
internas, etc.
● Medición – quién medirá si se han logrado los objetivos de segu-
ridad de la información, a quién se tienen que reportar los resulta-
dos, con qué frecuencia, etc. (Vea también la sección 10.1.)
● En algunas empresas más grandes, he visto una combinación de la
Política de seguridad de información con la Política de gestión de
riesgos de empresa. Aunque esto no está mal, creo que es mejor
mantener estas políticas como documentos separados – el enfo-
que es mucho más claro.
Entradas. Hay un par de entradas que hay que tener en cuenta al es-
cribir la política:
● Las intenciones de la alta dirección con la seguridad de la informa-
ción – lo mejor sería concertar una entrevista con su director y pa-
sar por todos los elementos de la política; usted podría enviar un
85
SEGURO & SIMPLE
correo electrónico con un par de días de antelación a la reunión,
así el director puede tener tiempo para pensar sobre ello.
● Legislación y requisitos contractuales - la política debe reflejarlos.
● El sistema existente para el establecimiento de objetivos – si ya

existe un sistema, debe referenciarlo.
Decisiones. La alta dirección debe aprobar la política, aunque sería útil

enviarla primero a otras personas clave de la organización para su revisión.
 Consejo de documentación: (obligatorio) Un documento denomi-
nado Política de seguridad de la información.
5.6 Definir los objetivos del SGSI de alto nivel

(cláusulas 5.2 b y 6.2)
Propósito. Peter Drucker (uno de los pensadores más influyentes en
cuestiones de gestión) dijo, “lo que puedes medir, lo puedes gestionar”.
Lo mismo aplica a la seguridad de la información – si no sabe lo bien que
lo está haciendo, será muy difícil para usted manejar la seguridad de la
información en la dirección deseada. Y es exactamente esta dirección
deseada la que es una parte esencial en la medición: lo que significa que
necesita establecer objetivos. Solamente si sabe exactamente lo que quie-
re lograr, podrá saber cuánto o cuán cerca está realmente para lograrlo.
Igualmente importante – usted será capaz de responder la pregunta de
dirección: ¿la inversión en seguridad de la información tiene sentido?
Opciones & Documentación. Existen al menos dos niveles para los

cuales es necesario establecer objetivos:
1) Objetivos de seguridad estratégicos – para todo su Sistema de

Gestión de Seguridad de la Información, y
2) Objetivos de seguridad tácticos – Para controles específicos o

grupos de controles, procesos de seguridad, departamentos, etc.
86
En esta sección me centraré sólo en los objetivos estratégicos (para
todo su SGSI), para los objetivos tácticos, por favor vea la sección 8.1.
Usted puede decidir si describirá los objetivos de seguridad de la informa-

ción estratégicos y su sistema de medición en la política de seguridad de la
información, o en un documento separado. Las empresas más pequeñas
normalmente los tienen escritos en la política, mientras que las grandes
empresas tienden a tener un documento separado para todos los objeti-
vos del negocio (tal vez un cuadro de mando integral) y un procedimiento
separado que describe cómo administrar todos los objetivos y las medidas
en este cuadro de mando integral.
Para definir buenos objetivos, el secreto radica en fijar objetivos que sean
fáciles de medir, quizás haya escuchado el concepto S.M.A.R.T.: los obje-
tivos deben ser específicos (Specific), medibles (Measurable), alcanzables
(Achievable), relevantes (Relevant) y basados en el tiempo (Time-based).
Así, objetivos como “Queremos implementar la seguridad de la infor-
mación” o “Queremos que nuestra información esté segura” no ayu-
dan realmente, es decir, ¿cómo sabe si logra estos objetivos?
Por otra parte, objetivos similares a estos pueden servirle:
● “Cumplir con la ley/reglamento xyz de 31 de Diciembre de 2017,
usando el marco de trabajo ISO 27001”
● “Conseguir al menos 5 nuevos clientes en los próximos 12 meses
como consecuencia de la certificación ISO 27001.”
● “En 2018 reducir el número de incidentes de seguridad en un 30%”
¿Son medibles? Sí - lo que tiene que hacer es medir si ha logrado lo que
usted planeó dentro del período de tiempo establecido. Por ejemplo,
para el objetivo de los incidentes visto previamente, puede medirse a
través del número de entradas en el registro de incidentes.
En la sección 10.1 explicaré cómo medir si se han conseguido los objetivos.
Entradas. Admito que determinar objetivos estratégicos para su SGSI
no es una tarea fácil. Pero, para facilitar este trabajo, usted debe comen-
87
SEGURO & SIMPLE
zar con su estrategia de empresa – ¿qué trata de alcanzar su empresa?
¿Cómo quiere conseguirlo?, ¿con qué competencias? ¿Cómo puede
ayudar la seguridad de la información a ejecutar esta estrategia? Una vez
que encuentre esta relación, será más fácil llegar a los objetivos del SGSI.
Además, tiene que pensar sobre los beneficios de la seguridad de la infor-

mación que identificó previamente – ¿cómo pueden traducirse en objetivos?
Decisiones. Dado que pensar sobre todo esto no es posible para una
única persona, debe incluir a todo su equipo de proyecto en este inter-
cambio de ideas; también, si alguien en su empresa ya está tratando
con la medición del desempeño – por ejemplo, el departamento de
control, le podrían ayudar mucho. Su alta dirección debería dar el visto
bueno definitivo a los objetivos - puede probar a discutirlos con su pa-
trocinador antes de presentarlos a su director.
 Consejo de documentación: (obligatorio) Los objetivos del SGSI
pueden figurar tanto en la Política de seguridad de la información
como en un documento separado, por ejemplo, Listado de objeti-
vos de seguridad de la información.
(no obligatorio) Un procedimiento que describa cómo manejar todos

estos objetivos y cómo medirlos – Por ejemplo, Procedimiento de
medición, o Metodología de medición.
5.7 Roles y responsabilidades, y cómo documentarlas

(cláusula 5.3)
Propósito. Asignar y comunicar roles y responsabilidades es importan-
te, dado que es la forma en la que todos los empleados de la empresa
sabrán lo que se espera de ellos, cuál es su impacto en la seguridad de
la información y cómo pueden contribuir.
Decisiones. Más concretamente la alta dirección debe asignar respon-

sabilidades de nivel superior y autoridades por 2 aspectos principales:
88
● Primero por que se necesitan responsabilidades para asegurar que
el SGSI cumple con los requisitos de la ISO 27001
● Y segundo porque se necesitan responsabilidades para monitori-
zar el funcionamiento del SGSI y su reporte a la alta dirección.
En el nivel inferior de la organización, las responsabilidades y roles de
seguridad serán asignados como tareas regulares – por ejemplo, iniciar
la copia de seguridad en un momento determinado del día. Estas tareas
se deben asignar a las personas que probablemente ya las están hacien-
do, sólo que ahora estos roles y responsabilidades serán más formales.
El seguimiento y el reporte deben hacerse también a través de canales
regulares – típicamente, el superior directo de los empleados está a
cargo de monitorizarlos, y reportar sobre sus resultados.
Opciones. Las autoridades y responsabilidades de nivel superior pueden
ser asignadas a una o más personas en la empresa, dependiendo de lo
que sea más apropiado. Por ejemplo para las pequeñas empresas con un
SGSI simple, lo lógico es asignar una persona responsable de implemen-
tar todos los requisitos de la ISO 27001 e informar sobre el rendimiento
del SGSI a la alta dirección. Éste es generalmente el CISO (responsable de
seguridad de la información).
En grandes empresas con SGSIs más complejos podría ser más factible
tener una persona responsable de implementar los requisitos y otra de
reportar. Otra opción sería tener una persona para asegurar la imple-
mentación de los requisitos, y esta misma persona puede reportar a un
segmento del SGSI, por ejemplo a Seguridad de los Recursos Humanos,
y a otra persona puede reportar a gestión de incidencias, etc.
Documentación. El estándar no requiere explícitamente que se docu-
menten los roles y responsabilidades, sin embargo las buenas prácticas
muestran que es más práctico comunicar las responsabilidades si las tie-
ne documentadas. Para ello, puede documentar los roles y responsabi-
lidades generales de seguridad de la información en la descripción de
puestos de la organización, o como parte del organigrama funcional. Por
supuesto debe documentar los roles y responsabilidades de seguridad es-
pecíficos de varias políticas, procedimientos, planes y otros documentos
que se desarrollan como parte de la implementación de la ISO 27001.
89
SEGURO & SIMPLE
En otras palabras, es necesario tener un documento que defina de ma-
nera centralizada y detallada todos los roles y responsabilidades de se-
guridad. Este documento no sería práctico si su información estuviese
repetida – en el momento que cambie algún rol o responsabilidad en un
procedimiento particular, tendrá que cambiar también este documento
central. Tarde o temprano, detectará alguna discrepancia, y créame - esta
situación es un gran problema cuando se trata con documentación.
En el Appendix L encontrará una lista de las responsabilidades que nor-

malmente ejerce un CISO (Responsable de seguridad) en un SGSI.

En resumen, si quiere que su proyecto empiece con buen pie, tiene
que tener cuidado de lo siguiente:
● Estar seguro de que comprende las cuestiones internas y externas

relacionadas con su organización
● Listar todas las partes interesadas y sus requerimientos relaciona-

dos con la seguridad de la información
● Definir el alcance del SGSI, si es posible para toda la compañía
● Presentar a la alta dirección exactamente qué es lo que se requiere de

ellos
● Escribir una Política de seguridad de la información que se adapta

a tu empresa
● Definir objetivos de seguridad de la información significativos que

le ayuden a medir el éxito (o fracaso) de su SGSI
● Asegúrese que define responsabilidades
Ahora que ha iniciado la construcción de su SGSI, vamos a ver lo que

necesita para sostenerlo.
90
6
CUESTIONES NO RELACIONADAS
CON LA SEGURIDAD, NECESARIAS
PARA GESTIONAR LA SEGURIDAD
Como se mencionó antes, el SGSI que no tenga una parte de gestión,

simplemente no funcionará. Una parte importante de los elementos de
la gestión se describen en la cláusula 7 del estándar ISO 27001 – en
este capítulo le explicaré los detalles.
6.1 Gestionar documentos y registros (cláusula 7.5)

Propósito. Puede parecer un poco extraño establecer reglas para el
control de documentos en una etapa tan temprana del proyecto; sin
embargo, recomiendo escribir este procedimiento tan pronto como sea
posible en su proyecto porque si no tiene reglas claras sobre el formato
de los documentos, quién puede aprobarlos, dónde se publican, quién
deben revisarlos, etc., muy pronto su documentación será un caos. Y la
documentación, si no es el corazón de su sistema de gestión, segura-
mente sea su torrente sanguíneo.
Sólo destacar aquí, que ISO 27001 habla sobre “información documen-
tada”, que significa tanto documentos (por ejemplo, planes, políticas,
procedimientos, etc.) como registros (por ejemplo, registros, informes,
registros de formación, reunión, minutas, etc.).
Documentación. Si ya ha implementado ISO 9001, ISO 22301 o cual-

quier otro sistema de gestión ISO, usted puede usar el mismo procedi-
miento desarrollado para el SGC o SGCN, y con cambios muy peque-
ños, usarlo también para el SGSI.
En cualquier caso, este procedimiento debe definir claramente las respon-

sabilidades y las reglas para el manejo de los documentos: formato reque-
91
SEGURO & SIMPLE
rido, medios utilizados para su elaboración, quién puede aprobarlos, cómo
están distribuidos y archivados, cómo se mantienen hasta la fecha, qué sis-
tema de control de versiones está en uso, cómo seguir los cambios en los
documentos, cómo controlar la recepción de documentos externos, etc.
Mientras escriba este procedimiento, debe tener en cuenta que los do-
cumentos pueden encontrarse en varias formas – documentos en pa-
pel, archivos de texto u hojas de cálculo, archivos de vídeo o audio, etc.
Una organización no sólo debe gestionar documentos internos (por
ejemplo, diferentes políticas, procedimientos, documentación del pro-
yecto etc.), también debe gestionar documentos externos (por ejem-
plo, diferentes tipos de correspondencia, documentación recibida con
los equipos de los usuarios, etc..). En otras palabras, asegúrese de que
el procedimiento tiene en cuenta todos estos documentos.
Entradas. En primer lugar, tiene que averiguar si ya existe un proce-
dimiento que defina la gestión de documentación o registros en su
empresa – si no tiene ningún estándar de gestión ISO, tal vez tenga
algunas reglas corporativas sobre la gestión de documentos o registros.
Además, tiene que tener en cuenta lo siguiente:
● S olución técnica existente para el manejo de documentación (por
ejemplo, un sistema de gestión documental, un software de gestión
de proyectos, un software de gestión de relaciones con clientes, etc.)
● P lantillas existentes que esté utilizando para la documentación interna
● Idiomas que son usados comúnmente en su empresa
Decisiones. Si no tiene ninguna regla para estas cuestiones, debe pro-
poner una estructura para este procedimiento y luego decidir las op-
ciones con su equipo de proyecto o con los jefes de un par de departa-
mentos que considere que podrían estar más interesados en este tema
(o simplemente puede enviarles una versión borrador). Si ya tiene reglas
similares, entonces tiene que proponer cambios para que sea compati-
ble con ISO 27001, y enviar el documento para su revisión y aprobación
según el proceso definido.
Opciones. Existen un par de opciones que usted debe decidir:
92
Cuestiones no relacionadas con la seguridad, necesarias para gestionar la seguridad
● F ormato electrónico o formato papel para sus políticas, pro-
cedimientos y planes – aunque el formato electrónico es el más
común, algunas agencias gubernamentales todavía prefieren el
formato en papel.
●A
ctualización de documentos – es una buena práctica nom-
brar al propietario de cada documento como el responsable de
las actualizaciones y revisiones regulares. Esta persona podría ser
alguien que lo escribió (por ejemplo, un administrador de TI po-
dría ser el dueño del procedimiento de copias de seguridad), o
alternativamente, una persona podría ser responsable de todos los
documentos del SGSI (por ejemplo, el CISO); sin embargo, si una
persona es responsable de todos los documentos, nunca sabrá to-
dos los cambios en cada departamento, por lo que tal solución
muchas veces es mala.
● ¿ Debería este procedimiento cubrir sólo la documentación del

SGSI o toda la documentación de la empresa? Aunque no es
necesario, sería mejor aplicar estas reglas claras a toda la docu-
mentación de la organización, independientemente si están rela-
cionados o no con el SGSI.
●D
ebería usar un sistema de gestión documental para manejar
documentos – Esto depende básicamente del tamaño de su em-
presa – para compañías más pequeñas, una o varias carpetas en la
intranet será totalmente suficiente, mientras que compañías más
grandes probablemente necesitarán un SharePoint o una tecnología
similar para este propósito.
 Consejo de documentación: (no obligatorio) Aunque no es obliga-

torio, es altamente recomendable escribir un procedimiento para el
control documental – sólo las empresas muy pequeñas encuentran
este procedimiento como algo innecesario. Este documento gene-
ralmente se conoce como Procedimiento de Control Documental o
Procedimiento de Gestión Documental, o si también incluye la ges-
tión de registros, puede encontrarlo como Procedimiento de Control
de Registros y Documentos.
93
SEGURO & SIMPLE
6.2 Proporcionar recursos para el SGSI (cláusula 7.1)

Propósito. Con respecto a los recursos, ISO 27001 requiere a las em-
presas identificar los recursos necesarios para el SGSI y que estos estén
disponibles para la operación diaria, así como para la mejora continua
del SGSI. Garantizar la disponibilidad de los recursos no aplica sólo a
los recursos financieros; incluye también la asignación de personas para
determinadas actividades, dedicando tiempo para actividades de segu-
ridad de la información, etc.
Esta cláusula es importante porque sin los recursos adecuados no sería

posible el funcionamiento del SGSI. Esto es por lo que la provisión de
recursos para el SGSI se describe como un compromiso de la dirección
en el estándar, como ya he mencionado anteriormente. Por ejemplo, si
la dirección define uno de los objetivos de seguridad de la información
para el próximo año, y este es por ejemplo aumentar la sensibilización
con una formación de 2 horas por empleado, entonces la dirección
debe hacer lo siguiente: asignar esta responsabilidad a alguien (gene-
ralmente esta persona será el CISO), asegurar que todos los empleados
tienen más de 2 horas disponibles para la formación, y asegurar que
el CISO tiene tiempo suficiente para llevar a cabo la capacitación a to-
dos los empleados, o bien se destina una partida presupuestaria para
contratar a un Consultor/formador para llevar a cabo la formación, etc.
Opciones. Las principales opciones para proporcionar recursos son,

utilizar los recursos ya disponibles en la empresa, o subcontratar trabajo
específico a una parte externa. En principio, la opción de subcontratar
puede parecer suficientemente atractiva, pero debe calcular el coste
real y evaluar los riesgos de esta subcontratación a largo plazo.
Documentación. El estándar no requiere documentación para esta

cláusula, sin embargo, es común documentar los recursos necesarios
a través del presupuesto financiero, el plan de recursos humanos, el
plan de tratamiento del riesgo, el plan de capacidad (relacionado con
control A.12.1.3) si dicho plan está documentado, etc.
Entradas. Las principales entradas para la planificación de recursos

pueden estar en cualquier documento que utilice para describir algo
94
que quiera hacer en su SGSI. Por ejemplo, el plan de tratamiento de
riesgos tiene una lista con todos los controles que deben aplicarse, jun-
to con los recursos que se necesitarán.
Decisiones. La decisión principal sobre qué recursos deben aplicarse, se

hace generalmente a través de la alta dirección. Sin embargo, a la dirección
generalmente no le gusta los gastos nuevos y no tomará ninguna decisión
sin ver una buena razón para el negocio, por lo que tiene que preparar-
se – para explicar en detalle por qué es necesaria esta decisión. Y no creo
que su sugerencia sea aceptada sólo «porque lo requiere el estándar ISO
27001” – usted tiene que explicar por qué esto es bueno para la empresa.
 Consejo de documentación: (no obligatorio) Un documento para
su planificación financiera (generalmente conocido como Presupues-
to), un documento que describa el plan de formación para sus em-
pleados (generalmente conocido como Plan de recursos humanos),
un plan que describa todos los controles que serán implementados
(Plan de tratamiento de riesgos).
6.3 Proporcionar formación en seguridad

(cláusula 7.2)
Propósito. Puede tener unos controles para la documentación per-
fectos, pero si la gente no sabe cómo poner en práctica las reglas y las
medidas de seguridad, entonces su SGSI no tendrá sentido. Por esta
razón la ISO 27001 requiere que la empresa defina las competencias de
seguridad de la información para todos los empleados, y que se asegu-
re de que tienen la formación adecuada y experiencia.
Opciones. El estándar requiere realizar los siguientes pasos de manera

continua:
1. Definir qué competencias (conocimientos y habilidades) se requie-

ren para el personal que tenga un papel en su SGSI - básicamente,
revise cada documento del SGSI y vea lo que se requiere de cada
persona responsable mencionada en el documento.
95
SEGURO & SIMPLE
2. Realizar capacitaciones para alcanzar el nivel de conocimientos y ha-
bilidades deseado – por ejemplo, cursos, lectura de literatura, parti-
cipación en foros de expertos, cursos de capacitación internos, etc.
3. Medir si cada individuo ha alcanzado el nivel deseado de conoci-

mientos y habilidades, a través de pruebas, entrevistas, etc.
Es crucial que la formación se realice en paralelo a la implementación

de su SGSI - no puede esperar que sus colegas lleven algo a cabo si no
saben cómo hacerlo. Así que no publique nuevas reglas o compre nue-
vo software sin antes entrenar a su gente.
Entradas. Tiene que estudiar los documentos de su SGSI, y entrevistar

a sus colegas (los que tienen un papel en esos documentos) – de esta
manera, podrá concluir si cada persona tiene suficiente nivel de habili-
dades y conocimientos; Si su empresa ya tiene registros de formación,
será una buena fuente de información.
Decisiones. Si usted tiene un departamento de recursos humanos en

su organización, sin duda debe consultar con ellos sobre qué métodos
funcionarán y cuáles no; en muchos casos, el jefe del Departamento de
recursos humanos tendrá que aprobar los programas. También debe
consultar con otras funciones similares en empresas del sector (por
ejemplo, continuidad del negocio) sobre su experiencia, pero también
con otras funciones relacionadas, y por supuesto con su equipo de pro-
yecto. La aprobación final de los programas de capacitación podría rea-
lizarla el departamento de recursos humanos, o bien la alta dirección.
Documentación. Debe crear registros que definan exactamente qué

habilidades y conocimientos se requieren para cada individuo con un
rol en el SGSI, registros que muestren qué capacitaciones han realizado
y los resultados – si este individuo ha mejorado sus conocimientos y ha-
bilidades (por ejemplo, con certificados, recomendaciones, registro de
asistencia a cursos etc..) también los puede incluir. Usted puede hacer
esto en una sola tabla (con las personas en filas, y los diferentes tipos
de registros en columnas), o puede decidir crear registros separados
para cada individuo - tal vez esto es lo que ya tiene su Departamento
de recursos humanos.
96
Consejo de documentación: (obligatorio) Registros de personal
(para cada empleado individual), o un documento conocido como
Plan de formación – este documento puede ser fusionado con el do-
cumento de concienciación, por lo que puede llamar al documento
Plan de Formación y Concienciación.
6.4 Concienciar a tu gente en por qué es importante la

seguridad de la información (cláusula 7.3)
Propósito. No basta que sus empleados sepan cómo realizar ciertas
actividades; también es importante que entiendan por qué lo hacen.
Seamos honestos, a nadie le gusta la seguridad de la información, para
la mayoría de la gente sólo es una molestia. Así que a menos que sus
empleados entiendan el propósito de seguridad de la información, pro-
bablemente evitarán sus nuevas reglas de seguridad.
Por lo tanto, el estándar exige que todas las personas que trabajan para
la empresa sean conscientes de la Política de seguridad de la informa-
ción, de su rol, el impacto que tienen en el SGSI, y las consecuencias en
el caso de no cumplir con las reglas del SGSI.
Como ocurre con la formación, debe trabajar en la concienciación antes

de publicar las políticas y procedimientos – tiene que sensibilizar durante
el desarrollo de su proyecto SGSI. La idea básica es explicar a sus emplea-
dos por qué la seguridad de la información es buena para ellos y para su
empresa, y también debe explicar que regla es aplicable en cada situación.
Opciones. Existen varios métodos que puede utilizar para concienciar:
● Artículos en su intranet o boletines de noticias – casos simples

(con el mayor número de ejemplos posible) que ayude a los emplea-
dos a entender por qué la seguridad de la información es importante.
● Discusiones a través de foros internos – puede iniciar y parti-

cipar en cuestiones concretas (por ejemplo basándose en mitos),
relacionadas con la seguridad de la información.
97
SEGURO & SIMPLE
● Formación online – puede crear cursos de formación online pe-
queños, que expliquen la importancia de la seguridad de la infor-
mación, lo cual también ayudará a capacitar a sus empleados.
● Videos – son un método muy potente de presentación – puede

distribuirlos a través de email, intranet, etc.
● Ocasionales mensajes de email – puede utilizarlos no sólo para

distribuir videos, también los puede utilizar para el envío de noti-
cias y consejos sobre seguridad de la información.
● Reuniones – utilice reuniones periódicas que sean organizadas en

su organización – por ejemplo, fiestas, aniversarios, etc. Para presen-
tar brevemente lo que está haciendo y cómo afecta a sus colegas.
● Y, sobre todo – comunicación en persona diaria – donde quiera

que vaya, hable con quien hable – tiene que vender la idea de la
Y, como ya se destacó en la sección 3.4, cualquier método que use para

crear conciencia, debe centrarse siempre en presentar los beneficios.
Entradas. Para los programas de concienciación, las entradas principa-

les son los beneficios enumerados para todo el SGSI, pero también los
beneficios para departamentos particulares o personas; también debe
buscar algunos buenos casos de estudio en Internet, para empresas
que son similares a la suya, ya sea en tamaño, sector, ubicación, etc.
Decisiones. El proceso de decisión es muy similar a la formación - debe

consultar con su Departamento de recursos humanos sobre qué mé-
todos funcionarán y cuáles no, y solicitar su aprobación si fuese ne-
cesario. Además, usted debe también consultar con otras funciones
similares en una empresa del sector, y con funciones relacionadas (por
ejemplo, relaciones públicas) y por supuesto con su equipo de proyec-
to. La aprobación final debe realizarla la alta dirección.
Documentación. ISO 27001 no requiere documentación sobre activi-

dades de concienciación, sin embargo si desea tener un enfoque más
98
estructurado en concienciación de seguridad de la información en su
empresa, usted puede documentar un plan de concienciación. En este
plan usted puede definir qué tipo de actividades de concienciación se
llevará a cabo (presentaciones, boletines informativos, etc.) durante qué
periodo (un año por ejemplo), la periodicidad para las actividades (men-
sual, trimestral etc.) y los recursos (sala de conferencias y proyector, etc..).
Vea también este mini caso de estudio en el capítulo 14: Concientiza-

ción en una agencia del gobierno.
Consejo de documentación: (no obligatorio) Un documento deno-
minado Plan de concienciación.
6.5 Cómo comunicar y con quien (cláusula 7.4)

Propósito. Por desgracia, es demasiado frecuente que no se hagan co-
sas porque la información no llega a los destinatarios adecuados de una
manera correcta. Esto es por lo que el estándar obliga a las empresas a
definir sus necesidades con respecto a las comunicaciones internas y ex-
ternas relevantes para la seguridad de la información, y definiendo qué
y cuándo debe ser comunicado, por quién y a quién se comunicará, etc..
Entradas & opciones. Debe considerar lo siguiente:
● Qué debería ser comunicado – por ejemplo, nuevas vulnerabi-

lidades y amenazas, riesgos no resueltos, objetivos de seguridad
nuevos o modificados, detalles de eventos o incidentes, logros y
felicitaciones a comportamientos excepcionales en seguridad.
● Quién debería comunicar – por ejemplo, el CISO podría ser re-

sponsable de comunicar la Política de seguridad de la información
y los objetivos a todos los empleados; en caso de que se produzca
una brecha de seguridad de la información, la comunicación hacia
las partes externas, podría ser a través del Encargado de relaciones
públicas para una empresa más grande, o el director de la organi-
zación para empresas más pequeñas.
99
SEGURO & SIMPLE
● A quien comunicar – no sería práctico (ni inteligente) enviar to-
dos los mensajes a todo el mundo. Lo mejor sería tomar la lista de
las partes interesadas, añadir a esa lista grupos de sus empleados,
y luego sistemáticamente definir qué tipo de mensajes debe ser
comunicado y a quien. Básicamente, la comunicación a sus em-
pleados se considera interna, mientras que a todo el mundo se
considera externa.
● Cómo comunicar – la forma debe ser apropiada para el grupo ob-

jetivo y el tipo de mensaje. Se puede utilizar el correo electrónico,
cartas, teléfono, reuniones, anuncios en medios de comunicación,
etc.
● Cuándo comunicar – dependiendo del mensaje, puede ser más o

menos urgente, puede ser una sola vez, o continuo.
Decisiones. Usted debe decidir si necesita un documento central que

defina las reglas de comunicación (por ejemplo, un Plan de comunica-
ción) - aunque he visto un documento de este tipo en algunas empre-
sas, no lo recomiendo. En mi opinión, una forma más natural de definir
las reglas para la comunicación es a través de documentos que se en-
carguen de determinadas actividades, y que requieran comunicación
– por ejemplo, es mejor definir quién comunicará los incidentes en el
procedimiento de gestión de incidentes, o el acceso a nuevos sistemas
en la Política de control de accesos.
Documentación. Esta cláusula no requiere que las reglas de comuni-

cación estén documentadas. Dependiendo del tipo de empresa y sus
objetivos de seguridad, las reglas para la comunicación pueden ser más
o menos formales, completamente documentadas como un documen-
to separado, o simplemente establecidas como párrafos dentro de las
políticas apropiadas, procedimientos y planes.
100

En resumen, para soportar su sistema de gestión, debe hacer lo siguien-
te:
● Definir quién revisa y aprueba los documentos del SGSI, dónde son
publicados, y con qué frecuencia son revisados
● Control de la documentación interna y externa
● Explicar a la alta dirección qué recursos son necesarios, y por qué

son importantes
● Definir qué competencias necesita, y capacitar a los empleados

que no tienen las habilidades requeridas
● Asegurarse de que explica a todo el mundo por qué es importante

la seguridad de la información
● Definir quién necesita comunicar qué, cuando, y hacia quién.
Ahora que tiene todos los elementos básicos, vamos a empezar a ave-
riguar cuál es su información más sensible, y cómo podría estar en
peligro.
101
7
GESTIÓN DE RIESGOS
La evaluación y el tratamiento son, sin duda, la parte más compleja de

la implementación del estándar ISO 27001, pero no puede dejar de
realizarlos – sin estos pasos (evaluación y tratamiento) no sabrá dónde
enfocar sus esfuerzos con respecto a la seguridad de la información, lo
que significa que perderá algo importante.
Por suerte, este proceso puede agilizarse bastante – si no se complica

con elementos innecesarios, se puede acabar en un tiempo bastante
aceptable y con un esfuerzo razonable. Además, usted se sorprenderá
con lo que aprenderá acerca de su empresa con este proceso.
7.1 Abordar riesgos y oportunidades (cláusula 6.1.1)

Además del mencionado análisis del contexto de la organización y las
partes interesadas, en el proceso de planificación del SGSI, las empresas
deben identificar los riesgos y oportunidades que se deben abordar. Se
trata de la única manera de impedir que sucedan incidentes, al mismo
tiempo que se consiguen los objetivos del SGSI. Por cierto, el abordar
los riesgos y oportunidades, tiene un papel similar al de las acciones
preventivas que existían en la antigua revisión 2005 de la ISO 27001.
Los riesgos se refieren a eventos no deseados que pueden tener impacto

negativo en la seguridad de la información, y por lo tanto en la empresa,
tales como una inundación que podría destruir información en papel.
Las oportunidades se refieren a las acciones que podría emprender la
empresa con el fin de mejorar la seguridad de la información, como la
contratación de un experto en seguridad de la información como CISO.
Voy a explicar cómo hacer frente a los riesgos en las siguientes sec-
ciones; por otro lado el abordar oportunidades puede integrarse en
102
Gestión de riesgos
el proceso de mejora continua, que significa que son oportunidades
que pueden ser documentadas y evaluadas como las iniciativas para
la mejora continua del SGSI, como voy a describir en la sección 10.6;
abordar oportunidades también puede ser parte de la configuración de
los objetivos de seguridad y la medición de su cumplimiento.
Por ejemplo, si la empresa decide elegir a uno de sus empleados para

que sea el CISO, podría ser una oportunidad para esta persona mejorar
su conocimiento de seguridad de la información. Para ello la empresa
puede iniciar la acción de la mejora de este conocimiento de la persona
y puede establecer un objetivo para el CISO, que puede ser obtener
certificados de seguridad.
7.2 Cinco pasos en el proceso de gestión de riesgos

(cláusula 6.1)
La evaluación y el tratamiento (juntos se llaman gestión del riesgo) son
los pasos más importantes al principio de su proyecto de seguridad de
la información – establecen las bases de la seguridad de la información
en su empresa.
La pregunta es – ¿por qué son tan importantes? La respuesta es muy

sencilla aunque no es entendida por muchas personas: la filosofía prin-
cipal del estándar ISO 27001 es averiguar qué incidentes pueden ocu-
rrir (es decir, evaluar los riesgos) y luego encontrar la manera más ade-
cuada para evitar estos incidentes (es decir, tratar los riesgos). No sólo
esto, también tiene que valorar la importancia de cada riesgo para que
usted pueda centrarse en los más importantes.
Aunque la gestión del riesgo es un trabajo complejo, muy a menudo in-

necesariamente se transfigura. Estos 5 pasos básicos arrojará luz sobre
lo que tiene que hacer:
Metodología de Análisis Tratamiento Declaración de Plan de tratamiento
análisis de riesgos de riesgos de riesgos aplicabilidad de riesgos
Figura 5: Cinco pasos en el proceso de gestión del riesgo
103
SEGURO & SIMPLE
1) Metodología de análisis de riesgos. Este es el primer paso en
su viaje a través de la gestión del riesgo. Es necesario definir las reglas
sobre cómo va a realizar la gestión del riesgo, dado que desea que su
organización lo haga siempre del mismo modo, ya que el mayor proble-
ma con la evaluación del riesgo ocurre si diferentes partes de la orga-
nización lo realizan de una manera diferente. Por lo tanto, es necesario
definir qué escala usas para la evaluación cualitativa, cuál será el nivel
aceptable de riesgo, etc.
2) Implementación del análisis de riesgos. Una vez que conoce las

reglas, puede empezar a averiguar qué problemas podrían sucederle
– generalmente mostrará una lista de todos sus activos, y las amena-
zas y vulnerabilidades relacionadas con estos activos, la evaluación del
impacto y la probabilidad para cada combinación de activos/amenazas/
vulnerabilidades, y finalmente el cálculo del nivel de riesgo.
3) Implementación del tratamiento de riesgos. Por supuesto, no

todos los riesgos son iguales – usted tiene que centrarse en los más im-
portantes, llamados “riesgos inaceptables”. Hay cuatro opciones que
usted puede elegir para mitigar cada riesgo inaceptable: aplicar contro-
les de seguridad, transferir el riesgo, evitar el riesgo y aceptar el riesgo.
4) Declaración de aplicabilidad. Este documento realmente muestra

el perfil de seguridad de su empresa - basándose en los resultados del
tratamiento de riesgo, necesitará una lista de todos los controles que
ha implementado, por qué se han aplicado y cómo. Este documento
también es muy importante porque el auditor de certificación lo usará
como guía principal para la auditoría.
5) Plan de tratamiento de riesgos. El propósito de este documento

es definir exactamente quién va a implementar cada control, en qué
tiempo, con qué presupuesto, etc. Yo prefiero llamar a este documento
“Plan de implementación” o “Plan de acción”, pero vamos a usar la
terminología de ISO 27001.
Como verá en otras secciones, este proceso es bastante sencillo y real-

mente no es tan difícil como podría parecer al principio. Lo bueno es – ISO
27001 le obliga a realizar esta gestión de riesgos de forma sistemática.
104
Gestión de riesgos
Es muy importante entender que estos cinco pasos deben realizarse secuen-
cialmente - no puede implementar los controles de seguridad a menos que
sepa que estos son los más adecuados; no puede saber qué salvaguardias
son apropiadas, antes de encontrar dónde están los potenciales problemas;
Si primero no define las reglas para todo el proceso, simplemente fallará.
En las secciones siguientes voy a explicar cada uno de estos pasos, uti-
lizando también las directrices de ISO 27005.
7.3 Escribir la metodología de análisis de riesgos

(cláusula 6.1.2)
Propósito. Como dice el viejo refrán, si no sabe dónde va, probablemen-
te acabará en algún lugar a donde no esperaba llegar. Por lo tanto, no
debe empezar a evaluar los riesgos con ninguna metodología en mente,
o con alguna hoja que descargaste en algún lugar de Internet (esta hoja
podría utilizar una metodología que es completamente inadecuada para
su empresa); del mismo modo no debería empezar a utilizar la metodolo-
gía descrita por la herramienta de evaluación de riesgos que ha adquirido
(en su lugar, usted debe elegir la herramienta de evaluación de riesgos
que se adapte a su metodología, o puede decidir que no necesita una
herramienta, y que lo puede hacer mediante sencillas hojas de Excel).
Lo que debe hacer es – debe desarrollar o adaptar la metodología a sus

circunstancias específicas y a sus necesidades.
Entradas. Existen muchos mitos con respecto a lo que la evaluación del

riesgo debe ser, pero en realidad los requisitos de la ISO 27001:2013 no
son muy difíciles - aquí tiene lo que la cláusula 6.1.2 requiere:
1) Definir cómo identificar los riesgos que podrían causar la pérdida de

confidencialidad, integridad y/o disponibilidad en su información.
2) Definir cómo identificar a los propietarios de riesgos
3) Definir los criterios para evaluar las consecuencias y evaluar la

probabilidad del riesgo
105
SEGURO & SIMPLE
4) Definir cómo será calculado el riesgo
5) Definir los criterios para la aceptación de riesgos
Por tanto, esencialmente, debe definir estos 5 elementos en su meto-

dología – cualquier otra cosa no será suficiente, pero más importante
aún - no es necesario nada más, lo cual significa: no se complique de-
masiado la vida.
También, debe asegurarse de que los resultados de la evaluación de riesgos

son consistentes, es decir, tiene que definir que dicha metodología produ-
ce resultados comparables en todos los departamentos de su empresa.
Opciones. Por supuesto, hay muchas opciones disponibles para los 5

elementos de arriba – aquí tiene lo que puede escoger:
● Identificación de riesgos. En la revisión del 2005 de la ISO 27001,

fue descrita la metodología para la identificación: necesita identificar
activos, amenazas y vulnerabilidades. La actual revisión del 2013 de
la ISO 27001 no requiere tal identificación, lo que significa que puede
identificar los riesgos basándose en sus procesos, en sus departamen-
tos, utilizando sólo las amenazas y vulnerabilidades, o cualquier otra
metodología que le gusta; sin embargo, mi preferencia sigue siendo el
viejo buen método de activos-amenazas-vulnerabilidades – por ejemplo
este método le permitirá identificar, por ejemplo, todas las personas
que crean altos riesgos en su empresa, y las personas muy a menudo
son el eslabón más débil de seguridad.
●
Propietarios de riesgos. Básicamente, usted debe elegir a una
persona que esté interesada en la resolución de un riesgo y esté bien
posicionada en la organización para hacer algo al respecto.
●E
valuando consecuencias y probabilidad. Se deben evaluar por
separado las consecuencias y la probabilidad para cada uno de sus
riesgos; Usted es totalmente libre de usar cualquier escala que le
guste – por ejemplo, Bajo-Medio-Alto, o de 1 a 5, o de 1 a 10, etc. -
lo que más le convenga. Por supuesto, si quiere hacerlo simple, utilice
Bajo-Medio-Alto.
106
Gestión de riesgos
● Método de cálculo del riesgo. Esto habitualmente se realiza medi-
ante la suma de las consecuencias y la probabilidad (por ejemplo, 2
+ 5 = 7) o a través de la multiplicación (por ejemplo, 2 x 5 = 10). Si
utiliza escalas de Bajo-Medio-Alto, esto es lo mismo que utilizar la
escala 1-2-3, por lo que de nuevo tendrás números para el cálculo.
● Criterio para aceptar riesgos. Si su método de cálculo del riesgo

no produce los valores de 1 a 10, puede decidir que un nivel acept-
able de riesgo es, por ejemplo, 7 – esto significa que sólo los riesgos
valorados con 8, 9 y 10, necesitan un tratamiento. Como alternativa,
puede examinar cada riesgo individual y decidir cuál necesita un trat-
amiento, basándose en su conocimiento y experiencia, usando va-
lores no predefinidos. En cualquier caso, el nivel de riesgo aceptable
debe estar en consonancia con su estrategia de negocio – si usted
por ejemplo es una organización conservadora como un banco, en-
tonces su nivel de riesgo aceptable será menor.
La decisión de elegir entre estas opciones dependerá de lo siguiente:
● Tamaño y complejidad de su empresa – mientras más pequeña

y menos compleja sea su organización, más simple deberá ser su
metodología
● Legislación y obligaciones contractuales – si las leyes y requerimien-

tos (también contratos con sus clientes) le requieren que use una
determinada metodología, entonces no tienes nada que hacer.
● Reglas existentes para la gestión de riesgos – si usted es una em-

presa grande, o un banco, es probable que ya tenga algunas políti-
cas para la gestión de riesgos empresariales – su gestión de riesgos
de seguridad de la información debe cumplir con estas políticas.
Decisiones. Ya que este tipo de metodología tendrá consecuencias en

los empleados involucrados, y también puede tener consecuencias en la
precisión de los resultados, se recomienda que la aprobación final de este
documento sea realizada por la alta dirección. Por supuesto, antes de
enviarlo para su aprobación, usted debe enviarla para su revisión a un par
de jefes de departamentos y a los miembros de su equipo de proyecto.
107
SEGURO & SIMPLE
Documentación. El documento de su metodología tiene que describir
lo siguiente:
● El proceso de evaluación de riesgos, incluyendo el método de iden-

tificación de riesgos, cómo se determina el nivel de riesgos, escalas
de evaluación, método para el cálculo del riesgo, cómo determinar
el propietario del riesgo, el nivel de riesgo aceptable, cómo realizar
la decisión del tratamiento del riesgo, qué herramientas utilizar, etc.
● El proceso de tratamiento de riesgos, incluyendo responsabilida-

des y documentación.
●
Leyes, regulaciones, requerimientos contractuales relacionados
con la gestión de riesgos.
● El periodo de revisión – normalmente una vez al año, o con más

frecuencia si existen cambios importantes. Vea también la sección
Revisión periódica del análisis y tratamiento de riesgos (cláusula
8.2)8.9 para más detalles.
● Roles en el proceso completo – por favor, sea las secciones sobre

la realización del análisis y tratamiento de riesgos.
● Qué documentos tienen que producirse – por favor, sea las seccio-
nes sobre la realización del análisis y tratamiento de riesgos.
● Quién debe comunicar qué información a quién, y qué reportes

serán necesarios.
● Cómo proteger la confidencialidad de la información producida

durante el análisis.
Consejo de documentación: (obligatorio) Un documento denomi-
nado Metodología de evaluación de riesgos o Metodología de ges-
tión de riesgos.
108
Gestión de riesgos
7.4 Análisis de riesgos parte I: Identificando riesgos

(cláusulas 6.1.2 y 8.2)
Propósito. Basándome en mi experiencia, los empleados y toda la or-
ganización en su conjunto son generalmente conscientes de sólo un 25
a 40% de los riesgos – por lo tanto, un proceso minucioso y sistemático
debe llevarse a cabo para averiguar todo lo que podría poner en peligro
la confidencialidad, integridad y disponibilidad de su información.
Opciones. Puesto que este paso en el proyecto podría ser bastante lar-
go y complejo, debe decidir si será coordinado por el CISO, o por algu-
nos expertos contratados (por ejemplo, un consultor) - por simplicidad,
voy a mencionar sólo el CISO en esta sección. En cualquier caso, esta
persona tiene que desarrollar hojas de recogida de información (o si se
utiliza una herramienta, configurarla), organizar entrevistas o talleres,
compilar toda la información y producir el informe.
Si elige la manera más fácil y envía la metodología y las hojas de eva-
luación de riesgos a las personas responsables de cada departamento,
y les dice que las deben devolver, por ejemplo, el próximo Lunes, puede
estar seguro que los resultados que obtendrá de ellos serán inservibles
(si los obtiene). Esto es porque resulta muy difícil entender lo que es la
evaluación de riesgos, incluso si ha escrito muy bien su metodología.
Por lo tanto, si quiere tener éxito, básicamente tiene 2 opciones:
a) Realizar el análisis de riesgos a través de entrevistas – Esto sig-
nifica que el CISO entrevistará a la persona responsable de cada
departamento, y en primer lugar explicará el propósito de la eva-
luación de riesgos, y por otra parte se asegurará de que todas
las decisiones, sobre el nivel de riesgo, de la persona responsable
(consecuencia y probabilidad), tienen sentido y no son parciales.
b) Realizar talleres con las personas responsables – en estos ta-
lleres el CISO explica a todas las personas responsables el objetivo
de la evaluación de riesgos, y a través de varios ejemplos de la
vida real, muestra cómo identificar los riesgos y evaluar su nivel.
109
SEGURO & SIMPLE
Por supuesto, el realizar entrevistas probablemente de mejores resulta-
dos; sin embargo, esta opción a menudo no es factible porque requiere
una gran inversión de tiempo por parte del CISO.
Entradas. La principal entrada para el proceso de evaluación de riesgos
es, por supuesto, la metodología de evaluación de riesgos, y también
necesitará una lista de sus departamentos.
Si ha elegido la identificación de riesgos basada en activos, entonces
usted tendrá que identificar todos los activos de cada departamento
(Nota: los procesos no se consideran activos). Para ello, puede utilizar
sus actuales inventarios de activos, pero generalmente la mejor técnica
para la identificación de activos es: preguntar a las personas con más
conocimiento de cada departamento, lo que utilizan en sus operacio-
nes diarias - qué hardware y equipamiento (sólo hay que mirar alrede-
dor de su oficina), software (lo que está instalado en su equipo), servi-
cios (qué sitios web accede a través del navegador) , información digital
(navegar por sus carpetas), información en papel (lo que tienen en sus
escritorios y archivadores), infraestructura (oficinas y servicios públicos
que utilizan), personas que trabajan, etc.
Si tiene por ejemplo un servidor que contiene información confidencial,
podría figurar tres veces como un tipo de activo distinto: como un ser-
vidor físico, como un software que se ejecuta en ese servidor, y como
una base de datos. Puesto que el estándar no es estricto en relación al
inventario de activos, para los servidores menos sensibles puede incluir
un servidor como único activo. Además, usted puede agrupar activos
similares – si tienes varios ordenadores en una empresa, debe enume-
rarlos como un único activo en su evaluación del riesgo.
Para las amenazas y vulnerabilidades, lo mejor sería utilizar catálogos - si
utiliza algún tipo de herramienta o plantilla, ya debe tener estos catálogos,
y en el apéndice M encontrará una lista de amenazas y vulnerabilidades.
Si le resulta útil, puede organizar las amenazas según su tipo: malicioso
(por ejemplo, bombas, virus, etc.), naturales (por ejemplo, terremoto,
tsunami, etc.), mal funcionamiento (por ejemplo, pérdida de energía,
distribución de unidades de disco, etc.) y errores humanos (por ejem-
plo, borrado de datos, incumplimiento de procedimiento, etc.).
110
Gestión de riesgos
Del mismo modo, si lo desea, puede organizar las vulnerabilidades se-
gún los tipos de activos con los que se relacionan: hardware y equipos
(por ejemplo, falta de mantenimiento, inadecuada protección de hu-
medad, etc.), software (por ejemplo, interfaz de usuario complicadas,
falta de control de entrada de datos, etc.), servicios (por ejemplo, falta
de cláusulas de seguridad en los contratos, falta de control sobre las
operaciones del proveedor, etc.), información digital (por ejemplo, falta
de control de acceso, no existen copias de seguridad, etc.), información
en papel (por ejemplo, falta de protección física, reglas de clasificación
inadecuada, etc.), infraestructura (por ejemplo, falta de control de ac-
ceso físico, inadecuada protección de incendio, etc.) y no se olvide lo
más importante – recursos humanos (por ejemplo, entrenamientos in-
adecuados, falta de reemplazos, etc.).
Decisiones. Al combinar activos, amenazas y vulnerabilidades, es im-
portante vincularlos de forma lógica - por ejemplo, la amenaza de fue-
go puede estar relacionada con el hardware o cualquier otro activo
físico, mientras que la vulnerabilidad relacionada con la falta de sistema
de extinción de incendios, está directamente relacionada con la amena-
za de incendio; una amenaza relacionada con los empleados es que la
gente importante pueda dejar la empresa, y la vulnerabilidad puede ser
que no exista nadie para reemplazarlos.
La decisión que puede tomar un propietario del riesgo, debería recaer
en las personas responsables de cada Departamento – van a estar en
la mejor posición para decidir quién está interesado en la resolución de
ese riesgo, y también tienen el poder de hacer algo al respecto.
Documentación. Si la organización no usa una herramienta, enton-
ces los resultados son generalmente registrados en hojas Excel - en
este caso, el CISO recoge todas estas hojas y las compila en una hoja
principal que contiene todos los riesgos de la empresa. Si se utiliza la
herramienta, entonces este trabajo de recopilación se realiza automá-
ticamente. En cualquier caso, debe compilar todos estos resultados en
un informe de evaluación de riesgos.
Aquí tiene un ejemplo de cómo podría ser la tabla de evaluación de
riesgos, con los riesgos identificados y sus dueños:
111
SEGURO & SIMPLE
Propietario del
Activo Amenaza Vulnerabilidad
riesgo
Corte de
Servidor No existe UPS Jefe de TI
electricidad
No existe extintor Coordinador de
Fuego
de incendios seguridad & salud
Acceso de
Contraseña Usuario del
Portátil (laptop) personas no
inadecuada portátil
autorizadas
No se realizan
Pérdida de Usuario del
copias de seguri-
datos portátil
dad regularmente
Administrador Deja la No existe Jefe de Recursos
de sistemas compañía reemplazo humanos
Figura 6: Ejemplo de tabla de evaluación de riesgos con riesgos identificados
En el ejemplo de la tabla anterior, verás que un activo puede tener múl-

tiples amenazas relacionadas, y que cada amenaza puede tener múlti-
ples vulnerabilidades relacionadas.
Vea también este mini caso de estudio en el capítulo 14: Realizar el

análisis de riesgos en un pequeño hospital.
Consejo de documentación: (obligatorio) Hojas de evaluación de
riesgos o información recopilada a través de la herramienta de aná-
lisis de riesgos.
7.5 Análisis de riesgos parte II: Analizando

y evaluando riesgos (cláusulas 6.1.2 y 8.2)
Propósito. Tras saber los riesgos que tiene, debe descubrir lo importantes
que son (esto se llama análisis de riesgos) y concluir si son aceptables o no
(evaluación del riesgo). De esta forma, como resultado de todo el proceso
de evaluación de riesgos, tendrá una lista con los riesgos que necesita tratar.
112
Gestión de riesgos
Opciones. (Lo mismo que en la sección previa.)
Entradas. La principal entrada es una lista de los riesgos identificados,

tal y como se describe en la sección anterior, y las escalas para la evalua-
ción de las consecuencias y la probabilidad, definidas en la metodología
de evaluación de riesgos.
Para evaluar el nivel de la consecuencia, la gente que hace la evalua-

ción, necesita pensar en cómo el riesgo va a afectar a la confidencia-
lidad, integridad y disponibilidad de la información. Por esta razón, la
metodología de evaluación de riesgos debe describir muy exactamente
en qué casos asignar por ejemplo, “Alto”, “Medio” y “Bajo”. Por su-
puesto, mientras la escala sea más compleja, la correspondiente expli-
cación en la metodología será más extensa.
Al evaluar la probabilidad, de nuevo la metodología tiene que describir

lo que debe tenerse en cuenta - generalmente esto se basa en la infor-
mación de incidentes similares que hayan podido ocurrir en el pasado,
teniendo en cuenta el nivel actual de controles de seguridad, etc.
Decisiones. La decisión sobre el nivel de riesgo, o en otras palabras

la evaluación de la consecuencia y probabilidad, debe dejarse siempre
a las personas responsables de cada departamento – el CISO nunca
conocerá los activos, los procesos y el entorno lo suficientemente bien
como para tomar esas decisiones, pero las personas que trabajaban en
cada departamento tendrán una mejor idea.
Sin embargo, el CISO tiene otra función importante durante el proceso

de evaluación de riesgos – una vez que empieza a recibir los resultados
de evaluación de riesgos, tiene que asegurarse de que tienen sentido,
y que los criterios entre los diferentes departamentos son uniformes.
Aunque se han realizado talleres, o se ha dado una explicación durante
la entrevista a cada persona responsable, las personas siempre suelen
dar una importancia mayor (lo que significa riesgos más altos) a sus
propios departamentos - en estos casos, el CISO debe cuestionar cada
evaluación, y pedirle a cada persona que reconsidere su decisión.
113
SEGURO & SIMPLE
Documentación. Este es un ejemplo de cómo la tabla de evaluación
de riesgos puede quedar si se agregan las consecuencias y la proba-
bilidad a la tabla presentada en la sección anterior (las escalas que se
utilizan son: 1 = Muy bajo, 2 = Bajo, 3 = Medio, 4 = Alto, 5 = Muy alto);
el riesgo se calcula a través de la suma, y nivel de riesgo aceptable es 7:
Propie-
Vulnera- Conse- Proba- Ries-
Activo Amenaza tario del
bilidad cuencia bilidad go
riesgo
Corte de No existe
Servidor Jefe de TI 4 2 6
electricidad UPS
Coordi-
No existe
nador de
Fuego extintor de 5 3 8
seguridad
incendios
& salud
Acceso de Contrase- Usuario
Portátil
personas no ña inade- del por- 4 4 8
(laptop)
autorizadas cuada tátil
No se
realizan
Usuario
Pérdida de copias de
del por- 4 3 7
datos seguridad
tátil
regular-
mente
Adminis- Jefe de
Deja la No existe
trador de Recursos 5 3 8
compañía reemplazo
sistemas humanos
Figura 7: Ejemplo de tabla de evaluación de riesgos
En el ejemplo de la tabla anterior, los riesgos de las filas 1 y 4 son acep-

tables y no necesitan tratamiento, mientras que los riesgos de las filas
2, 3 y 5 no son aceptables y tienen que pasar al paso siguiente – el
tratamiento de riesgos.
114
Gestión de riesgos
Consejo de documentación: (obligatorio) Hojas de análisis de ries-

gos o información recopilada a través de la herramienta de análisis
de riesgos.
(no obligatorio) Se debe elaborar un documento denominado In-

forme de análisis de riesgos; algunas veces también se le denomina
Informe de análisis y tratamiento de riesgos si incluye los resultados
del tratamiento de riesgos.
7.6 Realizando el tratamiento de riesgos

(cláusulas 6.1.3 y 8.3)
Propósito. El propósito del tratamiento de riesgos (o mitigación de ries-
gos) parece bastante simple: controlar los riesgos identificados durante
el análisis de riesgos; en la mayoría de los casos esto significa disminuir el
riesgo reduciendo la probabilidad de un incidente (por ejemplo, median-
te el uso de materiales de construcción inflamables), o reducir el impacto
sobre los activos (por ejemplo, mediante el uso de sistemas automáticos
de extinción de incendios). Durante el tratamiento de riesgos la organi-
zación debe centrarse en aquellos riesgos que no son aceptables; de lo
contrario, será difícil definir prioridades, y financiar la mitigación de todos
los riesgos identificados.
Opciones. Una vez que tiene una lista de los riesgos que no son acep-
tables, tiene que ir uno por uno y decidir cómo tratarlos - generalmen-
te, estas son las opciones que se aplican:
1. Reducir el riesgo – Esta opción es la más común, e incluye la imple-
mentación de salvaguardas (controles) – como por ejemplo sistemas
de extinción de incendios, etc.
2. Evitar el riesgo – paralizar la realización de ciertas tareas o procesos
si incurren en riesgos que simplemente son demasiado grandes para
mitigar con otras opciones, por ejemplo, puede decidir prohibir el
uso de ordenadores portátiles fuera de las instalaciones de la empre-
sa si el riesgo de accesos no autorizados a los ordenadores portátiles
es demasiado alto (porque por ejemplo, a través de estos equipos se
podría detener la infraestructura de TI completa que está utilizando).
115
SEGURO & SIMPLE
3. Transferir el riesgo – Esto significa transferir el riesgo a otra parte –
por ejemplo, usted compra una póliza de seguro para su edificio, para
protegerle contra el fuego, y por lo tanto transfiere parte de su riesgo
financiero a una compañía de seguros. Desafortunadamente, esta op-
ción no tiene influencia alguna sobre el incidente, por lo que la mejor
estrategia es utilizar esta opción junto con las opciones 1) y 2).
4. Asumir el riesgo – Esta es la opción menos deseable, y significa
que su organización acepta el riesgo sin hacer nada al respecto. Esta
opción debe usarse sólo si el coste de la mitigación es mayor que el
daño que produciría un incidente.
El disminuir los riesgos es la opción más común para el tratamiento
de riesgos, y para ello se utilizan los controles del anexo A de la ISO
27001 (y cualquier otro control que una empresa piense que puede
ser apropiado). Como aprenderá más adelante en detalle, el Anexo A
proporciona un total de 114 controles.
No importa si utiliza catálogos o no, cada salvaguarda vendrá principal-
mente para:
a) Definir nuevas reglas: Las reglas están documentadas a través de
planes, políticas, procedimientos, instrucciones, etc., aunque no tie-
ne que documentar algunos procesos menos complejos.
b) Implementar nueva tecnología: Por ejemplo, sistemas de copias
de seguridad, sitios de recuperación ante desastres para centros de
datos alternativos, etc.
c) Cambiar la estructura organizacional: En algunos casos, usted
tendrá que introducir una nueva función de trabajo, o cambiar las
responsabilidades de una posición existente.
Entradas. Las principales entradas para el tratamiento de riesgos, son
la Metodología de Gestión de Riesgo, y los riesgos no aceptables de
la evaluación de riesgos; sin embargo, una entrada adicional también
debe ser el presupuesto para el año en curso, porque muy a menudo la
mitigación requiere una inversión.
Decisiones. El tratamiento de riesgos es un paso que normalmente no
incluye a un círculo muy amplio de personas - tendrá que pensar cada
116
Gestión de riesgos
opción de tratamiento con especialistas en su compañía que se centren
en cada área específica. Por ejemplo, si el tratamiento tiene que ver
con TI, hablará a sus chicos de TI; Si se trata de nuevas capacitaciones,
hablará con recursos humanos, etc.
Por supuesto, la decisión final sobre una nueva opción de tratamiento

requerirá una decisión desde el apropiado nivel de dirección – a veces
el CISO será capaz de tomar tales decisiones, otras veces será el equipo
de proyecto, otras veces tendrá que ir a por el Jefe del departamento a
cargo de un campo determinado (por ejemplo, el Jefe del Departamen-
to legal si solicita cláusulas adicionales en los contratos con sus socios)
, o tal vez tenga que ir al nivel ejecutivo para mayores inversiones. Si
tiene dudas sobre quién puede tomas las decisiones, consulte con el
patrocinador del proyecto.
Al considerar estas opciones y particularmente las salvaguardas que

involucran una inversión en tecnología, por favor, tenga cuidado con
lo siguiente: muy a menudo la primera idea que viene a la mente es
comprar lo más caro - por lo tanto, reflexione antes de comprar un
costoso nuevo sistema. A veces existirán alternativas que serán igual-
mente eficaces, pero con menor coste. También, sea consciente de que
la mayoría de los riesgos que existen son debido a la conducta humana,
no por máquinas - por lo tanto, en estos casos es cuestionable que una
máquina sea la solución al problema.
En otras palabras, aquí es donde tiene que ser creativo – usted necesita
averiguar cómo disminuir los riesgos con una inversión mínima. Sería
más fácil si su presupuesto fuese ilimitado, pero esto nunca va a pasar.
Y debo decirles que desgraciadamente su dirección hace lo correcto -
es posible lograr el mismo resultado con menos dinero - sólo tiene que
ser lo suficientemente listo como para llegar a una solución.
Si elige medir los riesgos residuales, debería hacerlo junto con las personas
responsables de cada departamento – tiene que mostrarles las opciones
de tratamiento que usted tiene previstas, y basándose en esta informa-
ción, y utilizando las mismas escalas, se debe evaluar el riesgo residual para
cada riesgo no aceptable identificado anteriormente durante el análisis de
riesgos. Así, por ejemplo, si había identificado una consecuencia de nivel 4
117
SEGURO & SIMPLE
y una probabilidad de nivel 5 durante su análisis de riesgos (lo que significa
un riesgo de 9 según el método de la suma), el riesgo residual puede ser 5
si usted evalúa que la consecuencia bajaría a 3 y la probabilidad a 2, debi-
do a, por ejemplo, medidas de seguridad que tiene previsto implementar.
Documentación. El proceso de tratamiento de riesgos muy a menudo

se documenta también junto con el proceso de evaluación de riesgos
– a través de hojas de Excel o una herramienta y, finalmente, en el infor-
me de tratamiento de riesgos. Un ejemplo de una tabla de tratamiento
de riesgos podría ser algo como esto:
Opción Justificación de
Vulnera-
Activo Amenaza de trata- implementa-
bilidad
miento ción
Comprar extintor
1) Reducir
No existe de incendios +
riesgo +
Servidor Fuego extintor de contratar póliza de
2) Compartir
incendios seguro contra
riesgo
incendios
Acceso de
Portátil Contraseña 1) Reducir Escribir política de
personas no
(laptop) inadecuada riesgo contraseñas
autorizadas
Contratar un
segundo
Administra-
Deja la No existe 1) Reducir administrador de
dor de
compañía reemplazo riesgo sistemas que lo
sistemas
aprenda todo del
primero
Figura 8: Ejemplo de tabla de tratamiento de riesgos
Consejo de documentación: (obligatorio) Resultados del tratamien-

to de riesgos en forma de una hoja Excel o en una herramienta de
gestión de riesgos.
(no obligatorio) Se puede elaborar un documento denominado In-
forme de tratamiento de riesgos; algunas veces también se le de-
nomina Informe de análisis y tratamiento de riesgos si incluye los
resultados del tratamiento de riesgos
118
Gestión de riesgos
7.7 Declaración de aplicabilidad: El documento central

de todo el SGSI (cláusula 6.1.3 d)
Propósito. La importancia de la Declaración de Aplicabilidad (a veces
conocida como SoA, por sus iniciales en inglés de Statement of Appli-
cability) generalmente está subestimada – como el Manual de calidad
en ISO 9001, es el documento central donde define cómo implementa-
rá los elementos principales de la seguridad de la información.
En realidad, la Declaración de Aplicabilidad es el vínculo principal entre
la evaluación y el tratamiento, y la implementación de la seguridad de
la información – su propósito es definir cuál de los 114 controles suge-
ridos en el Anexo A de la ISO 27001 será aplicado, y para aquellos que
apliquen, cómo se aplicarán, su estado, etc. Como el Anexo A se con-
sidera completo, pero no exhaustivo para todas las situaciones, nada le
impide agregar otros controles que se consideren aplicables.
Si va a por la certificación ISO 27001, el auditor de certificación tomará
su Declaración de Aplicabilidad y caminará alrededor de su empresa com-
probando si se han implementado los controles de la manera en que se
describe en su SoA. Es el documento central para hacer su auditoría in situ.
Entradas. Como se mencionó anteriormente, la principal entrada de
la Declaración de Aplicabilidad son los resultados del tratamiento de
riesgos. Sin embargo, usted debe también tener en cuenta la legis-
lación, los requisitos contractuales, otros procesos, etc. porque ellos
también podrían influir en que controles se deben aplicar - por lo tan-
to, el análisis y tratamiento de riesgos no tiene el “monopolio” para
decidir qué controles deben aplicarse.
Opciones. Existen un par de opciones a la hora de escribir el SoA:
● Incluir objetivos de seguridad por cada control – este requisi-
to existió en la revisión del 2005 de la ISO 27001, pero ya no es
obligatorio en la última revisión del 2013 de la ISO 27001. Sin
embargo, creo que podría ser un buen lugar para definir objetivos
si no tiene previsto escribirlos en otro documento que defina los
objetivos de seguridad de nivel inferior. Hablaré más sobre cómo
establecer los objetivos de seguridad tácticos en la sección 8.1.
119
SEGURO & SIMPLE
● Incluir descripción de la manera en que controles específicos
son implementados – esto no existe como requisito en el estándar,
pero se recomienda incluir esta información en el SoA. Esto es por-
que (1) el auditor de certificación esperará ver algo como eso, por-
que hace su trabajo de auditoría más fácil, y más importante (2) será
más fácil para usted tener una visión general de qué están haciendo
en su empresa en materia de seguridad – como se mencionó ante-
riormente, esto también creará el perfil de seguridad de su empresa.
Decisiones. En base a mi experiencia, la mayoría de empresas que imple-
mentan un sistema de gestión de seguridad de la información según la
ISO 27001, pierden mucho tiempo escribiendo este documento, más de
lo que esperaban. La razón de esto es porque deben pensar cómo imple-
mentarán sus controles: ¿van a comprar nuevos equipos? ¿O van cambiar
un procedimiento? ¿O van a contratar a un nuevo empleado? Estas son
decisiones muy importantes (y a veces caras), por lo que no es de extrañar
que tarde mucho tiempo lograrlas. Lo bueno del SoA es que obliga a las
organizaciones a realizar este trabajo de una manera sistemática.
En mi opinión, la mejor manera de acelerar este proceso de toma de deci-
siones es llenar la Declaración de Aplicabilidad por columnas – en primer
lugar la aplicabilidad de cada control, a continuación, la justificación, etc.
Documentación. La mejor manera de redactar una Declaración de
Aplicabilidad, es en forma de tabla, con las siguientes columnas:
● ID del control – por ejemplo, A.6.2.1
● Nombre del control – por ejemplo, Política de dispositivos móviles
● Si el control e aplicable o no – Sí o No
● (si el control es aplicable) Justificación para la inclusión – por ejem-
plo, resultados del análisis de riesgos
● (si el control no es aplicable) Justificación para la exclusión – por
ejemplo, la actividad que causaría los riesgos no existe
● (opcional) Objetivos de control – por ejemplo, “Reducir el número
de incidentes de seguridad relacionados con los dispositivos móvi-
les en un 25% durante el siguiente año”
120
Gestión de riesgos
● (opcional, altamente recomendado) Método de implementación
– haciendo referencia a la política/procedimiento/instrucción de
trabajo, o describiendo brevemente el proceso que se usa, o men-
cionando el equipamiento que se utiliza
Si el control está implementado o no – por ejemplo, “Planificado” o
“Completamente implementado” o “Parcialmente implementado”
Así es como puede quedar su Declaración de Aplicabilidad para los
siguientes 2 controles:
Nombre Método
Aplica- Justifi- Objetivos Esta-
ID del con- de imple-
bilidad cación de control do
trol mentación
Reducir el
número de Com-
Política
incidentes ple-
Traer Su
de seguridad ta-
Política de Propio
Riesgos relacionados men-
dispositi- Dispositivo
A.6.2.1 Sí #34, 45 con los dis- te
vos móvi- (BYOD del
y 66 positivos mó- im-
les inglés Bring
viles en un ple-
Your Own
25% durante men-
Device)
el siguiente tado
año
Los em-
pleados
sólo
Teletra-
A.6.2.2 No trabajan - - -
bajo
desde
las ofici-
nas
Figura 9: Ejemplo de Declaración de Aplicabilidad

nado Declaración de Aplicabilidad.
121
SEGURO & SIMPLE
7.8 Desarrollando el Plan de tratamiento de riesgos

(cláusulas 6.1.3, 6.2, y 8.3)
Propósito. Como se mencionó antes, para empezar a pensar sobre el
plan de tratamiento de riesgos, es más fácil pensar en él como un “plan
de acción” donde usted debe especificar los controles de seguridad
que deberá implementar, quién es responsable de ellos, cuáles son los
plazos, y qué recursos (financieros y humanos) son necesarios.
Este es el paso en el que tiene que pasar de la teoría a la práctica. Vamos
a ser francos – todo hasta ahora en este trabajo de gestión de riesgos ha
sido puramente teórico, pero ahora es el momento de mostrar algunos
resultados concretos - es decir, implementar salvaguardias reales.
Por tanto, el Plan de tratamiento de riesgos es realmente un documento
que permite una transición de la fase de Planificar a la fase de Hacer
– esto significa que todos los controles que fueron seleccionados e in-
cluidos en el plan, se deben poner en práctica, teniendo en cuenta en el
plan los recursos disponibles, los plazos definidos y otros elementos. En
la práctica, esta implementación significa escribir varias políticas y proce-
dimientos, implementar algunos controles técnicos, organizar procesos
en una forma diferente, etc.
Entradas. Por supuesto, para escribir este documento, en primer lugar
usted necesita decidir qué controles deben aplicarse, y esto se hace me-
diante la Declaración de Aplicabilidad. Otras entradas que son útiles para
la redacción de este plan son: quiénes son los propietarios de riesgos que
deben aprobar el plan, cuál es el presupuesto disponible que tiene, cuál
es el procedimiento para la aprobación de nuevas inversiones, etc.
Documentación. El plan debe listar todos los controles de la Decla-
ración de Aplicabilidad que todavía no están aplicados, junto con los
detalles pertinentes acerca de cómo se van a implementar los controles.
Es una práctica común documentar el plan de tratamiento de riesgos
en forma de una tabla incluyendo elementos tales como:
● Los controles que serán implementados – por ejemplo, escribir un
documento como una Política criptográfica
122
Gestión de riesgos
● Referenciar al riesgo que inició la implementación de este control
– por ejemplo, la divulgación de información confidencial y la in-
tercepción de una comunicación por correo electrónico
● La persona responsable para la implementación de cada uno de
los controles
● El plazo para la implementación de cada control
● Los recursos necesarios – Por ejemplo, recursos financieros para
comprar software o hardware, expertos técnicos externos, etc.
● Una columna de seguimiento donde se anotarán los resultados de
la implementación.
Nota: El estado del Plan de tratamiento de riesgos y los resultados del tra-
tamiento de riesgos son también analizados en cada revisión por dirección.
Aquí tiene un ejemplo de Plan de tratamiento de riesgos:
Controles
Persona
que serán Referencia Resul-
responsa- Plazo Recursos
implemen- a riesgos tados
ble
tados
Documen- Riesgo 16 Respon- Mar- 1 hombre/día Imple-
tar una – Indispo- sable de zo menta-
política de nibilidad de Seguridad 2016 do
copias de información (CISO)
seguridad electrónica
debido a la
pérdida ac-
cidental de
información
Implemen- Riesgo 16 Adminis- Junio 3 hombres/ En pro-
tar la políti- – Indispo- trador de 2016 días; presu- ceso de
ca de copias nibilidad de sistemas puesto para imple-
de seguri- información los controles menta-
dad electrónica técnicos ción
debido a la
pérdida ac-
cidental de
información
123
SEGURO & SIMPLE
Imple- Riesgo 32 – Respon- Abril 3 hombre/ En pro-

mentar un Los portátiles sable de 2016 día; presu- ceso de
control de (laptops) operacio- puesto para imple-
entrada podrían ser nes técni- los controles men-
físico con robados por cas técnicos y las tación;
una tarjeta personal ex- tarjetas inte- plazo
inteligente terno ligentes para supera-
todos los do
empleados
Figura 10: Ejemplo de Plan de tratamiento de riesgos
Opciones. Usted puede decidir combinar el plan de tratamiento de ries-

gos con otros documentos en su empresa - he visto algunas compañías
que lo combinan con el Plan de proyecto (ya que ambos documentos
definen básicamente lo que hay que hacer durante la implementación
de la ISO 27001); sin embargo no le aconsejo hacerlo porque el plan
de tratamiento de riesgos debe ser utilizado también como una herra-
mienta una vez que se completa el proyecto de implementación – algu-
nos de los controles podrían retrasarse para después de la certificación,
y cada nueva revisión del análisis de riesgos y el tratamiento de riesgos
requerirá algunos nuevos controles a implementar.
Puede combinar este plan de tratamiento de riesgos con otros docu-

mentos de “plan de acción” en su empresa – por ejemplo, para el
proceso de presupuestos podría tener algunos documentos operacio-
nales que describan lo que debe hacerse en un determinado periodo
de tiempo, y sería muy bueno incluir el plan de tratamiento de riesgos
en dicho documento.
Decisiones. Después de documentar el plan de tratamiento de riesgos,

se debe obtener una aprobación de los propietarios de riesgo (o de la
alta dirección en su nombre). Esto es realmente importante porque los
propietarios de riesgo son las personas principales que pueden garan-
tizar la eficacia de los controles implementados y el tratamiento de los
riesgos, y si no están comprometidos con el plan de tratamiento de
riesgos propuesto, pueden ocurrir muchos problemas, como el retraso
de la implementación, incompatibilidad con otros elementos, etc.
124
Gestión de riesgos

nado Plan de tratamiento de riesgos.

Para resumir, esto es lo que tiene que hacer para realizar una gestión de
riesgos con garantías de éxito:
● Desarrollar una cultura de gestión de riesgos – la mayoría de las
salvaguardas deben implementarse por los riesgos
● Gestionar los riesgos de una manera sistemática – asegúrese de
realizar los cinco pasos en el orden correcto
● La metodología de gestión de riesgos tiene que ser adaptada a las
necesidades específicas de su compañía
● Los empleados de su empresa van a necesitar ayuda de su CISO
la primera vez que se analicen riesgos – Asegúrese de que se le
muestra cómo es realizado de una manera adecuada
● A la hora de recibir los resultados del análisis de riesgos de sus
colegas, asegúrese de que el CISO los revisa y solicita correcciones
si están demasiado sesgados
● A la hora de tratar riesgos, asegúrese de que ha cubierto todos los
riesgos no aceptables
● Siempre consulte con sus colegas a la hora de determinar los con-
troles – esta es una fase en la que se tienen que tomar muchas
decisiones de inversión
● No olvide la Declaración de Aplicabilidad – este documento es el
más importante para la auditoría de certificación (y muy útil para
la gestión de seguridad)
● El Plan de tratamiento de riesgos es su plan de implementación –
asegúrese de que lo usa adecuadamente
125
SEGURO & SIMPLE
Ahora usted sabe exactamente lo que necesita implementar – vamos a

ver cómo implementar las salvaguardas.
126
8
IMPLEMENTANDO CONTROLES
DE SEGURIDAD; CONTROL Y
PLANIFICACIÓN OPERACIONAL
Después de una cuidadosa y detallada planificación del sistema de ges-

tión de seguridad de la información es hora de comenzar a implemen-
tar el SGSI. La sección octava del estándar ISO 27001 está dedicada a la
puesta en práctica y operación del SGSI en el día a día.
En la fase de Hacer (o Implementar) la empresa implementará nume-

rosos controles de seguridad de la información, según el Plan de tra-
tamiento de riesgos, también implementará procesos, acciones para
abordar los riesgos y oportunidades, y se asegurará de que todo el
mundo está cumpliendo con todos las políticas, procedimientos, etc.
La implementación incluye la creación de diversa documentación para

el SGSI, como políticas, procedimientos, guías, etc. y también hay que
poner toda esta documentación en práctica. Por ejemplo, el plan de
tratamiento de riesgos define que se ejecutará una copia de seguridad.
Para tal fin, por ejemplo, el CISO debe identificar diferentes tipos de
información y la frecuencia óptima para la copia de seguridad – por
ejemplo la información sobre el servidor de archivos debe tener una co-
pia de seguridad diaria y la base de datos del software CRM (Customer
Relationship Management) debe tener 2 copias de seguridad al día.
Basado en este análisis, el CISO debería redactar una política de copias
de seguridad y asegurarse de que la pone en práctica. Poner en práctica
significa que el administrador de sistemas debe implementar los con-
troles técnicos que se describen en la política, como la instalación del
software de backup, la conexión con el dispositivo de almacenamiento
para las copias, definir las tareas de backup, etc.
127
SEGURO & SIMPLE
8.1 Establecimiento de objetivos para controles

de seguridad y procesos (cláusula 6.2)
Propósito. De manera similar a los objetivos para todo el SGSI (es decir,
“los objetivos estratégicos”), el propósito de los objetivos para con-
troles y procesos particulares de seguridad (es decir, “los objetivos de
seguridad tácticos”), debe ser medir si los controles y procesos han
justificado su existencia.
Y establecer los objetivos es el primer paso crucial – una vez que sepa
la meta, puede fácilmente medir lo cerca o lejos que está usted de ese
objetivo.
Idealmente, debe establecer los objetivos antes de empezar a aplicar sus

controles o procesos – así usted sabrá exactamente lo que quiere lograr.
Opciones. Con respecto a estos objetivos de seguridad tácticos, exis-

ten varias opciones que puede usar para establecerlos (y que luego más
adelante medirá):
a) Objetivos de seguridad para controles o grupos de controles
b) Objetivos de seguridad para procesos
c) Objetivos de seguridad para unidades organizativas – por ejemplo

departamentos
Puede seleccionar sólo una opción o varias juntas - debe tomar la deci-
sión basándose en la complejidad de su empresa: las empresas más pe-
queñas, que son menos complejas, tienden a tener objetivos sólo para
unidades organizativas, mientras que las grandes empresas probable-
mente tendrán los 3 niveles de objetivos anteriormente mencionados.
Decisiones. Igual que para los objetivos de seguridad estratégicos para

todo el SGSI, los objetivos tácticos tienen que estar basados en el con-
cepto S.M.A.R.T. explicado en la secció .6.
Por ejemplo, ¿qué objetivo le gustaría para el firewall? Algo así como
“Queremos que nuestro firewall detenga el 100% del tráfico de red no
128
Implementando controles de seguridad; control y planificación operacional
deseado”. ¿Es medible? Sí – porque usted detectará, tarde o temprano,
si ha pasado tráfico no deseado a través del firewall.
Otro ejemplo – las copias de seguridad. El objetivo podría ser “quere-

mos lograr que la pérdida de datos sea de máximo 6 horas.” ¿Es medi-
ble? Sí - y no tiene que esperar a que se pierdan datos, puede probar la
copia de seguridad y ver cuántos datos puede restaurar.
La decisión para estos objetivos debe ser un trabajo en equipo entre

el CISO, los propietarios de activos que son responsables de algunos
controles, los propietarios del riesgo, y los jefes de los departamentos
para los que deben ser fijados los objetivos. Dependiendo de las reglas
internas de su empresa, algunas veces este tipo de objetivos tienen que
ser aprobadas por la alta dirección.
En la secció 10.1 explicaré cómo medir si los objetivos se han logrado.
Entradas. Usted debe comenzar a familiarizarse con los objetivos de

seguridad estratégicos, porque los objetivos tácticos deben ser compa-
tibles con los objetivos estratégicos, y contribuir hacia el cumplimiento
de los objetivos estratégicos.
A continuación, usted debe entrevistar a todas las partes interesadas re-

lacionadas con el control, proceso o departamento concreto - debe oír lo
que quieren, y entonces empezar a tomar una decisión sobre el objetivo.
Documentación. Existen muchas formas para documentar los objeti-

vos de seguridad tácticos – puede escribirlos en un documento indepen-
diente junto con los objetivos estratégicos, puede usar la Declaración
de Aplicabilidad para escribir los objetivos de control, o puede utilizar
algún sistema tipo cuadro de mando integral para documentarlos.
 Consejo de documentación: (obligatorio) Los objetivos tácticos del
SGSI pueden ser listados en un documento separado, por ejemplo,
Lista de objetivos de seguridad de la información, o por ejemplo en
la Declaración de Aplicabilidad.
129
SEGURO & SIMPLE
8.2 Por dónde empezar con la documentación

Cuando se trata de escribir diferentes políticas, procedimientos, planes,
guías y otros documentos, aquí tiene un par de consejos que le pueden
ayudar para saber por dónde empezar.
Para compañías más pequeñas, utilice estos criterios para decidir qué
documentos escribir primero:
●Á
reas donde puede conseguir victorias rápidas – esto significa
que puede seleccionar un área donde usted sabe que terminará
su documento rápidamente, y de esta forma podrá demostrar a
su dirección, sus compañeros (y a usted mismo) que es capaz de
hacer este trabajo con eficacia.
●Á
reas donde tiene riesgos mayores – de esta manera puede em-
pezar a resolver en primer lugar los problemas más grandes – esto
no lo puede terminar rápidamente, pero a veces este enfoque es
necesario si su análisis de riesgos ha demostrado que tiene lagu-
nas muy grandes que tiene que tratar.
●Á
reas que son compatibles con otros proyectos que están en
marcha en su organización –por ejemplo, si su empresa está imple-
mentando un software tipo help desk (de soporte), puede comenzar a
escribir el procedimiento de gestión de incidencias, porque esto regu-
lará cómo utilizará el software en el contexto del estándar ISO 27001.
En relación a los documentos que se suelen dejar para el final, mi pre-

ferencia personal son los documentos que cubren el mayor número de
controles (por ejemplo, la Política de Uso Aceptable). De esta manera
sabrá qué controles ha cubierto con otros documentos, y cuáles de los
que no han sido descritos en otras políticas y procedimientos, pueden
ser descritos en otro documento. En la siguiente sección explicaré qué
documentos deben escribirse como parte del anexo A.
Las empresas más grandes tendrán un enfoque diferente – primero es-

criben las políticas (cada política podría cubrir una sección del anexo A),
después los procedimientos relacionados, y finalmente las instrucciones
de trabajo que explican los detalles de los procedimientos. Las grandes
130
empresas también pueden utilizar los criterios mencionados anterior-
mente para decidir qué políticas escribir primero.
Para finalizar, asegúrese de que utiliza la flexibilidad que ISO 27001 le

ofrece para adaptar la documentación a sus necesidades específicas –
porque la idea es que la documentación le sirva a usted, no al revés.
8.3 Decidir qué políticas y procedimientos escribir

Es importante saber que la ISO 27001 no especifica qué tipo de docu-
mentación es necesaria, pero señala que la organización tiene que te-
ner la cantidad necesaria de información documentada para que la or-
ganización pueda asegurar que las actividades y los controles se llevan
a cabo de acuerdo a lo que estaba previsto. Esto significa, que además
de los documentos mínimos (es decir, obligatorios), no existe una lista
más amplia de los documentos que se deben implementar, y depende
de cada empresa decidir cuántos registros y documentos creará para el
SGSI, y cómo serán de detallados.
Ahora probablemente esté en un dilema: Cuántos documentos es necesa-

rio tener, y si es necesario escribir ciertas políticas y procedimientos o no.
Criterio para decidir qué documentar. Bueno, el primer paso es fá-

cil, usted necesita comprobar si un documento es requerido por el es-
tándar ISO 27001 – para ello, consulte el Apéndice A de este libro. Si el
documento es obligatorio, no tienes nada que pensar – lo debe escribir
si quiere cumplir con este estándar.
Sin embargo, si el documento no es obligatorio, puede encontrarse

confuso sobre si es necesario que lo escriba o no – por ejemplo, ¿se
necesita una política de copias de seguridad? ¿O tal vez una política de
clasificación? ¿O una política BYOD?
Aquí tiene varios criterios que le ayudarán:
● Riesgos. Usted tiene que comenzar analizando riesgos para ver si ex-
iste una necesidad de algún control. Si no hay ningún riesgo, entonc-
es ciertamente no necesita un documento; si existe un riesgo, esto
131
SEGURO & SIMPLE
todavía no significa que tenga que escribir un documento, pero al
menos ha podido resolver el dilema de si el control es necesaria o no.
● Cumplimiento. A veces usted puede tener una regulación o un

requisito contractual para escribir un determinado documento –
por ejemplo, una regulación puede requerir escribir la Política de
Clasificación, o su cliente puede requerir que firme un tipo espe-
cífico de Acuerdo de Confidencialidad con sus empleados
● Tamaño de la compañía. Las empresas más pequeñas tienden a ten-

er menos documentos, por lo que en este caso se debe intentar evitar
escribir un procedimiento para cada pequeño proceso – por ejemplo,
si usted tiene 20 empleados no necesita 50 documentos para su SGSI.
Por supuesto, si usted es una organización multinacional con 10.000
empleados, es posible que escriba políticas, y para cada una tendría un
par de procedimientos relacionados, y luego para cada procedimiento
un par de instrucciones de trabajo - este enfoque tiene sentido.
● Importancia. Mientras más importante sea un proceso o una ac-

tividad, más probable es que quiera escribir una política o un pro-
cedimiento para describirlo - esto es porque usted querrá asegu-
rarse de que todo el mundo entiende cómo realizar dicho proceso
o actividad, para de esta manera poder evitar posibles interrup-
ciones en las operaciones.
● Número de personas involucradas. Mientras tenga más gen-

te que realiza un proceso o una actividad, más probable es que
tenga que documentarlo; por ejemplo, si tiene 100 personas in-
volucradas, será muy difícil de explicar verbalmente a todas estas
personas cómo llevar a cabo un determinado proceso – es mucho
más fácil escribir un procedimiento que pueda explicar todo en
detalle. Por otro lado, si tiene cinco personas involucradas, proba-
blemente pueda explicar cómo funciona el proceso entero en una
sola reunión, por lo que no hay necesidad de un procedimiento
escrito. Sin embargo hay una excepción: Si usted tiene sólo una
persona trabajando en un proceso, puede documentarlo, porque
nadie más sabrá cómo hacerlo - si esta persona no está disponible,
usted podrá continuar sus operaciones.
132
●C
omplejidad. Mientras más complejo sea el proceso, más proba-
ble será que necesite documentarlo (al menos en forma de lista de
verificación) – es simplemente imposible recordar de memoria, por
ejemplo, 100 pasos que deben realizarse en una secuencia exacta.
●M
adurez. Si un proceso o una actividad está claramente estable-
cida, si ha estado funcionando durante años y todo el mundo sabe
exactamente cómo llevarla a cabo, si está bien afinada, entonces
probablemente no hay necesidad de documentarlo.
● Frecuencia. Si realiza algunas actividades concretas sin una peri-

odicidad determinada, puede documentarlas, porque podría olvi-
dar cómo se hacen.
Encontrar el balance correcto. Mientras tenga más documentos y

sean más detallados, más difícil será mantenerlos, y asegurar que sus em-
pleados los leen. Por otra parte, un número menor de documentos, que
también sean breves, puede describir exactamente lo que necesita hacer.
En la mayoría de los casos, recomiendo a mis clientes no llegar a ser

demasiado ambiciosos - si no hay absoluta necesidad de crear un nuevo
documento, no lo haga; Si no hay necesidad de describir un proceso
con gran detalle, que sea más corto. Y recuerde – los documentos in-
necesarios no le traerán nada más que problemas – tener un menor
número de documentos sencillos es la mejor manera para asegurar que
los controles de seguridad de la información no le comen demasiado
el bolsillo.
8.4 Escribir la documentación que será aceptada por

todos los empleados
Por desgracia, muy a menudo ocurre la siguiente situación: invierte una
gran cantidad de tiempo y energía en el desarrollo de una nueva políti-
ca o un procedimiento, sólo para descubrir más tarde que no se ajusta
a las necesidades reales de un departamento particular; o peor aún – el
documento puede ser correcto pero los empleados simplemente lo re-
chazan, porque no estaban involucrados en todo el proceso.
133
SEGURO & SIMPLE
Así que aquí está el proceso de 7 pasos que debe seguir, para evitar
cualquier tipo de problemas - estos pasos son aplicables a cualquier
tipo y tamaño de empresa:
1) Estudiar los requerimientos. Primero tiene que estudiar con mu-

cho cuidado varios requisitos – ¿existe alguna legislación que requiera
tenerlos por escrito? ¿O tal vez un contrato con su cliente? ¿O alguna
otra política de alto nivel que ya existe en su organización (tal vez un
estándar corporativo)? Y por supuesto, asegúrese de que comprende
los requisitos de la ISO 27001.
2) Tener en cuenta los resultados de su análisis de riesgos. El

análisis de riesgos determinará qué cuestiones tiene que abordar en su
documento, pero también hasta qué punto – por ejemplo, puede que
necesite decidir si se clasifica la información según su confidencialidad,
y si es así, si necesita dos, tres o cuatro niveles de confidencialidad.
3) Optimizar y alinear sus documentos. Una cosa importante a con-

siderar es el número total de documentos – ¿vas a escribir diez docu-
mentos de 1 página o un documento de 10 páginas? Es mucho más
fácil gestionar un documento, especialmente si el grupo de lectores es
el mismo. (No cree un solo documento de 100 páginas.)
Además, tiene que tener cuidado de alinear su documento con otros do-
cumentos – las cuestiones que se están definiendo, puede que ya estén
parcialmente definidas en otro documento. En tal caso, no sería necesa-
rio escribir un nuevo documento, quizás sólo ampliar uno existente.
Si va a escribir un nuevo documento sobre una regla que ya se men-

ciona en otro documento, asegúrese de evitar redundancia – para des-
cribir la misma regla en ambos documentos. Más tarde se convertiría
en una pesadilla mantener esos documentos; es mucho mejor que un
documento haga referencia a otro, sin repetir la misma materia.
4) Estructurar su documento. También debe cuidar de observar las

reglas que define su empresa para dar formato al documento – tal vez
tiene un Procedimiento para el control de documentos que define el
formato, o puede tener una plantilla con las fuentes predefinidas, los
encabezados, los pies de página, etc.
134
5) Escribir su documento. La regla del pulgar es – mientras la organi-
zación sea más pequeña, y los riesgos sean menores, menos complejo
debe ser el documento. No hay nada más inútil que decidir escribir un
documento largo que nadie va a leer - tiene que entender que la lectu-
ra del documento toma tiempo, y el nivel de atención es inversamente
proporcional al número de líneas que tiene el documento.
Una técnica fundamental para vencer la resistencia de otros empleados con

respecto a un nuevo documento (a nadie le gusta un cambio, especialmen-
te si eso significa algo así como que se va a establecer como obligatorio el
cambiar las contraseñas regularmente) es implicarlos en escribir o comentar
este documento – de esta manera comprenderán por qué es necesario.
6) Obtener la aprobación de su documento. Este paso es algo casi

evidente, pero su importancia subyacente es - si usted no es un respon-
sable de alto rango en su empresa, usted no tiene el poder para hacer
valer un documento. Por esta razón, alguien con esta posición tiene
que entenderlo, aprobarlo, y cumplir activamente con su implementa-
ción. Suena fácil, pero créanme - no lo es. Este paso (y el siguiente) son
en los que más a menudo falla la implementación.
7) Capacitación y concientización de sus empleados. Este paso es

probablemente el más importante, pero lamentablemente es uno de
los que a menudo se olvidan. Los empleados están cansados de cons-
tantes cambios, y seguramente no recibirán con buen agrado otro, es-
pecialmente si significa más trabajo para ellos - por lo tanto, es muy
importante explicar a sus empleados por qué es necesaria una política
o un procedimiento, y cómo llevar a cabo nuevas actividades que se
requieran. He explicado estos puntos en las cio 6.3 y 6.4.
Por lo tanto el punto es - no es suficiente tener una plantilla bonita para

tener una exitosa política o un procedimiento - lo que necesita es un
enfoque sistemático para su implementación. Y al hacerlo no olvide lo
más importante: el documento no es un fin en sí mismo – es sólo una
herramienta para que sus actividades y procesos se puedan ejecutar sin
problemas. No deje que ocurra lo contrario – que un documento haga
que estas actividades y procesos se ejecuten con más dificultad.
135
SEGURO & SIMPLE
Vea también este mini caso de estudio en el capítulo 14: Escribir las políti-
cas de seguridad de la información en una compañía de manufacturación.
8.5 Operar el SGSI con una periodicidad diaria

(cláusula 8.1)
Finalmente, su documentación está escrita, sus controles técnicos están
implementados, ¡todo lo que tiene que hacer ahora es asegurarse de que
sus empleados están haciendo lo que deberían! Parece una tarea fácil,
pero no lo es – tener todos los requisitos de la ISO 27001 implementados,
o pasar la certificación ISO 27001, no significa que ha completado su tra-
bajo con respecto al SGSI. Acaba de empezar el trabajo real con su SGSI.
El sistema de gestión de seguridad de la información tiene sentido sólo

si es operado en el día a día. En primer lugar, usted tiene que asegurarse
de que realiza todas las actividades descritas en sus políticas y procedi-
mientos. Y no me refiero sólo a crear artificialmente algunos registros y
pretender hacer creer a los auditores que están haciendo algunas activi-
dades – me refiero a caminar realmente por el camino, cumpliendo con
todos los requisitos de todos los documentos, y produciendo registros
reales. Si usted piensa que esto no tiene sentido, tiene que simplificar sus
documentos o eliminar algunos documentos que no sean obligatorios.
Este funcionamiento diario del SGSI puede parecer una cosa obvia, pero
créame – aquí es donde sucederán la mayor parte de los problemas. Al-
gunos empleados simplemente olvidarán su procedimiento, otros lo inter-
pretarán de manera incorrecta, u otros lo obstruirán intencionadamente.
Algunos empleados interpretarán mal el propósito del estándar ISO

27001 – podrían pensar que la documentación fue creada solamente
con el propósito de la certificación, y después de esto ya no es necesaria.
Por tanto, si quiere mantener su SGSI completo, tendrá que volver al

papel de vendedor y diplomático que describí en la sección 3.2 – sin
una evangelización constante, poco a poco, sobre por qué son necesa-
rias estas nuevas reglas, y cuáles son los beneficios de la seguridad, sus
documentos comenzarán a ser olvidados, uno a uno.
136
8.6 Gestionar cambios en el SGSI (cláusula 8.1)

Propósito. Otra cosa en la que el estándar presta atención es en los cambios.
Obliga a la empresa a gestionar los cambios, planificándolos y controlando
su implementación, pero también señala que los cambios no planificados
deben ser analizados, y deben ser tratados para evitar efectos no deseados.
La gestión de cambios es un aspecto importante de la seguridad de la
información, debido a las grandes lagunas en seguridad que pueden pre-
sentarse exactamente a la hora de hacer cambios en su organización,
especialmente si los cambios son involuntarios y no están planificados.
Por ejemplo, si la alta dirección, por algún motivo inesperado, por ejem-
plo por un ahorro financiero, decide cambiar a otro software, tendrá
que analizar la implicación que puede tener en la seguridad de la infor-
mación, para anticipar posibles consecuencias y lidiar con ellas. Algunas
cuestiones que podrían ser críticas para la seguridad de la información
son: compatibilidad entre dos programas de software, y la protección de
la integridad de la información durante la transferencia al nuevo softwa-
re; la disponibilidad de la información, es decir, tener más actualizada
una copia funcional de la información, etc.
Entradas. Básicamente, usted debe estar atento a cualquier decisión
de la dirección, a cambios en la relación con terceros, cambios en los
riesgos identificados, etc. - todos ellos pueden desencadenar cambios
que son importantes para la seguridad de su información.
Documentación. ISO 27001 no requiere políticas ni procedimientos para
definir el proceso de cambios, sin embargo, para ser capaz de planificar e
implementar eficazmente cambios es recomendable establecer un proce-
dimiento de gestión de cambio, que cubra elementos tales como quién y
cómo se puede iniciar un cambio, qué tipo de análisis debe ser realizado
y documentado, quién aprueba los cambios, quién los implementa, etc.
Opciones. Como se mencionó anteriormente, usted tiene la opción de es-
cribir el procedimiento de cambio, o trabajar sin él; en general, usted pue-
de decidir lo formal que desea sea este proceso de cambio – en las empre-
sas más pequeñas tienden a ser informales, mientras que en las grandes
empresas lo tendrán todo documentado, y controlado muy estrictamente.
137
SEGURO & SIMPLE
También existen diferentes opciones a la hora de establecer quién
aprueba los cambios – esto podría ser un proceso muy centralizado
(típico para las empresas más pequeñas, con una persona como único
propietario), y en las grandes empresas los cambios menores pueden
ser decididos en niveles inferiores de la jerarquía, mientras que sólo los
cambios más grandes tienen que ser aprobadas por la parte superior.
Decisiones. En la línea de un ejemplo previo del cambio de software,

en el que la alta dirección inicia el cambio, pero dado que es un cambio
relacionado con TI, el administrador de sistemas será asignado para llevar
a cabo el análisis pertinente. Basado en los resultados de este análisis, el
administrador de sistemas debe preparar un informe explicando a la alta
dirección lo que debe hacerse y qué recursos son necesarios para el éxito
de la migración al nuevo software, proponiendo un calendario de las ac-
tividades así como un equipo de proyecto para implementar el cambio.
Basándose en este informe la alta dirección tiene que tomar una decisión
sobre si aprueba o no aprueba el cambio, y en qué medida.
Consejo de documentación: (no obligatorio) Documento que de-

fine cómo realizar los cambios, por ejemplo, Procedimiento de ges-
tión de cambios.
8.7 Mantenimiento de la documentación

(cláusula 7.5.2)
Propósito. Las políticas, los procedimientos y demás documentación de-
finen sus procesos y otras actividades de su empresa. Pero los procesos y
las actividades pueden cambiar tan rápidamente que su documentación
puede quedarse anticuada, si no en 3 meses, seguramente en un año.
Así que si no desea que su documentación se convierta en cosa del

pasado, tiene que mantenerla con regularidad - de lo contrario, se con-
vertirá en una carga en lugar de una herramienta que debería ayudarle
a aumentar el nivel de su seguridad.
Entradas. Debe supervisar que documentos no ha actualizado durante

un tiempo – si ha definido un periodo de revisión para cada docu-
138
mento, será mucho más fácil. También, para cada cambio mayor en
un determinado departamento, o algún proceso, usted debe ver si la
documentación relacionada también debe ser actualizada.
Documentación & decisiones. La mejor práctica es designar a un pro-

pietario para cada documento, y esta persona tendrá que revisar su do-
cumento periódicamente (generalmente una vez al año), y recomendar
posibles cambios. Este dueño debe especificarse en cada documento, o
usted puede tener una lista central con todos los documentos, y definir
en esta el dueño de cada uno.
Opciones. Usted puede revisar su documentación con más o menos

frecuencia, dependiendo de lo rápido que cambien las cosas en su em-
presa - para las empresas tradicionales donde los cambios son raros,
la revisión de los documentos una vez en 2 años podría ser suficiente;
sin embargo para empresas más pequeñas de rápido crecimiento esto
puede hacerse cada 6 meses.
 Consejo de documentación: (no obligatorio) Definir en cada una
de sus políticas, procedimientos y planes un responsable del docu-
mento, y especifique con qué frecuencia se tienen que revisar.
8.8 Gestión de servicios externalizados (cláusula 8.1)

Propósito. Además de los controles, acciones y procesos que la em-
presa va a operar, podría contratar a otras organizaciones para una
parte de las operaciones. ISO 27001 requiere que todas las operaciones
externalizadas sean identificadas y controladas adecuadamente en ma-
teria de seguridad de la información.
El requisito para el control de los procesos subcontratados es importan-

te porque la tendencia de las actividades de externalizadas está aumen-
tando en todo el mundo, y se ha vuelto muy común para las empresas
externalizar las operaciones críticas relacionadas con la seguridad de
la información, como el mantenimiento de la infraestructura de TI, la
gestión de recursos humanos, etc.
139
SEGURO & SIMPLE
Entradas. La principal entrada debe ser una lista de acuerdos firmados
con terceras partes, proveedores de servicios; Además, en cualquier
momento en el que se inicie un proceso de firma de un acuerdo con un
nuevo socio o proveedor, esto debe también servir como un disparador
para la gestión adecuada de dicha tercera parte.
Decisiones. Debe tener una lista de todos los acuerdos, examinar uno
a uno todos los que sean de terceras partes, y decidir si incluyen una
parte externalizada de sus operaciones. En caso afirmativo, tiene que
decidir cómo controlar estas terceras partes.
Veamos un ejemplo de una pequeña empresa de diseño que externaliza

el proceso de contratar a nuevos empleados a una empresa de recluta-
miento. La empresa debe asegurarse de que la empresa de reclutamiento
contratada sigue sus requisitos de seguridad relativos a los recursos hu-
manos, como por ejemplo llevar a cabo verificaciones de antecedentes
de los potenciales empleados, o incluyen los requisitos de seguridad de la
información en el contrato de trabajo etc. Para que la empresa de diseño
pueda ser capaz de controlar a la empresa de reclutamiento, debe do-
cumentar un procedimiento que incluya todos los aspectos de seguridad
de la información relevantes con respecto a la contratación de nuevos
empleados, debe comunicarlo a la empresa externalizada y obtener su
aceptación. Tener las reglas por escrito ayudará a la empresa de recluta-
miento a cumplir con los requisitos, y le dará la oportunidad a la empresa
de diseño de gestionar y controlar sus operaciones externalizadas.
Documentación & opciones. El estándar no requiere ninguna docu-

mentación relativa a operaciones de externalización, sin embargo, es
práctico tener información documentada, como una política para la ges-
tión de socios externalizados. Como explicaré en el capítulo ¡Error! No se
encuentra el origen de la referencia., el anexo A requiere la inclusión de
cláusulas de seguridad en los contratos y acuerdos de confidencialidad
con los proveedores de los servicios subcontratados etc. Además, puede
ser muy útil si la documentación para el control de los servicios exter-
nalizados de esta cláusula 8.1 se combina con la documentación de los
controles de relaciones con proveedores definidos en la sección A.15 del
anexo A. Hablaré sobre la seguridad en las relaciones con proveedores
con más detall la sección 9.14 de este libro.
140
 Consejo de documentación: (no obligatorio) Documento que defi-

ne cómo controlar proveedores, incluyendo servicios externalizados,
por ejemplo, Política de Seguridad de Proveedores.
8.9 Revisión periódica del análisis y tratamiento de

riesgos (cláusula 8.2)
Propósito. El análisis de riesgos de seguridad de la información que
traté en el capítulo 7, se menciona de nuevo en la cláusula octava del
estándar, esta vez como parte de la fase Hacer (o Implementar).
El estándar explica en este apartado que el análisis de riesgos de se-

guridad de la información debe realizarse regularmente, a intervalos
planificados - los resultados de las evaluaciones de riesgo deben ser
analizados en cada revisión por dirección. Un análisis de riesgos regular
es importante porque permite a las empresas reaccionar proactivamen-
te a un nuevo riesgo que puede aparecer como resultado de cambios
internos en la empresa, o cambios externos en el entorno.
El análisis de riesgos es una actividad bastante compleja, especialmente

cuando se realiza por primera vez puede ser complicado y puede perder
tiempo porque los empleados no saben realmente lo qué es; sin embar-
go, la realización de la revisión del análisis de riesgos le llevará mucho
menos tiempo.
Opciones. Se ha aceptado como buena práctica en las empresas el

planificar la realización del análisis de riesgos por lo menos una vez al
año; sin embargo si usted funciona en un entorno de alto riesgo, sería
mejor revisar los riesgos más a menudo – por ejemplo, cada tres meses.
Entradas. Además del tiempo definido para la revisión regular de los

riesgos, estos deberían ser re-evaluados en los casos en los que se pla-
nean cambios mayores, o suceden de manera inesperada. Por ejemplo,
si la dirección decide comenzar a usar servicios en la nube, la empresa
tendrá muchos cambios. Por esta razón, en esta situación debe reali-
zarse el análisis de riesgos con el fin de identificar los nuevos riesgos
141
SEGURO & SIMPLE
relacionados con los proveedores y los servicios en la nube, así como
re-evaluar los riesgos existentes ya conocidos.
Decisiones. El proceso de toma de decisiones es básicamente el mismo

que cuando evalúa los riesgos - el propietario del activo, o la persona
responsable del departamento que corresponda, debe listar todos los
activos y ver si faltan algunos nuevos, identificar amenazas y vulnera-
bilidades, evaluar la consecuencia y probabilidad, definir el propietario
del riesgo y determinar el nivel de riesgo.
Documentación. Como se mencionó previamente, los resultados del

análisis de riesgos se deben documentar. Dado que el análisis de riesgos
inicial ya está documentado como expliqué en el capítulo 7, las empre-
sas deben usar los mismos registros de análisis de riesgos para docu-
mentar las actualizaciones, marcando claramente las actualizaciones y
los cambios en los resultados, y creando una nueva versión del registro.
 Consejo de documentación: (obligatorio) El calendario para la re-

visión regular del riesgo, se define normalmente en la Metodología
de análisis de riesgos.

En resumen, para implementar todos los controles de la mejor mane-
ra, y llevar a cabo todas las operaciones de seguridad, debe hacer lo
siguiente:
● Asegúrese de que establece objetivos de seguridad que son medi-

bles – este es el elemento principal para la medición
● Decida qué documentos empezará a escribir primero, basándose

primero en un criterio claro
● No sea demasiado ambicioso a la hora de escribir documentos – su

forma de pensar debe ser “Mientras más pequeño, mejor”
142
● Incluya a otras personas en la elaboración de la documentación,
porque es la mejor manera de conseguir su compromiso
● Cuanto más utilice las políticas y procedimientos con una frecuen-

cia diaria, mejor
● Dado que cada cambio es un riesgo de seguridad, tiene que definir

un sistema que describa cómo controlar los cambios
● No mantener la documentación significaría que aunque ha inver-

tido una gran cantidad de esfuerzo para el desarrollo de los docu-
mentos, pronto se pueden convertir en algo inútil
● Evalúe los riesgos de cualquier parte externalizada de sus opera-

ciones
● Revise los resultados del análisis de riesgos regularmente, como

mínimo una vez al año
Ahora que sabe cómo manejar los controles, vamos a ver cómo son
realmente los controles del Anexo A.
143
9
RESUMEN DE LOS CONTROLES
DEL ANEXO A
Es posible que le decepcione un poco con este capítulo, porque no voy a

darle una explicación detallada de cada control - si tuviera que hacerlo,
no le hablaría más sobre ISO 27001, le explicaría en detalle la ISO 27002.
Realmente no tiene mucho sentido explicar los detalles de cada control

cuando esto ya está cubierto por la ISO 27002 – por lo tanto, le daré una
visión general de los controles que existen, cómo están estructurados y
dónde deben ser utilizados; También le proporciono enlaces a materiales
gratuitos que le dan consejos sobre la implementación, puesto que los ma-
teriales son muy numerosos y sería muy difícil incluirlos todos en este libro.
Para una explicación detallada de cada control, debe consultar la ISO

27002 - después de todo, este es el mejor documento que describe los
detalles de los controles de seguridad de información.
9.1 Introducción al Anexo A de la ISO 27001

El anexo A de la ISO 27001 ofrece un catálogo de 114 controles de se-
guridad, agrupados en 14 secciones. Estas secciones se dividen en varias
subsecciones con diferentes objetivos. Por ejemplo, la sección A.12 Segu-
ridad de las operaciones, tiene siete subsecciones. La tercera subsección
es A.12.3 Copias de seguridad, y su objetivo es evitar la pérdida de datos,
y la quinta subsección es A.12.5 Control del software en explotación,
cuyo objetivo es garantizar la integridad de los sistemas operacionales.
Como he mencionado en un punto anterior, no todos estos 114 con-

troles son obligatorios – a través del proceso de gestión de riesgos, una
empresa puede decidir por sí misma cuales son los controles que ne-
cesita aplicar, y entonces deberá implementarlos (en la mayoría de los
casos, al menos el 90% de los controles son aplicables).
144
Resumen de los controles del Anexo A
Lo mejor del Anexo A es que le proporciona un perfecto resumen de
los controles que puede aplicar, para que no olvide controles que pue-
den ser importantes, y le da la flexibilidad de seleccionar sólo los que
encuentre aplicables a su negocio, por lo que no tiene que desperdiciar
recursos en algo que no es relevante para usted.
Los controles del anexo A pueden ser organizacionales o técnicos, lo
que significa que pueden ser implementados documentando políticas,
procedimientos o implementando algunos medios técnicos como por
ejemplo la instalación de un software antivirus, o un firewall etc.
La verdad es que el anexo A de la ISO 27001 no da demasiados detalles
acerca de cada control. Generalmente sólo proporciona una frase para
cada control, lo cual da una idea de lo que usted necesita lograr, pero
no da detalles de cómo puede hacerlo. En el estándar ISO 27002 se dan
más detalles acerca de estos controles. Este estándar tiene exactamente
la misma estructura que el Anexo A de la ISO 27001, pero con una ex-
plicación más detallada sobre cómo implementar los correspondientes
controles. Es importante señalar aquí que sería un error utilizar sólo
ISO 27002 para la gestión de la seguridad de la información, puesto
que no da ninguna pista en cuanto a cómo seleccionar los controles a
implementar, cómo medirlos, cómo asignar responsabilidades, etc. ISO
27002 se utiliza como un estándar complementario a ISO 27001.
9.2 Estructura del Anexo A

Como se explicó anteriormente, cada sección del Anexo A cubre contro-
les relacionados con temas específicos, como por ejemplo controles para
la gestión de proveedores, o para el control de accesos. Este tipo de es-
tructura permite a los usuarios de este estándar entender qué tipo de con-
troles existen, y les ayuda a encontrar rápidamente el control apropiado.
Vamos a ver un rápido resumen del propósito de las 14 secciones del
Anexo A:
● A.5 Políticas de seguridad de la información – esta sección
proporciona controles sobre cómo se escriben las políticas y cómo
se revisan
145
SEGURO & SIMPLE
● A.6 Organización de la seguridad de la información – esta
sección incluye controles sobre cómo se asignan responsabilidades;
también incluye controles para dispositivos móviles y teletrabajo
● A.7 Seguridad relativa a los recursos humanos – controles
para antes del empleo, durante y después
●A
.8 Gestión de activos – controles relacionados con el inventa-
rio de activos, uso aceptable, y también para la clasificación de la
información y el manejo de soportes
● A.9 Control de acceso – controles para la Política de control de
accesos, la gestión de accesos de usuario, control de acceso a apli-
caciones y sistemas, y responsabilidades de usuarios
● A.10 Criptografía – controles relacionados con el cifrado y la
gestión de claves
●A
.11 Seguridad física y del entorno – controles para la definición
de áreas seguras, controles de entrada, protección contra amena-
zas, retirada segura, política de escritorio y pantalla limpia, etc.
● A.12 Seguridad de las operaciones – muchos de los controles
relacionados con la gestión de la parte de entornos de produc-
ción en TI: gestión de cambios, gestión de la capacidad, malware,
copias de seguridad, registro de eventos, monitorización, instala-
ción, vulnerabilidades, etc.
● A.13 Seguridad de las comunicaciones – controles relaciona-
dos con la seguridad de la red, segregación, servicios de red, trans-
ferencia de información, mensajería, etc.
● A.14 Adquisición, desarrollo y mantenimiento de los siste-
mas de información – controles de definición de requerimientos
de seguridad y seguridad en el desarrollo, y procesos de soporte
● A.15 Relación con proveedores – controles sobre qué incluir en
los acuerdos, y cómo supervisar a los proveedores
146
● A.16 Gestión de incidentes de seguridad de la información
– controles para reportar eventos y debilidades, definir responsabi-
lidades, procedimientos de respuesta, y recopilación de evidencias
●A
.17 Aspectos de seguridad de la información para la ges-
tión de la continuidad del negocio – controles que requieren la
planificación de la continuidad del negocio, procedimientos, veri-
ficación y revisión, y redundancia TI
● A.18 Cumplimiento – controles que requieren la identificación
de leyes y regulaciones aplicables, protección de la propiedad inte-
lectual, protección de datos personales, y revisiones de seguridad
de la información
Como puede notar en la estructura presentada del anexo A, los contro-
les de seguridad de la información no están sólo relacionadas con TI. La
Seguridad física, la protección legal, la gestión de recursos humanos,
las cuestiones organizacionales – todas estas cuestiones juntas son ne-
cesarias para asegurar la información.
En las siguientes secciones se cubrirá una descripción más detallada de

todas estas secciones y sus controles.
9.3 Estructurar la documentación para el Anexo A

Antes de comenzar a estructurar su documentación, permítame insistir
en un par de reglas muy importantes: simplemente no puede comenzar
a seleccionar los controles o escribir los documentos que más le gusten
- el punto es que la selección de los controles debe ser consecuencia
directa del análisis de riesgos y el proceso de tratamiento de riesgos; en
segundo lugar, debe saber qué documentos son obligatorios y cuáles
no; por último, una vez que conozca los controles que debe aplicar, y
qué documentos son obligatorios, debe decidir lo extensa que será la
documentación: las empresas más pequeñas tienden a tener un núme-
ro menor de documentos – no documentan cada control, e incluyen
varios controles en un único documento; para las grandes empresas el
enfoque será completamente opuesto.
147
SEGURO & SIMPLE
¿Qué documentos deben cubrir los controles? Dado que el Anexo A
tiene 114 controles, la verdad es que no es muy fácil decidir cómo agru-
par las políticas y procedimientos para cubrir todos los controles. Y el
hecho de que la ISO 27001 no describa qué controles deben asignarse
para cada una de las políticas o procedimientos, inicialmente puede pa-
recer un problema, pero una vez que se de cuenta de que este enfoque
le da gran libertad para adaptar la documentación a sus necesidades
reales, realmente agradecerá que la ISO 27001 sea tan flexible.
Básicamente, existen dos enfoques para agrupar los documentos:
Las empresas más pequeñas normalmente tienen políticas y/o procedi-
mientos que cubren muchos controles con sólo un documento – por
ejemplo, puede utilizar:
● La Política de Control de Accesos para cubrir 14 controles de la
sección A.9 (sin escribir procedimientos detallados),
● Política BYOD (Bring Your Own Device – Trae Tu Propio Dispositi-
vo) para cubrir no sólo A.6.2.1 (Política de Dispositivos Móviles) y
A.6.2.2 (Teletrabajo), también A.13.2.1 (Políticas y procedimientos
de intercambio de información),
● Con la Política de Uso Aceptable, puede ser más ambicioso y cu-
brir controles de varias secciones del Anexo A, dado que este do-
cumento podría servir como una base de seguridad para todos los
empleados: A.6.2.1, A.6.2.2, A.8.1.2, A.8.1.3, A.8.1.4, A.9.3.1,
A.11.2.5, A.11.2.6, A.11.2.8, A.11.2.9, A.12.2.1, A.12.3.1,
A.12.5.1, A.12.6.2, A.13.2.3, and A.18.1.2.
Las empresas más grandes generalmente estructuran la documenta-
ción de diferente manera:
● Cada sección del Anexo A se cubrirá con una política – Por ejem-
plo, Política de Organización de la seguridad de la información
(A.6), Política de Recursos Humanos (A.7), Política de Gestión de
Activos (A.8), etc.
● Cada política tendrá procedimientos, y cada procedimiento una
detallada instrucción de trabajo que cubre controles simples – por
148
ejemplo, Procedimiento de clasificación de la información, (para el
control A.8.2.1), Procedimiento de etiquetado de la información
(control A.8.2.2), Procedimiento de manipulado de la información
(control A.8.2.3), etc.
Integrar documentación existente. Muy a menudo las empresas ten-
drán alguna documentación escrita antes del inicio del proyecto del es-
tándar ISO 27001. Por ejemplo, puede tener una Política de clasificación
- en ese caso, debe comprobar si esta política es compatible con ISO
27001, y si cubre algunos de los controles de la Declaración de Apli-
cabilidad; Si el documento en general está en consonancia con lo que
planea hacer, puede continuar utilizándolo, y lo único que tendrá que
hacer es adaptarlo en el caso de que falte algo.
Por otro lado, si tiene un tipo de política de seguridad de la información

antigua, donde se han escrito todas las reglas posibles de seguridad,
y tiene una longitud de unas 100 páginas, va a tener que retirar este
documento, y usar sólo algunas de sus secciones a la hora de crear nue-
vos documentos - por ejemplo, podría utilizar la parte que hable de las
contraseñas para crear una nueva Política de contraseñas.
9.4 Política de seguridad de la información (A.5)

 Esta sección consta de lo siguiente:
● A.5 Políticas de seguridad de la información
 A.5.1 Directrices de gestión de la seguridad de la información
 A.5.1.1 Políticas para la seguridad de la información
 A.5.1.2 Revisión de las políticas para la seguridad de la in-
formación
Vamos a comenzar con la primera sección del Anexo A, las Políticas de segu-
ridad de la información, numeradas como A.5. El propósito de esta sección
es presentar una idea sobre cómo escribir detalladas políticas de seguridad
de la información, que cubran ciertos segmentos de los controles d Anexo A.
En la sección 5.5 he descrito que la Política de seguridad de la informa-

ción obligatoria es una política de alto nivel que establece el enfoque
149
SEGURO & SIMPLE
básico de la empresa con respecto a la seguridad de la información.
Aquí el Anexo del estándar se refiere a un nivel más bajo, políticas espe-
cíficas, como por ejemplo la política de control de acceso, la política de
copias de seguridad, la política para la clasificación de la información,
la política de escritorio despejado y pantalla limpia, etc.
Dependiendo de la necesidad de estas políticas, pueden ser enfocadas

en un cierto tema o un cierto grupo de personas, y deben ser comuni-
cadas a los empleados y a las partes interesadas.
Estas políticas de seguridad de la información deben ser revisadas regular-

mente, especialmente después de cambios significativos en la organización.
9.5 Organización de la seguridad de la información

(A.6)
● A.6 Organización de la seguridad de la información
 A.6.1 Organización interna
 A.6.1.1 Roles y responsabilidades en seguridad de la información
 A.6.1.2 Segregación de tareas
 A.6.1.3 Contacto con las autoridades
 A.6.1.4 Contacto con grupos de interés especial
 A.6.1.5 Seguridad de la información en la gestión de proyectos
 A.6.2 Los dispositivos móviles y el teletrabajo
 A.6.2.1 Política de dispositivos móviles
 A.6.2.2 Teletrabajo
Esta segunda sección del Anexo A cubre controles para la gestión de

la seguridad de la información dentro de la organización, y también
cubre controles para garantizar la seguridad en el teletrabajo y el uso
de dispositivos móviles.
150
Los controles relacionados con la organización interna, Incluyen:
● Definición de roles y responsabilidades de seguridad de la informa-
ción relacionados con procesos, procedimientos, políticas y con-
troles documentados e implementados como parte del SGSI.
● Segregación de funciones – en las grandes empresas es relativa-
mente fácil separar la persona que toma una decisión sobre una
determinada actividad, de la persona que la ejecuta (por ejemplo,
el CTO decide dar acceso a una aplicación determinada a un nue-
vo empleado, y el administrador de sistemas da el acceso en la
aplicación); en compañías más pequeñas es más difícil, por lo que
en este caso debe centrarse sólo en la segregación de las activida-
des donde se tienen riesgos altos.
● Mantener contacto con autoridades relevantes – como por ejem-
plo agencias que velan por el cumplimiento legal (por ejemplo la
autoridad para la protección de datos personales), para casos en
los que necesita reportar un incidente de seguridad si sospecha
que se ha incumplido una ley, por ejemplo porque alguien hackeó
su base de datos y se robaron datos personales
● Contactar con grupos de especial interés – como miembro de es-
tos grupos puede mejorar su conocimiento en mejores prácticas
y tendencias de seguridad de la información, y estos grupos le
pueden dar acceso a consejos de seguridad de la información, etc.
●A
bordar la seguridad de la información en gestión de proyectos sin
importar el proyecto, incluyendo los objetivos de seguridad en los ob-
jetivos del proyecto, realizando el análisis de riesgos de seguridad de
la información para el proyecto, y básicamente asegurándose de que
la seguridad de la información es parte de cada fase del proyecto.
Además de estos controles, también existen controles para los disposi-
tivos móviles y el teletrabajo, lo cual incluye:
● Adoptar una política de dispositivos móviles con el fin de reducir el
riesgo relacionado con los dispositivos móviles a través de contro-
les de acceso, restricción de instalación de software, criptografía,
deshabilitación de acceso remoto, etc.
151
SEGURO & SIMPLE
● P olítica para el teletrabajo – definición de reglas bajo las cuales se
permita el teletrabajo, asegurando la protección física, requisitos de
seguridad en las comunicaciones, protección a través de firewall, etc.
Estos controles son muy importantes, porque el uso de dispositivos móviles

ha crecido rápidamente en los últimos años, y los riesgos relacionados con
los dispositivos móviles están subiendo en las listas de ranking de riesgos.
 Recursos adicionales:
● artículo Special interest groups: A useful resource to support
your ISMS
● artículo How to manage security in project management ac-
cording to ISO 27001 A.6.1.5
● artículo How to write an easy-to-use BYOD policy compliant
with ISO 27001
9.6 Seguridad relativa a los recursos humanos (A.7)

● A.7 Seguridad relativa a los recursos humanos
 A.7.1 Antes del empleo
 A.7.1.1 Investigación de antecedentes
 A.7.1.2 Términos y condiciones del empleo
 A.7.2 Durante el empleo
 A.7.2.1 Responsabilidades de gestión
 A.7.2.2 Concienciación, educación y capacitación en segu-
ridad de la información
 A.7.2.3 Proceso disciplinario
 A.7.3 Finalización del empleo o cambio en el puesto de trabajo
 A.7.3.1 Responsabilidades ante la finalización o cambio
El propósito de esta sección es introducir los controles de seguridad a las

personas que trabajan para la organización (empleados y otras personas
que se contratan). Estos controles son muy importantes ya que estadísticas
a nivel mundial muestran que las personas que trabajan para las empresas
representan la mayor amenaza para la seguridad de la información.
152
Las formas más comunes de implementar estos controles de seguridad
son las siguientes:
● Documentar un procedimiento de gestión de recursos humanos,

aunque no es un documento obligatorio
● Firmar un contrato, con los empleados y demás contratistas, que

incluya cláusulas de seguridad de la información
● Concienciar regularmente a las personas en cuestiones de seguri-

dad, y llevar a cabo campañas de sensibilización continua
● Introducir un proceso disciplinario, para todos los empleados que

han cometido algún incumplimiento con respecto a la seguridad
de información
● artículo 8 Security Practices to Use in Your Employee Training
and Awareness Program
9.7 Gestión de activos (A.8)

● A.8 Gestión de activos
 A.8.1 Responsabilidad sobre los activos
 A.8.1.1 Inventario de activos
 A.8.1.2 Propiedad de los activos
 A.8.1.3 Uso aceptable de los activos
 A.8.1.4 Devolución de activos
 A.8.2 Clasificación de la información
 A.8.2.1 Clasificación de la información
 A.8.2.2 Etiquetado de la información
 A.8.2.3 Manipulado de la información
 A.8.3 Manipulación de los soportes
 A.8.3.1 Gestión de soportes extraíbles
 A.8.3.2 Eliminación de soportes
 A.8.3.3 Soportes físicos en tránsito
153
SEGURO & SIMPLE
La gestión de activos es importante para la empresa, debido al valor
que tienen los activos para la organización – por lo que necesitan ser
protegidos. Puesto que la información representa también un tipo de
activo, el estableciendo de reglas para la identificación de activos, el
uso aceptable y la clasificación de los activos, afecta directamente a la
Controles relacionados con la gestión de activos, incluyen:
●C
reación de un inventario de activos – este control está relacionado
con el análisis de riesgos, y como expliqué previamente en el capítu-
lo 7, el análisis de riesgos se lleva a cabo teniendo en consideración
los activos de la empresa. El inventario de activos puede ser docu-
mentado como parte de la documentación del análisis de riesgos.
●D
efinición de propietarios de los activos – son personas que son
responsables del mantenimiento de los activos, sin un sentido legal.
●U
so aceptable de activos – la empresa debe definir reglas sobre
cómo pueden usarse los activos, y escribir una política para este
propósito. Estas reglas pueden ser documentadas como un docu-
mento separado o como parte de otras políticas o directrices para
los empleados
●D
evolución de activos – todos los activos que son propiedad de la
empresa deben ser devueltos cuando se termina el contrato de tra-
bajo. Este control puede ser documentado como parte del proced-
imiento de recursos humanos si existe dicho procedimiento, o puede
ser incluido en el contrato, y documentado en alguna de las políticas.
Además esta sección también cuenta con controles que requieren la

definición de reglas para la clasificación de la información, junto con
reglas de etiquetado de la información, y el manejo de activos basado
en el nivel de clasificación.
El último grupo de controles de esta sección se refiere a la manipula-

ción de soportes, cubriendo procedimientos para la gestión de soportes
removibles, eliminación de soportes, y la transferencia de información
a través de soportes.
154
● artículo How to handle Asset register (Asset inventory) accor-
ding to ISO 27001
● artículo Risk owners vs. asset owners in ISO 27001:2013
● artículo Information classification according to ISO 27001
● artículo Secure equipment and media disposal according to ISO
27001
9.8 Control de acceso (A.9)

● A.9 Control de acceso
 A.9.1 Requisitos de negocio para el control de acceso
 A.9.1.1 Política de control de acceso
 A.9.1.2 Acceso a las redes y a los servicios de red
 A.9.2 Gestión de acceso de usuario
 A.9.2.1 Registro y baja de usuario
 A.9.2.2 Provisión de acceso de usuario
 A.9.2.3 Gestión de privilegios de acceso
 A.9.2.4 Gestión de la información secreta de autenticación
de los usuarios
 A.9.2.5 Revisión de los derechos de acceso de usuario
 A.9.2.6 Retirada o reasignación de los derechos de acceso
 A.9.3 Responsabilidades del usuario
 A.9.3.1 Uso de la información secreta de autenticación
 A.9.4 Control de acceso a sistemas y aplicaciones
 A.9.4.1 Restricción del acceso a la información
 A.9.4.2 Procedimientos seguros de inicio de sesión
 A.9.4.3 Sistema de gestión de contraseñas
 A.9.4.4 Uso de utilidades con privilegios del sistema
 A.9.4.5 Control de acceso al código fuente de los programas
Según la sección A.9, la Política de control de acceso debe ser documen-

tada, y debe estar basada en las necesidades del negocio, y de la seguri-
dad de la información de la empresa – por lo general cubre el acceso a los
sistemas de información, pero en algunos casos también cubre el acceso
155
SEGURO & SIMPLE
físico para asegurar las áreas. Básicamente esta Política de control de ac-
ceso debe contener las reglas que son definas por otros controles que se
mencionan en esta sección A.9 – aquí tiene algunos de estos controles:
● Sólo los usuarios autorizados deben tener acceso a la red y a los

servicios de red
● Cualquier derecho privilegiado tiene que ser asignado explícitamente
● Asignación de derechos de acceso a través de gestión de cuentas de

usuario / ID
● Uso de contraseñas u otro tipo de autenticación secreta
● Definición de provisión de derechos de acceso – por ejemplo tenien-

do un procedimiento que describa quién es responsable de iniciar la
apertura de nuevas cuentas de usuario, y que describa también la
asignación de acceso a estos nuevos usuarios, quién debe aprobarlo,
quién y cómo se abre la nueva cuenta de usuario, cómo ajustar los
derechos de usuario cuando la gente cambie su papel en la empresa
(como por ejemplo por promoción interna), o eliminarlos cuando
alguien abandona la empresa.
● Restricción y control del uso de utilidades con privilegios – por el

ejemplo, sólo el administrador de sistemas tendrá acceso a progra-
mas de sistemas con privilegios especiales
El control de acceso a la información, y a otros activos relevantes, es

crítico para la seguridad de la información. Con el control de acceso se
trata establecer que los empleados tengan acceso sólo a la información
y activos que necesitan para realizar sus tareas y responsabilidades. Este
enfoque reduce significativamente las posibilidades de daño no inten-
cionado y malicioso a la información.
● artículo How to handle access control according to ISO 27001
156
9.9 Criptografía (A.10)

● A.10 Criptografía
 A.10.1 Controles criptográficos
 A.10.1.2 Gestión de claves
La criptografía se refiere básicamente al cifrado de datos, o a la conver-

sión de datos electrónicos en otra forma, conocido habitualmente como
texto cifrado, que sólo puede ser entendido fácilmente por las partes
autorizadas. Por ejemplo, si desea enviar datos confidenciales a través de
correo electrónico, puede proteger la transferencia de los datos cifrándo-
los. Sin embargo, para que el destinatario pueda ser capaz de entender
los datos, necesita descifrarlo, para lo que necesitará una clave específica.
El Anexo A obliga a las empresas a definir una política sobre el uso de con-
troles criptográficos. Esta política debe considerar elementos tales como:
● Decisión de la dirección sobre qué información debería estar protegida

con controles criptográficos, y si los controles se utilizarán para la infor-
mación transferida mediante medios móviles o líneas de comunicación;
● El nivel requerido de protección debe ser identificado basado en el

análisis de riesgos – por ejemplo, el tipo de algoritmo de cifrado y las
herramientas que deben utilizarse;
● Decisión sobre lo que se hará internamente y para qué propósito se

contratará un proveedor externo de servicios criptográficos;
● Definición de responsabilidades para la implementación de la política

y la gestión de claves.
El propósito de esta política es maximizar los beneficios del uso de téc-

nicas criptográficas, y minimizar los riesgos, así como asegurar un uso
apropiado de los controles criptográficos.
Con respecto a la gestión de claves, la política también debería incluir

requisitos y responsabilidades para la gestión de las claves criptográ-
157
SEGURO & SIMPLE
ficas, empezando con su generación, la distribución a los empleados
pertinentes, y terminando con su eliminación y destrucción.
 ● artículo How to use the cryptography according to ISO 27001

control A.10
9.10 Seguridad física y del entorno (A.11)

● A.11 Seguridad física y del entorno
 A.11.1 Áreas seguras
 A.11.1.1 Perímetro de seguridad física
 A.11.1.2 Controles físicos de entrada
 A.11.1.3 Seguridad de oficinas, despachos y recursos
 A.11.1.4 Protección contra las amenazas externas y ambientales
 A.11.1.5 El trabajo en áreas seguras
 A.11.1.6 Áreas de carga y descarga
A.11.2 Seguridad de los equipos
 A.11.2.1 Emplazamiento y protección de equipos
 A.11.2.2 Instalaciones de suministro
 A.11.2.3 Seguridad del cableado
 A.11.2.4 Mantenimiento de los equipos
 A.11.2.5 Retirada de materiales propiedad de la empresa
 A.11.2.6 Seguridad de los equipos fuera de las instalaciones
 A.11.2.7 Reutilización o eliminación segura de equipos
 A.11.2.8 Equipo de usuario desatendido
 A.11.2.9 Política de puesto de trabajo despejado y pantalla limpia
La protección de áreas significa la prevención de accesos físicos no au-

torizados y de daños a las instalaciones de procesamiento de informa-
ción, estableciéndose controles para:
● Asegurar que no se permite el acceso público a sus oficinas e

instalaciones, y estableciendo diferentes salas para diferentes pro-
pósitos;
158
● Proteger a las personas, oficinas y equipamiento de amenazas ex-
ternas y ambientales, como por ejemplo incendios, inundaciones,
ataques malintencionados, etc.
● Controles físicos de entrada – tales como puertas bloqueadas con
llaves o tarjetas, recepción para los visitantes etc.
● Puntos de acceso para partes externas, como por ejemplo áreas de
carga y descarga que estarán separadas de las habitaciones donde
se guarda y se procesa la información, etc.
Asegurar el equipamiento significa prevenir la pérdida, daño o el com-
prometer los activos, a través de controles tales como:
●U
bicación adecuada del equipamiento – por ejemplo ubicando las
computadoras lejos de fuentes de agua, para evitar posibles daños
● P rotección del equipamiento contra fallos de electricidad – por
ejemplo utilizando SAIs y generadores
● P rotección de cables contra daños o intercepción – por ejemplo,
poniendo los cables en canaletas de cable cerradas, en lugar de
tenerlos repartidos por los suelos de la oficina.
●M
antenimiento regular del equipamiento, de acuerdo a las espe-
cificaciones del fabricante
● P rotección del equipamiento cuando sale fuera de las instalaciones
– no permitiendo la salida de las instalaciones sin autorización,
definiendo reglas para el uso de equipos fuera de las oficinas, etc.
●D
efinición de una política de escritorio limpio y pantalla despejada
– el usuario deberá cerrar sesión cuando no esté en la computado-
ra, y no debe estar permitido que existan documentos en formato
papel en el escritorio cuando el empleado no esté en su puesto
Esta sección se centra más en la implementación de controles técnicos,
que en documentar, sin embargo algunas empresas pueden aprovechar
para documentar una política de escritorio limpio y pantalla despejada,
y establecer procedimientos para trabajar en zonas seguras.
159
SEGURO & SIMPLE
Esta sección es muy importante porque cuando se habla de seguridad
de la información, las empresas tienden a poner demasiado énfasis en
la seguridad de TI, descuidando otros aspectos como la seguridad fí-
sica. Por ejemplo, existen casos en los que las computadoras tienen
contraseñas fuertes, pero luego se dejan en habitaciones sin vigilancia,
y sin control, a las que tienen acceso partes externas.
● artículo Physical security in ISO 27001: How to protect the secure
areas
● artículo How to protect against external and environmental threats
according to ISO 27001 A.11.1.4
● artículo How to implement equipment physical protection accor-
ding to ISO 27001 A.11.2 – Part 1
● artículo How to implement equipment physical protection accor-
ding to ISO 27001 A.11.2 – Part 2
● artículo Secure equipment and media disposal according to ISO
27001
● artículo Clear desk and clear screen policy – What does ISO 27001
require?
9.11 Seguridad de las operaciones (A.12)

● A.12 Seguridad de las operaciones
 A.12.1 Procedimientos y responsabilidades operacionales
 A.12.1.1 Documentación de procedimientos de las opera-
ciones
 A.12.1.2 Gestión de cambios
 A.12.1.3 Gestión de capacidades
 A.12.1.4 Separación de los recursos de desarrollo, prueba
y operación
● A.12.2 Protección contra el software malicioso (malware)
 A.12.2.1 Controles contra el código malicioso
● A.12.3 Copias de seguridad
 A.12.3.1 Copias de seguridad de la información
● A.12.4 Registros y supervisión
160
 A.12.4.1 Registro de eventos
 A.12.4.2 Protección de la información de registro
 A.12.4.3 Registros de administración y operación
 A.12.4.4 Sincronización del reloj
● A.12.5 Control del software en explotación
 A.12.5.1 Instalación del software en explotación
● A.12.6 Gestión de la vulnerabilidad técnica
 A.12.6.1 Gestión de las vulnerabilidades técnicas
 A.12.6.2 Restricción en la instalación de software
● A.12.7 Consideraciones sobre la auditoría de sistemas de información
 A.12.7.1 Controles de auditoría de sistemas de información
Esta sección se centra en cuestiones típicas se seguridad de TI - por su-

puesto, estos controles son importantes porque son cruciales para garan-
tizar el funcionamiento seguro de la infraestructura de TI de la empresa.
Entre los primeros controles se encuentra el de documentar los pro-
cedimientos operacionales. De acuerdo a este control, las empresas
deben documentar los procedimientos relacionados con la seguridad
operacional, así como otros controles que se mencionan en esta sec-
ción. Estos procedimientos deben estar disponibles para todas aquellas
personas que los necesiten en la compañía, que habitualmente son los
administradores de sistemas.
Otros controles que forman parte de A.12 son:
●G
estión de la capacidad – lo cual significa la monitorización del
uso de recursos en la organización, y la realización de previsiones
para los requerimientos de capacidad futuros
● Separación de entornos de desarrollo, pruebas y producción – lo
cual significa que el desarrollo y las pruebas de un nuevo software,
o un sistema, se hará por separado del entorno de producción de
la empresa, para evitar problemas y para disminuir los riesgos en
el entorno de producción.
●C
ontroles contra el malware – por ejemplo, instalación de soft-
ware de protección de malware, prohibición del uso de software
no autorizado, listas negras de sitios web, etc.
161
SEGURO & SIMPLE
● E stablecimiento de una política de copia de seguridad, implementán-
dola adecuadamente en los equipos, y realizando pruebas periódicas
de las copias. La política de copia de seguridad debe incluir la identifi-
cación de la información, el software y los sistemas que realizarán las
copias, la frecuencia de las copias de seguridad, el almacenamiento
y la protección de los soportes de copias de seguridad, etc.
● Registros y supervisión – lo cual significa que se pueden mantener
registros de varios eventos, que se revisen periódicamente, y que se
mantengan adecuadamente protegidos; también aplica a los registros
de las actividades de los operadores y los administradores de sistemas.
● I nstalación de software en sistemas de producción – lo cual sig-
nifica que las instalaciones deben ser realizadas solamente por ad-
ministradores de sistemas capacitados, se debe probar el software,
se deben seguir las reglas del proveedor, usar versiones soportadas
por el fabricante, tener planes de marcha atrás (rollback), etc.
●G
estión de vulnerabilidades técnicas – lo cual significa que se debe
asignar una persona responsable de las vulnerabilidades técnicas,
además todos los activos deben ser supervisados para detectar
posibles vulnerabilidades técnicas, y deberían adoptarse medidas
apropiadas para hacer frente a las vulnerabilidades basadas en su
criticidad y en el nivel de riesgo.
La gestión de cambios es también uno de los controles cubiertos por
esta sección, pero ya he explicado cómo las compañías deben co olar
los cambios en la sección 8.6.
● artículo How to manage changes in an ISMS according to ISO
27001 A.12.1.2
● artículo Implementing capacity management according to ISO
27001:2013 control A.12.1.3
● artículo Backup policy – How to determine backup frequency
● artículo Logging and monitoring according to ISO 27001 A.12.4
● artículo How to manage technical vulnerabilities according to ISO
27001 control A.12.6.1
● artículo How to use penetration testing for ISO 27001 A.12.6.1
162
● artículo Implementing restrictions on software installation using
ISO 27001 control A.12.6.2
9.12 Seguridad de las comunicaciones (A.13)

● A.13 Seguridad de las comunicaciones
 A.13.1 Gestión de la seguridad de redes
 A.13.1.1 Controles de red
 A.13.1.2 Seguridad de los servicios de red
 A.13.1.3 Segregación en redes
 A.13.2 Intercambio de información
 A.13.2.1 Políticas y procedimientos de intercambio de infor-
mación
 A.13.2.2 Acuerdos de intercambio de información
 A.13.2.3 Mensajería electrónica
 A.13.2.4 Acuerdos de confidencialidad o no revelación
La gestión de la seguridad de las comunicaciones incluye los siguientes

controles:
● Controles de red que asegurarán que la información, comunicada a

través de la red, esté protegida – por ejemplo, registro y seguimiento
de las acciones en la red, limitaciones de las conexiones a la red, au-
tenticación de los sistemas conectados a la red etc. El Anexo A no re-
quiere documentar este control, sin embargo con el fin de garantizar
la efectiva de los controles de red, se pueden documentar las respon-
sabilidades y los procedimientos para la gestión de los equipos de red.
● La seguridad de los servicios de red será gestionada definiendo

acuerdos de servicio de red con parámetros relevantes de seguri-
dad, y con requisitos tales como la implementación de firewalls, y
sistemas de detección de intrusiones, y monitorizando el desem-
peño de los proveedores de red. Este control debe ser documenta-
do a través de la firma de los acuerdos de servicios de red.
163
SEGURO & SIMPLE
● La segregación de las redes es uno de los métodos para la gestión
de su seguridad. Esto significa dividir la red en redes más pequeñas
independientes, que son más fáciles de administrar y proteger. Esta
división se puede basar en la criticidad de cada entorno (acceso pú-
blico, servidor, etc.), o también se puede basar en los departamen-
tos de la organización (por ejemplo alta dirección, departamento de
finanzas etc.) o en cualquier otra combinación conveniente para la
organización. ISO 27001 no requiere documentar este control.
El aspecto del intercambio de información incluye los siguientes controles:
● El intercambio de información puede ocurrir mediante diferentes
canales de comunicación (por ejemplo correo electrónico, herra-
mientas de mensajería instantánea, teléfonos, faxes etc.). Para este
propósito las empresas deben definir el uso aceptable de todas es-
tas herramientas de comunicación, qué tipo de información se debe
transferir y cómo se protegerá esta comunicación. Estas políticas y
procedimientos deben ser comunicados al personal pertinente.
● Acuerdos para el intercambio de información – en algunos casos
cuando la compañía intercambio información sensible con terceros,
se deben firmar acuerdos formales. Estos acuerdos pueden incluir
elementos tales como: normas para el etiquetado de la información,
uso de criptografía, definición de controles de acceso, definición de
responsabilidades para la gestión de incidentes de seguridad, etc.
●Mensajería electrónica – lo cual significa la protección de la infor-
mación involucrada en la mensajería electrónica – definiendo que
servicios públicos se pueden utilizar (por ejemplo redes sociales,
intercambio de archivos, etc.), utilizando firma electrónica, etc.
●A
cuerdos de confidencialidad y secreto profesional – una forma de
proteger datos sensibles de la empresa es utilizar herramientas le-
gales, a través de declaraciones de confidencialidad y acuerdos de
secreto profesional o no divulgación. Estos deben ser firmados por
empleados y terceros.
Esta sección es importante porque cubre controles para comunicar in-
formación dentro y fuera de la organización, lo cual es una actividad
164
esencial de cualquier organización, dada la era de la información en la
que nos encontramos hoy en día. La seguridad de las comunicaciones
también es crítica debido a que la confidencialidad, disponibilidad e
integridad de la información podría estar en peligro durante su tránsito.
● artículo Requirements to implement network segregation accor-
ding to ISO 27001 control A.13.1.3
9.13 Adquisición, desarrollo y mantenimiento de los

sistemas de información (A.14)
● A.14 Adquisición, desarrollo y mantenimiento de los sistemas de
información
 A.14.1 Requisitos de seguridad en sistemas de información
 A.14.1.1 Análisis de requisitos y especificaciones de seguri-
dad de la información
 A.14.1.2 Asegurar los servicios de aplicaciones en redes pú-
blicas
 A.14.1.3 Protección de las transacciones de servicios de
aplicaciones
 A.14.2 Seguridad en el desarrollo y en los procesos de soporte
 A.14.2.1 Política de desarrollo seguro
 A.14.2.2 Procedimiento de control de cambios en sistemas
 A.14.2.3 Revisión técnica de las aplicaciones tras efectuar
cambios en el sistema operativo
A .14.2.4 Restricciones a los cambios en los paquetes de sof-
tware
 A.14.2.5 Principios de ingeniería de sistemas seguros
 A.14.2.6 Entorno de desarrollo seguro
 A.14.2.7 Externalización del desarrollo de software
 A.14.2.8 Pruebas funcionales de seguridad de sistemas
 A.14.2.9 Pruebas de aceptación de sistemas
 A.14.3 Datos de prueba
 A.14.3.1 Protección de los datos de prueba
165
SEGURO & SIMPLE
Por supuesto, esta sección es principalmente importante para empresas
que desarrollan software, o sistemas de información en general, pero
también para todas las empresas que tienen que mantener sus sistemas
de información.
El propósito del primer conjunto de controles es garantizar la integración

de la seguridad en los nuevos sistemas de información que se van a imple-
mentar en la empresa, pero también para aquellos casos donde se man-
tienen los sistemas de información existentes. Estos controles incluyen:
● Identificación de requerimientos de seguridad de la información para

nuevos sistemas de información - lo cual significa que para todos
los nuevos sistemas deben de realizarse análisis apropiados sobre su
finalidad, tipo de información que será procesada, responsabilidades
de los usuarios, etc. Por ejemplo si su empresa decide apoyar los pro-
cesos financieros con un software, con el fin de elegir el software más
adecuado, la empresa debe identificar las necesidades y los requisitos
de seguridad. Digamos que parte de la información es confidencial
porque contiene datos de carácter personal, y para este propósito
es necesario un estricto control de acceso como autenticación, por
ejemplo a través de firmas o huellas digitales, pero también será ne-
cesario el cifrado de la información, porque parte de la información
pasará a través de las redes públicas a una agencia del gobierno.
● Pruebas de seguridad sobre los nuevos sistemas, para ver si satisfa-

cen los criterios predefinidos de aceptación de nuevos sistemas – por
ejemplo, se puede comprobar si el cifrado está funcionando bien, y si
es efectivo el control de acceso de huella digital.
●G
arantizar que la información involucrada en las transacciones de servi-
cios de aplicaciones es protegida cuando esta pasa por redes públicas,
para evitar transacciones incompletas, mal uso, modificación, etc. - por
ejemplo, debido a la criticidad de los datos que pasan a través de redes
públicas, usted puede decidir utilizar algoritmos de cifrado más fuertes.
Los controles para la seguridad en el desarrollo y soporte, son aplicables

para empresas que desarrollan software o sistemas de información en
general, y se incluyen los siguientes aspectos:
166
● E stablecer una política de desarrollo seguro – definiendo reglas para el
desarrollo de software y sistemas. El estándar no requiere específica-
mente que se documente esta política, sin embargo como se mencionó
anteriormente, en la mayoría de los casos cuando existen ciertas reglas
es bueno tenerlas documentadas. Puede tener estas reglas documen-
tadas como una política independiente, o como parte de otros docu-
mentos, dependiendo de las necesidades y preferencias de la empresa.
● E stablecer procedimientos para controlar los cambios en los sistemas

y en el software, a través de restricciones en los cambios, y revisión
de los cambios realizados. El estándar requiere que existan proced-
imientos formales de control cambios – vea también la sección 8.6
para más información sobre el control de cambios.
● E stablecer y documentar principios de ingeniería de sistemas seguros

– lo cual significa que la seguridad debe ser diseñada en los sistemas
de información, balanceando entre la necesidad de seguridad de la in-
formación y la accesibilidad. Para este propósito, los principios de inge-
niería se deben documentar, y deben ser aplicados a todos los sistemas
de información en el proceso de su desarrollo. El estándar no describe
cómo deben de escribirse estos principios (por ejemplo, no se mencio-
na como concepto el ciclo de vida para el desarrollo de sistemas), así
que usted debe consultar con su equipo de desarrollo de software, qué
tipo de seguridad es más apropiada para su proceso de desarrollo
● Pruebas de seguridad sobre el software y los sistemas recién desarrollados.
Los controles para la protección de los datos de prueba, implican el con-

trolar y proteger los datos utilizados en el proceso de pruebas, evitando el
uso de datos reales que contengan información personal o confidencial.
● mini caso de estudio en el capítulo 14: Aplicar principios de inge-
niería seguros en una empresa de desarrollo software.
● artículo How to set security requirements and test systems accor-
ding to ISO 27001
● artículo What are secure engineering principles in ISO 27001:2013
control A.14.2.5?
167
SEGURO & SIMPLE
9.14 Relación con proveedores (A.15)

● A.15 Relación con proveedores
 A.15.1 Seguridad en las relaciones con proveedores
 A.15.1.1 Política de seguridad de la información en las re-
laciones con los proveedores
 A.15.1.2 Requisitos de seguridad en contratos con terceros
 A.15.1.3 Cadena de suministro de tecnología de la infor-
mación y de las comunicaciones
A.15.2 Gestión de la provisión de servicios del proveedor
 A.15.2.1 Control y revisión de la provisión de servicios del
proveedor
 A.15.2.2 Gestión de cambios en la provisión del servicio
del proveedor
Los controles de relaciones con proveedores son importantes porque en los

tiempos que corren, los proveedores cada vez procesan y almacenan más
información, y la protección de dichos datos se está convirtiendo en un
problema cada vez más importante para la seguridad de la información.
Como se mencionó anteriormente, las empresas a las que usted externali-
za parte de sus operaciones, pueden ser consideradas como un proveedor.
El primer control definido en esta sección es definir y documentar una

política de seguridad de la información para las relaciones con provee-
dores, la cual debe incluir los procedimientos que debe aplicar la em-
presa, y los procedimientos que debe aplicar el proveedor:
● Identificar y documentar los tipos de proveedores – por ejemplo ser-

vicios de TI, servicios de consultoría, etc.
● Definir los tipos de acceso que pueden tener los proveedores a los
activos de su compañía, y la manera de monitorizar estos accesos
● Definir requerimientos de seguridad para todos los tipos de acceso

que los proveedores pueden tener
168
● Requisitos mínimos de seguridad de la información que deben ser
incluidos en los contratos con proveedores
El siguiente control define que los requerimientos de seguridad de la

información se deben documentar en acuerdos con los proveedores,
con el fin de definir claramente las obligaciones de seguridad de la
información de ambas partes. También se señala que estos acuerdos
deben incluir requisitos para abordar los riesgos relacionados con la
información y los servicios de tecnologías, tales como por ejemplo in-
ternet, hospedaje web, almacenamiento en la nube, etc.
Además, existen controles relacionados con la monitorización y la re-

visión de los servicios del proveedor, para asegurar que se cumplen los
niveles acordados de funcionamiento, y que se cumplen los requisitos
de seguridad de la información definidos en los acuerdos. Una forma
de monitorizar el servicio del proveedor, es exigirle que le proporcione
informes de servicio periódicos, para que pueda revisarlos y comprobar
si el nivel de su servicio es como se establece en el acuerdo. Por ejem-
plo, si el contrato con su proveedor de internet indica que tiene una
disponibilidad del 99,7% durante todo el mes, usted puede comprobar
a través de informes de servicio mensuales si la disponibilidad de inter-
net fue realmente de ese nivel o estuvo por debajo.
● artículo 6-step process for handling supplier security according to
ISO 27001
9.15 Gestión de incidentes de seguridad de la

información (A.16)
● A.16 Gestión de incidentes de seguridad de la información
 A.16.1 Gestión de incidentes de seguridad de la informa-
ción y mejoras
 A.16.1.1 Responsabilidades y procedimientos
 A.16.1.2 Notificación de los eventos de seguridad de la información
169
SEGURO & SIMPLE
 A.16.1.3 Notificación de puntos débiles de la seguridad
 A.16.1.4 Evaluación y decisión sobre los eventos de seguri-
A .16.1.5 Respuesta a incidentes de seguridad de la información
 A.16.1.6 Aprendizaje de los incidentes de seguridad de la
información
 A.16.1.7 Recopilación de evidencias
Antes de entrar en los detalles de los controles de esta sección, vamos a

ver lo que significa para el estándar los conceptos de debilidad, evento
e incidente:
●D
ebilidad se considera a un punto débil o un defecto en el sis-
tema de información y los servicios de la empresa. Por ejemplo
controles inadecuados para detener los ataques de hackers
● Evento es una ocurrencia identificada en un sistema de informa-

ción, servicio, o red, que indica una posible brecha de seguridad
de la información. Por ejemplo, un ataque sin éxito de un hacker.
● Incidente es uno, o varios, eventos no deseados o inesperados

que pueden comprometer la seguridad de la información (con-
fidencialidad, integridad o disponibilidad de la información). Por
ejemplo, un ataque de un hacker con éxito.
Como puede ver, la idea de la gestión de debilidades y eventos de seguri-

dad de la información es evitar que sucedan incidentes. Por ejemplo, si la
empresa es consciente de que tiene controles inadecuados para detener
los ataques de hackers, entonces puede implementar controles adiciona-
les para disminuir la posibilidad de un ataque hacker. Por otra parte, los
eventos también deben evaluarse para decidir si deberían ser clasificados
como incidentes, y si son necesarias acciones para lidiar con el evento.
El primer control de esta sección se refiere a definir y documentar respon-

sabilidades y procedimientos para una respuesta rápida y eficaz para la
seguridad de la información. El procedimiento de gestión de incidentes
170
de seguridad de la información debe incluir los siguientes aspectos que
se describen a través del resto de controles de esta sección del Anexo A:
● Definir responsabilidades para el reporte y la gestión de incidentes
●D
efinir un punto de contacto para reportar incidentes, eventos y
debilidades – esto podría ser una dirección de correo, o el teléfono
del CISO
● Definir cómo monitorizar, detectar y reportar incidentes y eventos
● Definir cómo registrar los incidentes y las actividades para el ma-

nejo de incidentes – por ejemplo utilizando una herramienta sof-
tware para la gestión de incidentes, o en el caso de pequeñas
empresas, utilizando una hoja Excel para el registro de incidentes
● Definir cómo responder a los incidentes – analizando, recopilando

evidencias, resolviendo el incidente
● Evaluar las debilidades y eventos reportados
● Priorizar y escalar los incidentes
● Aprender de los incidentes
La gestión de debilidades, eventos e incidentes es un aspecto crítico

de la seguridad de la información. Como se mencionó en un punto
anterior, los riesgos no pueden reducirse a cero, o no pueden evitarse
completamente, así que para tener un SGSI eficaz, es esencial buscar
continuamente formas de disminuir los riesgos y tratar eficazmente las
consecuencias cuando se materializa un riesgo.
● artículo How to handle incidents according to ISO 27001 A.16
● artículo Using ITIL to implement ISO 27001 incident management
171
SEGURO & SIMPLE
9.16 Aspectos de seguridad de la información para la

gestión de la continuidad del negocio (A.17)
● A.17 Aspectos de seguridad de la información para la gestión
de la continuidad del negocio
 A.17.1 Continuidad de la seguridad de la información
 A.17.1.1 Planificación de la continuidad de la seguridad de
la información
 A.17.1.2 Implementar la continuidad de la seguridad de la
información
 A.17.1.3 Verificación, revisión y evaluación de la continui-
dad de la seguridad de la información
 A.17.2 Redundancias
 A.17.2.1 Disponibilidad de los recursos de tratamiento de
la información
El propósito de esta sección es asegurar que la continuidad de la se-

guridad de la información es una parte integral del sistema de gestión
de continuidad de negocio de la empresa, donde la continuidad del
negocio se define como la capacidad de la organización para continuar
la entrega de los productos o servicios, al nivel predefinido como acep-
table, después de algún incidente destructivo. Los controles definidos
en esta sección se centran en garantizar que la seguridad de la informa-
ción es efectiva en una situación adversa, como por ejemplo durante
un desastre natural. Estos controles son importantes porque obligan
a las empresas a tener cuidado con la seguridad de la información en
casos de crisis, situaciones en las que las empresas generalmente se
centran sólo en conseguir de nuevo el entorno de producción.
ISO 22301 es el estándar que se centra en continuidad de negocio, y

puede ser usado de manera muy efectiva para la implementación de la
sección A.17, como se explica en la sección 13.8.
Aquí tiene una breve explicación de los controles incluidos en esta sec-
ción:
172
● Planificación de la continuidad de la seguridad de la información –
la organización debe identificar los requisitos de seguridad de la in-
formación para las situaciones en las que puede estar en una crisis,
o también en las que puede estar durante una interrupción. En los
casos en los que la empresa no tenga un sistema de gestión de con-
tinuidad de negocio, se puede asumir que los requisitos de seguridad
de la información durante la crisis, son los mismos que los que existen
durante las operaciones normales.
● Implementar la continuidad de la seguridad de la información – la

empresa debe documentar e implementar procedimientos y contro-
les para garantizar la continuidad de la seguridad de información,
formando un equipo de respuesta de emergencia, y definiendo sus
responsabilidades para mantener la seguridad de la información en
situaciones de emergencia, y documentando un plan de continuidad
de negocio donde se describan los detalles sobre el manejo de la se-
guridad de la información después de eventos disruptivos.
● Verificación, revisión y evaluación de la continuidad de la seguridad de

la información – lo cual significa ejecutar y probar los procedimientos
y controles implementados, incluyendo el plan de continuidad de ne-
gocio, para asegurar que son funcionales y eficaces. Esto significa que
la empresa debe simular una crisis, y probar si los controles proporcio-
narían realmente los efectos necesarios. Por ejemplo, la empresa debe
probar, en el caso de que las oficinas y la infraestructura de TI no estén
disponibles debido a algún desastre natural, si se tiene acceso a toda
la información relevante, como por ejemplo copias de seguridad de la
información que estén ubicadas físicamente en otra ubicación, etc.
● Redundancias – la empresa debe identificar los elementos de los siste-

mas de información que pueden no estar disponibles, u operacionales,
en una crisis, y se debe considerar el poder proporcionar sistemas de
información redundantes, como copia de seguridad, en situaciones de
emergencia. Por ejemplo, en caso de desastre natural, las oficinas de
la empresa pueden no ser accesibles. Para este propósito, la empresa
debe proporcionar otros locales de trabajo, que pueden ser oficinas
que la empresa tiene en otro lugar, espacios alquilados, o similar.
173
SEGURO & SIMPLE
● artículo How to implement business impact analysis (BIA) accor-
ding to ISO 22301
● artículo Business continuity plan: How to structure it according
to ISO 22301
● artículo How to perform business continuity exercising and tes-
ting according to ISO 22301
● artículo Understanding IT disaster recovery according to ISO
27031
9.17 Cumplimiento (A.18)

● A.18 Cumplimiento
 A.18.1 Cumplimiento de los requisitos legales y contractuales
 A.18.1.1 Identificación de la legislación aplicable y de los
requisitos contractuales
 A.18.1.2 Derechos de propiedad intelectual (DPI)
 A.18.1.3 Protección de los registros de la organización
 A.18.1.4 Protección y privacidad de la información de
carácter personal
 A.18.1.5 Regulación de los controles criptográficos
 A.18.2 Revisiones de la seguridad de la información
 A.18.2.1 Revisión independiente de la seguridad de la infor-
mación
A .18.2.2 Cumplimiento de las políticas y normas de seguridad
 A.18.2.3 Comprobación del cumplimiento técnico
El propósito de esta sección es garantizar que la seguridad de la infor-

mación está implementada y se mantiene según lo descrito en la docu-
mentación existente del SGSI de la empresa, y también tiene como pro-
pósito el ayudar a las empresas a evitar incumplimientos contractuales
y obligaciones legales relacionadas con la seguridad de la información.
Esta sección es importante porque si no se cumplen las reglas externas
e internas, la empresa puede llegar a tener grandes pérdidas.
174
En relación al cumplimiento legal y contractual, esta sección define los
siguientes controles:
● Identificación de la legislación aplicable y de los requisitos contrac-
tuales – la empresa debe identificar y documentar estos requisitos,
y mantenerlos al día con el fin de lograr el cumplimiento
● Se proporciona un enfoque de requisitos legales y contractuales en
materia de derechos de propiedad intelectual. Ejemplos relevantes
son el uso legal de software, la gestión de licencias de software,
etc. ISO 27001 no requiere que este control se documente, sin
embargo la empresa puede decidir escribir por ejemplo un proce-
dimiento de Derechos de propiedad intelectual.
● Protección de registros – además de las reglas internas para el con-
trol de información documentada, la empresa debe controlar los re-
gistros, de acuerdo a la legislación y los acuerdos contractuales. ISO
27001 no requiere se documente este control, pero generalmente
está documentado como parte del procedimiento, mencionado en
un punto anterior, para el control de documentos y registros.
Además, se proporciona un enfoque de legislación relativa a la protec-
ción de datos personales, y controles criptográficos, debido a su impor-
tancia para la seguridad de la información.
Esta sección también define un conjunto de controles que garantizarán
que la seguridad de la información se implementa según lo descrito en
la documentación del SGSI existente en la empresa. Este conjunto de
controles incluye lo siguiente:
● Revisión independiente de la seguridad de la información – esto
se refiere a las auditorías internas o a las auditorías de certificación
del SGSI, y deben llevarse a cabo por personas independientes en
intervalos planificados, o después de cambios significativos.
● Cumplimiento de las políticas y normas de seguridad – a diferencia
de las revisiones por dirección de alto nivel explicadas en la sección
10.4, este control requiere que la dirección revise el cumplimiento
a bajo nivel – con las políticas y normas relevantes.
175
SEGURO & SIMPLE
● Comprobación del cumplimiento técnico – se trata de una revisión
periódica de la conformidad técnica de los sistemas de información
con la documentación del SGSI y el estándar. Generalmente estas
revisiones se realizan utilizando software y herramientas automati-
zadas. Más comúnmente utilizadas para análisis de vulnerabilidades
y pruebas de penetración.
ISO 27001 no requiere documentos específicos para estos controles.
● white paper Privacy, cyber security, and ISO 27001 – How are
they related?
● Página web List of information security laws and regulations
● artículo Records management in ISO 27001 and ISO 22301

Resumiendo, para implementar los controles aplicables de manera ade-
cuada, debe hacer lo siguiente:
● Asegúrese de leer el Anexo A de la ISO 27001 un par de veces,

para conseguir una buena sensación de él
● Use la ISO 27002 para aprender más sobre los detalles de imple-
mentación
● Estructure la documentación de la manera más lógica para los

empleados
● Implemente sólo los controles que realmente necesita
¿Cree que su trabajo ha terminado una vez que ha implementado to-

dos los controles? Lamentablemente, esto no es así - ahora necesita
monitorizar y mejorar su seguridad de la información.
176
10
ASEGÚRESE DE QUE EL SGSI
FUNCIONA SEGÚN LO ESPERADO
Dado que el sistema de gestión de seguridad de la información consiste

en procesos, documentación, actividades, controles técnicos, personas,
etc. sin duda es un sistema muy dinámico. ¿Qué significa esto? Esto
significa que usted no puede esperar que las cosas sean iguales como
ahora, pero dentro de un año; tampoco se puede esperar que todo sea
igual dentro de tres meses.
Además, nunca debe perder el punto principal del SGSI – proteger la infor-
mación. Pero, ¿cómo sabe si está haciendo lo suficiente para hacer esto?
Esto es por lo que las fases “Check” y “Act” del ciclo PDCA, que men-
cioné en la sección 4.4, son tan importantes – le permiten monitorear
constantemente cómo está funcionando su SGSI, es decir, se trata de
saber si lo está haciendo bien o no, y qué debe corregir.
Como se dará cuenta en esta sección, la ISO 27001 (así como otros
estándares ISO de gestión) requiere varias actividades para este fin: me-
dición y monitorización, auditoría interna, revisión por dirección, accio-
nes correctivas y mejora continua. Vamos a verlas en detalle.
10.1 M
onitorizar, medir, analizar y evaluar el SGSI
(cláusula 9.1)
Propósito. Lo curioso es que esta es la cláusula con las que tienen más
problemas los profesionales de seguridad de la información. Y esto no
es tan extraño – la seguridad de la información siempre ha sido una
disciplina de la protección de la confidencialidad, integridad y disponi-
bilidad – ¿qué es medir?
177
SEGURO & SIMPLE
Bien, como mencioné en el capítulo 3, en algún momento, su dirección
le buscará y le preguntará si la inversión en ISO 27001 tiene sentido. Y
para demostrar que lo tiene, debe mostrarle números, es decir, tiene
que medir algo. Por supuesto, esto no es el único propósito de medir,
pero sin duda es muy importante
Con el fin de aclarar la terminología – el monitoreo se refiere a observar

y examinar, mientras que la medición se refiere a determinar el tamaño
o la cantidad de algo mediante el uso de valores concretos. Por ejemplo,
la monitorización de incidentes se refiere a revisar todos los incidentes
que han ocurrido, y la medición de los incidentes se refiere a determinar
el número de incidentes que se reportan diariamente. El análisis se refie-
re a examinar los resultados de la medición, por ejemplo, comparando
el número de incidentes diariamente, y la evaluación significa llegar a
conclusiones basadas en el análisis, por ejemplo si los análisis muestran
que el número de incidentes el lunes fue más alto que cualquier otro día,
entonces la empresa debe investigar esto con mayor detenimiento.
Entradas. Un pre-requisito crucial para la medición, son los objetivos – la

idea clave sobre la medición es saber lo cerca que está de cumplir ciertos
objetivos. Si no sabe cuales son los objetivos, entonces no tiene nada
que medir. Además, los objetivos tienen que ser medibles – si define un
objetivo simple como queremos conseguir la seguridad de la informa-
ción, será muy difícil medir si se consigue o n e c igue el objetivo. Vea
las secciones 5.6 y 8.1 de este libro para ejemplos de objetivos medibles.
Decisiones & opciones. Usted podría tener un sistema de medición

para los objetivos estratégicos (es decir, objetivos generales del SGSI) y
un sistema diferente para los objetivos tácticos (es decir, objetivos para
los controles, procesos, departamentos, etc.). En cualquier caso, una
vez que conozca sus objetivos, tiene que tomar las siguientes decisio-
nes para cada uno de los tipos de sus objetivos:
● Con qué frecuencia se realizará la medición. Los objetivos es-

tratégicos se podrían medir tal vez una vez al año, mientras que
podría medir sus objetivos tácticos después de cada incidente, o
después de que se haya realizado una determinada actividad.
178
Asegúrese de que el SGSI funciona según lo esperado
● Quién realizará la medición. Esto podría ser responsabilidad del CISO,
o si incluye su medición dentro de un sistema tipo cuadro de mando (si
tiene uno), entonces dicho sistema ya asigna responsabilidades.
●Q
ué método de medición será utilizado. Realmente, el método
de medición dependerá del objetivo en sí mismo. Por ejemplo, si su
objetivo es “Cumplir con la ley/Reglamento xyz del 31 de Diciembre
de 2018, usando la metodología ISO 27001”, entonces el método de
medición podría ser ver si el proyecto es completado dentro de ese
plazo; si su objetivo es “obtener al menos cinco nuevos clientes en los
próximos 12 meses debido a la certificación ISO 27001”, entonces
tiene que contar cuántos clientes adquiría en ese margen de tiempo.
●A
quién se comunicarán los resultados. Generalmente, los re-
sultados de los objetivos tácticos se reportarán al CISO, y al nivel
medio de la jerarquía ejecutiva, responsable de los respectivos de-
partamentos, mientras que los objetivos estratégicos normalmente
se reportarán a la alta dirección. Por lo general, la alta dirección revi-
sará los resultados en la revisión por dirección (vea la sección 10.4).
● Quién evaluará los resultados. Generalmente, las mismas perso-
nas a las que se envían los reportes, son las que los evalúan y estable-
cen conclusiones. Las empresas más grandes pueden tener analistas
que podrían analizar los resultados y realizar recomendaciones.
Documentación. Usted puede decidir si crear un documento separa-
do que defina completamente esta metodología de medición, o puede
dejarlo como un proceso sin documentar - pero en este caso, tiene que
asegurarse de que sea coherente. Como mínimo, debe definir las res-
ponsabilidades para la medición – si no tiene un documento separado
para este propósito, puede definir esas responsabilidades en su Política
de seguridad de la información.
Lo que debe documentar son los resultados de la monitorización y me-
dición – probablemente la mejor manera de documentarlos sea a través
de algún tipo de informe, ya sea manual o semi-automático.
Vea también este mini caso de estudio en el capítulo 14: Establecer ob-
jetivos de seguridad y mediciones en una compañía de servicios.
179
SEGURO & SIMPLE
 Consejo de documentación: (no obligatorio) Un documento que

describa el proceso de medición y la metodología – por ejemplo,
Proceso de medición. Las responsabilidades para le medición po-
drían documentarse, o bien a través del Proceso de medición, o bien
a través de la Política de seguridad de la información.
(obligatorio) Resultados de la medición y del proceso de monitoriza-

ción – diferentes tipos de reportes.
10.2 A
uditoría interna parte I:
Preparación (cláusula 9.2)
Propósito. A primera vista, la auditoría interna probablemente se vea
como un gasto excesivo. Sin embargo, las auditorías internas permiten
descubrir problemas (es decir, no conformidades) que de otra manera
podrían quedar ocultas, y que por tanto, podrían perjudicar a su nego-
cio. Vamos a ser realistas - es naturaleza humana cometer errores, por
lo que es imposible tener un sistema sin errores; sin embargo, es posi-
ble tener un sistema que se mejore a sí mismo, y que aprenda de sus
errores. Las auditorías internas son una parte crucial de este sistema.
Opciones. Existen varias opciones para realizar una auditoría interna:
a) C
ontratar a un auditor interno a tiempo completo. Esto es con-
veniente solamente para grandes organizaciones que tengan trabajo
suficiente para esta persona (algunos tipos de organizaciones – por
ejemplo, los bancos – están obligadas por ley a tener tales funciones).
b) Contratar auditores internos a tiempo parcial. Esta es la si-

tuación más común – las organizaciones utilizan a sus propios
empleados para llevar a cabo las auditorías internas, que las lle-
van a cabo cuando sea necesario (por ejemplo, un par de veces
al año), compatibilizándolo con su trabajo habitual. Una cosa
importante en lo que prestar atención: con el fin de evitar un
conflicto de intereses (los auditores no pueden auditar su propio
180
trabajo), deben existir al menos dos auditores internos, para que
uno pueda auditar el trabajo del otro.
c) Contratar un auditor interno independiente de la organi-
zación. Aunque esta persona no es un empleado de la organi-
zación, también se considera una auditoría interna ya que la au-
ditoria es realizada por la organización, según sus propias reglas.
Generalmente, esto se hace por una persona que es especialista
en este campo (consultor independiente o similar).
Otras opciones son las siguientes:
● Realizar una auditoría o una serie de auditorías durante el
año. Si es una empresa pequeña, una simple auditoría al año puede
ser suficiente; sin embargo, si es una empresa grande, quizás quiera
planear llevar a cabo una auditoría en un departamento en Enero,
otra auditoría en otro departamento en Febrero, etc.
● Usar las mismas reglas y el mismo auditor que para otros
estándares. Si ya ha implementado la ISO 9001, realmente puede
utilizar el mismo procedimiento de auditoría interna – no es nece-
sario crear un nuevo documento para ISO 27001. Además, el
mismo auditor puede realizar auditorías internas para todos estos
sistemas al mismo tiempo - si esta persona tiene conocimientos de
estos estándares, y tiene un conocimientos medio sobre TI, puede
estar perfectamente capacitado para hacer una auditoría interna
integrada, lo que puede suponer un ahorro de tiempo para todos.
● Escribir o no escribir un procedimiento de auditoría interna y
una lista de verificación. No es obligatorio tener un procedimiento
escrito que defina cómo se realiza la auditoría interna; sin embargo,
es ciertamente recomendable. Normalmente, los empleados no es-
tán muy familiarizados con las auditorías internas, por lo que es
bueno tener escritas algunas reglas básicas – a menos que, por
supuesto, la auditoría sea algo muy habitual y se realice a diario.
Ocurre algo similar con la lista de verificación de la auditoría interna
– no es obligatoria, pero sin duda es útil para los principiantes.
Entradas. La selección de las opciones anteriores depende, por su-
puesto, de si ya ha implementado ISO 9001 (u otro sistema de gestión
181
SEGURO & SIMPLE
ISO), y de qué perfil de auditor interno tiene. También debe estudiar la
legislación, porque algunas industrias (por ejemplo, la financiera) tie-
nen reglas especiales sobre las auditorías internas.
Decisiones. La alta dirección debe involucrarse aquí – desde la aprobación

del procedimiento y el nombramiento del auditor interno, hasta la aceptación
del programa de auditoría y la lectura del informe de auditoría interna. Estas
actividades no deben ser delegadas a niveles más bajos de la jerarquía, ya que
esto podría llevar al auditor interno a un conflicto de intereses, y además, la
información importante podría no encontrar su camino hacia la cúspide.
Y, lo más importante de todo, la alta dirección debe tomar una decisión
consciente sobre por qué aceptarán y apoyarán la auditoría interna
como algo que es útil para el negocio.
Documentación. Debe tener los siguientes documentos en relación a
su auditoría interna:
● P rocedimiento de auditoría interna – este procedimiento define las re-
glas básicas para realizar la auditoría – cómo seleccionar los auditores,
cómo se planifican las auditorías, los elementos para realizar la audito-
ría, actividades de seguimiento, y cómo informar sobre las auditorías.
● Programa de auditoría interna – aquí es donde se planifican las
auditorías anualmente, incluyendo criterios y alcance.
● Lista de verificación de la auditoría interna – esta lista de verifica-
ción ayuda al auditor a no olvidar nada durante la auditoría interna.
● Informe de auditoría interna – aquí es donde el auditor interno
reportará las no conformidades y otros hallazgos que detecte.
 Consejo de documentación: (obligatorio) Documentos denomina-
dos Informe de auditoría interna y Programa de auditoría interna; y
como resultado de la auditoría interna, tendrá que levantar Acciones
correctivas.
(no obligatorio) Procedimiento de auditoría interna y Lista de veri-

ficación de la auditoría interna – aunque no son obligatorios, real-
mente son muy recomendables.
182
10.3 A
uditoría interna parte II: Pasos en la auditoría &
preparación de la lista de verificación
Aquí tenemos malas noticias: no existe una lista de verificación universal
de auditoría interna que pueda encajar perfectamente en las necesida-
des de su empresa, porque cada empresa es muy diferente; pero la bue-
na noticia es: puede desarrollar una lista de verificación personalizada
muy fácilmente.
Pasos en la auditoría interna. Veamos qué pasos tiene que seguir
para realizar la auditoría, y cómo encajarlos con la lista de verificación:
1) Revisión de documentos. En este paso tiene que leer toda la
documentación de su Sistema de Gestión de Seguridad de la In-
formación (o la parte de su SGSI que quiere auditar) para de esta
manera: (1) familiarizarse con los procesos del SGSI, y (2) encon-
trar si existen no conformidades con respecto a la ISO 27001 en
la documentación.
2) C
rear la lista de verificación de auditoría. Básicamente, haga
una lista de verificación en paralelo a la revisión de documentos –
lea los requisitos específicos escritos en la documentación (políticas,
procedimientos y planes), y escríbalos para que pueda comprobar-
los en la auditoría principal. Por ejemplo, si la Política de copias
de seguridad requiere que se hagan copias cada 6 horas, entonces
tiene que indicarlo en su lista, para recordar que después tiene que
comprobar si realmente se realizó la copia de esta manera.
3) Planificar la auditoría principal. Dado que existirán muchas co-
sas que necesita comprobar, debe planificar qué departamentos o
lugares va a visitar y cuando – y su lista de comprobación le dará
una idea sobre dónde tiene que enfocarse más.
4) Realizar la auditoría principal. La auditoría principal, a diferen-
cia de la revisión documental, es muy práctica - tiene que cami-
nar alrededor de la compañía y hablar con los empleados, revisar
los ordenadores y otros equipos, observar la seguridad física, etc.
Una lista de verificación es crucial en este proceso – si no tie-
ne nada, puede estar seguro de que se olvidará de comprobar
183
SEGURO & SIMPLE
muchas cosas importantes; también, usted necesita tomar notas
detalladas de lo que encuentre.
5) Informe. Una vez que finalice la auditoría principal, tiene que re-
sumir todas las no conformidades detectadas, y escribir un informe
de auditoría interna – por supuesto, sin la lista de verificación y las
notas detalladas, no será capaz de escribir un informe preciso. Ba-
sándose en este informe, usted, o alguien más, tendrá que abrir ac-
ciones correctivas según el Procedimiento de acciones correctivas.
6) S
eguimiento. En la mayoría de los casos, el auditor interno será uno
de los que comprueben si están cerradas todas las acciones correcti-
vas planteadas durante la auditoría interna – de nuevo, aquí su lista de
verificación y sus notas pueden ser muy útiles para recordar las razo-
nes por las que levantó una no conformidad. Sólo después de que se
cierren las no conformidades, se acaba el trabajo del auditor interno.
Haga su lista de verificación útil para principiantes. Por lo tanto,
el desarrollo de su lista de verificación dependerá principalmente de los
requisitos específicos de sus políticas y procedimientos.
Pero si usted es nuevo en este mundo ISO, puede también agregar a
su lista algunos requisitos básicos del estándar ISO 27001 para que
se sienta más cómodo cuando empiece con su primera auditoría. En
primer lugar, tiene que adquirir el estándar; entonces, la técnica es bas-
tante simple - tiene que leer el estándar cláusula por cláusula, y escribir
notas en su lista de verificación sobre lo que tiene que buscar.
Después de eso, usted necesita leer todas las políticas del SGSI, proce-
dimientos y planes, y anotar los detalles que desea comprobar durante
la auditoría, como se mencionó anteriormente en el paso 2).
Qué incluir en su lista de verificación. Normalmente, la lista de veri-
ficación para la auditoría interna contendrá 4 columnas:
●R
eferencias – por ejemplo, cláusula del estándar, o número de
sección de una política, etc.
●Q
ué buscar – aquí es donde escribe lo que buscará durante la audi-
toría principal – con quién hablará, qué preguntas realizará, qué regis-
tros buscará, qué instalaciones visitará, qué equipamiento revisará, etc.
184
● C
umplimiento – esta columna se rellena durante la auditoría
principal, y es el lugar donde puede indicar si la empresa cumple
con cada requerimiento. En la mayoría de los casos podrá comple-
tar esta columna con un Sí o un No, aunque algunas veces podrá
ser también un No aplica o un Parcialmente.
●H
allazgos– Esta es la columna donde se escribe lo que ha encon-
trado durante la auditoría principal – nombres de las personas con
las que ha hablado, cosas que le dijeron, ID y el contenido de los
registros que examinó, descripción de las instalaciones que visitó,
observaciones sobre el equipo que usted supervisó, etc.
Aquí tiene un ejemplo de una lista de verificación para la auditoría
interna, centrado en la cláusula 4.2 de la ISO 27001 (Entendiendo las
necesidades y expectativas de las partes interesadas); los datos com-
pletados en las columna 3a y 4a sólo son un ejemplo de lo que puede
escribir un auditor interno durante la auditoría principal.
Referen- Cumpli-
Qué buscar Hallazgo
cia miento
ISO La empresa ha identificado
¿La organización
27001 todas las partes interesadas
determina las Sí
cláusula en el documento “Lista de
partes interesadas?
4.2 partes interesadas”.
ISO ¿Existe la lista de Sólo se han identificado las
27001 todos los requisitos Parcial- leyes y regulaciones, no se
cláusula de las partes mente han identificado los requeri-
4.2 interesadas? mientos de socios y clientes.
Figura 11: Ejemplo de lista de verificación para la auditoría interna
No tenga miedo. Como puede ver, no es difícil realizar la auditoría

interna – es bastante sencillo: deberá seguir lo que se requiere en el
estándar, y en la documentación del SGSI, y averiguar si los empleados
cumplen con las reglas. Si ha preparado su lista de verificación para la
auditoría interna adecuadamente, la tarea será mucho más fácil.
185
SEGURO & SIMPLE
 Herramienta gratuita: En este curso gratuito online aprenderá más

sobre los detalles de la auditoría interna: ISO 27001 Internal Auditor
Course.
10.4 Revisión por dirección que tenga sentido

(cláusula 9.3)
Propósito. Esta también es una de las tareas que se perciben como di-
fíciles de entender. Pero el punto es – la revisión por dirección es donde
el estándar le solicita a la alta dirección participar activamente en las
decisiones que tienen un gran impacto en el SGSI.
Así, por ejemplo, la seguridad de la información puede necesitar un pre-

supuesto más grande, o cambiar los objetivos estratégicos de su SGSI –
todas estas cuestiones requieren decisiones desde arriba. Y la revisión por
dirección es exactamente el lugar para tomar tales decisiones. Se puede
considerar esta revisión por dirección como una reunión ordinaria de sus
altos ejecutivos con un tema en la agenda: la seguridad de la información.
Opciones & documentación. Aquí tiene varias opciones entre las que
decidir:
● F recuencia. El mínimo para realizar la revisión por dirección es

una vez al año, aunque se puede realizar con más frecuencia si
ocurre cualquier cambio importante que pueda influir en la segu-
ridad de la información (por ejemplo, se presenta un nuevo cliente
que tiene peticiones muy particulares con respecto a la separación
de sus datos en la nube). Sin embargo, se podría hacer más a
menudo (por ejemplo, de manera trimestral o mensual), en el caso
de que la dirección quiera participar más activamente en cuestio-
nes más operativas con respecto a la seguridad de la información.
● F usión con otras revisiones por dirección. Si usted ha imple-

mentado ISO 22301, ISO 9001, u otro estándar similar, puede estar
tentado a realizar todas las revisiones por dirección juntas; sin em-
bargo, no le recomiendo esto – la seguridad de la información es un
tema bastante grande y necesita 30 o más minutos de atención de
186
la alta dirección. Podría realizar todas las revisiones por dirección el
mismo día, pero de manera secuencial, no al mismo tiempo.
●D
ónde documentar los resultados. En la mayoría de los casos, se
harán simples minutas de reunión; sin embargo, algunas grandes
corporaciones requieren realizar procedimientos formales, junto
con decisiones formales.
●
Cómo
comunicar los resultados. La compañía puede enviar
una notificación por correo electrónico a todos los empleados y
terceras partes que correspondan, organizar una reunión, o algo
similar.
●Q
uién preparará los materiales. Puesto que existe una gran
cantidad de información de entrada que la dirección debe con-
siderar en la reunión, alguien tiene que preparar materiales para
tratar estas entradas - generalmente se encargará el CISO; sin em-
bargo, en grandes empresas estos materiales podrían ser prepara-
dos por varios jefes de departamento.
Entradas. El estándar require a la alta dirección revisar los siguientes as-
pectos:
● Estado de las acciones desde anteriores revisiones por dirección –
por ejemplo, si en la última revisión por dirección se tomó la deci-
sión de entrenar 3 auditores internos más para poder realizar más
auditorías internas a lo largo del año, la dirección debe comprobar
si se implementó esta acción, y cuáles son los resultados.
● Información sobre el análisis de acciones correctivas, la monitoriza-
ción y los resultados de las mediciones, los resultados de auditorías,
y el cumplimiento de los objetivos de seguridad de la información
– por ejemplo se deberían revisar las mediciones de los objetivos de
seguridad, comprobar si los objetivos se cumplen, y definir nuevos
objetivos para el siguiente período. En caso de no cumplir los obje-
tivos, se deberían identificar las cuestiones y las razones.
● Comentarios provenientes de partes interesadas – por ejemplo se
deberían revisar y discutir posibles quejas del cliente relacionadas
con la seguridad de la información.
187
SEGURO & SIMPLE
● Resultados del análisis de riesgos y el estado del plan de tratamien-
to de riesgos – comprobar si se han implementado los controles en
el plan de tratamiento de riesgos, y si no se han implementado, se
deberían identificar las razones.
● Oportunidades para la mejora continua del SGSI – basándose en
todas las discusiones de la dirección, se deben identificar oportu-
nidades de mejora para el SGSI, por ejemplo la automatización del
proceso de gestión de incidencias mediante la instalación de un
software de gestión de incidencias.
Decisiones. Sus ejecutivos deben tomar las siguientes decisiones en la

revisión por dirección: Decidir si el SGSI ha cumplido sus objetivos, qué
mejoras son necesarias, aprobación de los recursos necesarios, etc.
 Consejo de documentación: (obligatorio) Un documento denomi-
nado Minutas revisión por dirección o un registro similar.
10.5 U
so práctico de las no conformidades y acciones
correctivas (cláusula 10.1)
Propósito. Básicamente, cualquier empresa que intente sobrevivir en el
mercado actual está haciendo mejoras constantemente – desarrollando
nuevos productos, resolviendo problemas de los productos y servicios
existentes, disminuyendo costes, etc., de lo contrario, no estarían en el
negocio mas.
Y todas estas cosas son, de hecho, acciones correctivas, aunque las em-
presas probablemente no pensarán así. ISO 27001 (y otros estándares
ISO de gestión) requieren simplemente realizar acciones correctivas de
una manera sistemática – lo que permite conocer dónde se reportarán
exactamente los problemas (es decir las no conformidades, en termino-
logía ISO), quién debe revisarlos y tomar una decisión sobre cómo resol-
verlos, quién es responsable de eliminarlos, etc. Y lo mejor de todo – en
un sistema transparente como este, todos pueden ver los problemas
que existen (no se puede ocultar nada), cuándo y cómo se resolverán
esos problemas, y quién es responsable de estos problemas.
188
Entradas. Cualquier persona en la empresa puede levantar una acción co-
rrectiva, y lo mismo aplica a los socios y proveedores que tengan un papel
en su SGSI. Una acción correctiva se puede levantar no sólo debido a
un informe de auditoría interna, también porque alguien pensó en una
mejor manera de escribir la documentación, o por ejemplo, pensó en
disminuir los costes de su análisis de vulnerabilidades. Las acciones co-
rrectivas también pueden exigir grandes cambios, por ejemplo, la alta
dirección puede concluir que el SGSI no alcanzó sus objetivos, y quiere
revisar el concepto completo de la seguridad de la información.
Documentación. Debe tener los siguientes documentos con respecto
a sus acciones correctivas:
● P rocedimiento de acciones correctivas – Este procedimiento define
las reglas básicas para resolver las acciones correctivas – cómo le-
vantarlas, dónde se documentan, quién tiene que tomar las deci-
siones, cómo controlar su ejecución, etc.
●A
cciones correctivas – Estos son los registros de no conformidades,
decisiones y actividades para resolverlas.
Opciones. Aquí tiene las opciones para sus acciones correctivas:
●D
ónde documentarlas. En numerosas ocasiones he visto empre-
sas que usan un diseño de formulario en papel para las acciones
correctivas (especialmente los que implementan la ISO 9001). ¿El
resultado? No se utiliza porque no es nada práctico, y además, no
se sabe dónde encontrarlos. (Por supuesto, siempre se rellenan un
par de estos formularios antes de venir el auditor de certificación).
Una solución mucho mejor es usar alguna herramienta tipo help
desk (o incluso de gestión de tareas), que probablemente ya exista
en su empresa, y sus empleados la estén usando a diario – sólo
tiene que añadir otra categoría de acciones correctivas, y básica-
mente, esta solución será práctica y cumplirá con ISO 27001.
● F usionar las acciones correctivas con otros sistemas de ges-
tión. Esto definitivamente es recomendable – no necesita separar
bases de datos (o formularios) para, por ejemplo, ISO 9001 e ISO
27001. Utilice el mismo procedimiento, el mismo sistema, la mis-
ma base de datos – por supuesto, la naturaleza de las no confor-
189
SEGURO & SIMPLE
midades y acciones correctivas será diferente, pero esto no impide
que unifique el sistema.
●E
scribir o no escribir un procedimiento. No es obligatorio es-
cribir un procedimiento de acciones correctivas; sin embargo, se
recomienda. Normalmente, los empleados no están familiarizados
con algo que no utilizan todos los días, por lo que podría tener
sentido escribir estas reglas – a menos que, por supuesto, sea un
proceso que funciona perfectamente en su empresa, en cuyo caso
no necesita dicho documento.
Decisiones. ISO 27001 requiere a las empresas realizar las siguientes
acciones cuando se producen no conformidades:
●C
ontrolar y corregir la no conformidad, y tratar con las consecuen-
cias – por ejemplo en el caso que la no conformidad sea que la audi-
toría interna la han realizado auditores inexpertos; la empresa debe
entrenar auditores internos, y tratar con los riesgos que podrían ha-
ber ocurrido como resultado de la auditoría interna llevada a cabo
de manera inadecuada.
●D
ecidir si eliminar la causa de la no conformidad para prevenir su re-
currencia – si nos referimos al mismo ejemplo, dado que la auditoría
interna es muy importante para la seguridad de la información, la
empresa debe asegurarse de que esta no conformidad no volverá a
ocurrir en el futuro. Si, por ejemplo, la causa de la no conformidad
fue la falta de una persona responsable para el proceso de auditoría
interna, la empresa debe asignar esta responsabilidad a una persona
para evitar que esto ocurra de nuevo.
●D
ecidir quién va a implementar las acciones – por ejemplo, realizar
una nueva auditoría interna con auditores recientemente capacitados.
● Revisar la eficacia de las acciones correctivas llevadas a cabo – por
ejemplo, después de un período determinado, se debe comprobar
si se ha realizado la nueva auditoría con los auditores capacitados.
● Si es necesario, realizar cambios en el SGSI – por ejemplo do-
cumentar un procedimiento de auditoría interna (aunque no es
requerido por el estándar ISO 27001), donde se expliquen las res-
190
ponsabilidades de la persona encargada de la auditoría interna, y
donde se indiquen claramente las necesidades de formación de
los auditores internos.
 Consejo de documentación: (obligatorio) Registros de acciones co-

rrectivas.
(no obligatorio) Un procedimiento denominado Procedimiento de

acciones correctivas.
10.6 Mejora constante del SGSI (cláusula 10.2)

Todo cambia; y estos cambios influyen en la seguridad de la informa-
ción de la empresa: los riesgos cambian, el nivel de riesgos cambia, y
como consecuencia de esto, la efectividad de los controles cambia. No
hay que olvidar que los estándares también cambian. Hubo una nueva
versión del estándar ISO 27001, publicada en 2013, que tuvo cambios
significativos con respecto a la versión anterior, publicada en 2005.
Todo esto lleva a la sencilla conclusión de que el SGSI debe cambiar tam-
bién, para de esta manera reflejar los cambios en el entorno, responder a
las nuevas amenazas y para así aprovechar nuevas oportunidades.
Las oportunidades de mejora pueden variar dependiendo del tipo de em-
presa y de la madurez del SGSI – aquí tiene algunos ejemplos de iniciativas
de mejora: implementar herramientas software que apoyen algunas de
las actividades de seguridad de información, documentar nuevos procedi-
mientos para algunas actividades, introducir nuevos métodos de sensibili-
zación en la empresa, etc.
Una manera de asegurar una efectiva mejora continua, es definir los ele-
mentos del proceso de mejora. Estos elementos podrían ser documentados
en una política o un procedimiento, aunque el estándar no requiere dicho
documento. Los siguientes aspectos pueden ser relevantes para esta política:
● Definir quién es el responsable de planificar, gestionar y coordinar
las actividades de mejora
● Comunicar que todos los empleados pueden contribuir a la mejo-
ra continua del SGSI
191
SEGURO & SIMPLE
● Definir formas para registrar toda la información relevante relacio-
nada con las mejoras
● Implementar la mejora como un cambio, documentando los cam-
bios, las razones detrás de los cambios y los resultados esperados,
y revisando la efectividad de los cambios
Por último, me gustaría señalar que toda mejora requiere cambios en el
SGSI, sin embargo no todos los cambios resultan en mejoras - por ello,
la mejora es un proceso continuo.
 Consejo de documentación: (no obligatorio) Un documento llama-
do Política de mejora.

Para mantener y mejorar su SGSI, asegúrese de que hace lo siguiente:
● Establece objetivos medibles, y los mide sistemáticamente
● Realiza una auditoría interna adecuadamente – esto le ayudará a
detectar los mayores problemas en su SGSI
● Asegúrese de que su auditor interno es competente para el traba-
jo que va a realizar
● Haga la revisión por dirección adecuadamente – pregunte a los
ejecutivos para ver si realmente intentan entender toda la infor-
mación de entrada, y llegan a las decisiones más cruciales
● Cree un sistema de registro de acciones correctivas que sea fácil de
usar
● Incorpore el pensamiento de la mejora continua en la cultura de
su empresa
Finalmente, lo ha hecho – ¡ha finalizado la implementación de su SGSI!

Ahora vamos a ver cómo preparar su compañía para la certificación.
192
11
ASEGURAR QUE SU COMPAÑÍA
PASA LA CERTIFICACIÓN
Sinceramente, nunca conocí a alguien que disfrute con la certificación.

En la mayoría de los casos, todo el mundo considera que es un mal
necesario, y odia el día en el que llega el auditor. (O se pone enfermo
ese día).
Pero no tiene que ser así – usted puede conseguir algo positivo además
del certificado - como le explicaré más adelante en este capítulo, los
auditores de certificación son gente experimentada, con una visión per-
fecta sobre buenas prácticas, y usted puede aprender mucho de ellos.
Pero debe de enfocarlo de la manera correcta.
11.1 ¿Realmente necesita el certificado?

Antes de decidir si su empresa debería ir a por la certificación, tiene que
hacerse una pregunta importante: ¿realmente lo necesita?
Debo decirle que hay muchas organizaciones que han implementado el

estándar, y que luego no han ido a por la certificación - un claro ejemplo
son los bancos y otras instituciones financieras. Existen regulaciones en la
mayoría de los países que exigen que este tipo de entidades tengan que
aplicar procedimientos de seguridad de la información muy estrictos, y
la mayoría de estas entidades lo hacen implementando ISO 27001. Pero,
muy pocos de ellos lo certifican – principalmente porque llegan a la con-
clusión de que no existe una razón de negocio para hacerlo.
Y esto es exactamente lo que tiene que hacer – considere cuidadosa-

mente si necesita el certificado. Aquí tiene potenciales razones por las
que puede encontrar útil la certificación (algunas de estas razones son
diferentes de las listadas en la sección 3.1):
193
SEGURO & SIMPLE
1) Marketing. Puede utilizar el certificado para conseguir nuevos clien-
tes (debido a, por ejemplo, ofertas), o permanecer en el negocio (por
ejemplo, todos sus competidores tienen ya el certificado).
2) Cumplimiento. En raras ocasiones, algunas regulaciones requerirán

implementar ISO 27001, pero también pueden existir casos en los
que firme contratos con clientes que le obliguen a implementar la
seguridad de la información conforme a ISO 27001. Y en lugar de
tener a los auditores de cada uno de sus clientes para verificar si ha
cumplido el contrato, el auditor de certificación hará el trabajo, y
luego podrá mostrar el certificado a todos los interesados.
3) Presión interna. En algunas empresas, este tipo de proyectos no

terminará nunca a menos que exista una fuerte presión – por ejemp-
lo, un plazo claro. Por lo tanto, si acuerda una fecha fija con la enti-
dad certificadora para la auditoría de certificación, su dirección y sus
empleados tendrán una sensación mayor de urgencia para terminar
el proyecto.
4) Entradas objetivas. Si usted quiere implementar la seguridad de la in-

formación de la mejor manera posible, es bueno llamar a personas con
mucha experiencia y que sepan cómo pueden emplear en su empresa
las mejores prácticas de la industria. Los auditores de certificación serán
mucho más felices con alguien que les facilite las cosas, y los auditores
proporcionarán información sobre lo que se podría mejorar.
Si no le encaja ninguno de los puntos anteriores, su compañía proba-

blemente no necesite el certificado.
11.2 Certificación vs. registro vs. acreditación

Antes de movernos con más profundidad en el tema de la certificación,
vamos a aclarar primero algunas cosas básicas.
Cómo funciona la certificación de una compañía. En primer lugar, las

normas ISO son publicadas por la Organización Internacional de Norma-
lización: es un organismo internacional fundado por gobiernos de todo
194
Asegurar que su compañía pasa la certificación
el mundo. Su propósito es publicar estándares, como una forma de en-
tregar conocimiento y mejores prácticas – en este momento, existen pu-
blicados casi 20.000 estándares en total, y son reconocidos en cada país.
Los estándares de gestión ISO son sólo una parte de estos 20.000 es-
tándares, que fueron creados principalmente como una ayuda para las
empresas para mejorar sus operaciones en ciertas áreas (por ejemplo,
ISO 9001:2015 para la gestión de calidad, ISO 22301 para la gestión
de la continuidad del negocio, etc.), es por ello que la mayor parte de
lo que se habla acerca de estos estándares está relacionado con las em-
presas y su registro, certificación y acreditación.
Certificación vs. registro. Cuando quiera decir que una empresa ha

implementado un estándar (por ejemplo, un Sistema de Gestión de
Seguridad de la Información según ISO 27001), ha completado con
éxito la auditoría de certificación, y la entidad certificadora ha emitido
el certificado, podría decir que ha obtenido el registro o la certificación.
En Norteamérica, el término “registro” es más comúnmente utilizado,

mientras que en el resto del mundo generalmente se denomina “certi-
ficación.” ¿Por lo tanto, hay alguna diferencia? Técnicamente, sí; pero
esencialmente, no.
La certificación es cuando una entidad certificadora emite un certifica-

do que demuestra que una empresa cumple con un estándar; el regis-
tro es cuando este certificado está registrado en la entidad certificado-
ra. Así que, básicamente, se trata de lo mismo: una empresa tiene un
certificado que es reconocido formalmente.
Por cierto, la Organización Internacional de Normalización recomienda

el uso del término “certificación”, así que usaré este término de aquí
en adelante.
Entidad certificadora vs. registrador. Esta es la diferencia de termi-

nología que surge directamente de la utilización de los términos de la
certificación/registro - en Norteamérica las personas suelen utilizar el
término registradores, mientras que en el resto del mundo se denomi-
nan entidades certificadoras.
195
SEGURO & SIMPLE
Pero, de nuevo, es lo mismo - son aquellas instituciones que realizan las
auditorías de certificación y expiden los certificados. Aquí, también, la
ISO recomienda utilizar el término “entidades certificadoras”.
Acreditación vs. certificación. Entonces, ¿Qué es la acreditación? Para

que las entidades certificadoras puedan realizar las auditorías de certifi-
cación, y puedan emitir los certificados, necesitan obtener una licencia - y
esta licencia se llama “acreditación”. Por lo tanto, las entidades certifi-
cadoras tienen que conseguir la acreditación, mientras que las empresas
tienen que conseguir la certificación. (La entidad certificadora tiene que
cumplir con el estándar ISO 17021, si quiere acreditarse para poder cer-
tificar sistemas de gestión.)
Generalmente sólo hay una entidad acreditadora por cada país (por
ejemplo, UKAS para el Reino Unido), mientras que existen varias enti-
dades certificadoras en cada país – desde pequeñas entidades certifica-
doras locales, hasta grandes corporaciones multinacionales como SGS,
BSI, Bureau Veritas, DNV, etc.
Lo bueno de las entidades acreditadoras es que suelen publicar la lista

de entidades certificadoras acreditadas en sus respectivos países – vea
este artículo lista de entidades certificadoras de Reino Unido, y este
otro lista de entidades certificadoras de Estados Unidos.
Por cierto, las entidades acreditadoras también deben cumplir con un

estándar - este es el ISO 17011, un estándar que define el proceso de
acreditación.
Certificación para personas individuales. Todo lo mencionado an-

teriormente es válido para la certificación de empresas – si usted quiere
ir a por una certificación personal, las cosas son un poco diferentes. Se
han desarrollado muchas sesiones de concienciación de estándares ISO
para ayudarle a implementar un estándar en una empresa, o a auditar-
lo. Es también por esto por lo que existen certificaciones y acreditacio-
nes relacionadas con esta industria de la capacitación. (Vea un listado
de cursos disponibles en la sección 12.1.)
196
Con respecto a la acreditación, hay un patrón similar a como se descri-
bió anteriormente - si una institución quiere proporcionar certificados
de concienciación, debe ser acreditado por una entidad acreditadora, y
en este caso, esta institución tiene que cumplir con ISO 17024.
Estas son algunas de las instituciones más populares de formación acre-

ditada: PECB, IRCA, Exemplar Global (antes RABQSA), etc.
Certificación personal vs. Certificación académica. En la mayoría

de los casos, las entidades de formación acreditadas no entrega los
cursos directamente a los estudiantes; sino que por el contrario, tienen
una red de socios – proveedores de formación – que realizan los cursos
bajo su licencia y supervisión.
Esta relación entre las instituciones acreditadas y los proveedores de

formación básicamente funciona de dos maneras: (a) los proveedores
de formación usan los cursos desarrollados por las instituciones acre-
ditadas, y la institución acreditada emite certificados directamente a
los estudiantes, o (b) la organización de formación desarrolla su propio
curso y una institución acreditada certifica este curso – en este caso, es
común que la organización de formación expida un certificado a sus
estudiantes , con la aprobación de la institución acreditada.
Existen numerosas organizaciones de formación en todo el mundo –

desde entidades certificadoras, que también ofrecen la certificación de
organizaciones, hasta pequeños proveedores especializados en cursos
en línea.
Cabe mencionar que la certificación de cursos es obligatoria para los

proveedores de formación que ofrecen cursos como el de Auditor Lí-
der (o Auditor Jefe), porque esta es la única manera de obtener el re-
conocimiento de entidades certificadoras que contratan auditores. Sin
embargo, para otros cursos más cortos, los proveedores de formación
a menudo eligen no certificar sus cursos porque en este caso el reco-
nocimiento no es importante, y consideran que su marca es suficiente
garantía de la calidad del curso.
197
SEGURO & SIMPLE
11.3 Últimos preparativos antes de la certificación

Trabajó en la implementación del estándar ISO 27001 durante varios
meses, trató de averiguar cómo hacerlo más fácil leyendo este libro,
convenció no sólo a sus colegas, también a su dirección, de que la se-
guridad de la información es muy útil, pero todavía tiene un problema:
está sesgado.
Este proyecto es su hijo, y usted puede estar inclinado a creer que los
documentos, y todo lo demás que ha preparado, está impecable. Pero
esto no es cierto - siempre le quedará algo en el aire, incluso podría
haber entendido algún requisito de forma equivocada, lo que le podría
haber llevado a perder algo. Y tal vez el problema no esté en usted -
puede existir alguien que por ejemplo, esté a cargo de la medición,
pero esta persona no haga el trabajo correctamente.
Todo esto significa que usted podría tener problemas en la certificación.

Para evitar esto, le recomiendo que haga una última comprobación,
que le de una imagen clara de lo que tenga que arreglar antes de la
certificación.
Básicamente, esto es lo que debería hacer:
● En primer lugar, asegúrese de que ha implementado todos los

controles, de acuerdo a lo planificado en el Plan de tratamiento
de riesgos. Puede planificar el implementar algunos controles me-
nos importantes después de la certificación, pero tiene que dejarlo
claro en el Plan de tratamiento de riesgos. (Cuanto menor sea el
número de controles que deja para después de la certificación,
mejor.)
● Verifique si se han realizado la auditoría interna, la revisión por

dirección y las acciones correctivas.
● A continuación, vaya a la lista de documentos obligatorios que

encontrará en el Appendix A de este libro, y compruebe si los
tiene todos.
198
● Después, lea la ISO 27001 una vez más y vea si su documentación
cumple con todos los requerimientos del estándar.
● Por último, ahora viene la parte más difícil – tiene que caminar
alrededor de su empresa (también debe visitar algunos de sus so-
cios y proveedores, los que tengan un papel en su seguridad de la
información) y comportarse como si fuera el auditor de certifica-
ción. Esto básicamente significa que tiene que preguntar de nuevo
una cuestión muy simple: ¿Realiza todo lo que está escrito en la
documentación? Basta con leer lo que dice cada uno de sus docu-
mentos (políticas, procedimientos, planes, etc.), y comprobar si las
respuestas que recibe son apropiadas. Para saber la verdad, usted
no debe confiar sólo en las respuestas - también debe profundizar
y buscar los documentos que prueben lo que le responden.
Y esto es todo – una vez que realiza este tipo de tareas - para cada una
de sus actividades, para cada uno de sus documentos, para cada uno
de sus principales proveedores y socios, tendrá una foto bastante bue-
na de lo que funciona y de lo que tiene que corregir.
Cuando usted mire más de cerca estos pasos, se dará cuenta de que se
asemejan mucho a los pasos que realiza un auditor interno. Así que se
podría preguntar, ¿Por qué hacer esto? En primer lugar, los auditores
internos son personas generalmente sin experiencia, y no puede espe-
rar mucho de ellos en sus primera auditorías; en segundo lugar, ya que
usted es responsable del éxito del proyecto, probablemente querrá
asegurarse de que todo esté a punto.
También puede contratar a una persona externa para realizar esta com-
probación final – esto lo puede hacer su consultor, suponiendo que
tenga uno - es cierto que no puede realizar la auditoría interna, debido
a los conflictos de intereses, pero nada impide que lo pueda emplear
para esta comprobación final. Y si el consultor tiene experiencia en au-
ditoría, mejor que mejor.
Vea también este mini caso de estudio en el capítulo 14: Preparar una
compañía de telecomunicaciones para la certificación.
199
SEGURO & SIMPLE
11.4 Cómo seleccionar una entidad certificadora

El precio es, por supuesto, el principal criterio para elegir la entidad cer-
tificadora; y por supuesto debe pedir un par presupuestos a entidades
certificadoras, y ver lo que incluyen en el precio.
Sin embargo, el precio no lo es todo - aquí tiene algunas otras cosas
que debe considerar a la hora de seleccionar con quién trabajar:
●R
eputación. Si desea utilizar su certificado para fines de market-
ing, probablemente no desee obtener el certificado de una en-
tidad que se sabe que regala los certificados sin ningún tipo de
criterio. Usted debe elegir una entidad certificadora con una sólida
y perfecta reputación.
●A
creditación. En realidad, cualquiera le puede dar un pedazo
de papel diciendo que está certificado en ISO 27001; pero por
desgracia no todas las entidades certificadoras están acreditadas
para hacerlo - por lo tanto, es necesario comprobar si esa entidad
certificadora tiene acreditación.
●E
specialización. Si usted es un banco, realmente no es una bue-
na idea tener una entidad certificadora que hasta ahora sólo haya
certificado empresas de fabricación. El auditor puede tener mucha
experiencia con la seguridad de la información, pero si él hasta
ahora ha auditado sólo empresas de fabricación, perderá mucho
tiempo explicándole cómo funciona el banco – como resultado, él
aprenderá mucho más de usted, que usted de él.
●E
xperiencia. Incluso si usted desea alguien con poca experiencia
para que la auditoría sea más sencilla, realmente es mejor un au-
ditor experimentado (vea la sección 11.7). Por lo tanto, no tenga
miedo en preguntar qué auditor le auditará, y pida su CV, o una
lista de las empresas que ha auditado.
●A
uditoría integrada. Usted puede comenzar solamente con la
ISO 27001, pero si también planea implementar la ISO 22301, la
ISO 9001, u otros estándares, en realidad puede pedir a su entidad
certificadora realizar lo que se conoce como auditoría integrada.
200
Esto significa que no tendrá que hacer auditorías independientes
para cada sistema (y pagar una tarifa independiente para cada
uno de ellos), puede hacer una única auditoría para todos estos
sistemas juntos – no sólo podrá ahorrar tiempo (una auditoría in-
tegrada es más corta que varias auditorías independientes), tam-
bién sí – tendrá que pagar menos.
● F lexibilidad. Si la entidad certificadora tiene un auditor que tiene
que volar desde otro continente (porque no tiene a nadie local-
mente), va a ser muy difícil para usted cambiar la fecha de la audi-
toría (por ejemplo, imagine que no termina su proyecto, debido a
que ha ocurrido algún problema) ya que es posible que se hayan
realizado ya todas las reservas para el viaje.
● L enguaje. A pesar de que la entidad certificadora puede propor-
cionar un traductor si el auditor (o auditores) no habla su idioma, si
el auditor habla su idioma la auditoría irá mucho mejor. Él leerá sus
documentos mucho más fácilmente, y usted será capaz de desarrol-
lar una mejor relación con él, si no existe una barrera con el idioma.
Por tanto, esto es – como con cualquier otro proveedor, usted tendrá que
hacer su trabajo y elegir el mejor para su empresa. Y recuerde, tiene que
pensar en el coste total del servicio que está recibiendo, y el precio de
oportunidad perdida – las entidades certificadoras de bajo coste podrían
tomar demasiado de su tiempo, y a cambio ofrecerle poco valor.
Vea también el Appendix J para una lista de preguntas detalladas que

debería realizar a potenciales entidades certificadoras.
11.5 Pasos en la certificación de la compañía y cómo

prepararse
Existen básicamente tres pasos en el proceso de certificación:
1) Auditoría Fase 1 – también conocida como Revisión documental,
2) Auditoría Fase 2 – también conocida como Auditoría principal, y
3) Auditorías de seguimiento.
201
SEGURO & SIMPLE
La Auditoría de Fase 1 es donde el auditor de certificación comprueba
si existe toda la documentación obligatoria - todas las políticas, procedi-
mientos y planes, todos los registros necesarios, etc. Básicamente, esta
es la parte más teórica de la auditoría, porque todo lo que hará el auditor
es leer sus documentos – esto es algo que se hace sin su participación.
La Auditoría de Fase 2 generalmente se realiza unas pocas semanas
después de la fase 1, y es completamente diferente: en esta auditoría
el enfoque no será la documentación, será comprobar si sus empleados
están haciendo realmente lo que dice su documentación, y lo que dice la
ISO 27001 que tienen que hacer. En otras palabras, el auditor comproba-
rá si realmente se ha materializado el SGSI en su organización, o si es sólo
es papel mojado. El auditor comprobará esto a través de observación, y
entrevistas a sus empleados, pero principalmente revisando sus registros
(vea la sección siguiente para más detalles). Por favor, tenga cuidado,
cualquier auditor experimentado notará inmediatamente cualquier parte
artificial en su SGSI, y también notará si está ocultando algo.
No conformidades mayores y menores. Durante la auditoría de fase
2, el auditor puede levantar no conformidades mayores o menores –
las no conformidades menores le permiten obtener el certificado, pero
tendrá que resolverlas en seis o 12 meses; las no conformidades ma-
yores significan que usted no puede obtener el certificado, pero esta
situación se puede resolver – vea la sección 11.9.
Visitas de seguimiento. Después de pasar la certificación, el certificado
es expedido para un período de tres años – así, por ejemplo, si la audi-
toría de certificación inicial fue realizada en Noviembre del 2017, esto
significa que el certificado será válido hasta Noviembre del 2020. Puesto
que la entidad certificadora garantiza que el sistema de gestión estará
funcionando a lo largo de la validez del certificado, la única forma para
la entidad certificadora de comprobarlo realmente, es enviar un auditor
de certificación periódicamente para ver cómo van las cosas. Y esto es lo
que se conoce como visitas de seguimiento – deben realizarse al menos
una vez al año, o, en algunos casos, se realizan dos veces al año.
En los casos en los que se realizan una vez al año, utilizando el ejemplo
anterior de la auditoría de certificación, la primera visita de seguimiento
202
sería en Noviembre del 2018, y la segunda (y última) visita de seguimiento
en Noviembre del 2019. Después de esto, en Noviembre del 2020, expira-
ría el certificado, y la compañía podría ir a la auditoría de recertificación.
Por tanto, durante la auditoría de seguimiento, el auditor se centrará en las
cosas en las que no fue capaz de verificar durante la auditoría de certifica-
ción: por ejemplo, si se registran todas las incidencias, si se hacen medicio-
nes, si todas las acciones correctivas se registran correctamente y se imple-
mentan, si la dirección realmente apoya y se preocupa por el sistema, etc.
Preparación. ¿Qué necesita hacer para prepararse para estas fases? Su-
poniendo que ha preparado la documentación y que todo funciona como
debería, lo único que puede hacer es avisar a todos los empleados cuan-
do venga el auditor de certificación, y saber qué esperar de él. Con esto
quiero decir que debe dejar claro a todo el mundo, que el auditor puede
ir a cualquier parte, ver a cualquiera, hacer cualquier pregunta, y ver cual-
quier documento/registro.
Basándome en mi experiencia, no tiene sentido que le diga a la gente
que oculten cosas, porque eso hará que se comporten de tal manera
que el auditor se dará cuenta muy rápidamente de lo que está suce-
diendo, y además - anularía el propósito de la auditoría.
11.6 ¿Qué cuestiones le preguntará el auditor de

certificación ISO 27001?
La mayoría de auditores generalmente no tienen una lista verificación
con preguntas, porque cada empresa es un mundo diferente, por lo
que suelen improvisar. El trabajo de un auditor es revisar la documen-
tación (políticas, procedimientos, planes, registros, etc.), formulando
preguntas (entrevistando a personas), y siempre buscará evidencias.
Documentación obligatoria. El auditor primero hará una verificación
de toda la documentación que existe en el SGSI (normalmente, esto tie-
ne lugar durante la auditoría de fase 1), comprobando si existen todos
los documentos requeridos por el estándar. Para el caso de los controles
de seguridad, utilizará la Declaración de Aplicabilidad como una guía
para empezar a comprobar la documentación que ha escrito.
203
SEGURO & SIMPLE
Además de los documentos obligatorios, el auditor examinará también
cualquier documento no obligatorio que la compañía haya desarrollado
como apoyo para la implementación del sistema, o para la implemen-
tación de los controles. Un ejemplo puede ser: un plan de proyecto, un
diagrama de red, la lista de documentación, etc.
Evidencia. Después de comprobar que los documentos existen en el

sistema, el siguiente paso es comprobar que todo lo que está escrito
corresponde a la realidad (normalmente, esto ocurre durante la audi-
toría de fase 2).
Por ejemplo, supongamos que la empresa define que la Política de Seguri-

dad de la Información se revisa anualmente. Por tanto, el auditor pregun-
tará: “¿Ha revisado la política este año?” Y la respuesta probablemente
será que sí. Sin embargo, el auditor no puede confiar en lo que él no ve;
por lo tanto, necesita evidencias. Estas evidencias pueden incluir registros,
minutas de reunión, etc. La pregunta siguiente sería: “¿Puede mostrarme
registros dónde pueda ver la fecha de cuando se revisó la política?”
Para los controles de seguridad implementados, también buscará evi-

dencias, aunque en este caso los registros pueden ser logs, archivos del
sistema, diagramas de red, configuración de plataformas, acuerdos con
proveedores o clientes, legislación, etc.
Entrevistas. En este momento, el auditor conoce los documentos que

utiliza la empresa, así que él necesita comprobar si las personas están
familiarizadas con estos documentos, y si los utilizan al realizar las acti-
vidades diarias; en otras palabras - comprueba si el SGSI está realmente
trabajando en su empresa.
Por lo tanto, quizás uno de los aspectos más importantes de la implemen-

tación del estándar ISO 27001 es la concienciación del personal. De esta
manera, el auditor llevará a cabo entrevistas con empleados, para conocer
el grado de conocimiento de los documentos más importantes que le
apliquen: Política de seguridad de información, cláusulas de confidenciali-
dad, Uso aceptable de activos, Política de control de accesos, etc.
Un ejemplo de preguntas en una entrevista podrían ser las siguientes:
204
●“
¿Tiene acceso a las reglas internas relacionadas con la seguridad
de la información?”
●“
¿Puede mostrarme alguna de las políticas?”
●“
¿Podría decirme cuáles son los puntos que considera más
importante en la política?”
Por otra parte, el auditor puede también entrevistar a los responsables

de procesos, áreas físicas y departamentos, para conseguir la percep-
ción que tienen de la implementación del estándar en la empresa. En
estas entrevistas, las preguntas tienen como objetivo conocer las fun-
ciones y los roles que tienen las personas en el SGSI, y si hacen su tra-
bajo correctamente.
Cómo prepararse. En definitiva, un auditor puede solicitar:
● Documentos requeridos por el estándar ISO 27001, y cualquier

documento que exista en el alcance del SGSI
● Registros para comprobar el cumplimiento de los documentos (po-

líticas, procedimientos, etc.)
● Entrevistas con el personal de la compañía
Por lo tanto, si usted quiere estar bien preparado para las preguntas
que un auditor le puede hacer, en primer lugar compruebe que tiene
todos los documentos requeridos, y luego verifique que la empresa
hace todo lo que los documentos requieren, y que usted puede demos-
trarlo todo a través de registros. Por último, es muy importante que la
gente conozca todos los documentos que les sean aplicables. En otras
palabras, asegúrese de que su empresa realmente ha implementado el
estándar, y que lo ha aceptado como algo necesario en sus operaciones
diarias - el funcionamiento de este estándar será imposible si creó la
documentación sólo para satisfacer la auditoría de certificación.
Vea también en el Appendix K una interesante infografía sobre qué

esperar de los auditores de certificación.
205
SEGURO & SIMPLE
11.7 Cómo hablar con los auditores para beneficiarse

de la auditoría
No olvide que los auditores son sólo personas, y no importa lo profe-
sionales que sean, siempre estarán contentos si los trata bien, y estarán
con una actitud negativa si los trata mal.
Por tanto, ¿Qué debería no hacer?
●N
o evite sus preguntas. Sabrán enseguida si usted está ocultan-
do algo, o si desea desviar la discusión a otra cosa - esto es una
buena manera de parecer sospechosos, porque el auditor pensará
que esconde una no conformidad.
● No mienta. Cuando descubran que está mintiendo (y lo harán),
perderán totalmente la confianza en usted, y se convertirán en
mucho más cuidadosos que antes.
● No pierda su tiempo. No los arrastre a un lugar donde no quieran
ir, o no pase demasiado tiempo en cosas en las que quieran despla-
zarse rápidamente. Esto hará que estén más nerviosos, ya que no
podrán pasar por algunas otras cosas que es importante para ellos.
Zona gris de la que puede tomar ventaja. Así que, ¿Por qué debe
usted tratarlos bien en primer lugar? Porque existe una zona gris de la
que podrá beneficiarse construyendo una relación positiva. (No se pre-
ocupe, como explicaré más adelante, con esta zona gris no me refiero
a nada ilegal o poco ético). Los auditores tienen una regla básica, y es
que deben hacer sólo auditoria, no consultoría – esto significa que le
deben decir si algo es bueno o malo (es decir, si hay no conformidades
o no), y deben de darle una explicación sobre por qué hay una no con-
formidad, o por qué algo es una buena práctica; sin embargo, no se
les permite dar consejos detallados sobre cómo resolver su problema.
Usted debe ser consciente de que los auditores de certificación han au-
ditado a cientos, y decenas de empresas donde han visto de todo – de la
peor práctica posible, a fantásticos ejemplos de soluciones inteligentes.
Básicamente, son una enciclopedia andante de lo que es bueno y malo
para la ISO 27001.
206
¿Cuál es esta zona gris? Esto es realmente a lo que me refería antes – si
desarrolla una relación positiva, una breve explicación no será sólo un
par de palabras, también tal vez será un par de sentencias – lo cual será
suficiente para que tenga alguna idea, lo que le puede hacer ahorrar un
poco de dinero y tiempo. Por otro lado, si trata mal al auditor, (por su-
puesto) guardará sus explicaciones al mínimo, y perderá la oportunidad
de aprender algo de él.
Relación positiva. Por tanto, debe de hacer lo siguiente para desarro-
llar una relación positiva:
●C
ontestar la cuestión directamente. Proporciónele respuestas
claras y oportunas, soportadas con hechos.
●A
dmitir que tiene un problema. Por supuesto, no va a contarle
todos sus problemas al inicio; pero si le pregunta directamente – dí-
gale abiertamente cuál es el problema. Los auditores interpretarán
su sinceridad como una intención de mejorar el sistema – en tales
casos, podrían levantar una no conformidad, pero seguramente
conseguirá debatir con el auditor cuál sería la mejor manera de ce-
rrar dicha no conformidad.
●P
regúntele su opinión. No tendrán tiempo de responder a sus
preguntas, pero si muestra su entusiasmo sobre el tema, conse-
guirán una imagen positiva sobre usted y su empresa.
11.8 Qué puede hacer y qué no puede hacer un auditor

Existe una regla fundamental que tiene que recordar: el auditor puede
levantar una no conformidad sólo si se cumplen estas condiciones:
1) Ha encontrado evidencia de una no conformidad, y
2) Este requisito existe en el estándar o en otro documento.
Qué no puede hacer un auditor. Esto nos lleva a una conclusión
importante: Si el auditor cree que no se realiza la copia de seguridad,
según el programa definido en la Política de copias de seguridad, pero
207
SEGURO & SIMPLE
no tiene una prueba de esto, entonces él no puede levantar una no
conformidad. Para levantar una no conformidad debe tener la prueba,
y en este caso necesitaría los registros de la copia de seguridad.
Otro ejemplo - el auditor de certificación no puede levantar una no
conformidad si usted está realizando la copia de seguridad cada 12
horas, y el auditor piensa que debe hacerse al menos cada 6 horas - no
puede hacerlo porque esto no es un requisito (al menos no lo es en
el estándar). Podría haber levantado esta no conformidad sólo si, por
ejemplo, se especifica una frecuencia de 6 horas para las copias de se-
guridad en su Política de copias de seguridad.
El punto es que el auditor de certificación debe tener 1) evidencia + 2)
el requisito. Si no tiene alguna de estas cosas, o ambas cosas, el auditor
no puede levantar una no conformidad.
Cómo argumentar. Por lo tanto, puede estar preparado para discutir
con el auditor, en el caso de que haya notado que la evidencia o el re-
quisito no existe. Por supuesto, tiene que hacerlo con calma y de forma
profesional, y el auditor aceptará cada corrección a sus hallazgos si sus
argumentos son sólidos.
Puede hacer este argumento en tres etapas: (1) lo mejor es hacerlo
durante la auditoría, porque hacerlo de una manera informal es lo más
fácil; (2) si ve que el auditor no acepta sus argumentos, su segunda
oportunidad para debatirlo es la reunión de cierre de la auditoría de
certificación, de una manera formal - en la reunión de cierre, el auditor
(o auditores) presentará los hallazgos y no conformidades, y le pre-
guntará si tiene algún comentario; (3) si eso no funciona bien, puede
presentar una queja por escrito a la entidad certificadora después de la
auditoría de certificación, explicando su caso.
Basándome en mi experiencia, el punto (1) se hace a veces, el (2) ra-
ramente, y el (3) casi nunca. Como mencioné en la sección anterior,
un enfoque mucho mejor es desarrollar una relación positiva con el
auditor, para que él realmente le ayude a mejorar la seguridad de la
información. Sólo en el caso de que estén absolutamente convencidos
de que el auditor está equivocado, debe discutir su caso.
208
11.9 No conformidades y cómo resolverlas

He mencionado muchas veces el término no conformidad en este libro,
pero nunca expliqué qué significa. La definición de no conformidad es
“incumplimiento de un requisito” - básicamente esto significa que una
no conformidad se produce cuando no cumple lo que es exigido por el
estándar, o lo que es requerido por su propia documentación, o lo que es
requerido por un tercero.
Aquí tiene varios ejemplos de no conformidades:
● Si no tiene registros de acciones correctivas, y el estándar requiere
tenerlos
● Si su procedimiento requiere utilizar un formulario específico para
el reporte de los resultados de la auditoría interna, sin embargo
utiliza un formulario completamente distinto
● Si no produce determinados reportes para sus clientes, a pesar
de que está obligado a hacerlo según el acuerdo contractual que
tiene firmado con sus clientes
¿Por qué las no conformidades son importantes? Las no conformidades
se utilizan tanto en las auditorías internas como en las externas (certi-
ficación) - son una “herramienta” con la que el auditor podrá juzgar
hasta qué nivel su sistema de gestión cumple con un estándar.
En otras palabras, mientras más no conformidades, menos cumplirá
con el estándar - y viceversa. Las no conformidades deben ser infor-
madas a través de un informe de auditoría, y esta parte del informe es
generalmente la más importante.
A la hora de reportar una no conformidad, el auditor debe incluir los
siguientes elementos:
● D
escribir la no conformidad – descripción general de lo que
está mal, en una frase o dos
●P
roporcionar evidencias de auditoría – por ejemplo, se puede
referir a un documento concreto, o un registro que falta o se uti-
209
SEGURO & SIMPLE
liza de manera inadecuada, o a una actividad que no se realiza, o
se realiza de manera incorrecta, etc.
● Incluir referencia al requerimiento específico – por ejemplo, nú-
mero concreto de la cláusula del estándar, o procedimiento o contrato
Resumir el requerimiento – generalmente, reformular lo que requiere

el estándar, el documento interno, o el contrato que se requiere hacer
No conformidades mayores vs. menores. Las no conformidades

mayores y menores (como categorías separadas) se utilizan general-
mente solamente en las auditorías de certificación (no tan a menudo
en las auditorías internas), y el objetivo principal es el siguiente: Si el
auditor levanta una no conformidad mayor, la empresa no puede ob-
tener la certificación.
Así que, ¿A qué se le considera una no conformidad mayor? Una no

conformidad mayor es una no conformidad que tiene alguna de estas
características:
● Si una compañía incumple totalmente cierto requerimiento del

estándar – por ejemplo, no ha realizado nada de la revisión por la
dirección, aunque esto es un requisito del estándar.
● S i su proceso falla completamente – por ejemplo, su procedimiento

requiere realizar copias de seguridad 1 vez al día, sin embargo la copia
de seguridad se realiza sólo un par de veces al mes, y aleatoriamente.
● Si tiene muchas no conformidades menores que están relacionadas

con el mismo proceso o el mismo elemento de su sistema de gestión
– por ejemplo, tiene varias no conformidades menores relacionadas
con su departamento de recursos humanos: algunos de los registros
de formación no están disponibles, no todos los empleados están
concienciados como debe ser, faltan algunos de los registros de em-
pleo, etc. - esto se convierte en una no conformidad mayor porque
obviamente hay algo muy mal en este departamento.
Si la marca de certificación se utiliza mal – por ejemplo, usted le dice

a sus clientes que su producto está certificado por ISO (la certificación
210
de los estándares de gestión ISO sólo cubren procesos y sistemas de
gestión, no productos).
Si una no conformidad menor, levantada durante una auditoría previa,

no ha sido resuelta dentro del plazo establecido – esta pequeña no
conformidad, automáticamente se convierte en una mayor.
La definición de no conformidad menor es fácil: se trata de cualquier

no conformidad que no sea mayor; por ejemplo, una no conformidad
menor podría ser que la copia de seguridad se realizó cada día, excepto
un solo día de un mes en particular.
Cómo resolver una no conformidad mayor. Lo preparó todo, pero

aún así sucedió – el auditor encontró una no conformidad mayor, y dijo
que no se emitirá el certificado ISO 27001. ¿Es este el fin del mundo?
Desde luego que no. El proceso va así - el auditor indicará los hallazgos
(incluyendo la no conformidad mayor) en el informe de auditoría, y le
dará un plazo para resolver la no conformidad (generalmente 90 días).
Su trabajo consiste en tomar medidas correctivas apropiadas; pero hay
que tener cuidado - esta acción debe resolver la causa de la no confor-
midad, de lo contrario el auditor no aceptará lo que ha hecho. Una vez
que toma la acción correcta, tiene que notificar al auditor, y enviarle la
evidencia de lo que haya hecho. En la mayoría de los casos, si ha hecho
bien su trabajo, el auditor aceptará su acción correctiva, y activará el
proceso de emitir el certificado.
Y eso es todo – esto requiere un esfuerzo extra (y supongo que un poco

de más estrés), pero incluso con una no conformidad mayor, lo más
probable es que finalmente obtenga el certificado. La única diferencia
es que lo tendrá un par de meses más tarde.
Así que lo consiguió – tomó un tiempo, pero ahora usted puede estar
orgulloso de que es propietario del certificado ISO 27001. Sin embargo,
tenga cuidado, a pesar de que el certificado es válido durante tres años,
puede ser suspendido durante este periodo si la entidad certificadora
identifica otra no conformidad mayor durante las visitas de seguimiento.
211
SEGURO & SIMPLE

Resumiendo, cuando su empresa vaya a por la certificación, debería:
● Primero decidir si usted necesita el certificado
● Finalizar la implementación de todos los controles y todos los do-

cumentos
● Realizar la auditoría interna, la revisión por dirección, y cerrar to-

das las acciones correctivas
● Realizar la “revisión final”
● Seleccionar la entidad certificadora mas apropiada a sus circuns-

tancias
● Estar preparado a que el auditor de certificación no sólo lea sus

documentos – mirará cómo sus empleados realizan las activida-
des, y los entrevistará
● En lugar de evitar al auditor, debería beneficiarse de su visita,

usando un enfoque positivo
212
12
CAPÍTULO EXTRA I:
OPORTUNIDADES DE CARRERA
EN ISO 27001
¿Se ha enganchado a ISO 27001? Ojalá que sí, y sea de su interés.
Por tanto, si así es, ahora, ¿Hacia dónde puede usted dirigir su carrera
si quiere aprovechar este estándar mundialmente reconocido, de segu-
ridad de la información? Básicamente, tiene 4 opciones, las cuales se
indican a continuación, de más sencilla a más difícil:
a) Convertirse en un implementador en su propia empresa, o
b) Convertirse en un consultor, o
c) Convertirse en un auditor de certificación, o
d) Convertirse en un formador docente
O también puede hacer una combinación de estas cosas - he trabajado

mucho tiempo como auditor de certificación, como consultor y como
formador. Y debo decir que estoy muy contento - siendo consultor,
tuve que averiguar cuáles son las mejores soluciones para una amplia
variedad de clientes; siendo auditor tuve la oportunidad de ver lo que
estaban haciendo otros consultores, y lo que han conseguido algunas
de las mejores empresas; siendo formador me bombardearon con mu-
chas cuestiones, y siempre tenía que asegurarme de que proporcionan
la respuesta correcta, aunque muy a menudo las preguntas eran algo
que no había pensado previamente.
Por lo tanto, vamos a ver cómo ISO 27001 puede ayudarle en su desa-
rrollo profesional.
213
SEGURO & SIMPLE
12.1 Cursos más populares a los que asistir

Si desea más información sobre ISO 27001, probablemente la mejor
idea sea asistir a un curso de capacitación. Aquí tiene una lista de las
formaciones más populares en todo el mundo:
Curso Auditor Jefe ISO 27001. Este es uno de los dos cursos más avan-
zados de ISO 27001 – dura cinco días y termina con un examen por escrito
(que es bastante difícil). Si pasa el examen, puede convertirse en un auditor
para una entidad certificadora, pero este no es su principal beneficio – es
muy útil para profesionales que implementan el estándar, ya que les propor-
ciona una excelente descripción de los estándares, y les proporciona explica-
ciones detalladas de lo que los auditores de certificación le solicitarán en la
auditoría de certificación. Por lo tanto, es útil para auditores e implementa-
dores. El público objetivo de este curso incluye a profesionales con experien-
cia moderada o importante en seguridad de la información, auditoría o TI.
Curso Implementador Jefe ISO 27001. Este curso avanzado dura tam-
bién cinco días, y es algo similar al curso de Auditor Jefe. La diferencia es
que este se centra en técnicas de implementación, en lugar de en técnicas
de auditoria - por lo tanto, si la certificación no es su preocupación, usted
puede encontrar este curso más conveniente. Aquí, el público objetivo es
similar: profesionales con moderada o significativa experiencia en seguridad
de la información o TI. Vea también la sección siguiente para más detalles.
Curso Auditor Interno ISO 27001. Este curso es una versión “light” del
curso de Auditor Jefe – generalmente tiene una duración de dos o tres
días, puede ser con o sin examen, y el contenido es una versión resumida
del curso de Auditor Jefe. La principal diferencia es que este curso no le
servirá para convertirse en auditor para una entidad certificadora; sin em-
bargo, si usted quiere conseguir una introducción sistemática al mundo
del estándar ISO 27001, o va a ser un auditor interno en su empresa, este
curso es la opción correcta para usted. El público objetivo son profesiona-
les con poca o moderada experiencia en seguridad de la información o TI.
Curso de Fundamentos / Curso introductorio ISO 27001. Estos cur-

sos generalmente duran uno o dos días – su propósito no es enseñarle
técnicas sobre auditoría o implementación, sino darle una visión gene-
214
Capítulo extra I: Oportunidades de carrera en ISO 27001
ral de las necesidades y problemas de la implementación. Si no tiene
mucho tiempo libre, y quiere saber lo que su empresa experimentará
durante la implementación, puede pensar en hacer uno de estos cur-
sos. El público objetivo incluye a miembros de la dirección, o profesio-
nales con, o sin, experiencia en seguridad de la información.
Los principales proveedores de todos estos cursos son entidades certi-

ficadoras, y organizaciones especializadas en formación – le ofrecen la
posibilidad de que estos cursos se puedan organizar en su país también,
por lo que sólo debe buscar un poco el mejor proveedor para usted. Los
cursos antes mencionados también se ofrecen en línea.
 Herramienta gratuita: Aquí puede ver cursos online gratuitos ISO
27001 Foundations Course and ISO 27001 Internal Auditor Course.
12.2 ¿En qué se parece el Curso de Auditor Jefe y el

Curso de Implementador Jefe?
Ambos cursos, es decir, el de Auditor Jefe y el de Implementador Jefe,
tienen una duración de cinco días, y el quinto día usted tiene que pasar
un examen; ambos cursos son muy intensos, y normalmente tiene que
asistir a 40 horas de curso repartidas en 5 días.
En el primer día del curso, usted tendrá una visión detallada de cada
cláusula del estándar, un profesor le enseñará a interpretar el estándar,
así como su lógica subyacente. Después de este primer día, el curso de
Auditor Jefe se centrará principalmente en técnicas de auditoría para
un estándar en particular, mientras que el curso de Implementador Jefe
le explicará los mejores métodos para la implementación.
La mayoría de los cursos son muy interactivos - por ejemplo, los cursos
que he impartido tenían aproximadamente 15 talleres, que se reali-
zaban durante 5 días, lo cual dio a los estudiantes una oportunidad
perfecta para aprender, mientras hacían el trabajo en equipo; por su-
puesto, también hay debates, y un buen tutor fomentará la discusión y
la aplicabilidad del estándar en situaciones reales.
215
SEGURO & SIMPLE
No necesita ningún conocimiento especial para inscribirse en el curso
– si está interesado en el curso de ISO 27001, es suficiente tener cono-
cimientos medios de TI, y no es necesario ningún conocimiento previo
en seguridad de la información.
12.3 Cómo convertirse en un auditor de certificación

Muchas personas piensan que sólo con asistir al curso de Auditor Jefe
ISO 27001, se pueden convertir en auditor de certificación. Bueno, esto
no es totalmente cierto.
Si usted quiere convertirse en un auditor de certificación, y trabajar

para una entidad certificadora, esto es lo que la ISO 27006 (estándar
que define los requisitos para las entidades certificadoras) requiere:
1) Experiencia – Usted necesita tener, por lo menos, cuatro años

de experiencia en tecnologías de la información, de los cuales, al
menos dos años, tienen que estar relacionados con un trabajo de
2) Pasar el examen – El curso de Auditor Jefe ISO 27001 dura 5

días, y el quinto día debe pasar el examen por escrito. Por lo tan-
to, es necesario invertir un esfuerzo considerable, no sólo para
estudiar para el examen, sino también para asistir a los 5 días del
curso (si pierde un solo día, no le permitirán realizar el examen).
3) Encontrar una entidad certificadora – Usted necesita encon-

trar una entidad certificadora que requiera un auditor de certifi-
cación ISO 27001 – esto puede resultar una tarea difícil, dado que
la mayoría de las entidades certificadoras ya tienen sus auditores.
4) Ir a través de un programa de prácticas – Cuando encuentre

una entidad certificadora que esté interesada, esto no significa
que usted comenzará a auditar desde el primer día – ISO 27006
requiere que usted realice un programa de formación (o similar),
durante el cual asistirá como observador a auditorías de certifi-
cación reales (que realizarán colegas con más experiencia), y en
216
donde usted aprenderá cómo llevar a cabo estas auditorías. Gen-
eralmente, este período de prácticas dura 20 jornadas de audi-
toría, y después de este periodo ya estará preparado para llevar a
cabo auditorías de SGSI como parte del equipo de auditoría.
5) Adquirir experiencia de auditoría – Para convertirse en Audi-

tor Jefe ISO 27001, es decir, para liderar un equipo de auditores
para realizar auditorías de ISO 27001, es necesario tener una ex-
periencia de haber participado en, al menos, tres ciclos completos
de auditorías de SGSI.
12.4 Cómo convertirse en consultor

Ser un consultor independiente es probablemente el mejor trabajo del
mundo – hace lo que quiere, cómo quiere, y cuándo quiere; pero tam-
bién vende sus conocimientos, es decir, las personas comienzan a per-
cibirle como un experto en su campo particular.
¿Qué cualificaciones necesita? Es algo curioso, pero no se necesitan

calificaciones específicas formales, al menos no se necesitan en la ma-
yoría de los países. Esto básicamente significa que cualquiera puede
convertirse en un consultor, sin ningún tipo de calificaciones.
Sin embargo, si quiere convertirse en un consultor respetado por sus

potenciales clientes, usted debe tener, por lo menos, lo siguiente:
● Certificados ISO 27001 – al menos debe obtener el certificado de

Auditor Jefe o implementador Jefe, pero sería mejor si obtuviera
ambos.
● Certificado de gestión de proyecto – dado que su trabajo con-

sistirá en la ejecución de proyectos, usted debe aprender a ejecu-
tarlos. Por ejemplo, usted debe obtener PMP, o algún otro certifi-
cado similar.
● Experiencia – los conocimientos teóricos no serán suficientes,

usted necesita mostrar a sus potenciales clientes que sabe cómo
realizar el trabajo.
217
SEGURO & SIMPLE
Dónde conseguir la experiencia:
● Trabajando como auditor de certificación – realizar auditorías
de certificación le dará una visión excelente de qué hacer o no
hacer durante la implementación del estándar ISO 27001, o
● Trabajando para otro consultor – Esta es la mejor manera de
aprender sobre los métodos de implementación, y cómo conse-
guir nuevos clientes, o
● Trabajando como principiante en seguridad de la informa-
ción – trabajar en una empresa es una manera excelente para
aprender el lado del cliente de esta historia: ¿Cuáles son los do-
lores habituales? ¿Para qué se necesita la ayuda de un experto?
¿Qué más necesita? Además de conseguir los conocimientos ya men-
cionados anteriormente, usted también necesitará algunas herramien-
tas y fuentes de información:
● Libros – existen disponibles muchos libros sobre ISO 27001 (este
que está leyendo ahora no es el único…)
● Plantillas de documentos – cuando empiece a trabajar con sus
clientes, necesitará plantillas de la ISO 27001, políticas y procedi-
mientos para acelerar su trabajo.
● Plantillas para propuestas y presentaciones – lo que muestre
a sus potenciales clientes debe ser muy completa y profesional.
● Herramientas – Además de un ordenador portátil y el MS Office,
usted también necesitará algún tipo de software de gestión de
relaciones con clientes (CRM), o un servicio en línea, ya que debe
realizar un seguimiento de todos los potenciales clientes, y en qué
fase está actualmente con cada uno de ellos.
● Habilidades con medios sociales – tiene que aprender a co-
municarse a través de Twitter, Facebook y LinkedIn, ya que son
canales importantes para conseguir nuevos clientes.
● Habilidades de desarrollo web – Si usted decide publicar artí-
culos, necesita al menos saber cómo montar un blog (esto cierta-
mente para mi funcionó muy bien).
218
Cómo encontrar clientes. Lo crea o no, esta es, de lejos, la tarea más
difícil; Aquí es donde han fracasado la mayoría de potenciales consulto-
res, sin importar los conocimiento que tenían sobre ISO 27001.
Existen varias maneras que debe emplear para comercializar sus servicios:
●U
se sus contactos de trabajos previos – por ejemplo, comience
a establecer un trato con uno de sus clientes, incluso antes de em-
pezar su nuevo trabajo de consultoría, con el fin de evitar un vacío
una vez que comience su nuevo trabajo; Esto es probablemente la
mejor manera de comenzar su carrera, pero debe tener cuidado,
permaneciendo dentro de los límites éticos - no debe molestar a
su cliente.
● Ventas directas – debe pasar al menos el 30% de su tiempo

marcando números de teléfono, y entregando presentaciones a
potenciales clientes - esta es básicamente la mejor forma de cerrar
un trato.
● Discursos en conferencias – Esta es una de las mejores maneras

de construir su credibilidad, y obtener nuevos contactos. Asegú-
rese de practicar sus habilidades de presentación, porque de lo
contrario, puede acabar con menos credibilidad de la que tenía
previamente.
● Escribir artículos de experto – debe publicar sus artículos en

revistas especializadas, y en Internet, de esta manera, mostrará su
experiencia a todo el mundo.
● Realizar cursos – esta es una excelente manera de obtener nue-

vos contactos y probar sus conocimientos.
● Asociaciones – tal vez usted pueda encontrar algunos proveedo-

res que sean compatibles (sin ser competencia) con su servicio - en
tales casos, cuando estos proveedores consigan nuevos acuerdos,
esto puede resultar también en nuevos clientes para usted.
219
SEGURO & SIMPLE
Y recuerde – los clientes no van a ir corriendo hacia usted el primer día
que comience su consultoría; por el contrario, al principio es probable
que tenga menos clientes de los que usted imaginó incluso en su peor
escenario. Esto es porque el ciclo de ventas es muy largo - normalmente
tarda mucho tiempo que un cliente decida empezar un proyecto.
No estoy diciendo que un buen consultor debe ser más experto en

marketing que en el estándar ISO 27001 – sólo estoy diciendo que no
se deben descuidar habilidades y esfuerzos en marketing, porque sin
esto su experiencia nunca llegará a los clientes.
Enfocarse en lo que es lo mejor para el cliente. Por último, pero

no menos importante, recuerde que la reputación es lo que le traerá
nuevos clientes. Asegúrese de que todo lo que hace, es siempre con el
mejor interés para el cliente – no debe recomendar alguna tecnología
nueva a un cliente sólo porque usted tiene un socio vendiendo este pro-
ducto; no debe retener cierta información sólo para que el cliente use
sus servicios más tarde. Lo que debe hacer es proteger los intereses de
su cliente y superar sus expectativas.
Una vez que los clientes se den cuenta de su integridad y capacidad,

comenzarán a recomendarle – y aquí es donde su carrera despegará.
220
13
CAPÍTULO EXTRA II: ESTÁNDARES
RELACIONADOS, CONCEPTOS,
Y MARCOS DE TRABAJO
Como verá, existen muchos estándares de gestión, marcos de trabajo

de seguridad de la información, y de continuidad de negocio, relacio-
nados con la ISO 27001 – es cada vez más difícil encontrar un camino
entre todos ellos, por lo que en esta sección he intentado listar lo más
importante de cada uno de ellos.
13.1 Los estándares más importantes de la serie ISO 27k

ISO 27001 no es el único estándar que se ocupa de la seguridad de la
información – de hecho, hay más de 30 estándares en la serie ISO 27k.
Así que, ¿Cuál es el propósito de todos estos estándares de seguridad de
la información? Cada uno de ellos da una orientación detallada sobre un
elemento específico de la seguridad de la información – por ejemplo, ISO
27005 explica en detalle cómo realizar el análisis y tratamiento de ries-
gos. Por suerte, no tiene que leer los 40 estándares, a menos que desee
convertirse en un gurú – al principio, ISO 27001 será más que suficiente
para usted, y después de que controle este estándar, a continuación,
puede empezar a explorar otros estándares ISO27k, los cuales le propor-
cionarán un conocimiento más profundo de ciertos segmentos.
Aquí tiene los estándares más populares de la serie ISO27k (además de
la ISO 27001):
ISO/IEC 27000 proporciona una lista de términos y definiciones que se
utilizan en seguridad de la información, y en la serie de estándares ISO27k.
ISO/IEC 27002 proporciona una guía de buenas prácticas para la im-
plementación de los controles incluidos en la ISO 27001. ISO 27001
221
SEGURO & SIMPLE
especifica 114 controles, que puede utilizar para reducir los riesgos de
seguridad, y la ISO 27002 puede ser muy útil porque proporciona in-
formación sobre cómo implementar estos controles. ISO 27002 ante-
riormente era conocido como ISO/IEC 17799 y este surgió del estándar
británico BS 7799-1.
ISO/IEC 27004 proporciona una guía de buenas prácticas para la medi-
ción de la seguridad de la información – esto encaja bien con la ISO 27001
porque explica cómo determinar si el SGSI ha logrado sus objetivos.
ISO/IEC 27005 proporciona una guía de buenas prácticas para la gestión
de riesgos de seguridad de la información. Es un complemento muy bue-
no para la ISO 27001, porque da detalles sobre cómo realizar el análisis
y tratamiento de riesgos, que probablemente sea la etapa más difícil en
la implementación. ISO 27005 surgió del estándar británico BS 7799-3.
ISO/IEC 27017 proporciona una guía de buenas prácticas para contro-
les de seguridad para servicios en la nube. Este estándar proporciona
controles adicionales a los ya tiene el estándar ISO 27002, los cuales
se centran específicamente en la protección de la información que es
procesada y almacenada en la nube.
ISO/IEC 27018 proporciona una guía de buenas prácticas para la protec-
ción de la privacidad en la nube. De la misma manera que con ISO 27017,
este estándar también está basado en ISO 27002, y proporciona algunos
controles de seguridad adicionales que ayudan a proteger la información
personal identificable.
ISO/IEC 27031 proporciona una guía de buenas prácticas para aspec-
tos relativos a TI, en la recuperación ante desastres. Este estándar ha
sustituido a la BS 25777, y describe los conceptos y los principios de
las tecnologías de la información y comunicación (TIC) para preparar
la continuidad del negocio, y proporciona un marco de trabajo de mé-
todos y procesos, para identificar y especificar todos los aspectos para
mejorar la disponibilidad de las TIC de una organización, para de esta
manera asegurar la continuidad del negocio.
ISO/IEC 27032 proporciona directrices para la ciberseguridad. Este es-
tándar explica cómo la ciberseguridad está relacionada con la seguri-
222
Capítulo extra II: Estándares relacionados, conceptos, y marcos de trabajo
dad de la información, cómo tratar problemas comunes de la ciberse-
guridad, cuáles son los actores típicos y cómo tienen que colaborar, etc.
Vamos a ver cómo algunos de estos estándares están relacionados con
ISO 27001.
13.2 ISO 27001 vs. ISO 27002

Si tuvo la oportunidad de leer la ISO 27001 y la ISO 27002, proba-
blemente notó que ISO 27002 es mucho más detallada, más precisa
- ¿Cuál es el propósito del estándar ISO 27001 entonces?
En primer lugar, una empresa no puede obtener la certificación ISO

27002, porque esto no es un estándar de gestión. En otras palabras,
ISO 27002 se centra sólo en controles de seguridad, pero no explica
cómo construir un sistema de gestión de seguridad de la información,
el cual incluiría roles y responsabilidades, establecer objetivos, gestión
de riesgos, auditorías internas, etc. Por lo tanto, no es posible una cer-
tificación ISO 27002.
Los controles de ISO 27002 tienen el mismo nombre que en el anexo A

de ISO 27001 – por ejemplo, en el estándar ISO 27002, el control 6.1.3 se
denomina Contacto con las autoridades, mientras que en el estándar ISO
27001 es A.6.1.3 Contacto con las autoridades. La diferencia está en el
nivel de detalle – en promedio, ISO 27002, explica un control en una pá-
gina entera, mientras que ISO 27001 dedica sólo una frase a cada control.
Finalmente, la diferencia es que ISO 27002 no hace una distinción en-

tre los controles que son aplicables y los que no son aplicables, para
una empresa en particular. Por otra parte, ISO 27001 establece que es
necesario realizar un análisis de riesgos para identificar qué control es
necesario para disminuir los riesgos, y hasta qué punto se debe aplicar.
Ahora surge la pregunta: ¿Por qué estos dos estándares se publican por
separado?, ¿Por qué no se han fusionado reuniendo los puntos positi-
vos de ambos? La respuesta es la usabilidad, si fuese un único estándar
sería demasiado complejo, y demasiado grande para un uso práctico.
223
SEGURO & SIMPLE
Para concluir, ISO 27002 es un estándar muy bueno con el que puede
aprender cómo implementar los controles individuales de ISO 27001; sin
embargo, ISO 27002 no debería utilizarse sin ISO 27001 ya que esto po-
dría conducir a un esfuerzo aislado por parte de algunos entusiastas de
seguridad de la información, lo que podría implicar la no aceptación de la
alta dirección, y por lo tanto no tendría un impacto real en la organización.
13.3 ISO 27001 vs. ISO 27005 vs. ISO 31000

ISO 31000 proporciona una guía de buenas prácticas sobre cómo or-
ganizar la gestión del riesgo en las organizaciones – este estándar no
se centra exclusivamente en los riesgos de seguridad de información;
puede ser utilizado para cualquier tipo de riesgos, como riesgos rela-
cionados con la continuidad del negocio, riesgos de mercados, riesgos
económicos, riesgos de créditos, riesgos operacionales y otros.
Proporciona un glosario detallado de términos de gestión de riesgos,

explica los principios básicos de la gestión de riesgos, y proporciona un
marco de trabajo general que incluye un ciclo PDCA para la gestión de
riesgos. Sin embargo, dado que es aplicable a cualquier tipo de orga-
nización y a cualquier tipo de riesgo, no proporciona una metodología
específica para, por ejemplo, la gestión de riesgos de seguridad de la
información.
Relación entre ISO 31000 y ISO 27001. La revisión previa del 2005 de
la ISO 27001, no hacía referencia a la ISO 31000, pero la nueva revisión
2013 sí lo hace, y esto ha causado confusión - muchas personas pien-
san que tienen que implementar algo nuevo en la ISO 27001 debido a
la ISO 31000, pero esto no es cierto.
Esto es lo que dice ISO 27001 sobre la ISO 31000: en la cláusula 4.1,
ISO 27001 señala que podría considerar los contextos internos y exter-
nos de la organización, según la cláusula 5.3 del estándar ISO 31000. Y,
de hecho, los apartados 5.3.2 y 5.3.3 del estándar ISO 31000 son muy
útiles en ese sentido, porque proporcionan valiosas directrices sobre los
contextos internos y externos; sin embargo, ISO 27001 menciona ISO
224
31000 solamente en una nota, lo cual significa que estas directrices no
son obligatorias.
En la cláusula 6.1.3, ISO 27001 señala que la gestión de la seguridad

de la información en ISO 27001 está alineada con ISO 31000. Por lo
tanto, ISO 27001 no dice que tiene que implementar el análisis y trata-
miento de riesgos según el estándar ISO 31000 – sólo dice que todos
los requisitos de ISO 27001 son compatibles con ISO 31000. Por lo
tanto, puede implementar la gestión de riesgos de la forma que desee,
siempre y cuando cumpla con ISO 27001.
ISO 31000 vs. ISO 27005. Como se mencionó anteriormente, ISO

31000 no ofrece ningún consejo específico sobre análisis y tratamiento
de riesgos de seguridad de la información; para este propósito está ISO
27005 – un estándar que proporciona una guía de buenas prácticas
para el análisis y tratamiento de riesgos de seguridad de la informa-
ción – lo cual es mucho mejor. Le da el conocimiento para identificar
activos, amenazas y vulnerabilidades, para evaluar las consecuencias y
la probabilidad, para calcular el riesgo, etc. Y es totalmente compatible
con ISO 31000.
Así que, ¿Por qué usar ISO 31000? Además de las buenas prácticas ya
mencionadas para la identificación de los contextos internos y exter-
nos, su mayor valor está en que proporciona un marco de trabajo para
la gestión de todo tipo de riesgos, a nivel de toda la empresa – esto
puede ayudarle a convertir la gestión de riesgos, de algo obscuro y
difícil de entender, a algo que sea fácilmente entendido por todas las
personas en la empresa.
Puesto que la ISO 31000 describe cómo enfocar la gestión de riesgos

estratégicamente y de una manera comprensiva, puede considerar este
estándar como un excelente marco de trabajo para la gestión de ries-
gos empresariales (Enterprise Risk Management - ERM). Así que, una
vez que domine su gestión de riesgos de seguridad de la información,
puedo utilizarlo como una base para la construcción del ERM, aunque
en teoría hacerlo a la inversa podría ser mejor.
225
SEGURO & SIMPLE
13.4 ISO 27001 vs. ISO 27017 vs. Seguridad en la nube

El nombre oficial de la ISO/IEC 27017 es Code of practice for informa-
tion security controls based on ISO/IEC 27002 for cloud services (Códi-
go de buenas prácticas para controles de seguridad de la información
basados en ISO/IEC 27002), lo cual significa que este estándar se basa
en los controles de seguridad existentes en la ISO 27002. En otras pa-
labras, ISO 27017 sugiere controles adicionales de seguridad para la
nube, donde ISO 27002 no cubre adecuadamente esta área.
Vamos a ver el nivel en que ISO 27017 sugiere cambiar ISO 27001/
ISO27002:
Nivel de cambio
Dominio de control ISO 27001/ISO 27002
en ISO 27017
5 Políticas de seguridad de la información Moderado
6 Organización de la seguridad de la información Moderado
7 Seguridad relativa a los recursos humanos Moderado/Bajo
8 Gestión de activos Moderado/Bajo
9 Control de acceso Alto
10 Criptografía Moderado
11 Seguridad física y del entorno Moderado/Bajo
12 Seguridad de las operaciones Moderado/Alto
13 Seguridad de las comunicaciones Moderado/Alto
14 Adquisición, desarrollo y mantenimiento de los
Moderado
sistemas de información
15 Relaciones con proveedores Moderado/Alto
16 Gestión de incidentes de seguridad de la infor-
Moderado
mación
17 Aspectos de seguridad de la información para la
Bajo
gestión de la continuidad del negocio
18 Cumplimiento Moderado/Alto
Por lo tanto, ISO 27017 sugiere cambios en la mayoría de las secciones de

controles - los mayores cambios se proponen en el área de Control de acce-
226
so, por ejemplo: 9.2.1 Registro y baja de usuario, 9.2.2 Provisión de acceso
de usuario, 9.2.3 Gestión de privilegios de acceso, 9.4.1 Restricción del ac-
ceso a la información, y 9.4.4 Uso de utilidades con privilegios del sistema.
Si comparamos ISO 27017 e ISO 27018 con respecto el tipo de cambios que
proponen, se dará cuenta de que ISO 27017 propone más cambios en con-
troles existentes, mientras que ISO 27018 propone más controles nuevos.
ISO 27017 sugiere siete nuevos controles, y la numeración de estos

controles es compatible con la estructura de ISO 27001/ISO 27002:
● 6.3.1 Roles y responsabilidades compartidas en un entorno de

computación en la nube
● 8.1.5 Eliminación de activos de clientes de servicios en la nube
● 9.5.1 Segregación en entornos de computación virtual
● 9.5.2 Virtual machine hardening
● 12.1.5 Seguridad operacional del administrador
● 12.4.5 Monitorización de servicios en la nube
● 13.1.4 Alineación de la gestión de la seguridad para redes virtua-

les y físicas
Por tanto, no hay nada espectacular aquí – sobre todo lo que existe es
sentido común a la hora de hablar de seguridad en la nube.
¿ISO 27001, ISO 27017, o ISO 27018? Mientras existan más estánda-
res, será más difícil elegir... En cualquier caso, ISO 27001 es un están-
dar básico perfecto para todas las empresas que quieran proteger su
información – es, de lejos, el estándar más popular de seguridad de la
información en todo el mundo, proporciona un marco de trabajo para
la gestión de la seguridad, y es el único que puede proporcionar la emi-
sión de un certificado.
27017 es ciertamente atractivo para las empresas que ofrecen servicios

en la nube, y quieren cubrir todos los ángulos cuando se trata de la segu-
227
SEGURO & SIMPLE
ridad en la computación en la nube. Por otra parte, ISO 27018 está más
enfocado hacia empresas que manejan datos de carácter personal y quie-
ren asegurarse de que protegen estos datos de la manera más adecuada.
Por lo tanto, la empresas que proporcionan servicios en la nube pro-

bablemente preferirán una combinación de la implementación de ISO
27001 e ISO 27017, mientras que las empresas que proporcionan ser-
vicios en la nube y tienen un montón de datos de carácter personal,
probablemente preferirán los tres: ISO 27001, ISO 27017 e ISO 27018.
13.5 ISO 27001 vs. ISO 27018 vs. Privacidad en la nube

ISO 27001 es un marco de trabajo ideal para lograr la privacidad, es
decir, para la protección de datos personales, porque todo el estándar
tiene como objetivo la protección de datos. Pero aún más importante -
muchas de las leyes de privacidad y los reglamentos de todo el mundo,
se han escrito basándose en el estándar ISO 27001. Básicamente, todas
las medidas de protección sugeridas por ISO 27001 son adecuadas para
la protección de datos personales, y la mayoría de la legislación no re-
quiere controles adicionales a los que ya están incluidos en ISO 27001.
ISO 27018 trata todo lo relativo a la protección de datos personales,

pero desde el punto de vista de la nube – su nombre completo es
ISO/IEC 27018 Code of practice for protection of personally identifia-
ble information (PII) in public clouds acting as PII processors (Código
de buenas prácticas para la protección de información personalmente
identificable, en nubes públicas actuando como procesadores de infor-
mación personalmente identificable). ISO 27018 trabaja de dos mane-
ras: (1) aumenta los controles existentes en ISO 27002 con elementos
específicos para la privacidad en la nube, y (2) proporciona controles de
seguridad completamente nuevos para los datos personales.
Aquí tiene un resumen de en qué grado ISO 27018 sugiere que deben
incrementarse los controles existentes:
228
Nivel de elementos
Dominio de control
adicionales en ISO
ISO 27001/ISO 27002
27018
5 Políticas de seguridad de la información Moderado
6 Organización de la seguridad de la in-
Bajo
formación
7 Seguridad relativa a los recursos huma-
Bajo
nos
8 Gestión de activos Bajo
9 Control de acceso Bajo
10 Criptografía Bajo
11 Seguridad física y del entorno Bajo
12 Seguridad de las operaciones Alto
13 Seguridad de las comunicaciones Bajo
14 Adquisición, desarrollo y mantenimien-
Bajo
to de los sistemas de información
15 Relación con proveedores Bajo
16 Gestión de incidentes de seguridad de
Moderado
la información
17 Aspectos de seguridad de la informa-
ción para la gestión de la continuidad del Bajo
negocio
18 Cumplimiento Moderado
Como puede ver, ISO 27018 sugiere los cambios más grandes en la
sección 12 Seguridad de las operaciones – Esto es principalmente para
los controles 12.1.4 Separación de los recursos de desarrollo, prueba
y operación (cuando se utilizan datos de carácter personal para prue-
bas); 12.3.1 Copias de seguridad de la información (múltiples copias de
datos, procedimientos para las copias de seguridad, su recuperación y
eliminación; proporcionar información al cliente); y 12.4.1 Registro de
eventos (procesos para revisar registros; registro de información privada
que haya cambiado; proporcionar información al cliente). Además de
los cambios de la sección 12 Seguridad de las operaciones, los elemen-
tos adicionales en otras secciones son sorprendentemente pequeños.
229
SEGURO & SIMPLE
Nuevos controles para la privacidad en la nube. El Anexo A de ISO
27018 enumera los siguientes controles adicionales (que no existen en
ISO 27001/27002), y que deben aplicarse para aumentar el nivel de
protección de los datos personales en la nube:
● Derechos del cliente para acceder y borrar datos
● Procesamiento de los datos únicamente para la finalidad para la
cual el cliente ha proporcionado estos datos
● No utilizar los datos para marketing y publicidad
● Eliminación de ficheros temporales
●N
otificación al cliente en caso de una solicitud de divulgación de datos
● Registro de todas las divulgaciones de datos personales
● Revelación de la información acerca de todos los subcontratistas
utilizados para el procesamiento de los datos personales
● Notificación al cliente en caso de un robo de datos
● Gestión documental para procedimientos y políticas de la nube
● Política de devolución, transferencia y eliminación de datos per-
sonales
● Acuerdos de confidencialidad para las personas que pueden acce-
der a datos personales
● Restricción a la hora de imprimir datos personales
● Procedimiento para la restauración de datos
● Autorización para llevar los medios físicos fuera de las instalaciones
● Restricción del uso de medios que no tiene capacidad de cifrado
● Cifrado de datos que se transmiten a través de redes públicas
● Destrucción de los medios impresos con datos personales
● Uso de identificadores únicos para los clientes de la nube
● Registros de acceso del usuario a la nube
230
● Deshabilitar el uso de IDs caducados
● Especificar mínimos controles de seguridad en los contratos con
los clientes y subcontratistas
● Eliminación de datos en almacenaje asignado a otros clientes
● Revelar al cliente en qué países estarán almacenados los datos
● Asegurar que los datos alcanzan su destino
Todo esto es sentido común, y me pareció bastante útil tener todos estos
controles enumerados en un único documento. Por supuesto, ISO 27018
proporciona una explicación detallada de cada uno de estos puntos.
13.6 ISO 27001 vs. ISO 27032 vs. ciberseguridad

Podemos definir la ciberseguridad como las medidas adoptadas para
proteger y asegurar la información en línea, y la infraestructura en la que
esta reside, contra abusos o interrupciones. Los principales aspectos que
deben protegerse son la confidencialidad de la información almacenada
en las Tecnologías de la Información y Comunicación (TIC), la integridad
de esa información, y la disponibilidad y confiabilidad de las TIC.
Por lo tanto, la ciberseguridad realmente es una parte de la gestión de

seguridad de la información definida por ISO 27001 – una parte que
se centra en datos digitales, especialmente en los datos archivados o
procesados a través de redes públicas.
Ciberseguridad, ciberespacio e ISO 27032. ¿Qué es el ciberespacio?

Es el lugar virtual donde todo el mundo hace negocios, estudios, o hace
transacciones. ISO 27032 define el término de la siguiente manera: «un
entorno complejo que resulta de la interacción de personas, software
y servicios en Internet, por medio de dispositivos tecnológicos, y redes
que conectan con él, y que no existe en forma física.”
¿Y la ciberseguridad? Es principalmente todo lo relacionado con la

seguridad del ciberespacio a través de las medidas de seguridad que lo
231
SEGURO & SIMPLE
protegen. Y este estándar, ISO 27032, proporciona una guía que nos
ayudará a asegurar que nuestra interacción con el entorno virtual del
ciberespacio es mucho más segura.
Diferencias entre ISO 27001 e ISO 27032. ISO 27032 no es un están-

dar que pueda certificar su empresa; tal vez esta es una de las diferen-
cias más importantes con respecto a la ISO 27001.
Sin embargo, estos dos estándares están estrechamente relacionadas.

ISO 27032 principalmente tiene como objetivo proporcionar una guía
para la ciberseguridad, a través de recomendaciones específicas, mien-
tras que ISO 27001 establece los requisitos para establecer un SGSI.
Así, el enfoque del estándar ISO 27001 es su organización y la gestión
de la seguridad, mientras que ISO 27032 se centra en el ciberespacio,
y es un marco de trabajo para abordar cuestiones relacionadas con la
seguridad en el ciberespacio.
A diferencia de la ISO 27001, ISO 27032 especifica varios tipos de ac-

tivos y no contiene un catálogo de amenazas y vulnerabilidades como
ISO 27005. Por otra parte, ISO 27001 establece varios requisitos que no
tiene ISO 27032: la metodología de gestión de riesgos debe cubrir, por
ejemplo, el establecimiento de criterios para la aceptación de riesgos,
el propietario del riesgo, el riesgo residual, etc.
Controles. Los controles que se pueden encontrar en ISO 27032 son, como
se esperaba, más específicos para la ciberseguridad (controles de nivel de
aplicación, protección del servidor, usuario final, controles de ataques de
ingeniería social, etc.). Además, ISO 27032 proporciona una guía detallada
para cada control. Por lo tanto, ISO 27001 es más amplia y global, mientras
que ISO 27032 es más concreta y específica para la ciberseguridad.
Otro componente importante que se puede encontrar en ISO 27032 es

un marco de trabajo para el intercambio y coordinación de información,
que es particularmente interesante a la hora de gestionar incidentes re-
lacionados con la ciberseguridad. ISO 27001 también tiene controles
en el anexo A para la gestión de incidentes, pero son principalmente
para incidentes internos de la organización.
232
13.7 Relación entre ISO 22301, ISO 20000, ISO 9001,

ISO 14001 e ISO 45001
ISO 27001 no es el único estándar de gestión – realmente incluso no es uno
de los más populares. Estándares como ISO 9001 (gestión de la calidad), ISO
14001 (gestión medioambiental) e ISO 45001 (gestión de seguridad y salud
en el trabajo, que en el momento de escribir este libro este estándar está to-
davía en desarrollo, y se espera que reemplace la actual OHSAS 18001) son
mucho más populares que el estándar ISO 27001. Existen otros estándares
de gestión que tampoco son muy populares, como ISO 20000 (gestión de
servicios TI) e ISO 22301 (gestión de la continuidad del negocio). (Nota: El
Appendix E le mostrará una comparativa entre ISO 27001 e ISO 20000.)
¿Son estándares muy diversos? A primera vista sí, pero si usted echa un
vistazo, verá muchas más similitudes de las que esperaría.
La organización ISO ha hecho una cosa muy inteligente – ha emitido un

estándar sobre los estándares, o para ser más precisos – ha publicado el
llamado “Anexo SL”, que define una estructura obligatoria para todos
los estándares de gestión. Esto significa que todos los estándares de
gestión mencionados anteriormente, tienen las mismas 10 cláusulas
que he descrito en la sección 2.8 de este libro.
Por supuesto, las cláusulas 6 (Planificación) y 8 (Operación) son muy diferen-

tes en cada uno de estos estándares, pero créame – las cláusulas 4 (Contex-
to de la organización), 5 (Liderazgo), 7 (Soporte), 9 (Evaluación del desem-
peño) y 10 (Mejora) son muy similares en todos los estándares de gestión.
¿Qué significa esto? Esto significa que si escribe un procedimiento para

un estándar, no tiene que escribir el mismo procedimiento con el mis-
mo propósito para otro estándar. Aquí tiene lo que es común para
todos estos estándares:
● Gestión de documentos – el procedimiento utilizado para la

gestión de documentos en, por ejemplo el estándar ISO 27001,
puede utilizarse para el mismo propósito en ISO 9001, con sólo
pequeños ajustes.
233
SEGURO & SIMPLE
● Auditoría interna – el mismo procedimiento puede utilizarse
para dos o más estándares, aunque cada auditoría interna gene-
ralmente la realizarán diferentes personas, ya que no es muy pro-
bable que una persona tenga un profundo conocimiento de por
ejemplo la seguridad de la información y de la calidad.
●A
cciones correctivas – el procedimiento utilizado para ISO
27001 se puede utilizar para el mismo propósito en el estándar
ISO 14001, u otros estándares, aunque es probable que diferentes
personas resuelvan temas relacionados con diferentes sistemas.
● Gestión de recursos humanos – el mismo ciclo de planificación
para los Recursos Humanos, la formación, y la evaluación, se utili-
za para todos los sistemas de gestión; Naturalmente, la diferencia
está en el perfil de conocimientos y habilidades necesarias.
● Revisión por dirección – los principios para la revisión por direc-
ción son los mismos para todos los sistemas de gestión; Aunque
no sería recomendable realizar dos revisiones en paralelo, ya que
la dirección tendrá que estar acostumbrada a tomar decisiones en
el SGSI, y puede que tengan mejor conocimiento de cómo tomar
decisiones en otros sistemas de gestión.
● Establecer metas para el negocio y medir si se han logrado - el
mismo mecanismo se establece en todos los estándares, por lo
que se utilizará el sistema de gestión para una planificación siste-
mática, y para obtener reportes.
Lo que he descrito arriba también es conocido como un sistema de
gestión integrado - esto se produce cuando se combinan procesos, pro-
cedimientos y políticas de diferentes sistemas de gestión, en un solo
sistema. Este enfoque es ciertamente preferible que tener, por ejem-
plo, un procedimiento de auditoria interna de ISO 27001, y luego otro
procedimiento muy similar para la auditoria interna de ISO 14001. En
realidad, existe un estándar que se centra en la creación de un sistema
de gestión integrado – se llama PAS 99.
En otras palabras, si ya ha implementado ISO 9001, tendrá un trabajo
muy fácil si desea implementar ISO 27001 (y viceversa) - usted podría
234
ahorrar hasta un 25% del tiempo de implementación. Además, podrá
tener auditorías de certificación más baratas, puesto que las entidades
certificadoras están ofreciendo lo que se conoce como “auditorías inte-
gradas”, lo que significa que ofrecen una misma auditoría de ISO 9001
e ISO 27001, lo que implica que le cobrarán una tarifa más pequeña en
comparación con auditorías separadas.
La integración más apretada puede realizarse entre ISO 27001 e ISO

22301, como se describe en la siguiente sección.
13.8 Usar la ISO 22301 para la implementación de la

continuidad de negocio en ISO 27001
Uno de los mayores misterios en la implementación del estándar ISO
27001 es la sección A.17 del Anexo A, que habla sobre la gestión de
la continuidad del negocio. Desafortunadamente, ISO 27001 no pro-
porciona muchos detalles cuando se trata este tema. Para agregar más
confusión, ISO 27001 habla de “aspectos de seguridad de la informa-
ción para la gestión de la continuidad del negocio”.
¿Cómo de similares son ISO 27001 e ISO 22301? En primer lugar, la
seguridad de la información y la continuidad del negocio tienen una
cosa muy importante en común: ambas protegen la disponibilidad de
la información – esto es por lo que ISO 27001 necesita incluir controles
de continuidad de negocio en su anexo A.
ISO 22301 es el estándar líder internacional de continuidad de negocio,
y al igual que los estándares de gestión ISO, se basa en el ciclo Plan-Do-
Check-Act. Esto significa que tiene prácticamente los mismos elementos
de gestión que ISO 27001 y otros estándares ISO, como se describe en
la sección anterior.
Por lo tanto, si ya ha implementado todos estos elementos para ISO 27001,
entonces está ya casi cumpliendo completamente con la ISO 22301 a la
hora de gestionar el sistema. También existe algunos elementos de la ISO
27001 que son totalmente compatibles con ISO 22301 – por ejemplo,
la gestión de riesgos, por lo que puede llevar a cabo un único análisis de
riesgos para satisfacer los requerimientos de ambos estándares.
235
SEGURO & SIMPLE
Dónde son diferentes. ISO 27001 es bastante pobre cuando se trata
de la documentación de la continuidad de negocio – es básicamente
suficiente con escribir un plan de recuperación ante desastres para cubrir
el control A.17.1.2 (que requiere la aplicación de procedimientos de con-
tinuidad) y el control A.17.2.1 (el cual requiere la disponibilidad de TI, es
decir, la redundancia).
Por otra parte, como podría esperarse, ISO 22301 requiere el desarrollo
de más documentos, muchos de estos para los siguientes elementos de
continuidad de negocio:
● Política de continuidad de negocio
● Análisis de impacto en el negocio
● Estrategia de continuidad de negocio
● Planes de continuidad de negocio
● Ejercicios y pruebas
Así que, ¿Qué significa esto en la práctica? Aunque ISO 27001 le per-
mite implementar la continuidad de negocio con un único documento;
en realidad, si usted quiere preparar su empresa correctamente, necesi-
tará más. E ISO 22301 le proporciona el conocimiento necesario.
Cómo usar ISO 22301 para ISO 27001. En mi opinión, la mejor ma-
nera de utilizar estos conocimientos de ISO 22301, es implementarlos
como un sub-proyecto de ISO 27001 – es decir, debe implementar la
ISO 27001 como usted ha planeado, y cuando llegue a la sección A.17,
debe implementar los principales elementos de continuidad de negocio
de ISO 22301, mencionados anteriormente.
En efecto, puesto que todos los demás elementos del estándar ISO
22301 son iguales que en ISO 27001, implementará estos dos están-
dares al mismo tiempo. Y lo mejor de todo - este esfuerzo adicional es
sólo el 10% del esfuerzo de implementación de toda la ISO 27001.
Por lo tanto, es cierto que puede cumplir con la sección A.17 en ISO
27001 escribiendo un único documento – el plan de recuperación ante
236
desastres. Sin embargo, ISO 22301 le permite hacer mucho más – pre-
parar su empresa para realmente continuar todas sus operaciones cru-
ciales si ocurre un verdadero desastre.
13.9 ISO 27001 y COBIT, PCI DSS, NIST SP800,

NIST Cybersecurity Framework e ITIL
Aquí tiene una lista de marcos de trabajo y estándares que de alguna
manera están relacionados con ISO 27001 – en la mayoría de los ca-
sos, la documentación y los procesos que se crean para ISO 27001, se
pueden utilizar también para estos estándares y marcos de trabajo, y
viceversa – hablaré más sobre esto en la siguiente sección.
COBIT es un marco de trabajo para el gobierno de TI, publicado por

ISACA. Puesto que está orientado principalmente hacia la gestión de
TI, tiene un gran solapamiento con parte de la gestión de la ISO 27001,
así como con los controles de TI del anexo A. Pero a diferencia de la ISO
27001, una empresa no puede obtener la certificación contra COBIT.
PCI DSS es un estándar de seguridad de la información enfocado en la

seguridad de las tarjetas de crédito; publicado por el Payment Card In-
dustry Security Standards Council, un organismo fundado por las com-
pañías de tarjetas de crédito más importantes. PCI DSS es mucho más
específico que el estándar ISO 27001 para los controles de seguridad,
porque describe ciertas tecnologías y métodos; por supuesto, estos 2
estándares tienen grandes solapamientos en los controles de seguridad
de TI, aunque PCI DSS es mucho más específico, pero PCI DSS también
tiene otros controles que no son de TI, y que también se solapan con
ISO 27001, como por ejemplo la gestión de recursos humanos. La certi-
ficación PCI DSS la realizan asesores de seguridad calificados (Qualified
Security Assessors - QSA).
NIST SP800 es una serie de estándares de seguridad de la información,

y de guías de buenas prácticas publicadas por el gobierno de Estados
Unidos a través del NIST (National Institute of Standards and Technolo-
gy) – esta serie es de alguna manera similar a la ISO 27k, porque cubre
237
SEGURO & SIMPLE
aspectos muy diversos de la seguridad de la información, y a menudo
es mucho más detallada que los estándares de la serie ISO 27k. A pesar
de que no es posible la certificación de estos estándares, son muy po-
pulares debido a su alta calidad, y porque son gratuitos.
NIST Cybersecurity Framework es una colección de estándares, y guías

de buenas prácticas orientadas a la protección de infraestructuras críticas.
Se publicó por iniciativa de la Casa Blanca, y es utilizado principalmente
por agencias gubernamentales estadounidenses, y por organizaciones
de infraestructura crítica. La ISO 27001 y el Cybersecurity Framework son
bastante similares en su enfoque, aunque el Cybersecurity Framework es
mejor que el estándar ISO 27001 cuando se trata de estructurar las áreas
de seguridad que deben implementarse, y a la hora de definir exacta-
mente los perfiles de seguridad que deben ser alcanzados; ISO 27001 es
mejor para tener una visión integral: para el diseño de un sistema en el
que la seguridad se pueda manejar a largo plazo.
ITIL es un marco de trabajo para la Gestión de Servicios de TI, publica-

do por el Gobierno Británico a través de una empresa llamada Axelos.
Aunque ITIL es más similar a ISO 20000 que a ISO 27001, ITIL e ISO
27001 también tienen un gran solapamiento en todos los controles re-
lacionados con TI. No es posible la certificación de una empresa en ITIL.
13.10 ISO 27001 como plataforma de cumplimiento

para varios marcos de trabajo
Como puede ver, ISO 27001 es muy compatible con otros estándares
ISO; y también es bastante compatible con otros marcos de trabajo de
TI y de seguridad de la información; finalmente, como mencioné en el
capítulo 5, ISO 27001 también es bastante compatible con varias leyes
y regulaciones, y también puede ser compatible con requerimientos
contractuales.
Esto lo hace un candidato perfecto para ser un marco de trabajo de alto

nivel, el cual puede fusionarse otros marcos de trabajo en un solo siste-
ma - el hecho de que ISO 27001 no es demasiado detallado, realmente
238
le proporciona una ventaja: no tiene que aplicar una cierta metodolo-
gía que podría obtener de otros marcos de trabajo. En cambio, usted
puede seguir los pasos de alto nivel requeridos por ISO 27001, y cada
vez que necesite ser más específico, entonces puede aplicar algún otro
estándar o marco de trabajo, el cual le dará los detalles.
Por lo tanto, usted puede satisfacer ambos lados: desde el punto de vis-
ta de gestión, usted tendrá un sistema a través del cual puede contro-
lar todo lo relacionado con la seguridad de la información, y tampoco
tendrá que preocuparse de pasar de un marco de trabajo a otro; desde
el punto de vista de las operaciones de TI, usted tendrá la oportunidad
de implementar marcos de trabajo detallados y concretos, que comple-
tarán el punto vista de gestión de alto nivel, y este tipo de proyectos
técnicos lo entenderán mucho mejor los ejecutivos de la dirección.
239
14
CAPÍTULO EXTRA III: MINI CASOS DE
ESTUDIO DE ISO 27001
Cuando hice una encuesta sobre lo que debería incluir en este libro,
uno de los primeros resultados de la lista de deseos fueron los casos de
estudio. Sin embargo, dado que ISO 27001 tiene como objetivo la pro-
tección de la información, fue muy difícil encontrar gente de seguridad
que abriese sus corazones y hablase de sus experiencias (es decir, de sus
problemas y sus soluciones).
Así que tuve que conciliar estas dos cosas – dado que no pude conseguir
entrevistas con personas reales que hayan implementado ISO 27001 en
empresas reales, he escrito un par de mini casos de estudio de empresas
imaginarias. (En realidad, hay un caso de estudio real – lo encontrará al
final de este capítulo).
Pero no se preocupe – podrá ver que los casos de ficción se crean a partir
de experiencias reales de personas de empresas reales, por lo que po-
dríamos decir que, a pesar de que la historia no es real, los detalles son
algo que verá en su vida cotidiana.
Lo que creo que más le gustará de estos casos de estudio, es que se

centran en los mayores problemas que suelen encontrarse las empresas
a la hora de implementar ISO 27001; también cubren las industrias más
comunes donde se implementa este estándar.
14.1 D
efinir un alcance de SGSI para un pequeño
proveedor de servicios en la nube
La Compañía A ha desarrollado un software especializado que están uti-
lizando para proporcionar servicios en la nube a sus clientes. Tienen 15
empleados, algunos de los cuales trabajan en sus oficinas en New York
240
Capítulo extra III: Mini casos de estudio de ISO 27001
City, mientras que otros trabajan remotamente desde sus casas. Paul es el
CTO de la compañía, y ahora está a cargo de implementar la ISO 27001.
Cuando Paul comenzó a implementar la ISO 27001 en junio de 2015, fue
muy optimista y planificó terminar el trabajo en el Otoño del mismo año.
Sin embargo, en una fase muy temprana se enfrentó a un problema de
definición del alcance: ¿Deben incluirse en el alcance del SGSI los emplea-
dos que trabajan desde casa, o deben excluirse? ¿Qué pasa con la infraes-
tructura de servidores, ya que están en la nube (Amazon AWS) – ¿Debe
formar parte del alcance?
Paul empezó a recopilar alguna información en Internet, y empezó a
definir el alcance del SGSI; sin embargo no pudo encontrar la manera
de cómo hacerlo, ya que le resultó imposible excluir del alcance a los
empleados que trabajan desde su casa, ya que también manejan infor-
mación sensible, pero por otro lado la empresa no podía controlar la se-
guridad física de sus viviendas. Con respecto a Amazon AWS, Paul sabía
que estaban certificados en ISO 27001, pero no estaba seguro si podía
incluir los servidores en el alcance, dado que su empresa no los posee, ni
los controla físicamente.
Por tanto, Paul se dio cuenta de que tenía que cambiar su enfoque – le
preguntó a una amiga, Jessica, que tiene una empresa similar y que con-
siguió la certificación, cómo resolver este problema.
Esto es lo que ella le aconsejó: con respecto a los empleados, deben ser
incluidos en el alcance del SGSI, así como los portátiles de empresa con los
que trabajan; sin embargo sus oficinas de casa deben ser excluidas porque
la empresa no puede tener un control sobre esto. Este problema de segu-
ridad física más tarde se resolvió con la definición de estrictas políticas de
teletrabajo, con las que se establecieron claras reglas de seguridad.
Con respecto a Amazon AWS, de nuevo, la solución fue pensar en lo
que controlan - dado que controlan el sistema operativo, las aplicaciones
y la base de datos, esto iba a ser incluido en el alcance; el hardware, así
como las telecomunicaciones no estaban bajo el control de la empresa
A, así que esto fue excluido del alcance del SGSI.
Paul estaba muy contento con una solución tan fácil y simple, porque había
eliminado posibles problemas con la entidad certificadora, pero también vio
241
SEGURO & SIMPLE
claramente dónde enfocar sus esfuerzos a la hora de implementar el SGSI –
Paul estaba feliz porque podría pasar la mayor parte del tiempo trabajando
en la protección de la información más sensible de su empresa.
14.2 Aplicar principios de ingeniería seguros en una

empresa de desarrollo de software
La Compañía B es una compañía de desarrollo software especializada
en soluciones a medida para compañías de seguros. Su oficina central
está en Melbourne, Australia, con 52 empleados, y tienen una filial en
Mumbai, India con 200 empleados, donde se realiza la mayor parte del
desarrollo software. Jean es la responsable de proyecto para la imple-
mentación de la ISO 27001, quien tiene experiencia a nivel de gestión
de proyectos, pero no tiene un perfil TI.
Al principio, Jean no era muy entusiasta con ISO 27001 ya que oyó que
era un estándar muy orientado a TI, y aunque ella se comunicaba muy
bien con sus colegas de TI en la empresa, no estaba segura de si ella sería
capaz de controlar este proyecto. Pero vio esto como una oportunidad
de carrera, porque la seguridad se está convirtiendo en una gran opor-
tunidad laboral, así que se decidió a realizar el trabajo.
Cuando comenzó el proyecto, se dio cuenta muy rápidamente lo fácil

que era coordinar la redacción de algunos documentos de carácter ge-
neral, incluso logró coordinar con éxito el proceso de gestión de riesgos.
Pero una vez que comenzó la implementación de controles específicos
de TI, se encontró en una posición donde sus miedos se hicieron reali-
dad - ella no era capaz de explicar a los chicos de TI qué tipo de seguri-
dad tenían que implementar. El mayor problema lo tenía con la sección
A.14.2, en particular con los principios de ingeniería seguros - Vijay, jefe
de desarrollo de software en Mumbai, fue muy entusiasta sobre mejorar
la seguridad, pero le pidió instrucciones específicas de lo había que ha-
cer, y ella no sabía qué decirle.
Así que después de consultar con un par de colegas que conoció en una
conferencia de seguridad, se dio cuenta de cuales deberían ser los próxi-
mos pasos: le pidió a Vijay que estudiase literatura sobre desarrollo de
242
software seguro, específico para la tecnología que estaban usando, y tam-
bién le pidió que viese algunos cursos en línea sobre el tema; Jean le dijo
que tenía 3 semanas para prepararlo todo, y después iría a Mumbai para
trabajar junto a él.
Cuando Jean llegó a Mumbai, comenzó una serie de reuniones con

su equipo – ella básicamente les dijo que, dado que la ISO 27001 no
describe los detalles sobre el desarrollo de software seguro, tenían que
averiguar las reglas ellos mismos. Así que acordaron que al diseñar el
software, tenían que incluir requisitos de seguridad en cada uno de los
pasos del diseño del software – y esta planificación se tenía que hacer
formalmente a través de documentación, que se pusieron de acuerdo
que tendrían que desarrollar de ahora en adelante. Resultó que el equi-
po de Vijay ya cuidaba la seguridad, pero nunca de manera estructurada
y formal, por lo que esto no resultaba ser un problema para ellos - sólo
tenían que escribir lo que ya hacían.
Después de seis meses, cuando los auditores de su cliente más impor-

tante vinieron a examinar su proceso de desarrollo de todo el software,
estaban encantados de ver el proceso sistemático que habían definido.
14.3 Concientización en una agencia del gobierno

La Agencia C es un organismo del gobierno suizo, que tiene como car-
go la supervisión de parte de la industria financiera. Tiene cerca de 300
empleados en varias oficinas repartidas por el país – la media de edad
de los empleados es de 40 años, y muchos de ellos llevan trabajando en
la agencia más de 7 años. Emma es miembro del equipo de proyecto de
la ISO 27001, y está a cargo de la seguridad de los recursos humanos.
Cuando Emma fue nombrada como miembro del equipo de proyecto
de ISO 27001, y le asignaron el trabajo de organizar la concienciación y
capacitación en seguridad, estaba emocionada y preocupada – y dado
que su agencia estaba tratando con algunos datos muy sensibles de la
industria financiera, sabía lo importante que era mejorar su seguridad;
por otra parte sabía lo difícil que era cambiar las cosas en la agencia.
Este temor resultaba correcto – sus colegas fueron los encargados de
243
SEGURO & SIMPLE
escribir los procedimientos y las políticas de seguridad, y fueron muy
ignorados por los jefes de los departamentos, los cuales deberían haber
participado en este proceso, incluso en algunas ocasiones fueron ridi-
culizados. Cuando Emma trató de organizar una presentación sobre la
importancia de la ISO 27001, y los principales elementos del estándar,
sólo un tercio de los trabajadores invitados estuvieron atentos; el resto
estaban más interesados en sus teléfonos que en su presentación.
Emma entendió que tenía que cambiar el enfoque, pero inicialmente no
estaba segura de qué tenía que hacer. Después de hablar con un par de
amigos en la agencia, se dio cuenta que realmente nadie echaba cuenta
al proyecto, y la mayoría de la gente lo vio como una carga innecesaria -
básicamente, nadie vio nada positivo en este proyecto.
Por tanto, aquí es donde ella entendió dónde estaba el problema - además
de su equipo de proyecto, nadie entendía por qué se había iniciado este
proyecto. Así que decidió cambiar su enfoque: empezó primero a hablar
con dos de los diputados más influyentes de la Dirección de la agencia –
les explicó cuáles eran los beneficios del proyecto. Por suerte, aceptaron
sus argumentos muy rápidamente y prometieron que ayudarían cuando
fuese necesario. Después de esto, visitó a 8 jefes de departamento, y bási-
camente utilizó la misma táctica - tuvo éxito con 5 de ellos, mientras que
para el resto tuvo que pedir la ayuda de los diputados.
Por lo tanto, convenciendo a la dirección, y a los responsables de nivel
medio, sobre los beneficios de este proyecto, consiguió una posición mu-
cho mejor para empezar a trabajar con el resto de los empleados – en
su siguiente sesión de capacitación, el 70% de los trabajadores invitados
demostraron atención, y en el resto de las sesiones llegó incluso al 90%.
Ella también cambió su estilo de presentación - en lugar de pasar muchas
diapositivas de PowerPoint, utilizó sólo 4 ó 5 durante toda la sesión, y se
centró mucho más en la interacción con los empleados. Emma estimuló
a los asistentes a hablar abiertamente sobre los problemas reales que
tenían en su trabajo cotidiano, y cómo este proyecto podía ayudarles a
resolver estos problemas. Este enfoque de trabajo – muy a menudo ha
iniciado una acalorada discusión, pero en última instancia, la mayoría de
la gente entiende la necesidad del cambio.
244
14.4 Obtener el apoyo de la alta dirección en una

compañía de propiedad estatal
La Compañía D es una empresa de servicios públicos, que opera en Mé-
xico. Tienen 3000 empleados, y su alta dirección es nombrada por el go-
bierno local, generalmente como un compromiso entre varios partidos
políticos – la actual dirección tiene el mandato para el próximo año y
medio. Juan es el jefe del departamento de TI, y está a cargo de la imple-
mentación de la ISO 27001.
Juan odiaba el día en el consiguió el trabajo, hace 1 mes, para la im-
plementación de la ISO 27001 – otras personas intentaron lanzar el
proyecto sin éxito, y ahora era obvio que nadie querría acercarse a este
proyecto; nadie parecía saber por qué se inició el proyecto (el proyecto
fue iniciado hace 2 años por el antiguo director general, pero este fue
despedido poco después). Así que Juan consiguió este trabajo porque
parecía que era el más cercano a la seguridad de la información.
Desde el principio las cosas iban muy mal – el director general no le
permitía organizar un equipo de proyecto, no le daba un presupuesto, y
tenía que compatibilizar el proyecto junto con su actual trabajo, aunque
su trabajo ya le requería quedarse horas extras.
Por lo tanto, se dio cuenta de que tenía que decidir – dejar la empresa,
o tener éxito con este proyecto cambiando cosas drásticamente. Juan
también sabía que no podía lograr nada sin antes tratar con el director
general. Por lo tanto, decidió usar un enfoque diferente - ofrecer algo
positivo en lo que el director general viese interés, y hacer algo que le
ayudase a convencerlo.
Juan comenzó a trabajar con el departamento jurídico, y encontró una re-
gulación que requería la implementación del estándar ISO 27001 en los
servicios públicos – lo curioso es que, muy pocas empresas han cumplido
dicha regulación, y la Agencia de gobierno que estuvo a cargo de la supervi-
sión de dicha regulación, estuvo tratando de encontrar buenos ejemplos de
implementaciones, por lo que podrían servir de ejemplo y estimular a otras
empresas. Juan se dio cuenta de que esto sería una muy buena oportunidad
política para el director general, porque necesitaba ser reelegido en breve,
así que necesitaba que sucediese algo positivo en su empresa.
245
SEGURO & SIMPLE
Por otra parte, Juan recordó a un viejo amigo del colegio que era muy
influyente en uno de los partidos políticos que decidieron la elección del
director general - a través de él, consiguió que el director general apro-
base el presupuesto y el equipo de proyecto que necesitaba.
Y la estrategia de Juan funcionó – obtuvo el compromiso del director gene-
ral, pero consiguió mucho más – el director general vio esto como una de
sus principales oportunidades para la reelección, por lo que cada vez que el
proyecto tuvo problemas, el director general los resolvió muy rápidamente.
14.5 Listar las partes interesadas y sus relaciones en

un banco Europeo
El Banco E es un banco con 1000 empleados, ubicado en Alemania –
tienen 50 sucursales y una sede principal en Munich. Proporcionan ser-
vicios de banca universal a clientes privados y pequeñas empresas. Leon
es el CISO, a cargo de la implementación de la ISO 27001.
Cuando la autoridad central bancaria presionó a los bancos para reforzar
la seguridad de la información, Leon estaba emocionado, previamente
trabajó como administrador de seguridad de TI, pero no pudo conseguir
que sus ideas las escuchasen los que toman decisiones. Poco después de
esto se publicaron las nuevas regulaciones, y Leon consiguió cambiar de
puesto – obtuvo la posición de CISO que soñó tanto tiempo.
Sin embargo, ahora se enfrentaba a un problema totalmente diferente
– en vez de tratar con las computadoras, de repente tuvo que tratar con
la gente, de organizar las cosas... y la gente es mucho menos predecible
que las computadoras.
Dado que eligieron ISO 27001 como marco de trabajo para cumplir con
las nuevas regulaciones, una de las primeras tareas fue identificar to-
dos los requisitos de las partes interesadas. Leon intentó hacer esto por
si mismo, pero dadas las distintas leyes y reglamentos que existen, no
pudo averiguar cuales serían relevantes para su banco; intentó hablar
con el director general del Banco y uno de sus delegados, pero le anula-
ron la reunión porque pensaron que esto sería una pérdida de tiempo.
246
Por lo que le pidió a un amigo, que había trabajado como consultor de
seguridad, que le ayudase - este amigo realmente le dio varios consejos.
Le dijo “en primer lugar tienes que identificar todas las partes interesadas
– piensa quién estaría afectado por una fuga de datos del banco. Segu-
ramente sean los clientes, pero quizás también incluirías a sus socios”. Y
agregó “también debes pensar a quién puede influir la seguridad de la
información del banco, y definitivamente hay que pensar en las agencias
del gobierno, pero también pueden ser algunos proveedores importantes,
los empleados, sus familias, etc.” y agregó “una vez que tengas esta lista,
el segundo paso es fácil, simplemente tienes que preguntarte qué es lo
que requieren estas partes interesadas del banco.”
Leon ya sabía por dónde empezar - tenía que hablar con la gerencia
media, es decir, con los jefes de varios departamentos, y preguntarles
sobre las partes interesadas relevantes para su línea de trabajo. Resultó
que además de la autoridad central bancaria, la autoridad fiscal también
estaba muy interesada (debido a la forma que usan los bancos para
controlar el flujo de dinero), los clientes (por supuesto, querían que la
información sobre sus cuentas estuviese protegida), la empresa que ha
desarrollado el software para el banco (requiere mayor presupuesto para
características adicionales de seguridad de TI), los empleados que traba-
jan con los clientes privados más importantes (querían instrucciones más
claras, y capacitación para cuando se trabaja con información altamente
sensible), etc.
Cuando presentó los resultados a su jefe, los resultados fueron mucho
mejores de lo que esperaba – su jefe pasó esta información a la alta direc-
ción, y la utilizaron para hacer algunos cambios estratégicos. Su jefe indicó
que uno de los directivos dijo que “nunca fueron conscientes de muchos
de estos requisitos, y ahora estaban contentos de haber revelado estas
cuestiones de manera temprana, antes de causar daños mayores”.
247
SEGURO & SIMPLE
14.6 Escribir las políticas de seguridad de la

información en una compañía de manufacturación
La Compañía F es una empresa Británica, centrada en el desarrollo y
producción de equipamiento especializado óptico de alta precisión, para
el ejercito. Además de la sede principal y una planta de producción en
Londres, tienen una segunda planta de producción en la zona industrial
de Milán, Italia. Oliver es un ingeniero en la compañía, pero también es
un representante de la gestión de la calidad, y está a cargo de la imple-
mentación de la ISO 27001.
Oliver era consciente de las similitudes entre ISO 9001 e ISO 27001, y
cómo ya tenía implementado el SGC, sabía que iba a ser más fácil imple-
mentar la ISO 27001. Sin embargo, no estaba muy emocionado cuando lo
designaron como jefe de proyecto para la implementación de ISO 27001
– recordaba muy bien los problemas que surgieron cuando su empresa
adquirió una fábrica en Italia. Esta adquisición ocurrió aproximadamente
al mismo tiempo que cuando fue nombrado como el representante de la
gestión de la calidad – el mayor problema fue cómo llevar dos culturas
completamente diferentes a trabajar bajo las mismas reglas.
Sus temores se hicieron realidad - cuando escribió la política de seguridad

de la información de alto nivel, fue aceptada bastante bien en la parte de la
compañía en Reino Unido, sin embargo los empleados de la parte italiana
parecieron ignorarla completamente. Cuando organizó sesiones de concien-
ciación, los resultados nuevamente fueron totalmente contrarios - la sesión
fue muy bien en el Reino Unido, mientras que en Italia fue todo lo contrario.
Dado que la ISO 27001 no fue el único responsable de la implementación

de las políticas de seguridad (también algunos de sus clientes le obligaron
a implementar políticas y procedimientos de clasificación), Olvier decidió
hacer una pausa en el proyecto de SGSI, porque sabía que saldría mal si no
cambiaba nada; entonces contrató a un consultor local en Italia para que le
ayudase, y el consultor le proporcionó varias ideas muy buenas: primero le
sugirió que cada documento debía ser revisado por un empleado de Reino
Unido y un empleado de Italia; en segundo lugar le sugirió que cambiase
el estilo de la sesión de concienciación, y utilizase muchos más ejemplos,
muchos de los cuales deben ser de cada mercado local.
248
Oliver siguió sus consejos, y al principio fue difícil encontrar a la persona
adecuada de Italia para la revisión de los documentos - tuvo que cambiar
dos personas antes de encontrar la adecuada: su nombre era Isabella, y
era una de las principales ingenieras de la planta italiana. Dado que era
muy comunicativa y respetada en esa planta de producción, logró empe-
zar a cambiar la impresión general sobre los documentos de seguridad.
Para las sesiones de concienciación italianas tuvo que hacer una investi-
gación para encontrar varios ejemplos de incidentes de seguridad ocu-
rridos en Italia, en empresas similares a la suya – decidió utilizar estos
ejemplos como su tema principal; también pidió a Isabella participar en
una parte de la sesión. Este enfoque mostró mucho mejores resultados -
la gente empezó a escucharlo.
Varios meses más tarde, uno de sus clientes (un militar de un país eu-
ropeo) auditó su compañía para asegurarse de que aplicaban todos los
controles de seguridad establecidos en sus acuerdos. Esta vez Oliver tuvo
una tarea fácil – el auditor tardó 1 día menos en la auditoría, porque la
documentación estaba muy claramente estructurada, y obviamente se
estaba usando en las actividades diarias de toda la empresa.
14.7 P
reparar una compañía de telecomunicaciones
para la certificación
La Compañía G es un pequeño operador de telecomunicaciones ubicado
en los Países Bajos – tienen un equipo joven y ambicioso, y son la em-
presa de telecomunicaciones con un crecimiento más rápido en el país.
Proporcionan principalmente servicios de acceso a Internet a clientes
corporativos. Jan es el CTO (Chief Technology Officer) en la compañía, y
también está a cargo de la seguridad.
Cuando Jan se unió a la empresa hace 7 años en sus inicios, nunca pensó
que podrían lograr gran cosa: al principio no tenían nada, y ahora ya tie-
nen un mercado sólido, y una muy buena reputación; algunos inversores
ya han comenzado a mostrar interés en su compañía.
Pero también tiene una desventaja este rápido crecimiento – muy a me-
nudo no está claro quién debe hacer algo, o quién tiene que tomar
249
SEGURO & SIMPLE
decisiones, quién está a cargo de las actividades, cuáles son los pasos
para realizar ciertas actividades, etc. Y había otro tema que se estaba
convirtiendo cada vez más en un problema – la seguridad de los datos.
Dado que todos los sistemas fueron desarrollados con prisas, a nadie
realmente le importaba que su diseño fuese seguro. Por esta razón Jan
coincidió con sus colegas en que se encargarían de la seguridad – no
querían dejar abandonado un tema tan importante.
Hace unos 6 meses, el director general y el CMO (Chief Marketing Offi-
cer) insistieron en que querían ir a por la certificación de ISO 27001,
porque esto le daría un impulso adicional a sus ventas. Naturalmente,
Jan asumió el control de este trabajo como responsable de proyecto, y
contrató a un consultor para implementar el estándar.
Sin embargo, a lo largo de la implementación, Jan ha encontrado un
problema: mientras que una parte del área de tecnologías de la empresa
(de la que Jan estaba a cargo) estaba bastante conforme con aceptar
los cambios, e introducir políticas y procedimientos de seguridad, partes
del área administrativa, y de ventas y marketing de la organización, sim-
plemente no tenían tiempo o no querían ocuparse de esto. Por lo que
en la mayoría de los casos, para las áreas administrativas y de ventas y
marketing, el consultor escribió la documentación sólo para satisfacer al
auditor de certificación – en realidad, estas políticas y procedimientos no
fueron utilizadas en el trabajo diario.
A pesar de que Jan sabía que tenían un SGSI que no funcionaba com-
pletamente, decidió que la empresa podía ir a por la certificación, con la
esperanza de que el auditor de certificación se centrase más en los temas
de tecnología. Para su horror, el auditor de certificación encontró dos no
conformidades mayores, y esto no permitió a la empresa certificarse.
La mayoría de las no conformidades fueron, naturalmente, de las áreas
administrativas, y ventas y marketing de la empresa, aunque estas no
conformidades también incluían que: los empleados no son conscientes
de la política de seguridad de la información, ni entienden por qué la
seguridad es importante; Aunque existen registros que muestran que las
políticas y procedimientos se cumplen, en la vida real la mayoría de los
empleados nunca leyeron los procedimientos; para las tareas específicas
en las que la seguridad es sensible, los empleados no recibieron ningu-
250
na capacitación; por último, algunos miembros de la alta dirección no
saben en realidad cuáles son los objetivos de alto nivel para el SGSI, y la
revisión por dirección se ha realizado sin tener en cuenta los resultados
del análisis de riesgos (no se definió el tratamiento de algunos de los
riesgos no aceptables).
Jan decidió que tenía que hacer algo que nunca había hecho antes en
estos 7 años: confrontar abiertamente al director general, y a los otros
colegas de la alta dirección, para conseguir que finalmente se llevasen
las cosas de manera ordenada, o de lo contrario abandonaría la em-
presa. El director general, viendo que todo empezaba a irse demasiado
lejos, aceptó su propuesta; sin embargo, dijo “Dado que tenemos que
limpiar nuestra seguridad, vamos a aprovechar esta oportunidad para
limpiar la casa entera – si tenemos que definir reglas de seguridad, tam-
bién vamos a definir otras reglas”. Y lo hicieron – esto hizo a Jan esperar
más tiempo (4 meses adicionales), pero ahora ya han resuelto todas las
no conformidades que detectaron los auditores de la entidad certifica-
dora, y también tienen definidos procedimientos paso a paso para el
funcionamiento de los procesos más importantes (de seguridad y no de
seguridad) de la empresa.
Una vez que la empresa consiguió el certificado, la alta dirección lo cele-
bró como un gran logro; La declaración del director general también fue
notable: “siento de alguna manera que las cosas últimamente van mejor
en la empresa. Supongo qué, dado que la gente tiene más tiempo libre, es
tiempo de acelerar el desarrollo de nuestros nuevos productos. “
14.8 R
ealizar el análisis de riesgos en un pequeño hospital
El Hospital H es una clínica privada especializada en el tratamiento del
cáncer. Están ubicados en Toronto, Canadá, y cuentan con un equipo de
100 personas, entre doctores y personal de apoyo. Sus clientes son ma-
yoritariamente celebridades y gente rica. William es el administrador de
TI, y también está a cargo de la implementación de la ISO 27001.
Cuando William consiguió el empleo en la clínica, estaba muy emocio-

nado – fue su primer trabajo permanente después de su graduación, y
251
SEGURO & SIMPLE
también se trataba de una clínica de élite, en la que era muy difícil de
entrar (como empleado o como un paciente). Pero una vez que comenzó
a trabajar, aprendió los aspectos negativos de trabajar en una organiza-
ción – William no pensaba que trabajaría tantas horas, y tampoco pen-
só que tendría problemas con los médicos - chicos que parecía que no
escuchaban a nadie, al menos a William, un novato que recientemente
había cumplido 30 años.
Y qué problemas crearon – muy a menudo tenía que hacer una limpieza
después de que los médicos dejaban en mal estado el software principal
de la compañía, el equipamiento de TI se rompía con demasiada fre-
cuencia debido al mal uso, existieron numerosas ocasiones en las que
se produjeron acciones muy peligrosas sobre los datos (por ejemplo, los
médicos se descargaban las listas de todos los datos de los pacientes a
sus teléfonos o memorias USB, o enviaban datos confidenciales a través
de correo electrónico sin protección, etc.).
Por tanto, en cuanto propuso a la dirección que debían cumplir más

estrictamente con la regulación HIPAA, se sorprendió de lo rápido que
tomaron una decisión – obviamente, la dirección también tenía miedo
de fugas de datos y altas multas. William se sorprendió aún más al sa-
ber que la dirección había decidido implementar la ISO 27001, ya que
pensaban que esta certificación les traería ciertos beneficios que no pro-
porcionaba el cumplimiento de HIPAA. No estaba sorprendido porque
le había tocado la tarea de ejecutar estos proyectos – él sabía que esto
ocurriría, y estaba encantado de empezar a hacer algo nuevo.
Pero se encontró con el primer gran problema cuando el hospital comen-

zó a realizar el análisis de riesgos - los médicos, por supuesto, dijeron
que este no era su problema, y que no querían participar; Desafortuna-
damente la dirección tenía la misma actitud. Cuando trató de explicar
a varios médicos que si no se identificaba dónde estaban los riesgos
reales, no podrían implementar salvaguardas adecuadas, básicamente le
contestaron que no les pagaban por esto, y que además tenían antes la
tarea de cuidar a los pacientes.
Así que William encontró un experto online en ISO 27001 y le solicitó

ayuda – este le sugirió encontrar a una persona con quien William pudiese
preparar un ejemplo positivo, y de esta manera, los demás pudieran se-
252
guirle. Por lo que decidió hablar con Marie, una de las médicas más jóve-
nes, pero también de las más cercanas y amistosas; así que, siguiendo el
asesoramiento del experto online, se centró en los beneficios que tendría
Marie si realizaba este análisis de riesgos correctamente.
De esta manera, explicó a Marie que en el caso de existiese una fuga de

datos, la imagen del hospital se dañaría mucho, lo que significaría que
habría menos pacientes, lo que significaría menos trabajo para ellos, y
potencialmente algunos despidos; Además, le explicó que el médico que
causase el incumplimiento podría ser materialmente responsable – lo
que implicaría que el hospital y los pacientes podrían demandar al médi-
co en cuestión, por los datos expuestos.
Marie muy rápidamente entendió este punto, y acordó pasar 1 hora hacien-
do el ejercicio del análisis de riesgos con William – mientras lo hacía, tuvo
una especie de iluminación: “¡No tenía idea de que hacíamos tantas cosas
mal! Realmente es una maravilla que hasta ahora no haya sucedido nada
malo.” y “Ahora me doy cuenta por qué los chicos de TI no podían arreglar
estos problemas.”
Por lo que ella accedió a presentar su experiencia en la próxima reunión

con sus colegas – después de esto, William encontró repentinamente
que los médicos estaban interesados en colaborar con él.
14.9 Establecer objetivos de seguridad y mediciones

en una compañía de servicios
La Compañía I ofrece servicios de limpieza y mantenimiento de edificios
a clientes corporativos en el área de Los Ángeles. Tienen sobre 1000 em-
pleados con un elevado número de rotaciones. Olivia es la responsable
de recursos humanos, actuando también como CISO.
Olivia pensó después de ser nombrada como CISO hace 2 años “Nunca
me imaginé que gestionaría la seguridad”, pero esta fue una decisión
lógica que hizo el director general – en aquel momento tenían muy poco
personal administrativo en la empresa (sólo 20), y de otros gerentes de
la empresa, ella era la que entendía mejor todo lo relativo a TI (TI fue
253
SEGURO & SIMPLE
totalmente externalizada). Además, la empresa requiere mucha mano
de obra, por lo que los mayores problemas de seguridad estaban preci-
samente en los recursos humanos, y aquí es donde estaba su objetivo
– Asegurarse de contratar solamente a personas que tienen una vida
laboral impoluta, sin problemas, que no creen problemas en las instala-
ciones del cliente, etc.
Cuando uno de sus principales clientes (un gran banco) solicitó que se
certificasen en ISO 27001, ella se encargó del trabajo. Como todo lo que
hizo en su vida, ella realizó este trabajo correctamente – fue a sesiones de
capacitación, leyó un libro de ISO 27001, y obtuvo los conocimientos de
un experto. Seis meses después, la compañía consiguió todas las políticas
y procedimientos, sus empleados fueron capacitados y concienciados en
seguridad, y se generaron todos los registros necesarios.
Sin embargo, cuando fueron a por la certificación, ella estaba realmente

avergonzada – aunque el auditor de certificación elogió cómo se había
implementado el SGSI, de forma realmente efectiva, levantó una no con-
formidad mayor: no tienen documentación relativa a la medición del sis-
tema. Y Olivia comenzó a decir: “Pero el estándar no requiere tener una
política o un procedimiento para la medición”; el auditor respondió: “Esto
es cierto, pero no tiene los registros como resultado de haber medido el lo-
gro de sus objetivos”. Después de meditarlo brevemente, Olivia dijo “pero
establecemos como un objetivo general el preservar la confidencialidad,
la integridad y la disponibilidad de la información de nuestros clientes -
no estoy segura qué tipo de medición necesitaría para esto.” a lo que el
auditor respondió “aquí en este objetivo es exactamente donde está el
problema - no es un objetivo que se pueda medir, por lo que es lógico que
nunca haya hecho nada al respecto.”
Así que cuando se dio cuenta donde estaba el problema, Olivia tuvo que
tomar un enfoque completamente diferente para la creación de los objeti-
vos – estuvo de acuerdo con su director general en que el nuevo objetivo
general para el SGSI debe ser “Disminuir el número de incidentes de se-
guridad relacionados con el trabajo en las instalaciones del cliente en un
50% en el año próximo”, y la manera de medir este objetivo sería muy
fácil – todos los clientes que tengan algún problema con su personal lla-
marán al director general, así que ahora lo que tienen que hacer es crear
254
un registro de incidentes, donde el director general registre cada problema
relacionado con la seguridad.
Con respecto a los objetivos de nivel inferior, Olivia ha establecido un obje-

tivo muy bueno para los recursos humanos: “todo empleado tiene que te-
ner una puntuación de al menos un 80% en el test de seguridad.” – Olivia
ha desarrollado una capacitación de seguridad, y una prueba relacionada
con esta capacitación, que cada empleado tiene que hacer una vez al año;
tomando los resultados de esta prueba puede tener una medida muy clara
sobre cómo realizó su tarea de recursos humanos.
Después de la conmoción inicial, finalmente Olivia se quedó satisfecha –

y cuando pasaron la certificación, Olivia dijo a su director general: “estoy
realmente satisfecha con cómo estas mediciones están funcionando -
realmente empecé a utilizar un sistema similar para otras cosas que no
están relacionadas con ISO 27001.”
14.10 Implementando ISO 27001 en Centros

de Procesamiento de Datos – Una entrevista
Goran Djoreski es el director general del Centro de Procesamiento de
Datos independiente Altus, ubicado en Zagreb, Croacia. Previamente
trabajó durante 12 años en el sector de la industria financiera, donde se
encargó del desarrollo del negocio de las tarjetas, así como de la seguri-
dad de los pagos a través de tarjeta de crédito.
En esta entrevista Goran y yo discutimos qué obstáculos se encontraron
durante la implementación de la ISO 27001, y cómo están utilizando
este estándar para competir en el mercado.
DK: Ha pasado más de un año y medio desde que consiguieron la
certificación ISO 27001 – ¿Cuáles son sus impresiones? ¿Realmen-
te merece la pena?
GD: Sin duda merece la pena, dado que una certificación de ISO 27001
no es necesariamente una ventaja competitiva, también es un conjunto
de cosas que hay que tener. El fondo de toda la historia es que estamos
tratando de abordar mercados regulatorios exigentes. Por lo que esta-
255
SEGURO & SIMPLE
mos hablando de la industria farmacéutica, las telecomunicaciones, el
sector financiero, y quizás en el futuro también la producción de alimen-
tos y similares, y todos están extremadamente regulados, y en una con-
versación con ellos puedes descubrir que esperan que tengas una ISO
27001, porque de lo contrario no están dispuestos a hablar contigo. Así
que no diría que nos ha llevado a traer clientes, sino que más bien nos
ha proporcionó el poder entrar en un mercado, al que de otra manera
no habríamos podido tener acceso.
DK: ¿Por qué tantos potenciales clientes están haciendo hincapié
en la ISO 27001?; ¿Por qué este estándar se acepta como algo que
es necesario?
GD: Para ellos, ISO 27001 a menudo no es suficiente. Es necesaria pero no
suficiente. Establecen con ISO 27001 un nivel inicial, algo así como: “Ahora
podemos empezar a hablar.” Si una empresa tiene un certificado ISO 27001,
asumen que cumplen algunos criterios básicos, y después de eso, están real-
mente buscando su anexo específico. Además, el proceso ISO 27001 acorta
sus auditorías – que ahora toma sólo dos días, en lugar de seis.
DK: Por tanto, ISO 27001 realmente se considera una línea base.
GD: Correcto, una línea base.
DK: ¿Existe otro estándar parecido, que pueda ser una línea base
para potenciales clientes?
GD: No, yo diría que la ISO 27001 es el requisito principal. En particular,
las instituciones financieras miran generalmente PCI DSS, pero dado que
somos una infraestructura de procesamiento de datos, no entramos en
sus datos y transacciones, y si miran PCI DSS, todo lo que no esté relacio-
nado con la infraestructura, está fuera del alcance para nosotros. Lo que
esperan es que con el certificado ISO 27001, cubramos los capítulos de
PCI DSS que son relevantes para la infraestructura. No solicitan ISO 9001
porque asumen generalmente que si tenemos la certificación ISO 27001,
si es importante para ellos la ISO 9001, ya está incluida.
DK: Si he entendido bien su negocio, principalmente alquila in-
fraestructura, por lo tanto, ¿No maneja datos?
256
Introducción
GD: En la mayoría de los casos es así, sí.

DK: ¿Cómo de beneficioso es para ti el certificado ISO 27001 si
consideramos que este estándar se centra en la información?
GD: Yo diría que ISO 27001 no se basa sólo en información, también se
basa en todo lo que contribuye a garantizar la seguridad y la transferen-
cia de esta información, y todo lo necesario para hacer que esta informa-
ción está disponible, es auténtico, etc. De hecho, la información como
tal no es nada; no puede existir fuera de una infraestructura.
DK: En los últimos tiempos, la tendencia ha sido ir cada vez más
hacia la nube; ¿Cómo de útil es ISO 27001 para esto, o es más un
obstáculo? De hecho, podría ser un obstáculo, dado que las em-
presas que usan servicios en la nube, realmente pierden el control
sobre sus datos.
GD: En realidad no. Si pensamos en la nube en la forma en la que es uti-
lizada por algunos de los grandes proveedores – ya sea Amazon AWS o
Rackspace o similar – han industrializado altamente sus nubes, y tienen un
conjunto estándar de productos, que abordan más o menos el mismo pa-
trón; toda esta historia está diseñada de manera que los centros de datos
están alrededor de todo el mundo, y migran servidores virtuales entre ellos,
así que de hecho, desde esta perspectiva parece realmente que los usuarios
no tienen control sobre sus datos. No pueden saber dónde están los datos,
ya que hoy tal vez estén en Johannesburgo, y mañana tal vez en Munich, y
no tiene influencia sobre la estructura de la red, etc. Esto es la nube.
Pero la nube también es algo más. Nube también es lo que hacemos
nosotros, pero en comparación con otros proveedores, nos gustaría ha-
cer una distinción, como la que existe entre la ropa a medida y los trajes
fabricados industrialmente. Así que podemos cortar y coser a medida
redes: el usuario, que viene a nosotros, está de acuerdo con nosotros en
la estructura de la red, dónde se coloca el servidor virtual, y cómo se tra-
tará la seguridad. Por supuesto, todo esto tiene que ser dentro de ciertos
estándares en relación a los grandes actores globales, dado que éstos
son sus servidores y sus ciudades, etc., donde las máquinas virtuales del
usuario se colocan físicamente. Podemos definir un marco de trabajo,
con unos límites, dentro del cual actuará su nube.
257
SEGURO & SIMPLE
DK: De esta manera, en contraste con estos grandes actores in-
dustrializados también existen actores pequeños, que realmente
ajustan la nube a sus necesidades específicas de seguridad.
GD: Sí. En realidad, en mi opinión, con en este tipo de configuración he-
mos conseguido conciliar seguridad y economía. La nube ahorra signifi-
cativamente recursos, y esto hace posible alcanzar el mismo nivel, o un
nivel más alto, de redundancia, y en caso de fallas y problemas técnicos, el
servidor virtual seguirá trabajando en una infraestructura completamente
diferente, y no necesita comprar 3 o 4 servidores para este propósito. Esto
significa que alineamos este enfoque con el hecho de que el entorno,
donde todo está configurado, se puede controlar, y eres consciente de
que podrías compartir un servidor físico con otro usuario. Pero, por otro
lado, sabes que tienes un segmento de red independiente - entre usted y
el exterior existe un firewall, que este está en un clúster, donde el acceso
está controlado, por lo que no hay ninguna posibilidad de que alguien sa-
que un disco del servidor y vuelva a colocarlo en otro lugar sin control, etc.
Esto realmente da a los usuarios una sensación de que tienen la misma
seguridad que antes, pero con los beneficios de usar una nube.
DK: OK, ahora me gustaría hablar sobre tu experiencia con la do-
cumentación. ¿Qué te sorprendió más? ¿Conseguiste algo que no
esperabas? ¿Qué esperabas y qué no esperabas?
GD: La mayor sorpresa durante la implementación fue que pensába-
mos que simplemente obtendríamos una especie de libro de cocina, y
que habría algún tipo de formulario, de donde partiríamos para la im-
plementación de un estándar, e iríamos punto a punto a través de él,
siguiendo algún tipo de proceso, y después de esto terminaríamos. Pero
resultó que esto no era así, y tuvimos que empezar con una visión sobre
nosotros mismos, lo que supuso una gran sorpresa para nosotros. No
tuvimos una definición tipo “ISO es que y que”; en cambio, tuvimos
algo como “Averigua primero lo que necesitas” y “¿Qué quieres de ISO,
en conjunción con que?” y tuvimos que definir nosotros mismos cómo
implementar el marco de trabajo proporcionado por el estándar.
DK: Por lo tanto, ¿Tuviste que comenzar con el análisis de riesgos?
GD: Sí, el análisis de riesgos y antes de esto, un análisis de nuestros
propios procesos de negocio, para saber cuáles eran los riesgos. Sin em-
258
Introducción
bargo, no me lo esperaba que la ISO nos ayudase a facilitar las opera-
ciones, porque uno siempre ve la ISO y todos los otros certificados como
una carga adicional; por otra parte, con respecto a algunas cosas que
teníamos sin resolver, con las que habíamos luchado, pudimos regularlas
a través de procesos definidos, y ahora sabemos cómo funcionan en el
negocio.
DK: ¿Cómo de difícil fue instruir a su gente para que escribiera
documentos, procedimientos y políticas?
GD: No fue fácil, y esto realmente es algo que nunca acaba. Es una batalla
continua. Inicialmente, es necesario establecer unas reglas para este seg-
mento, porque si no, de lo contrario no habrá ninguna documentación. Por
lo que es un proceso perpetuo, porque estamos luchando para que todo
sea como debe.
DK: OK, pero la pregunta es si la documentación es necesaria, si
es útil para todos.
GD: Esta es otra parte de la historia. No importa el esfuerzo que invierta,
y que los preparativos duren 6 meses o más, los documentos pueden no
adaptarse perfectamente a lo que hacemos. Puesto que el objetivo es
obtener la certificación, puede existir una tendencia a aceptar las cosas
que están escritas ya en los documentos, aunque tal vez no se adapten
perfectamente a las operaciones diarias. Entonces sucede mucho cuan-
do va a la primera auditoría de certificación, y el auditor de certificación
pregunta: “¿funcionan las cosas que tiene escritas ahí?” Y entonces te
das cuenta de que ninguna persona normal hace lo que está escrito ahí.
Y luego en la siguiente visita de seguimiento estas cosas no pasan, por-
que cada vez se ajusta más los documentos a las necesidades, dado que
se ha ganado experiencia. Pero de nuevo, existe una necesidad humana
de hacer mucho trabajo en un determinado período de tiempo, y la do-
cumentación es siempre una sobrecarga.
DK: Cómo puede resolver, a nivel psicológico, esta cuestión – In-
cluso si los documentos son necesarios, son odiados por las perso-
nas que los necesitan, que están muy ocupados por la naturaleza
de su trabajo?
259
SEGURO & SIMPLE
GD: Uno nunca debe ser un esclavo de la formalidad. He tenido experiencia
con una empresa donde un proceso formal de aprobación estaba regulado
de tal manera que algo tenía que ser impreso en papel en múltiples copias,
se tenía que enviar a 12 directores, que tenían que leerlo, y los 12 directo-
res tenían que firmar, y solamente después de eso fui a un comité - era un
infierno. Es normal que esto sea un horror para la gente. Por otra parte, ISO
27001 permite, en gran medida, que una empresa pueda describir por si
misma lo que sea suficiente para sus necesidades, y en este sentido puede
simplificar todo lo que pueda. No debe permitir que se necesiten 12 per-
sonas para leer y aprobar algo, o 9 miembros, no importa. Debe hacer el
procedimiento más fácil y más eficaz, deben comenzar a utilizar las herra-
mientas. ¿Por qué alguien firma algo en el papel, si la aprobación a través
de un CMS es suficiente? Esto implica que tiene trazabilidad, y también
puede saber quién fue la persona que firmó y aprobó, y no necesita traer a
un notario para demostrar la aprobación. Y luego, esto puede permitir que
la gente deje de percibir todo esto como una molestia, y puede comenzar
a vivirlo como parte del proceso, y por lo tanto, hacerlo todo más fácil.
DK: ¿Qué fue lo más difícil durante la implementación? ¿Hubo
algo que le hizo pensar en abandonar?
GD: No quisimos renunciar, ya que nos dimos cuenta muy rápidamente
que esto era para nosotros un beneficio. Nuestra motivación era el hecho
de que si queríamos lidiar con eso, necesitábamos este estándar. ¿Cuál
fue la parte más difícil? Yo diría que lo más difícil fue evaluar el alcance del
sistema, con qué trataríamos, y lo detallado que sería. Existe la posibilidad
de llegar a una documentación ISO que sea para una empresa mucho
más grande de lo que somos, aunque otra opción es simplificar y hacer
las cosas más sencillas, por lo que tendríamos que cortar mucho, pero
por otra parte, si cortamos mucho, y comprobamos si cumplimos con el
estándar, puede suceder que hayamos dejado algo fuera, y que esto era
importante. Aquí, su ayuda fue muy importante, dado que estaba orien-
tado a objetivos, y dijiste: “No creo que no sea importante para usted,”
o “Los tres documentos se pueden combinar dentro de las estructuras
operativas,” por lo que esta parte fue bastante buena. Creo que durante
la implementación, especialmente cuando las empresas estén trabajando
solas, existe la oportunidad de ser demasiado extenso, o ir por debajo del
nivel requerido. El límite no está muy claro y esto fue difícil.
260
Introducción
DK: ¿Cómo de importante es la ayuda externa? ¿Dónde está el
punto óptimo entre los dos extremos? – Por un lado, puedes im-
plementar este estándar sin plantillas y sin un consultor, y por
otro lado puedes tener un consultor que lo haga todo ¿Cuál es el
punto medio?
GD: Lo primero que una empresa debe hacer es comprender esta ver-
dad básica: un consultor no hace tu certificado ISO. Tienes que hacer
tu certificado ISO, o no lo hará otra persona por ti. Los consultores no
hacen certificados ISO; lo hace tu empresa, y el consultor reconoce los
procesos de negocio. Para ser capaces de entender los procesos de ne-
gocio, es necesario emplear una gran cantidad de consultores, y esto es
otro trabajo por cuenta propia. Por lo tanto, esto significa que tienes que
hacer el certificado ISO por tu cuenta, no con consultores. Un consultor
es importante en otra área, y es que el consultor entiende el estándar
mucho mejor, por lo que él puede enfatizar cosas que hayas podido
olvidar, o tal vez que hayas exagerado. Otra cosa es que un consultor
acumula experiencia de trabajo práctico – pensemos en una analogía de
tráfico: en teoría, sé cómo pasar por un cruce ferroviario, pero si no se
que en Croacia la rampa en el carril de cruce a menudo no desciende
cuando pasa un tren, podría pasar algo muy malo. Ocurre lo mismo con
los consultores: saben hacer los trabajos prácticos, dónde se encontrarán
con problemas, durante la certificación, o en la práctica, dónde pueden
solapar algunas cosas, dónde pueden medir, etc. Durante la implemen-
tación fuimos en varias ocasiones en la dirección equivocada. Trabajába-
mos y escuchábamos de repente – ¿Qué has hecho? Dábamos dos pasos
atrás, y nos dirigíamos en la dirección correcta otra vez. Si no tienes un
consultor que compruebe lo que estás haciendo sobre una base regular,
y que te permita retroceder dos pasos cuando vayas en la dirección equi-
vocada, puede ocurrir que tengas que ir hasta diez pasos hacia atrás y
empezar de nuevo.
DK: Sólo aclarar una cosa – ¿Es deber del consultor escribir su do-
cumentación, o no?
GD: No. Las plantillas de documentos fueron de gran ayuda para noso-
tros. No tanto por el contenido, sino porque podíamos ver qué forma
tenían que tener, y qué temas tenía que contener para cumplir con el
261
SEGURO & SIMPLE
estándar. Tomemos el ejemplo de la política de contraseñas; es absoluta-
mente cierto que la plantilla donde se describe la política de contraseñas
no tiene nada que ver con lo que hacemos. Así que hicimos una historia
nueva dentro del análisis de riesgos, y luego también en la descripción
de nuestra regulación de contraseñas, y en ese lugar del documento de-
finimos cómo trabajar con las contraseñas - el texto es probablemente
un 70% diferente de la plantilla. Nos ayudó el hecho de que sabíamos
que teníamos que escribir cómo gestionamos las contraseñas, y que te-
nía que estar en una parte específica de la documentación.
DK: Es decir, ¿Por un lado las plantillas dan una estructura, y por
otro lado dan la flexibilidad de escribir lo que realmente existe en
la empresa?
GD: Así es.
DK: ¿Cuál es el rol del consultor en este caso? Si el consultor no
escribe la documentación, ¿Tiene que estar presente en su em-
presa?
GD: No, no es necesario que esté presente. Siempre hemos querido que el
consultor esté presente, pero no siempre estuvo aquí. Teníamos un mon-
tón de reuniones en línea. Nos encantó conocer el consultor también en
la vida real, pero esto no tiene nada que ver con su trabajo profesional, y
más teniendo en cuenta el fondo cultural de Croacia – nos encanta cono-
cer a una persona en la vida real y tomar un café juntos. En realidad, no
era esencial tenerlo en la oficina, porque fuimos capaces de leer los do-
cumentos en una pantalla también. Por tanto, diría que no es necesario,
- agradable, pero no necesario.
DK: ¿Por qué el certificado ISO 27001 no es todavía tan popular
como el certificado ISO 9001?
GD: Probablemente debido a las necesidades no reconocidas. El certifi-
cado ISO 9001 es algo parecido a un zapato que se adapta a cada pie.
Cada empresa se reconocerá en la ISO 9001, pero por otra parte, ISO
9001 también es mencionado muy a menudo en los medios públicos.
Se utiliza como una herramienta de marketing, como algo muy impor-
tante. Una tercera cosa es, creo yo, que ISO 9001 puede implementarse
mucho más fácil que ISO 27001. Por otra parte, reconocer la ISO 27001
262
Apéndice
es mucho más difícil, no importa que yo piense que cada empresa tenga
información mínima dentro de su casa - todos tenemos un mínimo de
registros contables y una lista de usuarios con sus números de teléfono
– y también son datos que tienen que tener seguridad. Todo el mundo
podría implementarlo. Pero sólo existen empresas raras que necesitan
implementar ISO 27001, como lo hicimos nosotros, y cuando se dan
cuenta que ISO 27001 es mucho más difícil de implementar que ISO
9001, es lógico que sea menos popular.
DK: Y finalmente, ¿Qué 3 cosas recomendaría a empresas de TI
que han comenzado con el certificado ISO 27001? ¿En qué tienen
que prestar atención antes de empezar con la implementación?
GD: Primero tienen que responder a la pregunta ¿Por qué quieren un
certificado ISO 27001?, ¿Lo quieren, o lo necesitan? y si lo necesitan,
¿Están motivados para tenerlo? Esto debe hacerse al principio, dando
ventajas y desventajas. Otra cosa es, si deciden que quieren tenerlo, en-
tonces necesitan un compromiso absoluto de la dirección para la ISO
27001. No deben existir dilemas, ya que durante alguna discusión a me-
nudo existirá un momento en el que decidir cómo asignar los recursos
entre proyectos, para ISO 27001, o para otro proyecto que pueda parecer
ser más importante a primera vista. El beneficio del estándar ISO 27001
no es que ganará más dinero cuando termine el proyecto. Aunque lo
hará a pesar de que no verá beneficios inmediatos. Este proyecto puede
perderse rápidamente en un canal oculto. Si decides que quieres la ISO,
entonces el compromiso de la dirección debe ser fuerte, y debe ser más
fuerte que con otros proyectos que directamente generen ingresos. La
tercera cosa importante, en mi opinión, es prestar atención a los extre-
mos sueltos. Como con cualquier proyecto, con ISO 27001 puede tener
atado un 95% de todo lo que necesita, y luego puede ser suficiente con
los certificadores y el auditor interno, que te harán preguntas estúpidas,
y entonces tendrá que hacer todavía otras 20 cosas, cuando pensaste
que ya habías terminado. Por lo que también tienes que pasar esta meta,
este último 5%, y después todo se pondrá más fácil.
263
15
¡BUENA SUERTE!
Y esto es todo - espero que ahora ISO 27001 no sea tanto misterio
como lo era antes.
Me gusta pensar que ISO 27001 es bastante lógica – una vez que la co-
noce totalmente, puede empezar a darse cuenta de que implementar la
seguridad de la información de otra manera puede ser un error. Todos los
elementos y piezas tienen un sentido perfecto, y puede empezar a pre-
guntarse: ¿Por qué no empecé a trabajar de esta manera mucho antes?
Pero no vaya demasiado lejos – ISO 27001 no es perfecto después de

todo. El principal defecto reside en el hecho de que no hay ninguna
garantía de que su implementación tenga éxito. Así que por esta razón
me gustaría recordar este punto: ISO 27001 no debe ser su objetivo,
tampoco debe ser su objetivo escribir una documentación perfecta; su
objetivo debería ser usar ISO 27001 y la documentación sólo como una
herramienta para lograr algo mucho más importante: que sus emplea-
dos empiecen a cambiar su comportamiento, y comiencen a utilizar la
tecnología de una forma más segura
Y sí – no olvide disfrutar del trabajo durante todo el proceso :)
Dejan Kosutic
P.S. En este libro probablemente no haya respondido a todas sus pre-

guntas, por tanto siéntase libre de preguntarme cualquier cuestión a
través de nuestra comunidad Expert Advice Community – la idea princi-
pal de este foro es proporcionar un asesoramiento gratuito a cualquier
principiante en seguridad de la información, y estaré encantado de res-
ponder cualquier pregunta personalmente.
264
APÉNDICE A – LISTA DE
VERIFICACIÓN DE LA
DOCUMENTACIÓN OBLIGATORIA
DE LA ISO 27001:2013
1. ¿Qué documentos y registros son obligatorios?

Esta lista muestra el mínimo de documentos y registros que son nece-
sarios para la ISO 27001:2013:
Número de la
Documentos* cláusula de
ISO 27001:2013
Alcance del SGSI 4.3
Política de seguridad de la información y objetivos 5.2, 6.2
Metodología de análisis y tratamiento de riesgos 6.1.2
Declaración de Aplicabilidad 6.1.3 d)
Plan de Tratamiento de Riesgos 6.1.3 e), 6.2
Informe de Análisis y Tratamiento de riesgos 8.2, 8.3
Definición de roles y responsabilidades de seguridad A.7.1.2, A.13.2.4
Inventario de activos A.8.1.1
Uso aceptable de activos A.8.1.3
Política de control de accesos A.9.1.1
Procedimientos operacionales para la gestión de TI A.12.1.1
Secure system engineering principles A.14.2.5
Política de seguridad de proveedores A.15.1.1
Procedimiento de gestión de incidentes A.16.1.5
Procedimientos de continuidad de negocio A.17.1.2
Requerimientos contractuales, regulatorios, y legales A.18.1.1
265
SEGURO & SIMPLE
Número de la
Registros* cláusula de
ISO 27001:2013
Registros de formación, habilidades, experiencia y
7.2
calificaciones
Seguimiento y resultados de medición 9.1
Programa de auditoría interna 9.2
Resultados de auditorías internas 9.2
Resultados de la Revisión por Dirección 9.3
Resultados de acciones correctivas 10.1
Registros de las actividades de usuario, excepcio-
A.12.4.1, A.12.4.3
nes y eventos de seguridad
*Los controles del Anexo A se pueden excluir si la organización conclu-

ye que no hay ningún riesgo o requisito que exija la implementación de
un control.
Esto no es una lista definitiva de los documentos y registros que se pue-
den utilizar durante la implementación de la ISO 27001 – el estándar
permite añadir cualquier otro documento para mejorar el nivel de la
2. Documentos no obligatorios comúnmente utilizados

Otros documentos que frecuentemente son utilizados son los siguientes:
Número de la
Documentos cláusula de
ISO 27001:2013
Procedimiento para control de documentos 7.5
Controles para la gestión de registros 7.5
Procedimiento para auditoría interna 9.2
Procedimiento para acciones correctivas 10.1
Política BYOD (Bring Your Own Device = Trae tu
A.6.2.1
propio dispositivo)
Política de dispositivos móviles y teletrabajo A.6.2.1
266
Apéndice
A.8.2.1, A.8.2.2,
Política de clasificación de la información
A.8.2.3
A.9.2.1, A.9.2.2,
Política de claves A.9.2.4, A.9.3.1,
A.9.4.3
Política de eliminación y destrucción A.8.3.2, A.11.2.7
Procedimientos para trabajo en áreas seguras A.11.1.5
Política de pantalla y escritorio limpios A.11.2.9
Política de gestión de cambios A.12.1.2, A.14.2.4
Política de Copias de seguridad A.12.3.1
A.13.2.1, A.13.2.2,
Política de transferencia de información
A.13.2.3
Análisis de impacto en el negocio (BIA) A.17.1.1
Plan de pruebas y verificación A.17.1.3
Plan de mantenimiento y revisión A.17.1.3
Estrategia de continuidad de negocio A.17.2.1
3. Cómo estructurar los documentos y registros más comunes

Alcance del SGSI. Este documento es generalmente bastante corto y
se escribe al principio de la implementación de la ISO 27001. Normal-
mente, es un documento independiente, aunque puede estar combi-
nado con la Política de seguridad de la información.
Política de seguridad de la información y objetivos. La Política de

seguridad de la información suele ser breve, un documento de alto nivel,
que describe el propósito principal del SGSI. Los objetivos para el SGSI,
generalmente, están en un documento independiente, pero también
pueden estar combinados con la Política de seguridad de la información.
Metodología e informe del análisis y tratamiento de riesgos. La

metodología de análisis y tratamiento de riesgos generalmente es un
documento de 4 a 5 páginas, y debe ser escrito antes de que se lleve
a cabo el análisis y tratamiento de riesgos. El informe del análisis y
tratamiento de riesgos tiene que escribirse después de llevar a cabo el
267
SEGURO & SIMPLE
análisis y tratamiento de riesgos, indicando un resumen de todos los
resultados.
Declaración de Aplicabilidad. La Declaración de Aplicabilidad (o SoA

por sus iniciales en Inglés Statement of Applicability) se escribe basán-
dose en los resultados del tratamiento de riesgos – este es un documen-
to central dentro del SGSI, porque describe qué controles del anexo A
son aplicables, y también describe cómo se implementarán, y su estado
actual. Usted también podría considerar la Declaración de Aplicabilidad
como un documento que describe el perfil de seguridad de su empresa.
Plan de tratamiento de riesgos. Básicamente se trata de un plan de

acción sobre cómo implementar los diferentes controles definidos en el
SoA – se desarrolla en base a la Declaración de Aplicabilidad, y es ac-
tivamente utilizado y actualizado a lo largo de toda la implementación
del SGSI. A veces puede ser combinado con el plan del proyecto.
Roles y responsabilidades de seguridad. El mejor método es descri-

bir estos roles y responsabilidades en cada una de las políticas y proce-
dimientos, con la mayor precisión posible. Se deben evitar expresiones
como “se debe hacer,” y en su lugar usar algo como “El CISO realizará
las acciones xyz todos los lunes a la hora zxy.” Algunas empresas pre-
fieren describir los roles y responsabilidades de seguridad en su descrip-
ción de puestos de trabajo; sin embargo, esto puede llevar a tener una
gran cantidad de papeleo. En relación a las terceras partes, los roles y
responsabilidades de seguridad se definen en los contratos.
Inventario de activos. Si no tiene este inventario antes de comenzar

el proyecto de ISO 27001, lo mejor es crear un documento utilizando
directamente como referencia el resultado del análisis de riesgos – du-
rante el análisis de riesgos, tienen que identificarse todos los activos y
sus propietarios, por lo que sólo debe de tomarlos de aquí.
Uso aceptable de activos. Esto se escribe generalmente en forma de

política, y este documento puede cubrir una amplia gama de temas,
porque el estándar no define muy bien este control. Probablemente la
mejor manera de abordarlo sea de la siguiente forma: (1) dejarlo para el
268
Apéndice
final de la implementación de su SGSI, y (2) todas las áreas y controles
que no se han cubierto con otros documentos, y que se refieren a todos
los empleados, se cubren con esta política.
Política de control de accesos. Con este documento, puede cubrir

solamente la parte relacionada con la aprobación de accesos a determi-
nada información, y a determinados sistemas, o también puede cubrir
la parte técnica del control de accesos; Además, puede elegir definir
reglas sólo para el acceso lógico, o también para el acceso físico. Debe
escribir este documento sólo después de haber terminado su proceso
de análisis y tratamiento de riesgos.
Procedimientos de operación para gestión de TI. Lo puede escribir

como un solo documento, o como una serie de políticas y procedimien-
tos – si usted es una empresa pequeña, tenderá a tener un número
menor de documentos. Normalmente, puede cubrir todas las áreas de
las secciones A.12 y A.13 – gestión del cambio, servicios de terceros,
backup, seguridad de red, código malicioso, disposición y destrucción,
transferencia de información, sistema de monitoreo, etc. Debe escribir
este documento sólo después de haber terminado su proceso de análi-
sis y tratamiento de riesgos.
Principios de ingeniería de sistemas seguros. Este es un nuevo con-

trol en ISO 27001:2013, y requiere documentar principios de ingeniería
seguros, en forma de procedimiento o norma, y debe definir cómo
incorporar técnicas de seguridad en todas las capas de la arquitectura -
negocio, datos, aplicaciones y tecnología. Esto puede incluir validación
de datos de entrada, depuración, técnicas para la autenticación, con-
troles de sesión segura, etc.
Política de seguridad para proveedores. Este también es un nuevo

control en ISO 27001:2013, y esta política puede cubrir una amplia
gama de controles – cómo se realiza la selección de potenciales con-
tratistas, cómo se hace el análisis de riesgos de un proveedor, qué cláu-
sulas de seguridad se insertan en el contrato, cómo supervisar el cum-
plimiento de las cláusulas contractuales de seguridad, cómo cambiar el
contrato, cómo quitar el acceso una vez que el contrato se termina, etc.
269
SEGURO & SIMPLE
Procedimiento para gestión de incidentes. Este es un procedimien-
to importante que define cómo reportar, clasificar y manejar las debili-
dades de seguridad. Este procedimiento define también cómo aprender
de los incidentes de seguridad de la información, lo cual puede ayudar
a prevenir que se vuelvan a materializar. Este procedimiento también
puede invocar al Plan de continuidad de negocio si un incidente causa
una larga interrupción.
Procedimientos de continuidad de negocio. Estos generalmente

son planes de continuidad de negocio, planes de respuesta a inciden-
tes, planes de recuperación para la parte del negocio de la organiza-
ción, y planes de recuperación ante desastres (planes de recuperación
para infraestructura de TI). Estos se describen mucho mejor en el están-
dar ISO 22301, el principal estándar internacional para la continuidad
del negocio.
Requerimientos legales, regulatorios y contractuales. Esta lista

debe hacerse en una etapa temprana del proyecto, porque muchos
documentos se tendrán que desarrollar según esta lista. Por otra parte,
esta lista debe incluir las responsabilidades para cumplir con ciertos
requisitos, y también los plazos para cumplirlos.
Registros de formación, habilidades, experiencia y calificaciones.

Estos registros normalmente los mantiene el departamento de recursos
humanos – si usted no tiene este departamento, cualquier persona que
se encargue de mantener los registros de los empleados, podría hacer
el mismo trabajo. Básicamente, se hará una carpeta y se incluirán todos
los documentos.
Seguimiento y resultados de medición. La forma más sencilla de

describir la manera en la que se medirán los controles, es a través de
las políticas y procedimientos que se definan en cada control – normal-
mente, esta descripción puede estar escrita al final de cada documento,
y esta descripción puede definir los tipos de KPI (Key Performance Indi-
cators = Indicadores Clave del Desempeño) que tiene que medir para
cada control, o para cada grupo de controles.
270
Apéndice
Una vez que se pone en marcha este método de medición, se debe
realizar la medición en consecuencia. Es importante informar estos re-
sultados periódicamente a las personas que tienen la responsabilidad
de evaluarlos.
Programa de auditoría interna. El programa de auditoría interna no

es nada más que un plan de 1 año para la realización de las auditorías
- para una compañía pequeña podría ser una única auditoría, mientras
que para una mayor organización esto podría ser una serie de, por
ejemplo, 20 auditorías internas. Este programa debe definir quién reali-
zará las auditorías, los métodos, los criterios de auditoría, etc.
Resultados de auditorías internas. El auditor interno debe elaborar

el informe de auditoría, que incluye los hallazgos de la auditoría (ob-
servaciones y acciones correctivas). Este informe debe presentarse con
un plazo de 2 días después de la realización de la auditoría interna. En
algunos casos, el auditor interno deberá verificar si se han realizado
todas las acciones correctivas según lo esperado.
Resultados de la Revisión por Dirección. Estos registros normalmen-

te suelen estar en forma de minutas o actas - tienen que incluir todos
los materiales que estuvieron involucrados en la reunión de dirección,
así como todas las decisiones que se tomaron. Las minutas pueden es-
tar en forma de papel, o en formato digital.
Resultados de acciones correctivas. Estos tradicionalmente se inclu-

yen en los formularios de acciones correctivas. Sin embargo, es mucho
mejor incluir estos registros en alguna aplicación que ya se utilice en la
organización, tipo Help Desk – porque las acciones correctivas no son
nada más que listas de tareas con responsabilidades claramente defini-
das, y los plazos.
Registros de las actividades de usuario, excepciones y eventos

de seguridad. Estos se mantienen normalmente de dos formas: (1) en
formato digital, producidos como registros de logs de varios sistemas
de TI, automáticamente o semiautomáticamente y (2) en papel, donde
cada registro se escribe manualmente.
271
SEGURO & SIMPLE
Procedimiento para control de documentos. Este es normalmente
un procedimiento independiente, de 2 o 3 páginas de longitud. Si ya
ha implementado algún otro estándar como ISO 9001, ISO 14001, ISO
22301 o similar, puede utilizar el mismo procedimiento para todos es-
tos sistemas de gestión. A veces es mejor escribir este procedimiento
como el primer documento del proyecto.
Controles para la gestión de registros. La forma más sencilla es des-

cribir el control de los registros en cada política o procedimiento (u otro
documento), lo que requiere que se cree un registro. Estos controles se
escriben normalmente al final de cada documento, y suelen estar en
forma de tabla, la cual describe dónde se archiva el registro, quién tiene
acceso, cómo se protege, para cuánto tiempo se archiva, etc.
Procedimiento para auditoría interna. Este normalmente es un pro-

cedimiento independiente, que puede tener de 2 a 3 páginas, y que tie-
ne que escribirse antes de que comience la auditoría interna. Como con
el Procedimiento para el control de documentos, puede utilizarse un
Procedimiento de auditoría interna para cualquier sistema de gestión.
Procedimiento para acciones correctivas. Este procedimiento no

debe tener una longitud superior a 2 o 3 páginas, y puede escribirlo al
final del proyecto de implementación, aunque es mejor escribirlo antes
para que los empleados puedan acostumbrarse a él.
272
APÉNDICE B – DIAGRAMA DE
IMPLEMENTACIÓN DE LA ISO
27001:2013
273
SEGURO & SIMPLE
274
APÉNDICE C – APLICABILIDAD
DE LA ISO 27001 DIVIDIDO POR
INDUSTRIA
Esta es una lista de las cuestiones más comunes en las que ISO 27001
puede ayudarle. Algunas de estas cuestiones son típicas para una in-
dustria en particular, mientras que otras cuestiones son relevantes para
todas las industrias.
Cuestiones Cómo puede ayudar

Industria
a resolver ISO 27001
Todas las in- Cumplir con un núme- ISO 27001 le proporciona un muy
dustrias ro cada vez mayor de buen marco de trabajo para iden-
requisitos legales y re- tificar todos los requerimientos,
gulatorios y definir un método sistemático
para cumplir con todos ellos;
Además, la mayoría de la legisla-
ción de seguridad de la informa-
ción se basa en ISO 27001.
Todas las in- Defensa contra un ISO 27001 proporciona una me-
dustrias número creciente de todología para contar los dife-
incidentes de seguridad rentes tipos de amenazas – físico,
(es decir, ataques de cibernético, interior, natural, etc..
hackers, espionaje in- Es muy bueno para combinar
dustrial, malversaciones diferentes tipos de actividades de
de fondos, fallos de seguridad en un solo sistema.
hardware, etc.)
Todas las in- Priorizar las inversiones Mediante el análisis de riesgos se-
dustrias en seguridad gún ISO 27001, usted tendrá una
idea clara de qué salvaguardas
deben aplicarse rápidamente.
275
SEGURO & SIMPLE

Industria
Todas las in- Disminuir el coste de La lógica básica de la ISO 27001
dustrias los incidentes de segu- es intentar prevenir incidentes
ridad – en la mayoría de los casos, el
coste de la implementación de la
ISO 27001 es mucho menor que
el ahorro de costes conseguido
debido a la prevención de inci-
dentes.
Todas las in- Proporcionar una he- ISO 27001 tiene varias secciones
dustrias rramienta para la alta dedicadas a la alta dirección –
dirección con la que esta tiene que estar involucrada
puedan comprender y en la gestión de seguridad de la
controlar cuestiones de información, y en la información
seguridad que tiene que recibir. Lo mejor de
todo es que la ISO 27001 ayuda
a los profesionales de seguridad,
a empezar a presentar su trabajo,
en el lenguaje de los negocios,
que es el idioma entendido por
los altos directivos.
Todas las in- Ganar ventaja competi- Muchas grandes empresas, en-
dustrias tiva en licitaciones tidades financieras y agencias
gubernamentales prefieren pro-
veedores que tienen certificado
ISO 27001.
Todas las in- Definir roles y responsa- ISO 27001 requiere una defini-
dustrias bilidades de seguridad ción clara de quién es respon-
sable de todo lo relativo a la
seguridad; también proporciona
una forma natural de identificar
quién debe ser responsable de
cada área.
276
Apéndice

Industria
Compañías Convencer a los clien- Mediante la obtención de un cer-
de TI (pro- tes que su información tificado ISO 27001, las empresas
veedores de está a salvo acreditan (a través de una enti-
servicios en dad certificadora) que protegen
la nube, de- la información de acuerdo con el
sarrolladores estándar líder de seguridad de la
de software, información.
etc.)
Distintos Disminuir las penali-La implementación de ISO 27001
prestadores zaciones debido a la aumenta el nivel de resiliencia de
de servicio indisponibilidad de su
una organización - como conse-
(online y offli- servicio cuencia, el número de incidentes
ne) es menor, y su duración es más
corta.
Instituciones Encontrar la metodolo- La gestión de riesgos de segu-
financieras gía para la gestión del ridad de la información es una
riesgo operacional parte de la gestión del riesgo
operacional; por lo tanto, ISO
27001 proporciona una metodo-
logía para la gestión de una parte
importante de los riesgos opera-
cionales.
Organizacio- Proteger registros de ISO 27001 proporciona una me-
nes del sector salud todología para la protección de
de la salud todo tipo de información – sobre
todo la información que se con-
sidera más sensible (por ejemplo
datos personales del paciente o
datos del cliente).
Compañías Protección de la propie- ISO 27001 proporciona una me-
de alta tec- dad intelectual todología para la protección de
nología todo tipo de información – sobre
todo la información que se con-
sidera más sensible (por ejemplo,
conocimientos, desarrollo de pro-
ductos, etc.).
277
SEGURO & SIMPLE

Industria
Compañías Encontrar la metodo- ISO 27001 proporciona un flujo
de consulto- logía para ayudar a paso a paso para empresas de
ría resolver cuestiones de consultoría que implementan
seguridad relacionadas salvaguardas de seguridad de la
con sus clientes información en las compañías de
sus clientes.
278
APÉNDICE D – INFOGRAFÍA:
ISO 27001 (REVISIÓN 2013) –
¿QUÉ HA CAMBIADO?
Nueva revisión ISO 27001:2013
¿QUÉ HA CAMBIADO?
ISO/IEC 27001 es el estándar internacional líder para la gestión de la
seguridad de la información, publicado por la Organización
Internacional de Normalización. Después de 8 años, la revisión del
2005 fue reemplazada por la revisión ISO/IEC 27001:2013
Historia de los estándares de seguridad de la información

1995 2000 2007
Fue publicado Se convirtió en Se convirtió en
BS 7799-1 ISO/IEC 17799 ISO/IEC 27002
1999 2005 2013

Fue publicado Se convirtió en Se convirtió en
BS 7799-2 ISO 27001:2005 ISO 27001:2013
1995 2000 2005 2010 2015
Alineación
ISO 9001
ISO 14001
ISO 27001
279 ISO 20000
La revisión del 2013 es
compatible con las
Directivas del Anexo SL
(esto está alineado con
SEGURO &1995
SIMPLE 2000 2005 2010 2015
Alineación
ISO 9001
ISO 14001
ISO 27001 ISO 20000
La revisión del 2013 es
compatible con las
Directivas del Anexo SL
(esto está alineado con
ISO 22000 otros estándares de
gestión) ISO 22301
Periodo de transición
Las compañías certificadas contra la revisión
del 2005 tiene que hacer la transición
Las compañías pueden a la revisión del
Revisión antigua certificarse contra la 2013 antes del 25 de
del 2005 revisión del 2005 hasta Septiembre de 2015
el 25 de septiembre de (periodo de 2 años)
2014 (periodo de 1 año)
Nueva revisión Las compañías pueden certificarse contra la

del 2013 revisión del 2013 desde el 25 de septiembre del
2013
| ||||||| || | | | | | | | | |||| ||||||| || |

September 25, 2013 September 25, 2014 September 25, 2015
Comparación
Revisión antigua del 2005 Nueva revisión del 2013
Publicada el 15 de Octubre de 2005 Publicada el 25 de septiembre de 2013
11
secciones en el Anexo A secciones en el Anexo A
14
133
controles en el Anexo A controles en el Anexo A
114
280
del 2013 revisión del 2013 desde el 25 de septiembre del
2013
| ||||||| || | | | | | | | | |||| ||||||| || |

September 25, 2013 September 25, 2014 September 25, 2015 Apéndice
Comparación
Revisión antigua del 2005 Nueva revisión del 2013
Publicada el 15 de Octubre de 2005 Publicada el 25 de septiembre de 2013
11
secciones en el Anexo A secciones en el Anexo A
14
133
controles en el Anexo A controles en el Anexo A
114
Requisitos
Nuevos requisitos en la Requisitos que ya no están en la
revisión de la ISO 27001:2013 ISO 27001:2013
• Propietarios de riesgos (cláusula 6.1.2 c) • Acciones preventivas

• Partes interesadas (cláusula 4.2) • El Control de documentos, la Auditoría
interna y las Acciones correctivas siguen
siendo un requisito en el estándar, pero ya
no es necesario documentarlos
• Anexo B
• Anexo C
Similitudes y diferencias
ÁREAS MÁS IMPORTANTES
Mayor
Partes interesadas
Objetivos, monitorización & medición
Alcance del SGSI
Moderado
Política de seguridad de la información

GRADO DE CAMBIO
Análisis y tratamiento de riesgos

Comunicación
Gestión de documentos
Controles del Anexo A
Liderazgo y compromiso
Declaración de aplicabilidad
281de riesgos
Plan de tratamiento
Bajo
Gestión de recursos humanos

Auditoría interna
Revisión por dirección
siendo un requisito en el estándar, pero ya
no es necesario documentarlos
• Anexo B
• Anexo C
SEGURO & SIMPLE
Similitudes y diferencias
Mayor ÁREAS MÁS IMPORTANTES
Partes interesadas
Objetivos, monitorización & medición
Alcance del SGSI
Moderado
Política de seguridad de la información

GRADO DE CAMBIO
Análisis y tratamiento de riesgos

Comunicación
Gestión de documentos
Controles del Anexo A
Liderazgo y compromiso
Declaración de aplicabilidad
Plan de tratamiento de riesgos
Bajo
Gestión de recursos humanos

Auditoría interna
Acciones correctivas
Nuevos controles de seguridad
Nuevos controles de la revisión del 2013,

que no existen en la revisión del 2005:
A.6.1.5 Seguridad de la información en la gestión de proyectos
14.2.1 Política de desarrollo seguro
14.2.5 Principios de ingeniería de sistemas seguros
14.2.6 Entorno de desarrollo seguro
14.2.8 Pruebas funcionales de seguridad de sistemas
16.1.4 Evaluación y decisión sobre los eventos de seguridad de la información
17.2.1 Disponibilidad de los recursos de tratamiento de la información
Courtesy of: Information Security &

Business Continuity Academy
www.iso27001standard.com
Copyright ©2013 EPPS Services Ltd
282
APÉNDICE E – MATRIZ
ISO 27001 VS ISO 20000
ISO/IEC
ISO/IEC 20000-1:2011 Explicación
27001:2013
0 Introducción Introducción
Aunque no existen sub-cláusulas en
la introducción de la ISO 20000-1,
ambos estándares establecen en sus
introducciones la necesidad de un
enfoque a procesos para la planifi-
0.1 General 1.1 General cación, el establecimiento, la imple-
mentación, la operación, el manteni-
miento y la mejora, para cumplir con
los requisitos de un sistema de ges-
tión ISO (en este caso para seguridad
de la información y para servicios).
Compatibili-
dad con otras
No existen cláusulas similares en ISO
0.2 normas de
20000-1.
sistema de
gestión
1 Alcance 1 Alcance
Aunque no existen sub-cláusulas en
1.1 General el ámbito de la ISO 27001, ambos
estándares establecen aquí lo que
incluyen: requisitos para la gestión
del sistema, gestión de servicios
(ISO 20000 - 1), y evaluación y trata-
miento de riesgos de seguridad de la
información (ISO 27001).
La generalidad del estándar que co-

1.2 Aplicación
rresponda (apto para todo tipo de
organizaciones, independientemen-
te del tamaño, tipo y naturaleza).
Al igual que ISO 27001, ISO 20000-1

no permite exclusiones de cláusulas.
283
SEGURO & SIMPLE
ISO/IEC
27001:2013
Este requisito es idéntico para
Normativa de Normativa de ambos estándares, excepto las
2 2
referencia referencia referencias específicas para cada
estándar.
Ambos estándares incluyen sus pro-
pios “fundamentos y vocabulario” (ISO
Términos y Términos y
3 3 27000 para ISO 27001 e ISO 20000-1
definiciones definiciones
proporciona sus propias definiciones
para los principales términos).
Establecer y
4.5
Contexto de la mejorar el SGS
4
organización
Procesos de
7
relación
Definir el al- Puede utilizar el mismo documento

4.5.1
cance para definir el proceso de identi-
ficación de las partes interesadas,
y para los requisitos legales, regla-
mentarios, contractuales y otros
relacionadas con los servicios que
Comprensión serán proporcionados, y las respon-
de la organi- sabilidades para su cumplimiento.
4.1 Gestión de re-
zación y de su Puede utilizar el Plan del sistema
contexto 7.1 laciones con el de gestión del servicio (SGS), ma-
negocio pear los aspectos específicos del
contexto del sistema de gestión del
servicio y, con unos ajustes, puede
utilizar un mapeo similar para iden-
tificar los aspectos del contexto de
seguridad de información del SGSI.
Comprensión Definir el al-
4.5.1
de las ne- cance
cesidades y
4.2 Puede utilizar el mismo documento
expectativas
Gestión de re- para listar los requisitos de los ser-
de las partes
7.1 laciones con el vicios que se proporcionan.
interesadas
negocio
284
Apéndice
ISO/IEC
27001:2013
Determinación
del alcance
del sistema Definir el al- Puede utilizar el mismo documento
4.3 4.5.1
de gestión de cance para definir el alcance de su SGS.
seguridad de
la información
No existe una cláusula en ISO
20000-1 similar a esta cláusula de
ISO 27001, pero las siguientes cláu-
sulas proporcionan algunos detalles
útiles que pueden ayudarle a enten-
der mejor la cláusula 4.4 de la ISO
27001:
● ISO 20000-1 cláusula 4.5.2

Planificar el SGS (Planificar) –
Vea los detalles en las cláusulas
6 y 7 de ISO 27001.
Sistema de
gestión de se- ● ISO 20000-1 cláusula 4.5.3
4.4
guridad de la Implementar y operar el SGS
información
(Hacer) – Vea los detalles en la
cláusula 8 de la ISO 27001.
● ISO 20000 cláusula 4.5.4 Mon-

itorizar y revisar el SGS (Veri-
ficar) – Vea los detalles en la
cláusula 9 de la ISO 27001.
● ISO 20000 cláusula 4.5.5 Man-

tener y mejorar el SGS (Actuar)
– Vea los detalles en las cláusu-
las 6 y 10 de la ISO 27001.
Responsabili-
4.1 dad de la direc-
5 Liderazgo ción
Gestión de la
6.6 seguridad de la
información
285
SEGURO & SIMPLE
ISO/IEC
27001:2013
Los requisitos son los mismos, y la
dirección tiene que tratar ambos
estándares de la misma manera con
Compromiso de
4.1.1 respecto a la implementación de
la dirección
políticas, provisión de recursos, me-
Liderazgo y jora continua, asignación de roles y
5.1 responsabilidades, etc.
compromiso
Política de se-
Este requisito es básicamente la
guridad de la
implementación de un SGSI; así,
información
mediante la realización de esta
6.6.1 a) (comunicación
cláusula de ISO 27001 puede con-
e importancia
seguir cumplir con la sub-cláusula
de la conformi-
6.6.1 a) de ISO 20000-1.
dad)
Los requisitos son casi los mismos,
y en teoría, se podrían cumplir a
través de un único documento. Sin
Política de ges-
4.1.2 embargo, es mejor si las políticas
tión del servicio
están escritas como documentos
separados, en cuyo caso deben ser
5.2 Política compatibles entre sí.
Política de se-
guridad de la Este requisito es básicamente la
información implementación de un SGSI; así,
(definición de mediante la realización de esta
6.6.1
objetivos de cláusula de la ISO 27001 puede
gestión de se- obtener a través de apartado 6.6.1
guridad de la b) de la norma ISO 20000-1.
información)
Autoridad, res- Los requisitos son los mismos, así
4.1.3 ponsabilidad y que los roles, las responsabilidades,
comunicación y las autoridades para ambos están-
Roles, respon- dares pueden ser comunicadas de
5.3 sabilidades y la misma manera. Por ejemplo, un
autoridades responsable, o varios responsables,
en la organiza- Representante deben ser asignados para supervi-
ción 4.1.4 sar actividades de gestión del ser-
de la dirección
vicio / seguridad de información; el
mismo auditor puede realizar audi-
torías del SGS y del SGSI, etc.
286
Apéndice
ISO/IEC
27001:2013
Gobierno de
los procesos No existe una cláusula similar en
4.2
operados por ISO 27001.
terceros
Responsabili-
4.1 dad de la direc-
ción
Planificar el
4.5.2
SGS (Planificar)
Mantener y
4.5.5 mejorar el SGS
(Actuar)
6 Planificación
Política de
seguridad de Este requisito de ISO 20000-1 in-
la información cluye la planificación de un SGSI;
(definición así, mediante la realización de
6.6.1 c)
del enfoque todos los elementos de la cláusula
and d)
del análisis de 6 de la ISO 27001 puede conseguir
riesgos, y reali- cumplir con las sub-cláusulas 6.6.1
zación del aná- c) y d).
lisis de riesgos)
Acciones
Abordar riesgos puede ser conside-
para tratar
rado como una acción preventiva,
6.1.1 los riesgos y 4.5.5.1 General
pero no se puede fusionar en el
oportunidades
mismo documento.
– general
Análisis de
riesgos de se- 4.5.2 j) Enfoque que
6.1.2 debe adoptarse
guridad de la
información 4.5.3 d) para la gestión El enfoque general puede ser el
de riesgos y el mismo, pero orientado a los riesgos
Tratamiento 6.6.1 c) criterio para la del servicio.
de riesgos de aceptación de
6.1.3
seguridad de 6.6.2 riesgos
la información
287
SEGURO & SIMPLE
ISO/IEC
27001:2013
Objetivos de
seguridad de Los objetivos de ambos estándares,
la información 4.1.1 Compromiso de y los planes para su realización,
6.2
y planificación 6.6.1 b) la dirección pueden colocarse en un solo docu-
para su conse- mento.
cución
Requisitos
generales del
4 sistema de
gestión del
servicio
Planificación
7 Soporte
de servicios
5.2
nuevos o modi-
ficados
Procesos de
6 provisión del
servicio
La organización debe determinar y
proporcionar los recursos necesa-
rios para la ejecución del proceso,
Provisión de para cumplir con los requisitos de
7.1 Recursos 4.4.1
recursos ambos estándares. Puede utilizar
los mismos procesos para cumplir
con los requisitos, como con un
proceso de compra.
7.2 Competencia ISO 27001 divide la competencia y
la concienciación, y enfatiza más la
Recursos huma- concienciación en ISO 20000-1. Sin
Conciencia- 4.4.2
7.3 nos embargo, puede utilizar un plan de
ción formación para ambos estándares
para reducir registros
Comunicación
5.2 c) con partes inte- La comunicación a las partes in-
7.4 Comunicación resadas teresadas debe establecerse para
Informes del ambos estándares.
6.2
servicio
288
Apéndice
ISO/IEC
27001:2013
Se puede aplicar el mismo procedi-
Información Gestión de la miento para cumplir con los requisi-
7.5 4.3
documentada documentación tos de ambos estándares, y estable-
cer un sistema de documentación.
Implementar y
4.5.3 operar el SGS
(Hacer)
Gestión de
continuidad y
8 Operación 6.3
disponibilidad
del servicio
Gestión de la
6.6 seguridad de la
información
Los indicadores clave del desempe-
Gestión de los
Planificación y ño (KPI) se pueden establecer para
procesos de
8.1 control opera- 4.5.3 e) los procesos de ambos estándares,
gestión del ser-
cional y se pueden describir en el mismo
vicio
documento.
Identificación,
evaluación y El enfoque general puede ser el
4.5.3 d) gestión de los mismo, pero orientado a los riesgos
riesgos sobre del servicio.
los servicios
Análisis de Aunque el primer paso de este
riesgos de se- tema específico de ISO 20000-1
8.2
guridad de la es en el campo de la continuidad
información Requisitos de
del negocio, el paso del análisis
continuidad y
6.3.1 de riesgos puede utilizar el mismo
disponibilidad
enfoque general utilizado por el
del servicio
análisis de riesgos de seguridad de
la información, pero orientado a los
riesgos del servicio.
289
SEGURO & SIMPLE
ISO/IEC
27001:2013
Identificación,
evaluación y El enfoque general puede ser el
4.5.3 d) gestión de los mismo, pero orientado a los riesgos
riesgos sobre del servicio.
los servicios
Aunque el primer paso de este
tema específico de ISO 20000-1
es en el campo de la continuidad
Planes de con-
Tratamiento del negocio, el paso del análisis
tinuidad y dis-
de los riesgos 6.3.2 de riesgos puede utilizar el mismo
ponibilidad del
8.3 de seguridad enfoque general utilizado por el
servicio
de la informa- análisis de riesgos de seguridad de
ción la información, pero orientado a los
riesgos del servicio
Controles de
6.6.2 seguridad de la
información Estas dos cláusulas de ISO 20000-1
pueden completarse exactamente
Cambios e con los elementos de la cláusula 8
incidencias de de la ISO 27001.
6.6.3
seguridad de la
información
Monitorizar y
4.5.4 revisar el SGS
(Verificar)
Gestión de
Evaluación del continuidad y
9 6.3
desempeño disponibilidad
del servicio
Gestión de la
6.6 seguridad de la
información
No existen cláusulas similares en
4.5.4.1 General
ISO 27001.
290
Apéndice
ISO/IEC
27001:2013
La organización debe demostrar
la eficacia del sistema a través de
la monitorización de los paráme-
tros que la organización identificó
como importantes para la realiza-
ción del proceso. Aunque están
brevemente descritos en ISO
4.5.4.1 General 20000-1, estos requisitos se de-
tallan mejor en ISO 27001, y los
requisitos de ambos estándares
se pueden cumplir con un mis-
mo documento, por ejemplo, un
Cuadro de Mando o una matriz
de indicadores clave de desem-
peño.
Puede utilizar el mismo documen-
Seguimiento, to para determinar la frecuencia y
medición, los métodos de prueba para eva-
9.1 luar la viabilidad de las medidas y
análisis y eva-
luación los acuerdos para la continuidad
del servicio, y para el estableci-
miento de las medidas correctivas
necesarias.
Monitorización La organización debe demostrar

y prueba de la eficacia de los servicios presta-
la continuidad dos a través de la monitorización
6.3.3
y de la dispo- de los parámetros que la organi-
nibilidad del zación identificó como importan-
servicio tes para la prestación de servicios.
Aunque brevemente descritos en
la ISO 20000-1, estos requisitos
se detallan mejor en ISO 27001
y los requisitos de ambos están-
dares se pueden cumplir con un
mismo documento, por ejemplo,
un Cuadro de Mando o una ma-
triz de indicadores clave de des-
empeño.
291
SEGURO & SIMPLE
ISO/IEC
27001:2013
El mismo procedimiento para la au-
Auditoría inter-
4.5.4.2 ditoría interna puede ser aplicado
na
para ambos estándares.
Auditoría in- Este requisito de ISO 20000-1 es si-
9.2 Política de se- milar a la auditoría interna necesaria
terna
guridad de la in- para un SGSI; por tanto, cumpliendo
6.6.1 e)
formación (au- la cláusula 9.2 de ISO 27001 puede
ditoría interna) conseguir cumplir con la sub-cláusu-
la 6.6.1 e) de ISO 20000-1.
Aunque el requisito es el mismo,
los elementos de entrada de la revi-
sión por dirección son diferentes. Se
Revisión por la
4.5.4.3 puede utilizar el mismo documento
dirección
para ambos estándares, pero debe
contener elementos de entrada se-
Revisión por la parados para ambos estándares.
9.3
dirección
Política de se- Este requisito de ISO 20000-1 incluye
guridad de la la revisión de los resultados de las au-
información ditorías de SGSI; por tanto, cumpliendo
6.6.1 f)
(revisión de los con la cláusula 9.3 de ISO 27001, pue-
resultados de de conseguir cumplir con la sub-cláu-
auditoría) sula 6.6.1 f) de la ISO 20000-1.
Mantener y
10 Mejora 4.5.5 mejorar el SGS
(Actuar)
Los requisitos son casi los mismos
No conformi- (ISO 27001 no requiere explícita-
10.1 dad y acciones 4.5.5.1 General mente acciones preventivas), y en
correctivas ambos casos se puede utilizar el
mismo procedimiento.
Como cada sistema de gestión, el
énfasis está en la mejora continua,
Mejora conti- Gestión de me-
10.2 4.5.5.2 que se lleva a cabo a través de un
nua joras
procedimiento común para las ac-
ciones correctivas.
Procesos de No existen cláusulas similares en
8
resolución ISO 27001.
Procesos de No existen cláusulas similares en
9
control ISO 27001.
292
APÉNDICE F – PLANTILLA
PROPUESTA PROYECTO PARA LA
IMPLEMENTACIÓN DE LA ISO 27001
[logo de la organización]
[nombre de la organización]
PROPUESTA DE PROYECTO PARA LA

Código:
Versión:
Fecha de la versión:
Creado por:
Aprobado por:
Nivel de confidencialidad:
293
SEGURO & SIMPLE
Historial de modificaciones
Fecha Ver- Creado por Descripción de la modifica-

sión ción
xx/xx/2014 0.1 Dejan Kosutic Plantilla básica del documento
294
Apéndice
1. Propósito
El propósito de este documento es proponer el proyecto de implemen-
tación de ISO 27001 y/o ISO 22301 a la alta dirección.
Este documento no es un plan de proyecto – el Plan de proyecto se

desarrollará una vez que el proyecto sea formalmente aprobado.
2. Razones para la implementación

Las principales razones para la implementación de ISO 27001/ISO
22301 son las siguientes:
● cumplimiento de leyes y reglamentos
● reducción de costes en los incidentes
● ventaja de marketing
● optimización de procesos
● menor dependencia de individuos
3. Objetivos del proyecto

Los objetivos para el proyecto son:
● implementación de la ISO 27001 / ISO 22301 a lo largo de, o antes

de [fecha]
● la implementación de la seguridad de la información / continuidad

de negocio no debe interrumpir la operación normal de las acti-
vidades
● los miembros del equipo de proyecto pueden dedicar un [xyz%]

de su tiempo a este proyecto
295
SEGURO & SIMPLE
4. Duración del proyecto y estructura

El proyecto de implementación se divide en diferentes fases:
Fase de planificación, incluyendo el desarrollo de la política de alto ni-

vel, el análisis y tratamiento de riesgos
1) Implementación de los controles seleccionados
2) Auditoría interna
3) Revisión por dirección
4) Certificación
Los principales hitos del proyecto de implementación son:
Hito Fecha de vencimiento

Fase de planificación
Implementación de los controles
Auditoría interna
Certificación
El contenido detallado de los hitos y las responsabilidades se describen

en el documento del Plan de proyecto.
5. Responsabilidades
El proyecto será liderado por [nombre], y los miembros del equipo de
proyecto serán [listar nombres].
296
Apéndice
6. Recursos
Los recursos necesarios para implementar el proyecto incluyen los re-
cursos humanos, financieros y técnicos.
Los recursos financieros incluyen:
● C
antidad: [definir la cantidad de dinero necesaria para finalizar el
proyecto]
○ Tipos de costes: [dividir los costes según el tipo de coste, e in-

cluir todos los recursos mencionados aquí, por ejemplo, recur-
sos humanos - internos y externos, técnicos y otros]
Los recursos humanos incluyen:
● Recursos internos – [listar todos los recursos internos, por ejemplo

nombre del grupo, nombre del proyecto, etc.]
● Recursos externos – [listar todos los recursos externos, por ejemplo

empresa de consultoría, etc.]
Los recursos técnicos incluyen:
● Herramienta – nombre de la herramienta: [introducir el nombre de

la herramienta]
● Equipamiento – [listar equipamiento necesario]
Otros recursos incluyen:
● Documentación – [listar toda la documentación que es requerida,

por ejemplo Paquete de documentos ISO 27001 o ISO 22301, los
estándares, etc.]
297
SEGURO & SIMPLE
7. Entregables
Durante el proyecto de implementación del SGSI, se escribirán los si-
guientes documentos (algunos de los cuales contienen apéndices que
no se indican expresamente aquí):
●P
rocedimiento para el control de documentos y registros –
procedimiento de descripción de reglas básicas para la redacción,
aprobación, distribución y actualización de documentos y registros
●P
rocedimiento para la identificación de requerimientos –
procedimiento para la identificación de obligaciones legales, re-
glamentarias y contractuales
●A
lcance del Sistema de Gestión de Seguridad de la Informa-
ción – un documento para definir de manera precisa las ubicacio-
nes, la tecnología, los activos, etc. que forman parte del alcance
● Política de Seguridad de la Información – Este es un documen-

to clave utilizado por la dirección para el control de la gestión de
la seguridad de la información
●M
etodología de análisis y tratamiento de riesgos – describe
la metodología para la gestión de riesgos de la información
●T
abla de análisis de riesgos – la tabla es el resultado de la eva-
luación de los activos, amenazas y vulnerabilidades
● Tabla de tratamiento de riesgos – una tabla en la que se selec-

cionan los controles de seguridad que son apropiados para cada
riesgo no aceptable
● I nforme de análisis y tratamiento de riesgos – un documento

que contiene todos los documentos claves realizados en el proce-
so de análisis y tratamiento de riesgos
●D
eclaración de Aplicabilidad – un documento que determina
los objetivos y la aplicabilidad de cada control según el Anexo A
del estándar ISO 27001
298
●P
rocedimiento para la auditoría interna – define cómo se se-
leccionan los auditores, cómo se escriben los programas de audi-
toría, cómo se llevan a cabo las auditorías y cómo se informan los
resultados de la auditoría
●P
rocedimiento para las acciones correctivas – describe el pro-
ceso de implementación de las acciones correctivas y preventivas
● F ormulario para las minutas de la Revisión por Dirección –

un formulario utilizado para crear minutas de la reunión que reali-
za la dirección para revisar la adecuación del SGSI
● Plan de tratamiento de riesgos – un documento de implemen-

tación que especifica los controles a implementar, quién es res-
ponsable de la implementación, los plazos y los recursos
Otros documentos que se deban escribir durante la implementación del

SGSI, se especificarán en el Plan de tratamiento de riesgos.
299
APÉNDICE G – LISTA DE
VERIFICACIÓN PARA LA
Fases de Reali-
Tarea
implementación zado
Obtener el apoyo Investigar qué beneficios de la ISO
de la dirección 27001 serían aplicables a su empresa
Presentar los beneficios a la direc-
ción y conseguir su compromiso
Conseguir la aprobación for-
mal para el proyecto
Prepararse para Decidir si va a utilizar consultores, o va

su proyecto a utilizar plantillas de documentos
Comprar el estándar ISO 27001
Educar a su equipo de proyecto
Escribir el plan del proyecto, incluyendo la
definición del jefe de proyecto, el equipo
del proyecto, el patrocinador del proyec-
to, los recursos necesarios y los hitos
Definir qué actores necesitan estar
informados acerca de cada
paso del proyecto
Organizar reunión
Identificar re- Identificar partes interesadas

querimientos Identificar los requerimien-
tos de las partes interesadas
300
Apéndice
Definir el alcance, el Escribir el Documento del Alcance del

propósito de la direc- SGSI
ción y las responsabi- Escribir la Política de Seguridad de la
lidades Información
Decidir los objetivos de seguridad de la
información
Implementar procedi- Escribir un procedimiento para el control

mientos de soporte de documentos
Escribir un procedimiento para la auditoría
interna
Escribir un procedimiento para las
acciones correctivas
Realizar la gestión de Desarrollar una metodología de análisis de

riesgos riesgos
Realizar el análisis de riesgos
Realizar el tratamiento de riesgos
Escribir el informe de análisis y
tratamiento de riesgos
Desarrollar el perfil Desarrollar la Declaración de Aplicabilidad

de seguridad de su Desarrollar el Plan de tratamiento de
compañía, y el plan riesgos
de acción para con-
seguirlo Aceptar los riesgos residuales
Implementar los con- Implementar todos los controles definidos

troles en el Plan de tratamiento de riesgos
Mantener registros de la implementación
301
SEGURO & SIMPLE
Realizar programas Llevar a cabo capacitaciones para los

de capacitación y empleados que carecen de las
concienciación habilidades requeridas
Realizar programas de sensibilización para
todos los empleados, y para los terceros
que tienen un rol en su SGSI
Operar el SGSI Mantener todos los registros requeridos

por sus propias políticas y procedimientos
Realizar acciones correctivas cuando sea
necesario
Monitorizar y medir Asegúrese de que monitoriza todos sus

el SGSI sistemas
Mida si ha alcanzado los objetivos
establecidos para el SGSI y sus controles
Realizar la auditoría Desarrollar el programa de auditoría

interna Realizar la auditoría interna
Escribir un informe de auditoría interna
Realizar acciones correctivas
Realizar la revisión Realizar la revisión por dirección

por dirección Mantener registros de la revisión por
dirección
Realizar acciones correctivas
Auditoría de Obtener propuestas de diferentes

certificación entidades certificadoras
Seleccionar la entidad certificadora
Fase 1 de la auditoría de certificación
Fase 2 de la auditoría de certificación
Visitas de seguimiento
302
APÉNDICE H – PLAN DE PROYECTO
PARA LA IMPLEMENTACIÓN DE LA
ISO 27001
[logo de la organización]
[nombre de la organización]
PLAN DE PRYECTO
para la implementación del Sistema de Gestión
de Seguridad de la Información
Código:
Versión:
Fecha de la versión:
Creado por:
Aprobado por:
Nivel de confidenciali-
dad:
303
SEGURO & SIMPLE
Historial de modificaciones
Fecha Ver- Creado por Descripción de la
sión modificación
01/10/2013 0.1 Dejan Kosutic Esquema del documento
básico
304
Apéndice
1. Propósito, alcance y usuarios
El propósito del Plan de proyecto es definir claramente el objetivo del
proyecto de implementación del Sistema de Gestión de Seguridad de la
Información (SGSI), los documentos que se escribirán, los plazos, y los
roles y responsabilidades en el proyecto.
El Plan de proyecto aplica a todas las actividades realizadas en el pro-

yecto de implementación del SGSI.
Los usuarios de este documento son miembros de [alta dirección] y

miembros del equipo de proyecto.
2. Documentos de referencia
● Estándar ISO/IEC 27001
● Estándar ISO 22301
● Estándar BS 25999-2
● [decisión o cualquier documento similar para la descripción del

lanzamiento del proyecto]
● [metodología para la gestión del proyecto]
3. Proyecto de implementación del SGSI

3.1. Objetivo del proyecto
Implementar el Sistema de Gestión de Seguridad de la Información se-
gún el estándar ISO 27001 en [fecha] a más tardar.
305
SEGURO & SIMPLE
3.2. Resultados del proyecto
Durante el proyecto de implementación del SGSI, se escribirán los si-

guientes documentos (algunos de los cuales contienen apéndices que
no se indican expresamente aquí):
●P
rocedimiento para el control de documentos y registros – pro-
cedimiento de descripción de reglas básicas para la redacción,
aprobación, distribución y actualización de documentos y registros
●P
rocedimiento para la identificación de requerimientos – proce-
dimiento para la identificación de obligaciones legales, reglamen-
tarias y contractuales
●A
lcance del Sistema de Gestión de Seguridad de la Información
– un documento para definir de manera precisa las ubicaciones, la
tecnología, los activos, etc. que forman parte del alcance
● Política de Seguridad de la Información – Este es un documento
clave utilizado por la dirección para el control de la gestión de la
seguridad de la información
● Metodología de análisis y tratamiento de riesgos – describe la
metodología para la gestión de riesgos de la información
●T
abla de análisis de riesgos – la tabla es el resultado de la evalua-
ción de los activos, amenazas y vulnerabilidades
● Tabla de tratamiento de riesgos – una tabla en la que se selec-
cionan los controles de seguridad que son apropiados para cada
riesgo no aceptable
● Informe de análisis y tratamiento de riesgos – un documento
que contiene todos los documentos claves realizados en el proce-
so de análisis y tratamiento de riesgos
● Declaración de Aplicabilidad – un documento que determina los
objetivos y la aplicabilidad de cada control según el Anexo A del
estándar ISO 27001
●P
rocedimiento para la auditoría interna – define cómo se seleccio-
nan los auditores, cómo se escriben los programas de auditoría, cómo
306
Apéndice
se llevan a cabo las auditorías y cómo se informan los resultados de la
auditoría
●P
rocedimiento para las acciones correctivas – describe el proceso
de implementación de las acciones correctivas y preventivas
● F ormulario para las minutas de la Revisión por Dirección – un
formulario utilizado para crear minutas de la reunión que realiza la
dirección para revisar la adecuación del SGSI
● Plan de tratamiento de riesgos – un documento de implementa-
ción que especifica los controles a implementar, quién es respon-
sable de la implementación, los plazos y los recursos
Otros documentos que se deban escribir durante la implementación del
SGSI, se especificarán en el Plan de tratamiento de riesgos
3.3. Plazos
Los plazos para la aceptación de documentos individuales en el curso

de la implementación del SGSI son los siguientes:
Documento Plazos para la aceptación del

documento
La presentación final de los resultados del proyecto está prevista para

el día [fecha].
307
SEGURO & SIMPLE
3.3. Organización del proyecto
3.3.1. Patrocinador del proyecto
Cada proyecto tiene asignado un “patrocinador”, que no participa ac-

tivamente en el proyecto. El patrocinador del proyecto debe ser regu-
larmente informado por el responsable del proyecto sobre el estado del
proyecto, e intervenir si el proyecto se detiene.
[nombre, cargo] ha sido designado como patrocinador del proyecto.
3.3.2. Responsable del proyecto
El rol del responsable del proyecto es garantizar los recursos necesarios

para la ejecución del proyecto, coordinar el proyecto, informar al patro-
cinador del progreso, y llevar a cabo tareas administrativas relacionadas
con el proyecto. La autoridad del responsable del proyecto debe ser tal
que pueda asegurar la ejecución del proyecto sin interrupciones dentro
de los plazos establecidos.
[nombre, cargo] ha sido designado como responsable del proyecto.
3.3.3. Equipo de proyecto
El rol del equipo del proyecto es ayudar en diversos aspectos durante la im-
plementación del proyecto, para llevar a cabo las tareas especificadas del
proyecto, y para tomar decisiones sobre cuestiones que requieren un enfo-
que multidisciplinario. El equipo del proyecto se reúne antes de completar
la versión final de los documentos de la sección 2 de este Plan de proyecto,
y en los casos en los que el responsable de proyecto lo estime necesario.
Tabla de participantes en el proyecto
Nombre Unidad organizacional Cargo Teléfono E-mail
308
Apéndice
3.4. Principales riesgos del proyecto
Los principales riesgos en la implementación del proyecto son los si-

guientes:
1) Extensión de los plazos en la fase del análisis de riesgos
2) Extensión de los plazos durante el desarrollo de los planes de con-

tinuidad de negocio
3) Realizar actividades que incurran en gastos innecesarios y pérdida

de tiempo
4) Selección de demasiados controles y/o demasiado caros
Las medidas para reducir los riesgos mencionados, son las siguientes:
● El responsable de proyecto monitoriza que todas las actividades

en el proyecto se realicen dentro de los plazos definidos, y busca
la intervención del patrocinador del proyecto en tiempo y forma
● Contratar a un consultor para que asegure que el tiempo o los

recursos no se gastan en actividades que no son importantes para
el proyecto, y que las actividades individuales no se dirigen en la
dirección equivocada
● Contratar a un consultor para proponer controles más rentables
3.5. Herramientas para la implementación del proyecto, e informes
Se creará una carpeta compartida, en la red local, que incluirá todos los
documentos producidos durante el proyecto. Todos los miembros del
equipo del proyecto tendrán acceso a estos documentos. Solamente
el responsable del proyecto [y los miembros del equipo de proyecto]
estará autorizado para modificar y borrar archivos.
El responsable del proyecto preparará mensualmente un informe de la

implementación del proyecto, y se lo enviará al patrocinador del proyecto.
309
SEGURO & SIMPLE
4. Gestión de registros guardados en base a este documento
Nombre del Ubicación Persona Controles Tiempo

registro del archivo responsable para la pro- de reten-
del archivo tección del ción
registro
Informe de Carpeta Responsable Sólo el respon- Los infor-
implemen- compartida del proyecto sable del pro- mes son
tación del para activida- yecto está au- almacena-
proyecto (en des relacio- torizado para dos duran-
formato elec- nadas con el editar datos te un plazo
trónico) proyecto de 3 años
5. Validez y gestión de documentos

Este documento es válido hasta el [fecha].
El propietario de este documento es el [cargo].
Al evaluar la efectividad y adecuación de este documento, es necesario

tener en cuenta los siguientes criterios:
● Si todos los empleados involucrados en el proyecto realizan sus

actividades en conformidad con este documento.
● Si se cumplen todos los plazos del proyecto.
310
APÉNDICE I – LISTA DE PREGUNTAS
PARA HACERLE A SU CONSULTOR
ISO 27001
Antes de decidir sobre la contratación de un consultor para la imple-

mentación de la ISO 27001, considere estas preguntas, y úselas para
hablar con potenciales consultores.
Preguntas generales:
1) ¿Cuál es la experiencia del consultor en su industria en particular?

[Trate de relacionar la experiencia del consultor con su industria]
2) ¿Cuántos clientes tiene? ¿A qué tipo de clientes ha ofrecido sus
servicios? ¿Puede proporcionar una lista de referencia? [Verifique
si tiene experiencia con empresas del tamaño de la suya]
3) ¿Cuál es su reputación? – ¿Qué dicen otros consultores de él?;
¿Qué dicen sus clientes sobre él? [No tenga miedo de llamar a sus
clientes – muy a menudo ellos estarán dispuestos a decirte abier-
tamente cómo actuó.]
4) ¿Cuál es su experiencia (líneas de negocio) en otras cuestiones
diferentes de ISO 27001? [Por ejemplo, una experiencia en difer-
entes tipos de operaciones, le ayudará a entender sus procesos y
sus retos de seguridad.]
5)
¿Cuál es su experiencia en otros estándares ISO? [Tener
conocimientos por ejemplo de ISO 9001 o ISO 20000 aumentará el
nivel de servicio de la consultoría, porque será capaz de relacionar
la documentación con otras partes de su empresa.]
6) ¿Habla perfectamente su idioma? [Si no habla su idioma bien,
no sólo tendrá problemas de comunicación con sus empleados,
sino que además cometerá un montón de errores en las políticas
y procedimientos.]
311
SEGURO & SIMPLE
7) ¿Tiene algún conflicto de intereses? [Si su compañía está vendien-
do algún tipo de herramienta o software, ¿Están utilizando este
trabajo de consultoría para entender mejor cómo vender?]
Preguntas sobre experiencia en ISO 27001:
1)
¿Cuántos proyectos de implementación de ISO 27001 ha
completado con éxito en los últimos dos años?
2)
¿Cuántos de sus clientes solicitaron certificarse, y cuántos se
certificaron en ISO 27001 exitósamente (en su primer intento)?
3) ¿Cuál ha sido el proyecto ISO 27001 más complejo que ha tenido?
¿Podría describirlo brevemente? [Esta pregunta tiene como obje-
tivo la experiencia del consultor, y lo que usted (con su compleji-
dad) puede esperar de él.]
4) ¿ Cuál es su trayectoria educativa en el estándar ISO 27001? Es decir,
¿Qué certificados tiene? [Los cursos (por ejemplo el curso de Auditor
Jefe, o el curso de Implementador Jefe) dan excelentes conocimientos].
5) ¿Imparte cursos de ISO 27001? En caso afirmativo, ¿Cuántos cur-
sos ha realizado y para cuanta gente aproximadamente? [General-
mente los consultores que imparten cursos tienen una excelente
experiencia respecto a problemas del mundo real, y son capaces de
transferir sus conocimientos a otras personas - en este caso – usted.]
6) ¿Ha publicado alguna vez artículos de experto? ¿Cuántos y dónde?
7) ¿Trabajó como un auditor de certificación? [Esta experiencia le
ayudará a entender lo que solicitan las entidades certificadoras en
la certificación.]
8) ¿Puede mostrarle ejemplos sobre documentación de análisis de
riesgos que él haya creado para algunos de sus clientes? [Esto es
útil por varias razones. Usted puede juzgar: (1) lo profesional que
parece esta documentación, (2) si sería apropiada para su empresa;
y (3) si el consultor muestra abiertamente los datos de otros clientes,
lo cual le puede servir para saber si este consultor encaja en su em-
presa (él probablemente haga lo mismo con su documentación).]
312
Apéndice
Preguntas específicas sobre la implementación:
1. Puede describir brevemente los requisitos de la ISO 27001:
a) ¿Cuáles son las fases en la implementación? [Puede comparar

su información con los pasos de este libro]
b) ¿Cuál es la documentación mínima que necesita desarrollar?

[Puede comparar su información con la lista de documentos
obligatorios del de este libro]
2. ¿Cuáles son los problemas más comunes que ha tratado en los

proyectos de implementación de la ISO 27001, y cuál fue su
enfoque para resolverlos?
3.
¿Cuánto es el tiempo habitual para la implementación del
proyecto? ¿De qué depende el tiempo? [Puede comparar su es-
timación con esta herramienta Herramienta de la duración de la
implementación]
4. ¿Cómo definiría el consultor el alcance del proyecto para su caso?
5. ¿Cuál es su sugerencia con respecto a la definición de responsabilidades

para realizar tareas particulares en el proyecto? [Cuidado con todas
las tareas que proponga que usted debería estar haciendo.]
Precio:
1. ¿Cuál es el precio total de sus servicios (Asegúrese de que in-

cluye todo: análisis, entrevistas, desarrollo de documentación,
formación, gastos de transporte, etc..)? [Asegúrese de que ofrece
abiertamente el precio de todo el proyecto, porque de lo contrario
los costes adicionales podrían ser mayor que el precio inicial.]
2. ¿Qué servicios adicionales usted tendrá que comprar a otros pro-
veedores? [Por ejemplo, formación, literatura, plantillas, etc.]
3. ¿Cuál es el coste del tiempo empleado para la participación en el pro-

yecto? [A pesar de que el consultor trabajará en el proyecto, sus em-
pleados tendrán que invertir su tiempo para trabajar con el consultor.]
313
APÉNDICE J – LISTA DE PREGUNTAS
PARA HACERLE A UNA ENTIDAD
CERTIFICADORA DE ISO 27001
Antes de decidir la entidad certificadora para la certificación de la ISO

27001, considere estas preguntas, y úselas para hablar con la entidad
certificadora de ISO 27001.
1. ¿La entidad certificadora tiene acreditación para la auditoría de

ISO 27001? Si va a utilizar la certificación para temas de market-
ing, es importante asegurarse de que la certificación estará recon-
ocida. Asegúrese de que la entidad está acreditada, por ejemp-
lo en: Reino Unido acredita UKAS; en Estados Unidos acredita
ANAB.]
2.
¿Qué reputación tiene la entidad certificadora? [¿La entidad
certificadora tiene una buena reputación? ¿Qué dicen otras
empresas, y cuáles son las recomendaciones de otros clientes?]
3. ¿Cuántos auditores tiene la entidad certificadora con experiencia

en su industria? [Compare la experiencia del auditor con su
industria; el auditor no tendrá tiempo para aprender nada sobre
su industria]
4. ¿Qué idiomas hablan los auditores que tienen experiencia en su

industria? [Dependiendo del idioma que hablen sus empleados,
es fundamental para la auditoría la capacidad de los auditores
de entender las respuestas, y utilizar un lenguaje común, para de
esta manera realizar una auditoría exitosa.]
5. ¿Los auditores están cerca de su localización? [Aunque esto no

afecta a la calidad de la auditoría, los gastos del viaje se incluyen
en el precio.]
6. ¿Cuántos clientes tiene la entidad certificadora? ¿Qué tipo de
314
Apéndice
clientes tiene la entidad? ¿Le puede proporcionar una lista de ref-
erencia? [Averigüe si la entidad certificadora y los auditores tienen
experiencia con empresas de su tamaño. El tener experiencias de
auditoría con compañías más grandes, pueden ser difícil de apli-
car a empresas que son más pequeñas y simples.]
7. ¿Cuál es el requisito de la entidad certificadora en relación a la

madurez del SGSI antes de la certificación? [El tiempo que una
empresa debe tener registros adecuados del funcionamiento del
SGSI difiere entre las entidades certificadoras.]
8. ¿Cuál es la política de la entidad certificadora en relación a las

acciones correctivas y oportunidades de mejora? [Es importante
saber los plazos para las acciones correctivas, y si los auditores
pueden identificar oportunidades de mejora.]
9. ¿Qué nivel de experiencia laboral solicita la entidad a sus auditores

antes de convertirse en auditores de certificación? [La experiencia
en la industria es muy beneficiosa para los auditores de su em-
presa.]
10. ¿La entidad certificadora tiene un reconocimiento a nivel

mundial, o sólo localmente? [Dependiendo de su cliente, puede
ser más beneficiosa para usted una opción u otra.]
11. ¿La entidad tiene auditores con experiencia en otros estándares

de gestión? ¿La entidad certificadora ofrece auditorías integradas
para más de un estándar? [Algunas empresas implementan un
sistema integrado con estándares como ISO 9001 para calidad,
e ISO 14001 para medio ambiente. La capacidad para auditar
contra diversos estándares es útil en caso de que esto surja.]
12. ¿Qué considera la entidad certificadora que es su mayor beneficio

en comparación con otras entidades certificadoras? [Esto ayuda
a comprender lo que cree la entidad certificadora que son sus
puntos fuertes. Trate de encajar esto con lo que busca de su
entidad certificadora.]
315
SEGURO & SIMPLE
13. ¿Qué otros servicios se incluyen en el precio? [Si bien es cierto
que las entidades certificadoras no pueden hacer consultoría a
sus clientes, pueden incluir otros servicios beneficiosos para ust-
ed.]
14. ¿La entidad imparte cursos de ISO 27001? En caso afirmativo,

¿Cómo participan los auditores en la formación? [Muchas en-
tidades mantienen separados los auditores y a los formadores;
pero, los auditores experimentados en formación de ISO 27001
pueden conocer preguntas de principiantes, lo que le puede
ayudar a desarrollar su SGSI.]
15. ¿Qué opciones ofrece la entidad certificadora para las visitas de

seguimiento? [Las visitas de seguimiento se pueden realizar 1, 2
y hasta 4 veces al año. Para utilizar las visitas de seguimiento de
manera que le puedan ayudar a mejorar, debe comprender sus
opciones y lo que funcionará mejor para usted.]
16. ¿Cuál es el precio para el programa completo de auditorías

de certificación de tres años de seguimiento (mantenimien-
to)? ¿Cuántos días de auditoría serán necesarios por auditoría?
¿Cómo decide la empresa los días de auditoría y el precio? [La
mayoría de las empresas deciden el número de días de auditoría
en base al número de empleados. Si el número de días se calcula
de manera diferente, debe ser consultado.]
17. ¿Cuáles son los problemas más comunes que ha visto la entidad
certificadora en una auditoría de certificación inicial? [Esto
puede ayudar a centrar la atención, durante la implementación,
para tener un proceso robusto donde otros tuvieron problemas.]
18. ¿Cómo ve la forma en la que la entidad certificadora hace su

negocio (misión, visión, valores y prácticas)? [Esto puede ayudar
a la organización a identificar si existe un ajuste cultural entre si
mismo, y un potencial proveedor de servicios de certificación.]
316
APÉNDICE K – INFOGRAFÍA:
EL CEREBRO DE UN AUDITOR
ISO – QUÉ ESPERAR DE UNA
AUDITORÍA DE CERTIFICACIÓN
AUDITOR DE
EL CEREBRO DE UN CERTIFICACIÓN
QUÉ ESPERAR DE UNA
ISO
9001, 14001, 18001, 20000, 22000, o 27001 puede ser útil, en lugar de
AUDITORÍA DE CERTIFICACIÓN estresante
HECHO
El auditor debe evaluar si: (1) usted tiene toda la documentación obligatoria,
(2) si sus actividades y documentación cumplen con el estándar,
y (3) si sus actividades cumplen con su propia documentación
TRUCO
No escriba políticas y procedimientos que no necesite, y que no vaya a cumplir; una vez que publique un
documento, asegúrese de que todo el mundo se lo toma en serio
AUDITOR?
HECHO
HECHO
- personas, y se molestarán si intenta
toría en su compañía sólo contra un estándar impedir realizar su trabajo
(por ejemplo ISO 27001). A pesar de esto,
tenga en cuenta que la mayoría de auditores 317
TRUCO
son expertos en varios estándares
ISO (por ejemplo, ISO 9001, ISO 14001, No evite preguntas (ellos sabrán que está
ISO 22301, ISO 20000, ISO 22000, etc) ocultando algo)
y (3) si sus actividades cumplen con su propia documentación
TRUCO
No escriba políticas y procedimientos que no necesite, y que no vaya a cumplir; una vez que publique un
SEGURO documento,
& SIMPLE asegúrese de que todo el mundo se lo toma en serio
AUDITOR?
HECHO
HECHO
- personas, y se molestarán si intenta
toría en su compañía sólo contra un estándar impedir realizar su trabajo
(por ejemplo ISO 27001). A pesar de esto,
tenga en cuenta que la mayoría de auditores TRUCO
son expertos en varios estándares
ISO (por ejemplo, ISO 9001, ISO 14001, No evite preguntas (ellos sabrán que está
ISO 22301, ISO 20000, ISO 22000, etc) ocultando algo)
TRUCO No mienta (cuando ellos detecten que está
mintiendo, perderán completamente la
Utilice sus conocimientos y su experiencia
de auditor para obtener una imagen más
amplia de cuáles son los estándares que No pierda su tiempo (no los arrastre a un
pueden ser adecuados para usted, es decir, lugar donde no quieren ir, o no pierda mucho
cómo podría mejorar aún más las opera-
ciones de su empresa rápidamente)
BÚSQUEDA
CONOCIMIENTO MOLESTIA
FELICIDAD
AUTORIZACIÓN
PROHIBIDO
EXPECTATIVAS
CERTIFICACIÓN?
HECHO
Durante la auditoría, el auditor de
con cualquier persona que esté dentro del 318

para ver cualquier documento, y andar por HECHO
las instalaciones de la empresa
de auditor para obtener una imagen más
amplia de cuáles son los estándares que No pierda su tiempo (no los arrastre a un
pueden ser adecuados para usted, es decir, lugar donde no quieren ir, o no pierda mucho
cómo podría mejorar aún más las opera-
ciones de su empresa rápidamente) Apéndice
BÚSQUEDA
CONOCIMIENTO MOLESTIA
FELICIDAD
AUTORIZACIÓN
PROHIBIDO
EXPECTATIVAS
CERTIFICACIÓN?
HECHO
Durante la auditoría, el auditor de
con cualquier persona que esté dentro del
para ver cualquier documento, y andar por HECHO

las instalaciones de la empresa
TRUCO permiso para hacerle consultoría – no le
puede explicar en detalle cómo resolver
Asegúrese de que todo el mundo está un problema particular que tenga
documentación está completa TRUCO
Desarrollar una relación positiva:
HACER ● De respuestas claras y oportunas,
UN AUDITOR? apoyadas en hechos
HECHO ● Reconozca que tiene un problema,
y no trate de ocultarlo
una no conformidad si no determina el ● Solicite la opinión del auditor
requisito del estándar, o de su docu- Si hace esto, entonces el auditor no se
mentación, que se incumple, y además no parará simplemente a decirte que tiene
puede demostrar que cumple con el requisito una no conformidad – irá un paso más
allá, y en un par de frases, le guiará sobre
TRUCO
cómo enfocar la no conformidad- esto no
Prepárese para debatir con el auditor si nota que es tampoco consultoría, pero le ahorrará
el auditor no encuentra el requisito escrito, o si
319
mucho tiempo
no encuentra una prueba de incumplimiento
puede demostrar que cumple con el requisito
allá, y en un par de frases, le guiará sobre
TRUCO
cómo enfocar la no conformidad- esto no
Prepárese para debatir con el auditor si nota que es tampoco consultoría, pero le ahorrará
SEGURO el& auditor
SIMPLEno encuentra el requisito escrito, o si mucho tiempo
no encuentra una prueba de incumplimiento
HECHO
las auditorías de seguimiento

TRUCO
Además de dejar una buena impresión, también debe asegurarse de que mantiene su sistema y su
documentación- esto es en lo que más incidirá el auditor cuando vuelva
Advisera
Courtesy of Advisera.com. Copyright ©2015 EPPS Services Ltd.
320
APÉNDICE L – ¿CUÁL ES EL TRABAJO
DEL RESPONSABLE DE SEGURIDAD
(CHIEF INFORMATION SECURITY
OFFICER -CISO) EN ISO 27001?
Dado que ISO 27001 no requiere la posición de un responsable de segu-

ridad, tampoco describe lo que tiene que hacer esta persona - por lo que
usted decide qué es lo más conveniente para su empresa. Generalmente,
esta persona debe coordinar todas las actividades relacionadas con la
información en la empresa, y aquí puede ver algunas ideas sobre lo que
esta persona podría hacer (dividido por las secciones de ISO 27001):
Cumplimiento:
● Elaborar la lista de partes interesadas relacionadas con la seguri-

● Elaborar la lista de requisitos de las partes interesadas
● Permanecer en contacto continuo con grupos y autoridades de
especial interés
● Coordinar todos los esfuerzos relacionados con la protección de
datos personales
Documentación:
● Proponer una versión borrador de los documentos principales de

la seguridad de la información – por ejemplo, la Política de segu-
ridad de la información, la Política de clasificación, la Política de
control de accesos, el Uso aceptable de activos, la metodología de
análisis y tratamiento de riesgos, la Declaración de Aplicabilidad,
el Plan de tratamiento de riesgos, etc.
● Ser responsable de la revisión y actualización de los principales
documentos
321
SEGURO & SIMPLE
Gestión de riesgos:
● Enseñar a los empleados cómo realizar el análisis de riesgos
● Coordinar todo el proceso de análisis de riesgos
● Proponer la selección de salvaguardas
● Proponer plazos para la implementación de las salvaguardas
● Gestión de recursos humanos:
● Realizar una verificación de los antecedentes de los candidatos a

un puesto de trabajo
● Preparar el plan de capacitación y concienciación para la seguridad

de la información
● Realizar actividades continuas relacionadas con la concienciación
● Realizar cursos de iniciación en temas de seguridad para los nue-

vos empleados
● Proponer acciones disciplinarias a los empleados que no cumplan

las reglas de seguridad
Relación con la alta dirección:
● Comunicar los beneficios de la seguridad de la información
● Proponer objetivos de seguridad de la información
● Informar sobre los resultados de la medición
● Proponer mejoras de seguridad y acciones correctivas
322
Apéndice
● Proponer el presupuesto y otros recursos necesarios para la protec-
ción de la información
● Informar sobre los requisitos importantes de las partes interesadas
● Notificar a la alta dirección sobre los principales riesgos
● Informar sobre la implementación de las salvaguardas
● Asesorar a los directivos de la organización sobre todos los asuntos

de seguridad
Mejoras:
● Asegurar que se realizan todas las acciones correctivas
● Verificar si las acciones correctivas han eliminado la causa de las

no conformidades
● Gestión de activos:
● Mantener un inventario de todos los activos de información im-

portantes
● Eliminar los registros que no son necesarios
● Eliminar de forma segura los dispositivos y el equipamiento que no

se va a utilizar más
Terceras partes:
● Realizar el análisis de riesgos para actividades que se externalizan
● Realizar una verificación de antecedentes de los candidatos a so-

cios
● Definir las cláusulas de seguridad que deben formar parte de los

acuerdos
323
SEGURO & SIMPLE
Comunicación:
● Definir qué tipo de canales de comunicación son aceptables, y cuá-
les no
● Preparar el equipamiento de comunicación que se utilizará en caso
de emergencia / desastre
Gestión de incidentes:
● Recibir información sobre los incidentes de seguridad
● Coordinar la respuesta ante incidentes de seguridad
● Preparar evidencias para acciones legales en caso de incidentes
● Analizar los incidentes para evitar que se vuelvan a repetir
Continuidad del negocio:

● Coordinar el proceso de análisis de impacto en el negocio, y la
creación de planes de respuesta
● Coordinar el ejercicio de pruebas
● Realizar el informe de los planes de recuperación
Cuestiones técnicas:
● Aprobar los métodos adecuados para la protección de los dis-
positivos móviles, las redes de computadoras, y otros canales de
comunicación
● Proponer métodos de autenticación, Política de contraseñas, mé-
todos de cifrado, etc.
● Proponer reglas para el teletrabajo seguro
● Definir características de seguridad para los servicios de Internet
● Definir principios para el desarrollo seguro de sistemas de información
● Revisar logs de actividad de los usuarios para identificar compor-
tamientos sospechosos
324
APÉNDICE M – CATÁLOGO DE
AMENAZAS Y VULNERABILIDADES
Esta lista de amenazas y vulnerabilidades puede servir como ayuda para

la implementación del análisis de riesgos en el marco de trabajo de la
ISO 27001. Esta lista no es definitiva - cada organización debe agregar
sus propias amenazas y vulnerabilidades específicas, que pueden afec-
tar a la confidencialidad, la integridad y la disponibilidad de sus activos.
Amenazas
Aquí tiene el listado de amenazas – no es una lista definitiva, debe
adaptarse a cada organización:
● Acceso a la red por personas no autorizadas

● Acceso físico no autorizado
● Acceso no autorizado a un sistema de información
● Amenaza de bomba
● Ataque de bomba
● Ataques terroristas
● Cambios no autorizados en datos de un sistema de información
● Cambios no autorizados en registros
● Código malicioso
● Comprometer información confidencial
● Contaminación
● Daños causados por una tercera parte
● Daños derivados de pruebas de intrusión
325
SEGURO & SIMPLE
● Daños ocasionados por un relámpago
● Desastre (causado por una persona)
● Desastre (natural)
● Destrucción de registros
● Divulgación de contraseñas
● Divulgación de información
● Encubrir la identidad de un usuario
● Errores de mantenimiento
● Errores de software
● Errores de usuario
● Espionaje
● Espionaje industrial
● Falsificación de registros
● Fallo de los enlaces de comunicaciones
● Fraude
● Fuego
● Fuga de información
● Huelga
● Incumplimiento de la legislación
● Incumplimiento de relaciones contractuales
● Ingeniería social
● Instalación de software no autorizado
326
Apéndice
● Interrupción de los procesos de negocio
● Inundación
● Mal funcionamiento de equipamiento
● Mal uso de las herramientas de auditoría
● Mal uso de los sistemas de información
● Malversación
● Pérdida de electricidad
● Pérdida de los servicios de soporte
● Robo
● Uso no autorizado de material con copyright
● Uso no autorizado de software
● Vandalismo
Vulnerabilidades
Aquí tiene el listado de vulnerabilidades – no es una lista definitiva,
debe adaptarse a cada organización:
● Ausencia de control sobre los datos de entrada y salida
● Ausencia de documentación interna
● Ausencia de política de control de accesos
● Ausencia de política de escritorio despejado y pantalla limpia
● Ausencia de política para el uso de la criptografía
● Ausencia de procedimiento para la eliminación de derechos cuan-
do el empleado abandona la compañía
327
SEGURO & SIMPLE
● Ausencia de protección para el equipamiento móvil
● Ausencia de redundancia
● Ausencia de sistemas para la identificación y la autenticación
● Ausencia de validación de datos procesados
● Ausencia o realización de una auditoría interna pobre
● Conexiones de redes públicas no protegidas
● Copia simple
● Demasiado poder en una persona
● Descontrol de las descargas de Internet
● Descontrol del uso de los sistemas de información
● Descontrol en las copias de datos
● Destrucción de dispositivos de almacenamiento sin borrar datos
● Empleados no motivados
● Equipamiento sensible a cambios de voltaje
● Equipamiento sensible a la humedad y contaminantes
● Equipamiento sensible a la temperatura
● Especificación incompleta para el desarrollo de software
● Inadecuada capacitación de los empleados
● Inadecuada clasificación de la información
● Inadecuada concienciación de seguridad
● Inadecuada gestión de cambios
● Inadecuada gestión de contraseñas
328
Apéndice
● Inadecuada gestión de la capacidad
● Inadecuada gestión de la red
● Inadecuada o irregulares copias de seguridad
● Inadecuada protección de claves criptográficas
● Inadecuada protección física
● Inadecuada segregación de instalaciones de producción y pruebas
● Inadecuada segregación de responsabilidades
● Inadecuada seguridad del cableado
● Inadecuada supervisión de empleados
● Inadecuada supervisión de proveedores
● Inadecuada sustitución de equipamiento obsoleto
● Inadecuado control del acceso físico
● Insuficientes pruebas de software
● Interfaz de usuario complicada
● La contraseña por defecto no se ha modificado
● Los derechos de usuario no son revisados regularmente
● Mala selección de los datos de prueba
● Mantenimiento inadecuado
● Software sin documentar
● Ubicación vulnerable a inundaciones
329
GLOSARIO
Acciones correctivas – actividades que se tienen que realizar con el fin

de eliminar la causa de una no conformidad.
Activo – todo lo que es valioso para la empresa. Podría ser por ejemplo,
hardware, software, datos, pero también personas, infraestructura, etc.
Análisis de riesgos – el proceso de determinar qué incidentes podrían

ocurrir (es decir, que riesgos existen), y la gravedad.
Amenaza – causa potencial de un incidente – podría ser natural o ar-

tificial; podría ser deliberada o accidental; etc.
Continuidad del Negocio no es más que la capacidad de una organiza-

ción para reaccionar a perturbaciones, y a continuar sus operaciones o ac-
tividades clave. Este término está estrechamente vinculado a la resiliencia.
Control or salvaguarda – métodos que se utilizan para disminuir el

nivel de riesgo – por ejemplo, un firewall, o un procedimiento de copias
de seguridad.
Disponibilidad – una característica de la información o de un proceso,

que hace que sea accesible a aquellos que lo necesitan, en el momento
que lo necesiten.
Evento disruptivo es cualquier tipo de incidente que pueda detener las

operaciones de una organización. Esto puede ser causado por un desas-
tre natural, aunque también puede ser artificial, o un fallo técnico, etc.
Incidente es un evento que tiene consecuencias negativas para la con-

fidencialidad, la integridad o la disponibilidad de la información. Un in-
cidente podría verse también como un riesgo que se ha materializado.
Impacto – el daño que afectará a los activos, a las actividades o toda la

organización, cuando se produzca un incidente.
330
Glosario
No conformidad – incumplimiento de ciertos requisitos; los requisitos

podrían estar definidos en leyes y reglamentos, en contratos, en ISO
27001 o en políticas, procedimientos, planes u otros documentos escri-
tos por la organización.
Plan de continuidad del negocio es un documento (o, más a me-

nudo, un conjunto de documentos) que describe cómo responder a
un incidente, y cómo continuar con las actividades principales de la
organización dentro de los Tiempos Objetivos de Recuperación (RTO
– Recovery Time Objective). También puede considerar los Planes de
Continuidad de Negocio como listas de verificación sobre lo que tiene
que hacer si sus actividades se interrumpen – Lea más sobre esto en la
sección 6.9: Plan de continuidad de negocio (cláusula 8.4)
Plan de recuperación ante desastres es la parte del plan de conti-

nuidad de negocio que se centra en la recuperación de la información,
y los sistemas de comunicación y datos. Muy a menudo es la parte más
detallada del plan de continuidad de negocio .
Probabilidad – la probabilidad de que se produzca un incidente.
Seguridad de la información – capacidad que tiene una organiza-

ción para proteger la confidencialidad, la integridad y la disponibilidad
de su información.
Tratamiento de riesgos (Mitigación del riesgo) – un proceso para

determinar qué hacer con los riesgos que son demasiado altos, y por lo
tanto, que no son aceptables.
Ubicación alternativa (o: ubicación secundaria) – una ubicación en

la que las operaciones se trasladan y se recuperan en el caso de que la
primera ubicación no esté disponible por un incidente. A una ubicación
alternativa para los sistemas centrales de TI, y de comunicaciones, tam-
bién se le denomina sitio de recuperación ante desastres.
Vulnerabilidad – característica de un activo, o de un proceso, que per-

mite que se materialice la amenaza. Por ejemplo, la falta de un sistema
de extinción de incendios puede permitir que se produzca un fuego.
331
BIBLIOGRAFÍA
ISO 9001:2015, Quality management systems – Requirements
ISO 14001:2015, Environmental management systems – Requirements

with guidance for use
ISO/IEC 20000-1:2011, Information technology – Service management

– Part 1: Service management system requirements
ISO 22301: 2012, Societal security – Business continuity management

systems – Requirements
ISO/IEC 27000:2016, Information technology – Security techniques –

Information security management systems – Overview and vocabulary

Information security management systems – Requirements

Information security management systems – Requirements

Code of practice for information security controls

Information security management – Measurement

Information security risk management

Code of practice for information security controls based on ISO/IEC
27002 for cloud services

Code of practice for protection of personally identifiable information
332
Bibliografía
(PII) in public clouds acting as PII processors

Guidelines for cybersecurity
ISO 31000:2009, Risk management – Principles and guidelines
ISO/DIS 45001, Occupational health and safety management systems –

Requirements with guidance for use
COBIT 5, ISACA, 2012
ITIL 2011, Axelos, 2011
PCI DSS version 3.2, Payment Card Industry Security Standards Council,
2016
SP800 series, NIST
Kosutic, Dejan, 9 Steps to Cybersecurity, Zagreb: EPPS Services Ltd,

2012
Kosutic, Dejan, Becoming Resilient, Zagreb: EPPS Services Ltd, 2013
http://advisera.com/27001academy/blog/ ISO 27001 & ISO 22301 Blog,

Advisera.com
http://training.advisera.com/course/iso-27001-foundations-course/ ISO
27001 Foundations Course, Advisera.com
333
ÍNDICE
acciones correctivas 11, 40, 69, 177, alta dirección 9, 10, 12, 20, 23, 29, 39,
184, 187, 188, 189, 190, 191, 192, 44, 46, 47, 50, 52, 53, 61, 79, 82,
198, 203, 209, 212, 266, 271, 272, 83, 84, 85, 86, 88, 89, 90, 95, 96,
292, 299, 301, 302, 307, 315, 322, 98, 101, 107, 124, 129, 137, 138,
323 164, 179, 182, 186, 187, 189, 224,
acreditación 12, 194, 195, 196, 197, 245, 247, 251, 276, 295, 305, 322,
200, 314 323
actividades 32, 51, 53, 67, 68, 81, 83, amenaza 49, 111, 112, 152, 331
84, 94, 97, 98, 99, 100, 131, 133, amenazas y vulnerabilidades 14, 104,
135, 136, 138, 139, 151, 162, 171, 106, 110, 111, 142, 225, 232, 298,
177, 182, 189, 191, 199, 204, 212, 306, 325
249, 250, 266, 271, 275, 286, 295, ANAB 314
305, 309, 310, 321, 322, 323, 330, análisis de impacto en el negocio 324
331 análisis de riesgos 10, 13, 104, 105, 109,
activos 11, 28, 41, 46, 104, 106, 110, 112, 115, 117, 118, 120, 124, 125,
111, 113, 115, 129, 142, 146, 153, 130, 134, 141, 142, 143, 147, 151,
154, 156, 159, 162, 168, 204, 225, 154, 157, 188, 223, 235, 251, 252,
226, 227, 229, 232, 265, 268, 298, 253, 258, 262, 268, 269, 275, 287,
306, 321, 323, 325, 330 289, 290, 298, 301, 306, 309, 312,
administrador de sistemas 28, 118, 127, 322, 323, 325
138, 151, 156 Anexo A 11, 38, 40, 116, 119, 143, 144,
administrador de TI 21, 54, 93, 251 145, 147, 148, 149, 150, 157, 163,
administradores de sistemas 51, 161, 171, 176, 230, 235, 266, 298, 306
162 Anexo SL 38, 233
agencias gubernamentales 8, 93, 238, auditor de certificación 12, 78, 104,
276 119, 120, 189, 194, 199, 202, 203,
agencias gubernamentales estadoun- 208, 212, 213, 216, 218, 250, 254,
idenses 238 259, 312
alcance 10, 12, 14, 32, 33, 39, 57, 78, auditoría de certificación 13, 70, 125,
79, 80, 81, 85, 90, 182, 205, 240, 194, 195, 202, 203, 205, 208, 214,
241, 256, 260, 284, 285, 298, 301, 259, 302, 316, 317
305, 306, 313 auditoría de recertificación 203
alcance del SGSI 10, 14, 33, 39, 78, 79, Auditoría Fase 1 201
80, 85, 90, 205, 241 Auditoría Fase 2 201
334
Índice
auditoría integrada 200, 201 219, 220, 227, 230, 231, 240, 246,
auditoría interna 14, 40, 177, 180, 181, 247, 248, 249, 251, 253, 254, 256,
182, 183, 184, 185, 186, 189, 190, 277, 278, 311, 312, 314, 315, 316
191, 192, 198, 199, 209, 212, 234, COBIT 69, 237, 333
266, 271, 272, 292, 299, 301, 302, competencias 39, 88, 95, 101
306 compromiso 34, 50, 53, 55, 56, 82, 84,
auditoría interna integrada 181 94, 143, 245, 246, 263, 286, 300
auditoría principal 183, 184, 185 comunicación 23, 39, 57, 62, 77, 85, 98,
auditor interno 180, 181, 182, 184, 185, 99, 100, 123, 157, 164, 222, 286,
192, 199, 214, 263, 271 288, 311, 324, 331
Auditor Jefe 12, 57, 63, 197, 214, 215, concienciación 51, 67, 97, 98, 99, 196,
216, 217, 312 197, 204, 243, 248, 249, 288, 302,
banco 17, 19, 77, 107, 200, 246, 247, 322
254 consecuencias 97, 105, 106, 107, 113,
bancos 17, 57, 180, 193, 246, 247 114, 137, 171, 190, 225, 330
beneficios 18, 20, 33, 37, 44, 45, 46, 47, consultor 21, 47, 55, 56, 57, 58, 63, 67,
48, 49, 50, 51, 53, 83, 88, 98, 136, 69, 109, 181, 199, 213, 217, 218,
157, 244, 252, 253, 258, 263, 300, 220, 247, 248, 250, 261, 262, 309,
322 311, 312, 313, 341
British Standards Institution 26 consultoría 16, 21, 57, 58, 70, 168, 206,
BS 7799 26, 37, 222 219, 220, 278, 297, 311, 312, 316
BS 25999-2 305 controles 20, 28, 30, 32, 35, 38, 39, 40,
BSI 26, 37, 196 41, 42, 59, 64, 66, 67, 69, 86, 95,
Bureau Veritas 196 104, 105, 113, 115, 116, 119, 120,
cálculo del riesgo 107, 108 121, 122, 123, 124, 125, 127, 128,
capacitación 31, 94, 96, 152, 196, 214, 129, 130, 131, 133, 136, 139, 140,
243, 244, 247, 251, 254, 255, 302, 142, 143, 144, 145, 146, 147, 148,
322 149, 150, 151, 152, 153, 154, 156,
capacitación y concienciación 302, 322 157, 158, 159, 161, 162, 163, 164,
catálogos 110, 116 166, 167, 168, 169, 170, 171, 172,
certificado 27, 33, 36, 45, 79, 193, 194, 173, 174, 175, 176, 177, 178, 188,
195, 197, 200, 202, 203, 210, 211, 191, 198, 203, 204, 212, 221, 222,
212, 217, 227, 251, 256, 257, 261, 223, 224, 226, 227, 228, 229, 230,
262, 263, 276, 277 231, 232, 235, 237, 238, 242, 249,
China 35 266, 268, 269, 270, 272, 296, 298,
ciclo PDCA 39, 40, 59, 60, 64, 177, 224 299, 301, 302, 306, 307, 309
ciclo Plan-Do-Check-Act (PDCA) 60 controles técnicos 42, 66, 122, 123, 124,
clientes 27, 28, 30, 36, 45, 57, 58, 70, 127, 136, 159, 177
77, 87, 92, 107, 133, 179, 185, copias de seguridad 29, 84, 93, 111,
194, 204, 209, 210, 213, 217, 218, 112, 114, 116, 123, 127, 129, 131,
335
SEGURO & SIMPLE
146, 150, 162, 173, 183, 207, 208, entidad certificadora 67, 194, 195, 196,
210, 229, 330 200, 201, 202, 208, 211, 212, 214,
coste 45, 66, 67, 94, 116, 117, 201, 276, 216, 241, 251, 277, 302, 314, 315,
297, 313 316
costes 36, 44, 64, 66, 67, 188, 189, 276, entrevistas 55, 96, 109, 110, 202, 204,
295, 297, 313 205, 240, 313
cuestiones internas y externas 39, 74, equipo de proyecto 61, 62, 79, 88, 92,
79, 90 96, 98, 107, 117, 138, 243, 244,
cumplimiento 18, 27, 33, 36, 45, 47, 77, 245, 246, 295, 296, 300, 305, 309
103, 129, 151, 174, 175, 176, 187, escala 58, 104, 106, 107, 113
205, 238, 252, 269, 284 estrategia 46, 70, 74, 75, 88, 107, 116,
cuota de mercado 44 246
curso 63, 116, 186, 197, 214, 215, 216, estrategia de negocio 46, 74, 107
307, 312 Europa occidental 35
Curso de Auditor Jefe 57, 215 Excel 105, 111, 118, 171
Curso de Implementador Jefe 215 gestión del proyecto 62, 68, 305
cursos 8, 16, 22, 24, 57, 63, 67, 96, 98, gestión de riesgos 30, 34, 35, 36, 74, 85,
196, 197, 214, 215, 219, 243, 312, 103, 104, 107, 108, 118, 122, 125,
316, 322 144, 222, 223, 224, 225, 232, 235,
Cybersecurity Framework 237, 238 242, 277, 287, 298, 301, 306
Declaración de Aplicabilidad 38, 59, herramienta de análisis de riesgos 112,
119, 120, 121, 122, 125, 129, 149, 115
203, 265, 268, 301, 306, 321 implementación 3, 5, 16, 20, 21, 22, 23,
departamento de recursos humanos 96, 24, 25, 28, 31, 32, 33, 38, 39, 40, 45,
210, 270 52, 53, 54, 55, 56, 59, 60, 62, 63, 64,
departamento de TI 32, 62, 79, 245 65, 66, 70, 72, 75, 82, 83, 89, 96,
Departamento de ventas 50 102, 104, 115, 118, 119, 121, 122,
derechos de propiedad intelectual 175 123, 124, 125, 127, 135, 137, 144,
director de cumplimiento 47 157, 159, 163, 172, 176, 192, 198,
director financiero 47, 66 204, 205, 212, 214, 215, 218, 221,
director general 28, 245, 246, 250, 251, 222, 228, 235, 236, 242, 245, 246,
253, 254, 255 248, 250, 251, 255, 258, 260, 261,
disminución de costes 44 263, 264, 266, 267, 268, 269, 272,
dispositivo 29, 127, 266 273, 276, 277, 283, 286, 293, 295,
DNV 196 296, 298, 299, 300, 301, 303, 305,
documentos externos 92 306, 307, 308, 309, 310, 311, 312,
documentos internos 92 313, 316, 322, 323, 325, 341
ejecutivos 36, 68, 82, 83, 84, 186, 188, India 35, 242
192, 239 información documentada 71, 91, 131,
Enterprise Risk Management 225 140, 175
336
Índice
Informe de auditoría interna 182 315, 332
infraestructura de TI 115, 139, 161, 173, ISO 17011 196
270 ISO 17021 196
instituciones financieras 8, 36, 45, 193, ISO 17024 197
256 ISO 20000 42, 233, 238, 283, 284, 285,
Inversión 25, 48 286, 287, 288, 289, 290, 291, 292,
IRCA 197 311
ISO 3, 4, 5, 6, 8, 16, 17, 18, 19, 20, 21, ISO 22301 4, 8, 38, 91, 172, 174, 176,
22, 23, 24, 25, 26, 27, 28, 29, 30, 186, 195, 200, 233, 235, 236, 237,
31, 32, 33, 35, 36, 37, 38, 39, 40, 270, 272, 295, 297, 305, 332, 333
41, 42, 44, 45, 46, 47, 50, 51, 52, ISO 27000 19, 39, 284
53, 54, 57, 58, 59, 60, 62, 63, 64, ISO 27002 144, 145, 176, 222, 223, 224,
65, 66, 68, 69, 70, 71, 73, 74, 75, 226, 227, 228, 229
79, 80, 82, 83, 84, 87, 89, 91, 92, ISO 27004 74
94, 95, 98, 102, 103, 104, 105, ISO 27005 105, 221, 222, 224, 225, 232
106, 116, 119, 120, 124, 127, 130, ISO 27006 216
131, 134, 136, 137, 139, 144, 145, ISO 27017 222, 226, 227, 228
148, 149, 152, 155, 156, 158, 160, ISO 27018 227, 228, 229, 230, 231
162, 163, 164, 165, 167, 169, 171, ISO 31000 74, 224, 225, 333
172, 174, 175, 176, 177, 178, 179, ISO 45001 233
181, 182, 183, 184, 185, 186, 188, ITIL 171, 237, 238, 333
189, 190, 191, 193, 194, 195, 196, jefe de departamento 21, 66
197, 198, 199, 200, 202, 203, 204, jefes de departamento 187, 244
205, 206, 210, 211, 213, 214, 215, jefes de departamentos 107
216, 217, 218, 219, 220, 221, 222, legislación 18, 36, 119, 134, 174, 175,
223, 224, 225, 226, 227, 228, 229, 182, 204, 228, 275
230, 231, 232, 233, 234, 235, 236, leyes y regulaciones 36, 147, 185, 238
237, 238, 239, 240, 241, 242, 243, línea de responsables 50, 53
244, 245, 246, 248, 250, 251, 252, manufacturación 136, 248
254, 255, 256, 257, 258, 259, 260, marco de gestión 20
261, 262, 263, 264, 265, 266, 267, medición 38, 40, 69, 86, 87, 88, 103,
268, 269, 270, 272, 273, 275, 276, 142, 177, 178, 179, 180, 198, 222,
277, 278, 279, 283, 284, 285, 286, 254, 266, 270, 271, 291, 322
287, 288, 289, 290, 291, 292, 293, mejora 40, 94, 103, 177, 188, 191, 192,
295, 298, 299, 300, 303, 305, 306, 283, 286, 292, 315
311, 312, 313, 314, 315, 316, 321, mejora continua 40, 94, 103, 177, 188,
325, 331, 332, 333, 341 191, 192, 286, 292
ISO 9001 27, 38, 40, 42, 80, 91, 119, metodología de análisis de riesgos 105, 301
181, 186, 189, 195, 200, 233, 234, Metodología de análisis de riesgos 104,
235, 248, 256, 262, 263, 272, 311, 142
337
SEGURO & SIMPLE
midiendo 20, 83 Peter Drucker 86
minutas de reunión 187, 204 Plan de proyecto 61, 124, 295, 296, 303,
mitos 26, 29, 31, 97, 105 305, 308
monitorizando 163 Plan de recuperación ante desastres
NIST SP800 237 331
no conformidad 184, 190, 206, 207, plan de tratamiento de riesgos 95, 122,
208, 209, 210, 211, 254, 330 124, 127, 188
no conformidades 40, 180, 182, 183, planes de continuidad de negocio 270,
184, 188, 189, 190, 202, 206, 208, 309
209, 210, 250, 251, 323 planes de recuperación 270, 324
no conformidad mayor 210, 211, 254 plantillas de documentos 8, 25, 67, 261,
nube 25, 33, 35, 46, 70, 78, 81, 141, 300
142, 169, 186, 222, 226, 227, 228, Política de clasificación 149, 267, 321
230, 240, 241, 257, 258, 277 Política de control de accesos 100, 146,
objetivos 20, 38, 39, 60, 73, 74, 75, 82, 204, 265, 269, 321
83, 84, 85, 86, 87, 88, 90, 94, 99, Política de Control de Accesos 148
100, 102, 103, 119, 128, 129, 142, Política de seguridad de la información
144, 151, 178, 179, 186, 187, 188, 81, 86, 88, 90, 97, 99, 149, 168,
189, 192, 222, 223, 251, 253, 254, 179, 180, 265, 267, 286, 287, 292,
255, 260, 265, 267, 286, 288, 295, 321
298, 301, 302, 306, 322 presupuesto 56, 57, 65, 66, 72, 94, 104,
objetivos de seguridad de la información 116, 117, 122, 123, 124, 186, 245,
39, 74, 75, 83, 84, 85, 87, 88, 90, 246, 247, 323
94, 129, 187, 301, 322 prevención 49, 158, 276
objetivos estratégicos 20, 87, 128, 129, probabilidad 46, 104, 105, 106, 107,
178, 179, 186 109, 113, 114, 115, 118, 142, 225,
Organización Internacional de Normal- 331
ización 26, 38, 194, 195 Procedimiento de acciones correctivas
Organización Internacional de Normal- 184, 191
ización (ISO) 26 Procedimiento de Control Documental
partes interesadas 30, 38, 39, 41, 74, 93
75, 76, 77, 78, 84, 85, 90, 100, Procedimiento para la identificación de
102, 129, 150, 185, 187, 246, 247, requisitos 77
284, 288, 300, 321, 323 profesional de seguridad de la infor-
PAS 99 234 mación 21, 44, 341
patrocinador 61, 63, 64, 66, 79, 88, 117, Programa de auditoría interna 182, 266,
300, 308, 309 271
PCI DSS 237, 256, 333 protección de datos personales 45, 147,
PECB 197 151, 175, 228, 321
338
Índice
proveedores y socios 45, 199 RIS 48, 49, 53
RABQSA 197 roles y responsabilidades 39, 46, 52, 88,
recursos 20, 24, 28, 29, 32, 39, 42, 54, 89, 90, 151, 223, 265, 268, 276,
55, 65, 74, 77, 82, 94, 95, 96, 98, 286, 305
99, 101, 111, 117, 122, 123, 138, salvaguarda 116, 330
139, 140, 145, 146, 147, 152, 153, salvaguardas 20, 30, 31, 32, 35, 40, 42,
154, 158, 160, 161, 172, 188, 210, 48, 115, 117, 125, 126, 252, 275,
226, 229, 234, 237, 243, 253, 254, 278, 322, 323
255, 258, 263, 270, 286, 288, 297, satisfacción del cliente 44
299, 300, 307, 308, 309, 322, 323 seguir los cambios 92
recursos financieros 20, 94, 123, 297 Seguridad de la información 28, 150,
registro 87, 96, 142, 146, 161, 163, 171, 331
188, 192, 194, 195, 203, 209, 229, serie ISO27k 221
255, 271, 272, 310 SGC 91, 248
registros 32, 33, 39, 75, 76, 91, 92, 93, SGS 196, 284, 285, 286, 287, 289, 290,
96, 131, 136, 142, 162, 174, 175, 292
184, 185, 189, 202, 203, 204, 205, SGSI 20, 21, 22, 33, 39, 41, 42, 54, 71,
208, 209, 210, 229, 250, 254, 263, 73, 74, 76, 78, 79, 80, 81, 82, 83,
265, 266, 267, 270, 271, 272, 277, 84, 85, 86, 87, 88, 89, 90, 91, 93,
288, 298, 301, 302, 306, 310, 315, 94, 95, 96, 97, 98, 101, 102, 103,
323 119, 127, 128, 129, 131, 132, 136,
Reino Unido 26, 35, 196, 248, 314 137, 151, 171, 174, 175, 176, 177,
requisitos contractuales 86, 119, 174, 178, 183, 184, 185, 186, 188, 189,
175 190, 191, 192, 202, 203, 204, 205,
requisitos legales y regulatorios 275 217, 222, 232, 234, 240, 241, 242,
responsabilidades de la alta dirección 248, 250, 251, 254, 265, 267, 268,
39, 82 269, 284, 286, 287, 292, 298, 299,
responsable de proyecto 51, 56, 61, 62, 301, 302, 305, 306, 307, 315, 316
63, 66, 72, 242, 250, 308, 309 sistema de extinción de incendios 48,
Retorno de la Inversión en Seguridad 48 111, 331
revisión 2005 102 sistema de gestión de continuidad de
revisión 2013 224, 279 negocio 172, 173
revisión por dirección 40, 83, 123, 141, Sistema de Gestión de Seguridad de la
177, 179, 186, 187, 188, 192, 198, Información 41, 43, 86, 183, 195,
212, 234, 251, 292, 302 298, 303, 305, 306
Revisión por dirección 83, 186, 234, 296 sistema de gestión documental 92, 93
riesgo operacional 35, 277 sistema de gestión integrado 234
riesgo residual 117, 118, 232 sitio de recuperación ante desastres 29,
riesgos no aceptables 116, 125, 251 31, 331
339
SEGURO & SIMPLE
sitios de recuperación ante desastres 147, 188, 198, 221, 222, 225, 265,
116 267, 268, 269, 283, 296, 298, 299,
talleres 109, 113, 215 301, 306, 307, 321, 341
teléfono 67, 100, 171, 219, 263 ubicación alternativa 331
tratamiento de riesgos 30, 32, 38, 39, UKAS 196, 314
95, 104, 108, 114, 115, 116, 118, visitas de seguimiento 202, 211, 316
119, 122, 123, 124, 125, 127, 141, vulnerabilidad 111, 161
340
SEGURO & SIMPLE: UNA GUÍA PARA
LA PEQUEÑA EMPRESA PARA LA
CON MEDIOS PROPIOS
El manual, con un idioma plano, paso a paso, para los profesionales de

seguridad de la información
Piense y actúe como un consultor con esta guía comprensiva, y prácti-

ca, para la implementación de la ISO 27001.
El autor Dejan Kosutic, consultor experimentado en seguridad de la in-

formación, comparte con usted todo su conocimiento, y su experiencia
práctica en este libro invaluable.
 Consiga una explicación simple sobre el estándar ISO 27001
 Aprenda cómo empezar el proyecto de implementación
 Aprenda cómo escribir la política de seguridad de la información,

y otras políticas y procedimientos
 Realice el análisis y tratamiento de riesgos
 Aprenda cómo estructurar la documentación obligatoria
 Aprenda el proceso de certificación, y el criterio de las entidades

certificadoras
 Todo esto y mucho más…
Escrito en español y evitando la jerga técnica de los frikis, Seguro & Sim-
ple, está escrito para personas normales, con un lenguaje llano, simple.
Si usted es un profesional de seguridad de la información, o es nuevo
en este campo, este el único libro que necesitará.
341
342

Seguro & Simple - Una Guia para La Pequeña Empresa para La Implementación de La Iso 27001 Con Medios Propios

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Seguro & Simple - Una Guia para La Pequeña Empresa para La Implementación de La Iso 27001 Con Medios Propios

Cargado por

Copyright:

Formatos disponibles

1

Ciberseguridad en 9 pasos El manual sobre seguridad

Becoming Resilient: The Definitive Guide to ISO 22301

Seguro & Simple:

El manual, con un idioma plano, paso a paso, para

Advisera Expert Solutions Ltd

Límite de responsabilidad / exención de garantía: Aunque que el edi-

Publicado por primera vez por Advisera Expert Solutions Ltd

Primera edición, 2016

Título original: “Secure & Simple: A Small-Business Guide to Implemen-

Traducido del Inglés por Antonio José Segovia

Dejan Kosutic es autor de numerosos artículos, video tutoriales, plan-

Click aquí para ver su perfil de LinkedIn profile.

2 ¿QUÉ ES EXACTAMENTE LA ISO 27001?...................................................26

4 PREPARACIÓN PARA LA IMPLEMENTACIÓN.............................................54

8 IMPLEMENTANDO CONTROLES DE SEGURIDAD;

9 RESUMEN DE LOS CONTROLES DEL ANEXO A......................................144

10 ASEGÚRESE DE QUE EL SGSI FUNCIONA SEGÚN LO ESPERADO...... 177

12 CAPÍTULO EXTRA I: OPORTUNIDADES DE CARRERA EN ISO 27001....213

13 CAPÍTULO EXTRA II: ESTÁNDARES RELACIONADOS,

14 CAPÍTULO EXTRA III: MINI CASOS DE ESTUDIO DE ISO 27001........... 240

APÉNDICE A – LISTA DE VERIFICACIÓN DE LA DOCUMENTACIÓN

APÉNDICE B – DIAGRAMA DE IMPLEMENTACIÓN

APÉNDICE C – APLICABILIDAD DE LA ISO 27001 DIVIDIDO

APÉNDICE D – INFOGRAFÍA: ISO 27001 (REVISIÓN 2013) –

APÉNDICE E – MATRIZ ISO 27001 VS ISO 20000........................................282

APÉNDICE F – PLANTILLA PROPUESTA PROYECTO PARA LA

APÉNDICE G – LISTA DE VERIFICACIÓN PARA LA IMPLEMENTACIÓN

APÉNDICE H – PLAN DE PROYECTO PARA LA IMPLEMENTACIÓN

APÉNDICE I – LISTA DE PREGUNTAS PARA HACERLE A SU

APÉNDICE J – LISTA DE PREGUNTAS PARA HACERLE A UNA

APÉNDICE K – INFOGRAFÍA: EL CEREBRO DE UN AUDITOR ISO – QUÉ

APPENDIX M – CATÁLOGO DE AMENAZAS Y VULNERABILIDADES....... 325

FIGURA 2: RELACIÓN ENTRE SEGURIDAD DE LA INFORMACIÓN,

FIGURA 3: PALABRAS A EVITAR Y PALABRAS A USAR CUANDO

FIGURA 4: GRÁFICO DE LOS PROCESOS DEL SGSI INDICADOS

FIGURA 5: CINCO PASOS EN EL PROCESO DE GESTIÓN DEL RIESGO............ 103

FIGURA 6: EJEMPLO DE TABLA DE EVALUACIÓN DE RIESGOS

FIGURA 7: EJEMPLO DE TABLA DE EVALUACIÓN DE RIESGOS...................... 114

FIGURA 8: EJEMPLO DE TABLA DE TRATAMIENTO DE RIESGOS.................... 118

FIGURA 9: EJEMPLO DE DECLARACIÓN DE APLICABILIDAD ........................ 121

FIGURA 10: EJEMPLO DE PLAN DE TRATAMIENTO DE RIESGOS.................... 124

FIGURA 11: EJEMPLO DE LISTA DE VERIFICACIÓN PARA

Agradecimiento especial a Ana Meskovska, quien me ayudó a escribir

Agradezco también a Rhand Leal y Buddhika De Alwis, por revisar el

Un agradecimiento final a mi equipo de Marketing - Ziółkowski y Vinko

Veo miles de visitantes leyendo diariamente mis artículos en el blog ISO

¿Por qué su organización necesitaría tener su información a salvo?

1.1 ¿Por qué la seguridad de la información? ¿Por qué ISO 27001?

Si usted fuera un ejecutivo de una organización de hace diez años, pro-

La mayoría de nosotros imagina que un banco maneja grandes cantida-

El problema es que en la actualidad hay una abundante información so-

Aquí es donde ISO 27001 entra – como se explica a lo largo de este

Por lo tanto, lo principal es – ISO 27001 no tiene que ser un trabajo de

1.2 Principios básicos de seguridad de la información

Por otra parte, la seguridad de la información se puede definir como la

Veamos las definiciones oficiales de estos términos en ISO 27000: con-

Dentro de unos meses cuando vuelva a retirar mi depósito, quiero la

Por último, si quiero retirar mi dinero no quiero que el empleado del

ISO 27001 tiene exactamente el mismo enfoque – la protección de la

1.3 ISO 27001 lo une todo

ISO 27001 explica cómo estructurar la documentación de la seguridad

Como explicaré más adelante en mayor detalle, ofrece un camino de

8 IMPLEMENTANDO CONTROLES DE SEGURIDAD;

13 CAPÍTULO EXTRA II: ESTÁNDARES RELACIONADOS,

APÉNDICE A – LISTA DE VERIFICACIÓN DE LA DOCUMENTACIÓN

APÉNDICE B – DIAGRAMA DE IMPLEMENTACIÓN

APÉNDICE C – APLICABILIDAD DE LA ISO 27001 DIVIDIDO

APÉNDICE D – INFOGRAFÍA: ISO 27001 (REVISIÓN 2013) –

APÉNDICE F – PLANTILLA PROPUESTA PROYECTO PARA LA

APÉNDICE G – LISTA DE VERIFICACIÓN PARA LA IMPLEMENTACIÓN

APÉNDICE H – PLAN DE PROYECTO PARA LA IMPLEMENTACIÓN

APÉNDICE I – LISTA DE PREGUNTAS PARA HACERLE A SU

APÉNDICE J – LISTA DE PREGUNTAS PARA HACERLE A UNA

APÉNDICE K – INFOGRAFÍA: EL CEREBRO DE UN AUDITOR ISO – QUÉ

FIGURA 2: RELACIÓN ENTRE SEGURIDAD DE LA INFORMACIÓN,

FIGURA 3: PALABRAS A EVITAR Y PALABRAS A USAR CUANDO

FIGURA 4: GRÁFICO DE LOS PROCESOS DEL SGSI INDICADOS

FIGURA 5: CINCO PASOS EN EL PROCESO DE GESTIÓN DEL RIESGO............ 103

FIGURA 6: EJEMPLO DE TABLA DE EVALUACIÓN DE RIESGOS

FIGURA 11: EJEMPLO DE LISTA DE VERIFICACIÓN PARA

● Cuando ciertas secciones de este libro estén relacionadas con una

● Dado que los capítulos del 5 al 8 y 10 describen la implementación

○ Propósito – describe brevemente por qué existe la cláusula y

○ Decisiones – qué decisiones necesita tomar para avanzar

○ Documentación – describe cómo documentar los requisitos

○ Truco de documentación – resume brevemente los docu-

● Algunas secciones contienen consejos de herramientas libres, que

● Al final del libro, en el capítulo 14 verá un par de pequeños casos

● Encontrará mucha información útil en los apéndices - glosario,

1) ISO 27001 online courses – cursos online gratuitos que le enseña-

2) ISO 27001 Descargas gratuitas – colección de documentos, listas

4) Conformio – sistema de gestión de documentos basado en la

5) ISO 27001 Paquete de documentos – Conjunto de todas las plan-