1. Gestión Estratégica
GUÍA DE IMPLEMENTACIÓN
ISO 27001

2. Agenda
1. Aproximación inicial
2. Soporte Administrativo
3. Alcance
4. Planeación
5. Comunicación
6. Evaluación de Riesgos
7. Selección de Controles
8. Documentación
9. Pruebas
10. Certificación Exitosa

3. Aproximación Inicial
La preparación de una implementación exitosa implica cuatro factores:
1. Conocimiento – y ser capaz de comunicarlo claramente – porque la
seguridad de la información es importante para cualquier organización y,
particularmente la suya,
2. Saber específicamente porque ISO 27001 es la forma correcta de
proporcionar seguridad a la información – y que esto también significa
tener un conocimiento base del estándar y como funciona,
3. Saber como se va a estructurar el proyecto, cuales son los elementos
clave (los que siguen), y porque es la mejor forma de trabajarla,
4. Saber si se van a contratar consultores o lo va a hacer usted mismo, y los
pros y contras de ambas.

4. Que es la gestión de la seguridad?
• El sistema de gestión de la seguridad de la
información (SGSI) es la parte del sistema de
gestión global basada en un enfoque de riesgos del
negocio, para:
– Implementar, operar, monitorear, mantener y mejorar la
seguridad de la información.

5. Modelo PHVA
• Definir la política de • Adoptar acciones correctivas
seguridad • Adoptar acciones
• Establecer el alcance del preventivas
SGSI • Adoptar acciones de mejora
• Realizar análisis de riesgos
• Seleccionar los controles
Planear Hacer
Actuar Verificar
• Implantar el SGSI • Revisar la eficacia de los
• Implantar los controles controles
• Implantar indicadores • Realizar auditorías internas
del SGSI
• Revisiones del sistema por
parte de la dirección

6. Alcance del SGSI
• Descripción de la empresa
• Delimitación del alcance
• Descripción de la organización dentro de la
empresa

7. Política de Seguridad de la
Información
• Establecer anualmente objetivos con relación a la
Seguridad de la Información
• Complimiento de requisitos legales en materia de
seguridad de la información
• Realizar el análisis de riesgo

8. Identificación y valoración de
activos
1. Identificación de dueños de activos de la
información
2. Identificación de procesos/procedimientos
3. Identificación y clasificación de activos
4. Agrupamiento de activos (tipo-cliente-ubicación)
5. Valoración de los activos
6. Valoración de los grupos

9. ISO/IEC 17799:2005
• La seguridad de la información es un asunto de negocios, no
uno de tecnología.
• Se trata de asegurar la disponibilidad, confidencialidad e
integridad de la información de la organización.
• La introducción de la ISO/IEC 17799:2005 dice que ‘es la
protección de la información de una variedad de amenazas
con el objetivo de garantizar la continuidad del negocio,
minimizar el daño y maximizar el retorno de la inversión y las
oportunidades de negocios, además que es una herramienta
útil para mantener una ventaja competitiva, un flujo de caja,
rentabilidad, cumplimiento legal y regulatorio y una imagen
comercial.

10. Riesgos de Información y Riesgos
Regulatorios
• El propósito de un sistema de gestión de seguridad
de la información es el de reducir y controlar los
riesgos a la seguridad de la información.
• Su organización necesita entender entonces, de
una manera visceral, como se relacionan estos
riesgos con sus operaciones.

11. Soporte Administrativo
Guía de Implementación de ISO27001

12. Soporte Administrativo
• La implementación exitosa de un SGSI depende
absolutamente de que el proyecto tenga todo el
apoyo desde la gerencia administrativa del negocio.

13. Alineación estratégica
• La primera razón de porque el CEO debe apoyar
completamente el proyecto de SGSI es que este es
un proyecto de negocio, y no solamente un
proyecto de TI.
• El compromiso de la alta gerencia significa que el
proyecto obtenga los recursos (financieros y
humanos) que requiere.

