ISO-IEC 27005-2011-Risk Management-Desbloqueado-Convertido ES

Suscríbete a DeepL Pro para poder editar este documento.
Entra en www.DeepL.com/pro para más información.
AVISO DE DERECHOS DE AUTOR Y CONDICIONES DE USO DE

ISO STANDARDS
Este documento es el copyright del editor. Todos los derechos están reservados.
El contrato que le permite utilizar este documento contiene las siguientes condiciones de uso que
deben seguirse:-
(a) Este material se reproduce de las publicaciones de la ISO con el número de licencia de
derechos de autor de la Organización Internacional de Normalización (ISO) SAI
GLOBAL/MCEA/2008. No para su reventa. Ninguna parte de estas publicaciones de la ISO puede
ser reproducida en ninguna forma, sistema de recuperación electrónica o de otro modo, excepto en
la medida en que lo permita la ley de derechos de autor del país de utilización, o con el
consentimiento previo por escrito de la ISO (Case postale 56, 1211 Ginebra 20, Suiza, correo
electrónico: [email protected]) o de los miembros de la ISO.
(b) Usted puede reproducir en copia impresa solamente, directamente del documento
proporcionado en formato de medios electrónicos, todo o parte del documento para fines internos,
en el/los sitio(s) designado(s) en su acuerdo, siempre que dichas copias incluyan un aviso de
derechos de autor y estén fechadas y destruidas después de su uso, con sujeción a las excepciones
descritas en la Sección 7.3 (c) siguiente
(c) Cuando se requiera una licitación o un acuerdo contractual en el que se exija la reproducción
de un documento de la ISO en el marco de esta suscripción como parte de su documentación para
su presentación externa, se podrán reproducir y presentar las páginas necesarias de la publicación
de la ISO, o la publicación completa, si así se requiere.
(d) Bajo ninguna circunstancia se podrán prestar, comercializar o distribuir copias de la totalidad
o parte de cualquier publicación de la ISO, tomadas del servicio de suscripción, de ninguna manera,
excepto en los casos establecidos en los apartados b) y c) anteriores.
(e) Bajo ninguna circunstancia se permite la reproducción total o parcial de ninguna publicación
de la ISO contenida en el servicio de suscripción para uso externo o para su uso en cualquier sitio o
grupo de sitios, salvo lo dispuesto en los apartados a) y b) anteriores.
SAI GLOBAL - ILI Publishing, Index House, Ascot, Berks, SL5 7EU, UK
: +44 (0)1344636300 Fax: +44 (0)1344 Correo electrónico291194 :
[email protected] Web: www.ili.co.uk
Material con derechos de autor licenciado al Instituto de Tecnología de Dublín por SAI Global (www.saiglobal.com), descargado el 31 de diciembre
11 por Ann McSweeney.
No se permite ninguna otra reproducción o distribución. No se controla cuando se imprime.
NORMA ISO/IEC
INTERNACIONAL 27005
Segunda
edición
2011-06-01
Tecnología de la información -
Técnicas de seguridad - Gestión de
riesgos para la seguridad de la
información
Tecnología de la información - Técnicas de seguridad - Gestión de
riesgos de seguridad de la información
Número de
referencia ISO/IEC
27005:2011(E)
© ISO/IEC 2011
ISO/IEC 27005:2011(E)
DOCUMENTO PROTEGIDO POR DERECHOS DE AUTOR

© ISO/IEC 2011
Todos los derechos reservados. A menos que se especifique lo contrario, ninguna parte de esta publicación podrá ser reproducida o
utilizada en forma alguna ni por ningún medio, electrónico o mecánico, incluidos la fotocopia y el microfilm, sin el permiso escrito de la
ISO en la dirección que figura a continuación o del órgano miembro de la ISO en el país del solicitante.
La oficina de derechos de autor de la ISO
Case postale 56 CH-1211 Ginebra 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
Correo electrónico
[email protected] Web
www.iso.org
Publicado en Suiza
ii© ISO/IEC 2011 - Todos los derechos reservados
ISO/IEC 27005:2011(E)
Página de contenidos
Foreword........................................................................................................................................................... v
Introduction...................................................................................................................................................... vi
1 Scope.................................................................................................................................................... 1
2 Normativareferences.......................................................................................................................... 1
3 Términos ydefinitions......................................................................................................................... 1
4 La estructura de esta InternacionalStandard................................................................................... 5
5 Background.......................................................................................................................................... 6
6 Panorama general de la gestión de riesgos para la seguridad de la informaciónprocess.......... 7
7 Contextoestablishment.................................................................................................................... 10
7.1 General considerations..................................................................................................................... 10
7.2 Basic Criteria...................................................................................................................................... 10
7.2.1 Riesgomanagement approach......................................................................................................... 10
7.2.2 Evaluación del riesgocriteria........................................................................................................... 10
7.2.3 Impactocriteria.................................................................................................................................. 11
7.2.4 Aceptación del riesgocriteria........................................................................................................... 11
7.3 Alcance yboundaries........................................................................................................................ 12
7.4 Organización para el riesgo de la seguridad de la informaciónmanagement............................. 12
8 Riesgo para la seguridad de la informaciónassessment.............................................................. 13
8.1 Descripción general del riesgo para la seguridad de la informaciónassessment...................... 13
8.2 Riesgoidentification.......................................................................................................................... 13
8.2.1 Introducción al riesgoidentification................................................................................................ 13
8.2.2 Identificación deassets..................................................................................................................... 14
8.2.3 Identificaciónof threats..................................................................................................................... 14
8.2.4 Identificación de lascontrols............................................................................................................ 15
8.2.5 Identificación devulnerabilities........................................................................................................ 15
8.2.6 Identificación deconsequences....................................................................................................... 16
8.3 Risk analysis...................................................................................................................................... 17
8.3.1 Risk analysis methodologies............................................................................................................ 17
8.3.2 Evaluaciónof consequences............................................................................................................ 18
8.3.3 Evaluación del incidentelikelihood................................................................................................. 18
8.3.4 Nivel de riesgodetermination........................................................................................................... 19
8.4 Risk evaluation................................................................................................................................... 19
9 Riesgo para la seguridad de la informacióntreatment................................................................... 20
9.1 Descripción general del riesgotreatment........................................................................................ 20
© ISO/IEC 2011 - Todos los derechos reservadosiii
ISO/IEC 27005:2011(E)
9.2 Riesgomodification........................................................................................................................... 22
9.3 Risk retention..................................................................................................................................... 23
9.4 Risk avoidance................................................................................................................................... 23
9.5 Risk sharing....................................................................................................................................... 23
10 Riesgo para la seguridad de la informaciónacceptance............................................................... 24
11 La comunicación de los riesgos para la seguridad de la información yconsultation................ 24
12 La vigilancia de los riesgos para la seguridad de la información yreview.................................. 25
12.1 Vigilancia y examen del riesgofactors............................................................................................ 25
12.2 Vigilancia de la gestión de riesgos, examen yimprovement......................................................... 26
Anexo A (informativo) Definición del alcance y los límites del riesgo para la seguridad de la información
gestiónprocess................................................................................................................................. 28
A.1 Estudio dethe organization.............................................................................................................. 28
A.2 Lista de las limitaciones que afectan athe organization............................................................... 29
A.3 Lista de las referencias legislativas y reglamentarias aplicables alorganization....................... 31
A.4 Lista de las limitaciones que afectan a lascope............................................................................. 31
Anexo B (informativo) Identificación y valoración de los activos y el impactoassessment..................... 33
B.1 Ejemplos del activoidentification.................................................................................................... 33
B.1.1 La identificación de losassets........................................................................................ 33 primarios
B.1.2 Lista y descripción del apoyoassets............................................................................................... 34
B.2 Activovaluation................................................................................................................................. 38
B.3 Impactoassessment.......................................................................................................................... 41
Anexo C (informativo) Ejemplos de los típicosthreats.................................................................................. 42
Anexo D (informativo) Vulnerabilidades y métodos para la vulnerabilidadassessment............................. 45
D.1 Ejemplos devulnerabilities............................................................................................................... 45
D.2 Métodos para la evaluación de la técnicavulnerabilities............................................................... 48
Anexo E (informativo) Evaluación de los riesgos para la seguridad de la informaciónapproaches........ 50
E.1 Riesgo de alto nivel para la seguridad de la informaciónassessment......................................... 50
E.2 Información detallada sobre el riesgo para la seguridadassessment.......................................... 51
E.2.1 Ejemplo 1 Matriz conpredefined values.......................................................................................... 52
E.2.2 Ejemplo 2 Clasificación de las amenazas por medidasof Risk..................................................... 54
E.2.3 Ejemplo 3 Evaluación de un valor para la probabilidad y las posibles consecuencias derisks 54
Anexo F (informativo) Limitaciones del riesgomodification.......................................................................... 56
Anexo G (informativo) Diferencias en las definiciones entre la ISO/CEI 27005:2008 y la ISO/CEI
27005:2011............................................................................................................................................ 58
Bibliography.................................................................................................................................................... 68
iv© ISO/IEC 2011 - Todos los derechos reservados

ISO/IEC 27005:2011(E)
Prólogo
La ISO (Organización Internacional de Normalización) y la CEI (Comisión Electrotécnica Internacional) forman
el sistema especializado de normalización mundial. Los organismos nacionales que son miembros de la ISO
o la CEI participan en la elaboración de normas internacionales mediante comités técnicos establecidos por la
organización respectiva para ocuparse de determinadas esferas de actividad técnica. Los comités técnicos de
la ISO y la IEC colaboran en esferas de interés mutuo. También participan en la labor otras organizaciones
internacionales, gubernamentales y no gubernamentales, en enlace con la ISO y la CEI. En la esfera de la
tecnología de la información, la ISO y la CEI han establecido un comité técnico conjunto, ISO/CEI JTC 1.
Las normas internacionales se redactan de conformidad con las reglas que figuran en las directivas de la ISO/CEI,
parte 2.
La principal tarea del comité técnico conjunto es preparar las normas internacionales. Los proyectos de
Normas Internacionales aprobadas por el comité técnico conjunto se distribuyen a los organismos nacionales
para su votación. La publicación como Norma Internacional requiere la aprobación de al menos el 75% de los
organismos nacionales que emiten un voto.
Se llama la atención sobre la posibilidad de que algunos de los elementos de este documento sean objeto de
derechos de patente. La ISO y la IEC no se responsabilizan de la identificación de alguno o todos esos
derechos de patente.
ISO/IEC 27005 fue preparada por el Comité Técnico Conjunto ISO/IEC JTC 1, Tecnología de la Información,
Subcomité SC 27, Técnicas de Seguridad de TI.
Esta segunda edición cancela y reemplaza la primera edición (ISO/IEC 27005:2008) que ha sido
técnicamente revisada.
© ISO/IEC 2011 - Todos los derechos reservadosv
ISO/IEC 27005:2011(E)
Introducción
Esta Norma Internacional proporciona directrices para la gestión de los riesgos de seguridad de la
información en una organización, apoyando en particular los requisitos de una gestión de la seguridad de la
información (GSI) de acuerdo con la norma ISO/CEI 27001. Sin embargo, esta Norma Internacional no
proporciona ningún método específico para la gestión de riesgos para la seguridad de la información.
Corresponde a la organización definir su enfoque de la gestión del riesgo, en función, por ejemplo, del
alcance del SGSI, del contexto de la gestión del riesgo o del sector industrial. En el marco descrito en esta
Norma Internacional pueden utilizarse varias metodologías existentes para aplicar los requisitos de un SGSI.
Esta Norma Internacional es pertinente para los directivos y el personal que se ocupan de la gestión de los
riesgos para la seguridad de la información dentro de una organización y, cuando proceda, para las partes
externas que apoyan esas actividades.
vi© ISO/IEC 2011 - Todos los derechos reservados
INTERNACIONALSTANDARD ISO/IEC 27005:2011(E)
Tecnología de la información - Técnicas de seguridad -

Gestión de riesgos para la seguridad de la información
1 Alcance
Esta Norma Internacional proporciona directrices para lagestión de los riesgos de seguridad de la información.
Esta Norma Internacional apoya los conceptos generales especificados en la norma ISO/CEI 27001 y tiene
por objeto contribuir a la aplicación satisfactoria de la seguridad de la información sobre la base de un
enfoque de gestión de riesgos.
El conocimiento de los conceptos, modelos, procesos y terminologías descritos en la ISO/IEC 27001 y la

ISO/IEC 27002 es importante para una completa comprensión de esta Norma Internacional.
Esta Norma Internacional es aplicable a todos los tipos de organizaciones (por ejemplo, empresas
comerciales, organismos gubernamentales, organizaciones sin fines de lucro) que se proponen gestionar los
riesgos que podrían comprometer la seguridad de la información de la organización.
2 Referencias normativas
Los siguientes documentos de referencia son indispensables para la aplicación del presente documento. Para
las referencias fechadas, sólo se aplica la edición citada. Para las referencias no fechadas, se aplica la última
edición del documento referenciado (incluyendo cualquier enmienda).
ISO/IEC 27000, Tecnología de la información - Técnicas de seguridad - Sistemas de gestión de la seguridad

de la información - Visión general y vocabulario
ISO/IEC 27001:2005, Tecnología de la información - Técnicas de seguridad - Sistemas de gestión de la

seguridad de la información - Requisitos
3 Términos y definiciones
A los efectos del presente documento, se aplican los términos y definiciones que figuran en la norma ISO/CEI 27000 y
los siguientes.
NOTA Las diferencias en las definiciones entre la norma ISO/CEI 27005:2008 y la presente norma internacional se muestran en el
Anexo G.
3.1
consecuencia
resultado de un evento (3.3) que afecte a los
objetivos [Guía ISO 73:2009]
NOTA1 Un evento puede llevar a una serie de consecuencias.
NOTA2 Una consecuencia puede ser cierta o incierta y en el contexto de la seguridad de la información suele
ser negativa. NOTA3 Las consecuencias pueden expresarse cualitativa o cuantitativamente.
NOTA4 Las consecuencias iniciales pueden escalar a través de los efectos secundarios.
© ISO/IEC 2011 - Todos los derechos reservados1
ISO/IEC 27005:2011(E)
3.2
control
medida que está modificando el
riesgo (3.9) [Guía ISO 73:2009]
NOTA1 Los controles para la seguridad de la información incluyen cualquier proceso, política, procedimiento,
directriz, práctica o estructura organizativa, que puede ser de naturaleza administrativa, técnica, de gestión o jurídica que
modifique el riesgo para la seguridad de la información.
NOTA Es posible que2 los controles no siempre ejerzan el efecto modificador
previsto o asumido. NOTA3 El término "control" también se utiliza como
sinónimo de salvaguardia o contramedida.
3.3
evento
ocurrencia o cambio de un conjunto de circunstancias
particulares [Guía ISO 73:2009]
NOTA1 Un evento puede ser una o más ocurrencias, y puede tener varias
causas. NOTA2 Un evento puede consistir en algo que no está sucediendo.
NOTA3 Un evento a veces puede ser referido como un "incidente" o "accidente".
3.4
contexto externo
entorno externo en el que la organización busca alcanzar sus objetivos [Guía
ISO 73:2009]
NOTE El contexto externo puede incluir:
⎯ el entorno cultural, social, político, jurídico, reglamentario, financiero, tecnológico, económico, natural
y competitivo, ya sea internacional, nacional, regional o local;
⎯ los principales impulsores y tendencias que repercuten en los objetivos de la organización; y
⎯ las relaciones con los interesados externos y las percepciones y valores de éstos.
3.5
contexto interno
entorno interno en el que la organización busca alcanzar sus objetivos [Guía ISO
73:2009]
NOTE El contexto interno puede incluir:
⎯ la gobernanza, la estructura organizativa, las funciones y las responsabilidades;

⎯ las políticas, los objetivos y las estrategias que se han establecido para lograrlos;
⎯ las capacidades, entendidas en términos de recursos y conocimientos (por ejemplo, capital, tiempo,
personas, procesos, sistemas y tecnologías);
⎯ los sistemas de información, las corrientes de información y los procesos de adopción de decisiones (tanto oficiales
como oficiosos);
⎯ las relaciones con los interesados internos y las percepciones y valores de éstos;
⎯ la cultura de la organización;
⎯ normas, directrices y modelos adoptados por la organización; y
⎯ forma y alcance de las relaciones contractuales.
2© ISO/IEC 2011 - Todos los derechos reservados
ISO/IEC 27005:2011(E)
3.6
nivel de riesgo
magnitud de un riesgo (3,9), expresada en términos de la combinación de consecuencias (3,1) y su probabilidad
(3.7)
[Guía ISO 73:2009]
3.7
probabilidad
posibilidad de que algo ocurra [Guía
ISO 73:2009]
NOTA 1 En la terminología de la gestión de riesgos, la palabra "probabilidad" se utiliza para referirse a la posibilidad de
que algo suceda, ya sea definida, medida o determinada objetiva o subjetivamente, cualitativa o cuantitativamente, y
descrita con términos generales o matemáticamente (como una probabilidad o una frecuencia en un período de tiempo
determinado).
NOTA 2 El término inglés "likelihood" no tiene un equivalente directo en algunos idiomas; en cambio, a menudo se utiliza
el equivalente del término "probability". Sin embargo, en inglés, "probability" suele interpretarse en sentido estricto como
un término matemático. Por consiguiente, en la terminología de gestión de riesgos, "probabilidad" se utiliza con la
intención de que tenga la misma interpretación amplia que el término "probabilidad" tiene en muchos idiomas distintos del
inglés.
3.8
riesgo residual
riesgo (3.9) que queda después del
tratamiento de riesgo (3.17) [Guía ISO
73:2009]
NOTA El1 riesgo residual puede contener un riesgo1 no identificado.
NOTA2 El riesgo residual también puede ser conocido como "riesgo2 retenido".
3.9
riesgo
efecto de la incertidumbre en los
objetivos [Guía ISO 73:2009]
NOTA1 Un efecto es una desviación de lo esperado - positivo y/o negativo.
NOTA 2 Los objetivos pueden tener diferentes aspectos (como objetivos financieros, de salud y seguridad, de seguridad
de la información y ambientales) y pueden aplicarse a diferentes niveles (como el estratégico, el de toda la organización,
el de los proyectos, el de los productos y el de los procesos).
NOTA 3 El riesgo se caracteriza a menudo por la referencia a los acontecimientos potenciales (3.3) y las consecuencias
(3.1), o una combinación de éstos.
NOTA 4 El riesgo para la seguridad de la información suele expresarse en términos de una combinación de las
consecuencias de un evento de seguridad de la información y la correspondiente probabilidad (3.9) de que ocurra.
NOTA 5 La incertidumbre es el estado, incluso parcial, de deficiencia de información relacionada con un acontecimiento,
su consecuencia o probabilidad, o de su comprensión o conocimiento.
NOTA 6 El riesgo para la seguridad de la información está asociado a la posibilidad de que las amenazas exploten las
vulnerabilidades de un activo de información o un grupo de activos de información y, por consiguiente, causen daño a una
organización.
3.10
análisis de riesgos
proceso para comprender la naturaleza del riesgo y determinar el nivel de
riesgo (3.6) [Guía ISO 73:2009].

ISO/IEC 27005:2011(E)
NOTA El análisis de1 riesgos proporciona la base para la evaluación de los riesgos y las
decisiones sobre el tratamiento de los mismos. NOTA El análisis de riesgos2 incluye la
estimación del riesgo.
3.11
evaluación de riesgos
proceso general de identificación de riesgos (3.15), análisis de riesgos (3.10) y
evaluación de riesgos (3.14) [Guía ISO 73:2009].
3.12
comunicación y consulta de riesgos
procesos continuos e iterativos que una organización lleva a cabo para proporcionar, compartir u obtener
información, y para entablar un diálogo con los interesados (3.18) en relación con la gestión del riesgo (3.9)
[Guía ISO 73:2009]
NOTA1 La información puede referirse a la existencia, la naturaleza, la forma, la probabilidad, la importancia, la

evaluación, la aceptabilidad y el tratamiento del riesgo.
NOTA2 La consulta es un proceso bidireccional de comunicación informada entre una organización y sus
interesados sobre una cuestión antes de tomar una decisión o determinar una dirección sobre esa cuestión. La consulta
es:
⎯ un proceso que repercute en una decisión a través de la influencia en lugar del poder; y
⎯ una aportación a la toma de decisiones, no a la toma de decisiones conjuntas.
3.13
criterios de riesgo
mandato con el que se evalúa la importancia de un riesgo (3.9) [Guía ISO
73:2009]
NOTA Los criterios1 de riesgo se basan en los objetivos de la organización y en el contexto
externo e interno. NOTA Los criterios de riesgo2 pueden derivarse de normas, leyes,
políticas y otros requisitos.
3.14
evaluación de riesgos
proceso de comparación de los resultados del análisis de riesgos (3.10) con los criterios de riesgo (3.13)
para determinar si el riesgo y/o su magnitud es aceptable o tolerable
[Guía ISO 73:2009]
NOTE La evaluación de los riesgos ayuda en la decisión sobre el tratamiento deNOTE los riesgos.
3.15
identificación de riesgos
proceso de encontrar, reconocer y describir los
riesgos [Guía ISO 73:2009]
NOTA1 La identificación de riesgos implica la identificación de las fuentes de riesgo, los acontecimientos, sus causas
y sus posibles consecuencias.
NOTA2 La identificación de riesgos puede incluir datos históricos, análisis teóricos, opiniones informadas y expertas,
y las necesidades de los interesados.
4 © ISO/IEC 2011 - Todos los derechos reservados
ISO/IEC 27005:2011(E)
3.16
gestión de riesgos
actividades coordinadas para dirigir y controlar una organización en relación
con el riesgo [Guía ISO 73:2009].
NOTE En esta Norma Internacional se utiliza el término "proceso" para describir la gestión del riesgo en general. Los
elementos del proceso de gestión de riesgos se denominan "actividades".
3.17
tratamiento del riesgo
proceso de
modificación del
riesgo [Guía ISO
73:2009]
NOTA1 El tratamiento de los riesgos puede implicar:
⎯ evitar el riesgo decidiendo no iniciar o continuar con la actividad que da origen al riesgo;
⎯ tomar o aumentar el riesgo para buscar una oportunidad;
⎯ eliminando la fuente de riesgo;
⎯ cambiando la probabilidad;
⎯ cambiando las consecuencias;
⎯ compartir el riesgo con otra u otras partes (incluidos los contratos y la financiación del riesgo); y
⎯ reteniendo el riesgo mediante una elección informada.
NOTA2 Los tratamientos de riesgo que se ocupan de las consecuencias negativas se denominan a veces
"mitigación de riesgos", "eliminación de riesgos", "prevención de riesgos" y "reducción de riesgos".
NOTA3 El tratamiento de los riesgos puede crear nuevos riesgos o modificar los existentes.
3.18
interesado
persona u organización que puede afectar, ser afectada o percibir que se ve afectada por una decisión o
actividad
[Guía ISO 73:2009]
NOTE Un responsable de la toma de decisiones puede ser una parte interesada.
4Estructura de esta norma internacional

Esta Norma Internacional contiene la descripción del proceso de gestión de los riesgos para la seguridad de
la información y sus actividades.
La información de antecedentes se presenta en la cláusula 5.
En la cláusula 6 se ofrece un panorama general del proceso de gestión de riesgos para la seguridad de la
información.
Todas las actividades de gestión de riesgos para la seguridad de la información que se presentan en la
cláusula 6 se describen posteriormente en las siguientes cláusulas:
 Establecimiento del contexto en la cláusula 7,

 Evaluación del riesgo en la cláusula 8,
 Tratamiento del riesgo en la cláusula 9,

ISO/IEC 27005:2011(E)
 Aceptación del riesgo en la cláusula 10,

 Comunicación de riesgos en la cláusula 11,
 Vigilancia y examen de los riesgos en la cláusula 12.
En los anexos se presenta información adicional sobre las actividades de gestión de los riesgos para la
seguridad de la información. El establecimiento del contexto se apoya en el anexo A (Definición del alcance y
los límites del proceso de gestión de los riesgos para la seguridad de la información). La identificación y
valoración de los activos y las evaluaciones de los efectos se examinan en el anexo B. En el anexo C se dan
ejemplos de amenazas típicas y en el anexo D se examinan las vulnerabilidades y los métodos de evaluación
de la vulnerabilidad. En el anexo E se presentan ejemplos de enfoques de evaluación de los riesgos para la
seguridad de la información.
Las limitaciones para la modificación del riesgo se presentan en el Anexo F.
Las diferencias en las definiciones entre la norma ISO/CEI 27005:2008 y la norma ISO/CEI 27005:2011
se muestran en el anexo G. Todas las actividades de gestión de riesgos presentadas desde la cláusula 7
a la cláusula 12 se estructuran de la siguiente manera:
Entrada: Identifica cualquier información necesaria para realizar la
actividad. Acción: Describe la actividad.
Orientación para la aplicación: Proporciona orientación para la realización de la acción. Algunas de estas
orientaciones pueden no ser adecuadas en todos los casos, por lo que otras formas de realizar la acción pueden
ser más apropiadas.
Salida: Identifica cualquier información derivada después de realizar la actividad.
5 Antecedentes
Es necesario un enfoque sistemático de la gestión de los riesgos para la seguridad de la información a fin de
determinar las necesidades de la organización en lo que respecta a los requisitos de seguridad de la
información y crear un sistema eficaz de gestión de la seguridad de la información (SGSI). Este enfoque debe
ser adecuado para el entorno de la organización y, en particular, debe estar en consonancia con la gestión
general de los riesgos de la empresa. Los esfuerzos en materia de seguridad deben abordar los riesgos de
manera eficaz y oportuna donde y cuando sea necesario. La gestión de los riesgos para la seguridad de la
información debe formar parte integrante de todas las actividades de gestión de la seguridad de la
información y debe aplicarse tanto a la aplicación como al funcionamiento continuo de un SGSI.
La gestión de los riesgos para la seguridad de la información debe ser un proceso continuo. El proceso debe
establecer el contexto externo e interno, evaluar los riesgos y tratarlos mediante un plan de tratamiento de
riesgos para aplicar las recomendaciones y decisiones. La gestión de riesgos analiza lo que puede suceder y
cuáles pueden ser las posibles consecuencias, antes de decidir lo que se debe hacer y cuándo, para reducir
el riesgo a un nivel aceptable.
La gestión de los riesgos para la seguridad de la información debería contribuir a lo siguiente:
 Los riesgos que se identifican

 Riesgos que se evalúan en función de sus consecuencias para el negocio y la probabilidad de que se
produzcan
 La probabilidad y las consecuencias de que esos riesgos se comuniquen y se comprendan
 Se establece un orden de prioridad para el tratamiento de riesgos
 Prioridad de las medidas para reducir los riesgos que se producen
 Participación de los interesados en la adopción de decisiones de gestión de riesgos y mantenimiento de
la información sobre la situación de la gestión de riesgos
 Eficacia de la vigilancia del tratamiento de riesgos
6 © ISO/IEC 2011 - Todos los derechos reservados

ISO/IEC 27005:2011(E)
 Los riesgos y el proceso de gestión de riesgos se vigilan y revisan periódicamente

 Información que se está captando para mejorar el enfoque de gestión de riesgos
 Se está educando a los directivos y al personal sobre los riesgos y las medidas adoptadas para mitigarlos
El proceso de gestión de riesgos para la seguridad de la información puede aplicarse a la organización en su

conjunto, a cualquier parte discreta de la organización (por ejemplo, un departamento, una ubicación física,
un servicio), a cualquier sistema de información, a aspectos de control existentes o previstos o a aspectos
particulares (por ejemplo, la planificación de la continuidad de las actividades).
6Panorama general del proceso de gestión de riesgos para la seguridad de la información

En la norma ISO 31000 se especifica una visión de alto nivel del proceso de gestión de riesgos, que se muestra en la
figura 1.
Figura 1 - El proceso de gestión de riesgos

ISO/IEC 27005:2011(E)
La figura 2 muestra cómo esta Norma Internacional aplica este proceso de gestión de riesgos.
El proceso de gestión de riesgos en materia de seguridad de la información consiste en el establecimiento del

contexto (cláusula 7), la evaluación de los riesgos (cláusula 8), el tratamiento de los riesgos (cláusula 9), la
aceptación de los riesgos (cláusula 10), la comunicación y consulta de los riesgos (cláusula 11) y la vigilancia
y el examen de los riesgos (cláusula 12).
Figura 2 - Ilustración de un proceso de gestión de riesgos para la seguridad de la información
Como se ilustra en la figura 2, el proceso de gestión de riesgos para la seguridad de la información puede ser
iterativo para las actividades de evaluación y/o tratamiento de riesgos. Un enfoque iterativo para realizar la
evaluación de riesgos puede aumentar la profundidad y el detalle de la evaluación en cada iteración. El
enfoque iterativo ofrece un buen equilibrio entre la reducción al mínimo del tiempo y el esfuerzo dedicados a
la identificación de los controles, sin dejar de garantizar que se evalúen adecuadamente los riesgos elevados.
El contexto se establece primero. Luego se realiza una evaluación del riesgo. Si ésta proporciona suficiente
información para determinar eficazmente las medidas necesarias para modificar los riesgos a un nivel
aceptable, entonces la tarea está completa y sigue el tratamiento del riesgo. Si la información es insuficiente,
se realiza otra iteración de la evaluación del riesgo con
ISO/IEC 27005:2011(E)
Se llevará a cabo una revisión del contexto (por ejemplo, los criterios de evaluación de riesgos, los
criterios de aceptación de riesgos o los criterios de impacto), posiblemente en partes limitadas del
alcance total (véase la figura 2, punto 1 de decisión sobre riesgos).
La eficacia del tratamiento de los riesgos depende de los resultados de la evaluación
de los mismos. Nótese que el tratamiento de riesgos implica un proceso cíclico de:
 evaluar un tratamiento de riesgo;
 decidir si los niveles de riesgo residual son aceptables;
 generar un nuevo tratamiento de riesgos si los niveles de riesgo no son aceptables; y
 evaluar la eficacia de ese tratamiento
Es posible que el tratamiento del riesgo no conduzca inmediatamente a un nivel aceptable de riesgo residual.
En esta situación, puede ser necesaria otra iteración de la evaluación del riesgo con parámetros de contexto
modificados (por ejemplo, evaluación del riesgo, aceptación del riesgo o criterios de impacto), de ser
necesario, seguida de un nuevo tratamiento del riesgo (véase la figura 2, punto 2 de la decisión sobre el
riesgo).
La actividad de aceptación de riesgos tiene que asegurar que los riesgos residuales sean aceptados
explícitamente por los directivos de la organización. Esto es especialmente importante en una situación en
que la aplicación de los controles se omite o se aplaza, por ejemplo, debido al costo.
Durante todo el proceso de gestión de riesgos para la seguridad de la información es importante que los
riesgos y su tratamiento se comuniquen a los directivos y el personal operacional apropiados. Incluso antes
del tratamiento de los riesgos, la información sobre los riesgos identificados puede ser muy valiosa para
gestionar los incidentes y puede ayudar a reducir los posibles daños. El conocimiento de los riesgos por parte
de los administradores y el personal, la naturaleza de los controles establecidos para mitigar los riesgos y las
esferas de interés para la organización ayudan a hacer frente a los incidentes y los acontecimientos
inesperados de la manera más eficaz. Se deben documentar los resultados detallados de cada actividad del
proceso de gestión de riesgos para la seguridad de la información y de los dos puntos de decisión sobre
riesgos.
La ISO/IEC 27001 especifica que los controles implementados dentro del alcance, los límites y el contexto del
SGSI deben basarse en el riesgo. La aplicación de un proceso de gestión de riesgos para la seguridad de la
información puede satisfacer este requisito. Hay muchos enfoques mediante los cuales el proceso puede
aplicarse con éxito en una organización. La organización debe utilizar el enfoque que mejor se adapte a sus
circunstancias para cada aplicación concreta del proceso.
En un SMIA, el establecimiento del contexto, la evaluación de los riesgos, la elaboración de un plan de

tratamiento de los riesgos y la aceptación de los riesgos forman parte de la fase de "plan". En la fase "do" del
SGSI, las medidas y controles necesarios para reducir el riesgo a un nivel aceptable se aplican de acuerdo
con el plan de tratamiento del riesgo. En la fase de "comprobación" del SGSI, los administradores
determinarán la necesidad de revisar la evaluación y el tratamiento de los riesgos a la luz de los incidentes y
los cambios de circunstancias. En la fase de "actuación" se realizan las acciones necesarias, incluida la
aplicación adicional del proceso de gestión de riesgos para la seguridad de la información.
En el cuadro siguiente se resumen las actividades de gestión de los riesgos para la seguridad de la
información correspondientes a las cuatro fases del proceso del Sistema de Gestión de la Seguridad de la
Información:
Cuadro 1 - Alineación del SGSI y el proceso de gestión de riesgos de seguridad de la información
El proceso Proceso de gestión de riesgos para la

del SGSI seguridad de la información
Establecimiento del
contexto Evaluación del
Plan
riesgo
Desarrollo de un plan de tratamiento de riesgos
Aceptación del riesgo
Haz Aplicación del plan de tratamiento de riesgos
Revisa Vigilancia y examen continuos de los riesgos
Mantener y mejorar el proceso de gestión de
Actúa riesgos para la seguridad de la
información

ISO/IEC 27005:2011(E)
7 Establecimiento del contexto
7.1 Consideraciones generales

Entrada: Toda la información sobre la organización pertinente para el establecimiento del contexto de gestión
de riesgos para la seguridad de la información.
Acción: Se debe establecer el contexto externo e interno de la gestión de los riesgos para la seguridad de la
información, lo que entraña fijar los criterios básicos necesarios para la gestión de los riesgos para la
seguridad de la información (7.2), definir el alcance y los límites (7.3) y establecer una organización adecuada
que se encargue de la gestión de los riesgos para la seguridad de la información (7.4).
Orientación para la aplicación:
Es esencial determinar el propósito de la gestión de los riesgos para la seguridad de la información, ya que ello
afecta al proceso general y al establecimiento del contexto en particular. Este propósito puede ser
 Apoyar un ISMS
 Cumplimiento legal y prueba de la diligencia debida
 Preparación de un plan de continuidad de las actividades
 Preparación de un plan de respuesta a incidentes
 Descripción de los requisitos de seguridad de la información para un producto, un servicio o un mecanismo
Las orientaciones para la aplicación de los elementos de establecimiento del contexto necesarios para apoyar
un SGSI se examinan con más detalle en las cláusulas 7.2, 7.3 y 7.4 infra.
NOTA La norma ISO/CEI 27001:2005 no utiliza el término "contexto". Sin embargo, toda la Cláusula 7 se refiere a los
requisitos de "definir el alcance y los límites del SGSI" [4.2.1 a)], "definir una política de SGSI" [4.2.1 b)] y "definir el
enfoque de evaluación del riesgo" [4.2.1 c)], especificados en la norma ISO/CEI 27001:2005.
Salida: La especificación de los criterios básicos, el alcance y los límites, y la organización del proceso de
gestión de riesgos para la seguridad de la información.
7.2 Criterios básicos
7.2.1 Enfoque de gestión de riesgos
Según el alcance y los objetivos de la gestión de riesgos, pueden aplicarse diferentes enfoques. El enfoque
también puede ser diferente para cada iteración.
Debe seleccionarse o elaborarse un enfoque apropiado de gestión de riesgos que aborde criterios básicos
como: criterios de evaluación de riesgos, criterios de impacto, criterios de aceptación de riesgos.
Además, la organización debería evaluar si se dispone de los recursos necesarios para ello:
 Realizar una evaluación de riesgos y establecer un plan de tratamiento de riesgos

 Definir y aplicar políticas y procedimientos, incluida la aplicación de los controles seleccionados
 Controles de monitorización
 Supervisar el proceso de gestión de los riesgos para la seguridad de la información
NOTA Véase también la norma ISO/CEI 27001:2005 (cláusula 5.2.1) relativa a la provisión de recursos para la
aplicación y el funcionamiento de un SGSI.
7.2.2 Criterios de evaluación de riesgos
Se deben elaborar criterios de evaluación de riesgos para evaluar el riesgo de la seguridad de la información
de la organización teniendo en cuenta lo siguiente
 El valor estratégico del proceso de información comercial

 La criticidad de los activos de información involucrados
 Requisitos legales y reglamentarios y obligaciones contractuales

ISO/IEC 27005:2011(E)
 Importancia operacional y comercial de la disponibilidad, la confidencialidad y la integridad

 Expectativas y percepciones de los interesados y consecuencias negativas para la buena voluntad
y la reputación Además, se pueden utilizar criterios de evaluación de riesgos para especificar las
prioridades del tratamiento de los riesgos.
7.2.3 Criterios de impacto
Los criterios de impacto deben elaborarse y especificarse en función del grado de daño o los costos para la
organización causados por un evento de seguridad de la información, teniendo en cuenta lo siguiente
 Nivel de clasificación del activo de información impactado

 Violaciones de la seguridad de la información (por ejemplo, pérdida de confidencialidad, integridad y
disponibilidad)
 Operaciones deterioradas (internas o de terceros)
 Pérdida de valor comercial y financiero
 Interrupción de planes y plazos
 Daño a la reputación
 Incumplimientos de los requisitos legales, reglamentarios o contractuales
NOTA Véase también ISO/CEI 27001:2005 [Cláusula 4.2.1 d) 4] en relación con la identificación de los criterios de
impacto de las pérdidas de confidencialidad, integridad y disponibilidad.
7.2.4 Criterios de aceptación del riesgo
Se deben elaborar y especificar criterios de aceptación de riesgos. Los criterios de aceptación del riesgo
suelen depender de las políticas, las metas, los objetivos y los intereses de las partes interesadas de la
organización.
Una organización debe definir sus propias escalas de niveles de aceptación de riesgos. Durante su
elaboración se debería tener en cuenta lo siguiente
 Los criterios de aceptación del riesgo pueden incluir múltiples umbrales, con un nivel de riesgo objetivo
deseado, pero se prevé que el personal directivo superior acepte los riesgos por encima de este nivel en
circunstancias definidas
 Los criterios de aceptación del riesgo pueden expresarse como la relación entre el beneficio estimado (u
otro beneficio comercial) y el riesgo estimado
 Es posible que se apliquen diferentes criterios de aceptación de riesgos a diferentes clases de riesgos,
por ejemplo, es posible que no se acepten los riesgos que podrían dar lugar al incumplimiento de
reglamentos o leyes, mientras que puede permitirse la aceptación de riesgos elevados si ello se
especifica como requisito contractual
 Los criterios de aceptación del riesgo pueden incluir requisitos para un futuro tratamiento adicional, por
ejemplo, se puede aceptar un riesgo si hay aprobación y compromiso de tomar medidas para reducirlo a
un nivel aceptable dentro de un período de tiempo definido
Los criterios de aceptación del riesgo pueden diferir según el tiempo que se prevea que exista el riesgo, por
ejemplo, el riesgo puede estar asociado a una actividad temporal o a corto plazo. Los criterios de aceptación
del riesgo deben establecerse teniendo en cuenta lo siguiente
 Criterios comerciales
 Aspectos jurídicos y reglamentarios
 Operaciones
 Tecnología
 Finanzas
 Factores sociales y humanitarios
NOTA Los criterios de aceptación de riesgos corresponden a los "criterios de aceptación de riesgos e identificación del
nivel de riesgo aceptable" especificados en la norma ISO/CEI 27001:2005, cláusula 4.2.1 c) 2).
En el Anexo A se puede encontrar más información.

ISO/IEC 27005:2011(E)
7.3 Alcance y límites
La organización debe definir el alcance y los límites de la gestión de los riesgos para la seguridad de la información.
Es necesario definir el alcance del proceso de gestión de riesgos para la seguridad de la información a fin de
garantizar que todos los activos pertinentes se tengan en cuenta en la evaluación del riesgo. Además, es
necesario identificar los límites [véase también la norma ISO/CEI 27001:2005, cláusula 4.2.1 a)] para
abordar los riesgos que podrían surgir a través de esos límites.
Se debe reunir información sobre la organización para determinar el entorno en que opera y su pertinencia
para el proceso de gestión de los riesgos para la seguridad de la información.
Al definir el alcance y los límites, la organización debería tener en cuenta la siguiente información:
 Los objetivos, estrategias y políticas empresariales estratégicos de la organización

 Procesos de negocio
 Las funciones y la estructura de la organización
 Requisitos legales, reglamentarios y contractuales aplicables a la organización
 La política de seguridad de la información de la organización
 El enfoque general de la organización en materia de gestión de riesgos
 Los activos de información
 Ubicación de la organización y sus características geográficas
 Limitaciones que afectan a la organización
 Expectativas de los interesados
 Entorno sociocultural
 Interfaces (es decir, intercambio de información con el medio ambiente)
Además, la organización debe justificar toda exclusión del ámbito de aplicación.
Ejemplos del ámbito de la gestión de riesgos pueden ser una aplicación informática, una infraestructura de TI,
un proceso empresarial o una parte definida de una organización.
NOTA El alcance y los límites de la gestión de riesgos para la seguridad de la información están relacionados con el
alcance y los límites del SGSI exigidos en la norma ISO/CEI 27001:2005 4.2.1 a).
En el Anexo A se puede encontrar más información al respecto.
7.4 Organización para la gestión de los riesgos de la seguridad de la información
Se debe establecer y mantener la organización y las responsabilidades del proceso de gestión de los riesgos
para la seguridad de la información. A continuación se indican las principales funciones y responsabilidades
de esta organización:
 Desarrollo del proceso de gestión de riesgos para la seguridad de la información adecuado para la organización
 Identificación y análisis de las partes interesadas
 Definición de las funciones y responsabilidades de todas las partes, tanto internas como externas a la organización
 Establecimiento de las relaciones necesarias entre la organización y los interesados, así como de las
interfaces con las funciones de gestión de riesgos de alto nivel de la organización (por ejemplo, la gestión
de riesgos operacionales), así como las interfaces con otros proyectos o actividades pertinentes
 Definición de las vías de escalada de decisiones
 Especificación de los registros que deben mantenerse
Esta organización debe ser aprobada por los directores apropiados de la organización.
NOTA La norma ISO/CEI 27001:2005 exige la determinación y provisión de los recursos necesarios para establecer,
implementar, operar, supervisar, revisar, mantener y mejorar un SGSI [5.2.1 a)]. La organización para las operaciones de
gestión de riesgos puede considerarse como uno de los recursos requeridos por la ISO/CEI 27001:2005.
ISO/IEC 27005:2011(E)
8 Evaluación de los riesgos para la seguridad de la información
8.1 Descripción general de la evaluación de los riesgos para la seguridad de la información
NOTE La actividad de evaluación de riesgos se denomina proceso en la norma ISO/IEC 27001:2005.
Entrada: Criterios básicos, el alcance y los límites y la organización del proceso de gestión de riesgos
para la seguridad de la información que se está estableciendo.
Acción: Los riesgos deben identificarse, cuantificarse o describirse cualitativamente, y se debe establecer un
orden de prioridad en función de los criterios de evaluación de riesgos y los objetivos pertinentes de la
organización.
Un riesgo es una combinación de las consecuencias que se derivarían de la ocurrencia de un evento no

deseado y la probabilidad de que ocurra. La evaluación del riesgo cuantifica o describe cualitativamente el
riesgo y permite a los administradores establecer un orden de prioridad de los riesgos en función de su
gravedad percibida o de otros criterios establecidos.
La evaluación del riesgo consiste en las siguientes actividades:
 Identificación de riesgos (cláusula 8.2)

 Análisis de riesgos (cláusula 8.3)
 Evaluación del riesgo (cláusula 8.4)