14. Administración de Cambios
• Un proyecto exitoso de implementación de un SGSI
es, en otras palabras, de bajo perfil, pero sin
embargo es un proyecto que administra todos los
cambios de la organización de una manera aplica y
la forma en que la organización tiene que aprender
de la experiencia de los programas de
administración de cambios exitosos.

15. El rol del CEO
• El CEO necesita estar completamente al tanto de
los problemas estratégicos relacionados con el
gobierno de TI y de seguridad de la información y el
valor para la compañía de una certificación exitosa.
• La cláusula 5.1 de el estándar específicamente
requiere evidencia de este compromimo desde la
alta gerencia.

16. El compromiso del CEO
• Cualquiera sea la procedencia del mensaje, sea interno o por medio de consultores externos, es necesario
explicar que el soporte activo y comprometido es esencial al proyecto, es necesario explicar porque (razones
abajo), y se necesita especificar lo que este implica.
1. Que el CEO personalmente aplica al entender los beneficios de negocio que persiguen la estrategia de seguridad de
la información, y el retorno de la inversión que este proyecto traera a la organización.
2. Que el CEO organizará una presentación a la Junta Directiva sobre la estrategia de seguridad de la información,
incluyendo la certificación del SGSI en las metas de negocio para el año, asegurando el soporte de la misma para
lograr el objetivo.
3. Y organiza un monitoreo de el progreso del proyecto (el cual asegurara que el proyecto logre y mantenga su
naturaleza política que mejorara las probabilidades de éxito del mismo) mediante su ciclo de vida.
4. Que el CEO personalmente organizará la presentación del proyecto a el grupo de directivos de la organización así
como también a todo el personal en cada foro organizacional que es usado para la comunicación del personal.
5. El CEO debe nominar a alguno de sus altos ejecutivos para soportar el proyecto y liderar el Comité de Seguridad,
para proporcionar soporte y respaldo día a día, y para liderar los esfuerzos de administración de cambios. Y que esta
persona tiene que estar comprometido con el éxito del proyecto, y preparado para hacer lo que sea necesario para
que este tenga éxito.
6. Que el CEO claramente especifique – para la junta directiva y para cualquiera en la organización – la prioridad de
este proyecto, y la autoridad para involucrar aquellos quienes deben contribuir al éxito de este proyecto.
7. Que el CEO pone ejemplo personal aplicando todas las prácticas y siguiendo todos los procedimientos que hacen
parte del nuevo SGSI.

17. Soporte de Gerencia Administrativa
• Un proyecto de un SGSI cruza transversalmente todas las áreas de la
organización, y por consiguiente, es necesario estar seguro cuales son los
líderes clave al interior de la misma.
1. El Comité de Seguridad puede ser liderado tanto por el CEO como por
alguien que haya sido nominado por el CEO y debe ser de un grupo
orientado a los negocios de la organización. Este grupo debe incluir
algunos individuos que pueden ser reacios al proyecto, y que, si es posible,
se les den responsabilidades clave de liderar el éxito del proyecto.
Finalmente, se debe resaltar la importancia de que este grupo no tenga una
preponderancia de gente perteneciente al área de TI o personal técnico – el
proyecto debe verse como un proyecto del negocio, no solo uno de TI.
2. El CEO debe hacer la presentación inicial del Comité de Seguridad, y la
presentación debería enfocarse en los riesgos de seguridad que enfrenta la
organización, y en los impactos potenciales para la organización en el caso
de una falla en la implementación de la seguridad apropiado, y debería
ajustar la categorización relativa y la importancia que tiene el proyecto.

18. Alcance
Guía de Implementación ISO27001

19. Alcance
• La cláusula 4.2.1b de ISO27001 define claramente los componentes de la política
del SGSI.
• La política debe ser aprobada por el comité.
• Su alcance (4.2.1ª), y la política en sí, debe tener en cuenta las características del
negocio, su organización, localización, activos y tecnología.
• La política debe incluir un marco de trabajo para ajustar los objetivos de la política
y establecer el sentido general de su dirección.
• Debe tener en cuenta los requisitos legales, de negocios, regulatorios y
contractuales de seguridad.
• El alcance es esencial para cualquier organización de cualquier tamaño: se debe
decidir cuales activos de información se van a proteger – y cuales no – antes de
decidir en su protección adecuada.
• Se debe ser categórico en definir que va a estar dentro de la fortaleza de
seguridad y que va a quedar por fuera, y esto significa que no se desea que ningún
sistema de información, dispositivo o unidad de negocios quede a ambos lados –
ya que este sería en enlace más débil.