La evaluación del riesgo determina el valor de los activos de información, identifica las amenazas y
vulnerabilidades aplicables que existen (o podrían existir), identifica los controles existentes y su efecto en el
riesgo identificado, determina las posibles consecuencias y, por último, prioriza los riesgos derivados y los
clasifica en función de los criterios de evaluación del riesgo establecidos en el establecimiento del contexto.
La evaluación de los riesgos suele realizarse en dos (o más) iteraciones. En primer lugar se realiza una
evaluación de alto nivel para determinar los riesgos potencialmente elevados que merecen una evaluación
más a fondo. La siguiente iteración puede entrañar un examen más a fondo de los riesgos potencialmente
altos revelados en la iteración inicial. Cuando esto no proporciona información suficiente para evaluar el
riesgo, se realizan entonces análisis más detallados, probablemente en partes del alcance total, y
posiblemente utilizando un método diferente.
Corresponde a la organización seleccionar su propio enfoque de la evaluación de riesgos basándose en los

objetivos y la finalidad de la evaluación de riesgos.
En el anexo E se analizan los enfoques de la evaluación de los riesgos para la seguridad
de la información: Una lista de los riesgos evaluados, clasificados por orden de prioridad
según los criterios de evaluación de los riesgos.
8.2 Identificación de riesgos
8.2.1 Introducción a la identificación de riesgos
El propósito de la identificación de riesgos es determinar lo que podría suceder para causar una pérdida
potencial, y comprender cómo, dónde y por qué podría ocurrir la pérdida. Los pasos descritos en las
siguientes subcláusulas de la sección 8.2 deben recoger datos de entrada para la actividad de análisis de
riesgos.
La identificación del riesgo debe incluir los riesgos independientemente de que su fuente esté o no bajo el
control de la organización, aunque la fuente o la causa del riesgo no sea evidente.
NOTE Las actividades descritas en cláusulas posteriores pueden realizarse en un orden diferente según la
metodología aplicada.
ISO/IEC 27005:2011(E)
8.2.2 Identificación de los activos
Entrada: Alcance y límites de la evaluación de riesgos que se va a realizar, lista de componentes con sus
propietarios, ubicación, función, etc.
Acción: Se deben identificar los activos dentro del ámbito establecido (se refiere a la norma ISO/IEC
27001:2005, cláusula 4.2.1 d) 1)).
Un activo es cualquier cosa que tenga valor para la organización y que, por lo tanto, requiera protección. Para
la identificación de los activos debe tenerse en cuenta que un sistema de información consiste en algo más
que hardware y software.
La identificación de los activos debe realizarse con un nivel de detalle adecuado que proporcione información
suficiente para la evaluación del riesgo. El nivel de detalle utilizado en la identificación de los activos influirá
en la cantidad total de información reunida durante la evaluación de los riesgos. El nivel puede perfeccionarse
en iteraciones posteriores de la evaluación de riesgos.
Se debe identificar a un propietario de cada activo, para que asuma la responsabilidad y la rendición de
cuentas del mismo. El propietario del activo puede no tener derechos de propiedad sobre el mismo, pero
tiene la responsabilidad de su producción, desarrollo, mantenimiento, utilización y seguridad, según proceda.
El propietario del activo suele ser la persona más idónea para determinar el valor del activo para la
organización (véase el apartado 8.3.2 para la valoración del activo).
El límite de revisión es el perímetro de activos de la organización definido para ser administrado por el
proceso de gestión de riesgos para la seguridad de la información.
En el anexo B se puede encontrar más información sobre la identificación y valoración de los activos en
relación con la seguridad de la información.
Salida: Una lista de los activos que deben ser objeto de gestión de riesgos y una lista de los procesos
comerciales relacionados con los activos y su pertinencia.
8.2.3 Identificación de las amenazas
Entrada: Información sobre las amenazas obtenidas de la revisión de incidentes, los propietarios de los
activos, los usuarios y otras fuentes, incluidos los catálogos de amenazas externas.
Acción: Se deben identificar las amenazas y sus fuentes (se refiere a la norma ISO/IEC 27001:2005,
Cláusula 4.2.1 d) 2)). Orientación para la aplicación:
Una amenaza tiene el potencial de dañar bienes tales como la información, los procesos y los sistemas y, por
consiguiente, las organizaciones. Las amenazas pueden ser de origen natural o humano y pueden ser
accidentales o deliberadas. Se deben identificar tanto las fuentes de amenazas accidentales como las
deliberadas. Una amenaza puede surgir de dentro o de fuera de la organización. Las amenazas deben
identificarse de manera genérica y por tipo (por ejemplo, acciones no autorizadas, daños físicos, fallos
técnicos) y luego, cuando proceda, las amenazas individuales dentro de la clase genérica identificada. Esto
significa que no se pasa por alto ninguna amenaza, incluidas las inesperadas, pero que el volumen de trabajo
necesario es limitado.
Algunas amenazas pueden afectar a más de un activo. En tales casos pueden causar diferentes impactos
dependiendo de los bienes afectados.
Los datos para la identificación de la amenaza y la estimación de la probabilidad de que ocurra (véase 8.3.3)
pueden obtenerse de los propietarios o usuarios de los bienes, del personal de recursos humanos, de los
especialistas en gestión de instalaciones y seguridad de la información, de los expertos en seguridad física,
del departamento jurídico y de otras organizaciones, incluidos los órganos jurídicos, las autoridades
meteorológicas, las compañías de seguros y las autoridades gubernamentales nacionales. Al abordar las
amenazas también deben tenerse en cuenta los aspectos del medio ambiente y la cultura.
ISO/IEC 27005:2011(E)
La experiencia interna de los incidentes y las evaluaciones de amenazas pasadas deben tenerse en cuenta
en la evaluación actual. Tal vez valga la pena consultar otros catálogos de amenazas (tal vez específicos de
una organización o empresa) para completar la lista de amenazas genéricas, cuando sea pertinente. Los
catálogos y estadísticas de amenazas pueden obtenerse en los organismos industriales, los gobiernos
nacionales, los órganos jurídicos, las compañías de seguros, etc.
Al utilizar los catálogos de amenazas, o los resultados de evaluaciones anteriores de amenazas, hay que
tener en cuenta que hay un cambio continuo de las amenazas pertinentes, especialmente si cambia el
entorno empresarial o los sistemas de información.
En el Anexo C se puede encontrar más información sobre los tipos de amenazas.
Salida: Una lista de amenazas con la identificación del tipo y la fuente de la amenaza.
8.2.4 Identificación de los controles existentes
Entrada: Documentación de los controles, planes de aplicación del
tratamiento de riesgos. Acción: Se deben identificar los controles
existentes y previstos.
Se deben identificar los controles existentes para evitar el trabajo o los costos innecesarios, por ejemplo, en
la duplicación de los controles. Además, al tiempo que se identifican los controles existentes, debe hacerse
una comprobación para asegurar que los controles funcionan correctamente; la referencia a los informes de
auditoría del Sistema de Gestión Integrada de la Seguridad (SGSI) ya existentes debe limitar el tiempo
dedicado a esta tarea. Si un control no funciona como se espera, esto puede causar vulnerabilidades. Se
debe considerar la situación en que un control (o estrategia) seleccionado falla en su funcionamiento y, por lo
tanto, se requieren controles complementarios para abordar eficazmente el riesgo identificado. En un SGSI,
de acuerdo con la norma ISO/IEC 27001, esto se apoya en la medición de la eficacia del control. Una forma
de estimar el efecto del control es ver cómo reduce la probabilidad de la amenaza y la facilidad de explotar la
vulnerabilidad, o el impacto del incidente. Los exámenes de la administración y los informes de auditoría
también proporcionan información sobre la eficacia de los controles existentes.
Los controles que se prevé aplicar de conformidad con los planes de aplicación del tratamiento de riesgos
deben considerarse de la misma manera que los que ya se han aplicado.
Un control existente o planificado podría ser considerado ineficaz, o insuficiente, o no justificado. Si no está
justificado o no es suficiente, el control debe ser comprobado para determinar si debe ser eliminado,
sustituido por otro control más adecuado, o si debe permanecer en su lugar, por ejemplo, por razones de
costo.
Para la identificación de los controles existentes o previstos, las siguientes actividades pueden ser útiles:
 Revisar los documentos que contienen información sobre los controles (por ejemplo, los planes de
aplicación del tratamiento de riesgos). Si los procesos de gestión de la seguridad de la información están
bien documentados, todos los controles existentes o previstos y el estado de su aplicación deben estar
disponibles;
 Comprobar con las personas responsables de la seguridad de la información (por ejemplo, el oficial de
seguridad de la información y el oficial de seguridad de los sistemas de información, el administrador del
edificio o el gerente de operaciones) y los usuarios qué controles se aplican realmente al proceso de
información o al sistema de información de que se trate;
 Realizar un examen in situ de los controles físicos, comparando los aplicados con la lista de los controles
que deberían existir y comprobando los aplicados para ver si funcionan correcta y eficazmente, o
 Examen de los resultados de las auditorías
Salida: Una lista de todos los controles existentes y previstos, su aplicación y estado de utilización.
8.2.5 Identificación de vulnerabilidades

Entrada: Una lista de amenazas conocidas, listas de bienes y controles existentes.
Acción: Se deben identificar las vulnerabilidades que pueden ser explotadas por amenazas de causar daños
a los activos o a la organización (se relaciona con la norma ISO/CEI 27001:2005, Cláusula 4.2.1 d) 3)).

Material con derechos de autor licenciado al Instituto de Tecnología de Dublín por SAI Global (www.saiglobal.com), descargado el 31 de diciembre 11 por
Ann McSweeney.
ISO/IEC 27005:2011(E)
Las vulnerabilidades pueden identificarse en las siguientes áreas:
 Organización
 Procesos y procedimientos
 Rutinas de gestión
 Personal
 El entorno físico
 Configuración del sistema de información
 Hardware, software o equipo de comunicaciones
 Dependencia de partes externas
La presencia de una vulnerabilidad no causa daño en sí misma, ya que es necesario que exista una amenaza
para explotarla. Una vulnerabilidad que no tenga una amenaza correspondiente tal vez no requiera la
aplicación de un control, pero debe reconocerse y vigilarse para detectar cambios. Cabe señalar que un
control aplicado incorrectamente o que funcione mal, o un control que se utilice incorrectamente, podría ser
en sí mismo una vulnerabilidad. Un control puede ser eficaz o ineficaz según el entorno en que funcione. A la
inversa, una amenaza que no tenga una vulnerabilidad correspondiente puede no dar lugar a un riesgo.
Las vulnerabilidades pueden estar relacionadas con las propiedades del activo que pueden utilizarse de una
manera, o con un propósito, distinto del previsto cuando se compró o fabricó el activo. Es necesario
considerar las vulnerabilidades que surgen de diferentes fuentes, por ejemplo, las intrínsecas o extrínsecas al
activo.
En el anexo D figuran ejemplos de vulnerabilidades y métodos de evaluación de la vulnerabilidad.
Salida: Una lista de vulnerabilidades en relación con los activos, las amenazas y los controles; una lista de
vulnerabilidades que no se relacionan con ninguna amenaza identificada para su examen.
8.2.6 Identificación de las consecuencias
Entrada: Una lista de activos, una lista de procesos comerciales y una lista de amenazas y vulnerabilidades,
cuando proceda, relacionadas con los activos y su pertinencia.
Acción: Se deben identificar las consecuencias que las pérdidas de confidencialidad, integridad y
disponibilidad pueden tener sobre los activos (véase ISO/CEI 27001:2005 4.2.1 d) 4)).
Una consecuencia puede ser la pérdida de eficacia, condiciones operativas adversas, pérdida de negocios,
reputación, daños, etc.
Esta actividad identifica el daño o las consecuencias para la organización que podría causar un escenario de
incidente. Un escenario de incidente es la descripción de una amenaza que explota una cierta vulnerabilidad
o conjunto de vulnerabilidades en un incidente de seguridad de la información (véase la norma ISO/CEI
27002:2005, cláusula 13). El impacto de los escenarios de incidentes debe determinarse teniendo en cuenta
los criterios de impacto definidos durante la actividad de establecimiento del contexto. Puede afectar a uno o
más bienes o a parte de un bien. Así pues, los activos pueden tener asignados valores tanto por su costo
financiero como por las consecuencias comerciales si resultan dañados o comprometidos. Las consecuencias
pueden ser de carácter temporal o pueden ser permanentes como en el caso de la destrucción de un activo.
NOTA ISO/IEC 27001:2005 describe la ocurrencia de escenarios de incidentes como "fallas de seguridad".
Las organizaciones deben identificar las consecuencias operacionales de los escenarios de incidentes en
términos de (pero no limitados a):
 Investigación y tiempo de reparación

 (Trabajo) tiempo perdido
 Oportunidad perdida
No se permite ninguna otra reproducción o distribución. No se controla cuando

se imprime.
Ann McSweeney.

se imprime.
ISO/IEC 27005:2011(E)
 Salud y seguridad
 El costo financiero de las habilidades específicas para reparar el daño
 La reputación de la imagen y la buena voluntad
Los detalles sobre la evaluación de las vulnerabilidades técnicas se encuentran en B.3 Evaluación del impacto.
Salida: Una lista de escenarios de incidentes con sus consecuencias relacionadas con los activos y los procesos
comerciales.
8.3 Análisis de riesgo
8.3.1 Metodologías de análisis de riesgos
El análisis de riesgos puede realizarse con diversos grados de detalle, dependiendo de la criticidad de los
activos, el alcance de las vulnerabilidades conocidas y los incidentes anteriores que se produzcan en la
organización. La metodología de análisis de riesgos puede ser cualitativa o cuantitativa, o una combinación
de ellas, según las circunstancias. En la práctica, el análisis cualitativo suele utilizarse en primer lugar para
obtener una indicación general del nivel de riesgo y revelar los principales riesgos. Posteriormente puede ser
necesario realizar un análisis más específico o cuantitativo de los principales riesgos porque suele ser menos
complejo y menos costoso realizar un análisis cualitativo que uno cuantitativo.
La forma de análisis debe ser coherente con los criterios de evaluación de riesgos elaborados como parte del
establecimiento del contexto.
A continuación se describen más detalles de las metodologías de análisis:
(a) Análisis cualitativo de riesgos:
El análisis de riesgos cualitativo utiliza una escala de atributos calificativos para describir la magnitud de las
posibles consecuencias (por ejemplo, baja, media y alta) y la probabilidad de que éstas se produzcan. Una
ventaja del análisis cualitativo es su facilidad de comprensión por todo el personal pertinente, mientras que
una desventaja es la dependencia de la elección subjetiva de la escala.
Estas escalas pueden adaptarse o ajustarse a las circunstancias y pueden utilizarse diferentes descripciones
para diferentes riesgos. Se puede utilizar un análisis cualitativo de los riesgos:
 Como actividad inicial de selección para identificar los riesgos que requieren un análisis más detallado
 Cuando este tipo de análisis es apropiado para las decisiones
 Cuando los datos numéricos o los recursos sean inadecuados para un análisis de
riesgos cuantitativo, el análisis cualitativo deberá utilizar información y datos fácticos
cuando estén disponibles.
(b) Análisis cuantitativo de riesgos:
El análisis cuantitativo de riesgos utiliza una escala con valores numéricos (en lugar de las escalas
descriptivas utilizadas en el análisis cualitativo de riesgos) tanto para las consecuencias como para la
probabilidad, utilizando datos de diversas fuentes. La calidad del análisis depende de la exactitud e integridad
de los valores numéricos y de la validez de los modelos utilizados. En la mayoría de los casos, el análisis
cuantitativo de los riesgos utiliza datos históricos de los incidentes, lo que ofrece la ventaja de que puede
relacionarse directamente con los objetivos y preocupaciones de la organización en materia de seguridad de
la información. Una desventaja es la falta de esos datos sobre los nuevos riesgos o las deficiencias de la
seguridad de la información. Una desventaja del enfoque cuantitativo puede producirse cuando no se dispone
de datos factuales y auditables, lo que crea una ilusión de valor y precisión de la evaluación del riesgo.
La forma en que se expresan las consecuencias y la probabilidad y las maneras en que se combinan para
proporcionar un nivel de riesgo variarán según el tipo de riesgo y el propósito con el que se utilizará el
resultado de la evaluación del riesgo. La incertidumbre y la variabilidad tanto de las consecuencias como de
la probabilidad deben tenerse en cuenta en el análisis y comunicarse eficazmente.
ISO/IEC 27005:2011(E)
8.3.2 Evaluación de las consecuencias
Entrada: Una lista de los escenarios de incidentes pertinentes identificados, incluida la identificación de
amenazas, vulnerabilidades, activos afectados, consecuencias para los activos y procesos comerciales.
Acción: Se debe evaluar el impacto comercial en la organización que podría resultar de los incidentes de
seguridad de la información posibles o reales, teniendo en cuenta las consecuencias de una violación de la
seguridad de la información, como la pérdida de confidencialidad, integridad o disponibilidad de los activos
(se refiere a la norma ISO/CEI 27001:2005, Cláusula 4.2.1 e) 1)).
Guía de aplicación:
Tras identificar todos los bienes objeto de examen, los valores asignados a esos bienes deben tenerse en
cuenta al evaluar las consecuencias.
El valor de impacto comercial puede expresarse en forma cualitativa y cuantitativa, pero cualquier método de
asignación de valor monetario puede en general proporcionar más información para la adopción de
decisiones y, por lo tanto, facilitar un proceso de adopción de decisiones más eficiente.
La valoración de los activos comienza con la clasificación de los mismos según su criticidad, en términos de
la importancia de los activos para el cumplimiento de los objetivos comerciales de la organización. A
continuación, la valoración se determina utilizando dos medidas:
 el valor de reemplazo del activo: el costo de la recuperación, limpieza y reemplazo de la información (si
es posible), y
 las consecuencias comerciales de la pérdida o el compromiso del activo, como las posibles
consecuencias comerciales y/o jurídicas o reglamentarias adversas de la divulgación, modificación, no
disponibilidad y/o destrucción de la información, y otros activos de información
Esta valoración puede determinarse a partir de un análisis del impacto comercial. El valor, determinado por la
consecuencia para las empresas, suele ser considerablemente mayor que el simple costo de sustitución,
dependiendo de la importancia del activo para la organización en el cumplimiento de sus objetivos
comerciales.
La valoración de los activos es un factor clave en la evaluación del impacto de un escenario de incidente,
porque el incidente puede afectar a más de un activo (por ejemplo, los activos dependientes), o sólo a una
parte de un activo. Diferentes amenazas y vulnerabilidades tendrán diferentes repercusiones en los activos,
como la pérdida de confidencialidad, integridad o disponibilidad. Por consiguiente, la evaluación de las
consecuencias está relacionada con la valoración de los activos basada en el análisis del impacto comercial.
Las consecuencias o el impacto comercial pueden determinarse mediante la modelización de los resultados
de un evento o conjunto de eventos, o mediante la extrapolación de estudios experimentales o datos
anteriores.
Las consecuencias pueden expresarse en términos de criterios de impacto monetario, técnico o humano, u
otros criterios pertinentes para la organización. En algunos casos, se requiere más de un valor numérico para
especificar las consecuencias en diferentes momentos, lugares, grupos o situaciones.
Las consecuencias en el tiempo y en la financiación deben medirse con el mismo enfoque utilizado para la
probabilidad de amenaza y la vulnerabilidad. Debe mantenerse la coherencia en el enfoque cuantitativo o
cualitativo.
En el anexo B se puede encontrar más información tanto sobre la valoración de los activos como sobre la evaluación de los
efectos.
Salida: Una lista de las consecuencias evaluadas de un escenario de incidente expresadas con respecto a
los bienes y los criterios de impacto.
8.3.3 Evaluación de la probabilidad de incidentes
Entrada: Una lista de los escenarios de incidentes pertinentes identificados, incluida la identificación de las
amenazas, los activos afectados, las vulnerabilidades explotadas y las consecuencias para los activos y los
procesos comerciales. Además, listas de todos los controles existentes y previstos, su eficacia, su aplicación
y su estado de utilización.

ISO/IEC 27005:2011(E)
Acción: Se debe evaluar la probabilidad de los escenarios de incidentes (se relaciona con la norma ISO/IEC
27001:2005, Cláusula 4.2.1 e) 2)).
Después de identificar los escenarios de incidentes, es necesario evaluar la probabilidad de que se produzca
cada escenario y el impacto, utilizando técnicas de análisis cualitativo o cuantitativo. Para ello se debe tener
en cuenta la frecuencia con que se producen las amenazas y la facilidad con que se pueden explotar las
vulnerabilidades, considerando:
 experiencia y estadísticas aplicables a la probabilidad de amenaza

 para las fuentes de amenazas deliberadas: la motivación y las capacidades, que cambiarán con el
tiempo, y los recursos disponibles para los posibles atacantes, así como la percepción del atractivo y la
vulnerabilidad de los bienes para un posible atacante
 para las fuentes de amenazas accidentales: factores geográficos, por ejemplo, la proximidad a plantas
químicas o petrolíferas, la posibilidad de condiciones climáticas extremas y los factores que podrían influir
en los errores humanos y el mal funcionamiento del equipo
 vulnerabilidades, tanto individuales como en conjunto
 los controles existentes y la eficacia con que reducen las vulnerabilidades
Por ejemplo, un sistema de información puede ser vulnerable a las amenazas de encubrimiento de la
identidad del usuario y al uso indebido de los recursos. La vulnerabilidad de la ocultación de la identidad del
usuario puede ser elevada debido a la falta de autenticación del usuario. Por otra parte, la probabilidad de
que se utilicen indebidamente los recursos puede ser baja, a pesar de la falta de autenticación del usuario,
porque las formas de utilizar indebidamente los recursos son limitadas.
Según la necesidad de precisión, los bienes podrían agruparse, o podría ser necesario dividirlos en sus
elementos y relacionar los escenarios con los elementos. Por ejemplo, en función de la ubicación geográfica,
la naturaleza de las amenazas a los mismos tipos de bienes puede cambiar, o la eficacia de los controles
existentes puede variar.
Salida: Probabilidad de escenarios de incidentes (cuantitativos o cualitativos).
8.3.4 Determinación del nivel de riesgo
Entrada: Una lista de escenarios de incidentes con sus consecuencias relacionadas con los bienes y
procesos comerciales y su probabilidad (cuantitativa o cualitativa).
Acción: El nivel de riesgo debe determinarse para todos los escenarios de incidentes pertinentes (se
relaciona con la norma ISO/IEC 27001:2005, Cláusula 4.2.1 e) 4)).
El análisis de riesgos asigna valores a la probabilidad y a las consecuencias de un riesgo. Estos valores
pueden ser cuantitativos o cualitativos. El análisis de riesgos se basa en la evaluación de las consecuencias y
la probabilidad. Además, puede tener en cuenta la relación costo-beneficio, las preocupaciones de los
interesados y otras variables, según proceda para la evaluación del riesgo. El riesgo estimado es una
combinación de la probabilidad de un escenario de incidente y sus consecuencias.
En el anexo E se presentan ejemplos de diferentes métodos o enfoques de análisis de los riesgos para
la seguridad de la información: Una lista de riesgos con niveles de valor asignados.
8.4 Evaluación del riesgo
Entrada: Una lista de riesgos con niveles de valor asignados y criterios de evaluación de riesgos.
Acción: El nivel de riesgos debe compararse con los criterios de evaluación de riesgos y los criterios de
aceptación de riesgos (se relaciona con la norma ISO/CEI 27001:2005, Cláusula 4.2.1 e) 4)).
ISO/IEC 27005:2011(E)
La naturaleza de las decisiones relativas a la evaluación de los riesgos y los criterios de evaluación de los
riesgos que se utilizarán para adoptar esas decisiones se habría decidido al establecer el contexto. Esas
decisiones y el contexto deberían volver a examinarse con más detalle en esta etapa, cuando se conozcan
mejor los riesgos concretos identificados. Para evaluar los riesgos, las organizaciones deberían comparar los
riesgos estimados (utilizando métodos o enfoques seleccionados, como se indica en el anexo E) con los
criterios de evaluación de riesgos definidos durante el establecimiento del contexto.
Los criterios de evaluación de riesgos utilizados para tomar decisiones deben ser coherentes con el contexto
definido de gestión de riesgos para la seguridad de la información externa e interna y tener en cuenta los
objetivos de la organización y las opiniones de los interesados, etc. Las decisiones adoptadas en la actividad
de evaluación de riesgos se basan principalmente en el nivel de riesgo aceptable. Sin embargo, también
deben tenerse en cuenta las consecuencias, la probabilidad y el grado de confianza en la identificación y el
análisis de los riesgos. La suma de múltiples riesgos bajos o medios puede dar lugar a riesgos generales
mucho más elevados y es necesario abordarlos en consecuencia.
Las consideraciones deben incluir:
 Propiedades de la seguridad de la información: si un criterio no es pertinente para la organización (por

ejemplo, la pérdida de confidencialidad), entonces todos los riesgos que afectan a este criterio pueden no
ser pertinentes
 La importancia del proceso o actividad comercial que se apoya en un determinado activo o conjunto de
activos: si se determina que el proceso es de baja importancia, los riesgos asociados a él deben recibir
una consideración menor que los riesgos que afectan a procesos o actividades más importantes
La evaluación de riesgos utiliza la comprensión del riesgo obtenida mediante el análisis de riesgos para tomar
decisiones sobre acciones futuras. Las decisiones deben incluir
 Si se debe realizar una actividad

 Prioridades del tratamiento de riesgos considerando los niveles de riesgo estimados
Durante la etapa de evaluación de los riesgos, los requisitos contractuales, jurídicos y reglamentarios son
factores que deben tenerse en cuenta además de los riesgos estimados.
Salida: Una lista de riesgos priorizados según los criterios de evaluación de riesgos en relación con las
hipótesis de incidentes que dan lugar a esos riesgos.
9 Tratamiento de los riesgos para la seguridad de la información
9.1 Descripción general del tratamiento de riesgos
Entrada: Una lista de riesgos priorizados según los criterios de evaluación de riesgos en relación con las
hipótesis de incidentes que dan lugar a esos riesgos.
Acción: Se deben seleccionar controles para reducir, retener, evitar o compartir los riesgos y se debe definir
un plan de tratamiento de riesgos.
Hay cuatro opciones disponibles para el tratamiento de los riesgos: modificación del riesgo (véase 9.2),
retención del riesgo (véase 9.3), evitación del riesgo (véase 9.4) y distribución del riesgo (véase 9.5).
NOTA ISO/CEI 27001:2005 4.2.1. f) 2) utiliza el término "aceptar el riesgo" en lugar de "retención del riesgo".
En la figura 3 se ilustra la actividad de tratamiento de riesgos dentro del proceso de gestión de riesgos para la
seguridad de la información que se presenta en la figura 2.
ISO/IEC 27005:2011(E)
Figura 3 - La actividad de tratamiento de riesgos
Las opciones de tratamiento de riesgos deben seleccionarse sobre la base del resultado de la evaluación de
los riesgos, el costo previsto de la aplicación de esas opciones y los beneficios previstos de esas opciones.
Cuando se puedan obtener grandes reducciones de los riesgos con un gasto relativamente bajo, se deben
aplicar esas opciones. Otras opciones de mejora pueden ser poco económicas y es necesario juzgar si son
justificables.
En general, las consecuencias adversas de los riesgos deben ser tan bajas como sea razonablemente
posible e independientemente de cualquier criterio absoluto. Los administradores deben considerar los
riesgos raros pero graves. En esos casos, tal vez sea necesario aplicar controles que no se justifiquen por
motivos estrictamente económicos (por ejemplo, los controles de continuidad de las operaciones que se
considere que cubren riesgos elevados específicos).
ISO/IEC 27005:2011(E)
Las cuatro opciones de tratamiento del riesgo no se excluyen mutuamente. A veces la organización puede
beneficiarse sustancialmente con una combinación de opciones como la reducción de la probabilidad de los
riesgos, la reducción de sus consecuencias y la distribución o retención de cualquier riesgo residual.
Algunos tratamientos de riesgo pueden abordar eficazmente más de un riesgo (por ejemplo, la capacitación y
la sensibilización en materia de seguridad de la información). Debe definirse un plan de tratamiento de los
riesgos que identifique claramente el orden de prioridad en el que deben aplicarse los tratamientos de los
riesgos individuales y sus plazos. Las prioridades pueden establecerse utilizando diversas técnicas, entre
ellas la clasificación de los riesgos y el análisis de costo-beneficio. Es responsabilidad de los administradores
de la organización decidir el equilibrio entre los costos de aplicación de los controles y la asignación
presupuestaria.
La identificación de los controles existentes puede determinar que éstos superen las necesidades actuales,
en términos de comparación de costos, incluido el mantenimiento. Si se considera la posibilidad de eliminar
los controles redundantes o innecesarios (especialmente si los controles tienen altos costos de
mantenimiento), se deben tener en cuenta los factores de seguridad de la información y de costo. Dado que
los controles pueden influirse mutuamente, la eliminación de los controles redundantes podría reducir la
seguridad general existente. Además, puede resultar más barato dejar los controles redundantes o
innecesarios en su lugar que eliminarlos.
Se deben considerar las opciones de tratamiento de los riesgos teniendo en cuenta:
 Cómo perciben el riesgo las partes afectadas

 Las formas más apropiadas para comunicarse con esas partes
El establecimiento del contexto (véase 7.2 - Criterios de evaluación de riesgos) proporciona información sobre
los requisitos legales y reglamentarios que debe cumplir la organización. El riesgo para las organizaciones es
el incumplimiento y deben aplicarse opciones de tratamiento para limitar esta posibilidad. Todas las
limitaciones - organizativas, técnicas, estructurales, etc. - que se identifiquen durante la actividad de
establecimiento del contexto deben tenerse en cuenta durante el tratamiento del riesgo.
Una vez definido el plan de tratamiento de riesgos, es necesario determinar los riesgos residuales. Esto
supone una actualización o una reiteración de la evaluación de los riesgos, teniendo en cuenta los efectos
previstos del tratamiento de riesgos propuesto. Si el riesgo residual sigue sin cumplir los criterios de
aceptación del riesgo de la organización, puede ser necesaria una nueva iteración del tratamiento del riesgo
antes de proceder a la aceptación del riesgo. Se puede encontrar más información en la cláusula 0.3 de la
norma ISO/CEI 27002:2005.
Salida: Plan de tratamiento de riesgos y riesgos residuales sujeto a la decisión de aceptación de los directivos
de la organización.
9.2 Modificación del riesgo
Acción: El nivel de riesgo debe gestionarse introduciendo, eliminando o alterando controles para que el riesgo
residual pueda volver a evaluarse como aceptable.
Se deben seleccionar controles apropiados y justificados para cumplir los requisitos identificados por la
evaluación y el tratamiento de los riesgos. En esta selección se deben tener en cuenta los criterios de
aceptación del riesgo, así como los requisitos legales, reglamentarios y contractuales. Esta selección también
debe tener en cuenta el costo y el plazo de aplicación de los controles, o los aspectos técnicos, ambientales y
culturales. A menudo es posible reducir el costo total de propiedad de un sistema con controles de seguridad
de la información debidamente seleccionados.
En general, los controles pueden proporcionar uno o más de los siguientes tipos de protección: corrección,
eliminación, prevención, reducción al mínimo de los efectos, disuasión, detección, recuperación, vigilancia y
sensibilización. Durante la selección de los controles es importante sopesar el costo de adquisición,
aplicación, administración, funcionamiento, vigilancia y mantenimiento de los controles con el valor de los
bienes que se protegen. Además, se debe considerar el rendimiento de la inversión en términos de reducción
de riesgos y el potencial de explotación de nuevas oportunidades comerciales que ofrecen ciertos controles.
Además, se deben tener en cuenta los conocimientos especializados que puedan ser necesarios para definir
y aplicar nuevos controles o modificar los existentes.
La norma ISO/IEC 27002 proporciona información detallada sobre los controles.

ISO/IEC 27005:2011(E)
Hay muchas limitaciones que pueden afectar a la selección de los controles. Las limitaciones técnicas, como
los requisitos de rendimiento, la capacidad de gestión (requisitos de apoyo operacional) y los problemas de
compatibilidad pueden obstaculizar el uso de ciertos controles o pueden inducir a error humano, ya sea
anulando el control, dando una falsa sensación de seguridad o incluso aumentando el riesgo más allá de no
tener el control (por ejemplo, exigiendo contraseñas complejas sin la capacitación adecuada, lo que lleva a
los usuarios a escribir las contraseñas). Además, podría darse el caso de que un control afectara al
rendimiento. Los administradores deben tratar de identificar una solución que satisfaga los requisitos de
rendimiento y garantice al mismo tiempo una seguridad suficiente de la información. El resultado de este paso
es una lista de posibles controles, con su costo, beneficio y prioridad de aplicación.
Se deben tener en cuenta varias limitaciones al seleccionar los controles y durante la aplicación. Por lo
general, se consideran las siguientes:
 Las limitaciones de tiempo

 Restricciones financieras
 Restricciones técnicas
 Restricciones operacionales
 Restricciones culturales
 Restricciones éticas
 Restricciones ambientales
 Restricciones legales
 Facilidad de uso
 Las limitaciones de personal
 Limitaciones para la integración de controles nuevos y existentes
En el Anexo F se puede encontrar más información sobre las limitaciones para la modificación del riesgo.
9.3 Retención del riesgo
Acción: La decisión de mantener el riesgo sin más medidas debe adoptarse en función de la evaluación del riesgo.
NOTA ISO/CEI 27001:2005 4.2.1 f 2) "aceptar los riesgos a sabiendas y objetivamente, siempre que satisfagan
claramente las políticas y los criterios de aceptación de riesgos de la organización" describe la misma actividad.
Si el nivel de riesgo cumple los criterios de aceptación del riesgo, no es necesario aplicar controles
adicionales y el riesgo puede mantenerse.
9.4 Evitar el riesgo
Acción: Debe evitarse la actividad o condición que da lugar al riesgo particular.
Cuando se considera que los riesgos identificados son demasiado elevados, o los costos de la aplicación de
otras opciones de tratamiento de los riesgos superan los beneficios, se puede tomar la decisión de evitar
completamente el riesgo, retirándose de una actividad o conjunto de actividades planificadas o existentes, o
cambiando las condiciones en que se realiza la actividad. Por ejemplo, en el caso de los riesgos causados
por la naturaleza puede ser la alternativa más rentable trasladar físicamente las instalaciones de tratamiento
de la información a un lugar donde el riesgo no exista o esté controlado.
9.5 Compartir el riesgo
Acción: El riesgo debe compartirse con otra parte que pueda gestionar con mayor eficacia el riesgo concreto
en función de la evaluación del mismo.
La distribución de riesgos implica la decisión de compartir ciertos riesgos con partes externas. Compartir el
riesgo puede crear nuevos riesgos o modificar los riesgos existentes e identificados. Por lo tanto, puede ser
necesario un tratamiento adicional del riesgo.
ISO/IEC 27005:2011(E)
El intercambio puede hacerse mediante un seguro que soporte las consecuencias, o mediante la
subcontratación de un socio cuya función será vigilar el sistema de información y tomar medidas inmediatas
para detener un ataque antes de que cause un nivel definido de daños.
Cabe señalar que tal vez sea posible compartir la responsabilidad de la gestión del riesgo, pero normalmente
no es posible compartir la responsabilidad de un impacto. Los clientes normalmente atribuirán un impacto
adverso como culpa de la organización.
10 Aceptación del riesgo de seguridad de la información

Entrada: Plan de tratamiento de riesgos y evaluación de riesgos residuales sujeto a la decisión de aceptación
de los directivos de la organización.
Acción: La decisión de aceptar los riesgos y responsabilidades de la decisión debe ser tomada y registrada
formalmente (esto se relaciona con ISO/IEC 27001:2005 párrafo 4.2.1 h)).
Los planes de tratamiento de riesgos deben describir la forma en que se han de tratar los riesgos evaluados
para cumplir los criterios de aceptación del riesgo (véase la cláusula 7.2 Criterios de aceptación del riesgo).
Es importante que los gestores responsables examinen y aprueben los planes de tratamiento de riesgos
propuestos y los riesgos residuales resultantes, y registren las condiciones asociadas a dicha aprobación.
Los criterios de aceptación del riesgo pueden ser más complejos que la simple determinación de si un riesgo
residual está por encima o por debajo de un umbral único.
En algunos casos el nivel de riesgo residual puede no cumplir los criterios de aceptación del riesgo porque los
criterios que se aplican no tienen en cuenta las circunstancias imperantes. Por ejemplo, podría argumentarse
que es necesario aceptar los riesgos porque los beneficios que acompañan a los riesgos son muy atractivos,
o porque el costo de la modificación del riesgo es demasiado alto. Esas circunstancias indican que los
criterios de aceptación del riesgo son inadecuados y deben revisarse de ser posible. Sin embargo, no
siempre es posible revisar oportunamente los criterios de aceptación del riesgo. En esos casos, es posible
que los encargados de adoptar decisiones tengan que aceptar riesgos que no cumplan los criterios de
aceptación normales. Si ello es necesario, la persona encargada de la adopción de decisiones debe comentar
explícitamente los riesgos e incluir una justificación de la decisión de anular los criterios normales de
aceptación del riesgo.
Salida: Una lista de los riesgos aceptados con la justificación de los que no cumplen los criterios normales de
aceptación de riesgos de la organización.
11 Comunicación y consulta sobre los riesgos para la seguridad de la información

Entrada: Toda la información sobre el riesgo obtenida de las actividades de gestión de riesgos (véase la figura 2).
Acción: La información sobre el riesgo debería intercambiarse y/o compartirse entre el responsable de la
toma de decisiones y otros interesados.
La comunicación de riesgos es una actividad para lograr un acuerdo sobre la forma de gestionar los riesgos
mediante el intercambio y/o la puesta en común de información sobre el riesgo entre los responsables de la
adopción de decisiones y otros interesados. La información incluye, entre otras cosas, la existencia, la
naturaleza, la forma, la probabilidad, la gravedad, el tratamiento y la aceptabilidad de los riesgos.
La comunicación eficaz entre los interesados es importante, ya que puede tener un impacto significativo en
las decisiones que deben adoptarse. La comunicación garantizará que los responsables de la aplicación de la
gestión de riesgos y los que tienen un interés personal comprendan la base sobre la que se adoptan las
decisiones y por qué es necesario adoptar determinadas medidas. La comunicación es bidireccional.
ISO/IEC 27005:2011(E)
Las percepciones del riesgo pueden variar debido a las diferencias en las suposiciones, los conceptos y las
necesidades, cuestiones y preocupaciones de los interesados en lo que respecta al riesgo o a las cuestiones
que se examinan. Es probable que las partes interesadas emitan juicios sobre la aceptabilidad del riesgo
basándose en su percepción del mismo. Esto es especialmente importante para asegurar que las
percepciones de los interesados sobre el riesgo, así como sus percepciones de los beneficios, puedan
identificarse y documentarse y que las razones subyacentes se entiendan y aborden claramente.
La comunicación de los riesgos debe llevarse a cabo con el fin de lograr lo siguiente:
 Para asegurar el resultado de la gestión de riesgos de la organización

 Para recopilar información sobre los riesgos
 Compartir los resultados de la evaluación de riesgos y presentar el plan de tratamiento de riesgos
 Evitar o reducir tanto la aparición como las consecuencias de las violaciones de la seguridad de la
información debido a la falta de entendimiento mutuo entre los encargados de la adopción de decisiones
y las partes interesadas
 Para apoyar la toma de decisiones
 Para obtener nuevos conocimientos sobre seguridad de la información
 Para coordinar con otras partes y planificar respuestas para reducir las consecuencias de cualquier incidente
 Dar a los responsables de la toma de decisiones y a las partes interesadas un sentido de responsabilidad sobre
los riesgos
 Para mejorar la conciencia
Una organización debe elaborar planes de comunicación de riesgos tanto para las operaciones normales
como para las situaciones de emergencia. Por lo tanto, la actividad de comunicación de riesgos debe
realizarse continuamente.
La coordinación entre los principales responsables de la toma de decisiones y las partes interesadas puede
lograrse mediante la formación de un comité en el que se pueda debatir sobre los riesgos, su priorización y
tratamiento adecuado, y su aceptación.
Es importante cooperar con la dependencia de relaciones públicas o de comunicaciones apropiada dentro de

la organización para coordinar todas las tareas relacionadas con la comunicación de riesgos. Esto es crucial
en caso de acciones de comunicación de crisis, por ejemplo, en respuesta a incidentes particulares.
Salida: Comprensión continua del proceso y los resultados de la gestión de riesgos para la seguridad de la
información de la organización.
12 Vigilancia y examen de los riesgos para la seguridad de la información
12.1 Vigilancia y examen de los factores de riesgo
Acción: Los riesgos y sus factores (es decir, el valor de los activos, los impactos, las amenazas, las
vulnerabilidades, la probabilidad de que se produzcan) deben vigilarse y revisarse para identificar cualquier
cambio en el contexto de la organización en una etapa temprana, y para mantener una visión general del
panorama completo de los riesgos.
Los riesgos no son estáticos. Las amenazas, vulnerabilidades, probabilidades o consecuencias pueden
cambiar abruptamente sin ninguna indicación. Por lo tanto, es necesaria una vigilancia constante para
detectar estos cambios. Esto puede ser apoyado por servicios externos que proporcionen información sobre
nuevas amenazas o vulnerabilidades.
Las organizaciones deben asegurarse de que se vigilen continuamente los siguientes aspectos:
 Nuevos activos que se han incluido en el ámbito de la gestión de riesgos

 Modificación necesaria del valor de los activos, por ejemplo, debido a cambios en los requisitos comerciales
 Nuevas amenazas que podrían estar activas tanto fuera como dentro de la organización y que no han
sido evaluadas
 Posibilidad de que las vulnerabilidades nuevas o aumentadas permitan a las amenazas explotar estas
vulnerabilidades nuevas o modificadas
 Identificó las vulnerabilidades para determinar aquellos que se exponen a las amenazas nuevas o reemergentes

ISO/IEC 27005:2011(E)
 Aumento de los efectos o consecuencias de las amenazas, vulnerabilidades y riesgos evaluados en

conjunto, lo que da lugar a un nivel de riesgo inaceptable
 Incidentes de seguridad de la información
Las nuevas amenazas, vulnerabilidades o cambios en la probabilidad o las consecuencias pueden aumentar
los riesgos previamente evaluados como bajos. El examen de los riesgos bajos y aceptados debe considerar
cada riesgo por separado, y todos esos riesgos también en conjunto, para evaluar su posible impacto
acumulado. Si los riesgos no entran en la categoría de riesgos bajos o aceptables, deben tratarse utilizando
una o más de las opciones consideradas en la cláusula 9.
Los factores que influyen en la probabilidad y las consecuencias de las amenazas que se producen podrían
cambiar, así como los factores que afectan a la idoneidad o el costo de las diversas opciones de tratamiento.
Los cambios importantes que afecten a la organización deberían ser motivo de un examen más específico.
Por consiguiente, las actividades de vigilancia de los riesgos deben repetirse periódicamente y las opciones
seleccionadas para el tratamiento de los riesgos deben revisarse periódicamente.
El resultado de las actividades de vigilancia de los riesgos puede contribuir a otras actividades de examen de
los riesgos. La organización debe examinar todos los riesgos con regularidad y cuando se produzcan
cambios importantes (según la norma ISO/CEI 27001:2005, cláusula 4.2.3)).
Salida: Alineación continua de la gestión de riesgos con los objetivos comerciales de la organización y con los
criterios de aceptación de riesgos.
12.2 Vigilancia, examen y mejora de la gestión de riesgos
Acción: El proceso de gestión de los riesgos para la seguridad de la información debe ser objeto de una
vigilancia, revisión y mejora continuas, según sea necesario y apropiado.
Es necesario realizar una vigilancia y un examen continuos para garantizar que el contexto, el resultado de la
evaluación de los riesgos y el tratamiento de los riesgos, así como los planes de gestión, sigan siendo
pertinentes y adecuados a las circunstancias.
La organización debe asegurarse de que el proceso de gestión de riesgos para la seguridad de la información
y las actividades conexas sigan siendo apropiados en las circunstancias actuales y se cumplan. Toda mejora
convenida del proceso o las medidas necesarias para mejorar el cumplimiento del proceso deben notificarse
a los administradores apropiados para tener la seguridad de que no se pasa por alto ni se subestima ningún
riesgo o elemento de riesgo y de que se adoptan las medidas y decisiones necesarias para proporcionar una
comprensión realista del riesgo y la capacidad de respuesta.
Además, la organización debe verificar periódicamente que los criterios utilizados para medir el riesgo y sus
elementos siguen siendo válidos y coherentes con los objetivos, las estrategias y las políticas comerciales, y
que los cambios en el contexto comercial se tienen debidamente en cuenta durante el proceso de gestión de
los riesgos para la seguridad de la información. En esta actividad de vigilancia y examen se debería abordar
(pero no limitarse a)
 Contexto jurídico y ambiental

 Contexto de la competencia
 Enfoque de evaluación de riesgos
 Valor del activo y categorías
 Criterios de impacto
 Criterios de evaluación de riesgos
 Criterios de aceptación del riesgo
 Costo total de propiedad
 Recursos necesarios