20. Seguridad de Punto Final
• La decisión del alcance necesita incluir todos los dispositivos de
información que la gente usa para realizar su trabajo – tales como
celulares, tabletas, PDAs, portátiles inalámbricos, equipos de escritorio etc.
– así como también los sistemas de oficina centrales mas obvios –
contabilidad, nómina, producción, ventas y manejo de ordenes, correo
electrónico, ofimática, etc. -.
• Pare de la razón del sistema de seguridad de la información es el de
asegurar que se está en cumplimiento con una gran variedad de leyes y
regulaciones, así que tiene sentido para la entidad que tiene estas
obligaciones de cumplimiento estar completamente definidas en el alcance
del proyecto de seguridad de la información.
• Se debe tener presente que un SGSI es un sistema administrativo, una
estructura formal que administra desarrollos para asegurar que su política
de seguridad de la información es aplicada consistentemente a través de la
organización.

21. Definición de Límites
• Típicamente, los límites son identificables lógica y físicamente.
• Los límites deben ser identificados en términos de la organización,
o parte de la organización, que debe ser protegida, cuales redes y
cuales datos, y en que ubicaciones geográficas.
• Organizaciones de múltiples sitios o virtuales necesitan considerar
cuidadosamente los diferentes requisitos de seguridad de sus
diferentes sitios y las implicaciones administrativas de estos.
• El proceso de diseño e implementación de un SGSI es
usualmente simple cuando incluye completamente a la
organización para la cual la junta o el equipo gerencial tiene
responsabilidades definidas.

22. Mapeo de la Red
• El mapa inicial que se dibuja ayuda a hacer el ejercicio
de alcance inicial, el cual necesita ser extendido como
parte de un proyecto detallado en fase de planeación
para asegurarse que todos los aspectos de los
sistemas de información han sido identificados.
• El mapa de la infraestructura debería también
integrarse con la lista de activos de tecnología (los
cuales conformaran la base de la evaluación de
riesgos) y deberían ser un documento vivo, el cual es
actualizado a medida que cambia la red.

23. Planeación
Guía de implantación ISO27001

24. Planeación
• Para los propósitos de la implementación de un
SGSI, la ‘planeación’ incluye el manejo de temas
como el desarrollo de consultores, como se
administrará el proyecto, que tantos sistemas de
administración serán integrados, y la identificación
de las responsabilidades claves y requisitos de
recursos a través del ciclo de vida del proyecto.

25. Aproximación estructurada a la
implementación (1)
• Planee
a) Defina el alcance del SGSI
b) Defina la política de seguridad de la información
c) Defina una aproximación sistemática de evaluación de riesgos
d) Realice la evaluación de riesgos para identificar, dentro del contexto
de la política y el alcance del SGSI, los activos importantes de
información de la organización y los riesgos de éstos
e) Evalúe los riesgos
f) Identifique y evalúe opciones para el tratamiento de estos riesgos
g) Seleccione, para cada aproximación, los objetivos de control y los
controles que serán implementados
h) Prepare una Declaración de Aplicabilidad (SoA)

26. Aproximación estructurada a la
implementación (2)
• Haga
a) Formulación del plan de tratamiento de riesgos, y su
documentación, incluyendo los procesos planeados y los
procedimientos detallados
b) Implementación de un plan de tratamiento de riesgos y
controles planeados
c) Entrenamiento apropiado para el personal afectado, así
como también programas de prevención
d) Manejo de operaciones y recursos en línea con el SGSI
e) Implementación de procedimientos que le permiten un
aviso temprano de la detección, y respuesta a, incidentes
de seguridad