La organización debe asegurarse de que se disponga continuamente de recursos para la evaluación y el

tratamiento de los riesgos a fin de examinarlos, abordar las amenazas o vulnerabilidades nuevas o
modificadas y asesorar a la administración en consecuencia.
ISO/IEC 27005:2011(E)
La vigilancia de la gestión de riesgos puede dar lugar a la modificación o adición del enfoque, la
metodología o los instrumentos utilizados, según el caso:
 Los cambios identificados

 Iteración de la evaluación de riesgos
 Objetivo del proceso de gestión de riesgos para la seguridad de la información (por ejemplo, continuidad
de las actividades, resistencia a los incidentes, cumplimiento)
 Objeto del proceso de gestión de riesgos para la seguridad de la información (por ejemplo, la
organización, la unidad comercial, el proceso de información, su ejecución técnica, la aplicación, la
conexión a Internet)
Salida: Pertinencia continua del proceso de gestión de los riesgos para la seguridad de la información
para los objetivos comerciales de la organización o la actualización del proceso.
ISO/IEC 27005:2011(E)
Anexo A
(informativo)
Definir el alcance y los límites de

el proceso de gestión de riesgos para la seguridad de la información
A.1 Estudio de la organización

Evaluar la organización El estudio de la organización recuerda los elementos característicos que definen la
identidad de una organización. Esto concierne al propósito, los negocios, las misiones, los valores y las
estrategias de esta organización. Éstos deben identificarse junto con los elementos que contribuyen a su
desarrollo (por ejemplo, la subcontratación).
La dificultad de esta actividad radica en comprender exactamente cómo está estructurada la organización. La
identificación de su estructura real permitirá comprender el papel y la importancia de cada división en la
consecución de los objetivos de la organización.
Por ejemplo, el hecho de que el gerente de seguridad de la información dependa de los altos directivos y no
de los gerentes de tecnología de la información puede indicar la participación de los altos directivos en la
El propósito principal de la organización El propósito principal de una organización puede definirse como la
razón de su existencia (su campo de actividad, su segmento de mercado, etc.).
Su negocio El negocio de la organización, definido por las técnicas y el saber hacer de sus empleados, le
permite cumplir sus misiones. Es específico del campo de actividad de la organización y a menudo define su
cultura.
Su misión La organización logra su propósito al cumplir su misión. Para identificar sus misiones, los servicios
prestados y/o los productos fabricados deben identificarse en relación con los usuarios finales.
Sus valores Los valores son principios importantes o un código de conducta bien definido aplicado al ejercicio
de un negocio. Puede referirse al personal, a las relaciones con agentes externos (clientes, etc.), a la calidad
de los productos suministrados o de los servicios prestados.
Tomemos el ejemplo de una organización cuyo propósito es el servicio público, cuyo negocio es el transporte
y cuyas misiones incluyen el transporte de los niños hacia y desde la escuela. Sus valores pueden ser la
puntualidad del servicio y la seguridad durante el transporte.
Estructura de la organización Hay diferentes tipos de estructura:
 Estructura divisional: cada división está bajo la autoridad de un director de división responsable de las
decisiones estratégicas, administrativas y operacionales relativas a su unidad.
 Estructura funcional: la autoridad funcional se ejerce sobre los procedimientos, la naturaleza del
trabajo y, a veces, sobre las decisiones o la planificación (por ejemplo, la producción, la
informática, los recursos humanos, la comercialización, etc.)
Observaciones:
 Una división dentro de una organización con estructura divisional puede organizarse como una
estructura funcional y viceversa
 Se puede decir que una organización tiene una estructura de matriz si tiene elementos de ambos tipos de estructura
 En cualquier estructura organizativa se pueden distinguir los siguientes niveles:
 el nivel de toma de decisiones (definición de orientaciones estratégicas);
 el nivel de liderazgo (coordinación y gestión);
 el nivel operacional (actividades de producción y de apoyo).
ISO/IEC 27005:2011(E)
Organigrama La estructura de la organización se representa esquemáticamente en un organigrama. En esta

representación deben destacarse las líneas de presentación de informes y de delegación de autoridad, pero
también deben incluirse otras relaciones que, aunque no se basen en ninguna autoridad oficial, son sin
embargo líneas de flujo de información.
La estrategia de la organización Esto requiere una expresión formal de los principios rectores de la
organización. La estrategia de la organización determina la dirección y el desarrollo necesarios para
beneficiarse de las cuestiones en juego y de los grandes cambios que está planificando.
A.2 Lista de las limitaciones que afectan a la organización

Se deben tener en cuenta todas las limitaciones que afectan a la organización y que determinan su
orientación hacia la seguridad de la información. Su fuente puede estar dentro de la organización, en cuyo
caso ésta tiene cierto control sobre ellas, o fuera de la organización y, por lo tanto, generalmente no es
negociable. Las limitaciones de recursos (presupuesto, personal) y las limitaciones de emergencia se
encuentran entre las más importantes.
La organización establece sus objetivos (en relación con sus negocios, su comportamiento, etc.)
comprometiéndose a un determinado camino, posiblemente durante un largo período. Define lo que quiere
llegar a ser y los medios que deberán aplicarse. Al especificar este camino, la organización tiene en cuenta la
evolución de las técnicas y del saber hacer, los deseos expresados por los usuarios, los clientes, etc. Este
objetivo puede expresarse en forma de estrategias de explotación o de desarrollo con el fin, por ejemplo, de
reducir los costos de explotación, mejorar la calidad del servicio, etc.
Estas estrategias probablemente incluyen la información y el sistema de información (SI), que ayudan a su
aplicación. Por consiguiente, las características relativas a la identidad, la misión y las estrategias de la
organización son elementos fundamentales en el análisis del problema, ya que la violación de un aspecto de
la seguridad de la información podría dar lugar a un replanteamiento de estos objetivos estratégicos. Además,
es esencial que las propuestas de requisitos de seguridad de la información sigan siendo coherentes con las
normas, los usos y los medios vigentes en la organización.
La lista de limitaciones incluye, entre otras cosas,
las siguientes: Restricciones de naturaleza política
Éstas pueden referirse a las administraciones públicas, a las instituciones públicas o, más en general, a
cualquier organización que tenga que aplicar las decisiones gubernamentales. Suelen ser decisiones relativas
a la orientación estratégica u operacional adoptadas por una división gubernamental u órgano decisorio y
deben aplicarse.
Por ejemplo, la informatización de las facturas o documentos administrativos introduce problemas de

Limitaciones de naturaleza estratégica
Las limitaciones pueden surgir de cambios planificados o posibles en las estructuras u orientación de la
organización. Se expresan en los planes estratégicos u operativos de la organización.
Por ejemplo, la cooperación internacional en el intercambio de información sensible puede requerir acuerdos
relativos a un intercambio seguro.
Limitaciones territoriales
La estructura y/o el propósito de la organización puede introducir limitaciones específicas, como la

distribución de los emplazamientos en todo el territorio nacional o en el extranjero.
Ejemplos de ello son los servicios postales, las embajadas, los bancos, las filiales de un gran grupo industrial, etc.
ISO/IEC 27005:2011(E)
Las limitaciones derivadas del clima económico y político
El funcionamiento de una organización puede verse profundamente modificado por acontecimientos específicos
como huelgas o crisis nacionales e internacionales.
Por ejemplo, algunos servicios deberían poder continuar incluso durante una crisis grave.
Restricciones estructurales
La naturaleza de la estructura de una organización (divisional, funcional o de otro tipo) puede dar lugar a una
política específica de seguridad de la información y a una organización de seguridad adaptada a la estructura.
Por ejemplo, una estructura internacional debería poder conciliar los requisitos de seguridad específicos de
cada país.
Restricciones funcionales
Las limitaciones funcionales surgen directamente de las misiones generales o específicas de la organización.
Por ejemplo, una organización que funciona las veinticuatro horas del día debe asegurarse de que sus recursos
estén disponibles continuamente.
Restricciones relativas al personal
La naturaleza de estas limitaciones varía considerablemente. Están relacionadas con: el nivel de

responsabilidad, el reclutamiento, la calificación, la formación, la conciencia de seguridad, la motivación, la
disponibilidad, etc.
Por ejemplo, todo el personal de una organización de defensa debe tener autorización para manejar información
altamente confidencial.
Limitaciones derivadas del calendario de la organización
Estas limitaciones pueden ser el resultado de la reestructuración o el establecimiento de nuevas políticas

nacionales o internacionales que impongan ciertos plazos.
Por ejemplo, la creación de una división de seguridad.
Limitaciones relacionadas con los métodos
Será necesario imponer métodos apropiados a los conocimientos técnicos de la organización para aspectos
como la planificación de proyectos, especificaciones, desarrollo, etc.
Por ejemplo, una limitación típica de este tipo es la necesidad de incorporar las obligaciones jurídicas de la
organización en la política de seguridad.
Restricciones de naturaleza cultural
En algunas organizaciones los hábitos de trabajo o el negocio principal han dado lugar a una "cultura"
específica dentro de la organización, que puede ser incompatible con los controles de seguridad. Esta cultura
es el marco de referencia general del personal y puede estar determinada por muchos aspectos, entre ellos la
educación, la instrucción, la experiencia profesional, la experiencia fuera del trabajo, las opiniones, la filosofía,
las creencias, la condición social, etc.
Restricciones presupuestarias
Los controles de seguridad recomendados pueden tener a veces un costo muy alto. Aunque no siempre es
apropiado basar las inversiones en seguridad en la eficacia en función de los costos, el departamento
financiero de la organización suele exigir una justificación económica.
Por ejemplo, en el sector privado y en algunas organizaciones públicas, el costo total de los controles de
seguridad no debería exceder el costo de las posibles consecuencias de los riesgos. Por consiguiente, los
altos directivos deberían evaluar y asumir riesgos calculados si desean evitar costos de seguridad excesivos.
ISO/IEC 27005:2011(E)
A.3 Lista de las referencias legislativas y reglamentarias aplicables a la organización
Se deben identificar los requisitos reglamentarios aplicables a la organización. Puede tratarse de leyes,
decretos, reglamentos específicos en el ámbito de la organización o reglamentos internos y/o externos. Esto
también se refiere a los contratos y acuerdos y, más en general, a cualquier obligación de carácter jurídico o
reglamentario.
A.4 Lista de las limitaciones que afectan al alcance

Al identificar las limitaciones es posible enumerar las que repercuten en el alcance y determinar cuáles son,
no obstante, susceptibles de ser objeto de medidas. Se añaden a las limitaciones de la organización
determinadas anteriormente, y posiblemente las modifiquen. En los párrafos siguientes se presenta una lista
no exhaustiva de los posibles tipos de limitaciones.
Limitaciones derivadas de procesos preexistentes
Los proyectos de aplicación no se desarrollan necesariamente de forma simultánea. Algunos dependen de

procesos preexistentes. Aunque un proceso puede desglosarse en subprocesos, el proceso no está
necesariamente influenciado por todos los subprocesos de otro proceso.
Restricciones técnicas
Las limitaciones técnicas, relativas a la infraestructura, suelen derivarse de los equipos y programas
informáticos instalados, y de las salas o emplazamientos que albergan los procesos:
 Archivos (requisitos relativos a la organización, gestión de los medios de comunicación, gestión de las normas de
acceso, etc.)
 Arquitectura general (requisitos relativos a la topología (centralizada, distribuida, cliente-servidor),
arquitectura física, etc.)
 Software de aplicación (requisitos relativos al diseño de software específico, normas de mercado, etc.);
 Paquete de software (requisitos relativos a las normas, el nivel de evaluación, la calidad, el
cumplimiento de las normas, la seguridad, etc.)
 Hardware (requisitos relativos a las normas, la calidad, el cumplimiento de las normas, etc.)
 Redes de comunicación (requisitos de cobertura, normas, capacidad, fiabilidad, etc.)
 Infraestructura de edificios (requisitos relativos a la ingeniería civil, construcción, altos voltajes,
bajos voltajes, etc.)
Restricciones financieras
La aplicación de los controles de seguridad suele estar restringida por el presupuesto que la organización
puede comprometer. Sin embargo, la restricción financiera debe ser aún la última que se considere, ya que la
asignación presupuestaria para la seguridad puede negociarse sobre la base del estudio de seguridad.
Restricciones ambientales
Las limitaciones ambientales se derivan del entorno geográfico o económico en el que se llevan a cabo los
procesos: país, clima, riesgos naturales, situación geográfica, clima económico, etc.
Las limitaciones de tiempo
El tiempo necesario para aplicar los controles de seguridad debe considerarse en relación con la capacidad
de mejorar el sistema de información; si el tiempo de aplicación es muy largo, los riesgos para los que se
diseñó el control pueden haber cambiado. El tiempo es un factor determinante para la selección de
soluciones y prioridades.
Limitaciones relacionadas con los métodos
Para la planificación de los proyectos, las especificaciones, el desarrollo, etc., se deben utilizar métodos
adecuados a los conocimientos técnicos de la organización.
ISO/IEC 27005:2011(E)
Restricciones de organización
Las exigencias de la organización pueden dar lugar a diversas limitaciones:
 Funcionamiento (requisitos relativos a los plazos de entrega, suministro de servicios, vigilancia,

supervisión, planes de emergencia, funcionamiento degradado, etc.)
 Mantenimiento (requisitos para la solución de problemas de incidentes, acciones preventivas, corrección rápida, etc.)
 Gestión de los recursos humanos (requisitos relativos a la capacitación de operadores y usuarios,
calificación para puestos como el de administrador de sistemas o administrador de datos, etc.)
 Gestión administrativa (requisitos relativos a las responsabilidades, etc.)
 Gestión del desarrollo (requisitos relativos a los instrumentos de desarrollo, ingeniería de software
asistida por ordenador, planes de aceptación, organización que debe establecerse, etc.)
 Gestión de las relaciones exteriores (requisitos relativos a la organización de las relaciones con
terceros, contratos, etc.)

ISO/IEC 27005:2011(E)
Anexo B
(informativo)
Identificación y valoración de los activos y evaluación del impacto
B.1 Ejemplos de identificación de activos

Para realizar la valoración de los activos, una organización necesita primero identificar sus activos (con un
nivel de detalle apropiado). Se pueden distinguir dos tipos de activos:
 Los activos principales:

 Procesos y actividades comerciales
 Información
 Los activos de apoyo (de los que dependen los elementos primarios del ámbito de aplicación) de todos los tipos:
 Hardware
 Software
 Red
 Personal
 Sitio
 Estructura de la organización
B.1.1 La identificación de los activos primarios
Para describir el alcance con mayor precisión, esta actividad consiste en identificar los activos primarios
(procesos y actividades comerciales, información). Esta identificación es llevada a cabo por un grupo de
trabajo mixto representativo del proceso (gestores, especialistas en sistemas de información y usuarios).
Los principales activos suelen ser los procesos y la información básicos de la actividad en el ámbito de
aplicación. También pueden considerarse otros activos primarios, como los procesos de la organización, que
serán más apropiados para elaborar una política de seguridad de la información o un plan de continuidad de
las actividades. Según el propósito, algunos estudios no requerirán un análisis exhaustivo de todos los
elementos que componen el ámbito. En tales casos, los límites del estudio pueden limitarse a los elementos
clave del alcance.
Los activos primarios son de dos tipos:
1 - Por ejemplo, procesos (o subprocesos) y actividades comerciales:
 Procesos cuya pérdida o degradación hace imposible llevar a cabo la misión de la organización
 Procesos que contienen procesos secretos o procesos con tecnología patentada
 Procesos que, si se modifican, pueden afectar en gran medida al cumplimiento de la misión de la organización
 Procesos necesarios para que la organización cumpla con los requisitos contractuales, legales
o reglamentarios
2 - Información:
En términos más generales, la información primaria comprende principalmente
 Información vital para el ejercicio de la misión o negocio de la organización

 La información personal, como puede definirse específicamente en el sentido de las leyes nacionales relativas a
la privacidad
 Información estratégica necesaria para alcanzar los objetivos determinados por las orientaciones estratégicas
 Información de alto costo cuya recopilación, almacenamiento, procesamiento y transmisión requieren
mucho tiempo y/o implican un alto costo de adquisición
ISO/IEC 27005:2011(E)
Los procesos y la información que no se identifiquen como sensibles después de esta actividad no tendrán
una clasificación definida en el resto del estudio. Esto significa que incluso si tales procesos o información se
ven comprometidos, la organización seguirá cumpliendo la misión con éxito.
Sin embargo, a menudo heredarán los controles aplicados para proteger los procesos y la información
identificados como delicados.
B.1.2 Lista y descripción de los activos de apoyo
El ámbito de aplicación consiste en los bienes que deben ser identificados y descritos. Estos activos tienen
vulnerabilidades que pueden ser explotadas por amenazas que tienen por objeto deteriorar los principales
activos del ámbito (procesos e información). Son de varios tipos:
Hardware
El tipo de hardware consiste en todos los elementos físicos que apoyan los procesos.
Equipo de procesamiento de datos (activo)
Equipo de procesamiento automático de información, incluidos los elementos necesarios para
funcionar de manera independiente. Equipo transportable
Equipo de computación portátil.
Ejemplos: computadora portátil, Asistente Digital Personal
(PDA). Equipo fijo
El equipo informático utilizado en los locales de la
organización. Ejemplos: servidor, microcomputadora
utilizada como estación de trabajo. Periféricos de
procesamiento
Equipo conectado a una computadora a través de un puerto de comunicación (enlace en serie, paralelo,
etc.) para introducir, transportar o transmitir datos.
Ejemplos: impresora, unidad de disco
extraíble. Soporte de datos (pasivo)
Estos son medios para almacenar datos o
funciones. Medio electrónico
Un medio de información que puede conectarse a una computadora o red de computadoras para el
almacenamiento de datos. A pesar de su tamaño compacto, estos medios pueden contener una gran
cantidad de datos. Pueden utilizarse con equipos informáticos estándar.
Ejemplos: Disco flexible, CD ROM, cartucho de reserva, disco duro extraíble, llave de
memoria, cinta. Otros medios
Medios de comunicación estáticos, no electrónicos, que contienen datos.
Ejemplos: papel, diapositivas, transparencia, documentación, fax.
Software
El software consiste en todos los programas que contribuyen al funcionamiento de un conjunto de procesamiento de
datos.
ISO/IEC 27005:2011(E)
Sistema operativo
Esto incluye todos los programas de una computadora que constituyen la base operativa desde la que
se ejecutan todos los demás programas (servicios o aplicaciones). Incluye un núcleo y funciones o
servicios básicos. Según la arquitectura, un sistema operativo puede ser monolítico o estar compuesto
por un micronúcleo y un conjunto de servicios del sistema. Los principales elementos del sistema
operativo son todos los servicios de gestión de equipo (CPU, memoria, disco e interfaces de red), los
servicios de gestión de tareas o procesos y los servicios de gestión de derechos de usuario.
Software de servicio, mantenimiento o administración
Los programas informáticos se caracterizan por el hecho de que complementan los servicios del
sistema operativo y no están directamente al servicio de los usuarios o de las aplicaciones (aunque
suelen ser esenciales o incluso indispensables para el funcionamiento global del sistema de
información).
Paquete de software o software estándar
Los programas informáticos estándar o los paquetes de programas informáticos son productos
completos comercializados como tales (en lugar de desarrollos únicos o específicos) con medio,
lanzamiento y mantenimiento. Proporcionan servicios para los usuarios y las aplicaciones, pero no son
personalizados ni específicos como las aplicaciones empresariales.
Ejemplos: software de gestión de bases de datos, software de mensajería electrónica, software de

grupos, software de directorios, software de servidores web, etc.
Aplicación de negocios
Aplicación comercial estándar
Se trata de un programa informático comercial diseñado para dar a los usuarios acceso directo a
los servicios y funciones que requieren de su sistema de información en su contexto profesional.
Existe una gama muy amplia, teóricamente ilimitada, de campos.
Ejemplos: software de cuentas, software de control de herramientas mecánicas, software de

atención al cliente, software de gestión de competencias del personal, software administrativo,
etc.
Aplicación comercial específica
Se trata de programas informáticos en los que se han desarrollado específicamente diversos

aspectos (principalmente el apoyo, el mantenimiento, la actualización, etc.) para dar a los
usuarios un acceso directo a los servicios y funciones que requieren de su sistema de
información. Existe una gama muy amplia, teóricamente ilimitada, de campos.
Ejemplos: Gestión de facturas de los clientes de los operadores de telecomunicaciones,

aplicación de vigilancia en tiempo real para el lanzamiento de cohetes.
Red
El tipo de red consiste en todos los dispositivos de telecomunicación utilizados para interconectar varias
computadoras o elementos físicamente remotos de un sistema de información.
Medio y soportes
Los medios o equipos de comunicaciones y telecomunicaciones se caracterizan principalmente