27. Aproximación estructurada a la
implementación (3)
• Chequee
– La etapa de chequeo es, esencialmente, solo un paso,
sin embargo contiene un conjunto de pasos
subsidiarios:
• Monitoreo
• Revisión
• Pruebas
• Auditoría

28. Aproximación estructurada a la
implementación (4)
• Actúe
– Los resultados de las pruebas y auditorías deben ser
revisados por la administración, así como también el SGSI,
a la luz de el ambiente cambiante de riesgos, la tecnología u
otras circunstancias; las mejoras a el SGSI deben ser
identificadas, documentadas e implementadas.
– Posteriormente, deben ser sujetas de una revisión
constante, pruebas posteriores y mejoramiento de
implementación, en un proceso conocido como
‘mejoramiento continuo’

29. Integración con los sistemas de
administración de seguridad existentes
• La evaluación de riesgos es un paso crítico; cualquier control implementado
antes de una evaluación de riesgos que se haya realizado puede ser
deficiente o inapropiado.
• También es muy probable que algunos de los controles implementados
posteriormente a la terminación de una evaluación de riesgos apropiada
puedan ser demasiado robustos, y por ende no son costo efectivos, y
ciertamente no reflejan el estándar o la guía de la ISO 17799; la
certificación debe ser tan compleja de lograr con los controles
extremadamente robustos así como los débiles.
• ISO 27001 necesita asegurarse de que esos controles que se toman son
los adecuados y apropiados y que esos controles requeridos adicionales
son implementados lo más rápido posible. En otras palabras, un análisis
de brecha entre lo que se tiene y lo que se requiere debe ser realizado.

30. Análisis de Brecha
• Este análisis de brecha puede ser conducido tanto de arriba abajo como de
abajo a arriba.
• Un análisis de abajo a arriba empezará recogiendo la información de todos
los controles que se tienen actualmente implementados al interior de la
organización y entonces evaluar si son o no adecuados contra los
requerimientos de la declaración de aplicabilidad de la organización y el
estándar.
• Una aproximación de arriba abajo empieza por los controles identificados
en la declaración de aplicabilidad y evalúa la extensión a cuales ya han
sido implementados.
• La declaración de aplicabilidad solo estará completa una vez todos los
riesgos identificados sean evaluados y la aplicabilidad de todos los
controles identificados ha sido considerada y documentada.
• Usualmente, la declaración se inicia antes de que es implemente alguno de
los controles y completada una vez el control final se pone en marcha.

31. Integración al Sistema de Calidad
• El SGSI debe ser integrado con el sistema de aseguramiento
de la calidad a su mayor extensión posible.
• Particularmente, las cláusulas 4.3 (Documentación), 4.3.2
(Control de documentos) y 4.3.3 (registros) pueden (y
deberían) ser cumplidos mediante la aplicación de cualquier
requisito de control de documentación existente de un
sistema de manejo de ISO 9001.
• La aproximación lógica es que la aproximación de la ISO
9000 debe ser adoptada por cualquier organización que
implemente un SGSI.

32. Gerencia de Proyectos (1)
• El equipo ciertamente debe incluir al menos un gerente de
proyectos experimentado, el cual sería el responsable de
trazar y reportar el progreso contra los objetivos planeados.
• El equipo del proyecto debe reportarle tanto al jefe del comité
de dirección o (preferiblemente) al CEO y debe tener la
autoridad apropiada delegada para implementar un plan de
proyecto para el SGSI aprobada por la junta. (Cláusula 5.1e)
• Aparte del gerente responsable de la seguridad de la
información y un experto en seguridad de la información
entrenado, la representación más crítica será de ventas,
operaciones y admiinstración.

33. Gerencia de Proyectos (2)
• Director del Equipo del Proyecto
– El director necesita, entonces, ser alguien que es capaz
de obtener el respeto de todos los miembros del equipo
del proyecto.

34. Plan del Proyecto
• El plan del proyecto necesita contener y delinear un calendario y una identificación de alto nivel de las
responsabilidades, así como también el camino crítico para ser completado.
• También debería proporcionar un alcance suficiente para aquellos que tendrán que implementar el plan para
encontrar las soluciones apropiadas a los muchos desafíos operacionales que este proyecto tendrá.
• Hay un número de razones posibles para esto, incluyendo el deseo del director de TI de no perder el control
de la seguridad de TI (particularmente en la acreditación de ISO27001 que se ha definido como una
responsabilidad del departamento de TI), el deseo del departamento de TI de mantener su halo de misticismo
y miedo de que sus controles puedan ser encontrados como inadecuados.
• ISO 27001 requiere que la junta de la organización y la alta dirección tome el control del SGSI y que toda la
organización apoye y entienda los aspectos clave de la política de seguridad.
• El equipo del proyecto necesitaran un entrenamiento inicial en los principios de ISO 27001, la metodología de
cambio y gerencia de proyectos y los principios de las comunicaciones internas.
• El director de TI y el personal de TI deberán tener las competencias específicas en Seguridad de la
Información y, si esto requiere ser apalancado por entrenamiento, este debe ser realizado por una
organización que reconozca y entienda los aspectos técnicos del entrenamiento en ISO 27001.

35. Costos y Monitoreo del Proyecto
• Los aspectos clave del progreso del proyecto que deben ser
revisados son:
1. Luego de completar el borrador de la declaración de aplicabilidad
(SoA). Cualquiera de los costos luego de esto deben ser mínimos,
pero, hasta que la Soa defina lo que se requiere hacer, no será
posible tener un presupuesto efectivo para la implementación.
2. Luego de la implementación de la parte inicial de los procedimientos
que aplican a los controles identificados.
3. Luego de completar el primer ciclo de auditorías del sistema y las
revisiones y posterior a la visita inicial del cuerpo de certificación.
4. Anualmente, como parte de la revisión regular del SGSI, para
asegurar que el presupuesto esta correctamente aplicado, y que
algún asunto de nuevas tecnologías, amenazas y vulnerabilidades
estén siendo tenidas en cuenta.

36. Comunicaciones
Guía de implantación de ISO 27001

37. Comunicaciones
• Las comunicaciones de arriba debajo de la visión de seguridad de la información –
porque se requiere el SGSI, cuales son las responsabilidades legales de la
organización, como será la percepción del negocio una vez se ha completado el
programa y cuales son los beneficios que traerá a todos en la organización.
• Reuniones regulares en cascada a todo el personal acerca del progreso sobre los
objetivos del plan.
• Un mecanismo para asegurar que los factores clave y los individuos en el
desarrollo de los componentes clave del sistema.
• Un mecanismo para asegurar la retroalimentación regular e inmediata de las
personas de la organización, o las organizaciones de tercera parte afectadas, para
así tener una aproximación de su experiencia directa del sistema inicial así como
su implementación puede ser usada en la evolución de la versión final.
• Las comunicaciones frente a frente deberían ser apuntaladas con un sistema para
compartir la información efectivo.

38. Comunicaciones (cont.)
• Se va a requerir un compromiso simple, fuerte,
amplio en toda la organización, de arriba abajo,
soportado por un gran número de discusiones en
las cuales se ajustará como el proyecto del SGSI
mejorará específicamente las circunstancias de
negocios para cada persona con la que se habla.

39. Política de Seguridad de la
Información
• La extensión en la cual se ha tenido éxito en la
construcción de un soporte a través de la organización
y a través de las funciones para este proyecto se verá
reflejado en la facilidad con la cual se va a poder tener
un borrador de la política de seguridad de la
información y se llega a un acuerdo sobre la misma.
• Esta política de seguridad de la información es el
conductor principal para el SGSI; ajusta las políticas de
la junta, y los requerimientos respecto a la seguridad
de la información.

40. Evaluación de Riesgos
Guía de implantación de ISO 27001