por las características físicas y técnicas del equipo (punto a punto, radiodifusión) y por los
protocolos de comunicación (enlace o red - niveles 2 y 3 del modelo OSI de 7 capas).
Ejemplos: Red telefónica pública de conmutación (PSTN), Ethernet, GigabitEthernet, Línea digital
asimétrica de abonado (ADSL), especificaciones de protocolos inalámbricos (por ejemplo, WiFi
802.11), Bluetooth, FireWire.
ISO/IEC 27005:2011(E)
Relevo pasivo o activo
Este subtipo incluye todos los dispositivos que no son las terminaciones lógicas de las
comunicaciones (visión de la IS) pero que son dispositivos intermedios o de retransmisión. Los
relés se caracterizan por los protocolos de comunicación de red soportados. Además del relé
básico, suelen incluir funciones y servicios de enrutamiento y/o filtrado, empleando conmutadores
de comunicación y enrutadores con filtros. A menudo pueden administrarse a distancia y suelen
ser capaces de generar registros.
Ejemplos: puente, router, hub, interruptor, intercambio automático.
Interfaz de comunicación
Las interfaces de comunicación de las unidades de procesamiento están conectadas a las

unidades de procesamiento, pero se caracterizan por los medios y protocolos soportados, por las
funciones instaladas de filtrado, registro o generación de avisos y sus capacidades y por la
posibilidad y el requisito de la administración a distancia.
Ejemplos: Servicio General de Radio de Paquetes (GPRS), adaptador Ethernet.
Personal
The personnel type consists of all the groups of people involved in the information system.
Decision maker
Decision makers are the owners of the primary assets (information and functions) and the
managers of the organization or specific project.
Examples: top management, project leader.
Users
Users are the personnel who handle sensitive elements in the context of their activity and who
have a special responsibility in this respect. They may have special access rights to the
information system to carry out their everyday tasks.
Examples: human resources management, financial management, risk manager.
Operation/ Maintenance staff
These are the personnel in charge of operating and maintaining the information system. They
have special access rights to the information system to carry out their everyday tasks.
Examples: system administrator, data administrator, back-up, Help Desk, application deployment
operator, security officers.
Developers
Developers are in charge of developing the organization's applications. They have access to part
of the information system with high-level rights but do not take any action on the production data.
Examples: business application developers.
Sitio
The site type comprises all the places containing the scope or part of the scope, and the physical means
required for it to operate.
36© ISO/IEC 2011 – All rights reserved
ISO/IEC 27005:2011(E)
Location
External environment
This concerns all locations in which the organization's means of security cannot be applied.
Examples: homes of the personnel, premises of another organization, environment outside

the site (urban area, hazard area).
Premises
This place is bounded by the organization's perimeter directly in contact with the outside.
This may be a physical protective boundary obtained by creating physical barriers or means
of surveillance around buildings.
Examples: establishment, buildings.
Zone
A zone is formed by a physical protective boundary forming partitions within the

organization's premises. It is obtained by creating physical barriers around the
organization's information processing infrastructures.
Examples: offices, reserved access zone, secure zone.
Essential services
All the services required for the organization's equipment to operate.
Communication
Telecommunications services and equipment provided by an operator.
Examples: telephone line, PABX, internal telephone networks.
Utilities
Services and means (sources and wiring) required for providing power to information
technology equipment and peripherals.
Examples: low voltage power supply, inverter, electrical circuit head-end.
Water supply
Waste disposal
Services and means (equipment, control) for cooling and purifying the air.
Examples: chilled water pipes, air-conditioners.
Organización
The organization type describes the organizational framework, consisting of all the personnel structures
assigned to a task and the procedures controlling these structures.
© ISO/IEC 2011 – All rights reserved37

ISO/IEC 27005:2011(E)
Authorities
These are organizations from which the studied organization derives its authority. They may
be legally affiliated or external. This imposes constraints on the studied organization in
terms of regulations, decisions and actions.
Examples: administrating body, Head office of an organization.
Structure of the organization
This consists of the various branches of the organization, including its cross-functional
activities, under the control of its management.
Examples: human resources management, IT management, purchasing management,

business unit management, building safety service, fire service, audit management.
Project or system organization
This concerns the organization set up for a specific project or service.
Examples: new application development project, information system migration project.
Subcontractors / Suppliers / Manufacturers
These are organizations that provide the organization with a service or resources and
bound to it by contract.
Examples: facilities management company, outsourcing company, consultancy companies.
B.2 Asset valuation
The next step after asset identification is to agree upon the scale to be used and the criteria for assigning a
particular location on that scale to each asset, based on valuation. Because of the diversity of assets found
within most organizations it is likely that some assets that have a known monetary value will be valued in the
local unit of currency while others which have a more qualitative value may be assigned a value ranging, for
example, from ”very low” to ”very high”. The decision to use a quantitative scale versus a qualitative scale is
really a matter of organizational preference, but should be relevant to the assets being valued. Both valuation
types could be used for the same asset.
Typical terms used for the qualitative valuation of assets include words such as: negligible, very low, low,
medium, high, very high, and critical. The choice and range of terms suitable to an organization is strongly
dependent on an organization's needs for security, organizational size, and other organization specific factors.
Criteria
The criteria used as the basis for assigning a value to each asset should be written out in unambiguous terms.
This is often one of the most difficult aspects of asset valuation since the values of some assets may have to
be subjectively determined and since many different individuals are likely to be making the determination.
Possible criteria used to determine an asset’s value include its original cost, its replacement or re-creation cost
or its value may be abstract, e.g. the value of an organization’s reputation.
Another basis for the valuation of assets is the costs incurred due to the loss of confidentiality, integrity and
availability as the result of an incident. Non-repudiation, accountability, authenticity and reliability should also
be considered, as appropriate. Such a valuation would provide the important element dimensions to asset
value, in addition to replacement cost, based on estimates of the adverse business consequences that would
result from security incidents with an assumed set of circumstances. It is emphasized that this approach
accounts for consequences that are necessary to factor into the risk assessment.

ISO/IEC 27005:2011(E)
Many assets may during the course of valuation have several values assigned. For example: a business plan
may be valued based on the labour expended to develop the plan, it might be valued on the labour to input the
data, and it could be valued based on its value to a competitor. Each of the assigned values will most likely
differ considerably. The assigned value may be the maximum of all possible values or may be the sum of
some or all of the possible values. In the final analysis, which value or values are assigned to an asset should
be carefully determined since the final value assigned enters into the determination of the resources to be
expended for the protection of the asset.
Reduction to the common base
Ultimately, all asset valuations need to be reduced to a common base. This may be done with the aid of
criteria such as those that follow. Criteria that may be used to assess the possible consequences resulting
from a loss of confidentiality, integrity, availability, non-repudiation, accountability, authenticity, or reliability of
assets are:
 Violation of legislation and/or regulation

 Impairment of business performance
 Loss of goodwill/negative effect on reputation
 Breach associated with personal information
 Endangerment of personal safety
 Adverse effects on law enforcement
 Breach of confidentiality
 Breach of public order
 Financial loss
 Disruption to business activities
 Endangerment of environmental safety
Another approach to assess the consequences could be:

 Interruption of service
 inability to provide the service
 Loss of customer confidence
 loss of credibility in the internal information system
 damage to reputation
 Disruption of internal operation
 disruption in the organization itself
 additional internal cost
 Disruption of a third party's operation:
 disruption in third parties transacting with the organization
 various types of injury
 Infringement of laws / regulations:
 inability to fulfill legal obligations
 Breach of contract:
 inability to fulfill contractual obligations
 Danger to personnel / user safety:
 danger for the organization's personnel and / or users
 Attack on users' private life
 Financial losses
 Financial costs for emergency or repair:
 in terms of personnel,
 in terms of equipment,
 in terms of studies, experts' reports
 Loss of goods / funds / assets
 Loss of customers, loss of suppliers
 Judicial proceedings and penalties
 Loss of a competitive advantage
 Loss of technological / technical lead
 Loss of effectiveness / trust
 Loss of technical reputation
 Weakening of negotiating capacity

ISO/IEC 27005:2011(E)
 Industrial crisis (strikes)

 Government crisis
 Dismissal
 Material damage
These criteria are examples of issues to be considered for asset valuation. For carrying out valuations, an
organization needs to select criteria relevant to its type of business and security requirements. This might
mean that some of the criteria listed above are not applicable, and that others might need to be added to the
list.
Scale
After establishing the criteria to be considered, the organization should agree on a scale to be used
organization-wide. The first step is to decide on the number of levels to be used. There are no rules with
regard to the number of levels that are most appropriate. More levels provide a greater level of granularity but
sometimes a too fine differentiation makes consistent assignments throughout the organization difficult.
Normally, any number of levels between 3 (e.g. low, medium, and high) and 10 can be used as long as it is
consistent with the approach the organization is using for the whole risk assessment process.
An organization may define its own limits for asset values, like “low”, “medium”, or “high”. These limits should
be assessed according to the criteria selected (e.g. for possible financial loss, they should be given in
monetary values, but for considerations such as endangerment of personal safety, monetary valuation can be
complex and may not be appropriate for all organizations). Finally, it is entirely up to the organization to decide
what is considered as being “low” or a “high” consequence. A consequence that might be disastrous for a
small organization could be low or even negligible for a very large organization.
Dependencies
The more relevant and numerous the business processes supported by an asset, the greater the value of this
asset. Dependencies of assets on business processes and other assets should be identified as well since this
might influence the values of the assets. For example, the confidentiality of data should be kept throughout its
life-cycle, at all stages, including storage and processing, i.e. the security needs of data storage and
processing programmes should be directly related to the value representing the confidentiality of the data
stored and processed. Also, if a business process is relying on the integrity of certain data being produced by
a programme, the input data of this programme should be of appropriate reliability. Moreover, the integrity of
information will be dependent on the hardware and software used for its storage and processing. Also, the
hardware will be dependent on the power supply and possibly air conditioning. Thus information about
dependencies will assist in the identification of threats and particularly vulnerabilities. Additionally, it will help to
assure that the true value of the assets (through the dependency relationships) is given to the assets, thereby
indicating the appropriate level of protection.
The values of assets on which other assets are dependent may be modified in the following way:
 If the values of the dependent assets (e.g. data) are lower or equal to the value of the asset
considered (e.g. software), its value remains the same
 If the values of the dependent asset (e.g. data) is greater, then the value of the asset considered (e.g.
software) should be increased according to:
- The degree of dependency

- The values of the other assets
An organization may have some assets that are available more than once, like copies of software
programmes or the same type of computer used in most of the offices. It is important to consider this fact
when doing the asset valuation. On one hand, these assets are overlooked easily, therefore care should be
taken to identify all of them; on the other hand, they could be used to reduce availability problems.

ISO/IEC 27005:2011(E)
Output
The final output of this step is a list of assets and their values relative to disclosure (preservation of
confidentiality), modification (preservation of integrity, authenticity, non-repudiation and accountability), non-
availability and destruction (preservation of availability and reliability), and replacement cost.
B.3 Impact assessment

An information security incident can impact more than one asset or only a part of an asset. Impact is related to
the degree of success of the incident. As a consequence, there is an important difference between the asset
value and the impact resulting from the incident. Impact is considered as having either an immediate
(operational) effect or a future (business) effect that includes financial and market consequences.
Immediate (operational) impact is either direct or indirect.
Direct:
a) The financial replacement value of lost (part of) asset
b) The cost of acquisition, configuration and installation of the new asset or back-up
c) The cost of suspended operations due to the incident until the service provided by the asset(s) is restored
d) Impact results in a information security breach
Indirect:
a) Opportunity cost (financial resources needed to replace or repair an asset would have been used
elsewhere)
b) The cost of interrupted operations
c) Potential misuse of information obtained through a security breach
d) Violation of statutory or regulatory obligations
e) Violation of ethical codes of conduct
As such, the first assessment (with no controls of any kind) will estimate an impact as very close to the
(combination of the) concerned asset value(s). For any next iteration for this (these) asset(s), the impact will
be different (normally much lower) due to the presence and the effectiveness of the implemented controls.

ISO/IEC 27005:2011(E)
Annex C
(informative)
Examples of typical threats
The following table gives examples of typical threats. The list can be used during the threat assessment
process. Threats may be deliberate, accidental or environmental (natural) and may result, for example, in
damage or loss of essential services. The following list indicates for each threat type where D (deliberate), A
(accidental), E (environmental) is relevant. D is used for all deliberate actions aimed at information assets, A is
used for all human actions that can accidentally damage information assets, and E is used for all incidents that
are not based on human actions. The groups of threats are not in priority order.
Type Threats Origin

Fire A, D, E
Water damage A, D, E
Pollution A, D, E
Physical damage
Major accident A, D, E
Destruction of equipment or media A, D, E
Dust, corrosion, freezing A, D, E
Climatic phenomenon E
Seismic phenomenon E
Natural events Volcanic phenomenon E
Meteorological phenomenon E
Flood E
Failure of air-conditioning or water supply system A, D
Loss of essential
Loss of power supply A, D, E
services
Failure of telecommunication equipment A, D
Electromagnetic radiation A, D, E
Disturbance due to
Thermal radiation A, D, E
radiation
Electromagnetic pulses A, D, E
Interception of compromising interference signals D
Remote spying D
Eavesdropping D
Theft of media or documents D
Theft of equipment D
Compromise of Retrieval of recycled or discarded media D
information
Disclosure A, D
Data from untrustworthy sources A, D
Tampering with hardware D
Tampering with software A, D
Position detection D

ISO/IEC 27005:2011(E)
Type Threats Origin

Equipment failure A
Equipment malfunction A
Technical failures Saturation of the information system A, D
Software malfunction A
Breach of information system maintainability A, D
Unauthorised use of equipment D
Fraudulent copying of software D
Unauthorised Use of counterfeit or copied software A, D
actions
Corruption of data D
Illegal processing of data D
Error in use A
Abuse of rights A, D
Compromise of Forging of rights D
functions
Denial of actions D
Breach of personnel availability A, D, E
Particular attention should be paid to human threat sources. These are specifically itemized in the following
table:
Origin of threat Motivation Possible consequences

Challenge • Hacking
Ego • Social engineering
Hacker, cracker Rebellion • System intrusion, break-ins
Status • Unauthorized system access
Money
Destruction of information • Computer crime (e.g. cyber stalking)
Illegal information disclosure • Fraudulent act (e.g.
replay, impersonation,
Monetary gain
Computer criminal interception)
Unauthorized data alteration
• Information bribery
• Spoofing
• System intrusion
Blackmail • Bomb/Terrorism
Destruction • Information warfare
Exploitation • System attack (e.g. distributed denial
Terrorist of service)
Revenge
• System penetration
Political Gain
• System tampering
Media Coverage

ISO/IEC 27005:2011(E)
Origin of threat Motivation Possible consequences

Competitive advantage • Defence advantage
Economic espionage • Political advantage
• Economic exploitation
Industrial espionage
(Intelligence, • Information theft
companies, foreign • Intrusion on personal privacy
governments, other
government • Social engineering
interests) • System penetration
• Unauthorized system access (access
to classified, proprietary, and/or
technology-related information)
Curiosity • Assault on an employee
Ego • Blackmail
Intelligence • Browsing of proprietary information
Monetary gain • Computer abuse
Revenge • Fraud and theft
Insiders Unintentional errors and omissions • Information bribery
(poorly trained, (e.g. data entry error, programming error)
disgruntled, • Input of falsified, corrupted data
malicious, • Interception
negligent,
dishonest, or • Malicious code (e.g. virus, logic bomb,
terminated Trojan horse)
employees)
• Sale of personal information
• System bugs
• System intrusion
• System sabotage
• Unauthorized system access
ISO/IEC 27005:2011(E)
Annex D
(informative)
Vulnerabilities and methods for vulnerability assessment
D.1 Examples of vulnerabilities

The following table gives examples for vulnerabilities in various security areas, including examples of threats
that might exploit these vulnerabilities. The lists can provide help during the assessment of threats and
vulnerabilities, to determine relevant incident scenarios. It is emphasized that in some cases other threats may
exploit these vulnerabilities as well.
Types Examples of vulnerabilities Examples of threats

Insufficient maintenance/faulty installation Breach of informationsystem
of storage media maintainability
Lack of periodic replacement schemes Destruction of equipment or media
Susceptibility to humidity, dust, soiling Dust, corrosion, freezing
Sensitivity to electromagnetic radiation Electromagnetic radiation
Lack of efficient configuration change
Error in use
Hardware control
Susceptibility to voltage variations Loss of power supply
Susceptibility to temperature variations Meteorological phenomenon
Unprotected storage Theft of media or documents
Lack of care at disposal Theft of media or documents
Uncontrolled copying Theft of media or documents
No or insufficient software testing Abuse of rights
Well-known flaws in the software Abuse of rights
No 'logout' when leaving the workstation Abuse of rights
Disposal or reuse of storage media without
Abuse of rights
proper erasure
Lack of audit trail Abuse of rights
Wrong allocation of access rights Abuse of rights
Software Widely-distributed software Corruption of data
Applying application programs tothe
Corruption of data
wrong data in terms of time
Complicated user interface Error in use
Lack of documentation Error in use
Incorrect parameter set up Error in use
Incorrect dates Error in use

ISO/IEC 27005:2011(E)
Lack of identification and authentication

Forging of rights
mechanisms like user authentication
Unprotected password tables Forging of rights
Poor password management Forging of rights
Unnecessary services enabled Illegal processing of data
Immature or new software Software malfunction
Unclear or incomplete specifications for

Software malfunction
developers
Lack of effective change control Software malfunction
Uncontrolled downloading and use of
Tampering with software
software
Lack of back-up copies Tampering with software
Lack of physical protection of the building,
Theft of media or documents
doors and windows
Failure to produce management reports Unauthorised use of equipment
Lack of proof of sending or receiving a
Denial of actions
message
Unprotected communication lines Eavesdropping
Unprotected sensitive traffic Eavesdropping
Poor joint cabling Failure of telecommunication equipment
Single point of failure Failure of telecommunication equipment
Red Lack of identification and authentication of
Forging of rights
sender and receiver
Insecure network architecture Remote spying
Transfer of passwords in clear Remote spying
Inadequate networkmanagement
Saturation of the information system
(resilience of routing)
Unprotected public network connections Unauthorised use of equipment
Absence of personnel Breach of personnel availability
Inadequate recruitment procedures Destruction of equipment or media
Insufficient security training Error in use
Incorrect use of software and hardware Error in use
Personal Lack of security awareness Error in use

Lack of monitoring mechanisms Illegal processing of data
Unsupervised work by outside or cleaning
staff
Lack of policies for the correct use of
Unauthorised use of equipment
telecommunications media and messaging

ISO/IEC 27005:2011(E)
Inadequate or careless use of physical

Destruction of equipment or media
access control to buildings and rooms
Location in an area susceptible to flood Flood
Sitio
Unstable power grid Loss of power supply
Lack of physical protection of the building,
Theft of equipment
doors and windows
Lack of formal procedure foruser
Organización Abuse of rights
registration and de-registration
Lack of formal process for access right
Abuse of rights
review (supervision)
Lack or insufficient provisions (concerning
security) in contracts with customers Abuse of rights
and/or third parties
Lack of procedure of monitoringof

Abuse of rights
information processing facilities
Lack of regular audits (supervision) Abuse of rights

Lack of procedures of risk identification
Abuse of rights
and assessment
Lack of fault reports recordedin
Abuse of rights
administrator and operator logs
Breach of informationsystem
Inadequate service maintenance response
maintainability
Lack or insufficient ServiceLevel Breach of informationsystem
Agreement maintainability
Breach of informationsystem
Lack of change control procedure
maintainability
Lack of formal procedure forISMS
Corruption of data
documentation control
Lack of formal procedure for ISMS record
Corruption of data
supervision
Lack of formal process for authorization of
Data from untrustworthy sources
public available information
Lack of proper allocation of information
Denial of actions
security responsibilities
Lack of continuity plans Equipment failure
Lack of e-mail usage policy Error in use
Lack of procedures forintroducing
Error in use
software into operational systems
Lack of records in administrator and
Error in use
operator logs
Lack of procedures forclassified
Error in use
information handling
Lack of information security responsibilities
Error in use
in job descriptions

ISO/IEC 27005:2011(E)
Lack or insufficient provisions (concerning

information security) in contracts with Illegal processing of data
employees
Lack of defined disciplinary process in
Theft of equipment
case of information security incident
Lack of formal policy on mobile computer
Theft of equipment
usage
Lack of control of off-premise assets Theft of equipment
Lack or insufficient 'clear desk and clear
screen' policy
Lack of information processing facilities
authorization
Lack of establishedmonitoring
mechanisms for security breaches
Lack of regular management reviews Unauthorised use of equipment
Lack of procedures for reporting security
Unauthorised use of equipment
weaknesses
Lack of procedures ofprovisions
Use of counterfeit or copied software
compliance with intellectual rights
D.2 Methods for assessment of technical vulnerabilities
Proactive methods such as information system testing can be used to identify vulnerabilities depending on the
criticality of the Information and Communications Technology (ICT) system and available resources (e.g.
allocated funds, available technology, persons with the expertise to conduct the test). Test methods include:
 Automated vulnerability scanning tool

 Security testing and evaluation
 Penetration testing
 Code review
The automated vulnerability scanning tool is used to scan a group of hosts or a network for known vulnerable
services (e.g. system allows anonymous File Transfer Protocol (FTP), sendmail relaying). It should be noted,
however, that some of the potential vulnerabilities identified by the automated scanning tool may not represent
real vulnerabilities in the context of the system environment. For example, some of these scanning tools rate
potential vulnerabilities without considering the site’s environment and requirements. Some of the
vulnerabilities flagged by the automated scanning software may actually not be vulnerable for a particular site
but may be configured that way because their environment requires it. Thus, this test method may produce
false positives.
Security testing and evaluation (STE) is another technique that can be used in identifying ICT system
vulnerabilities during the risk assessment process. It includes the development and execution of a test plan
(e.g. test script, test procedures, and expected test results). The purpose of system security testing is to test
the effectiveness of the security controls of an ICT system as they have been applied in an operational
environment. The objective is to ensure that the applied controls meet the approved security specification for
the software and hardware and implement the organization’s security policy or meet industry standards.