41. Evaluación de Riesgos
• Entender el significado total de este proceso es crítico, y es uno
de los procesos claves para el éxito del proyecto.
• La junta adopta una política de seguridad de la información debido
a que hay un número significativo de riesgos a la disponibilidad,
integridad y confidencialidad de la información de la organización.
• El punto de partida de cualquier director de proyecto de un SGSI
para considerar el riesgo es de aceptar la existencia de funciones
para el manejo de riesgos (si es que hay una) dentro de la
organización, con el objetivo de entender:
a) Su aproximación total a los riesgos.
b) Su aproximación específica a los riesgos de seguridad de la
información.

42. Introducción de Administración de
Riesgos
• La administración de riesgos es una disciplina para
manejar cualquier riesgo no especulativo, aquellos
riesgos en los cuales solo puede ocurrir una
pérdida.
• Usualmente, la identificación de un riesgo es tanto
especulativo o permanentemente refleja el apetito
por el riesgo de la organización.

43. Planes de Administración de
Riesgos (1)
1. Eliminar Riesgos.
2. Reducir aquellos riesgos que no pueden ser
eliminados a un nivel aceptable.
3. Vivir con ellos, ejercitando controles cuidadosos
que los mantienen en un nivel aceptable.
4. Transferirlos, mediante el aseguramiento, a algún
otra organización.

44. Planes de Administración de
Riesgos (2)
• Las estrategias de administración de riesgos usualmente están basadas en una
evaluación de los beneficios económicos que la organización puede derivar de una
inversión en un control particular.
• En otras palabras, para cada control que la organización pueda implementar, el
cálculo es aquel cuyo costo de implementación puede ser sopesado de los
beneficios económicos de los que se pueda derivar, o las pérdidas económicas
que puedan ser evitadas como resultado de su implementación.
• Una aproximación sistemática a la evaluación de riesgos puede tener en cuenta
los requisitos de negocios, legales y regulatorios ubicados en los negocios.
• En otras palabras, deben ser conducidas por el negocio.
• Los negocios, manejados por su junta de directivos, deben identificar las
amenazas a los activos, vulnerabilidades e impactos en la organización y debería
determinar el grado de riesgo que la organización esté preparada a aceptar – a la
luz de su modelo de negocios, su estrategia de negocios y sus criterios de
inversión.

45. Evaluación de Riesgos (1)
• La evaluación de riesgos es el ‘estudio sistemático’ de
activos, amenazas, vulnerabilidades e impactos a los
activos y las probabilidades y consecuencias de dichos
riesgos.
a) El daño de negocios probable como resultado de un rango
de fallas de negocios.
b) La probabilidad realística de dichas fallas si ocurren.
• La complejidad de una evaluación de riesgos
dependerá de la complejidad de la organización y los
riesgos que se están analizando.

46. Evaluación de Riesgos (2)
• Análisis de Riesgos
– El análisis cualitativo de riesgos es de lejos el mas usado
ampliamente (y es la aproximación esperada por ISO
27001).
– El análisis de riesgos empieza con la identificación de los
activos que están dentro del alcance del SGSI propuesto,
debido a que estos activos son los que están ‘en riesgo’.
– Todas las entradas individuales en el análisis reflejarán el
prejuicio individual, y así el proceso de recolección de
información debería cuestionar las entradas para establecer
que es lo que en realidad se sabe – y que no se sabe.

47. Amenazas
• Una amenaza es algo que puede ir mal o que puede
atacar un activo.
• Pueden ser tanto internas como externas.
• Las amenazas siempre están presentes para cada
sistema o activo – debido a que es valioso para su
dueño, o será disponible para alguien más.
• Para cada uno de los activos, las amenazas deberían
ser consideradas bajo la luz de los encabezados de
confidencialidad, integridad y disponibilidad.

48. Vulnerabilidades
• Las vulnerabilidades dejan un sistema expuesto a
un ataque por una amenaza o permiten que un
ataque sea exitoso o que tenga un mayor impacto.

49. Impacto
• Identificar los posibles impactos que la explotación
exitosa de una vulnerabilidad por una amenaza tendría
en la integridad, confidencialidad y disponibilidad de un
activo (análisis de impacto).
• Evalúa la probabilidad de que el evento ocurra, usando
un sistema de clasificación tal como: una vez cada
ciertos años, una vez al año, una vez cada seis meses,
etc.
• Los ataques por virus por ejemplo pueden caer en la
categoría de ‘Todos los días’.

50. Controles
• El punto clave para tener en cuenta acerca de la
evaluación de riesgos es que no es un ejercicio de
solo una vez.
• Se necesitará repetirlo en una base regular, solo
chequear la línea base de la evaluación es aún
preciso, y aquellos controles que se han
desplegado sean aún apropiados.

51. Selección de Controles
Guía de implantación de ISO 27001

52. Tipos de Controles
1. Los controles disuasorios reducen la probabilidad
de un ataque deliberado.
2. Los controles preventivos protegen
vulnerabilidades y hacen que los ataques no
tengan éxito o reducen su impacto.
3. Los controles correctivos reducen el efecto de un
ataque.
4. Los controles detectivos descubren ataques y
disparan controles preventivos o correctivos.

53. Criterio de Selección de Controles
• El principio consiste en que el costo de implementación y mantenimiento de
un control no debe ser mayor que el costo identificado y cuantificado del
impacto de la amenaza (o amenazas) identificadas.
• Ninguna organización debe invertir en tecnologías de seguridad de la
información (hardware o software) o implementar procesos y
procedimientos de administración de seguridad de la información sin antes
no haber realizado una evaluación de riesgos y controles que les asegure
que:
– La inversión propuesta (el costo total del control) es el mismo que, o menor
que, el costo del impacto de la amenaza identificada.
– La clasificación de riesgos, la cual tiene en cuenta su probabilidad, su
apropiación de la inversión propuesta, y
– La prioridad del riesgo – por ejemplo, todos los riesgos con priorizaciones
mayores ya han sido apropiadamente controlados y, entonces, es ahora
apropiado invertir en los controles para éste.

54. Declaración de Aplicabilidad (SoA)
• La SoA es, en esencia, una lista de los controles
identificados en el Anexo A de ISO 27001:2005 en
conjunto con su declaración sea que el control se
aplique o no a la organización.
• La SoA describe como es aplicada e identifica las
políticas y procedimientos a través de los cuales es
aplicado, la SoA explica porque no es aplicado, y
proporciona razones claras y concisas.

55. Documentación
Guía de implantación de ISO 27001

56. Documentación
• ISO 27001 describe la documentación mínima que debe ser incluida en el SGSI (para
cumplir con los requisitos del estándar de que la organización mantiene los registros
suficientes para demostrar el cumplimiento con los requerimientos del estándar). Estos
documentos incluyen:
– La política de seguridad de la información, la declaración del alcance del SGSI, la evaluación de riesgos,
los objetivos de control y la declaración de aplicabilidad. En conjunto, estos forman el manual de
políticas del SGSI.
– Evidencia de las acciones tomadas por la organización y su gerencia para especificar el alcance del
SGSI (las minutas de la junta y las reuniones del comité de dirección, así como también algunos reportes
de especialistas).
– Una descripción de la plataforma administrativa (comité de dirección, etc.). Esto podría ser útil si se
relaciona con un gráfico de la estructura organizacional.
– El plan de tratamiento de riesgos y los procedimientos documentados relacionados (los cuales pueden
incluir las responsabilidades y las acciones requeridas) que implementan cada uno de los controles
específicos. Un procedimiento describe quien ha hecho que, bajo que condiciones, o para cuando, y
como. Estos procedimientos (que podrían ser uno para cada uno de los controles implementados)
serían parte del manual de políticas el cual, en sí mismo, puede estar en formato impreso o electrónico.
– Los procedimientos (los cuales pueden incluir responsabilidades y acciones requeridas) que gobiernan la
administración y revisión del SGSI. Estos pueden ser parte del manual de políticas.