Ann McSweeney.
ISO/IEC 27005:2011(E)
Penetration testing can be used to complement the review of security controls and ensure that different facets
of the ICT system are secured. Penetration testing, when used in the risk assessment process, can be used to
assess an ICT system’s ability to withstand intentional attempts to circumvent system security. Its objective is
to test the ICT system from the viewpoint of a threat source and to identify potential failures in the ICT system
protection schemes.
Code review is the most thorough (but also most expensive) way of vulnerability assessment.
The results of these types of security testing will help identify a system’s vulnerabilities.
It is important to note that penetration tools and techniques can give false results unless the vulnerability is
successfully exploited. To exploit particular vulnerabilities one needs to know the exact system/ application/
patches setup on tested system. If those data are not known at the time of testing, it might not be possible to
successfully exploit particular vulnerability (for example, gaining remote reverse shell); however, it is still
possible to crash or restart a tested process or system. In such a case, the tested object should be considered
vulnerable as well.
Methods may include the following activities:
 Interview people and users

 Questionnaires
 Physical inspection
 Document analysis

se imprime.
Ann McSweeney.

se imprime.
ISO/IEC 27005:2011(E)
Annex E
(informative)
Information security risk assessment approaches
E.1 High-level information security risk assessment

The high-level assessment allows definition of the priorities and chronology in the actions. For various
reasons, such as budget, it may not be possible to implement all controls simultaneously and only the most
critical risks can be addressed through the risk treatment process. As well, it can be premature to begin
detailed risk management if implementation is only envisaged after one or two years. To reach this objective,
the high-level assessment may begin with a high-level assessment of consequences instead of starting with a
systematic analysis of threats, vulnerabilities, assets and consequences.
Another reason to start with the high-level assessment is to synchronize with other plans related to change
management (or business continuity). For example, it is not sound to completely secure a system or
application if it is planned to outsource it in the near future, although it may still be worth doing the risk
assessment in order to define the outsource contract.
Features of the high-level risk assessment iteration may include the following:
 The high-level risk assessment may address a more global view of the organization and its information
systems, considering the technology aspects as independent from the business issues. By doing this, the
context analysis concentrates more on the business and operational environment than technological
elements.
 The high-level risk assessment may address a more limited list of threats, and vulnerabilities grouped in
defined domains or, to expedite the process, it may focus on risk or attack scenarios instead of their
elements.
 Risks presented in a high-level risk assessment are frequently more general risk domains than specific
identified risks. As the scenarios or the threats are grouped in domains, the risk treatment proposes lists of
controls in this domain. The risk treatment activities try then first to propose and select common controls
that are valid across the whole system.
 However, the high-level risk assessment, because it seldom addresses technology details, is more
appropriate to provide organizational and non-technical controls and management aspects of technical
controls, or key and common technical safeguards such as back-ups and anti-virus.
The advantages of a high-level risk assessment are as follows:
 The incorporation of an initial simple approach is likely to gain acceptance of the risk assessment
program.
 It should be possible to build a strategic picture of an organizational information security program, i.e. it
will act as a good planning aid.
 Resources and money can be applied where they are most beneficial, and systems likely to be in the
greatest need of protection will be addressed first.
As the initial risk analyses are at a high level, and potentially less accurate, the only potential disadvantage is
that some business processes or systems may not be identified as requiring a second, detailed risk
assessment. This can be avoided if there is adequate information on all aspects of the organization and its
information and systems, including information gained from the evaluation of information security incidents.
The high-level risk assessment considers the business values of the information assets, and the risks from the
organization's business point of view. At the first decision point (see Figure 2), several factors assist in
determining whether the high-level assessment is adequate to treat risks; these factors may include the
following:

ISO/IEC 27005:2011(E)
 The business objectives to be achieved by using various information assets;

 The degree to which the organization's business depends on each information asset, i.e. whether
functions that the organization considers critical to its survival or the effective conduct of business are
dependent on each asset, or on the confidentiality, integrity, availability, non-repudiation, accountability,
authenticity, and reliability of the information stored and processed on this asset;
 The level of investment in each information asset, in terms of developing, maintaining, or replacing the
asset, and
 The information assets, for which the organization directly assigns value.
When these factors are assessed, the decision becomes easier. If the objectives of an asset are extremely
important to an organization's conduct of business, or if the assets are at high risk, then a second iteration, the
detailed risk assessment, should be conducted for the particular information asset (or part thereof).
A general rule to apply is: if the lack of information security can result in significant adverse consequences to
an organization, its business processes or its assets, then a second iteration risk assessment, at more
detailed level, is necessary to identify potential risks.
E.2 Detailed information security risk assessment

The detailed information security risk assessment process involves in-depth identification and valuation of
assets, the assessment of threats to those assets, and assessment of vulnerabilities. The results from these
activities are then used to assess the risks and then identify risk treatment.
The detailed step usually requires considerable time, effort and expertise, and may therefore be most suitable
for information systems at high risk.
The final stage of the detailed information security risk assessment is to assess the overall risks, which is the
focus of this annex.
Consequences may be assessed in several ways, including using quantitative, e.g. monetary, and qualitative
measures (which can be based on the use of adjectives such as moderate or severe), or a combination of
both. To assess the likelihood of threat occurrence, the time frame over which the asset will have value or
needs to be protected should be established. The likelihood of a specific threat occurring is affected by the
following:
 The attractiveness of the asset, or possible impact applicable when a deliberate human threat is being
considered
 The ease of conversion exploiting a vulnerability of the asset into reward, applicable if a deliberate human
threat is being considered
 The technical capabilities of the threat agent, applicable to deliberate human threats, and
 The susceptibility of the vulnerability to exploitation, applicable to both technical and non-technical
vulnerabilities
Many methods make use of tables, and combine subjective and empirical measures. It is important that the
organization uses a method with which the organization is comfortable, in which the organization has
confidence, and that will produce repeatable results. A few examples of table-based techniques are given
below.
For additional guidance on techniques that can be used for detailed information security risk assessment, see
IEC 31010.
The following examples use numbers to describe qualitative assessments. Users of these methods should be
aware that it might be invalid to perform further mathematical operations using the numbers that are qualitative
results produced by qualitative risk assessment methods.

ISO/IEC 27005:2011(E)
E.2.1 Example 1 Matrix with predefined values
In risk assessment methods of this type, actual or proposed physical assets are valued in terms of
replacement or reconstruction costs (i.e. quantitative measurements). These costs are then converted onto
the same qualitative scale as that used for information (see below). Actual or proposed software assets are
valued in the same way as physical assets, with purchase or reconstruction costs identified and then
converted to the same qualitative scale as that used for information. Additionally, if any application software is
found to have its own intrinsic requirements for confidentiality or integrity (for example if source code is itself
commercially sensitive), it is valued in the same way as for information.
The values for information are obtained by interviewing selected business management (the “data owners”)
who can speak authoritatively about the data, to determine the value and sensitivity of the data actually in use,
or to be stored, processed or accessed. The interviews facilitate assessment of the value and sensitivity of the
information in terms of the worst case scenarios that could be reasonably expected to happen from adverse
business consequences due to unauthorized disclosure, unauthorized modification, non-availability for varying
time periods, and destruction.
The valuation is accomplished using information valuation guidelines, which cover such issues as:
 Personal safety
 Personal information and privacy
 Legal and regulatory obligations
 Law enforcement
 Commercial and economic interests
 Financial loss/disruption of activities
 Public order
 Business policy and operations
 Loss of goodwill
 Contract or agreement with a customer
The guidelines facilitate identification of the values on a numeric scale, such as the 0 to 4 scale shown in the
example matrix below, thus enabling the recognition of quantitative values where possible and logical, and
qualitative values where quantitative values are not possible, e.g. for endangerment of human life.
The next major activity is the completion of pairs of questionnaires for each threat type, for each grouping of
assets that a threat type relates to, to enable the assessment of the levels of threats (likelihood of occurrence)
and levels of vulnerabilities (ease of exploitation by the threats to cause adverse consequences). Each
question answer attracts a score. These scores are accumulated through a knowledge base and compared
with ranges. This identifies threat levels on say a high to low scale and vulnerability levels similarly, as shown
in the example matrix below, differentiating between the types of consequences as relevant. Information to
complete the questionnaires should be gathered from interviews with appropriate technical, personnel and
accommodation people, and physical location inspections, and reviews of documentation.
The asset values, and the threat and vulnerability levels, relevant to each type of consequence, are matched
in a matrix such as that shown below, to identify for each combination the relevant measure of risk on a scale
of 0 to 8. The values are placed in the matrix in a structured manner. An example is given below:

Copyrighted material licensed to Dublin Institute of Technology by SAI Global (www.saiglobal.com), downloaded on 31
Dec 11 No further reproduction or distribution is permitted. Uncontrolled when printed.
ISO/IEC 27005:2011(E)
Table E.1 a)
Likelihood of
occurrence – Low Medium High
Threat
Ease of
L M H L M H L M H
Exploitation
0 0 1 2 1 2 3 2 3 4
1 1 2 3 2 3 4 3 4 5
Asset 2 2 3 4 3 4 5 4 5 6
Value
3 3 4 5 4 5 6 5 6 7
4 4 5 6 5 6 7 6 7 8
For each asset, the relevant vulnerabilities and their corresponding threats are considered. If there is a
vulnerability without a corresponding threat, or a threat without corresponding vulnerability, there is presently
no risk (but care should be taken in case this situation changes). Now the appropriate row in the matrix is
identified by the asset value, and the appropriate column is identified by the likelihood of the threat occurring
and the ease of exploitation. For example, if the asset has the value 3, the threat is “high” and the vulnerability
“low”, the measure of risk is 5. Assume an asset has a value of 2, e.g. for modification, the threat level is “low”
and the ease of exploitation is “high”, then the measure of risk is 4. The size of the matrix, in terms of the
number of threat likelihood categories, ease of exploitation categories and the number of asset valuation
categories, can be adjusted to the needs of the organization. Additional columns and rows will necessitate
additional risk measures. The value of this approach is in ranking the risks to be addressed.
A similar Matrix as shown in Table E.1 b) results from the consideration of the likelihood of an incident
scenario, mapped against the estimated business impact. The likelihood of an incident scenario is given by a
threat exploiting a vulnerability with a certain likelihood. The Table maps this likelihood against the business
impact related to the incident scenario. The resulting risk is measured on a scale of 0 to 8 that can be
evaluated against risk acceptance criteria. This risk scale could also be mapped to a simple overall risk rating,
for example as:
 Low risk: 0-2

 Medium Risk: 3-5
 High Risk:6-8
Table E.1 b)
Likelihood of
Very Low Low Medium High Very High
incident
(Very Unlikely) (Unlikely) (Possible) (Likely) (Frequent)
scenario
Very Low 0 1 2 3 4
Low 1 2 3 4 5
Business
Medium 2 3 4 5 6
Impact
High 3 4 5 6 7
Very High 4 5 6 7 8

Copyrighted material licensed to Dublin Institute of Technology by SAI Global (www.saiglobal.com), downloaded on 31 Dec 11
Copyrighted material licensed to Dublin Institute of Technology by SAI Global (www.saiglobal.com), downloaded on 31 Dec 11 by Ann McSweeney
No further reproduction or distribution is permitted. Uncontrolled when printed.
ISO/IEC 27005:2011(E)
E.2.2 Example 2 Ranking of Threats by Measures of Risk
A matrix or table such as that shown in Table E.2 can be used to relate the factors of consequences (asset
value) and likelihood of threat occurrence (taking account of vulnerability aspects). The first step is to evaluate
the consequences (asset value) on a predefined scale, e.g. 1 through 5, of each threatened asset (column “b”
in the table). The second step is to evaluate the likelihood of threat occurrence on a predefined scale, e.g. 1
through 5, of each threat (column “c” in the table). The third step is to calculate the measure of risk by
multiplying (b  c). Finally the threats can be ranked in order of their associated measure of risk. Note that in
this example, 1 is taken as the lowest consequence and the lowest likelihood of occurrence.
Table E.2
Threat descriptor Consequence Likelihood of threat Measure of risk Threat ranking

(asset) value occurrence
(a) (d) (e)
(b) (c)
Threat A 5 2 10 2
Threat B 2 4 8 3
Threat C 3 5 15 1
Threat D 1 3 3 5
Threat E 4 1 4 4
Threat F 2 4 8 3
As shown above, this is a procedure which permits different threats with differing consequences and likelihood
of occurrence to be compared and ranked in order of priority, as shown here. In some instances it will be
necessary to associate monetary values with the empirical scales used here.
E.2.3 Example 3 Assessing a value for the likelihood and the possible consequences of
risks
In this example, the emphasis is placed on the consequences of information security incidents (i.e. incident
scenarios) and on determining which systems should be given priority. This is done by assessing two values
for each asset and risk, which in combination will determine the score for each asset. When all the asset
scores for the system are summed, a measure of risk to that system is determined.
First, a value is assigned to each asset. This value relates to the potential adverse consequences that can
arise if the asset is threatened. For each applicable threat to the asset, this asset value is assigned to the
asset.
Next a likelihood value is assessed. This is assessed from a combination of the likelihood of the threat
occurring and the ease of exploitation of the vulnerability, see Table E.3 expressing the likelihood of an
incident scenario.
Table E.3
Likelihood of Threat Low Medium High

Levels of L M H L M H L M H
Vulnerability
Likelihood Value of 0 1 2 1 2 3 2 3 4
an incident scenario

Copyrighted material licensed to Dublin Institute of Technology by SAI Global (www.saiglobal.com), downloaded on 31 Dec 11 by Ann McSweeney
No further reproduction or distribution is permitted. Uncontrolled when printed.
ISO/IEC 27005:2011(E)
Next, an asset/threat score is assigned by finding the intersection of asset value and likelihood value in
Table E.4. The asset/threat scores are totalled to produce an asset total score. This figure can be used to
differentiate between the assets forming part of a system.
Table E.4
Asset Value 0 1 2 3 4
Likelihood Value
0 0 1 2 3 4
1 1 2 3 4 5
2 2 3 4 5 6
3 3 4 5 6 7
4 4 5 6 7 8
The final step is to total all the asset total scores for the assets of the system, producing a system score. This
can be used to differentiate between systems and to determine which system's protection should be given
priority.
In the following examples all values are randomly chosen.
Suppose System S has three assets A1, A2 and A3. Also suppose there are two threats T1 and T2 applicable
to system S. Let the value of A1 be 3, similarly let the asset value of A2 be 2 and the asset value of A3 be 4.
If for A1 and T1 the threat likelihood is low and the ease of exploitation of the vulnerability is medium, then the
likelihood value is 1 (see Table E.3).
The asset/threat score A1/T1 can be derived from Table E.4 as the intersection of asset value 3 and likelihood
value 1, i.e. 4. Similarly, for A1/T2 let the threat likelihood is medium and the ease of exploitation of
vulnerability is high, giving an A1/T2 score of 6.
Now the total asset score A1T can be calculated, i.e. 10. The total asset score is calculated for each asset and
applicable threat. The total system score is calculated by adding A1T + A2T + A3T to give ST.
Now different systems can be compared to establish priorities and different assets within one system as well.
Above example shows in terms of information systems, however similar approach can be applied to business
processes.
ISO/IEC 27005:2011(E)
Annex F
(informative)
Constraints for risk modification
While considering constraints for risk modification the following constraints should be taken into account:
Time constraints:
Many types of time constraints can exist. For example, controls should be implemented within a time period
acceptable for the organization’s managers. Another type of time constraint is whether a control can be
implemented within the lifetime of the information or system. A third type of time constraint may be the period
of time the organization’s managers decides is an acceptable period to be exposed to a particular risk.
Financial constraints:
Controls should not be more expensive to implement or to maintain than the value of risks they are designed
to protect, except where compliance is mandatory (e.g. with legislation). Every effort should be made not to
exceed assigned budgets and achieve financial advantage through the use of controls. However, in some
cases it may not be possible to achieve the desired security and level of risk acceptance due to budget
constraints. This therefore becomes an organization’s managers’ decision for resolution of this situation.
Great care should be taken if the budget reduces the number or quality of controls to be implemented since
this can lead to the implicit retention of greater risk than planned. The established budget for controls should
only be used as a limiting factor with considerable care.
Technical constraints:
Technical problems, like the compatibility of programmes or hardware, can easily be avoided if they are taken
into account during the selection of controls. In addition, the retrospective implementation of controls to an
existing process or system is often hindered by technical constraints. These difficulties may move the balance
of controls towards the procedural and physical aspects of security. It may be necessary to revise the
information security programme in order to achieve security objectives. This can occur when controls do not
meet the expected results in reducing risks without lessening productivity.
Operational constraints
Operational constraints such as the need to operate 24x7 yet still perform back-ups can result in complex and
costly implementation of controls unless they are built into the design right from the start.
Cultural constraints:
Cultural constraints to the selection of controls may be specific to a country, a sector, an organization or even
a department within an organization. Not all controls can be applied in all countries. For example, it may be
possible to implement bag searches in parts of Europe but not in parts of the Middle East. Cultural aspects
cannot be ignored because many controls rely on the active support of the staff. If the staff does not
understand the need for the control or do not find it culturally acceptable, the control will become ineffective
over time.
Ethical constraints:
Ethical constraints can have major implications on controls as ethics change based on social norms. This can
prevent implementing controls such as email scanning in some countries. Privacy of information can also
change dependent on the ethics of the region or government. These may be of more concern in some industry
sectors than others, for example, government and healthcare.

ISO/IEC 27005:2011(E)
Environmental constraints:
Environmental factors may influence the selection of controls, such as space availability, extreme climate
conditions, surrounding natural and urban geography. For example earthquake proofing may be required in
some countries but unnecessary in others.
Legal constraints:
Legal factors such as personal data protection or criminal code provisions for information processing could
affect the selection of controls. Legislative and regulatory compliance can mandate certain types of control
including data protection and financial audit; they can also prevent the use of some controls, e.g. encryption.
Other laws and regulations such as labour relations legislation, fire department, health and safety, and
economic sector regulations, etc., could affect control selection as well.
Ease of use:
A poor human-technology interface will result in human error and may render the control useless. Controls
should be selected to provide optimal ease of use while achieving an acceptable level of residual risk to the
business. Controls that are difficult to use will impact their effectiveness, as users may try to circumvent or
ignore them as much as possible. Complex access controls within an organization could encourage users to
find alternate, unauthorized methods of access.
Personnel constraints:
The availability and salary cost of specialized skill sets to implement controls, and the ability to move staff
between locations in adverse operating conditions, should be considered. Expertise may not be readily
available to implement planned controls or the expertise may be overly costly for the organization. Other
aspects such as the tendency of some staff to discriminate other staff members who are not security screened
can have major implications for security policies and practices. As well, the need to hire the right people for
the work, and finding the right people, may result in hiring before security screening is completed. The
requirement for security screening to be completed before hiring is the normal, and safest, practice.
Constraints of integrating new and existing controls:
Integration of new controls in the existing infrastructure and the interdependencies between controls are often
overlooked. New controls may not easily be implemented if there is incongruity or incompatibility with existing
controls. For example, a plan to use biometric tokens for physical access control may cause conflict with an
existing PIN-pad based system for access control. The cost of changing controls from existing controls to the
planned controls should include elements to be added to the overall costs of risk treatment. It may not be
possible to implement a selected control due to interference with current controls.

Mate58
Annex G IS Mate
rial rial
O/
con
dere
(informative) IE
con
dere
chos chos
de C de
autor Differences in definitions between ISO/IEC 27005:2008 and ISO/IEC 27005:2011 27 autor
licen licen
ciad
00 ciad
o al 5: o al
Instit 20 Instit
uto uto
de NOTE: This Annex is dedicated for ISO/IEC 27001:2005 users. As some terms and definitions are different in ISO Guide 73:2009 comparing with those used in ISO/IEC 11 de
Tecn 27001:2005, and subsequently in ISO/IEC 27005:2008, this Annex summarises all relevant changes. (E Tecn
ologí ologí
a de a de
Dublí Terms defined in ISO/IEC 27005:2008 Terms defined in ISO/IEC 27000:2009 Terms defined in ISO Guide 73:2009 used in ISO/IEC 27005:2011 Dublí
n por used in ISO/IEC 27005:2008 n por
SAI SAI
Glob n/a n/a 3.1 Glob
al consecuencia al
(ww (ww
w.sai resultado de un evento (3.3) que afecte a los w.sai
glob glob
al.co objetivos [Guía ISO 73:2009] al.co
m), m),
desc desc
arga NOTA1 Un evento puede llevar a una serie de consecuencias. arga
do el do el
31 31
de NOTE 2 A consequence can be certain or uncertain and in the context of de
dicie information security is usually negative. dicie
mbre mbre
11 11
por NOTE 3 Consequences can be expressed qualitatively or quantitatively. por
Ann Ann
McS McS
NOTE 4 Initial consequences can escalate through knock-on effects.
wee wee
ney. ney.
No n/a control 3.2 No
se se
per © means of managing risk, including control per
mite IS policies, procedures, guidelines, medida que está modificando el mite
ning practices or ning
O/
una una
otra IE organizational structures, which can be riesgo (3.9) [Guía ISO 73:2009] otra
repr C administrative, technical, management, repr
odu 20 or legal in nature NOTE 1 Controls for information security include any process, policy, odu
cció 11 cció
no – procedure, guideline, practice or organizational structure, which can be no
distr All NOTE Control is also used as a synonym for administrative, technical, management, or legal in nature which modify distr
ibuc rig safeguard or countermeasure. information security risk. ibuc
ión. ht ión.
No s No
se re [ISO/IEC 27002:2005] NOTE 2 Controls may not always exert the intended or assumed se
cont se cont
rola rv rola
cua cua
ndo ndo
se se
imp imp
Mate Mate
rial rial
con con
dere dere
chos © Terms defined in ISO/IEC 27005:2008 Terms defined in ISO/IEC 27000:2009 Terms defined in ISO Guide 73:2009 used in ISO/IEC 27005:2011 chos
de IS de
autor O/ used in ISO/IEC 27005:2008 autor
licen IE modifying effect. licen
ciad C ciad
o al 20 o al
Instit 11 NOTE 3Control is also used as a synonym for safeguard or Instit
uto – countermeasure. uto
de All de
Tecn Tecn
rig
ologí ologí
a de ht a de
Dublí s Dublí
n por re n por
SAI se SAI
Glob rv Glob
al al
(ww (ww
w.sai w.sai
glob glob
al.co al.co
m), n/a n/a 3.3 m),
desc evento desc
arga arga
do el ocurrencia o cambio de un conjunto de circunstancias do el
31 31
de particulares [Guía ISO 73:2009] de
dicie dicie
mbre mbre
11 NOTE 1 An event can be one or more occurrences, and can have several 11
por causes. por
Ann Ann
McS McS
wee NOTE 2 An event can consist of something not happening. wee
ney. ney.
No No
se NOTE 3 An event can sometimes be referred to as an “incident” or se
per “accident”. per
mite mite
ning ning
una n/a n/a 3.4 una
otra contexto externo otra
repr repr
external environment in which the organization seeks to achieve its
odu IS odu
cció objectives cció
no [Guía ISO 73:2009] O/ no
distr IE distr
ibuc ibuc
ión. NOTE El contexto externo puede incluir: C ión.
No ⎯ the cultural, social, political, legal, regulatory, financial, 27 No
se technological, economic, natural and competitive environment, se
cont 00 cont
whether international, national, regional or local;
rola 5: rola
cua ⎯ key drivers and trends having impact on the objectives of the cua
ndo organization; and 20 ndo
se 59 ⎯ relationships with, and perceptions and values of, external 11 se
imp imp
(E
Mate60 Terms defined in ISO/IEC 27005:2008 Terms defined in ISO/IEC 27000:2009 Terms defined in ISO Guide 73:2009 used in ISO/IEC 27005:2011 IS Mate
rial rial
con used in ISO/IEC 27005:2008 O/ con
dere stakeholders. IE dere
chos chos
de C de
autor 27 autor
licen 3.1 The definition has been removed 00 licen
ciad impact ciad
o al 5: o al
Instit adverse change to the level of business Instit
20
uto objectives achieved uto
de 11 de
Tecn (E Tecn
ologí 3.2 The definition has been removed (see NOTE 6 in 3.9) ologí
a de information security risk a de
Dublí Dublí
n por
potential that a given threat will exploit n por
SAI vulnerabilities of an asset or group of SAI
Glob assets and thereby cause harm to the Glob
al al
(ww
organization (ww
w.sai w.sai
glob NOTE It is measured in terms of a glob
al.co al.co
m), combination of the likelihood of an m),
desc event and its consequence. desc
arga arga
do el do el
31 n/a n/a 3.5 31
de contexto interno de
dicie internal environment in which the organization seeks to achieve its dicie
mbre mbre
11 objectives 11
por por
Ann [Guía ISO 73:2009] Ann
McS McS
wee wee
ney. NOTE Internal context can include: ney.
No ⎯ la gobernanza, la estructura organizativa, las funciones y las No
se responsabilidades; se
per per
© ⎯ policies, objectives, and the strategies that are in place to achieve
mite mite
ning IS them; ning
una O/ ⎯ the capabilities, understood in terms of resources and knowledge una
otra IE (e.g. capital, time, people, processes, systems and technologies); otra
repr C repr
odu 20 ⎯ perceptions and values of internal stakeholders; odu
cció 11 ⎯ information systems, information flows and decision-making cció
no – processes (both formal and informal); no
distr All distr
⎯ relationships with, and perceptions and values of, internal
ibuc rig ibuc
ión. ht stakeholders; ión.
No s ⎯ la cultura de la organización; No
se re ⎯ standards, guidelines and models adopted by the organization; se
cont se and cont
rola rv rola
cua ⎯ forma y alcance de las relaciones contractuales. cua
ndo ndo
se se
imp imp
Mate Mate
rial rial
con con
dere dere
de IS de
licen IE licen
ciad C ciad
o al 20
n/a n/a 3.6 o al
Instit 11 nivel de riesgo Instit
uto – magnitude of a risk (3.9), expressed in terms of the combination of uto
de All de
Tecn
consequences (3.1) and their likelihood (3.7) Tecn
rig
ologí ologí
a de ht [ISO Guide 73:2009 a de
Dublí s Dublí
n por re n por
SAI se n/a n/a 3.7 likelihood SAI
Glob rv posibilidad de que algo ocurra Glob
al al
(ww (ww
w.sai [Guía ISO 73:2009] w.sai
glob glob
al.co al.co
m),
NOTE 1 In risk management terminology, the word “likelihood” is used to m),
desc refer to the chance of something happening, whether defined, measured or desc
arga determined objectively or subjectively, qualitatively or quantitatively, and arga
do el described using general terms or mathematically (such as a probability or a do el
31 frequency over a given time period). 31
de de
dicie dicie
mbre NOTE 2 The English term “likelihood” does not have a direct equivalent in some mbre
11 languages; instead, the equivalent of the term “probability” is often used. 11
por However, in English, “probability” is often narrowly interpreted as a por
Ann mathematical term. Therefore, in risk management terminology, “likelihood” is Ann
McS McS
wee used with the intent that it should have the same broad interpretation as the wee
ney. term “probability” has in many languages other than English. ney.
No No
se se
per
n/a riesgo residual 3.8 residual risk per
mite the risk remaining after risk treatment risk remaining after risk treatment mite
ning ning
una una
otra
[ISO/IEC 27001:2005] [ISO Guide 73:2009] otra
repr repr
odu NOTE 1 Residual risk can contain unidentified risk. IS odu
cció cció
no O/ no
NOTE 2 Residual risk can also be known as “retained risk”.
distr IE distr
ibuc ibuc
ión. riesgo 3.9 C ión.
No combination of the probability of an riesgo 27 No
se se
cont event and its consequence effect of uncertainty on objectives 00 cont
rola 5: rola
cua cua
ndo
[ISO/IEC 27002:2005] [Guía ISO 73:2009] 20 ndo
se 61 11 se
imp imp
(E
rial rial
dere NOTE 1 An effect is a deviation from the expected — positive and/or IE dere
chos negative. chos
de C de
autor 27 autor
licen NOTE 2 Objectives can have different aspects (such as financial, health licen
ciad and safety, information security, and environmental goals) and can apply at
00 ciad
o al different levels (such as strategic, organization-wide, project, product and 5: o al
Instit 20 Instit
uto
process). uto
de 11 de
Tecn NOTE 3 Risk is often characterized by reference to potential events (3.3) (E Tecn
ologí and consequences (3.1), or a combination of these. ologí
a de a de
Dublí Dublí
n por NOTE 4 Information security risk is often expressed in terms of a n por
SAI combination of the consequences of an information security event and the SAI
Glob associated likelihood (3.9) of occurrence. Glob
al al
(ww (ww
w.sai NOTE 5 Uncertainty is the state, even partial, of deficiency of information w.sai
glob related to, understanding or knowledge of, an event, its consequence, or glob
al.co likelihood. al.co
m), m),
desc desc
arga NOTE 6 Information security risk is associated with the potential that arga
do el threats will exploit vulnerabilities of an information asset or group of information do el
31 assets and thereby cause harm to an organization. 31
de de
dicie dicie
mbre n/a análisis de riesgos 3.10 mbre
11 systematic use of information to identify análisis de riesgos 11
por por
Ann sources and to estimate risk process to comprehend the nature of risk and to determine the level of Ann
McS risk (3.6) McS
wee NOTE Risk analysis provides a basis for wee
ney. ney.
No risk evaluation, risk treatment and No
[Guía ISO 73:2009]
se risk acceptance se
per per
©
mite NOTE 1 Risk analysis provides the basis for risk evaluation and decisions mite
ning IS [ISO/IEC 27001:2005] ning
una O/ about risk treatment. una
otra IE otra
repr C NOTE 2 Risk analysis includes risk estimation. repr
odu 20 odu
cció 11 cció
no – n/a evaluación de riesgos 3.11 no
distr All overall process of risk analysis and evaluación de riesgos distr
ibuc rig ibuc
ión. ht evaluación de riesgos overall process of risk identification (3.15), risk analysis (3.10) and ión.
No s risk evaluation (3.14) No
se re [ISO/IEC 27001:2005] se
cont se cont
rola rv rola
cua cua
ndo ndo
se se
imp imp
Mate Mate
rial rial
con con
dere dere
de IS de
licen IE [Guía ISO 73:2009] licen
ciad C ciad
o al 20
3.3 This term is currently covered by risk treatment o al
Instit 11 risk avoidance Instit
uto – decision not to become involved in, or uto
de All de
Tecn action to withdraw from, a risk situation Tecn
rig
ologí ologí
a de ht [ISO/IEC Guide 73:2002] a de
Dublí s Dublí
n por re n por
SAI se 3.4 3.12 SAI
Glob rv risk communication comunicación y consulta de riesgos Glob
al al
(ww exchange or sharing of information procesos continuos e iterativos que una organización lleva a cabo para (ww
w.sai about risk between the decision-maker proporcionar, compartir u obtener información, y para entablar un w.sai
glob and other stakeholders diálogo con los interesados (3.18) en relación con la gestión del glob
al.co al.co
m), riesgo (3.9) m),
desc [ISO/IEC Guide 73:2002] desc
arga [Guía ISO 73:2009] arga
do el do el
31 31
de NOTE 1 The information can relate to the existence, nature, form, de
dicie dicie
likelihood, significance, evaluation, acceptability and treatment of risk.
mbre mbre
11 11
por NOTE 2 Consultation is a two-way process of informed communication por
Ann Ann
McS
between an organization and its stakeholders on an issue prior to making a McS
wee decision or determining a direction on that issue. Consultation is: wee
ney. ney.
No No
⎯ a process which impacts on a decision through influence
se se
per rather than power; and per
mite mite
ning ⎯ an input to decision making, not joint decision making. ning
una una
otra n/a n/a 3.13 otra
repr criterios de riesgo repr
odu terms of reference against which the significance of a risk (3.9) is IS odu
cció cció
no evaluated O/ no
distr IE distr
ibuc [Guía ISO 73:2009] ibuc
ión. C ión.
No 27 No
se NOTE 1 Risk criteria are based on organizational objectives, and external se
cont 00 cont
and internal context.
rola 5: rola
cua cua
ndo NOTE 2 Risk criteria can be derived from standards, laws, policies and
20 ndo
se 63 11 se
imp imp
(E
rial rial
dere other requirements. IE dere
chos chos
de C de
autor 3.5 This term has been removed 27 autor
licen risk estimation licen
ciad
00 ciad
o al process to assign values tothe 5: o al
Instit probability and consequences of a risk 20 Instit
uto uto
de 11 de
Tecn [ISO/IEC Guide 73:2002] Tecn
(E
ologí NOTE 1 In the context of this ologí
a de International Standard, the term a de
Dublí Dublí
n por “activity” is used instead of the term n por
SAI “process” for risk estimation. SAI
Glob Glob
al al
(ww NOTE 2 In the context of this (ww
w.sai International Standard, the term w.sai
glob “likelihood” is used instead of the term glob
al.co al.co
m), “probability” for risk estimation. m),
desc desc
arga n/a evaluación de riesgos 3.14 arga
do el do el
31 process of comparing the estimated risk evaluación de riesgos 31
de against given risk criteria to determine proceso de comparación de los resultados del análisis de riesgos de
dicie dicie
mbre
the significance of the risk (3.10) con los criterios de riesgo (3.13) para determinar si el riesgo mbre
11 [ISO/IEC 27001:2005] y/o su magnitud es aceptable o tolerable 11
por por
Ann Ann
McS
[Guía ISO 73:2009] McS
wee wee
ney. NOTE La evaluación de los riesgos ayuda en la decisión sobre el ney.
No No
se
tratamiento deNOTE los riesgos. se
per
©
3.6 3.15 per
mite identificación de riesgos identificación de riesgos mite
ning IS ning
una O/ process to find, list and characterize proceso de encontrar, reconocer y describir los una
otra IE elements of risk otra
repr C riesgos [Guía ISO 73:2009] repr
odu 20 odu
cció 11 [ISO/IEC Guide 73:2002] cció
no – NOTE 1 Risk identification involves the identification of risk sources, no
distr All NOTE In the context of this International distr
events, their causes and their potential consequences.
ibuc rig ibuc
ión. ht Standard, the term “activity” is used ión.
No s instead of the term NOTE 2 Risk identification can involve historical data, theoretical No
se re se
cont se cont
rola rv rola
cua cua
ndo ndo
se se
imp imp
Mate Mate
rial rial
con con
dere dere
de IS de
licen IE “process” for risk identification. analysis, informed and expert opinions, and stakeholders’ needs. licen
ciad C ciad
o al 20 o al
Instit 11 Instit
uto – uto
de All de
Tecn Tecn
rig
ologí ologí
a de ht a de
Dublí s Dublí
n por re n por
SAI se SAI
Glob rv Glob
al al
(ww (ww
w.sai n/a gestión de riesgos 3.16 w.sai
glob glob
al.co coordinated activities to direct and gestión de riesgos al.co
m), control an organization with regard to coordinated activities to direct and control an organization with regard m),
desc risk to risk desc
arga arga
do el [ISO/IEC 27001:2005] do el
31 [Guía ISO 73:2009] 31
de de
dicie dicie
mbre NOTE This International Standard uses the term ‘process’ to describe risk mbre
11 management overall. The elements within the risk management process are 11
por por
Ann termed ‘activities’ Ann
McS McS
wee 3.7 This term is replaced with ‘risk modification’ and currently wee
ney. ney.
No risk reduction covered by risk treatment No
se actions taken to lessen the probability, se
per negative consequences, or both, per
mite mite
ning associated with a risk ning
una una
otra [ISO/IEC Guide 73:2002] otra
repr repr
odu IS odu
cció NOTE In the context of this International cció
no O/ no
Standard, the term “likelihood” is used
distr
instead of the term “probability” for risk IE distr
ibuc ibuc
ión. reduction. C ión.
No 27 No
se se
cont 3.8 This term is currently covered by risk treatment 00 cont
rola risk retention 5: rola
cua acceptance of the burden of loss or cua
ndo 20 ndo
se 65 11 se
imp imp
(E
rial rial
dere benefit of gain from a particular risk IE dere
chos chos
de C de
autor [ISO/IEC Guide 73:2002] 27 autor
licen licen
ciad
00 ciad
o al NOTE In the context of information 5: o al
Instit security risks, only negative 20 Instit
uto consequences (losses) are considered uto
de 11 de
Tecn for risk retention. Tecn
(E
ologí ologí
a de 3.9 This term is replaced with ‘risk sharing’ and currently covered by a de
Dublí Dublí
n por risk transfer risk treatment n por
SAI sharing with another party the burden of SAI
Glob loss or benefit of gain, for a risk Glob
al al
(ww (ww
w.sai [ISO/IEC Guide 73:2002] w.sai
glob glob
al.co al.co
m), NOTE In the context of information m),
desc security risks, only negative desc
arga consequences (losses) are considered arga
do el do el
31 for risk transfer. 31
de de
dicie n/a tratamiento del riesgo 3.17 dicie
mbre mbre
11 process of selection and implementation tratamiento del riesgo 11
por of measures to modify risk proceso de por
Ann Ann
McS McS
wee NOTE: In this International Standard the modificación del wee
ney. term ‘control’ is used as a synonym for ney.
No ‘measure’. No
se riesgo [Guía ISO se
per per
mite
© [ISO/IEC 27001:2001] mite
73:2009]
ning IS ning
una O/ una
otra IE NOTA1 El tratamiento de los riesgos puede implicar: otra
repr C repr
odu 20 odu
cció 11 ⎯ evitar el riesgo decidiendo no iniciar o continuar con la cció
no – actividad que da origen al riesgo; no
distr All distr
ibuc rig ⎯ tomar o aumentar el riesgo para buscar una oportunidad; ibuc
ión. ht ión.
No s ⎯ eliminando la fuente de riesgo; No
se re se
cont se ⎯ cambiando la probabilidad; cont
rola rv rola
cua ⎯ cambiando las consecuencias; cua
ndo ndo
se ⎯ sharing the risk with another party or parties (including se
imp contracts and risk financing); and imp
Mate Mate
rial rial
con con
dere dere
de IS de
licen IE ⎯ retaining the risk by informed choice. licen
ciad C ciad
o al 20 NOTA2 Los tratamientos de riesgo que se ocupan de las o al
Instit 11 Instit
consecuencias negativas se denominan a veces "mitigación de riesgos",
uto – uto
de All "eliminación de riesgos", "prevención de riesgos" y "reducción de riesgos". de
Tecn Tecn
rig
ologí ologí
a de ht
NOTA3 El tratamiento de los riesgos puede crear nuevos riesgos o a de
Dublí s modificar los existentes. Dublí
n por re n/a n/a 3.18 n por
SAI se SAI
Glob rv interesado Glob
al persona u organización que puede afectar, ser afectada o percibir que al
(ww se ve afectada por una decisión o actividad (ww
w.sai w.sai
glob glob
al.co NOTE A decision maker can be a stakeholder. al.co
m), m),
desc desc
arga [ISO Guide 73:2009] arga
do el threat Current definition from ISO/IEC 27000:2009 applies do el
31 31
de
a potential cause of an unwanted de
dicie incident, which may result in harm to a dicie
mbre system or organization mbre
11 11
por por
Ann [ISO/IEC 27002:2005] Ann
McS McS
wee wee
ney. ney.
No No
se se
per per
mite mite
ning ning
una una
otra otra
repr repr
odu IS odu
cció cció
no O/ no
distr IE distr
ibuc ibuc
ión. C ión.
No 27 No
se se
cont 00 cont
rola 5: rola
cua cua
ndo 20 ndo
se 67 11 se
imp imp
(E
ISO/IEC 27005:2011(E)
Bibliography
[1] ISO/IEC Guide 73:2009, Risk management — Vocabulary
[2] ISO/IEC 16085:2006, Systems and software engineering — Life cycle processes — Risk management
[3] ISO/IEC 27002:2005, Information technology — Security techniques — Code of practice for
information security management
[4] ISO 31000:2009, Risk management — Principles and guidelines
[5] NIST Special Publication 800-12, An Introduction to Computer Security: The NIST Handbook
[6] NIST Special Publication 800-30, Risk Management Guide for Information Technology Systems,
Recommendations of the National Institute of Standards and Technology
68PROOF/ÉPREUVE© ISO/IEC 2011 – All rights reserved

ISO/IEC 27005:2011(E)
ICS 35.040
Price based on 68 pages
© ISO/IEC 2011 – All rights reserved

ISO-IEC 27005-2011-Risk Management-Desbloqueado-Convertido ES

Cargado por

Copyright:

Formatos disponibles

ISO-IEC 27005-2011-Risk Management-Desbloqueado-Convertido ES

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

ISO-IEC 27005-2011-Risk Management-Desbloqueado-Convertido ES

Cargado por

Copyright:

Formatos disponibles

Suscríbete a DeepL Pro para poder editar este documento.

Entra en www.DeepL.com/pro para más información.

AVISO DE DERECHOS DE AUTOR Y CONDICIONES DE USO DE

DOCUMENTO PROTEGIDO POR DERECHOS DE AUTOR

iv© ISO/IEC 2011 - Todos los derechos reservados

Tecnología de la información - Técnicas de seguridad -

El conocimiento de los conceptos, modelos, procesos y terminologías descritos en la ISO/IEC 27001 y la

ISO/IEC 27000, Tecnología de la información - Técnicas de seguridad - Sistemas de gestión de la seguridad

ISO/IEC 27001:2005, Tecnología de la información - Técnicas de seguridad - Sistemas de gestión de la

objetivos [Guía ISO 73:2009]

NOTA1 Un evento puede llevar a una serie de consecuencias.

ser negativa. NOTA3 Las consecuencias pueden expresarse cualitativa o cuantitativamente.

riesgo (3.9) [Guía ISO 73:2009]

NOTA Es posible que2 los controles no siempre ejerzan el efecto modificador

previsto o asumido. NOTA3 El término "control" también se utiliza como

sinónimo de salvaguardia o contramedida.

particulares [Guía ISO 73:2009]

causas. NOTA2 Un evento puede consistir en algo que no está sucediendo.

NOTA3 Un evento a veces puede ser referido como un "incidente" o "accidente".

NOTE El contexto externo puede incluir:

NOTE El contexto interno puede incluir:

⎯ la gobernanza, la estructura organizativa, las funciones y las responsabilidades;

[Guía ISO 73:2009]

tratamiento de riesgo (3.17) [Guía ISO

NOTA El1 riesgo residual puede contener un riesgo1 no identificado.

objetivos [Guía ISO 73:2009]

NOTA1 Un efecto es una desviación de lo esperado - positivo y/o negativo.

© ISO/IEC 2011 - Todos los derechos reservados3

decisiones sobre el tratamiento de los mismos. NOTA El análisis de riesgos2 incluye la

estimación del riesgo.

evaluación de riesgos (3.14) [Guía ISO 73:2009].

[Guía ISO 73:2009]

NOTA1 La información puede referirse a la existencia, la naturaleza, la forma, la probabilidad, la importancia, la

NOTA Los criterios1 de riesgo se basan en los objetivos de la organización y en el contexto

políticas y otros requisitos.

[Guía ISO 73:2009]

riesgos [Guía ISO 73:2009]

con el riesgo [Guía ISO 73:2009].

riesgo [Guía ISO

NOTA1 El tratamiento de los riesgos puede implicar:

[Guía ISO 73:2009]

NOTE Un responsable de la toma de decisiones puede ser una parte interesada.

4Estructura de esta norma internacional

La información de antecedentes se presenta en la cláusula 5.

 Establecimiento del contexto en la cláusula 7,

© ISO/IEC 2011 - Todos los derechos reservados5

 Aceptación del riesgo en la cláusula 10,

Las limitaciones para la modificación del riesgo se presentan en el Anexo F.

a la cláusula 12 se estructuran de la siguiente manera:

Entrada: Identifica cualquier información necesaria para realizar la

actividad. Acción: Describe la actividad.

Salida: Identifica cualquier información derivada después de realizar la actividad.

La gestión de los riesgos para la seguridad de la información debería contribuir a lo siguiente:

 Los riesgos que se identifican

6 © ISO/IEC 2011 - Todos los derechos reservados

 Los riesgos y el proceso de gestión de riesgos se vigilan y revisan periódicamente

El proceso de gestión de riesgos para la seguridad de la información puede aplicarse a la organización en su

6Panorama general del proceso de gestión de riesgos para la seguridad de la información

Figura 1 - El proceso de gestión de riesgos