57. Cuatro niveles de documentación
• En términos prácticos, hay cuatro niveles de documentación de un SGSI, y cada
nivel tiene diferentes características, incluyendo acerca de quien está autorizado a
tomar decisiones relacionadas con revisiones a estos. Los cuatro niveles son:
1. La política aprobada por la junta corporativa, la cual dirige todos los otros aspectos
del SGSI.
2. La declaración de aplicabilidad y las políticas individuales (estableciendo, por
instancias, que constituye el uso aceptable de la Internet)
3. Procedimientos detallados, que describen quien es responsable de hacer que y en
que orden.
4. Instrucciones de Operaciones/Trabajo, que determinan precisamente en detalle
como cada una de las tareas identificadas son realizadas.
• La cantidad de trabajo se incrementa a medida que se desciende por los cuatro
niveles; el nivel mas demandante en términos de tiempo, es producir el cuarto
nivel – aún si es esencialmente la documentación de los métodos existentes de
realizar actividades específicas – una vez, estos han sido formados en línea con
los requisitos de control.

58. Pruebas
Guía de implantación de ISO 27001

59. Pruebas
• Un SGSI debe trabajar en el mundo real.
• Se han identificado los riesgos, se ha desplegado lo
que se considera ser los controles apropiados, y se
quiere estar seguro de dos cosas:
– Que los controles trabajan como debe ser
– Y que cuando se ven abrumados (y tarde o temprano lo
serán), sus medidas de contra emergencia funcionarán

60. Tipos de Pruebas
• Auditoría directa: la que involucra a un auditor entrenado que realiza un
procedimiento documentado y solicita se le demuestre que lo que se
describe en el procedimiento es efectivamente lo que pasa.
• ‘Prueba de Papel’: Este es un ejercicio intelectual, que requiere más de una
persona, y que requiere familiaridad con las vulnerabilidades del activo, los
mecanismos de control y los mecanismos de tratamiento de las amenazas
potenciales.
• Prueba de la vida real limitada: Esta, por ejemplo, involucrara apagar el
cuarto de servidores durante las operaciones normales, para observar si el
sistema UPS y los procedimientos de apagado del servidor funcionan como
es especificado.
• Prueba de gran escenario: usualmente usado para probar planes de
continuidad de negocios.
• Se necesitará programas las auditorías y pruebas para que, en el curso del
año, todos los aspectos del SGSI estén cubiertos.

61. Certificación Exitosa
Guía de implantación de ISO 27001

62. Certificación
1. Asegúrese que la documentación este completa, comprensible y totalmente disponible para la inspección –
en la visita inicial, que se presenta antes de la auditoría de certificación.
2. Asegúrese que toda su auditoría interna y los registros de pruebas están inmediatamente disponibles para
los auditores de certificación cuando planifican y comienzan su trabajo; ellos deberían usar estos registros
para garantizar que se enfocan en las áreas clave del SGSI, y así asegurarse que se han probado
adecuadamente.
3. Entrene al personal de toda la organización para que sea completamente honesto con los auditores,
especialmente acerca de cosas que puedan sentir que no vayan con el estándar. Esto sirve a dos
propósitos: muestra las debilidades que se requiera reforzar, además que demuestra a los auditores que se
tiene una organización abierta que identifica y maneja los problemas de seguridad de la información.
4. Eduque ese personal que pueda ser más probable de ser entrevistado por los auditores para que les
muestren como el sistema que está siendo examinado trabaja realmente y a restringir todo lo que dicen a
responder la pregunta específica que les está haciendo el auditor, en lugar de moverse a explicar todo lo
demás que no es específico i ajustado al asunto de la pregunta.
5. Críticamente, asegúrese que están completamente involucrados en la auditoría de certificación. Si es
necesario, ensaye con el personal administrativo el tipo de preguntas y los tipos de respuestas que se
espera den.
6. Esté preparado para argumentar – constructiva y calmadamente, pero si hay asuntos en los cuales siente
que el auditor no ha entendido su SGSI o algún aspecto de éste, o se ha malinterpretado el estándar, y es,
como resultado el reporte de una no-conformidad (mayor o menor), se debe explicar, calmada y firmemente,
porque se cree que se esté en lo correcto.