Guía de Aplicación de La Norma UNE-ISOIEC 27001 Sobre Segurida PDF

Guía de aplicación de la Norma UNE-ISO/IEC 27001
sobre seguridad en sistemas

de información para pymes
Luis Gómez Fernández y Ana Andrés Álvarez

2.ª edición
(ampliada con el Esquema
Nacional de Seguridad)
Título: Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes.
2.ª edición
Autores: Luis Gómez Fernández y Ana Andrés Álvarez
© AENOR (Asociación Española de Normalización y Certificación), 2012

Todos los derechos reservados. Queda prohibida la reproducción total o parcial en cualquier soporte,
sin la previa autorización escrita de AENOR.
ISBN: 978-84-8143-7áÜ-ß
Impreso en España - Printed in Spain
Edita: AENOR
Maqueta y diseño de cubierta: AENOR
Nota: AENOR no se hace responsable de las opiniones expresadas por los autores en esta obra.
Génova, 6. 28004 Madrid • Tel.: 902 102 201 • Fax: 913 103 695
comercial@aenor.es • www.aenor.es
Índice
Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Objeto de esta guía . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introducción a los Sistemas de Gestión de Seguridad de

la Información (SGSI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.1. Definición de un SGSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.2. El ciclo de mejora continua . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.3. La Norma UNE-ISO/IEC 27001 . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.3.1. Origen de la norma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.3.2. Objeto y campo de aplicación de la norma . . . . . . . . . . . . 17
1.4. La Norma UNE-ISO/IEC 27002 . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.4.1. Origen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.4.2. Objeto y campo de aplicación . . . . . . . . . . . . . . . . . . . . . . 18
1.5. El Esquema Nacional de Seguridad (ENS) . . . . . . . . . . . . . . . . . . . . 18
1.5.1. Origen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.5.2. Objeto y campo de aplicación . . . . . . . . . . . . . . . . . . . . . . 19
1.6. Términos y definiciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2. Comprender la Norma UNE-ISO/IEC 27001 . . . . . . . . . . . . . . . . . . . . . 23

2.1. Requisitos generales del sistema de gestión de la seguridad . . . . . . . 23
2.2. Establecimiento y gestión del SGSI . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.2.1. Establecimiento del SGSI . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.2.2. Definición del alcance del SGSI . . . . . . . . . . . . . . . . . . . . . 27
2.2.3. Definición de la política de seguridad . . . . . . . . . . . . . . . . . 28
4 Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes
2.2.4. Identificación de los activos de información . . . . . . . . . . . . 28

2.2.5. Definición del enfoque del análisis de riesgos . . . . . . . . . . . 29
2.2.6. Cómo escoger la metodología del análisis de riesgos . . . . . 30
2.2.7. Tratamiento de los riesgos . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.2.8. Selección de controles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.2.9. Gestión de riesgos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.2.10. Declaración de aplicabilidad . . . . . . . . . . . . . . . . . . . . . . . 32
2.2.11. Implementación y puesta en marcha del SGSI . . . . . . . . . . . 33
2.2.12. Control y revisión del SGSI . . . . . . . . . . . . . . . . . . . . . . . . 33
2.2.13. Mantenimiento y mejora del SGSI . . . . . . . . . . . . . . . . . . . 34
2.3. Requisitos de documentación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.3.1. Generalidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.3.2. Control de documentos . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.3.3. Control de registros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.4. Compromiso de la dirección . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.5. Gestión de los recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.6. Formación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.7. Auditorías internas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.8. Revisión por la dirección . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.8.1. Entradas a la revisión . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.8.2. Salidas de la revisión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.9. Mejora continua . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.9.1. Acción correctiva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.9.2. Acción preventiva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.10. El anexo A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3. Comprender la Norma UNE-ISO/IEC 27002 . . . . . . . . . . . . . . . . . . . . . 45

3.1. Valoración y tratamiento del riesgo . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.2. Política de seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.3. Organización de la seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.4. Gestión de activos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.5. Seguridad ligada a los recursos humanos . . . . . . . . . . . . . . . . . . . . 50
3.6. Seguridad física y del entorno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.7. Gestión de comunicaciones y operaciones . . . . . . . . . . . . . . . . . . . . 53
Índice 5
3.8. Control de acceso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

3.9. Adquisición, desarrollo y mantenimiento de los sistemas . . . . . . . . . . 64
3.10. Gestión de las incidencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
3.11. Gestión de la continuidad del negocio . . . . . . . . . . . . . . . . . . . . . . 68
3.12. Cumplimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4. Definición e implementación de un SGSI . . . . . . . . . . . . . . . . . . . . . . . . 73

4.1. El proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.2. Documentación del SGSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.3. Política de seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.4. Inventario de activos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.5. Análisis de riesgos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
4.6. Gestión de riesgos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
4.7. Plan de tratamiento del riesgo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
4.8. Procedimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
4.9. Formación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
4.10. Revisión por la dirección . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
4.11. Auditoría interna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
4.12. Registros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5. Proceso de certificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
6. Relación entre los apartados de la norma y la documentación del sistema . . 93
7. Correspondencia entre las Normas UNE-EN ISO 9001:2008,

UNE-EN ISO 14001:2004 y UNE-ISO/IEC 27001:2007 . . . . . . . . . . . . 97
8. Caso práctico: modelo de SGSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

8.1. Documentación de la política de seguridad . . . . . . . . . . . . . . . . . . . 101
8.1.1. Política de seguridad de la información . . . . . . . . . . . . . . . 101
8.1.2. Definición del SGSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
8.1.3. Organización e infraestructura de seguridad . . . . . . . . . . . . 103
8.1.4. Clasificación de la información . . . . . . . . . . . . . . . . . . . . . 104
8.1.5. Análisis de riesgos de seguridad . . . . . . . . . . . . . . . . . . . . . 104
8.2. Documentación del inventario de activos . . . . . . . . . . . . . . . . . . . . . 105
8.2.1. Procesos de negocio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
8.2.2. Inventario de activos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

8.2.3. Relación proceso de negocio-activos . . . . . . . . . . . . . . . . . 106
8.2.4. Valoración de activos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
8.3. Documentación del Análisis de riesgos . . . . . . . . . . . . . . . . . . . . . . 107
8.3.1. Valoración del riesgo por activos . . . . . . . . . . . . . . . . . . . . 107
8.3.2. Tramitación del riesgo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
8.4. Documentación de la Gestión de riesgos . . . . . . . . . . . . . . . . . . . . . 110
8.4.1. Valoración del riesgo por activos . . . . . . . . . . . . . . . . . . . . 110
8.5. Documentación de la Declaración de aplicabilidad . . . . . . . . . . . . . 114
8.5.1. Controles aplicados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
8.6. Documentación del Plan de tratamiento del riesgo . . . . . . . . . . . . . . 123
8.6.1. Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
8.6.2. Alcance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
8.6.3. Responsabilidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
8.6.4. Tareas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
8.6.5. Seguimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
8.6.6. Objetivos e indicadores . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
8.7. Documentación del Procedimiento de auditorías internas . . . . . . . . . 125
8.7.1. Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
8.7.2. Alcance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
8.7.4. Desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
8.7.5. Requisitos de documentación . . . . . . . . . . . . . . . . . . . . . . . 128
8.7.6. Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
8.7.7. Anexos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
8.8. Documentación del Procedimiento para las copias de seguridad . . . . 131
8.8.1. Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
8.8.2. Alcance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
8.8.4. Términos y definiciones . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
8.8.5. Procedimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
8.8.6. Requisitos de documentación . . . . . . . . . . . . . . . . . . . . . . . 134
8.8.7. Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
8.8.8. Anexos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Índice 7
9. Comprender el Esquema Nacional de Seguridad (ENS) . . . . . . . . . . . . . 137

9.1. Generalidades del ENS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
9.2. Principios básicos del ENS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
9.3. Requisitos mínimos de seguridad del ENS . . . . . . . . . . . . . . . . . . . . 140
9.3.1. Organización e implementación del proceso de seguridad . . 140
9.3.2. Análisis y gestión de los riesgos . . . . . . . . . . . . . . . . . . . . . 140
9.3.3. Gestión de personal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
9.3.4. Profesionalidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
9.3.5. Autorización y control de los accesos . . . . . . . . . . . . . . . . . 141
9.3.6. Protección de las instalaciones . . . . . . . . . . . . . . . . . . . . . . 141
9.3.7. Adquisición de nuevos productos de seguridad . . . . . . . . . . 142
9.3.8. Seguridad por defecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
9.3.9. Integridad y actualización del sistema . . . . . . . . . . . . . . . . . 142
9.3.10. Protección de la información almacenada y en tránsito . . . . 143
9.3.11. Prevención ante otros sistemas de información
interconectados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
9.3.12. Registro de actividad . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
9.3.13. Incidentes de seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
9.3.14. Continuidad de la actividad . . . . . . . . . . . . . . . . . . . . . . . . 144
9.3.15. Mejora continua del proceso de seguridad . . . . . . . . . . . . . 144
9.3.16. Soporte al cumplimiento . . . . . . . . . . . . . . . . . . . . . . . . . . 144
9.4. Otros requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
9.4.1. Comunicaciones electrónicas . . . . . . . . . . . . . . . . . . . . . . . 145
9.4.2. Auditoría de la seguridad . . . . . . . . . . . . . . . . . . . . . . . . . 146
9.4.3. Estado de seguridad de los sistemas . . . . . . . . . . . . . . . . . . 146
9.4.4. Respuesta a incidentes de seguridad . . . . . . . . . . . . . . . . . . 146
9.4.5. Normas de conformidad . . . . . . . . . . . . . . . . . . . . . . . . . . 147
9.4.6. Actualización . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
9.4.7. Categorización de los sistemas . . . . . . . . . . . . . . . . . . . . . 147
9.4.8. Formación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
10. Implementación del ENS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

10.1. El plan de adecuación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
10.2. Adecuación al ENS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
10.2.1. Planificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
10.2.2. Implementación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
10.2.3. Verificación y validación . . . . . . . . . . . . . . . . . . . . . . . . . . 154

10.2.4. Actualización y mejora continua . . . . . . . . . . . . . . . . . . . . . 155
11. Ejemplo práctico: plan de adecuación . . . . . . . . . . . . . . . . . . . . . . . . . . 157

11.1. Documentación de la política de seguridad . . . . . . . . . . . . . . . . . . . 157
11.2. Documentación de la categoría del sistema . . . . . . . . . . . . . . . . . . . 158
11.2.1. Criterios de valoración de los activos . . . . . . . . . . . . . . . . . 158
11.2.2. Categorización de sistemas . . . . . . . . . . . . . . . . . . . . . . . . 158
11.3. Documentación del análisis de riesgos . . . . . . . . . . . . . . . . . . . . . . 160
11.3.1. Metodología de análisis . . . . . . . . . . . . . . . . . . . . . . . . . . 160
11.3.2. Valoración de activos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
11.3.3. Mapas de riesgos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
11.3.4. Nivel de riesgo aceptable . . . . . . . . . . . . . . . . . . . . . . . . . 161
11.4. Documentación de la declaración de aplicabilidad . . . . . . . . . . . . . 164
11.5. Insuficiencias del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
11.6. Plan de mejora . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
12. Bibliografía . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

Normas de referencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Legislación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Otros documentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Links de interés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Norma UNE-ISO/IEC 27001:2007 Tecnología de la información. Técnicas de

seguridad. Sistemas de Gestión de la Seguridad de la Información (SGSI).
Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Introducción
La información es el principal activo de muchas organizaciones y precisa ser prote-

gida adecuadamente frente a amenazas que puedan poner en peligro la continuidad
del negocio.
En la actualidad, las empresas de cualquier tipo o sector de actividad se enfrentan
cada vez más con riesgos e inseguridades procedentes de una amplia variedad de
contingencias, las cuales pueden dañar considerablemente tanto los sistemas de infor-
mación como la información procesada y almacenada.
Ante estas circunstancias, las organizaciones han de establecer estrategias y contro-
les adecuados que garanticen una gestión segura de los procesos del negocio, pri-
mando la protección de la información.
Para proteger la información de una manera coherente y eficaz es necesario imple-
mentar un Sistema de Gestión de Seguridad de la Información (SGSI). Este sis-
tema es una parte del sistema global de gestión, basado en un análisis de los riesgos
del negocio, que permite asegurar la información frente a la pérdida de:
• Confidencialidad: sólo accederá a la información quien se encuentre autori-
zado.
• Integridad: la información será exacta y completa.
• Disponibilidad: los usuarios autorizados tendrán acceso a la información
cuando lo requieran.
La seguridad total es inalcanzable, pero mediante el proceso de mejora continua

del sistema de seguridad se puede conseguir un nivel de seguridad altamente satis-
factorio, que reduzca al mínimo los riesgos a los que se está expuesto y el impacto
que ocasionarían si efectivamente se produjeran.
Objeto de esta guía
El objeto de esta publicación es facilitar la comprensión de los diversos conceptos

involucrados en un sistema de gestión normalizado y contemplar las recomenda-
ciones generales para la implementación de un SGSI en una pyme, utilizando la
norma de facto en el mercado internacional para ello, la Norma UNE-ISO/IEC
27001. También se ofrece una visión general de cómo hacerlo en el caso de utilizar el
modelo del Esquema Nacional de Seguridad (ENS), obligatorio por ley en nuestro
país, para la protección de los sistemas que soportan la administración electrónica,
visión también particularmente de interés para pymes que proporcionen servicios
TIC a las Administraciones Públicas.
Tanto la Norma UNE-ISO/IEC 27001 como el ENS, facilitan la mejora en segu-
ridad, aunque pueden resultar de difícil aplicación para aquellos que no estén
familiarizados con los conceptos que tratan.
Esta guía no pretende ser preceptiva (existen infinidad de formas de implementar
correctamente la norma y el ENS), sino informativa, proporcionando explicaciones
básicas de los requisitos de la norma y orientando respecto a la manera en que se
pueden cumplir esos requisitos.
Generalmente, una primera aproximación a la norma puede infundir desconfianza
en cuanto a la capacidad de la empresa para poder llevar a cabo todos los requeri-
mientos que expresa. Muchos términos no se utilizan en la actividad cotidiana de
una pyme, tales como riesgos, amenazas, vulnerabilidades. Además, exige una serie
de tareas desconocidas en la operativa habitual, tales como la realización de un aná-
lisis de riesgos y la selección de controles. Para complicar más las cosas, se hace
referencia a la Norma UNE-ISO/IEC 27002, que especifica una amplia gama de
controles de seguridad a implementar, en numerosos casos, con una gran carga de
contenido técnico. Los objetivos, controles e indicaciones contenidos en la Norma
UNE-ISO/IEC 27002 pueden llegar a ser muy difíciles de valorar por un gestor
que no cuente con la información o la formación adecuada, hecho que le impediría
decidir cabalmente sobre cuál es su relevancia para la empresa y las consecuencias
de la implementación o no de un determinado control en ella.
Esta guía pretende suplir semejantes carencias, proporcionando información deta-
llada sobre el significado práctico de los requisitos de la norma y explicando con
ejemplos cómo se pueden realizar, teniendo siempre en cuenta la situación inicial,
los requisitos de seguridad de la empresa y, por supuesto, los recursos disponibles,
ya que sin contar con esto ningún sistema de gestión se hallará bien diseñado y, por
lo tanto, estará condenado al fracaso.
Para una mejor comprensión de las implicaciones de los diversos requisitos de la
norma, esta guía incluye un ejemplo práctico, basado en una empresa ficticia, con
la documentación básica que debe incluir un SGSI e indicaciones sobre la informa-
ción que debe recoger cada documento.
1
Introducción a los
Sistemas de Gestión
de Seguridad de la
Información (SGSI)
1.1. Definición de un SGSI

Un Sistema de Gestión de Seguridad de la Información (SGSI), según la Norma
UNE-ISO/IEC 27001, es una parte del sistema de gestión general, basada en un
enfoque de riesgo empresarial, que se establece para crear, implementar, operar,
supervisar, revisar, mantener y mejorar la seguridad de la información. Esto signi-
fica que se va a dejar de operar de una manera intuitiva y se va a empezar a tomar
el control sobre lo que sucede en los sistemas de información y sobre la propia
información que se maneja en la organización. Nos permitirá conocer mejor nues-
tra organización, cómo funciona y qué podemos hacer para que la situación
mejore.
La norma especifica que, como cualquier otro sistema de gestión, el SGSI incluye
tanto la organización como las políticas, la planificación, las responsabilidades, las
prácticas, los procedimientos, los procesos y los recursos. Es decir, tanto la docu-
mentación de soporte como las tareas que se realizan. Los sistemas de gestión que
definen las normas ISO siempre están documentados, ya que, por un lado, es la
mejor manera de formalizar normas e instrucciones y, por otro, son más fáciles de
transmitir y comunicar, cosa que no sucedería si se confía en un traspaso de infor-
mación verbal informal.
La norma es compatible con el resto de las normas ISO para sistemas de gestión
(UNE-EN ISO 9001 y UNE-EN ISO 14001) y poseen idéntica estructura y
requisitos comunes, por lo que se recomienda integrar el SGSI con el resto de los
sistemas de gestión que existan en la empresa para no duplicar esfuerzos.
Incluso cuando no exista un sistema de gestión formal, el amplio conocimiento
actual de estos sistemas hace que las principales características de la norma sean
comprensibles para la mayoría de la gente, y que para explicarla en detalle sea

suficiente con incidir en las diferencias fundamentales, a saber, que con un SGSI
lo que tratamos es de gestionar la seguridad de la información de nuestra
organización.
1.2. El ciclo de mejora continua

Para establecer y gestionar un sistema de gestión de la seguridad de la información
se utiliza el ciclo PDCA (conocido también como ciclo Deming), tradicional en los
sistemas de gestión de la calidad (véase la figura 1.1). El ciclo PDCA es un con-
cepto ideado originalmente por Shewhart, pero adaptado a lo largo del tiempo por
algunos de los más sobresalientes personajes del mundo de la calidad. Esta meto-
dología ha demostrado su aplicabilidad y ha permitido establecer la mejora conti-
nua en organizaciones de todas clases.
El modelo PDCA o “Planificar-Hacer-Verificar-Actuar” (Plan-Do-Check-Act, de sus
siglas en inglés), tiene una serie de fases y acciones que permiten establecer un
modelo de indicadores y métricas comparables en el tiempo, de manera que se
pueda cuantificar el avance en la mejora de la organización:
• Plan. Esta fase se corresponde con establecer el SGSI. Se planifica y diseña el
programa, sistematizando las políticas a aplicar en la organización, cuáles son
los fines a alcanzar y en qué ayudarán a lograr los objetivos de negocio, qué
medios se utilizarán para ello, los procesos de negocio y los activos que los
soportan, cómo se enfocará el análisis de riesgos y los criterios que se segui-
rán para gestionar las contingencias de modo coherente con las políticas y
objetivos de seguridad.
• Do. Es la fase en la que se implementa y pone en funcionamiento el SGSI.
Las políticas y los controles escogidos para cumplirlas se implementan
mediante recursos técnicos, procedimientos o ambas cosas a la vez, y se asig-
nan responsables a cada tarea para comenzar a ejecutarlas según las instruc-
ciones.
• Check. Esta fase es la de monitorización y revisión del SGSI. Hay que con-
trolar que los procesos se ejecutan como se ha establecido, de manera eficaz
y eficiente, alcanzando los objetivos definidos para ellos. Además, hay que
verificar el grado de cumplimiento de las políticas y procedimientos, identi-
ficando los fallos que pudieran existir y, hasta donde sea posible, su origen,
mediante revisiones y auditorías.
1. Introducción a los Sistemas de Gestión de Seguridad de la Información (SGSI) 15
• Act. Es la fase en la que se mantiene y mejora el SGSI, decidiendo y efec-

tuando las acciones preventivas y correctivas necesarias para rectificar los
fallos, detectados en las auditorías internas y revisiones del SGSI, o cualquier
otra información relevante para permitir la mejora permanente del SGSI.
La mejora continua es un proceso en sí mismo. Debe entenderse como la mejora

progresiva de los niveles de eficiencia y eficacia de una organización en un pro-
ceso continuo de aprendizaje, tanto de sus actividades como de los resultados
propios.
Dado que la norma se encuentra enfocada hacia la mejora continua, es un esfuerzo
innecesario tratar de implementar un SGSI perfecto en un primer proyecto de este
tipo. El objetivo debería ser diseñar un SGSI que se ajuste lo más posible a la reali-
dad de la organización, que contemple las medidas de seguridad mínimas e impres-
cindibles para proteger la información y cumplir con la norma, pero que consuma
pocos recursos e introduzca el menor número de cambios posibles. De esta manera,
el SGSI se podrá integrar de una forma no traumática en la operativa habitual de la
organización, dotándola de herramientas con las que hasta entonces no contaba que
puedan demostrar su eficacia a corto plazo.
La aceptación de este primer SGSI es un factor de éxito fundamental. Permitirá a
la organización ir mejorando su seguridad paulatinamente y con escaso esfuerzo.
Tomar acciones correctivas

y preventivas
Act Plan Definir política y alcance
Revisar y auditar el SGSI Check Do Implementar el SGSI
Figura 1.1. Ciclo PDCA

1.3. La Norma UNE-ISO/IEC 27001

1.3.1. Origen de la norma
ISO (Organización Internacional de Normalización) e IEC (Comisión Electrotéc-
nica Internacional) constituyen el sistema especializado para la normalización a
nivel mundial. Los organismos nacionales que son miembros de ISO o IEC parti-
cipan en el desarrollo de las normas internacionales a través de comités técnicos
establecidos por las organizaciones respectivas para realizar acuerdos en campos
específicos de la actividad técnica. Los comités técnicos de ISO e IEC colaboran en
los campos de interés mutuo.
En el campo de la tecnología de la información, ISO e IEC han establecido un
comité técnico conjunto, el denominado ISO/IEC JTC 1 (Joint Technical Commit-
tee 1). Los borradores de estas normas internacionales, adoptadas por la unión de
este comité técnico, son enviados a los organismos de las diferentes naciones para
su votación. La publicación como norma internacional requiere la aprobación de,
por lo menos, el 75% de los organismos nacionales que emiten su voto.
La Norma Internacional ISO/IEC 27002 fue preparada inicialmente por el Insti-
tuto de Normas Británico (como BS 7799), y adoptada bajo la supervisión del sub-
comité de técnicos de seguridad del comité técnico ISO/IEC JTC 1, en paralelo
con su aprobación por los organismos nacionales miembros de ISO e IEC.
Una vez que fue publicada la Norma ISO/IEC 17799-1 (actualmente se corres-
ponde con la Norma ISO/IEC 27002), Reino Unido (BSI) y España (AENOR)
elevaron al comité internacional sus normas nacionales sobre las especificaciones de
los sistemas de gestión de la seguridad de la información (SGSI), BS 7799-2 y
UNE 71502 respectivamente, siendo estas normas el origen de lo que finalmente
acabo publicándose como norma internacional ISO/IEC 27001 en el año 2005,
que fue adoptada como norma española UNE-ISO/IEC 27001 en el año 2007,
tras un periodo de convivencia con la norma anteriormente mencionada.
Actualmente, tanto la norma ISO/IEC 27001 como la ISO/IEC 27002 están en
proceso de revisión internacional, y se espera que se publiquen las nuevas versiones
a lo largo del año 2013.
Como se ha comentado anteriormente, este estándar internacional adopta también
el modelo Plan-Do-Check-Act (PDCA), es decir, se basa en un ciclo de mejora con-
tinua que consiste en planificar, desarrollar, comprobar y actuar en consecuencia
con lo que se haya detectado al efectuar las comprobaciones. De esta manera se
conseguirá ir refinando la gestión, haciéndola más eficaz y efectiva.
1.3.2. Objeto y campo de aplicación de la norma

La Norma UNE-ISO/IEC 27001, como el resto de las normas aplicables a los sis-
temas de gestión, está pensada para que se emplee en todo tipo de organizaciones
(empresas privadas y públicas, entidades sin ánimo de lucro, etc.), sin importar el
tamaño o la actividad.
Esta norma especifica los requisitos para la creación, implementación, funciona-
miento, supervisión, revisión, mantenimiento y mejora de un SGSI documentado,
teniendo en cuenta los riesgos empresariales generales de la organización. Es decir,
explica cómo diseñar un SGSI y establecer los controles de seguridad, de acuerdo
con las necesidades de una organización o de partes de la misma, pero no aclara
mediante qué procedimientos se ponen en práctica. Por ejemplo, uno de los princi-
pales requisitos es la realización de un análisis de riesgos con unas determinadas
características de objetividad y precisión, pero no aporta indicaciones de cuál es la
mejor manera de llevar a cabo dicho análisis. Puede ejecutarse con una herramienta
comercial, con una aplicación diseñada expresamente para la empresa, mediante
reuniones, entrevistas, tablas o cualquier otro método que se estime oportuno.
Todos estos recursos servirán para cumplir la norma, siempre y cuando se observen
los requisitos de objetividad del método, los resultados sean repetibles y la
metodología se documente.
1.4. La Norma UNE-ISO/IEC 27002

1.4.1. Origen
La Norma UNE-ISO/IEC 27002 Tecnología de la información. Código de buenas
prácticas para la gestión de la seguridad de la información, ha sido elaborada por el
AEN/CTN 71/SC 27 Técnicas de seguridad que pertenece al comité técnico con-
junto ISO/IEC JTC 1/SC 27 Tecnología de la información. En ambas normas el con-
tenido es idéntico, diferenciándose únicamente en la numeración, que ha sido
modificada en el marco de la creación de la familia de normas ISO 27000.
Esta norma se está desarrollando dentro de una familia de normas internacionales
sobre Sistemas de Gestión de la Seguridad de la Información (SGSI). Tal familia
incluye normas internacionales sobre requisitos, gestión del riesgo, métricas y
mediciones, así como una guía de implementación de los sistemas de gestión de la
seguridad de la información. Dicha familia de normas tiene un esquema de nume-
ración que utilizará los números de la serie 27000.
1.4.2. Objeto y campo de aplicación

La Norma UNE-ISO/IEC 27002 establece las directrices y principios generales
para el comienzo, la implementación, el mantenimiento y la mejora de la gestión
de la seguridad de la información en una organización. Es un catálogo de buenas
prácticas, obtenido a partir de la experiencia y colaboración de numerosos partici-
pantes, los cuales han alcanzado un consenso acerca de los objetivos comúnmente
aceptados para la gestión de la seguridad de la información.
Los objetivos de control y los controles de esta norma internacional tienen como
fin servir de guía para el desarrollo de pautas de seguridad internas y prácticas efec-
tivas de gestión de la seguridad. Por ello, la elección de los controles permanece
sujeta a lo detectado en un análisis de riesgos previo, y el grado de implementación
de cada uno de los controles se llevará a cabo de acuerdo a los requisitos de seguri-
dad identificados y a los recursos disponibles de la organización para alcanzar así
un balance razonable entre seguridad y coste.
1.5. El Esquema Nacional de Seguridad (ENS)

1.5.1. Origen
La Ley 11/2007, de 22 de junio, de acceso electrónico de los ciudadanos a los Ser-
vicios Públicos está siendo el motor y la guía de la administración electrónica. Esta
ley ha dado paso a una nueva etapa en la gestión de la Administración Pública,
impulsando la adopción de los medios tecnológicos actualmente disponibles para
realizar tareas de gestión y facilitando a los ciudadanos el acceso a la Administra-
ción Pública en contextos más adecuados a la realidad social.
Esta ley, en su artículo 1 reconoce el derecho de los ciudadanos a relacionarse con
las Administraciones Públicas por medios electrónicos con la misma validez que
por los medios tradicionales, y estipula que éstas utilicen las tecnologías de la infor-
mación asegurando la disponibilidad, el acceso, la integridad, la autenticidad, la
confidencialidad y la conservación de los datos, informaciones y servicios que ges-
tionen en el ejercicio de sus competencias. También determina que la herramienta
para conseguir este objetivo será el Esquema Nacional de Seguridad, que estable-
cerá una política de seguridad en la utilización de medios electrónicos, y contará
con unos principios básicos y una serie de requisitos mínimos que permitirán una
protección adecuada de los sistemas y la información.
El ENS está regulado por el Real Decreto 3/2010, de 8 de enero, que recoge los
requisitos técnicos y organizativos que se deben cumplir para proteger la informa-
ción dentro del ámbito de aplicación del mismo. Por tanto, se puede decir que trata
la protección de la información y de los servicios en el ámbito de la administración

electrónica y que, a la luz de principios y requisitos generalmente reconocidos,
exige la gestión continuada de la seguridad, aplicando un sistema de gestión de
seguridad de la información.
1.5.2. Objeto y campo de aplicación

El objeto del ENS es garantizar la seguridad de los servicios prestados mediante
medios electrónicos, de manera que los ciudadanos puedan realizar cualquier trá-
mite con la confianza de que va a tener validez jurídica plena y que sus datos van a
ser tratados de manera segura.
Toda la Administración Pública española, Administración General del Estado,
Administraciones de las Comunidades Autónomas, Administraciones Locales, así
como las entidades de derecho público vinculadas o dependientes de las mismas,
están sujetas al cumplimiento de los requisitos del ENS.
Su ámbito de aplicación son los sistemas de información, los datos, las comunica-
ciones y los servicios electrónicos, que permitan a los ciudadanos y a las Adminis-
traciones Públicas el ejercicio de derechos y el cumplimiento de deberes a través de
medios electrónicos.
1.6. Términos y definiciones

Para cumplir con las intenciones de este documento, conviene aclarar el significado
de ciertos términos y definiciones:
• Activo
Cualquier bien que tiene valor para la organización.
[ISO/IEC 13335-1:2004]
• Disponibilidad
La propiedad de ser accesible y utilizable por una entidad autorizada.
[ISO/IEC 13335-1:2004]
• Confidencialidad
La propiedad por la que la información no se pone a disposición o se revela
a individuos, entidades o procesos no autorizados.
[ISO/IEC 13335-1:2004]
• Seguridad de la información
La preservación de la confidencialidad, la integridad y la disponibilidad de la
información, pudiendo, además, abarcar otras propiedades, como la autenti-
cidad, la responsabilidad, la fiabilidad y el no repudio.
[ISO/IEC 17799:2005]
• Evento de seguridad de la información

La ocurrencia detectada en un estado de un sistema, servicio o red que indica
una posible violación de la política de seguridad de la información, un fallo
de las salvaguardas o una situación desconocida hasta el momento y que
puede ser relevante para la seguridad.
[ISO/IEC TR 18044:2004]
• Incidente de seguridad de la información

Un único evento o una serie de eventos de seguridad de la información, ines-
perados o no deseados, que tienen una probabilidad significativa de compro-
meter las operaciones empresariales y de amenazar la seguridad de la infor-
mación.
[ISO/IEC TR 18044:2004]
• Sistema de Gestión de la Seguridad de la Información (SGSI) [Information

Security Management System, ISMS]
La parte del sistema de gestión general, basada en un enfoque de riesgo
empresarial, que se establece para crear, implementar, operar, supervisar, revi-
sar, mantener y mejorar la seguridad de la información.
Nota: el sistema de gestión incluye la estructura organizativa. las políticas, las actividades
de planificación, las responsabilidades, las prácticas, los procedimientos, los procesos y
los recursos.
• Integridad
La propiedad de salvaguardar la exactitud y completitud de los activos.
[ISO/IEC 13335-1:2004]
• Riesgo residual
Riesgo remanente que existe después de que se hayan tornado las medidas
de seguridad.
[ISO/IEC Guide 73:2002]
• Aceptación del riesgo

La decisión de aceptar un riesgo.
• Análisis de riesgos
Utilización sistemática de la información disponible para identificar peligros
y estimar los riesgos.
• Evaluación de riesgos
El proceso general de análisis y estimación de los riesgos.
• Estimación de riesgos
El proceso de comparación del riesgo estimado con los criterios de riesgo,
para así determinar la importancia del riesgo.
• Gestión de riesgos
Actividades coordinadas para dirigir y controlar una organización con res-
pecto a los riesgos.
• Tratamiento de riesgos
El proceso de selección e implementación de las medidas encaminadas a
modificar los riesgos.
[ISO/IEC Guide 73:2002].
Nota: en esta norma internacional, el término “control” se utiliza como sinónimo de
“medida de seguridad.”
• Declaración de aplicabilidad
Declaración documentada que describe los objetivos de control y los contro-
les que son relevantes para el SGSI de la organización y aplicables al mismo.
Nota: los objetivos de control y los controles se basan en los resultados y conclusiones de
la evaluación de riesgos y en los procesos de tratamiento del riesgo, en los requisitos lega-
les o reglamentarios, en las obligaciones contractuales y en las necesidades empresariales
de la organización en materia de seguridad de la información.
2 Comprender la
Norma UNE-ISO/IEC 27001
La seguridad no es el resultado de un proceso, es un proceso en sí mismo. Se con-

seguirá un nivel de seguridad aceptable en la medida en que este proceso funcione
y progrese adecuadamente.
No es de extrañar, por tanto, que la Norma UNE-ISO/IEC 27001 exija que se
adopte un proceso para establecer, implementar, operar, monitorizar, revisar, man-
tener y mejorar el SGSI en una organización. Es decir, hay que diseñarlo, ponerlo
en marcha, comprobar que se obtienen los resultados esperados y, en función de
esa evaluación, tomar acciones para corregir las desviaciones detectadas o intentar
mejorar la situación, en este caso, la seguridad de la información. Y todo ello de
una manera ordenada y metódica, mediante un proceso.
2.1. Requisitos generales del sistema de gestión

de la seguridad
Una organización necesita identificar y administrar cualquier tipo de actividad para
funcionar eficientemente. Cualquier actividad que emplea recursos y es adminis-
trada para transformar entradas en salidas, puede ser considerada como un “pro-
ceso”. A menudo, estas salidas son aprovechadas nuevamente como entradas, gene-
rando una realimentación.
Habitualmente se piensa que los sistemas de gestión son un conjunto de activida-
des que requieren unos niveles de recursos y dinero que no están al alcance de una
empresa pequeña. Nada más lejos de la realidad. En infinidad de ocasiones son las
pequeñas empresas las que más se pueden beneficiar de estas iniciativas, ya que
carecen de los conocimientos y la cultura que transmiten las normas de manera tan
sintética y depurada. El éxito de un proyecto de implementación de un SGSI está
fuertemente ligado a la habilidad del promotor de asignar los recursos justos y
necesarios para diseñar un sistema adecuado a las necesidades de la organización.
El sistema debe cumplir con los requisitos de la norma, por supuesto, pero no
menos importante es el cumplimiento de los requisitos del negocio. Cualquier
sistema de gestión debe apoyar el cumplimiento de los objetivos de la organización
o no tendrá razón de ser.
Los requisitos que exige este estándar internacional son genéricos y aplicables a la
totalidad de las organizaciones, independientemente de su tamaño o sector de acti-
vidad. En particular, no se acepta la exclusión de los requerimientos especificados
en los apartados 4, 5, 6, 7 y 8 cuando una organización solicite su conformidad con
esta norma. Estos apartados son las que realmente conforman el cuerpo principal
de la norma:
• Sistema de gestión de la seguridad de la información.
• Responsabilidad de la dirección.
• Auditorías internas del SGSI.
• Revisión del SGSI por la dirección.
• Mejora del SGSI.
Lo que la norma reclama es que exista un sistema documentado (política, análisis

de riesgos, procedimientos, etc.), donde la dirección colabore activamente y se
implique en el desarrollo y gestión del sistema. Se controlará el funcionamiento
del sistema para que marche correctamente y la mejora sea continua, practicándose
auditorías internas y revisiones del sistema para verificar que se están obteniendo
los resultados esperados, igualmente se activarán acciones encaminadas a solucio-
nar los problemas detectados en las actividades de comprobación (auditorías y revi-
siones), a prevenir problemas y a mejorar aquellos asuntos que sean susceptibles
de ello.
El sistema constará de una documentación en varios niveles (véase la figura 2.1):
• Políticas, que proporcionan las guías generales de actuación en cada caso.
• Procedimientos, que dan las instrucciones para ejecutar cada una de las tareas
previstas.
• Registros, que son las evidencias de que se han llevado a cabo las actuaciones
establecidas.
2. Comprender la Norma UNE-ISO/IEC 27001 25
Políticas
Procedimientos
Registros
Figura 2.1. Niveles de documentación
2.2. Establecimiento y gestión del SGSI

2.2.1. Establecimiento del SGSI
La norma establece una serie de requisitos, que se detallan a continuación (véase la
figura 2.2). Para satisfacerlos, la organización debe buscar los medios más apropia-
dos a sus circunstancias, necesidades y, por supuesto, los recursos disponibles. Debe
recopilarse información sobre varios aspectos, tales como a qué se dedica la organi-
zación, qué necesidades de seguridad precisa teniendo en cuenta su actividad, y el
ámbito en el que opera, así como las restricciones legales a las que puede estar
sujeta dicha actividad.
Los requisitos en muchos casos no se encuentran definidos. La organización sabe,
en términos generales, qué nivel de seguridad desea, pero no existen mecanismos
para expresarlo y documentarlo. Hay que concretar esas necesidades que se perci-
ben para poder comenzar el diseño del SGSI. Sabiendo qué se necesita se podrán
ISO 27001
Reglamentos Leyes
SGSI
Recursos Negocio
Contratos
Figura 2.2. Requisitos del SGSI
proponer opciones y tomar decisiones. Es fundamental no comprometer recursos

difíciles de conseguir. Hay que ser realista con los recursos disponibles en cada
momento y dimensionar el proyecto de acuerdo con las prioridades del negocio.
Cuando una empresa decide adaptarse a esta norma (véase la figura 2.3), básica-
mente se emprenderán las actividades que se detallan a continuación, y que como
tienen que ser documentadas, al finalizarlas, el SGSI contará ya con los siguientes
documentos:
• Política de seguridad, que contendrá las directrices generales a las que se
ajustará la organización en cuanto a seguridad, así como la estrategia a seguir
a la hora de establecer objetivos y líneas de actuación. La política estará ali-
neada con el resto de los objetivos del negocio y políticas de gestión que
existan en la organización. Esta política estará aprobada por la dirección.
• Inventario de activos, que detallará los activos dentro del alcance del SGSI,
así como los propietarios y la valoración de tales activos.
• Análisis de riesgos, con los riesgos identificados basándose en la política de
la organización sobre seguridad de la información y el grado de seguridad
requerido.
• Las decisiones de la dirección respecto a los riesgos identificados, así como

la aprobación de los riesgos residuales.
• Documento de aplicabilidad con la relación de los controles que son aplicables
para conseguir el nivel de riesgo residual aprobado por la dirección.
Definir
alcance
Definir política
de seguridad
Identificar activos
Definir el enfoque
de análisis
Identificar los riesgos
Analizar los riesgos
Tratar los riesgos
Figura 2.3. Establecer el SGSI
2.2.2. Definición del alcance del SGSI

Es decir, sobre qué proceso (o procesos) va a actuar, ya que no es necesaria la apli-
cación de la norma a toda la entidad. Hay que evaluar los recursos que se pueden
dedicar al proyecto y si realmente es preciso abarcar toda la organización. Normal-
mente es más práctico limitar el alcance del SGSI a aquellos servicios, departamentos
o procesos en los que resulte más sencillo, bien porque el esfuerzo va a ser menor
o porque la visibilidad del proyecto (interna o externa) es mayor. En cualquier caso,
hay que tener en cuenta que dimensionar correctamente el proyecto es fundamental

para alcanzar el éxito. Embarcarse en un proyecto costoso, complejo, que se alarga
en el tiempo, con falta de resultados, está abocado al fracaso.
2.2.3. Definición de la política de seguridad

Decidir qué criterios se van a seguir, estableciendo las principales líneas de acción
que se van a seguir para que la confidencialidad, la integridad y la disponibilidad
queden garantizadas. Esta política tendrá en cuenta los requisitos del negocio, los
contractuales y los legales y estatutarios que sean aplicables. Es primordial incorpo-
rar en esta fase inicial las necesidades de la organización. Aunque a veces son difíci-
les de expresar y documentar, es esencial que el SGSI esté alineado con el resto de
las estrategias, planes y modos de funcionar de la organización para que pueda inte-
grarse en el día a día sin complicaciones y rindiendo resultados desde el principio.
Cuando resulte posible, será útil recopilar los documentos de seguridad existentes
en la organización para incorporarlos desde el principio al sistema. La política de
seguridad debe dejar claras las normas básicas de seguridad en la organización,
definiendo cuál va a ser el comportamiento de la misma en cuanto a los usos de la
información y de los sistemas, los accesos, cómo se gestionarán las incidencias, etc.
Los empleados deben conocer esta política y adherirse a ella, incluso formalmente
si es necesario.
2.2.4. Identificación de los activos de información

Se deben identificar junto con sus responsables. El SGSI va a proteger los activos
que queden dentro del alcance definido, por eso es vital listarlos todos, lo cual no
significa que haya que detallar cada componente de los sistemas de información y
cada documento que se maneje en la empresa, pero sí es indispensable identificar
qué activos son los que soportan los procesos de la organización. Es decir, qué hace
falta para que la empresa funcione: los equipos, las aplicaciones, los informes, los
expedientes, las bases de datos, las comunicaciones, etc. Para ello, lo primero es
identificar los activos dentro del alcance del SGSI (hardware, software, infraestruc-
turas, aplicaciones, servicios, etc.) junto con los responsables de estos activos.
Una vez identificados deben valorarse, de manera que se puedan categorizar, ya
que es probable que este inventario de activos sea voluminoso, por lo que no es
viable realizar un análisis de riesgos sobre todos ellos. De acuerdo con la relevancia
que la organización otorgue a los activos, se escogerá el grupo de los más valiosos
para efectuar el análisis de riesgos. Esta tarea consume gran parte de los recursos del
proyecto, por lo que es conveniente simplificarla ya desde esta fase.
Los activos deben relacionarse con los procesos de negocio que soportan, de
forma que quede explícita la dependencia del negocio respecto de esos activos.
La norma es bastante clara al respecto. El SGSI debe apoyar la consecución de
los objetivos de negocio. Se realiza una gestión para obtener unos resultados, la
seguridad de la información no es una excepción. Su gestión ha de estar orien-
tada en todo momento a que la organización funcione más y mejor y consiga sus
propósitos. Como la seguridad parece un tema muy técnico se puede caer en el
error de considerar que es un problema que deben solucionar los informáticos.
No cabe duda de que la seguridad de la información consta de un destacable
componente técnico y que el personal técnico debe estar involucrado activamente
en el diseño, desarrollo y mantenimiento de un SGSI, pero recordemos que esta-
mos hablando de un sistema de gestión, por lo que la parte de gestión es tanto
o más importante que la parte técnica. Un sistema no funciona si el personal que
lo debe utilizar no lo hace. Como prueba, sólo hay que pensar que las incidencias
más graves de seguridad no suelen tener su origen en fallos técnicos, sino en fallos
humanos.
2.2.5. Definición del enfoque del análisis de riesgos

Hay que decidir cómo se enfocará el análisis de riesgos. El análisis de riesgos deter-
minará las amenazas y vulnerabilidades de los activos de información previamente
inventariados. Esta tarea es crucial para el correcto diseño del SGSI, puesto que de
su resultado depende que se escojan unos controles u otros, que son los que con-
formarán nuestro sistema.
Como es una tarea laboriosa, se buscan métodos para que su ejecución sea más
simple sin dejar de ser rigurosa. Primeramente se elige el nivel de detalle con el
que se va a llevar a cabo el análisis, enfoque de mínimos o detallado, y después
el grado de formalidad, enfoque informal o formal. Estas categorías no son exclu-
yentes, es decir, se puede optar por un enfoque detallado y formal para un grupo
de activos muy críticos, para otro grupo importante se hace un análisis detallado e
informal y para un tercer grupo de menor relevancia, un enfoque de mínimos.
Esto se llamaría enfoque mixto. En un enfoque de mínimos se establece un nivel
básico de seguridad para los sistemas, efectuando una simplificación del inventario
de activos y del análisis de riesgos que consuma los recursos mínimos. Con un
enfoque detallado se realizan revisiones detalladas del análisis de riesgos para todos
los sistemas, se identifican todos los riesgos y la evaluación de sus magnitudes.
Como estas tareas consumen muchos recursos, no se suele utilizar un enfoque deta-
llado para todos los activos, sólo para los más notables.
2.2.6. Cómo escoger la metodología del análisis

de riesgos
Puesto que la norma únicamente establece que los resultados han de ser compara-
bles y repetibles, debe escogerse aquella metodología que mejor se adapte a los
modos de trabajo de la organización, así el ejercicio se integrará sin problemas en
el trabajo cotidiano. Además, ayuda a que los resultados sean más aceptables por la
organización y a que se pueda mantener en el tiempo. Si la metodología escogida
es excesivamente complicada y requiere mucho esfuerzo para llevar a cabo el análisis,
la carga de trabajo añadida complicará el proyecto, y los resultados pueden parecer
poco fiables por los no implicados directamente en su obtención, puesto que será
difícil explicarlos.
Identificar los riesgos que pueden afectar a la organización y a sus activos de infor-
mación. Hay que saber cuáles son los peligros a los que se enfrenta la empresa, los
puntos débiles, para poder solucionar de manera efectiva los problemas, insistiendo
con más recursos y esfuerzos en los temas que más lo necesitan. Un SGSI tiene que
incluir medidas de seguridad apropiadas a los riesgos a los que la organización debe
enfrentarse, para ello se planteará un análisis de riesgos que determine el nivel de
riesgo existente sobre los activos de información de la empresa. Con un método
de análisis de riesgos ya escogido se identificarán las amenazas sobre estos activos,
las vulnerabilidades que podrían ser explotadas por las amenazas y los impactos que
pueden tener en los activos. El riesgo se define a menudo como la función del daño
que podría producir una amenaza por la probabilidad de que eso ocurra. Cuantifi-
cando estos parámetros, se obtendrán los valores de riesgo para cada activo.
Definir los criterios para aceptar los riesgos y seleccionar los controles, de manera
proporcional a los riesgos detectados y a los recursos disponibles. En la práctica, el
punto de corte para decidir si se acepta un riesgo o no va a venir dado por los
recursos que se le puedan asignar al SGSI. Puesto que tendremos valores para cada
uno de los activos, se decidirá a la vista de los mismos dónde se halla el valor por
debajo del cual ya no podremos hacer más de lo que se ha hecho. Aplicar controles
a todos los activos no suele ser viable ni organizativa ni económicamente.
Una vez definidos los límites, condicionantes y requisitos que debe cumplir el
SGSI, puesto que en la norma no se requiere que exista un Manual de seguridad en
la línea de otras normas de gestión, toda esta información debe quedar plasmada
en parte de los documentos que compondrán el SGSI. En particular es necesario
documentar en esta fase:
• La política de seguridad, que además debe aprobarse por la dirección.
• La metodología a seguir para realizar el análisis de riesgos.
2.2.7. Tratamiento de los riesgos

Obtenidos los niveles de riesgo, hay que decidir si son aceptables o no, según el cri-
terio fijado previamente. Si no lo son, hay que evaluar cómo se van a tratar esos
riesgos:
• Mitigar el riesgo. Es decir, reducirlo, mediante la implementación de controles
que disminuyan el riesgo hasta un nivel aceptable.
• Asumir el riesgo. La dirección tolera el riesgo, ya que está por debajo de un
valor de riesgo asumible o bien porque no se puede hacer frente razonable-
mente a ese riesgo, por costoso o por difícil. La dirección debe firmar que
los activos con un valor de riesgo inferior no estarán sometidos a controles
que mitiguen el riesgo.
• Transferir el riesgo a un tercero. Por ejemplo, asegurando el activo que tiene
el riesgo o subcontratando el servicio. Aún así, evidenciar que la responsabi-
lidad sobre el activo permanece siempre en manos de la organización y tener
en cuenta que hay daños, como los causados a la reputación de la organiza-
ción, que difícilmente son cubiertos por ningún seguro.
• Eliminar el riesgo. Aunque no suele ser la opción más viable, ya que puede
resultar complicado o costoso.
También se puede optar por una estrategia que combine dos o más de estas elec-
ciones. Por ejemplo, un sistema muy crítico y con mucho riesgo puede decidirse a
aplicar controles que mitiguen el riesgo en los aspectos operativos cotidianos y sub-
contratar los cambios con lo que se transferirá parte del riesgo al contratista. La
opciones más habituales son las de mitigar y asumir. Cuando se resuelva mitigar el
riesgo, los controles deben ser seleccionados e implementados teniendo en cuenta
los requisitos identificados y el resultado del análisis de riesgos.
2.2.8. Selección de controles

La norma especifica que los controles deben ser seleccionados de entre los listados
en el anexo A de la propia norma, es decir, los que la Norma UNE-ISO/IEC 27002
contiene. En caso necesario, se pueden añadir otros, pero esta lista de controles es
un sólido punto de partida para elegir las medidas de seguridad apropiadas para
el SGSI, asegurando que ningún aspecto o control importante se pasan por alto.
La selección de controles es un punto crítico del SGSI. A la hora de escoger o
rechazar un control se debe considerar hasta qué punto ese control va a ayudar
a reducir el riesgo que hay y cuál va a ser el coste de su implementación y mante-

nimiento. Cabe la posibilidad de que un control que se estime oportuno imple-
mentar, sea demasiado costoso o difícil de implementar para la organización, por
resistencia al cambio o por falta de formación, y que haya que excluirlo de la selec-
ción por esos motivos. Un SGSI no tiene necesariamente que tener cubiertos todos
y cada uno de los riesgos a los que se está expuesto, sino que tratará de mitigarlos
de acuerdo con las necesidades del negocio. Las necesidades de seguridad de un
banco y de un almacén de madera son radicalmente distintas, y eso significa que
sus SGSI también han de serlo. Nunca el coste de implementación y manteni-
miento de un control debe superar a los beneficios que se esperan de él.
2.2.9. Gestión de riesgos

Una vez seleccionados los controles se repetirá el análisis de riesgos, teniendo en
cuenta ya todas las medidas de seguridad implementadas y aquellas elegidas para
hacerlo. El valor del riesgo obtenido será el riesgo actual, en función del que se
determina el riesgo asumible por la organización, y se deciden las nuevas estrate-
gias y acciones para reducir los riesgos que estén por encima de ese valor.
Una tercera iteración del análisis de riesgos que contemplan las medidas previstas,
nos dará los riesgos residuales.
La dirección debe aprobar el valor de riesgo aceptable y asumir el riesgo residual.
2.2.10. Declaración de aplicabilidad

El siguiente requisito de la norma es la preparación de una declaración de aplicabi-
lidad, que debe incluir:
• Los objetivos de control y los controles seleccionados, con las razones de
esta selección.
• Los objetivos de control y los controles actualmente implementados, con
una justificación.
• La exclusión de cualquier control objetivo del control y de cualquier control
en el anexo A y la justificación para dicha exclusión.
Esta declaración de aplicabilidad sirve para comprobar que realmente se han consi-
derado todas las opciones de controles disponibles y que no se ha omitido ninguno.
2.2.11. Implementación y puesta en marcha del SGSI

Para poner en marcha el SGSI la dirección tiene que aprobar la documentación desa-
rrollada en las actividades detalladas en el punto anterior y proveer los recursos
necesarios para ejecutar las actividades.
Estas actividades se registrarán en un plan de tratamiento del riesgo que regule todas
las acciones necesarias para tratarle, además de los recursos, las responsabilidades y las
prioridades para la gestión de los riesgos de seguridad de la información.
Tan importante como la definición de las tareas a realizar y los recursos que se van a
asignar, es decidir cómo se va a medir la eficacia de estas acciones y de las medidas de
seguridad aplicadas. Esto implica establecer un conjunto de objetivos y métricas aso-
ciadas a los mismos, tanto para los procesos como para las medidas de seguridad, que
permitan evaluar de manera objetiva y precisa el avance en la mejora de la seguridad.
La seguridad de la información es una cuestión multidisciplinar e importante para
cada proyecto y sistema y para todos los usuarios en la organización. La asignación
y delimitación de responsabilidades debe asegurar que se acometen todas las tareas
relevantes y que se llevan a cabo de un modo eficiente. Si bien este objetivo puede
lograrse a través de diversos esquemas, dependiendo de la estructura y tamaño de
la organización, en cualquier caso se ha de de contar con la designación de:
• Un responsable de seguridad, que coordine las tareas y esfuerzos en materia de
seguridad. Actuará como foco de todos los aspectos de seguridad de la organi-
zación y sus responsabilidades cubrirán todas las funciones de seguridad.
• Un comité de seguridad que trate y busque soluciones a los temas de seguri-
dad, resuelva los asuntos interdisciplinarios y apruebe directrices y normas.
Ambos, el comité de seguridad y el responsable de seguridad de la organización,

deben tener sus tareas bien delimitadas y encontrarse a un nivel suficiente en la
estructura de la organización, de forma que pueda asegurarse el compromiso con
la política de seguridad. La organización debe proporcionar líneas claras de comu-
nicación, responsabilidad y autoridad al responsable de seguridad, y sus tareas han
de ser aprobadas por el comité de seguridad.
2.2.12. Control y revisión del SGSI

La revisión del SGSI forma parte de la fase del Check (comprobar) del ciclo PDCA.
Hay que controlar y revisar el SGSI de manera periódica para garantizar la conve-
niencia, adecuación y eficacia continuas del sistema.
Para efectuar la revisión hay que recopilar información de los resultados de las dis-
tintas actividades del SGSI para comprobar si se están alcanzando los objetivos, y,
si no es así, averiguar las causas y buscar soluciones.
Las revisiones consistirán en estudiar los resultados de las auditorías de seguridad,
los incidentes, los resultados de la eficacia de las mediciones, las sugerencias y las
opiniones de todas las partes interesadas. Hay que medir la eficacia de los controles
para verificar que se han cumplido los requisitos de seguridad.
Además, hay que revisar los análisis del riesgo a intervalos planificados y examinar
los riesgos residuales, así como los niveles aceptables del riesgo, teniendo en cuenta
los cambios en la organización, la tecnología, los objetivos y procesos del negocio,
las amenazas identificadas, la eficacia de los controles implementados, los cambios
en el entorno legal o reglamentarios, cambios en las obligaciones contractuales y
cambios en el entorno social. Las auditorías internas del SGSI también forman
parte de esta fase de revisión.
Las revisiones del SGSI tienen que estar planificadas y gestionadas para asegurar
que el alcance continúa siendo adecuado y que se han identificado mejoras en el
proceso del SGSI.
En cualquier caso, todos los resultados de las revisiones deben ser documentados
para proporcionar evidencia de su realización, involucrar a la dirección en la ges-
tión del sistema y apoyar las acciones de mejora, así como para actualizar los planes
de seguridad.
2.2.13. Mantenimiento y mejora del SGSI

La seguridad es un proceso en continuo cambio. Las organizaciones no son estáti-
cas y su gestión tampoco lo es. Por lo tanto, sería un grave error considerar que una
vez analizados los riesgos y definidas las medidas para reducirlos se haya terminado
el trabajo. Los cambios en la organización impactarán en los niveles de riesgo y a la
inversa, y tiene que haber mecanismos que acomoden estos cambios y mantengan
el nivel de seguridad en un nivel aceptable.
Un sistema de gestión debe mantenerse y mejorarse en lo posible para que resulte
efectivo. El mantenimiento incluye el detectar mejoras e implementarlas, aprender
de los defectos y errores identificados, y aplicar acciones correctivas y preventivas
donde sea apropiado.
2.3. Requisitos de documentación

2.3.1. Generalidades
El SGSI debe contar con la documentación necesaria que justifique las decisiones
de la dirección, las políticas y las acciones tomadas y que se pueda demostrar que
los controles seleccionados lo han sido como resultado de estas decisiones y del
análisis de riesgos. Es decir, se debe delinear la trazabilidad que se ha de seguir
desde las políticas y objetivos hasta los controles implementados.
Por ello es necesario tener documentado:
• La política y los objetivos del SGSI.
• El alcance del SGSI.
• Una descripción de la metodología de análisis del riesgo.
• El inventario de activos.
• Los procedimientos y controles de apoyo al SGSI.
• El análisis del riesgo.
• El plan de tratamiento del riesgo.
• La declaración de aplicabilidad.
• Los procedimientos necesarios para la implementación de los controles y
para asegurarse de que se cumplan los objetivos.
• Los registros requeridos por la norma.
La norma no exige ningún tipo de formato para los documentos ni para los regis-
tros, cualquier soporte es válido.
2.3.2. Control de documentos

Los documentos requeridos por el SGSI deben hallarse protegidos y controlados,
por lo que se precisan unos procedimientos de control de documentación, de revi-
sión y de registro (informes, auditorías, cambios, autorizaciones de acceso, permisos
temporales, bajas, etc.).
Los procedimientos de documentación deben contemplar cómo se generan, aprue-
ban, revisan y actualizan los documentos según sea necesario.
Una buena gestión documental contará con que los cambios sean identificados y
que la identificación de los documentos y su estado resulten claras.
Los documentos deben estar disponibles y accesibles en todos los puntos en los que
sea necesario utilizarlos. Además, hay que comprobar que el almacenamiento sea
correcto y que cuando haya que destruir los documentos se haga de acuerdo con su
clasificación. Cuando un documento quede obsoleto hay que retirarlo para evitar
su uso.
2.3.3. Control de registros

Los registros son aquellos documentos que proporcionan evidencia de la realiza-
ción de actividades del SGSI. Con ellos se puede verificar el cumplimiento de los
requisitos. Ejemplo de registros son el libro de visitas, los informes de auditorías y
los logs de los sistemas.
Los registros estarán protegidos y controlados teniendo en cuenta cualquier requi-
sito de tipo legal, reglamentario u obligación contractual. Permanecerán legibles,
fácilmente identificables y recuperables. Los controles necesarios para la identificación,
almacenamiento, protección, recuperación, tiempo de conservación y disposición
de los registros se encontrarán documentados e implementados.
Deberán guardarse todos los registros del funcionamiento del proceso y las inci-
dencias de seguridad significativas relacionadas con el SGSI.
2.4. Compromiso de la dirección

Uno de los requisitos fundamentales para poner en marcha un SGSI es contar
con el compromiso de la dirección, no sólo por ser uno de los epígrafes contem-
plados en la norma, sino porque el cambio de cultura y concienciación que
genera el proceso sería imposible de sobrellevar sin el compromiso constante de
la dirección.
El desarrollo, la implementación y el mantenimiento del SGSI exigen un esfuerzo
organizativo importante, que únicamente podría llevarse a cabo con una voluntad
clara de hacerlo por parte de la dirección, puesto que es ella quien tiene que pro-
veer de recursos al proyecto, tanto financieros como humanos, por lo que su apoyo
es imprescindible.
La dirección debe comprometerse de manera evidente con el establecimiento,
implementación, puesta en marcha, monitorización, revisión, mantenimiento y
mejora del SGSI. La forma en la que se plasma este compromiso es colaborando o

ejecutando, según los casos, las siguientes tareas:
• Establecer la política del SGSI.
• Asegurar que se establecen los objetivos y planes del SGSI.
• Asignar los roles y las responsabilidades para la seguridad de la informa-
ción.
• Comunicar a la organización la conveniencia del cumplimiento de los obje-
tivos de seguridad de la información y, conforme a la política de seguridad
de la información, sus responsabilidades legales y la necesidad de la mejora
continua.
• Proporcionar recursos suficientes para implementar, mantener y mejorar
el SGSI.
• Decidir los criterios de aceptación de los riesgos.
• Verificar que se realizan las auditorías internas del SGSI.
• Dirigir la gestión de las revisiones del SGSI.
2.5. Gestión de los recursos

Como se comentaba anteriormente, es la dirección la que debe gestionar los
recursos. Ha de comenzar por proveer de recursos al desarrollo y mantenimiento
del SGSI en función de lo que se estime necesario para establecer, implementar,
poner en funcionamiento, efectuar el seguimiento, revisar, mantener y mejorar el
SGSI.
Hay que contar con las diversas tareas que implica el funcionamiento, la verifica-
ción y la mejora del sistema, puesto que conservar el nivel de seguridad que aporta
el SGSI sólo puede lograrse comprobando regularmente que los procedimientos
de seguridad están alineados con el negocio, que cumplen con los requisitos legales,
que los controles están correctamente implementados y que se llevan a cabo las
acciones oportunas para corregir errores y mejorar el sistema.
Capítulo aparte merece la gestión de los recursos humanos. Este punto es uno de
los factores críticos de éxito. Sin una colaboración activa del personal es muy difícil
implementar con éxito un SGSI.
2.6. Formación
La norma exige que todos los trabajadores con responsabilidades definidas en el
SGSI sean competentes para efectuar las actividades necesarias. Esto significa que
hay que definir las competencias necesarias y, en función de tales necesidades,
proporcionar la formación a la plantilla o adoptar otras acciones para satisfacerlas
(por ejemplo, la contratación de personal competente).
Como cualquier otra actividad, requiere una planificación, así como verificar que
se cumplen los objetivos y mantener los registros de educación, formación y cuali-
ficación de los empleados.
Independientemente de la formación, el personal estará concienciado de la impor-
tancia de las actividades de seguridad de la información y en particular de las suyas
propias, y de que cómo la aportación de cada uno es fundamental para alcanzar los
objetivos de seguridad establecidos, y en consecuencia los de la organización.
En la medida que seamos capaces de formar al personal y concienciarlo de que es
fundamental ceñirse a las normas de seguridad, reduciremos drásticamente la pro-
babilidad de fallos y su potencial impacto.
2.7. Auditorías internas

Una de las herramientas más interesantes para controlar el funcionamiento del
SGSI son las auditorías internas. Estas auditorías deben programarse y prepararse
regularmente, normalmente una vez al año. Esta programación se recogerá en el
plan de auditorías.
A la hora de desarrollar el plan de auditorías hay que fijarse en:
• El estado e importancia de los procesos y las áreas que serán auditadas, de
este modo se determinará el tiempo y los recursos que habrá que destinar
para efectuar la auditoría.
• Los criterios de la auditoría.
• El alcance, si va a ser global (va a abarcar toda la empresa) o parcial (sólo una
parte).
• La frecuencia de realización de las auditorías, sabiendo que cada tres años, al
menos, toda la organización debe ser auditada.
• Los métodos que se van a utilizar para hacer las auditorías.
El plan ha de estar aprobado por la dirección. Una vez preparado y aprobado, debe
distribuirse a todos los departamentos y a los auditores afectados con la suficiente
antelación, de manera que puedan preparar adecuadamente la auditoría.
Las auditorías internas sirven para determinar si los objetivos, los controles y los
procedimientos son conformes con los requisitos aplicables (los de la propia
norma, los de negocio, los legales, los de seguridad, etc.), así como el grado de
implementación que tienen, si se están aplicando bien y si los resultados obtenidos
son los esperados.
Debe existir un procedimiento documentado que defina las responsabilidades y los
requisitos para planificar y dirigir las auditorías, para informar de los resultados y para
mantener los registros, tales como el informe de auditoría emitido por los auditores.
El responsable del área auditada debe asegurar que las acciones para eliminar las
no conformidades detectadas y sus causas se llevan a cabo en un plazo razonable.
El seguimiento de las actividades debe incluir la verificación de las acciones tomadas
y el informe de la verificación de los resultados.
Es importante la selección de los auditores, ya que no deben auditar su propio tra-
bajo, sólo siendo independientes se puede garantizar la imparcialidad.
2.8. Revisión por la dirección

La dirección debe revisar el SGSI de manera periódica para garantizar la conve-
niencia, adecuación y eficacia continuas del sistema. El proceso de revisión por la
dirección no debería ser un ejercicio ejecutado únicamente para cumplir los requi-
sitos de la norma y de los auditores, sino que debería ser una parte integral del pro-
ceso de gestión del negocio de la organización.
Para realizar esta revisión hay que recopilar información de los resultados de las dis-
tintas actividades del SGSI para comprobar si se están alcanzando los objetivos, y
si no es así, averiguar las causas y decidir sobre las posibles soluciones.
Esta revisión es una de las pocas tareas que se le asigna específicamente a la dirección,
por lo que posee relevancia en varios aspectos: mantiene a la dirección en contacto
con la realidad del SGSI, ya que lógicamente no se encuentra involucrada en el día a
día, pero es importante que esté al tanto de los trabajos realizados, de los logros obte-
nidos y de los problemas que aparezcan. Además es una herramienta para aportar ini-
ciativas al SGSI, ya que es la dirección la encargada de la visión estratégica de la
empresa, la que determina hacia dónde debe ir y cómo. Como herramienta de ges-
tión que es, el SGSI debe incorporar esta visión y colaborar para hacerla viable.
2.8.1. Entradas a la revisión

Los resultados de la revisión deben ser documentados para proporcionar evidencia
de su realización, involucrar a la dirección en la gestión del sistema y apoyar las
acciones de mejora.
Las entradas a la revisión pueden ser:
• Los resultados de las auditorías y las revisiones del SGSI.
• Comentarios de las partes interesadas (usuarios de los sistemas de informa-
ción, contratistas, clientes, etc.).
• Técnicas, productos o procedimientos que podrían ser empleados en la orga-
nización para mejorar el funcionamiento y la efectividad del SGSI.
• El estado de las acciones preventivas y correctivas.
• Las vulnerabilidades o amenazas que no se han tratado adecuadamente en
análisis de riesgos anteriores.
• Los resultados de las métricas de efectividad.
• Las acciones de seguimiento de anteriores revisiones por la dirección.
• Cualquier cambio que pudiera afectar al SGSI.
• Recomendaciones para la mejora.
Con esta información se puede tener una visión general de hasta qué punto el SGSI
está funcionando bien, mal o no todo lo bien que se esperaba. Investigando en las
causas de los fallos o dificultades encontradas se pueden corregir los errores y mejorar
el rendimiento del sistema, que en definitiva es el objetivo de la revisión, además
de involucrar a la dirección activamente en la gestión del sistema.
2.8.2. Salidas de la revisión

Los resultados de la revisión pueden ser de varios tipos:
• Identificación de acciones para mejorar la efectividad del SGSI.
• Actualización de la evaluación y la gestión de riesgos.
• Modificación de los procedimientos y controles que afectan a la seguridad
de la información para ajustarse a incidentes o cambios en:
– Requisitos de negocio, de seguridad o legales.
– Procesos de negocio que tengan efecto en los requisitos de negocio exis-

tentes.
– Obligaciones contractuales.
– Niveles de riesgo y/o criterios para aceptar los riesgos.
– Necesidades de recursos.
• Realización de mejoras en la manera de medir la efectividad de los con-

troles.
La revisión, aunque se centre en la detección y resolución de problemas en la gestión

y operativa del SGSI, debe considerar también los puntos fuertes, es decir, qué se
está haciendo bien y la razón, sobre todo en comparación con revisiones anteriores,
de manera que se ponga en evidencia la mejora continua del sistema.
Como resultado del proceso de revisión por la dirección, debería existir evidencia
de decisiones relacionadas con cambios en la política y los objetivos de seguridad,
los planes, presupuestos o acciones de mejora.
Se requieren registros de la revisión por la dirección, pero no se especifica su
formato. Las actas de las reuniones son el tipo más común de registro, pero los
registros electrónicos, los diagramas estadísticos, las presentaciones, etc., podrían
ser tipos de registro aceptables.
El informe de revisión por la dirección suele realizarlo el responsable de seguridad
y discutirse dentro del comité de seguridad, aunque es la dirección quien debe
aprobarlo una vez consensuado.
2.9. Mejora continua

La mejora continua es una actividad recurrente para incrementar la capacidad a la
hora de cumplir los requisitos. El proceso mediante el cual se establecen objetivos
y se identifican oportunidades de mejora es continuo.
Es un punto fundamental en cualquier sistema de gestión según las normas ISO.
Este concepto también es crucial en todos los modelos de mejora de procesos o
negocio que existen. En pura lógica, cualquier organización desea hacer las cosas
cada vez mejor (mejores productos, más baratos, en menos tiempo, mayores bene-
ficios), por lo que la mejora continua es un concepto empresarial de primer orden.
Los sistemas de gestión tendrán por tanto que apoyar este proceso, que se reali-
menta a sí mismo y nunca termina, ya que siempre se puede mejorar en algo.
Cuando una organización se considera madura, es decir, cuando la mejora conti-

nua forma parte de la cultura de la empresa y se obtiene el máximo rendimiento de
los procesos, es porque todos los niveles de la organización están involucrados y la
dirección ha hecho de la mejora continua una de las herramientas fundamentales
para la gestión del negocio. Aunque la mejora continua es un proceso que debe ser
impulsado desde la dirección, su implementación se realizará en la base, donde se
ejecuta el trabajo.
Las principales herramientas para la mejora continua son las revisiones, las audito-
rías, las acciones correctivas, preventivas y de mejora, los objetivos y el análisis de
los incidentes de seguridad. Los resultados de estas actividades son una valiosísima
fuente de información sobre cuáles son los puntos débiles de la organización y sus
procesos. Sabiendo esto, se pueden tomar acciones encaminadas a eliminarlos,
haciendo que los procesos sean más eficientes y efectivos, en definitiva, que hacer
el trabajo sea cada vez más rápido y menos costoso, tanto en recursos humanos
como en materiales.
2.9.1. Acción correctiva

La acción correctiva se define como la tarea que se emprende para corregir una no
conformidad significativa con cualquiera de los requisitos del sistema de gestión de
seguridad de la información.
Localizado el problema debe determinarse la relación causa-efecto, considerando
todas las causas posibles. A veces no es fácil dilucidar cuáles son las causas exactas
del problema, pero hay que intentar aproximarse lo más posible. En primer lugar
porque sólo conociendo de dónde partió el problema se puede tomar una decisión
coherente y acertada para solucionarlo. Y además porque es la manera de ir desta-
pando los puntos débiles de nuestros procesos. En más de una ocasión varios pro-
blemas detectados se han originado de un único punto, y hasta que no se solucione
ese punto es muy probable que se sucedan incidencias que aparentemente pueden
tener poco que ver entre sí.
Una vez localizado el origen, se analiza su importancia relativa y las alternativas que
pueden aplicarse para solucionar el problema, evaluando su coste y complejidad.
Esto se realizará normalmente dentro del comité de seguridad, que tomará la deci-
sión sobre las acciones a tomar y asignará responsables y plazos para su ejecución.
Es esencial el cumplimiento de los plazos, y el comité debe velar por ello y analizar,
en su caso, cuáles son los motivos por los que no se cumplen.
Un error frecuente cuando se empiezan a utilizar las acciones correctivas es hacerlo
para todo, grandes y pequeños problemas. Es cierto que, y más al principio, es difí-
cil distinguir entre los diversos grados de gravedad de las incidencias o no confor-
midades detectadas. Pero utilizar las acciones correctivas para todo no resulta
eficaz, deberían reservarse para asuntos que no pueden ser resueltos satisfactoria-
mente por otros medios. Cuando surgen los problemas hay que valorar si son inci-
dentes cotidianos, problemas de origen conocido, de fácil solución y que no conllevan
un impacto considerable. Si el problema tiene causas difíciles de detectar, la solu-
ción no es obvia o factible, es un hecho recurrente, el impacto que ha causado es
importante o es una desviación sistemática de las normas, entonces sí es apropiado
utilizar una acción correctiva para solucionarlo.
Esta herramienta debe emplearse para detectar errores o fallos en los procesos y
nunca para buscar culpables. Si no se hace así, no se contará con la colaboración
del personal en la detección de las causas de los problemas y la búsqueda de solu-
ciones, y realmente son los que tienen el conocimiento para ello, por lo que es fun-
damental asegurarse su colaboración.
2.9.2. Acción preventiva

Las acciones preventivas se aplican para evitar la aparición de futuras no conformida-
des. Son acciones encaminadas a eliminar la causa de una posible no conformidad.
En una acción preventiva se determina la posible fuente de problemas con el objeto
de eliminarla. Se pretende con ello evitar tener que solucionar problemas, puesto
que es más eficaz y sencillo prevenirlos que solucionarlos.
Se puede decidir abrir acciones preventivas a raíz de observaciones detalladas en las
auditorías internas o externas, del análisis de la evolución de los objetivos y de los
resultados de las actividades de revisión, ya que pueden utilizarse como fuentes de
información para el establecimiento de acciones preventivas:
• Los resultados de la revisión por la dirección.
• Los resultados de los análisis de incidencias y objetivos.
• Los registros.
• El personal.
Las acciones preventivas son poco frecuentes al inicio de la implementación de un

SGSI, ya que requieren una cierta madurez del sistema y una actitud proactiva del
personal para que afloren los problemas potenciales susceptibles de ser el objeto de
una acción preventiva. Por eso mismo son una potente herramienta de gestión que
permite adelantarse a los fallos, economizando recursos y costes. Se pasa de una
coyuntura de “apagar fuegos” a controlar la situación y modificarla de acuerdo con
las necesidades de la organización.
Tanto en el caso de las acciones preventivas como en el de las correctivas, debe asig-
narse responsables con nombres y apellidos, y determinar fechas límites de resolu-
ción para que la responsabilidad no se diluya. Por supuesto no es viable asignar
tareas a quien puede no tener la competencia o autoridad para llevarlas a cabo, por
lo que hay que ser cuidadosos al asignar dichas responsabilidades.
2.10. El anexo A
El anexo A contiene los 133 controles considerados como las mejores prácticas en
seguridad de la información y que se detallan en la Norma UNE-ISO/IEC 27002.
A lo largo de la Norma UNE-ISO/IEC 27001 se referencia este anexo como el
punto de partida para la selección de controles. Es decir, cuando se está desarro-
llando el SGSI, al llegar a dicha tarea, se debe utilizar esta tabla como lista de che-
queo para decidir si procede o no aplicar cada uno de los controles. El resultado de
este chequeo se documentará en el documento de aplicabilidad.
3 Comprender la Norma
UNE-ISO/IEC 27002
Esta norma contiene 11 capítulos de controles de seguridad, es decir, áreas de la

seguridad a considerar, con un total de 39 categorías principales de seguridad, con
sus correspondientes objetivos y los controles asociados a esos objetivos, más un
capítulo de introducción sobre valoración y tratamiento del riesgo.
Los 11 capítulos (acompañados del número de categorías principales de seguridad
incluidos dentro de cada capítulo) son los siguientes:
• Política de seguridad (1).
• Aspectos organizativos de la seguridad de la información (2).
• Gestión de activos (2).
• Seguridad ligada a los recursos humanos (3).
• Seguridad física y del entorno (2).
• Gestión de comunicaciones y operaciones (10).
• Control de acceso (7).
• Adquisición, desarrollo y mantenimiento de los sistemas de información (6).
• Gestión de incidentes de seguridad de la información y mejoras (2).
• Gestión de la continuidad del negocio (1).
• Cumplimiento (3).
Para cada uno de los controles la norma proporciona guías para su imple-
mentación. Esta norma no es certificable, por lo que las recomendaciones no deben
ser consideradas normativas. Las indicaciones que da la norma son bastantes
exhaustivas, por lo que resultan muy útiles como referencia, pero no son obligatorias.
El grado de implementación de cada uno de los controles es algo que la organización
debe decidir en función de sus necesidades y recursos disponibles. Y, por supuesto, el
modo en que se implementen es de competencia exclusiva de la organización.
3.1. Valoración y tratamiento del riesgo

La norma propone 133 controles, pero no para tener que cumplirlos todos, sino
para elegir de entre ellos los que sean más apropiados. Esto es precisamente lo que
nos ayudará a decidir la valoración del riesgo.
Una vez identificados y valorados los activos, se elige el grupo a analizar. Pueden
ser todos, pero en el caso de que sean numerosos es recomendable escoger un
grupo, habitualmente el de los más críticos, para no complicar en exceso el análisis
de riesgos. Este análisis es una tarea crucial y, en muchos casos, la más laboriosa,
por cuanto exige valorar una gran cantidad de parámetros desde múltiples puntos
de vista, y suele implicar a multitud de personas que deben llegar a un consenso en
sus valoraciones. El objetivo es poner un valor lo más objetivo posible a los riesgos
a los que están expuestos los activos.
Para ello existen diversas metodologías, como CRAMM, Ebios, Magerit, ISO
13335-2, etc., y muchas herramientas en el mercado, como Callio, Cramm, Pilar,
casi siempre basadas en alguna de las metodologías más aceptadas. Lo importante es
elegir aquel método o herramienta que sea fácil de utilizar y que no exija demasiado
esfuerzo después para mantener actualizado el análisis de riesgos.
Es necesario que el personal de los distintos ámbitos de la organización se implique
en la realización del análisis de riesgos. Lo que la norma sí exige es que este análisis
sea objetivo y repetible. Para cumplir con el primer requisito resulta casi impre-
scindible que la mayor parte de las áreas implicadas en el SGSI participen y aporten
su punto de vista en el análisis de riesgos. Las distintas perspectivas permitirán
obtener un idea más precisa de cuáles son exactamente los peligros y en qué medida
pueden afectar a la organización, sobre todo cuando la organización funciona por
departamentos y no por procesos, puesto que cada área conoce y controla lo que
pasa en su entorno, pero no en el resto, no lo que ocurre a lo largo de todo el pro-
ceso, y saber eso es precisamente lo que se necesita para que el análisis de riesgos
sea realista y esté lo menos sesgado posible hacia un área en particular. Cuanto más
objetivo sea el análisis y más fácil de utilizar el método o herramienta escogido,
mejor se cumplirá el segundo requisito de que el análisis sea repetible.
En general, en cualquier metodología o herramienta se proporcionará una lista de
posibles amenazas, unas vulnerabilidades que habrá que considerar, y unos baremos
para ponderar la probabilidad y el impacto que ocasionarían en la organización

que la amenaza se convirtiese en realidad. Valorando todos los parámetros que nos
ofrecen, se obtendrá un valor de riesgo. Señalar que este análisis de riesgos debe
efectuarse observando que no existe ninguna medida de seguridad implementada
para calcular lo que se llama riesgo intrínseco, es decir, el riesgo que presenta un
activo por el mero hecho de existir.
Obtenidos los valores de riesgo de todos los activos conseguiremos una imagen de
dónde radican los mayores riesgos en nuestra organización y, por lo tanto, en qué
puntos hay que incrementar el esfuerzo, dónde tendremos que aplicar medidas o
mejorar las existentes.
3.2. Política de seguridad

El único objetivo de este capítulo es que la organización cuente con una política
que refleje sus expectativas en materia de seguridad, a fin de gestionarla con
coherencia y soporte.
Este capítulo consta de dos controles:
• Documento de política de seguridad. El documento de política de seguridad
de la información debería establecer el compromiso de la dirección y el
enfoque de la organización para gestionar la seguridad de la información.
Este documento debería ser aprobado por la dirección y publicado y comu-
nicado a todos los empleados y terceras partes.
• Revisión de la política de seguridad. La política de seguridad debe ser un
documento vivo, que se revise y actualice periódicamente para que siga
siendo adecuado tras los inevitables cambios que sufre toda organización.
Al implementar un SGSI según la UNE-ISO/IEC 27001, es obligatorio desarrollar

una política de seguridad y mantenerla actualizada, por lo que la mera imple-
mentación del sistema ya cumple con estos dos controles.
3.3. Organización de la seguridad

Este capítulo tiene dos objetivos:
• Organización interna, para gestionar la seguridad de la información dentro
de la organización. Los controles de este objetivo son:
– Compromiso de la dirección con la seguridad de la información. La direc-

ción debe respaldar la seguridad de la información y tomar decisiones al
respecto, tales como poner objetivos y aprobar el riesgo aceptable, pro-
porcionando recursos y avalando acciones.
– Coordinación de la seguridad de la información. Es fundamental que las
actividades relativas a la seguridad de la información estén coordinadas
para que no haya redundancia o lagunas y produzcan situaciones inde-
seadas.
– Asignación de responsabilidades relativas a la seguridad de la información.
Hay que definir claramente quién se va a encargar de cada actividad de
seguridad de la información, evitando malentendidos y errores.
– Proceso de autorización de recursos para el tratamiento de la información.
La gestión de la seguridad debe comenzar en el mismo proceso de com-
pra de cada nuevo recurso de tratamiento de la información.
– Acuerdos de confidencialidad. Para proteger adecuadamente la informa-
ción sensible de la organización, deben establecerse y revisarse de una
manera regular cuándo y quién debe firmar este tipo de acuerdo.
– Contacto con las autoridades. Sería recomendable mantener los contactos
adecuados con las autoridades correspondientes, en particular en lo refe-
rente a planes de continuidad del negocio que pueden requerir de contac-
tos en los cuerpos y fuerzas de seguridad del Estado.
– Contacto con grupos de interés especial. Dada la complejidad de la seguri-
dad y los numerosos cambios tecnológicos que influyen en cómo hay que
enfocarla y tratarla, es fundamental mantenerse al día y conservar el con-
tacto con grupos de interés especial, foros y asociaciones profesionales
especialistas en seguridad.
– Revisión independiente de la seguridad de la información. Siempre es útil
contar con la opinión de terceros, sobre todo si son especialistas en el
tema, para que valoren si el enfoque de la organización para la gestión de
la seguridad de la información es adecuado y en qué se puede mejorar. La
ausencia de presiones internas y la comparación con otras organizaciones
o modelos de gestión permite que surja un aporte de cosas nuevas que
difícilmente hubieran aflorado internamente.
• Terceros. El objetivo aquí es que las medidas de seguridad abarquen tam-

bién a cualquier tercero que sea susceptible de acceder, procesar, comu-
nicar o gestionar la información de la organización. Los controles para
ello son:
– Identificación de riesgos derivados del acceso de terceros. Lógicamente, el

primer control será saber cuáles son los riesgos que supone el acceso de
terceros a nuestros sistemas e información, para poder implementar los
controles adecuados antes de permitir dicho acceso.
– Tratamiento de la seguridad en la relación con los clientes. Si a los clientes
se les permite acceder a la información, hay que considerar qué requisitos
deben cumplir y los sistemas para garantizar la seguridad.
– Tratamiento de la seguridad en contratos con terceros. Es crítico que se
hagan acuerdos formales con aquellos terceros que posean acceso a recur-
sos de tratamiento de información de la organización. Estos acuerdos
deben basarse en un contrato formal que contemple todos los requisitos
de seguridad necesarios y que obligue a que se cumplan las políticas y
normas de seguridad de la organización. El contrato debe asegurar que no
hay malentendidos entre la organización y los terceros. De esta manera la
organización puede mantener el mismo control tanto sobre sus usuarios
internos como sobre los externos.
3.4. Gestión de activos

Los activos de información son los elementos que tratamos de proteger con el
SGSI. Los controles de este capítulo están dirigidos a lograrlo.
• Responsabilidad sobre los activos. Para conseguir y mantener una protección
adecuada sobre los activos de la organización deben existir responsabilidades
claras. Hay tres controles para este objetivo:
– Inventario de activos. Para poder gestionarlos, es fundamental identificar
dichos activos, preparando con esa información un inventario de todos los
activos importantes, que habrá de ser mantenido y actualizado. Se nece-
sita un inventario de los recursos de información de la organización para,
basándose en este conocimiento, asegurar que se brinda un nivel adecuado
de protección.
– Propiedad de los activos. Cada uno de los activos contará con un propie-
tario, una parte designada de la organización, y será responsable de su
seguridad.
– Uso aceptable de los activos. Las reglas básicas para el empleo aceptable
de la información y de los activos asociados con los recursos para el
tratamiento de la información deben ser documentadas y publicadas, para
que se apliquen en toda la organización.
• Clasificación de la información, para asegurar que la información recibe un

nivel adecuado de protección en función de su criticidad. Existen dos con-
troles:
– Directrices de clasificación. Debe clasificarse la información de acuerdo a
su sensibilidad y criticidad, su valor para la organización y el daño que
ocasionaría su fuga o filtración, para así poder adoptar las medidas de
seguridad adecuadas a cada nivel de protección.
– Etiquetado y manipulado de la información. La información debe ser
marcada y tratada de acuerdo con el esquema de clasificación adoptado
por la organización. El etiquetado de la información puede realizarse de
diferentes formas, pero debería hacerse de modo que se distinga fácil-
mente el tipo de información que contiene el documento.
3.5. Seguridad ligada a los recursos humanos

Este capítulo establece la necesidad de educar e informar a los empleados
actuales y potenciales sobre lo que se espera de ellos en materia de seguridad y
asuntos de confidencialidad. También determina cómo incide el papel que los
empleados desempeñan en materia de seguridad en el funcionamiento general
de la compañía.
Ante la contratación de personal deben tomarse medidas de seguridad previas a la
contratación, durante el período que dure el contrato y al concluir. Este capítulo
marca tres objetivos:
• Antes del empleo, para asegurar que cualquier persona que entre a formar
parte de la organización (empleados, contratistas, etc.) conoce y entiende sus
responsabilidades en materia de seguridad y puede llevar a cabo las tareas
que se le encomienden, colaborando activamente en reducir los riesgos de
robo, fraude o utilización indebida de los recursos. Los controles son tres:
– Funciones y responsabilidades. Para poder exigirlas, las funciones y
responsabilidades de seguridad de los empleados contratistas y terceros se
deben definir y documentar.
– Investigación de antecedentes. Para según qué puestos puede ser especial-
mente relevante comprobar los antecedentes de todos los candidatos a
ejercer el trabajo. Esta comprobación deberá efectuarse de acuerdo a la
legislación vigente y de una manera proporcionada a los requisitos del
negocio y de seguridad de la organización.
– Términos y condiciones de contratación. Los contratos deberán reflejar,

junto con los términos del acuerdo, las obligaciones y responsabilidades
de las dos partes en lo relativo a seguridad de la información.
• Durante el empleo, para que en el trabajo cotidiano todo el mundo se

encuentre concienciado en materia de seguridad y ponga en práctica la
política de seguridad de la organización, reduciendo el riesgo de error
humano. Este objetivo cuenta con tres controles:
– Responsabilidades de la dirección, que es la que debe establecer las direc-
trices a seguir y exigir su cumplimiento, tanto a los empleados como a
contratistas y terceros.
– Concienciación, formación y capacitación en seguridad de la información.
Hay que poner en conocimiento de los implicados las políticas y proced-
imientos de la organización, y proporcionar la formación adecuada para
que las puedan ejecutar.
– Proceso disciplinario. Debe existir algún mecanismo de penalización para
las infracciones de seguridad que sirva como método de disuasión.
• Cese del empleo o cambio de puesto de trabajo, para lograr que cuando
alguien deja de trabajar con la organización o cambia la relación con ella,
dichos cambios discurran adecuadamente y no generan vulnerabilidades. Los
controles son:
– Responsabilidad del cese o cambio. Las responsabilidades deben estar
establecidas y ser conocidas en caso de cese o cambio de puesto de algún
empleado, para efectuarlo correctamente.
– Devolución de activos. Si cesa el empleo o contrato, los activos que se han
entregado para poder realizarlo deben ser devueltos.
– Retirada de los derechos de acceso. Cuando concluye el empleo, el con-
trato o el acuerdo con un empleado o contratista, deben retirarse todos los
derechos de acceso a la información y a los recursos de tratamiento de la
información o bien deben ser adaptados a los cambios producidos.
3.6. Seguridad física y del entorno

Este capítulo responde a la necesidad de proteger físicamente las áreas en las que
se encuentran los equipos y la información. Los mecanismos de protección para el
sistema de información de la organización pasan por definir un perímetro físico de

seguridad que impida el acceso no autorizado a la información y eviten daños por
eventos, tales como fuego, inundación, terremoto, explosión, malestar social y
otras formas de desastres naturales o provocados por el hombre.
Existen dos objetivos:
• Áreas seguras. Deben establecerse unas medidas de seguridad para prevenir
los accesos físicos no autorizados, los daños y las intromisiones en las instala-
ciones y en la información de la organización. Podemos utilizar los siguientes
controles:
– Perímetro de seguridad física. Barreras, muros, puertas de entrada con restric-
ciones (recepción, cerraduras, control a través de tarjeta, etc.), cualquier
medio que sirva para proteger las zonas en las que se encuentra la informa-
ción y los sistemas de información formarán parte de este primer control.
– Controles físicos de entrada. Las áreas en las que sólo el personal autori-
zado puede entrar deben poseer controles de entrada apropiados que res-
trinjan el acceso.
– Seguridad de oficinas, despachos e instalaciones. También estos recintos
deben contar con medidas razonables que permitan mantener la informa-
ción y los sistemas bajo control.
– Protección contra las amenazas externas y de origen ambiental. Tanto por
la magnitud de los daños que pueden ocasionar estas amenazas, como
por la legislación que controla este punto, se deben aplicar las medidas
apropiadas contra el daño causado por fuego, inundación, terremoto y
otros desastres, tanto naturales como provocados por el hombre.
– Trabajo en áreas seguras. Por su especial sensibilidad, las áreas seguras
contarán, además de con medidas de protección física, con directrices para
trabajar en ellas.
– Áreas de acceso público y de carga y descarga. Puesto que estos puntos
son vulnerables a accesos no autorizados, deberán controlarse con cuidado
y, en la medida de lo posible, mantenerlos alejados y aislados de aquellas
zonas en las que residan los sistemas de información.
• Seguridad de los equipos, para que las actividades de la organización no se

interrumpan debido a daños en los equipos, robo de activos o pérdidas de
los mismos. Los controles definidos para este objetivo son:
– Emplazamiento y protección de equipos. Los equipos deben situarse en
lugares seguros, protegidos de riesgos ambientales (agua, luz, viento, etc.)
que puedan dañarlos. Asimismo, se ubicarán allí donde su acceso resulte

complicado para personas no autorizadas.
– Instalaciones de suministro. Los equipos pueden dañarse si se producen
fallos en el suministro eléctrico o en las comunicaciones, por lo que es
recomendable que tengan alguna protección para evitar problemas si suce-
den estos fallos, especialmente si se trata de equipos muy críticos.
– Seguridad del cableado. Puesto que el cableado hace posible que los
equipos funcionen, se instalará de manera que se eviten daños, que impi-
dan interceptaciones o que dificulten una fuga de información.
– Mantenimiento de los equipos. Otro punto crucial para que los equipos
funcionen correctamente es que se sometan a un mantenimiento, preven-
tivo y correctivo, que asegure su disponibilidad y su integridad.
– Seguridad de los equipos fuera de las instalaciones. Cuando los equipos
están fuera de las instalaciones de la organización, el nivel de seguridad
debe ser el mismo, aunque las circunstancias no lo sean, por lo que
deben diseñarse y aplicarse las medidas de seguridad adecuadas a estos
equipos.
– Reutilización o retirada segura de equipos. Los equipos almacenan infor-
mación que debe ser eliminada (sobre todo si es sensible) cuando son reti-
rados o se van a reutilizar. Para evitar problemas, esta eliminación se com-
probará antes de retirarlos o ponerlos en uso de nuevo.
– Retirada de materiales propiedad de la empresa. Hay que autorizar y regis-
trar las salidas de equipos para poder controlar la información o software
en todo momento, de manera que se sepa quién es el responsable de los
activos y dónde se encuentran.
3.7. Gestión de comunicaciones y operaciones

Este es el capítulo con más objetivos y controles, y el más técnico de toda la
norma. Aquí se recogen los controles técnicos, puesto que se trata de proteger el
funcionamiento y las operaciones de los sistemas de información. Hay que tener
en cuenta que el origen de esta norma se encuentra en grandes empresas y corpo-
raciones con sistemas de información muy sofisticados y amplios. En el contexto
de una pyme, es aquí donde se hace más relevante realizar el esfuerzo de escalar
hacia abajo los requisitos planteados por la norma. Muchos de los controles de
este capítulo no serán aplicables en el contexto de una pyme típica, a menos que
su negocio posea implicaciones que los hagan necesarios, y desde luego la imple-
mentación de los que sí son aplicables tiene que ser lo más sencilla que seamos
capaces de diseñar. Un banco tendrá que tener un procedimiento de copias de
seguridad muy estricto y laborioso y muchos recursos dedicados a esa tarea, tanto
para realizarla como para almacenar las copias. En una pyme puede ser suficiente
una copia semanal, almacenada en un pequeño dispositivo USB que se pueda
transportar cómodamente fuera de las instalaciones a un lugar seguro.
Este capítulo contiene diez objetivos:
• Responsabilidades y procedimientos de operación. Para encargarse eficaz-
mente de que los sistemas de información funcionen de manera correcta y
segura, será necesario establecer las responsabilidades y procedimientos para
la gestión de todos los recursos de información, reduciendo los riesgos de
negligencia o uso indebido. Los controles son:
– Documentación de los procedimientos de operación. Siempre hay una
forma más o menos establecida de afrontar las tareas, este control trata de
documentar esos modos de trabajo, estableciendo las responsabilidades y
cubriendo todas las tareas fundamentales, por ejemplo, el procedimiento
para las copias de seguridad, para la configuración de accesos, etc.
– Gestión de cambios. Los sistemas de información y las aplicaciones deben
estar bajo control de cambios, ya que éstos son una fuente importante de
errores y fallos. Esta gestión del cambio tiene que incluir la identificación
de los cambios, su aprobación, la planificación de cómo y cuándo van a
ser incorporados, las pruebas que se efectuarán, siempre fuera del entorno
de producción, y cuál será el procedimiento para deshacerlos si sucede
algún evento imprevisto.
– Segregación de tareas. Hay que separar las diversas áreas de responsabili-
dad para evitar usos o accesos indebidos, accidentales o intencionados, de
la información. Esta segregación puede resultar difícil de emprender en
organizaciones pequeñas, pero el principio debería aplicarse en la medida
en que sea posible y práctico.
– Separación de los recursos de desarrollo, prueba y operación. Siguiendo
el mismo principio anterior, es necesario separar el entorno donde se rea-
licen desarrollos del entorno de prueba, y por supuesto los entornos de
producción deben permanecer aislados del resto, así se eliminan riesgos
de accesos no autorizados o cambios no deseados. Deberían establecerse
las normas para trasladar software y datos de unos entornos a otros, por
ejemplo, en qué condiciones se pueden usar datos reales para realizar
pruebas.
• Gestión de la provisión de servicios por terceros. Estos servicios deben tener el

mismo nivel de seguridad que los internos, por lo que se establecerán acuerdos
en los que se recogerán estos requisitos, comprobándose el cumplimiento de
los acuerdos y gestionando los cambios necesarios para asegurar que los servi-
cios entregados son conformes con lo estipulado. Los controles son tres:
– Provisión de servicios. Se establecerán acuerdos de nivel de servicio con
todos los requisitos necesarios para que se cumplan las expectativas, tanto
funcionales como de seguridad, para la provisión del servicio. Estos acuer-
dos establecerán las normas para el intercambio de información y las
responsabilidades de los contratistas respecto a los activos de información
a los que tengan acceso.
– Supervisión y revisión de los servicios prestados por terceros. Ha de man-
tenerse un control para garantizar que los servicios se suministran según
los acuerdos establecidos, incluso realizando auditorías cuando sea perti-
nente. Para ello se revisarán los informes entregados y los registros gene-
rados por la actividad, y se comprobará que los incidentes y problemas de
seguridad de la información se gestionan y resuelven adecuadamente.
– Gestión del cambio en los servicios prestados por terceros. En la línea de
mantener el mismo nivel de seguridad en los servicios suministrados por
terceros que en los internos, también los cambios deben ser gestionados
en dichos servicios. Durante su provisión pueden darse cambios para
mejorar los servicios, nuevos desarrollos, modificaciones de las políticas y
procedimientos de la organización, cambios tecnológicos, etc. Ha de exis-
tir un procedimiento claro para incorporar estos cambios a los servicios
de una forma eficaz.
• Planificación y aceptación del sistema, de modo que se eviten fallos de los

sistemas por sobrecargas y fallos de disponibilidad. Existen dos controles:
– Gestión de capacidades. Para ello se controlará el uso de recursos para que
se puedan hacer previsiones de futuro, planificando con tiempo suficiente
la capacidad que va a ser necesaria para evitar agotarla.
– Aceptación del sistema. Se deberían establecer, documentar, y probar pre-
viamente a su aceptación y uso los requisitos operacionales de los sistemas
nuevos, así se evitarían fallos, incluso aunque se trate de una simple actua-
lización.
• Protección contra código malicioso y descargable. Evitar virus, troyanos y el

resto de los tipos de código malicioso sirve para proteger la integridad del
software y de la información.
– Controles contra el código malicioso. La protección contra este riesgo

tiene dos vertientes, la técnica y la humana. Deben instalarse sistemas de
detección, prevención y recuperación que protejan contra código mali-
cioso. Además se deben realizar procedimientos adecuados de concien-
ciación para que todos los usuarios sean conscientes de los problemas que
genera el código malicioso y cómo proceder cuando se reciban correos
engañosos.
– Controles contra el código descargado en el cliente. Si se autoriza el uso
de código descargado en el cliente (JavaScript, VBScript, applets de Java
applets, controles ActiveX, etc.), la configuración debe garantizar que
dicho código autorizado funciona de acuerdo con una política de seguri-
dad claramente definida. Cualquier uso y recepción de código ambu-
lante no autorizado ha de bloquearse. Los ataques del código móvil
pueden modificar la información, robar las contraseñas o archivos, redi-
reccionar los accesos telefónicos por módem o lanzar un ataque de dene-
gación de servicio, por lo que hay que ser especialmente precavidos en
este punto.
• Copias de seguridad. Realizar copias de la información ayuda a mantener la

integridad y disponibilidad de la misma y de los recursos de tratamiento de
la información, ya que en caso de incidente se podría recuperar rápidamente.
Este objetivo sólo tiene un control:
– Copias de seguridad de la información. Deberían establecerse procedi-
mientos para efectuar las copias de seguridad de acuerdo con la frecuencia
y amplitud que recomienden la sensibilidad y criticidad de la información
gestionada. Además, las copias han de comprobarse regularmente para
verificar que la información es y permanece correcta y completa, y ensayar
los tiempos de recuperación. Se ha convertido en un requisito básico contar
con una copia de seguridad fuera de las instalaciones de la organización,
lo cual garantiza la disponibilidad de la información incluso en caso de
desastre.
• Gestión de la seguridad de las redes. Por pequeña que sea la organización, lo

más corriente es que cuente con una red por la que circulan las comunica-
ciones digitales y la información. Este objetivo trata de asegurar esta
infraestructura para evitar incidentes.
– Controles de red. Para proteger la red, en primer lugar, debe estar gestion-
ada y controlada, con responsabilidades claras y diferenciadas de las
responsabilidades operativas, si es posible. Las medidas de seguridad para
proteger la confidencialidad, la integridad de los datos que pasan a través
de ellas y los dispositivos que protegen las aplicaciones y los sistemas

conectados son críticas aquí, así como mantener logs con información que
pueda ayudar a detectar fallos, errores o ataques.
– Seguridad de los servicios de red. Dado el gran número de utilidades que
soportan las redes, se deben identificar los requisitos funcionales y de
seguridad y los niveles de servicio que deben incluirse en todo acuerdo
de servicios de red, tanto si estos servicios son internos como si se subcon-
tratan. Esto incluirá las necesidades de autenticación de usuarios, de ci-
frado de datos, de control de conexiones, requisitos de acceso para usuarios
remotos, etc.
• Manipulación de los soportes. La información puede estar en varios for-

matos y soportes, por lo que protegerlos es básico para evitar que se revele
o destruya información o se interrumpan las actividades de la organi-
zación.
– Gestión de soportes extraíbles. La proliferación de este tipo de soportes
(discos ópticos, lápices USB, discos duros externos…) hace necesario
establecer normas para su utilización.
– Retirada de soportes. Cuando ya no se vayan a utilizar, hay que retirarlos
de acuerdo con las normas que se establezcan, las cuales eviten que la
información que contengan pueda llegar a personas no autorizadas.
– Procedimientos de manipulación de la información. Se deberían estable-
cer procedimientos para tratar y almacenar la información. El objetivo
es impedir que dicha información sea revelada sin autorización o que se
la dé un mal uso, por ejemplo, se recomienda que se etiqueten los soportes
según la clasificación de la información que porten, considerando los
siguientes aspectos: las restricciones de acceso, el mantenimiento de un
registro de los destinatarios autorizados, el almacenamiento de los
soportes de acuerdo con las especificaciones del fabricante, etc.
– Seguridad de la documentación del sistema. Es importante mantener
segura esta información, ya que contiene datos valiosos para la organi-
zación, por ejemplo, las descripciones de las aplicaciones de los procesos,
las estructuras de datos y los procesos de autorización.
• Intercambio de información. Un SGSI debe proteger la información a lo

largo de todo su ciclo de vida, en muchos momentos de este ciclo la infor-
mación saldrá de la organización por unos motivos u otros, por lo que deben
establecerse los mecanismos adecuados para que permanezca segura cuando
se intercambie con terceros. Los controles para conseguirlo son:
– Políticas y procedimientos de intercambio de información. Se deberían

establecer procedimientos y normas para proteger la información y los
soportes físicos que contienen información en tránsito.
– Acuerdos de intercambio. El intercambio de información debe realizarse
en el marco de un acuerdo que recoja las responsabilidades de cada parte,
las exigencias en el caso de incidentes de seguridad de la información,
cómo va a ser etiquetada la información sensible o crítica, las normas téc-
nicas para el registro y lectura de la información y del software, etc.
– Soportes físicos en tránsito. Para que la información esté segura cuando se
encuentre en tránsito deben protegerse los soportes, utilizando mensajeros
y transportistas de confianza, embalando bien los soportes, etc.
– Mensajería electrónica. Se establecerán normas de seguridad para el uso
del correo electrónico, las cuales recogerán las medidas de seguridad míni-
mas para garantizar un empleo responsable y seguro del servicio, en par-
ticular cuando se utilice para el envío de información confidencial.
– Sistemas de información empresariales. Se deberían desarrollar y aplicar
políticas y procedimientos para proteger la información que se va a com-
partir con otros sistemas de información pertenecientes a otras organiza-
ciones, definiendo qué información puede ser compartida, por quién, las
responsabilidades de cada parte, etc.
• Servicios de comercio electrónico. El éxito de estos servicios se basa en la

confianza de los usuarios en la seguridad de los mismos. Para garantizar esta
seguridad de los servicios de comercio electrónico, se pueden utilizar los
siguientes controles:
– Comercio electrónico. Es vital que toda la información incluida en el com-
ercio electrónico se proteja contra actividades fraudulentas, disputas con-
tractuales y revelación o modificación no autorizada de dicha información.
– Transacciones en línea. Estas transacciones son muy vulnerables a errores
o fallos de transmisión o de direccionamiento, alteraciones no autorizadas
de los mensajes, así como revelación, duplicación o reproducción no
autorizadas del mensaje, por lo que han de ser correctamente protegidas.
– Información puesta a disposición pública. La integridad de la información
destinada a hacerse pública debe protegerse para impedir modificaciones
no autorizadas que dañen la reputación de la organización.
• Supervisión. La única manera de detectar a tiempo las actividades de proce-

samiento de la información no autorizadas es llevando a cabo una supervisión
que las ponga en evidencia. El nivel de monitorización está basado en el

nivel de riesgo del negocio, cuanto más riesgo mayor debería ser el nivel
de vigilancia. Los controles son:
– Registro de auditorías. Se deben mantener registros de las operaciones de
privilegio, las conexiones y desconexiones (log in / log out), los intentos
de acceso no autorizado, violaciones de la política de acceso, las alertas por
fallos, etc. Estos registros deben ser almacenados durante un período
acordado para servir como prueba en investigaciones futuras y en la super-
visión del control de acceso.
– Supervisión del uso del sistema, para verificar que los recursos del sistema
se utilizan debidamente.
– Protección de la información de los registros. Debido a la sensibilidad de
los dispositivos de registro y la información generada por ellos, deben ser
protegidos contra manipulaciones indebidas y accesos no autorizados.
– Registros de administración y operación. Los registros del administrador
del sistema y del operador del sistema deberían ser revisados regular-
mente, de manera que se compruebe que se cumplen las actividades del
sistema y de la administración de la red.
– Registro de fallos. Registrar los fallos, tanto de los usuarios como de las
aplicaciones, es el primer paso hacia una correcta gestión de los mismos
hasta su resolución. Deberían existir reglas precisas para el tratamiento de
los informes de fallos, incluyendo la revisión de los registros y el cumpli-
miento de las medidas correctivas tomadas.
– Sincronización del reloj. En caso de incidencias, teniendo todos los
equipos sincronizados, se podrá comprobar qué equipos estaban conecta-
dos en el sistema de información, y al observar los registros de dichos
equipos, se podrá llegar a una conclusión sobre lo sucedido.
3.8. Control de acceso

Este capítulo trata de las medidas a tomar cuando se desee monitorizar y controlar
el acceso a la red y los recursos de información, y de la protección existente contra
los abusos internos y los intrusos externos, dada la importancia que tienen para
la organización sus activos. Por lo tanto, el objetivo de este grupo de controles es
regular el acceso a la información, de acuerdo con los requisitos de negocio y los de
seguridad, que se puede obtener aplicando alguno de los siete objetivos de control
definidos:
• Requisitos de negocio para el control de acceso, de manera que sólo accedan

a la información quienes estén autorizados para ello. Tiene un control:
– Política de control de acceso. En primer lugar hay que definir y documen-
tar cuáles van a ser las líneas de actuación en la organización en este
aspecto. Hay que valorar qué clases de informaciones son tratadas y si se
puede permitir acceso a todo el mundo a toda o a la gran mayoría de la
información y restringir sólo una parte, o bien darle a cada uno acceso
sólo a aquella información que necesita.
• Gestión de acceso de usuario, de manera que sólo los usuarios autorizados

pueden acceder a la información y los sistemas, mientras que aquellos que
no lo estén no puedan hacerlo. Se utilizarán los siguientes controles:
– Registro de usuarios. El primer paso es establecer un registro de usuarios,
donde se anoten las altas y bajas de los mismos, junto con los permisos de
acceso que se les conceden o revoquen, todo ello de acuerdo con un pro-
cedimiento formal que evite errores en la asignación de permisos, en la
medida de lo posible.
– Gestión de privilegios. Los privilegios otorgados a los usuarios deben
estar debidamente autorizados, según su necesidad de uso, manteniendo
un registro para controlar su utilización.
– Gestión de contraseñas de usuario. Es uno de los controles más difundidos
y más eficaces para el control de accesos, siempre que esté bien implemen-
tado y gestionado. Para conservar la eficacia de las contraseñas es funda-
mental que permanezcan confidenciales, por lo que se debe concienciar
al personal sobre este punto. Las contraseñas deben tener mayor comple-
jidad (más caracteres, mezclar números, letras y símbolos) según la critici-
dad de las aplicaciones o la información a la que se acceda, y deben ser
cambiadas frecuentemente, como mínimo una vez al año.
– Revisión de los derechos de acceso de usuario. Debido a los cambios que
sufren las organizaciones, los accesos que se concedieron en su momento
pueden perder validez, por lo que hay que revisarlos regularmente para
actualizarlos.
• Responsabilidades de usuario. Ya se ha comentado la importancia de que el

personal colabore activamente en mantener la seguridad. Todas las medidas
técnicas implementadas no podrán evitar que se cometan errores, como
apuntar contraseñas en un papel o dejar informes confidenciales en la impre-
sora. Para evitar este tipo de fallos de seguridad, hay que formar, concienciar
y, si es necesario, comprometer al personal. Por ello, en este objetivo se tratan
los controles orientados a prevenir el acceso de usuarios no autorizados, y

evitar robos de información o equipos causados por las malas prácticas de
los usuarios.
– Uso de contraseña. Los usuarios deben seguir buenas prácticas de segu-
ridad en la selección y el uso de las contraseñas: mantener su confidenciali-
dad, no compartirlas, no emplear la misma contraseña para propósitos pro-
fesionales que para no profesionales, no guardarla en papel o en un fichero
de software fácil de acceder, etc.
– Equipo de usuario desatendido. Los usuarios, a lo largo de la jornada,
suelen ausentarse de su puesto de trabajo por diferentes motivos, dejando
desatendido el equipo y la información que están utilizando. Para evitar
incidentes no deseados, las pantallas y los equipos deberán bloquearse
pasado un período de inactividad, por ejemplo, con un protector de pan-
talla con contraseña.
– Política de puesto de trabajo despejado y pantalla limpia. Tanto las mesas
de trabajo como los equipos informáticos del puesto son dos elementos
del sistema de información susceptibles de fugas de información, por lo
que deben establecerse normas y mecanismos para que el personal man-
tenga tanto la mesa como la pantalla sin información visible, papeles o
medios de almacenamiento extraíbles, que puedan comprometer la confi-
dencialidad de los datos.
• Control de acceso a la red. Los sistemas de información actuales cuentan con

redes que son vulnerables a accesos no autorizados, por lo que deben ser
protegidas. Los controles para ello son:
– Política de uso de los servicios en red. Hay que establecer cómo se va a
utilizar la red y sus servicios, y definir cómo se van a asignar los accesos.
Esta política deberá ser coherente con la política de accesos de la organi-
zación.
– Autenticación de usuario para conexiones externas. Si los usuarios van a
conectarse en remoto a la red, hay mayores riesgos que en una conexión
interna, por lo que la autenticación debe ser más rigurosa, sobre todo si se
utilizan redes inalámbricas. Los métodos de autenticación se escogerán
tanto más seguros según la valoración del riesgo que se haya hecho de la
información y las aplicaciones a acceder y los medios de acceso que se van
a utilizar para ello. Si se emplean redes privadas virtuales (VPN) puede ser
suficiente el sistema de usuario y contraseña, si se va a trabajar con redes
públicas puede ser necesario utilizar, por ejemplo, técnicas criptográficas o
dispositivos biométricos.
– Identificación de los equipos en las redes. De esta manera se pueden aut-

enticar las conexiones provenientes de localizaciones y equipos específi-
cos. Los identificadores de los equipos indicarán claramente a qué red se
permite al equipo la conexión, si existe más de una red y, en particular, si
estas redes tienen distinto grado de sensibilidad. Se puede aplicar la iden-
tificación del equipo adicionalmente a la identificación de usuario,
reforzándola.
– Diagnóstico remoto y protección de los puertos de configuración. Cuando
sea necesario mantener un puerto abierto para estas tareas, se debe contro-
lar tanto el acceso físico como el lógico permitido para este puerto.
– Segregación de las redes. Cuando sea oportuno y práctico, se separarán en
redes distintas los servicios de información, los de usuarios y los sistemas,
evitando así filtraciones o modificaciones de la información.
– Control de la conexión a la red. Cuando se comparta la red, sobre todo si
se hace con otras organizaciones, los accesos deben estar perfectamente
definidos y restringidos. No todos los usuarios poseen las mismas nece-
sidades de acceso, así que, para evitar problemas, lo más recomendable
es que cada uno tenga los derechos de acceso a la red que estrictamente
necesite para realizar su trabajo.
– Control de encaminamiento (routing) de red. Los controles de encami-
namiento (routing) de redes se implementan para evitar que la información
llegue a un destino distinto del requerido, de manera que las conexiones de
los ordenadores y los flujos de información estén de acuerdo con la política
de control de acceso de la organización.
• Control de acceso al sistema operativo, para prevenir accesos indebidos a los

sistemas operativos que provoquen daños en las aplicaciones e inestabili-
dades de los sistemas. Los controles a utilizar para alcanzar este objetivo son:
– Procedimientos seguros de inicio de sesión. Las sesiones deben ser inicia-
das con un procedimiento que no facilite a un usuario no autorizado
la entrada ni revele información del sistema y que limite los intentos de
entrada para bloquearlos.
– Identificación y autenticación de usuario. Cada usuario deberá tener un
identificador único (ID de usuario) para su uso personal y exclusivo, así
se logrará que su autenticación sea fiable, de manera que se puedan seguir
sus actividades y, si es necesario, exigir responsabilidades.
– Sistema de gestión de contraseñas. Gestionar las contraseñas necesita de la
colaboración del personal y servirán a su propósito en función de la calidad
y robustez de las mismas. Donde sea posible, se permitirá a los usuarios

escoger sus propias contraseñas, aunque se establezcan criterios para dise-
ñarlas.
– Uso de los recursos del sistema. Hay programas y utilidades del sistema
que pueden ser capaces de invalidar los controles del mismo y de la apli-
cación, por lo que su uso debería estar restringido a los usuarios que real-
mente lo necesiten y encontrarse estrictamente controlado.
– Desconexión automática de sesión. Las sesiones abiertas son oportu-
nidades para realizar accesos no autorizados, por lo que debe establecerse
un tiempo tras el cual, si no ha habido actividad, la sesión caducará.
– Limitación del tiempo de conexión. Limitar la franja horaria en la que se
pueden realizar las conexiones es un mecanismo que refuerza el control de
accesos, ya que reduce el marco de oportunidades de acceso no autorizado.
• Control de acceso a las aplicaciones y a la información. Las aplicaciones y

la información que contienen son elementos muy sensibles de los sistemas
de información, que deben ser protegidos contra accesos no autorizados
para evitar fallos de confidencialidad o de integridad. Existen dos controles para
este objetivo:
– Restricción del acceso a la información. Debe seguirse la política de acce-
sos de la organización, de manera que el acceso se conceda a los usuarios
autorizados para ello. Además, deben protegerse contra accesos permitidos
por software malicioso o software del sistema operativo que permita obviar
los controles establecidos.
– Aislamiento de sistemas sensibles. Cuando las aplicaciones y su informa-
ción son particularmente críticos, deberían estar alojados en entornos pro-
tegidos con equipos dedicados, aislados del resto de los sistemas.
• Ordenadores portátiles y teletrabajo. Este tipo de equipos y modo de trabajo

se va extendiendo cada vez más, con la mejora del hardware, el software y las
comunicaciones, pero son muy vulnerables, por lo que hay que ser especial-
mente escrupuloso para garantizar su seguridad.
– Ordenadores portátiles y comunicaciones móviles. Cuando se emplean
este tipo de dispositivos, los riesgos son distintos que cuando se usan los
equipos de sobremesa, por lo que deben establecerse normas de uti-
lización específicas encaminadas a protegerlos adecuadamente, tales como
la protección física, los controles de acceso, las técnicas criptográficas, las
copias de respaldo y la protección antivirus.
– Teletrabajo. Para que el trabajo realizado en remoto se haga con el mismo

nivel de seguridad que si se realizara dentro de las instalaciones de la orga-
nización, deben existir unas normas que consideren aspectos como la
seguridad física en el lugar de teletrabajo y las comunicaciones. Es impres-
cindible contar con una definición del trabajo permitido, las horas de tra-
bajo, la clasificación de la información que puede mantenerse en el equipo,
y los sistemas y servicios a los que el teletrabajador está autorizado a
acceder, que garanticen unos mínimos de seguridad.
3.9. Adquisición, desarrollo y mantenimiento de

los sistemas
En toda labor de la tecnología de la información se debe implementar y mantener
la seguridad mediante el uso de controles de seguridad que abarquen todas las etapas
del ciclo de vida de los activos de información. El objetivo específico de este grupo
de controles es garantizar que la seguridad sea una parte integral de los sistemas de
información, desde su concepción hasta su retirada.
• Requisitos de seguridad de los sistemas de información. Si queremos garan-
tizar una seguridad integrada en los sistemas de información es fundamental
que los requisitos de seguridad sean explícitos y estén documentados. El con-
trol es claro:
– Análisis y especificación de los requisitos de seguridad. Tanto si se van
a comprar paquetes de software o equipos, como si se está pensando en
subcontratar un nuevo desarrollo, el primer paso es definir los requisitos
que debe cumplir el elemento que se va a adquirir. Si queremos que ese
elemento sea seguro y su incorporación a los sistemas de información no
cree problemas, los requisitos de seguridad deberán ser incorporados a las
especificaciones junto con el resto de los requisitos funcionales y técnicos.
• Tratamiento correcto de las aplicaciones. Las aplicaciones deben procesar

correctamente la información introducida en ellas para evitar errores, pérdidas,
modificaciones no autorizadas o usos indebidos de dicha información. Para
alcanzar este objetivo los controles a aplicar son:
– Validación de los datos de entrada. El primer paso será comprobar que los
datos de entrada en las aplicaciones son válidos, es decir, la aplicación
deberá ser capaz de detectar si los datos introducidos son correctos, en la
medida de lo posible: que se encuentran dentro de un rango, que el for-
mato es aceptable, que son coherentes, etc.
– Control del procesamiento interno. La validación de los datos debe conti-

nuar durante su procesamiento. La aplicación ha de contar con mecanismos
que detecten información corrupta, si los resultados no encajan con lo espe-
rado o si la información no ha seguido el ciclo esperado de trata-miento.
– Integridad de los mensajes. Los mensajes del sistema son herramientas
importantes para detectar y corregir errores, por lo que es fundamental
proteger su autenticidad e integridad.
– Validación de los datos de salida. Terminado el tratamiento de la informa-
ción, se deben validar los datos obtenidos comprobando que son cohe-
rentes con lo esperado, verosímiles y razonables, ya que a pesar de que se
han podido tomar todas las precauciones posibles en anteriores etapas del
procesamiento de la información, se pueden producir errores en la salida
que invaliden los datos.
• Controles criptográficos. Cuando la sensibilidad de los datos o su criticidad

hacen recomendable utilizar técnicas criptográficas para protegerlos, los con-
troles a aplicar son:
– Política de uso de los controles criptográficos. Estas medidas tan espe-
ciales son costosas, por lo que debe haber una política para aplicarlas de
manera coherente con las necesidades de la organización.
– Gestión de claves. El uso de técnicas criptográficas implica una gestión
de las claves que les dan soporte, lo cual incluirá tener normas para la gene-
ración de claves, su uso y su distribución a los usuarios autorizados, pro-
tegiéndolas en todo momento.
• Seguridad de los archivos de sistema. Estos archivos, incluyendo el código

fuente, son activos de información de los que dependen en gran medida la
seguridad de los datos almacenados en los sistemas. Por ello, debe contro-
larse el acceso y manipulación de estos archivos. Los controles son:
– Control del software en explotación. Para controlarlo adecuadamente
deben existir procedimientos para efectuar la instalación y actualización
de software en los sistemas operativos, incluyendo el modo de restaurar el
programa inicial si falla la instalación. Estas tareas deberán ser ejecutadas
por administradores con la adecuada formación y autorización para ello, y
sólo tras haber realizado pruebas que garanticen la ausencia de problemas
tras la instalación.
– Protección de los datos de prueba del sistema. En muchos casos se utilizan
datos reales para realizar las pruebas, por lo que hay que ser muy cuidadosos
al seleccionarlos, mantenerlos protegidos mientras duran las pruebas y eli-

minarlos de ese entorno en cuanto concluyan.
– Control de acceso al código fuente de los programas. Un acceso indebido
pondría en peligro la integridad de los programas, por lo que debe tomarse
medidas, tales como mantener el código fuente fuera de los entornos de
producción y tener distintos niveles de permisos de acceso, ya que no todo
el mundo necesita acceder a toda la biblioteca, por ejemplo, el personal de
asistencia técnica podrá acceder sólo a aquellos programas que precisen.
• Seguridad en los procesos de desarrollo y soporte. Cuando se desarrolla soft-

ware o se proporcionan servicios de asistencia técnica, es necesario que el
entorno en el que se desarrollan las actividades sea seguro y esté controlado,
lo cual se conseguirá con los siguientes controles:
– Procedimientos de control de cambios. Realizar cambios en un desarrollo
es una tarea que requiere de un estricto control para evitar costosos fallos.
Por ello, deben realizarse mediante un procedimiento formal que mini-
mice el riesgo de incidentes.
– Revisión técnica de las aplicaciones tras efectuar cambios en el sistema
operativo. Los sistemas operativos son susceptibles de cambios por diver-
sos motivos, pero, al depender de él las aplicaciones, es aconsejable realizar
un chequeo para verificar que esos cambios no han afectado de alguna
manera (funcional, operativa o en seguridad) a las aplicaciones, sobre
todo a aquellas que la organización considere críticas.
– Restricciones a los cambios en los paquetes de software. Es casi inevitable
tener que realizar cambios a los paquetes de software en algún momento
de su vida útil, pero para evitar problemas con su integridad o el de la
información que manejan, sólo se deben efectuar los cambios estricta-
mente necesarios, por personal autorizado y que controle perfectamente
todo el proceso.
– Fugas de información. Al desarrollar software se deben prever situaciones
que permitan fugas de información, para ello se supervisará al personal,
las actividades del sistema, el uso de los recursos, se escanearán las comu-
nicaciones para detectar información oculta, etc.
– Externalización del desarrollo de software. Cuando se subcontrata el desa-
rrollo de software, deben establecerse los mecanismos apropiados para super-
visar dicho desarrollo, de manera que los requisitos establecidos sean incor-
porados desde el principio y se vayan cumpliendo a lo largo del proyecto.
Así se evita llegar al final de proyecto y descubrir que falta alguno de ellos.
• Gestión de las vulnerabilidades técnicas. Los sistemas de información están

sujetos a cambios y actualizaciones para corregir fallos. Los proveedores
informan sobre los mismos y emiten parches y actualizaciones para mitigarlos
o eliminarlos.
– Control de las vulnerabilidades técnicas. Hay que esforzarse para mante-
nerse al día en lo relativo a las vulnerabilidades técnicas de los sistemas de
información que están siendo utilizados. Con esa información se puede
evaluar en qué grado pueden las vulnerabilidades afectar a los sistemas y
al negocio, y adoptar las medidas oportunas. Es decir, no necesariamente
deben implementarse los parches y actualizaciones que recomiende el fa-
bricante, pero al menos hay que considerarlo y tomar una decisión
documentada.
3.10. Gestión de las incidencias

Puesto que es inevitable que las incidencias ocurran, hay que tener mecanismos que
permitan detectarlas y emprender acciones inmediatas para reducir en lo posible
los daños originados. Los objetivos y controles de este capítulo tratan precisamente
de cómo hacerlo:
• Notificación de eventos y puntos débiles de la seguridad de la información.
En muchas ocasiones no se solucionan los problemas porque no existen
canales de comunicación apropiados para comunicarlos. El objetivo consiste
en asegurarse de que los eventos y las vulnerabilidades de la seguridad de la
información se comunican, y así puedan buscarse soluciones.
– Notificación de los eventos de seguridad de la información. Todos aquellos
en contacto con los sistemas de información, trabajadores, contratistas y
terceros, deberían tener instrucciones claras sobre cómo proceder en caso
de que detecten algún evento de seguridad, a quién deben comunicárselo
y de qué forma.
– Notificación de los puntos débiles de la seguridad. Como en el control
anterior, cualquier usuario de los sistemas y la información, tanto los
internos como los externos, deben estar obligados a notificar cualquier
punto débil que observen o que sospechen que exista.
• Gestión de incidentes de seguridad de la información y mejoras. Para solu-

cionar eficazmente los incidentes que ocurran deben tomarse medidas estu-
diadas y coherentes. Los controles a aplicar son:
– Responsabilidades y procedimientos. Deben existir responsabilidades y

procedimientos, de manera que se pueda dar una respuesta rápida a los
incidentes. Quizás sea necesario establecer distintos niveles de soporte de
incidentes en función del tipo y complejidad de los mismos.
– Aprendizaje de los incidentes de seguridad de la información. Si se regis-
tran los tipos, volúmenes y costes de los incidentes de seguridad de la
información, pueden detectarse incidentes recurrentes o con un elevado
alcance. Esto permitiría adoptar decisiones informadas para la mejora de
los controles o para añadir nuevos, que eviten gastos innecesarios.
– Recopilación de evidencias. Es necesario llevar a cabo este control con rigu-
rosidad en caso de establecer acciones legales tras un incidente. Hay que
recopilar evidencias y conservarlas en la manera prevista por la ley para
que puedan ser admitidas en un tribunal.
3.11. Gestión de la continuidad del negocio

En caso de desastre, la organización debe estar preparada para continuar con sus
actividades en el menor plazo de tiempo posible para evitar su desaparición. Los
peligros de ataque terrorista o desastres casuales, que se materializan de cuando en
cuando y llenan páginas en los periódicos, han hecho que ahora se perciban más
necesarios este tipo de actividades.
Un plan de continuidad se puede definir como el conjunto de instrucciones y pro-
cedimientos que van a seguirse en una organización en caso de que ocurra algo
que interrumpa las actividades normales durante un plazo de tiempo significativo.
Es decir, un corte de luz de unos minutos no será un incidente grave para la mayoría
de las organizaciones. Un corte de luz de horas puede comprometer algunas ope-
raciones de la organización y deberán existir procedimientos para paliar esta si-
tuación. Un corte de luz de días es muy probable que requiera un plan de con-
tinuidad en toda regla para impedir que la organización colapse.
Un plan de continuidad contendrá procedimientos para actuar en cada etapa de la
crisis, hasta que se consigan recuperar las actividades hasta un nivel aceptable. Para
que puedan aplicarse eficazmente, todo el personal de la organización debe for-
marse adecuadamente en estos procedimientos:
• Aspectos de seguridad de la información en la gestión de la continuidad del
negocio. Aun en el caso de que exista algún plan de continuidad en la orga-
nización, no es habitual que se contemplen los aspectos relacionados con los
sistemas de información y la información misma. Pero una organización no
puede subsistir sin su información, por lo que garantizar su seguridad debe

ser un elemento clave de cualquier plan de continuidad.
– Inclusión de la seguridad de la información en el proceso de gestión de la
continuidad del negocio. Debería desarrollarse y mantenerse un proceso
controlado para la continuidad del negocio en toda la organización que
trate los requisitos de seguridad de la información necesarios, como
cuáles son los activos que soportan los procesos críticos de negocio y cuáles
serían las consecuencias de incidencias en dichos activos.
– Continuidad del negocio y evaluación de riesgos. Una de las tareas funda-
mentales para desarrollar un plan de continuidad del negocio es el análisis
del impacto en él, es decir, un análisis de riesgos donde se identifican las
incidencias que pueden suponer una interrupción de las actividades, la
probabilidad de que ocurran, sus efectos y sus consecuencias en el tiempo.
– Desarrollo e implementación de planes de continuidad que incluyan la
seguridad de la información. Los planes de continuidad de negocio deben
permitir la recuperación y restauración de las operaciones de negocio y la
disponibilidad de la información en los plazos identificados. Para trazar
un plan de continuidad se debe:
√ Identificar los objetivos y los responsables de las distintas fases.
√ Identificar las pérdidas aceptables de información o servicios.
√ Definir las escalas temporales en las que deben estar restablecidos los
servicios y la información.
– Marco de referencia para la planificación de la continuidad del negocio.

Un marco de referencia de un plan de continuidad del negocio identifica
los requisitos de seguridad de la información, además tendrá en cuenta los
aspectos generales, tales como en qué condiciones se activarán los planes,
cuáles son los procedimientos de emergencia, medidas para proteger la
imagen y reputación de la organización, y formación del personal para
que pueda ejecutar sus tareas y responsabilidades adecuadamente en caso
de crisis.
– Pruebas, mantenimiento y revaluación de los planes de continuidad del
negocio. El plan ha de revisarse para verificar que sigue siendo aplicable
y que cubre todos los activos. El plan debe probarse para comprobar que es
viable y que todo el mundo conoce las acciones que debe emprender si
se activa el plan.
3.12. Cumplimiento
Este capítulo trata de garantizar que los sistemas cumplen con las políticas y normas
de seguridad de la organización, así como con los requisitos legales pertinentes.
Cuenta con tres objetivos de control:
• Cumplimiento de los requisitos legales. El objetivo de este procedimiento es
cumplir con la legislación aplicable a la organización, evitando infracciones
que pueden resultar muy dañinas tanto en términos económicos como de
reputación para la organización. En nuestro país, las principales leyes que
afectan a la mayoría de las organizaciones son:
– Ley Orgánica 15/1999, de 13 de diciembre, de Protección de datos de
carácter personal y Real Decreto 994/1999, de 11 de junio, por el que
se aprueba el Reglamento de Medidas de seguridad de los ficheros auto-
matizados que contengan datos de carácter personal.
– Real Decreto Legislativo 1/1996, de 12 de abril, por el que se aprueba el
Texto Refundido de la Ley de Propiedad Intelectual.
– Ley 32/2003, de 3 de noviembre, General de Telecomunicaciones, para la
regulación de las telecomunicaciones, sobre la explotación de las redes y
la prestación de los servicios de comunicaciones electrónicas y los recursos
asociados.
– Ley 34/2002, de 11 de julio, de servicios de la sociedad de la información
y de comercio electrónico (LSSI).
Los controles a aplicar son:

– Identificación de la legislación aplicable. El responsable de seguridad,
junto con los servicios jurídicos de la organización, debe mantener actuali-
zada una lista de legislación vigente aplicable y ocuparse de que cumplan
con ella los que tengan responsabilidades relativas a la aplicación de la ley.
– Derechos de Propiedad Intelectual (DPI). La organización debe contar
con procedimientos que garanticen un uso correcto de material con dere-
chos de propiedad intelectual, incluyendo el software propietario.
– Protección de los documentos de la organización. En toda organización
existen documentos importantes por diversos motivos, que deben prote-
gerse adecuadamente frente a pérdidas, destrucción y falsificación.
– Protección de datos y privacidad de la información de carácter personal.
El procedimiento deben seguirlo todos los empleados con acceso a datos
personales, bien a través del sistema informático habilitado para acceder a

los mismos o bien a través de cualquier otro medio.
– Prevención del uso indebido de los recursos de tratamiento de la informa-
ción. La organización debe tener medidas que impidan que los usuarios
recurran a los sistemas de información para usos indebidos.
– Regulación de los controles criptográficos. Estos controles están sujetos a
leyes y regulaciones, posiblemente también a acuerdos con otras organiza-
ciones, por lo que deben existir normas para su correcta utilización.
• Cumplimiento de las políticas y normas de seguridad, y cumplimiento téc-

nico. El SGSI contiene numerosas políticas y normas a seguir, por lo que hay
que efectuar un seguimiento para comprobar en qué medida se cumplen.
– Cumplimiento de las políticas y normas de seguridad. Los responsables
de cada área son los encargados de velar por el correcto cumplimiento de las
mismas. Para comprobar que es así, se llevarán a cabo auditorías internas
o externas que detecten las posibles no conformidades.
– Comprobación del cumplimiento técnico. Deben realizarse chequeos pe-
riódicos de los sistemas para verificar que se están aplicando los controles
y medidas definidos en el sistema, para detectar posibles errores u omi-
siones que comprometan la seguridad de la información.
• Consideraciones sobre la auditoría de los sistemas de información. Objetivo:

lograr que el proceso de auditoría de los sistemas de información alcance la
máxima eficacia con las mínimas interferencias.
– Controles de la auditoría de los sistemas de información. Las auditorías
informáticas son herramientas muy útiles para detectar vulnerabilidades y
puntos de mejora, pero por su propia naturaleza hay que ser cuidadosos al
planificarlas y diseñarlas, de manera que no interfieran o interrumpan las
actividades habituales de la organización.
– Protección de las herramientas de auditoría de los sistemas de informa-
ción. Un uso indebido de estas herramientas, intencionado o no, puede
ser muy perjudicial, por lo que deben estar protegidas y el acceso a ellas
debería encontrarse restringido.
4 Definición e
implementación
de un SGSI
4.1. El proyecto
Básicamente, un proyecto de definición de un SGSI se puede estructurar en 7 grandes
bloques, que comprenden una serie de fases y actividades de acuerdo al esquema
presentado en la figura 4.1.
Las actividades principales para crear un SGSI son:
• Definición del alcance, los objetivos y la política de seguridad. Debe cubrir
todos los aspectos de la seguridad: seguridad física, seguridad lógica, seguri-
dad del personal, y adecuarse a las necesidades y recursos de la organización.
• Desarrollar el inventario de activos. Hay que tener presente cuáles son los
activos más valiosos, que a la vez pueden ser los más vulnerables.
• Realizar el análisis de riesgos. Cada uno de los pasos ha de ser documentado
en el análisis de riesgos, con las valoraciones de todos los parámetros impli-
cados: amenazas que afectan a cada activo, nivel de vulnerabilidad, probabi-
lidad de ocurrencia y los efectos que podría suponer que se materializara la
amenaza, es decir, que una amenaza explorara la vulnerabilidad de un activo.
Este análisis proporcionará un mapa de los puntos débiles del negocio, que
serán los que hay que tratar en primer lugar.
• Seleccionar las medidas de seguridad a implementar. La gestión de los riesgos
implica seleccionar e implementar las medidas técnicas y organizativas nece-
sarias para impedir, reducir o controlar los riesgos identificados, de forma que
los perjuicios que puedan causar se eliminen o se reduzcan al máximo. Hay
que considerar, antes de seleccionarlos, que dichos controles tienen unos
costes de implementación y gestión.
Fases del proyecto
Lanzamiento y análisis de situación 1
Elaboración de política
Definición del alcance 2
y propuesta de objetivos
Inventario Análisis Selección

3
de activos de riesgos de controles
Elaboración de documentación del SGSI

4
(manual, procedimientos, instrucciones)
Implementación del SGSI 5
Auditoría interna Revisión del sistema 6
Auditoría de certificación 7
Figura 4.1. Fases del proyecto de implementación de un SGSI
• Evaluar los riesgos residuales. Después de identificar los controles adecuados

para reducir riesgos al valor estimado como aceptable, debe evaluarse en
cuánto se reduce el riesgo al aplicarlos. Por muchos controles que se apliquen
no se puede eliminar el riesgo totalmente, siempre habrá un riesgo residual.
La dirección tiene que conocer que este riesgo existe y aceptarlo.
4. Definición e implementación de un SGSI 75
• Documentar los procedimientos necesarios para implementar las medidas

seleccionadas. Los procedimientos son la manera de plasmar la imple-
mentación de los controles de seguridad y las tareas de administración
del SGSI. Un procedimiento debe reflejar fielmente los pasos a seguir para
la realización de las tareas, pero debe ser conciso y claro para que no se
cometan errores.
• Implementación de los controles y los procedimientos. Puesto que lo habitual
es que haya muchos controles a implementar, lo más práctico es planificarla
en el tiempo. De todos modos, es preferible abordar proyectos pequeños que
tengan un plazo de ejecución corto y permitan obtener beneficios enseguida,
que intentar abordar proyectos muy ambiciosos que se alargan en el tiempo
y que no parecen ofrecer un adecuado retorno de la inversión.
• Formar y concienciar al personal. Es fundamental para que el SGSI esté bien
implementación que haya un plan de formación con acciones formativas a
distintos niveles. El responsable del SGSI deberá poseer una formación
exhaustiva en todos los temas relacionados, incluso como auditor interno; el
personal en general tendrá que conocer y asumir, si no lo han hecho ya, sus
responsabilidades en materia de seguridad, y los afectados por los nuevos
procedimientos tendrán que asimilar sus nuevas tareas o los cambios que se
han producido en las que ejecutaban.
• Realizar la auditoría interna y la revisión del SGSI por la dirección. De esta
manera se comprobará que el SGSI se ajusta a la norma y a los requisitos de
la organización.
4.2. Documentación del SGSI

Según la norma, en un SGSI no se exige un manual de seguridad al uso de otras
normas de gestión, que sí especifican que ha de existir un manual de gestión. Sin
embargo, la norma es muy clara en cuanto a la información que debe estar docu-
mentada. Por ello, el SGSI consistirá en un conjunto de documentos que, como
mínimo, serán los siguientes:
• Política de seguridad.
• Inventario de activos.
• Análisis de riesgos.
• Gestión de riesgos.
• Documento de aplicabilidad.
• Procedimientos para implementar los controles.

• Procedimientos para la gestión del SGSI.
Pueden existir también otros documentos como planes de seguridad, instrucciones

técnicas, etc.
Uno de los requisitos de la norma es que se establezca la trazabilidad en todo el sis-
tema, desde la política hasta los procedimientos, justificando la elección de los con-
troles, que deben ser proporcionales a los riesgos y a las necesidades de la empresa.
Estas necesidades comprenden tanto las de seguridad (cómo de seguro quiere que
sea el sistema), como las del negocio (qué se necesita para funcionar eficazmente,
qué están haciendo sus competidores) y las legales o reglamentarias (qué leyes y
regulaciones aplicables a su negocio debe tener en cuenta).
4.3. Política de seguridad

La política de seguridad recogerá las líneas generales de actuación de la organización
en una declaración que estará firmada por la dirección, en la que se compromete a
velar por la confidencialidad, integridad, disponibilidad, autenticidad y trazabilidad
de los activos de información.
Además, como parte de este documento o en otro distinto, se debe documentar:
• El alcance del sistema, es decir, qué partes de la organización van a estar pro-
tegidas por el SGSI. Puede ser la organización entera o una parte relevante
de la misma: departamento, servicio o proceso. La recomendación a la hora
de decidir el alcance es escoger uno que sea realmente abordable por la
empresa. Si es demasiado amplio y no se cuenta con los recursos necesarios
para llevar a cabo un SGSI de esa dimensión, el proyecto se alargará y llegará
un momento en que se parará, puesto que no hay personal o presupuesto
para continuar con él, con la consiguiente frustración de los implicados y la
pérdida de tiempo y dinero de la organización.
• La estructura de la empresa, un organigrama de las distintas áreas y respons-
ables de la organización, y sus relaciones internas.
• Las diferentes responsabilidades de cada parte de la organización: el respon-
sable de seguridad, la dirección, el responsable de sistemas, el personal, etc.
• La topología de la red, de manera que se muestren los principales sistemas
de información y comunicación que se emplean.
• La clasificación de la información, utilizando la nomenclatura de la organi-

zación y explicando los criterios de clasificación.
• El enfoque y la metodología del análisis de riesgos. Así cualquiera puede veri-
ficar los resultados del análisis, ajustándose al razonamiento que se ha seguido
para llevarlo a cabo.
• Las normas generales de uso de los activos. Estas normas deben existir para
evitar incidentes no deseados y utilizaciones indebidas de los activos. Serán
hechas públicas, e incluso pueden ser objeto de una entrega formal a los
empleados o terceras partes implicadas, de modo que se hagan responsables de
las infracciones. Es fundamental establecer unas pautas mínimas en temas
como el empleo de las contraseñas y el de las comunicaciones, fuente de
numerosas incidencias. Estas normas de uso son un elemento importante en la
concienciación del personal, ya que establecen unas pautas de compor-
tamiento, que aunque sean de sentido común y no marquen límites demasiado
estrictos, sí indican que la empresa se preocupa al respecto y que los emplea-
dos deberían hacer lo mismo.
• Los objetivos de seguridad que se pretenden alcanzar. Puede ser difícil
establecer unos objetivos claros y útiles sin tener datos de partida, pero al
menos se deberá intentar expresar qué nivel de seguridad se desea alcanzar.
Se puede comenzar por estimar qué metas se quieren lograr en términos
de confidencialidad, disponibilidad e integridad. Por ejemplo, para veri-
ficar las mejoras en confidencialidad puede utilizarse como métrica el
número de incidencias relativas a la confidencialidad, y decidir que el obje-
tivo para este año va a ser tener tres o menos incidencias de este tipo. Con
los resultados que se vayan obteniendo, se irá revisando dicho objetivo
para ajustarlo a la realidad. Si sistemáticamente obtenemos un valor mucho
más elevado, puede que el objetivo no sea realista y haya que revisarlo a la
baja.
Un ejemplo de cómo realizar este documento puede consultarse en el apartado 8.1

de este libro.
4.4. Inventario de activos

El inventario de activos es la recopilación de todos aquellos elementos indispensa-
bles para que la administración electrónica pueda prestarse con todas las garantías,
de manera que los ciudadanos tengan confianza en ella.
El inventario de activos debe recoger la siguiente información:

• El nombre del activo, por ejemplo: equipo de usuario, router 014, proyecto,
expediente, etc.
• La descripción del activo.
• Categoría a la que pertenece, por ejemplo: equipo, aplicación, servicio, etc.
• Ubicación: el lugar físico en el que se encuentra dentro de la organización.
• Propietario: entendiendo por tal al responsable del activo.
• Identificados los activos de información: se les debe valorar de acuerdo a su
importancia para la empresa. Esta apreciación será lo más objetiva posible, ya
que con ella se determinará sobre qué activos se realizará el análisis de riesgos.
Por supuesto, se puede hacer una estimación de todos los activos, pero si son
muchos, los recursos limitados, o ambas cosas, lo razonable es elegir un grupo
de activos reducido para que el análisis de riesgos no sea inabarcable. Por ejem-
plo, se puede escoger analizar los activos que están por encima de un valor.
Para valorar los activos se considerarán los parámetros de confidencialidad, disponi-

bilidad e integridad de los activos, determinándose la importancia que tienen para la
organización en una escala de valores predefinida.
Como ejemplo, vamos a utilizar un activo llamado “Facturas”, del tipo “Datos”,
ubicado en el Servidor S y cuyo propietario es el responsable de administración.
Cada uno de los parámetros se valorará del 1 al 4 según su relevancia para la orga-
nización, y el valor total del activo será la suma aritmética de todos los valores par-
ciales (véase la tabla 4.1).
Tabla 4.1. Inventario de activos
Activo Confidencialidad Integridad Disponibilidad Valoración total
Facturas 2 4 2 8
La confidencialidad de las facturas es importante, pero no crítica, puesto que ha de

estar disponible para mucha gente (clientes, Hacienda, asesores fiscales, personal
de administración, etc.) y su filtración no supondría un trastorno excesivo. Una
base de datos de clientes tendría un valor más alto en este aspecto, por contener
datos de carácter personal.
La integridad de las facturas es muy importante, puesto que las erróneas son
origen de reclamaciones y trabajo extra, e incluso de sanciones por parte de la
Administración, lo cual no es en absoluto deseable. La integridad de un expediente

de compra se valoraría menos.
Que las facturas estén disponibles es importante, pero no fundamental para que el
negocio continúe funcionando. No se producirá un trastorno serio en la organi-
zación a menos que el momento en el que suceda la indisponibilidad sea crítico
(por ejemplo, cuando llega la hora de preparar los impuestos o cerrar el año). Sin
embargo, la disponibilidad del Servidor S en el que se alojan las facturas se valo-
raría más alta, puesto que la indisponibilidad de dicho equipo sí supondría un
trastorno considerable para la marcha de la organización.
La suma de los valores nos da 8. Haciendo lo mismo para todos los activos po-
dremos estimar cuáles son los activos más críticos, más valiosos para la organi-
zación y establecer comparaciones.
Obviamente, los razonamientos anteriores son hipotéticos y se ofrecen a modo de
ejemplo. En cada organización los activos se ven y valoran de acuerdo con las cir-
cunstancias y la utilización que brinda cada uno de ellos.
Otro aspecto a documentar en este punto es la relación entre los procesos de negocio y
los activos de información. Según la norma se debe documentar cómo la información
que se gestiona en la empresa soporta los procesos de negocio, es decir, colabora en el
funcionamiento del negocio y, por lo tanto, en que éste siga generando ingresos.
Para ello hay que definir cuáles son los principales procesos de negocio (adminis-
tración, producción, gestión de proyectos, compras, etc.) y especificar qué activos
forman parte de su operativa normal. Por ejemplo, podemos considerar que el pro-
ceso “Compras” se apoya en el personal del departamento, las aplicaciones con las
que se produce la documentación, la propia documentación (peticiones de oferta,
ofertas, órdenes de compra, etc.), los equipos de usuarios, los servidores donde se
aloja la información y las comunicaciones.
Un ejemplo de cómo realizar este documento puede consultarse en el apartado 8.2 de
este libro.
4.5. Análisis de riesgos

Para efectuar el análisis de riesgos confeccionaremos (o utilizaremos la propuesta
por la metodología o herramienta que se haya escogido) una lista de las amenazas
a las que se enfrenta la empresa. Por ejemplo:
• Fuego.
• Inundación.
• Corte de suministro eléctrico.

• Fallo del suministro de comunicaciones.
• Error de usuario.
Para cada activo hay que valorar cuál es la vulnerabilidad de ese activo con respecto
a cada una de las amenazas. Esta valoración se hará de acuerdo a una escala definida
por la empresa, por ejemplo de 1 a 4:
1 Nada vulnerable.
2 Poco vulnerable.
3 Bastante vulnerable.
4 Muy vulnerable.
Es decir, si tenemos un activo “facturas” expuesto a la amenaza “fuego”, será muy

vulnerable (4) si las facturas están en soporte papel, pero podemos considerar que
es bastante vulnerable (3) si están en soporte electrónico.
El siguiente paso será decidir cuál es la probabilidad de que ocurra la amenaza
(véase la tabla 4.2).
Tabla 4.2. Análisis de riesgos
Probabilidad de ocurrencia
Guía
de la amenaza
1 Muy baja Una media de una vez cada 5 años
2 Baja Una media de una vez cada 2 años
3 Media Una media de una vez al año
4 Alta Una media de 3 veces al año
Por último, para decidir el nivel de riesgo de los activos habrá que evaluar el
impacto que tendría en el negocio que la amenaza se materializara, siguiendo con
el ejemplo anterior, que un incendio acabara con las facturas.
Hay que definir de nuevo una escala para asignar un valor numérico a ese impacto,
como:
1 Ningún impacto.
2 Poco impacto.
3 Bastante impacto.
4 Mucho impacto.
En nuestro ejemplo vamos a considerar que el impacto sería 3.

Estas valoraciones se deben realizar sin aplicar ninguna medida de seguridad a los
activos, es decir, hay que estimar que nuestras facturas en papel están simplemente
en una carpeta o que las facturas en soporte electrónico no tienen copias de seguri-
dad ni se encuentran protegidas por contraseña.
Con los valores obtenidos para cada activo hay que calcular el riesgo para cada
amenaza (que será, por ejemplo, el producto de los tres parámetros), y después cal-
cular el nivel de riesgo de ese activo, que puede ser una simple suma de todos los
valores obtenidos o puede optarse por tomar sólo el valor más alto. El objetivo es
cuantificar algo tan intangible como el nivel de riesgo y poder comparar todos los
activos con un criterio homogéneo. Por ello, el método de cálculo no es tan crucial
como los criterios que se apliquen para efectuar esos cálculos, que deben ser claros,
coherentes y bien definidos.
Las escalas y los cálculos serán concretos, entendibles y se aplicarán a todos los
activos de la misma manera.
En este ejemplo (véase la tabla 4.3), el nivel de riesgo puede considerarse que
es 32, puesto que es el mayor de los obtenidos, o bien se pueden sumar los valores
y sería 50. En cualquier caso, lo esencial es utilizar el mismo sistema para todos y
cada uno de los activos, puesto que de lo que se trata es de comparar sus niveles de
riesgo, ver qué activos tienen más riesgo que otros. De esta manera, obtendremos
un “mapa de riesgos” coherente, como en la tabla 4.4, del que se puede deducir
que la aplicación de gestión está expuesta a más riesgo y entonces deberán aplicarse
más medidas de seguridad para protegerla.
Tabla 4.3. Ejemplo del nivel de riesgo
Amenazas Facturas
Fuego 3 1 3 9
Fallo de electricidad 1 3 3 9
Error de usuario 4 4 2 32
Tabla 4.4. “Mapa de riesgos”
Activo Riesgo
Facturas 32
Equipos de usuario 24
Aplicación de gestión 48
Base de datos de proveedores 9
Tanto los métodos de cálculo como las valoraciones y los resultados quedarán docu-
mentados para cumplir con la norma.
Una vez obtenidos todos los valores de riesgo hay que decidir qué se va hacer con
cada uno de ellos, si se va a asumir, a transferir, a eliminar o a mitigar. Esta
declaración de la gestión de los riesgos estará firmada por la dirección. Normal-
mente las decisiones son asumir los riesgos o mitigarlos. En cualquier caso hay que
tener en cuenta que siempre habrá un pequeño grupo de controles que van a apli-
carse sobre todos los activos o sobre muchos, como es el caso de la política de
seguridad, el inventario de activos, la protección de los datos personales o las
copias de seguridad.
Decidir en qué punto un nivel de riesgo puede ser asumido por la empresa, o por
decirlo con la expresión utilizada en la norma, cuándo un riesgo es asumible, depende
por entero de la empresa y de hasta qué punto puede y quiere tomar medidas en
cuanto a la seguridad de su información. Por eso hay que idear de nuevo un criterio
para distinguir entre los riesgos asumibles y los que no lo son.
Siguiendo con nuestro ejemplo, los posibles valores de riesgo irían del 1 al 64, por
lo que podríamos estipular que la mediana, el 32, es el valor por debajo del cual se
considerará asumible el riesgo. Otra opción podría ser la media de los valores, o
directamente convenir un valor por debajo del cual el riesgo es asumible, por ejem-
plo 10. La norma no especifica nada sobre cómo escoger este valor, y es la empresa
la que debe valorar cuántos riesgos está dispuesta a correr y hasta dónde puede
invertir en mitigarlos.
La documentación del análisis de riesgos recogerá:
• Todas las valoraciones realizadas.
• Los valores de riesgo intrínseco.
• Cuál es el riesgo asumible.

• Las decisiones tomadas respecto a cada uno de los activos.
Un ejemplo de cómo realizar este documento puede consultarse en el apartado 8.3

de este libro.
4.6. Gestión de riesgos

Una vez que sabemos a qué nos estamos enfrentando, es necesario escoger de entre
los controles incluidos en la Norma UNE-ISO/IEC 27002 los que nos van a servir
para reducir los niveles de riesgo identificados en la fase anterior.
En un sentido amplio, los controles se pueden dividir en dos grupos, los de carácter
organizativo y los técnicos. Es importante lograr un balance en la selección que ase-
gure que no sólo se aplican las medidas técnicas apropiadas, sino que la gestión de la
seguridad es lo suficientemente sólida como para que funcionen correctamente.
Hay que revisar uno por uno los controles y considerar:
• Si está ya implementado.
• Si ayudaría a reducir el riesgo de alguno de los activos.
• Si el coste de implementarlo es aceptable.
• Si el coste de la operación y el mantenimiento del control serán aceptables.
Existen una serie de controles que deben ser implementados obligatoriamente

si optamos por la certificación, por ejemplo, tener una política de seguridad o un
inventario de activos, pero salvo esos, el resto, aunque nos parezcan muy apro-
piados al problema que tenemos entre manos, hay que valorar cuidadosamente los
criterios expuestos anteriormente, porque aplicar un control que luego es muy cos-
toso de implementar no va a ser una medida de seguridad eficiente, y uno que
suponga mucho esfuerzo implementación por motivos culturales o de organi-
zación, será difícil que llegue a ser eficaz.
No hay un número establecido o recomendado de controles a implementar. Se
deben implementar todos aquellos que beneficien a la seguridad de la información,
pero no pretender abarcar demasiados, puesto que lastrarían el desarrollo del SGSI
y no le permitirían una implementación adecuada.
Por ejemplo, el activo “facturas” que manejábamos. Será necesario contar con con-
troles de acceso a esta información (no todo el mundo tiene por qué acceder a ella),
copias de seguridad (que garanticen la disponibilidad de la información) o proce-

dimientos para intercambio de información (cómo las vamos a hacer llegar de
manera segura a los clientes o a los asesores garantizando su integridad). En gene-
ral, estos controles son fáciles de implementar e incluso en muchos casos, aunque
sea de manera informal, ya existen buenas prácticas relacionadas. El coste no
resulta elevado y reducen los principales riesgos detectados (fallos de usuario,
fuego…). Aislar los equipos en los que se tratan las facturas en un área segura, con
costosas medidas de seguridad física y equipos especiales que garanticen la
disponibilidad es, normalmente, demasiado gravoso económicamente para los
beneficios que se obtienen. La reducción del riesgo sería mayor que en el primer
caso, pero no compensaría.
Puesto que estamos hablando de sistemas de gestión orientados a la mejora continua,
es mucho más práctico en una primera iteración quedarse con un conjunto mínimo
de controles que cumplan con los requisitos de la Norma UNE-ISO/IEC 27001,
y que mitiguen hasta un nivel aceptable, aunque no sea muy bajo, el riesgo. Una
vez que el SGSI funciona de un modo correcto, se pueden ir añadiendo controles
o mejorando la implementación de los existentes para reducir progresivamente el
riesgo, es decir, para ir mejorando el sistema.
Decididos los controles a implementar e identificados aquellos que ya se utilizaban
en la empresa, hay que repetir el análisis de riesgos, ciñéndose al mismo método y
a los mismos criterios que la primera vez. La diferencia estriba en que lo que ahora
se debe valorar es el riesgo, puesto que ya tenemos medidas de seguridad que
habrán reducido la vulnerabilidad del activo y el posible impacto que un incidente
de seguridad supondría.
Retomando nuestro ejemplo, supongamos en esta ocasión que el activo “facturas”
existe en papel, guardado en un armario en una oficina con medidas antiincendios
(detectores, extintores, alarmas), y además se almacenan en un servidor, que con-
tará con un Sistema de Alimentación Ininterrumpida (SAI), situado en un armario
específico cerrado con llave, con control de temperatura, etc. Además se realiza una
copia semanal de seguridad, que a partir de ahora se enviará a otra ubicación.
Con estas medidas de seguridad implementadas o a punto de hacerlo, la vulnera-
bilidad al fuego se ha reducido quizás a 1, y como existen copias de seguridad
incluso fuera de la oficina, el impacto también se reducirá, por ejemplo a 2. La
vulnerabilidad al fallo de electricidad, es baja, el SAI puede ayudar a aminorar el
impacto, ya que si se produce un fallo el usuario puede terminar y guardar su tra-
bajo antes de que la avería lo elimine o corrompa. Puesto que la implementación
de un SGSI conlleva la definición y publicación de una política de seguridad con
normas para los usuarios, la vulnerabilidad al error de usuario deberá ser menor
(véase la tabla 4.5).
Tabla 4.5. Gestión de riesgos
Facturas
Amenazas
Riesgo Vulnera- Riego
Impacto
inicial bilidad residual
Fuego 9 1 2 2
Fallo de electricidad 3 1 2 2
Error de usuario 8 2 2 4
El grado de riesgo del activo “facturas” es ahora de 4, lo cual le sitúa en un nivel

inferior por debajo del cual el riesgo es asumible, es decir, no es necesario añadir
más controles a este activo.
En esta fase se generarán dos documentos: el documento de aplicabilidad y el
informe de gestión de riesgos.
Las decisiones sobre aplicar o no un control deberán quedar documentadas en el
documento de aplicabilidad. Este documento debe contener para cada control la
siguiente información:
• Si está aplicado.
• Si se va a aplicar.
• Si no se va a aplicar.
• Razonamiento explicando la decisión.
El informe de gestión de riesgos recogerá:

• Los controles aplicados a cada activo.
• Las valoraciones y los valores de riesgo resultantes tras la aplicación de los
controles.
• La aceptación de la dirección de los riesgos residuales.
Un ejemplo de cómo realizar dichos documentos puede consultarse en los apar-

tados 8.4 y 8.5 de este libro.
4.7. Plan de tratamiento del riesgo

Es conveniente, una vez decidido lo que se va a hacer, que se prepare un plan para
ejecutar las tareas a emprender para que el SGSI quede completamente implemen-
tado.
Las principales tareas serán la implementación de todos los controles, la formación,
la auditoría interna y la revisión por la dirección.
El plan puede ser además el documento idóneo para plasmar los objetivos de seguri-
dad junto con un grupo de métricas relevantes, medibles con escasos recursos y que
ofrezcan una información fiable de cómo funciona el SGSI.
La norma establece que se debe medir el rendimiento de todos aquellos controles
que se consideren relevantes. Además, hay que procurar que medir no resulte cos-
toso, por lo que se escogerá un grupo reducido de métricas que nos orienten sobre
si el SGSI funciona o no, por ejemplo, partiendo de los tres aspectos de seguridad,
y ver de qué manera podemos medir si conseguimos mantenerlos:
• Confidencialidad: reducir el porcentaje de incidentes relacionados, aumentar
la concienciación del personal, etc.
• Disponibilidad: porcentaje de disponibilidad de los equipos y sistemas.
• Integridad: reducir el porcentaje de información errónea, disminuir el por-
centaje de fallos del sistema o las aplicaciones, etc.
Una vez en marcha el programa de métricas, se verá cuáles son los puntos que
aportan información relevante sobre la marcha del SGSI, cuáles deberían ser
descartados y cuáles incorporados para mejorar nuestro conocimiento del fun-
cionamiento del SGSI. El mismo funcionamiento de los controles puede sugerir
nuevos objetivos y métricas que añadir.
Un ejemplo de este documento puede consultarse en el apartado 8.6 de este libro.
4.8. Procedimientos
Es uno de los puntos más problemáticos. El objetivo de un procedimiento es
describir la manera en la que se va a realizar una tarea. El nivel de detalle de un pro-
cedimiento no debería ser muy alto. Se trata de contar cómo se hace una tarea de
forma que alguien que no esté familiarizado con ella pudiera ejecutarla en caso
necesario. Para ello se debería describir a grandes rasgos lo que se debe hacer y citar
aquellos documentos que puedan ser de ayuda para llevar a cabo la tarea. Se debe
evitar ofrecer detalles que pueden cambiar con frecuencia, y obligarían a revisar el
procedimiento muy a menudo. Este tipo de datos deberían documentarse en
instrucciones técnicas y no en procedimientos.
El lenguaje debería ser lo más claro posible, evitando modismos y jergas ininteligi-
bles o que conduzcan a malas interpretaciones. El estilo debería ser conciso, sin
rebozos, lo cual facilita la comprensión del texto. El procedimiento, lo más breve
posible para que sea sencillo de leer, comprender y, lo más importante, de utilizar.
No hay ninguna regla respecto al número de procedimientos que deben crearse.
Además, un control puede implementarse de diversas maneras. Habrá, por ejem-
plo, controles que se implementarán con un documento como el inventario de
activos, y otros que lo harán con una medida técnica (instalación de un cortafue-
gos). Cuando la implementación se efectúe mediante un procedimiento, puede
aplicarse un procedimiento para cada control que se ha decidido implementar, pero
no es necesario. También resulta útil recoger en un mismo procedimiento varios
controles relacionados, por ejemplo, los relativos al control de accesos. Esta agru-
pación facilita enormemente la implementación de los controles y la gestión de la
documentación, y en consecuencia hace más sencilla la implementación del sistema.
Por otro lado, dependiendo de la complejidad de la organización o de las activi-
dades a tratar, también puede suceder que un control requiera más de un procedi-
miento para implementarse.
Señalar de nuevo que lo propuesto por la Norma UNE-ISO/IEC 27002 es mera-
mente informativo, puede utilizarse como referencia y punto de partida, pero los
procedimientos deben recoger el modo de ejecutar un control o varios, depen-
diendo del funcionamiento, estructura y cultura de la organización. En la medida
que el procedimiento refleje la realidad de la organización, o al menos la tenga en
cuenta al introducir los cambios, tendrá más éxito la implementación de los nuevos
modos de trabajo.
Es en este punto donde se hace más notoria la necesidad de ajustar el sistema a la
organización. Los procedimientos son los documentos de trabajo que más difusión
van a tener y que más van a afectar al personal tras la política de seguridad. Por eso
es crucial que se perciban como herramientas de trabajo útiles y no como directri-
ces alejadas de los modos habituales de trabajo. Para ello deben reunir todos los
requisitos mencionados, que sintetizaremos en dos palabras: claridad y realismo.
Un ejemplo de cómo realizar este documento puede consultarse en los aparta-
dos 8.7 y 8.8 de este libro.
4.9. Formación
El personal afectado por el SGSI, y en la medida de lo posible, todo el personal de
la empresa, debe recibir formación adecuada en seguridad de la información.
El personal es el elemento clave que permitirá al SGSI funcionar o fracasar. Todo el
mundo ha de conocer su existencia, el motivo de la nueva situación y los objetivos
que se persiguen al implementar los nuevos modos de trabajo o al formalizar los ya
existentes.
Cada grupo tendrá unas necesidades específicas y no todo el mundo necesitará for-
mación en todos los aspectos del SGSI. Por eso, el plan de formación deberá
recoger distintas actuaciones en función de estas necesidades.
Los medios de comunicación interna que ya existan en la organización (intranet,
paneles informativos, boletines, etc.) son muy útiles para difundir, por ejemplo, la
política de seguridad que debe llegar a toda la organización.
La formación puede ser interna, por ejemplo, charlas del responsable de seguridad
para explicar qué es un SGSI, las causas de su implementación y los principales
cambios que haya habido es una manera muy eficaz de informar a todos.
La asistencia o participación de la dirección en las acciones formativas es una exce-
lente oportunidad de demostrar su compromiso con el SGSI y su apoyo a la iniciativa.
4.10. Revisión por la dirección

El informe de revisión por la dirección habitualmente es elaborado por el respon-
sable de seguridad, que siguiendo los parámetros establecidos por la norma, realiza
un resumen de lo que se ha hecho y de cómo se ha desarrollado la implementación
o en su caso la operativa del SGSI, con las incidencias, los problemas, las soluciones
y los beneficios recabados.
Este informe debe ser estudiado y aprobado por la dirección, lo cual se hace en
muchos casos dentro del comité de seguridad.
4.11. Auditoría interna

La auditoría es una potente herramienta que permite detectar errores y puntos
débiles en el SGSI. Consiste en evaluar hasta qué punto el SGSI se ajusta a la
norma y el grado de cumplimiento de la organización de sus propias normas.

Para ello:
• Se comprueba que la documentación del SGSI está de acuerdo con lo
establecido en la norma.
• Se revisa cada punto de la norma y se va verificando que, efectivamente, exis-
ten pruebas de su cumplimiento (habitualmente estas pruebas son los reg-
istros generados al ejecutar los procedimientos).
• Se revisan los procedimientos, confirmando que se ejecutan tal y como está
establecido en ellos, realizando pruebas de cumplimiento, es decir, verificar
técnicamente que los procedimientos se cumplen: que los usuarios están efec-
tivamente dados de alta, que se efectúan las copias de seguridad y cómo, etc.
Las auditorías internas deberían recoger y utilizar los resultados de otras auditorías
que se lleven a cabo, como la auditoría de la LOPD, pruebas de intrusión, audi-
torías informáticas, etc.
Los auditores internos han de conocer la empresa a fondo, ser independientes,
objetivos y tener algún conocimiento del SGSI.
4.12. Registros
Puestos en marcha los procedimientos, se generarán una serie de registros, que son
la prueba de que se han ejecutado.
Algunos de los principales registros son:
• Actas del comité de seguridad.
• Informe de la revisión por la dirección.
• Informes de auditorías.
• Registros de formación.
• Perfiles profesionales.
• Acciones correctivas y preventivas.
• Registros de copias de seguridad.
• Registros de mantenimientos.
• Registros de usuarios.
Los registros pueden estar en cualquier formato y soporte, pero deberán per-
manecer controlados para que no se deterioren o pierdan. El número de registros
dependerá de qué procedimientos se encuentren en uso, su complejidad y las cos-
tumbres de la empresa.
La recomendación es automatizar lo más posible la producción de registros para
evitar tener que generarlos manualmente, con el consiguiente consumo de recursos.
5 Proceso de certificación
Actualmente, la Norma UNE-ISO/IEC 27001 es la norma española vigente para

la certificación de sistemas de gestión de la seguridad de la información.
La Norma UNE-ISO/IEC 27002 no es certificable, es sólo una guía de buenas prác-
ticas.
Hay que tener claro que con estas normas no estamos certificando la seguridad de
la información de nuestra organización, sino el sistema mediante el cual gestion-
amos esta seguridad.
Certificar un sistema de gestión es obtener un “documento” que reconoce y respalda
la correcta adecuación del sistema de gestión de seguridad de la información con-
forme a una norma de referencia, en este caso la Norma UNE-ISO/IEC 27001.
El certificado de cumplimiento de una norma únicamente puede ser emitido por
una entidad debidamente acreditada ante el organismo que define los criterios bajo
los que pueden llevarse a cabo estas actividades.
En España las entidades de certificación tienen que estar acreditadas por ENAC.
ENAC es una entidad privada, independiente y sin ánimo de lucro, cuya función
es coordinar y dirigir en el ámbito nacional un sistema de acreditación conforme a
criterios y normas internacionales. ENAC acredita organismos que realizan acti-
vidades de evaluación de la conformidad, sea cual sea el sector en que desarrolle su
actividad, su tamaño, su carácter público o privado, o su pertenencia a asociaciones
o empresas, universidades u organizaciones de investigación. ENAC acredita a labo-
ratorios, entidades de inspección, entidades de certificación, verificadores medioam-
bientales, etc.
La realización de auditorías de sistemas de gestión en general se rige por la Norma
UNE-EN ISO/IEC 17021 Evaluación de la conformidad. Requisitos para los organismos
que realizan la auditoría y la certificación de sistemas de gestión, y en particular, son

los SGSI los que deben ser auditados por entidades que cumplan los requisitos de
la Norma ISO/IEC 27006 Tecnología de la información. Técnicas de seguridad. Req-
uisitos para organismos proveedores de auditoría y certificación de Sistemas de Gestión de
Seguridad de la Información.
Entre los beneficios de emprender la certificación señalaremos los siguientes:
• Contribuye a impulsar las actividades de protección de la información en las
organizaciones.
• Mejora la imagen y afianza la reputación de una organización.
• Genera confianza frente a terceros, ya que es una prueba de la rigurosidad de
la gestión de la empresa.
• Es un factor que permite diferenciarse de la competencia, lo que proporciona
una cierta ventaja competitiva.
• Si no existe todavía otro sistema de gestión en la organización, logra crear
una cultura de enfoque a procesos y de mejora continua que beneficiará a
toda la estructura.
La organización que desee solicitar el certificado debe contactar con una entidad
de certificación acreditada.
Esta entidad recoge la información básica de la empresa, como su tipo de negocio,
número de empleados y actividades a certificar, con el fin de asignar un equipo
auditor adecuado y determinar el número de días necesarios para llevar a cabo la
auditoría.
• Fase 1. Revisión documental. El equipo auditor revisa la documentación
del SGSI para verificar que cumple con los principales requisitos de la norma
y emiten un informe con los hallazgos. Si el equipo auditor descubriese
incumplimientos graves de la norma, informarían a la organización de la
imposibilidad de conseguir la certificación en esas condiciones. Si detectasen
pequeñas no conformidades, habría que corregirlas antes de la siguiente fase,
que suele realizarse un mes más tarde.
• Fase 2. Auditoría de certificación. El equipo auditor recogerá evidencias
objetivas de que la organización cumple tanto con los requisitos de la normas
como con sus políticas, objetivos y procedimientos, así como con los requi-
sitos documentados. Si los auditores no detectan no conformidades graves, se
concede el certificado a la empresa.
6 Relación entre los
apartados de la norma y
la documentación del sistema
Para certificar un SGSI debe cumplir con los apartados 4 al 8 de la norma. La justifi-
cación de este cumplimiento quedará recogida en los documentos correspondientes y
los registros de ciertas actividades, que, a modo de ejemplo, pueden ser los siguientes:
Apartados de la norma Documento de soporte
0 Introducción
1 Objeto y campo de aplicación
2 Normas para consulta
3 Términos y definiciones
4 Sistema de gestión de la seguridad de

la información
4.1 Requisitos generales Política de seguridad
4.2 Creación y gestión del SGSI
4.2.1 Creación del SGSI Política de seguridad

Inventario de activos
Análisis de riesgos
Gestión de riesgos
Documento de aplicabilidad
(continúa)
4.2.2 Implementación y operación Plan de tratamiento del riesgo

del SGSI
4.2.3 Supervisión y revisión del SGSI Gestión de incidencias

Auditorías internas
Revisión por la dirección
Monitorización de objetivos
4.2.4 Mantenimiento y mejora del SGSI Acciones de mejora

Acciones preventivas y correctivas
4.3 Requisitos de la documentación
4.3.1 Generalidades Política de seguridad

Objetivos de seguridad
Procedimientos
Análisis de riesgos
Gestión de riesgos
Registros
Documento de aplicabilidad
Procedimiento para el
4.3.2 Control de documentos
control de la documentación
Procedimiento para
4.3.3 Control de registros
el control de los registros
5 Responsabilidad de la dirección
5.1 Compromiso de la dirección Política y planes firmados

Criterios y aceptación
de riesgos firmada
Revisión aprobada por la dirección
5.2 Gestión de los recursos
5.2.1 Provisión de los recursos Planes de seguridad
5.2.2 Concienciación, formación y Planes de formación

capacitación Registros de formación
(continúa)
6. Relación entre los apartados de la norma y la documentación del sistema 95
6 Auditorías internas del SGSI Plan de auditorías

Informes de auditorías
7 Revisión del SGSI por la dirección Informe de revisión por la dirección
7.1 Generalidades
7.2 Datos iniciales de la revisión
7.3 Resultados de la revisión
8 Mejora del SGSI
8.1 Mejora continua Acciones de mejora
8.2 Acción correctiva Acciones correctivas
8.3 Acción preventiva Acciones preventivas

7
Correspondencia entre las
Normas UNE-EN ISO 9001:2008,
UNE-EN ISO 14001:2004
y UNE-ISO/IEC 27001:2007
UNE-EN ISO 9001:2008 UNE-EN ISO 14001:2004 UNE-ISO/IEC 27001:2007
0 Introducción Introducción 0 Introducción
0.1 Generalidades 0.1 Generalidades
0.2 Enfoque basado en 0.2 Enfoque por procesos

procesos
0.3 Relación con la
Norma ISO 9004
0.4 Compatibilidad 0.3 Compatibilidad
con otros sistemas con otros sistemas
de gestión de gestión
1 Objeto y campo de 1 Objeto y campo de 1 Objeto y campo de
aplicación aplicación aplicación
1.1 Generalidades 1.1 Generalidades
1.2 Aplicación 1.2 Aplicación
2 Normas para consulta 2 Normas para consulta 2 Normas para consulta
3 Términos y definiciones 3 Términos y definiciones 3 Términos y definiciones
4 Sistema de gestión de 4 Requisitos del sistema 4 Sistema de gestión de

la calidad de gestión ambiental la seguridad de la
información
(continúa)
4.1 Requisitos generales 4.1 Requisitos generales 4.1 Requisitos generales
4.2 Creación y gestión

del SGSI
4.2.1 Creación del SGSI
4.4 Implementación y 4.2.2 Implementación y

operación operación del SGSI
8.2.3 Seguimiento 4.5.1 Seguimiento y 4.2.3 Supervisión y

y medición de medición revisión del SGSI
los procesos 4.2.4 Mantenimiento y
mejora del SGSI
8.2.4 Seguimiento
y medición
del producto
4.2 Requisitos de la 4.3 Requisitos de la
documentación documentación
4.2.1 Generalidades 4.3.1 Generalidades
4.2.2 Manual de
la calidad
4.2.3 Control de los 4.4.5 Control de los 4.3.2 Control de los
documentos documentos documentos
4.2.4 Control de los 4.5.4 Control de los 4.3.3 Control de registros
registros registros
5 Responsabilidad 5 Responsabilidad
de la dirección de la dirección
5.1 Compromiso 5.1 Compromiso
de la dirección de la dirección
5.2 Enfoque al cliente
5.3 Política de la calidad 4.2 Política ambiental
5.4 Planificación 4.3 Planificación
(continúa)
7. Correspondencia entre las Normas UNE-EN ISO 9001:2008, UNE-EN ISO 14001:2004 y UNE-ISO/IEC 27001:2007 99
5.5 Responsabilidad,
autoridad y
comunicación
6 Gestión de los recursos 5.2 Gestión de
los recursos
6.1 Provisión de recursos 5.2.1 Provisión de
los recursos
6.2 Recursos humanos
6.2.2 Competencia, 4.4.2 Competencia, 5.2.2 Concienciación,

formación y toma formación y toma formación y
de conciencia de conciencia capacitación
6.3 Infraestructura
6.4 Ambiente de trabajo
8.2.2 Auditoría interna 4.5.5 Auditoría interna 6 Auditorías internas

del SGSI
5.6 Revisión por 4.6 Revisión por 7 Revisión del SGSI por
la dirección la dirección la dirección
5.6.1 Generalidades 7.1 Generalidades
5.6.2 Información 7.2 Datos iniciales

de entrada para de la revisión
la revisión
5.6.3 Resultados de 7.3 Resultados de
la revisión la revisión
8.5 Mejora 8 Mejora del SGSI
8.5.1 Mejora continua 8.1 Mejora continua
8.5.2 Acción correctiva 4.5.3 No conformidad, 8.2 Acción correctiva

acción correctiva
y acción preventiva
8.5.3 Acción preventiva 8.3 Acción preventiva

8 Caso práctico:
modelo de SGSI
8.1. Documentación de la política de seguridad

8.1.1. Política de seguridad de la información
En este apartado se debería hacer relación de los puntos que describan la política
de seguridad de la información de la empresa. Esta política debe estar aprobada por
la dirección de la empresa y debería ser revisada anualmente.
8.1.2. Definición del SGSI

Este apartado recoge el ámbito de aplicación y los límites del SGSI teniendo en
cuenta las actividades que realiza la organización, los servicios y productos que
oferta, el equipamiento con el que cuenta y las restricciones legales o reglamen-
tarias que sean aplicables a su actividad.
8.1.2.1. Conceptos generales

Definición de los conceptos más básicos de la seguridad:
• Disponibilidad.
• Confidencialidad.
• Integridad.
• Seguridad de la Información.
• Sistemas de Gestión de Seguridad de la Información.
También se pueden incluir las definiciones de conceptos utilizadas internamente en

la empresa.
8.1.2.2. Campo de aplicación de la política de seguridad

Descripción de a quién y a qué afecta la política de seguridad, ya que puede ser al
conjunto de la organización, a una parte o servicio, a todos los empleados, a los
contratistas, etc.
Se puede incluir un organigrama de la organización.
8.1.2.3. Alcance del sistema

Descripción de los servicios de venta y alquiler de vehículos terrestres tanto a
empresas como a particulares.
8.1.2.4. Infraestructura informática

Inclusión de un diagrama de red de la organización que muestre de manera
esquemática la infraestructura informática con la que se cuenta.
8.1.2.5. Objetivos de la política de seguridad

Breve descripción de qué se pretende conseguir con esta política:
• Definir el SGSI.
• Mejorar la confianza de los clientes y usuarios en las actividades.
• Reducir el riesgo de posibles pérdidas de información, reaccionar adecuada-
mente ante cualquier tipo de incidencia, etc.
8.1.2.6. Requisitos legales

Detalle de las leyes aplicables en relación con la seguridad de la información corres-
pondiente.
8.1.2.7. Revisiones y auditorías

Establecimiento de la metodología y periodicidad de la revisión de la política de
seguridad y de las auditorías de la misma.
8.1.2.8. Compromiso de la dirección

Descripción clara y directa de cómo la dirección está detrás de la definición y la
implementación del SGSI.
8. Caso práctico: modelo de SGSI 103
8.1.3. Organización e infraestructura de seguridad

Este apartado recoge quién y cómo se va a hacer cargo de la seguridad en la
organización.
8.1.3.1. Responsabilidades
En esta sección se describirían las responsabilidades de los distintos roles en materia

de seguridad de la información que existen en una organización.
8.1.3.1.1. Dirección
Breve definición de las responsabilidades de la dirección:
• Proporcionar recursos al SGSI.
• Aprobar los riesgos residuales.
• Realizar la revisión por la dirección.
• Etc.
8.1.3.1.2. Responsable de seguridad

Breve definición de sus responsabilidades:
• Gestionar y mantener el sistema de seguridad de la información.
• Proporcionar ayuda y soporte a los usuarios.
• Proteger la información y los sistemas adecuadamente protegidos.
• Etc.
8.1.3.1.3. Propietario de los activos

• Definir si el activo está afectado por la Ley de Protección de Datos y apli-
carle en su caso los procedimientos correspondientes.
• Definir quién, cómo y cuándo se puede tener acceso a la información.
• Clasificar la información y la función a desempeñar.
• Asegurarse de que el activo cuenta con el mantenimiento adecuado.
• Etc.
8.1.3.1.4. Responsable de sistemas

• Administrar y gestionar las cuentas de los usuarios.
• Asegurarse de que sólo las personas autorizadas a tener acceso cuentan con él.
• Asegurarse de que los sistemas tienen los niveles de disponibilidad requeridos
por la organización o incluir los aspectos de seguridad que se apliquen en los
requisitos para nuevos desarrollos.
8.1.3.1.5. Personal
Breve definición de las responsabilidades del personal:
• Cómo conocer y aplicar las directrices de la política de seguridad.
• Notificar las incidencias de seguridad.
• Etc.
8.1.3.2. Responsabilidades asociadas a los activos

Para gestionar correctamente los activos el responsable de seguridad debe crear y
mantener un inventario actualizado de los activos importantes, registrando quién es
el propietario del activo, su ubicación física y el valor que tiene para la organización.
8.1.4. Clasificación de la información

La información de la organización debe clasificarse según su nivel de confidenciali-
dad o sensibilidad para tomar las medidas de seguridad adecuadas a este nivel de
criticidad: información confidencial, restringida, interna, pública, etc.
8.1.5. Análisis de riesgos de seguridad

Definición de la necesidad de realizar el análisis de riesgos y los beneficios que
comporta.
8.1.5.1. Análisis de riesgos

Descripción de las tareas a realizar para el análisis de riesgos.
8.1.5.2. Gestión de riesgos

Descripción de las tareas a realizar para la gestión de riesgos.
8.2. Documentación del inventario de activos

En este apartado se describe la manera de documentar el listado y la valoración de
los activos de información con los que cuenta la organización de acuerdo con los
requisitos de la norma.
8.2.1. Procesos de negocio

Un ejemplo podría ser:
Proceso de negocio Descripción
Gestión de pagos y cobros,

Administración
pago de impuestos, etc.
Alquiler y venta Servicios de alquiler y venta de vehículos
Comercial Captación de clientes
Recursos Humanos Nóminas, altas y bajas de personal
8.2.2. Inventario de activos

Nombre Descripción Categoría Ubicación Propietario
Aplicaciones Office, NominaPlus, Responsable

Aplicaciones Servidor
comerciales FacturaPlus, etc. de informática
Servidor que contiene Responsable
Servidor Hardware Sala del servidor
los datos de la empresa de informática
Puestos Responsable
PC de los usuarios Hardware Oficinas
de usuario de informática
Clientes Datos de clientes Datos Servidor/Archivo Director General
Contabilidad Datos de contabilidad Datos Servidor Director financiero
Laboral Datos de personal Datos Servidor Director RRHH

Personal propio
Personal Personal Oficinas Director General
de Cibercar
8.2.3. Relación proceso de negocio-activos

Proceso Alquiler Recursos

Administración Comercial
Activos y venta humanos
Aplicaciones
X X X X
comerciales
Servidor X X X X
Puestos de usuario X X X X
Clientes X X X
Contabilidad X
Laboral X
Personal X X X X
8.2.4. Valoración de activos

Se valorarán los activos según una escala de puntuación de 0 (no aplicable/sin valor)
a 4 (mucho valor). La valoración total será la suma aritmética de los cuatro valores.
Activo Confidencialidad Integridad Disponibilidad Total
Aplicaciones
1 2 4 7
comerciales
Servidor 2 3 4 9
Puestos de usario 1 2 3 6
Clientes 4 4 4 12
Contabilidad 2 4 3 9
Laboral 4 4 3 11
Personal 1 2 3 6
8.3. Documentación del Análisis de riesgos

El nivel de riesgo vendrá dado por el valor más alto para cada activo de:
Nivel de amenaza × Nivel de vulnerabilidad × Nivel de impacto
Tanto el nivel de vulnerabilidad como el nivel (o probabilidad) de amenaza se valo-
ran de 0 a 3 (no aplicado, bajo, medio y alto).
8.3.1. Valoración del riesgo por activos

Aplicaciones comerciales
Impacto Nivel de Nivel

Amenaza Vulnerabilidad
(valor del activo) amenaza de riesgo
Fuego 7 1 0 0
Robo 7 1 1 7
Error de
7 1 3 21
mantenimiento
Fallo de software 7 3 2 42
Fallo de
7 2 1 14
comunicaciones
Errores de usuario 7 2 2 28
Servidor
Fuego 9 1 3 27
Robo 9 2 3 54
Error de
9 2 3 54
mantenimiento
Fallo de
9 1 1 9
comunicaciones
Puestos de usuario
Fuego 9 1 3 27
Robo 9 2 3 54
Error de
9 2 3 54
mantenimiento
Fallo de
9 1 0 0
comunicaciones
Clientes

Fuego 12 1 1 12
Robo 12 2 2 48
Error de
12 1 2 12
mantenimiento
Fallo de
12 1 1 12
comunicaciones
Contabilidad

Fuego 9 1 1 9
Robo 9 2 2 36
Error de
9 1 1 9
mantenimiento
(continúa)

Fallo de
9 1 2 18
comunicaciones
Laboral

Fuego 11 1 1 11
Robo 11 2 2 44
Error de
11 1 1 11
mantenimiento
Fallo de
11 1 2 22
comunicaciones
Personal

Fuego 6 1 3 18
Robo 6 0 0 0
Error de
6 0 0 0
mantenimiento
Fallo de
6 0 0 0
comunicaciones
8.3.2. Tratamiento del riesgo

Activo Riesgo Tratamiento
Aplicaciones comerciales 42 Se asume el riesgo
Servidor 54 Se asume el riesgo
Puestos de usario 54 Se asume el riesgo
Clientes 108 Se asume el riesgo
Contabilidad 81 Se asume el riesgo
Laboral 99 Se asume el riesgo
Personal 44 Se asume el riesgo
El valor de riesgo aceptable en este caso se establecería en 50, por lo que se tratarían
los que igualen o superen esta cifra y se asumirían los que estuvieran por debajo. De
todas formas, se aplicarían los controles mínimos establecidos por la norma.
8.4. Documentación de la Gestión de riesgos

Con la aplicación de controles se reducirían tanto el nivel de amenaza como el de
vulnerabilidad o posiblemente los dos. Consecuencia de todo ello sería la disminu-
ción del nivel de riesgo.
8.4.1. Valoración del riesgo por activos

Aplicaciones comerciales
Impacto Nivel de Riesgo Riesgo
(valor del activo) amenaza inicial residual
Fuego 7 1 0 0 0
Robo 7 1 1 7 7
Error de
7 1 3 21 14
mantenimiento
(continúa)

Fallo de software 7 2 2 42 28
Fallo de
7 2 1 14 14
comunicaciones
Errores de usuario 7 1 2 28 14
Servidor
Fuego 9 1 2 27 18
Robo 9 2 2 54 36
Error de
9 2 2 54 36
mantenimiento
Fallo de
9 1 1 9 9
comunicaciones
Puestos de usuario
Fuego 9 1 2 27 18
Robo 9 2 2 54 36
Error de
9 2 2 54 36
mantenimiento
Fallo de
9 1 0 0 0
comunicaciones
Clientes
Fuego 12 1 1 12 12
Robo 12 1 2 48 24
Error de
12 1 1 12 12
mantenimiento
Fallo de
12 1 1 12 12
comunicaciones
Contabilidad
Fuego 9 1 1 9 9
Robo 9 1 1 36 9
Error de
9 1 1 9 9
mantenimiento
Fallo de
9 1 2 18 18
comunicaciones
Laboral
Fuego 11 1 1 11 11
Robo 11 1 1 44 11
Error de
11 1 1 11 11
mantenimiento
Fallo de
11 1 2 22 22
comunicaciones
Personal
Fuego 6 1 2 12 12
Robo 6 0 0 0 0
Error de
6 0 0 0 0
mantenimiento
Fallo de
6 0 0 0 0
comunicaciones
8.5. Documentación de la Declaración de

aplicabilidad
Según lo exigido por la norma, se deben documentar los controles seleccionados,
su aplicación, así como aquellos que no han sido seleccionados y los motivos por
los que han sido rechazados. Toda esta información es la que se recoge en la
declaración de aplicabilidad.
8.5.1. Controles aplicados

Sección Objetivo Control Estado Justificación
A.5 Política de seguridad
5.1.1 Documento de política

Exigido por
de seguridad de la Aplicar
Política de UNE/ISO-IEC 27001
información
A.5.1 seguridad de la
información 5.1.2 Revisión de la política
Exigido por
de seguridad de la Aplicar
UNE/ISO-IEC 27001
información
A.6 Organización de la seguridad de la información
6.1.1 Compromiso de la
Exigido por
Dirección con la seguridad Aplicar
UNE/ISO-IEC 27001
de la información
6.1.2 Coordinación de la Exigido por

Aplicar
seguridad de la información UNE/ISO-IEC 27001
6.1.3 Asignación de
Exigido por
responsabilidades en seguri- Aplicar
UNE/ISO-IEC 27001
dad de la información
Organización La autorización para la
A.6.1 6.1.4 Proceso de autorización
interna compra e instalación de
para las instalaciones
Aplicado nuevos equipos o software
de procesamiento de la
se gestiona mediante el
Información
procedimiento de compras
6.1.5 Acuerdos de Se firman con empleados
Aplicado
confidencialidad y contratistas
No se considera que este
6.1.6 Contacto con las No control ayude a reducir
autoridades aplicar el riesgo de los activos
identificados
(continúa)
Se mantienen contactos con

6.1.7 Contacto con grupos de
Aplicado foros especializados, listas
interés especial
de correo, revistas, etc.
Organización
A.6.1 Se considera que el coste
interna 6.1.8 Revisión independiente
No de implementación de este
de la seguridad de la
aplicar control supera al beneficio
información
que se obtendría
Se considera que el coste
6.2.1 Identificación de
riesgos relacionados
con terceras partes
que se obtendría
6.2.2 Gestión de la seguridad al No control ayude a reducir
A.6.2 Terceras partes
tratar con clientes aplicar el riesgo de los activos
identificados
6.2.3 Gestión de la seguridad
en contratos con terceras
partes
que se obtendría
A.7 Gestión de activos
Exigido por
7.1.1 Inventario de activos Aplicar
UNE/ISO-IEC 27001
Responsabilidades Exigido por
A.7.1 7.1.2 Propiedad de los activos Aplicar
de los activos UNE/ISO-IEC 27001
7.1.3 Utilización aceptable de Se marcarán unas pautas
Aplicar
los activos de utilización de los activos
Exigido por
7.2.1 Guías de clasificación Aplicar
Clasificación de UNE/ISO-IEC 27001
A.7.2
la información 7.2.2 Etiquetado y tratamiento de Exigido por
Aplicar
la información UNE/ISO-IEC 27001
A.8 Seguridad de la gestión de los recursos humanos

En el análisis de riesgos
No
8.1.1 Roles y responsabilidades no se han detectado
aplicar
amenazas en este sentido
Antes de la Se controla la selección de
A.8.1 8.1.2 Análisis y selección Aplicado
contratación personal
8.1.3 Términos y condiciones Se documentan en los
Aplicado
de empleo contratos
(continúa)
8.2.1 Responsabilidades de los No
no se han detectado
gestores aplicar
Según el análisis de riesgos,
8.2.2 Concienciación, formación
una amenaza habitual es
A.8.2 Durante el empleo y entrenamiento sobre la Aplicar
la falta de formación en
seguridad de la información
materia de seguridad
No
8.2.3 Proceso disciplinario no se han detectado
aplicar
8.3.1 Responsabilidades No
no se han detectado
ante la finalización aplicar
Cuando el empleado cesa
Finalización o 8.3.2 Devolución de activos Aplicado devuelve todos los activos
A.8.3
cambio de empleo que poseía
Para evitar los accesos a
8.3.3 Retirada de los derechos la información de personal
Aplicado
de acceso que ya no pertenece a la
organización
A.9 Seguridad física y del entorno
Existen controles físicos de
entrada proporcionales
9.1.1 Perímetro de seguridad física Aplicado
al tamaño y actividad
de la organización
Existen controles físicos de
entrada proporcionales
9.1.2 Controles físicos de entrada Aplicado
al tamaño y actividad
de la organización
Se han asegurado las
A.9.1 Áreas seguras oficinas de acuerdo a la
9.1.3 Asegurar las oficinas, salas legislación vigente y
Aplicado
e instalaciones proporcionalmente al
tamaño y actividad de
la organización
Se han asegurado las
oficinas de acuerdo a la
9.1.4 Protección contra amenazas legislación vigente y
Aplicado
externas y ambientales proporcionalmente al
tamaño y actividad de
la organización
(continúa)
No No existen áreas
9.1.5 Trabajo en áreas seguras
aplicar consideradas seguras
A.9.1 Áreas seguras Se establece una zona
9.1.6 Áreas de acceso público, de
Aplicado en recepción para carga
carga y de distribución
y descarga
Los equipos están en áreas
9.2.1 Emplazamiento y protección controladas por personal
Aplicado
de los equipos autorizado o en salas
cerradas con llave
Los servidores cuentan
9.2.2 Servicios de soporte Aplicado
con SAI
La instalación del
9.2.3 Seguridad del cableado Aplicado
cableado es segura
9.2.4 Mantenimiento de los Existe un mantenimiento
Aplicado
Seguridad de equipos interno de los equipos
A.9.2
los equipos
Cuentan con ID y
9.2.5 Seguridad de los equipos
Aplicado contraseña para acceder
fuera de las instalaciones
a ellos
Los equipos descartados
9.2.6 Descarte o re-utilización se formatean e instalan de
Aplicado
seguros de los equipos nuevo cuando se ponen
de nuevo en servicio
Existe un procedimiento
9.2.7 Extracción de elementos de
Aplicado de autorización aunque
la propiedad
no está documentado
A.10 Gestión de las comunicaciones y las operaciones
10.1.1 Procedimientos operativos Exigido por

Aplicar
documentados UNE/ISO-IEC 27001
Los cambios se realizarán
10.1.2 Gestión de cambios Aplicar
de manera controlada
Procedimientos En circunstancias
A.10.1 operativos y aconsejables, los equipos
responsabilidades 10.1.3 Separación de tareas Aplicado
se encuentran aislados
del resto
10.1.4 Separación de las No se considera que este
No
instalaciones de desarrollo, control ayude a reducir los
aplicar
prueba y operación riesgos detectados
(continúa)

No de implementación de
10.2.1 Suministro del servicio
aplicar este control superaría al
beneficio que se obtendría
Gestión de Se considera que el coste
10.2.2 Revisión y monitorización
los servicios No de implementación de
A.10.2 de servicios de terceras
suministrados aplicar este control superaría al
partes
por terceros beneficio que se obtendría
10.2.3 Gestión de cambios a los No de implementación de
servicios de terceras partes aplicar este control superaría al
Se haría un estudio
periódico de las
Planificación 10.3.1 Gestión de la capacidad Aplicado necesidades presentes y
A.10.3 y aceptación futuras de capacidad
del sistema del sistema informático
Hasta ahora se hace de
10.3.2 Aceptación del sistema Aplicado
una manera informal
10.4.1 Controles contra código Se dispone de sistemas
Aplicado
malicioso antivirus y anti spyware
Protección frente a
A.10.4 código malicioso No se considera que este
y código móvil 10.4.2 Controles contra No control ayude a reducir
código móvil aplicar el riesgo de los activos
identificados
Necesario para evitar
Copias de 10.5.1 Respaldo de la
A.10.5 Aplicado riesgos de pérdida de
seguridad información
información
Cada departamento
dispondría de una firma
10.6.1 Controles de red Aplicado digital para usarla en
Gestión de caso de transmisión de
A.10.6 la seguridad información sensible
de la red Se considera que el coste
10.6.2 Servicios de seguridad No de implementación de
de redes aplicar este control superaría al
Necesario para evitar
riesgos de pérdida de
Gestión 10.7.1 Gestión de soportes
A.10.7 Aplicar información. Exigido
de soportes removibles
por la LOPD para datos
de carácter personal
(continúa)
10.7.2 Descarte de medios

Existirían trituradoras
(de almacenamiento de Aplicado
de papel
la información)
10.7.3 Procedimientos de Dado el resultado del aná-
Gestión tratamiento de la Aplicar lisis de riesgos, convendría
A.10.7
de soportes información aplicar este tipo de control
No se considera que la
10.7.4 Seguridad de la
No aplicación de este control
documentación
aplicar ayudaría a reducir los
del sistema
riesgos detectados
10.8.1 Políticas y procedimientos
de intercambio de la
información
No No se realizarían
10.8.2 Acuerdos de intercambio
aplicar intercambios
No se extraerían soportes
No
Intercambio 10.8.3 Soportes físicos en tránsito con información relevante
A.10.8 aplicar
de información fuera de las oficinas
Dado el resultado del
análisis de riesgos, se
10.8.4 Mensajería electrónica Aplicar
creería conveniente
aplicar este tipo de control
10.8.5 Sistemas de información No control ayudaría a reducir
de negocio aplicar el riesgo de los activos
identificados
No No se realizaría comercio
10.9.1 Comercio electrónico
aplicar electrónico
Servicios de No No se realizarían
10.9.2 Transacciones en línea
A.10.9 comercio aplicar transacciones en línea
electrónico Dado el resultado del
10.9.3 Información pública análisis de riesgos,
Aplicar
disponible se creería conveniente
Se controlarían los accesos
10.10.1 Registro de auditoría Aplicado
a algunas aplicaciones
A.10.10 Seguimiento Dado el resultado del

10.10.2 Uso del sistema de análisis de riesgos,
Aplicar
monitorización se creería conveniente
(continúa)
Dado el resultado
del análisis de riesgos,
10.10.3 Protección de la
Aplicar se creería conveniente
información de log
aplicar este tipo de
control
El tamaño de la
10.10.4 Logs del operador y No organización haría que
del administrador aplicar este control no fuera
necesario
A.10.10 Seguimiento
Dado el resultado
10.10.5 Registro de fallos Aplicar se creería conveniente
aplicar este tipo de
control

No control ayudaría a reducir
10.10.6 Sincronización horaria
aplicar el riesgo de los activos
identificados
A.11 Control de accesos
Los usuarios contarían

Requisitos del con la información
A.11.1 negocio para 11.1.1 Política de de accesos Aplicado pertinente respecto
el de accesos a los permisos de
accesos que poseen
El movimiento de
alta y baja de usuarios
11.2.1 Registro de usuarios Aplicar en los sistemas haría
indispensable este
control
Se asignarían permisos
Gestión 11.2.2 Gestión de privilegios Aplicar a nivel del sistema
A.11.2 de accesos de operativo
los usuarios Dado el resultado del
11.2.3 Gestión de contraseñas análisis de riesgos,
Aplicar
de usuarios se creería conveniente
Se haría bajo petición del
11.2.4 Revisión de derechos de
Aplicado responsable directo
usuario
del usuario
(continúa)
Sería necesario para

11.3.1 Uso de contraseñas Aplicar proteger el acceso a
la información
Se consideraría necesario
Responsabilidades 11.3.2 Equipamiento desatendido
A.11.3 Aplicar para evitar accesos
del usuario por el usuario
no autorizados
Se evitarían así
11.3.3 Política de mesas y
Aplicar filtraciones de información
pantallas “limpias”
indeseadas
Dado el resultado
11.4.1 Política de uso de
servicios de red
aplicar este tipo
de control
Dado el resultado
11.4.2 Autenticación de usuarios
para conexiones externas
aplicar este tipo
de control

11.4.3 Identificación de equipos No control ayude a reducir
en las redes aplicar el riesgo de los activos
identificados
Control de
A.11.4 11.4.4 Protección del puerto
acceso a la red
remoto de configuración Aplicado Se controlaría este acceso
y diagnóstico
No control ayude a reducir
11.4.5 Segmentación de rede
identificados

11.4.6 Control de conexión No control ayude a reducir
de red aplicar el riesgo de los activos
identificados

11.4.7 Control de
No control ayude a reducir
reencaminamiento
de redes
identificados
(continúa)
Se controlaría que el
11.5.1 Procedimientos seguros de acceso a los sistemas de
entrada a los sistemas Aplicado información no muestre
de información información y se limitaría el
número de intentos fallidos
11.5.2 Identificación y Cada usuario contaría con
Aplicado
autenticación de usuarios una ID y una contraseña
Cada usuario tendría su

contraseña. Este control
Control de acceso 11.5.3 Sistemas de gestión sería necesario para evitar
Aplicar
A.11.5 a los sistemas de contraseñas accesos que pudieran
en operación suplantar la identidad
de algún usuario
11.5.4 Uso de utilidades Se restringiría el uso de

Aplicar
del sistema estas utilidades.
11.5.5 Finalización del tiempo No
control ayudaría a reducir
de sesión aplicar
los riesgos detectados
11.5.6 Limitación en el tiempo No
control ayudaría a reducir
de conexión aplicar
los riesgos detectados
Sólo se daría acceso
11.6.1 Restricciones de acceso a la información que
Aplicado
a la información necesitara el usuario
Control de acceso para realizar su trabajo
A.11.6 a las aplicaciones
y la información No se considera que este
11.6.2 Aislamiento de sistemas No control ayudaría a reducir
sensibles aplicar el riesgo de los activos
identificados

11.7.1 Comunicaciones e No control ayudaría a reducir
informática móvil aplicar el riesgo de los activos
Informática móvil identificados
A.11.7
y teletrabajo Se considera que el coste
11.7.2 Teletrabajo
8.6. Documentación del Plan de tratamiento

del riesgo
Una vez establecidos los controles a implementar y el riesgo que se pretende
reducir con ellos, hay que definir las tareas que se van a llevar a cabo, los plazos y
los recursos asignados. Todo ello debe documentarse en este plan.
8.6.1. Objetivo
Descripción de los objetivos del plan de tratamiento del riesgo.
8.6.2. Alcance
Definición del periodo al que va afectar el plan de tratamiento del riesgo.
8.6.3. Responsabilidades
El responsable de seguridad se encargará de la ejecución y supervisión de las distintas
actividades.
La dirección debería revisar y aprobar el plan y los objetivos marcados en el plan.
8.6.4. Tareas
Un ejemplo podría ser: Mes 10
Mes 11
Mes 12
Mes 1
Mes 2
Mes 3
Mes 4
Mes 5
Mes 6
Mes 7
Mes 8
Mes 9
ID Actividades
1 Implementación del SGSI

Aprobación de la política de seguridad
Aprobación del inventario de activos
Aprobación del análisis de riesgos y los riesgos
residuales
Aprobación del documento de aplicabilidad
Aprobación del plan de tratamiento del riesgo
Aprobación de procedimientos
Publicación de documentos
Impartir formación
Implementar procedimientos
2 Auditoría interna
3 Revisión del SGSI
4 Auditoría de certificación
8.6.5. Seguimiento
Verificación del cumplimiento del plan en el plazo acordado por el responsable de
seguridad. En el caso de que produzcan desviaciones, se deberían tomar las medi-
das oportunas para corregirlas y, en caso necesario, se debería actualizar el plan para
reflejar los cambios.
8.6.6. Objetivos e indicadores

Frecuencia
Indicador Métrica Fórmula Responsable Fuente
de recogida
Mejorar la (Número de accesos

Porcentaje
efectividad del no autorizados / Responsable Registro
de accesos Trimestral
control de accesos Número total de de sistemas de accesos
no autorizados
en un 5% accesos) × 100
Suma total de
Mejorar la
Valoración de valoraciones totales
efectividad de Responsable Registros
la formación en de cada asistente / Trimestral
la formación de seguridad de formación
sí del personal Número de
en un 5%
asistencias
(Número de
Porcentaje de
incidencias
las incidencias
de seguridad Responsable Registros
de seguridad Trimestral
debidas a fallos del de sistemas de incidencias
debidas a fallos
usuario / Número de
del usuario
incidencias) × 100
(Número de equipos
Mejorar la Porcentaje de que pasaron su
efectividad de los los equipos mantenimiento en Responsable Registro de
Trimestral
mantenimientos correctamente fecha / Número de de sistemas mantenimientos
en un 5% mantenidos equipos totales de la
empresa) × 100
(Número de
Porcentaje incidencias
de incidencias de seguridad
Responsable Registro
debidas a debidas a fallos Trimestral
de sistemas de incidencias
fallos de del mantenimiento /
mantenimiento Número de
incidencias) × 100
(continúa)
Frecuencia
Indicador Métrica Fórmula Responsable Fuente
de recogida
(Número de ataques Registro

Reducir un 5% Porcentaje detectados / de incidencias
Responsable
los ataques con de ataques Número de ataques Trimestral
de sistemas Registros
éxito a los sí con éxito con impacto
en los sí) × 100 del sistema
(Número de
incidencias Test de
Porcentaje de intrusión
de seguridad Responsable
incidencias por Trimestral
debidas a ataques / de sistemas Monitorización
ataques a los sí
Número de de los sistemas
incidencias) × 100
(Número de horas
Mejorar la sin disponibilidad /
Porcentaje de Responsable Registros
disponibilidad Número de horas Trimestral
disponibilidad de sistemas del sistema
el 5% disponibilidad
necesaria) × 100
8.7. Documentación del Procedimiento de

auditorías internas
8.7.1. Objetivo
El presente procedimiento debería dar cumplimiento a la Norma UNE-ISO/IEC
27001 en lo relativo a las actividades, criterios y responsabilidades para la realización
de auditorías internas del sistema de gestión de seguridad de la información.
8.7.2. Alcance
Este procedimiento se debería aplicar a todos los servicios incluidos dentro del
alcance del sistema de gestión de seguridad de la información.
El responsable de seguridad debe definir e implementar un sistema de auditorías
internas que incluya la preparación, realización, registro y seguimiento de las mismas.
Para programar su frecuencia de realización ha de tenerse en cuenta que se debe
auditar por completo el conjunto del SGSI cada tres años. Lo más recomendable
es hacer una anualmente.
El personal que realice la auditoría no tendrá en ningún caso responsabilidad

directa sobre el área a auditar.
8.7.4. Desarrollo
La manera de llevar a cabo las tareas objeto de este procedimiento son detalladas a
continuación.
8.7.4.1. Cualificación del personal

El personal encargado de la ejecución de las auditorías debería tener las siguientes
características:
• Preparación profesional necesaria en las metodologías que hay que emplear.
• Conocimientos generales adecuados, tanto del ambiente empresarial como
del SGSI.
• Carisma personal para transmitir credibilidad.
• Estar convenientemente respaldado por la autoridad empresarial.
• Debe ser elegido de manera que se garantice la independencia en relación
con las actividades involucradas.
8.7.4.2. Planificación de la auditoría

Las auditorías pueden hacerse sobre la totalidad del SGSI implicando a toda la
organización, considerándose en estos casos como global. O bien, podría hacerse
sobre una parte en concreto, implicando a un determinado departamento, contrato,
sector, etc., considerándose entonces como parcial.
El responsable de seguridad debería realizar anualmente un plan de auditorías que
incluya las fechas y el auditor de cada auditoría. Este plan será aprobado por la
dirección y el responsable de seguridad lo distribuirá a todos los departamentos y
auditores afectados.
Con independencia de lo anterior, se deberían realizar auditorías internas cuando:
• La amplitud o profundidad de las modificaciones al SGSI así lo aconsejen.
• Parcialmente, cuando se implementen procedimientos nuevos o se detecten
no conformidades en las áreas afectadas.
8.7.4.3. Preparación de la auditoría
Las auditorías se llevan a cabo mediante una lista de comprobación que, en cada
caso, debe ser elaborada por el auditor bajo la supervisión del responsable de
seguridad y que será enviada al departamento afectado.
El auditor debe establecer el alcance de la auditoría, las actividades a auditar, los
documentos aplicables y la lista de comprobación. Basándose en esta información,
confeccionar la lista de comprobación que debería ser revisada por el responsable
de seguridad y enviada, con suficiente antelación, al departamento que va a ser
auditado. Además, en el caso de modificarse la inicialmente programada, en dicha
lista se incluiría la nueva fecha prevista de realización de la auditoría y que estaría
acordada entre los auditores y el área a auditar.
8.7.4.4. Realización de la auditoría
El primer paso en la auditoría debería ser una reunión donde se confirme el alcance
de la misma, su secuencia y donde se discuta aquellos puntos que cualquiera de las
partes crea conveniente.
A continuación, se procedería a llevar a cabo la auditoría en sí mediante el uso de
la lista de comprobación, anteriormente realizada, como guía de trabajo. Se exami-
naría simultáneamente la evidencia objetiva para comprobar que se cumplen los
requisitos y los controles aplicables.
En caso de que la auditoría se realizara como consecuencia de la existencia de no
conformidades, se profundizaría a fin de identificar las causas y efectos y poder
definir la acción correctiva/preventiva requerida.
Terminada la auditoría, el equipo auditor redactaría un informe de resultados, iden-
tificando de manera clara y concreta las no conformidades detectadas. Cuando haya
no conformidades importantes, se debería programar la fecha de la siguiente audi-
toría para verificar su eliminación.
El responsable del departamento afectado por la no conformidad detectada o en su
caso el comité de seguridad, elaborará la acción correctiva/preventiva a llevar a
cabo, que será aprobada por el responsable de seguridad. El responsable del área
afectada por la acción correctiva/preventiva deberá tomar las medidas necesarias
para aplicar totalmente las acciones correctivas y preventivas dentro del plazo seña-
lado en el informe.
Los informes de auditoría serán archivados por el responsable de seguridad y se
enviarán copias a dirección y al responsable del área auditada.
El cierre de la acción correctiva/preventiva se realizará una vez que, tanto el respon-

sable del área afectada como los auditores internos, hayan comprobado su efectivi-
dad. En el apartado correspondiente del impreso de la acción correctora, se dejará
constancia de dichas comprobaciones con lo que se considerará la acción
correctiva/preventiva cerrada.
8.7.5. Requisitos de documentación

Los documentos asociados a este procedimiento son:
• Plan de auditorías.
• Lista de comprobación.
• Informes de auditoría.
8.7.6. Referencias
Los documentos de referencia para la realización de este procedimiento son:
• Norma UNE-ISO/IEC 27001.
• Norma UNE-ISO/IEC 17799.
• Procedimientos de seguridad.
• Objetivos de seguridad.
• Resultados de otras auditorías: anteriores auditorías internas y externas del
SGSI, auditorías de la LOPD, tests de intrusión, etc.
• Revisión del sistema de gestión.
8.7.7. Anexos
• Lista de comprobación de auditoría (véase la figura 8.1).
• Informe de auditoría (véase la figura 8.2).
• Plan de auditorías internas (véase la figura 8.3).
Departamento Auditoría de calidad N.o Fecha
Cuestiones a aplicar:
• Verificación del cumplimiento de las no conformidades detectadas en anteriores auditorías.
• Revisión de documentación existente en el puesto.
• Cumplimiento del procedimiento (el que aplique al departamento).
• Verificación de registros.
• Cambios en la estructura y funcionamiento del departamento.
Observaciones
Auditor Jefe Dpto. afectado
Fecha Fecha
Figura 8.1. Lista de comprobación de auditoría

Número auditoría Fecha auditoría
Área/Proceso clave auditado
Auditor
Grupo auditor
Hallazgos detectados:
Requisito No
Hallazgos Observación
de la norma conformidad
Comentarios
Nombre Firma
Fecha
Elaborado por
Nombre Firma
Fecha
Revisa y aprueba
Figura 8.2. Informe de auditoría

N.o Departamento/Sección Fecha prevista Auditores
Figura 8.3. Plan de auditoría interna
8.8. Documentación del Procedimiento para las

copias de seguridad
8.8.1. Objetivo
El presente procedimiento general debería dar cumplimiento al control 10.5.1 de
la Norma UNE-ISO/IEC 17799 para asegurar la información de respaldo. Debería
definir la sistemática establecida para crear copias de seguridad de manera óptima y
que no sean obviadas por algún usuario del sistema.
8.8.2. Alcance
Debería estar dirigida a todos los equipos de proceso de información que realizan
copias de seguridad de la información principal.
Responsable Actividades
Administrador Se deberían definir:

del sistema • Todos los mecanismos necesarios para la correcta realización
de las copias de respaldo y recuperación.
• La realización de dichas copias según la normativa que ellos
mismos hayan definido.
8.8.4. Términos y definiciones

Equipos de proceso: cualquier equipo electrónico utilizado para procesar de
forma automática la información.
8.8.5. Procedimiento
Para asegurar que las copias de respaldo y recuperación son realizadas correcta-
mente según la normativa vigente y las definiciones establecidas por el adminis-
trador, se deberían establecer las siguientes medidas:
8.8.5.1. Realización de las copias de seguridad en servidores
La información que debería requerir copia de seguridad es:

• Documentación.
• Información del sistema.
• Páginas web.
• Bases de datos.
• Correos electrónicos.
Las copias de seguridad se deberían realizar periódicamente volcando la informa-

ción desde el servidor a un DVD que se debería almacenar de manera adecuada, en
un sitio protegido y controlado por el responsable correspondiente.
En el caso de que la información a guardar tuviera datos extremadamente confi-
denciales, ésta debería ser almacenada en una segunda ubicación diferente a la del
fichero principal haciendo para ello distintas copias y guardándolas en distintos
sitios bajo tutela del responsable correspondiente.
Si se produjeran fallos en la realización de la copia de respaldo, se deberá proceder a
realizarla de nuevo, bien de manera manual o bien automática con un nuevo soporte.
8.8.5.2. Rotación de los soportes de copias de seguridad y

recuperación en servidores
No se conveniente reutilizar los soportes de información. Cada semana se debería
utilizar un DVD diferente convenientemente identificado (contenido guardado en
él y fecha de realización).
Igualmente, se debería desechar y sustituir el soporte cuando se hayan encontrado
errores en la grabación del mismo. Todas estas altas y bajas de soportes deberán
quedar registradas de acuerdo a la sistemática definida en el “Procedimiento de
gestión de soportes”.
8.8.5.3. Recuperación de datos de servidores

La recuperación de datos de los servidores, así como del resto de equipamiento
informático, deberá ser llevada a cabo únicamente por los administradores del sis-
tema utilizando la copia de respaldo disponible más reciente o aquélla que sea más
adecuada a cada situación.
En el caso de que existan aplicaciones que lo permitan, puede utilizarse la opción
de la propia aplicación para restaurar los datos. De otra manera, su recuperación
consistirá en la reposición de los ficheros guardados en la copia de respaldo, copián-
dolos sobre la ubicación de los ficheros originales. En caso de ser necesario, se
grabarán los datos no incluidos en la copia de seguridad manualmente.
En caso de utilizar personal técnico externo no habitual para estas tareas, éste
deberá estar acompañado en todo momento del responsable de seguridad o del
personal correspondiente.
La recuperación de datos deberá registrarse como incidencia y quedar registrada de
acuerdo a la sistemática definida en el “Procedimiento de gestión de incidencias”.
8.8.5.4. Realización de copias de seguridad en los PC
La realización de las copias de respaldo de aquellos datos ubicados en los PC de

usuario consistirá en una copia extraída a un soporte externo cada vez que las modi-
ficaciones de la información sean relevantes.
De la misma manera que se ha detallado en el apartado 5.2, todas las altas y bajas
de soportes deberían quedar registradas de acuerdo a la sistemática definida en el
“Procedimiento de gestión de soportes”.
8.8.5.5. Recuperación de datos de los PC
La recuperación de datos consistirá en la reposición de los ficheros guardados en la

copia de respaldo, copiándolos sobre la ubicación de los ficheros originales.
8.8.6. Requisitos de documentación

• Inventario de equipos de proceso.
• Registro de simulaciones de recuperación de información.
• Inventario de soportes.
• Registro de incidencias.
8.8.7. Referencias
• UNE-ISO/IEC 17799.
• Manuales de funcionamiento y uso de los equipos electrónicos.
• Ley Orgánica de Protección de Datos.
8.8.8. Anexos
Registro de copias de seguridad (véase la figura 8.4).
Registro de copias de seguridad
Fecha de copia: ___ / ___ / ______ Hora: ___ : ___
Soporte
Tipo de soporte y número
Contenido
Servidor o equipo
Información almacenada
Almacenamiento
Medio
Responsable
Lugar
Autorización
Persona responsable
de la copia
Persona que autoriza
Observaciones
Firmas
Figura 8.4. Registro de copias de seguridad

9 Comprender el
Esquema Nacional
de Seguridad (ENS)
9.1. Generalidades del ENS

El ENS establece la política de seguridad en el ámbito de la administración electró-
nica. Para ello, se han definido unos principios básicos y unos requisitos mínimos
que se consideran imprescindibles para proteger adecuadamente unos servicios tan
críticos y sensibles como los que nos ocupan.
El alcance del ENS son los sistemas de información, los datos, las comunicaciones,
y los servicios electrónicos de cualquier Administración Pública (estatal, autonó-
mica o local), así como de las entidades dependientes de ellas que se utilicen para la
prestación de servicios electrónicos.
El Real Decreto 3/2010 pretende con su aplicación asegurar el acceso, la integri-
dad, la disponibilidad, la autenticidad, la confidencialidad, la trazabilidad y la con-
servación de los datos, las informaciones y los servicios utilizados en medios elec-
trónicos que se gestionan en las Administraciones Públicas.
Lógicamente, el ENS no se ha desarrollado sin consultar la normativa y legislación
que existen en el sector TIC a nivel internacional, por lo que muchos de los con-
ceptos que se manejan tienen similitudes y paralelismos con los que se han visto
anteriormente en esta publicación. Sin embargo, ha de tenerse en cuenta que las
normas son documentos voluntarios que las organizaciones adoptan con distintos
fines (mejorar su gestión, distinguirse en el mercado, etc.). En cambio, el ENS es
una obligación legal en el ámbito de la administración electrónica y no es opcional
para los organismos públicos que prestan estos servicios.
Como ejemplo de los paralelismos entre la Norma UNE-ISO/IEC 27001 y el ENS
se muestra la correspondencia que existe entre algunos de los requisitos de ambas
en la tabla 9.1.
Tabla 9.1. Correspondencias entre el ENS y la Norma UNE-ISO/IEC 27001
ENS Requisito UNE-ISO/IEC 27001
11 Política de seguridad 4.2.1.b)
12 Compromiso de la dirección 5.1.c) d)
13.1
Evaluación de riesgos 4.2.1.c) d) e)
13.2
13.3 Gestión de riesgos 4.2.1.f) g)
27.1 Documento de aplicabilidad 4.2.1.g)
14 - 15 Formación 5.2.2
34.1 Auditorías 4.2.3.e) - 6
26 Mejora continua 8.1
9.2. Principios básicos del ENS

El ENS señala unos principios básicos y unos requisitos mínimos que conducen a
la exigencia de la gestión continuada de la seguridad, para la que cabe aplicar un
sistema de gestión. Para satisfacerlos se puede aplicar un modelo de tipo PCDA
como el expuesto en la Norma UNE-ISO/IEC 27001. Los principios básicos esta-
blecidos en el ENS son los siguientes:
• Seguridad integral. Sin exigir expresamente que se desarrolle un sistema de
gestión, el ENS al reclamar que la seguridad sea un esfuerzo integral, impide
que se pretenda gestionar la misma mediante un plan formado por varias
medidas puntuales sin una visión global de los problemas de seguridad y su
importancia dentro de la organización. Con esto se evitan agujeros de segu-
ridad y utilizar recursos en aspectos que tal vez no lo necesiten.
• Gestión de riesgos. Es un aspecto que recoge cualquier método o modelo de
gestión de seguridad de la información, ya que sólo sabiendo los riesgos a
los que se está expuesto se pueden tomar decisiones informadas. Como los
9. Comprender el Esquema Nacional de Seguridad (ENS) 139
sistemas de información y su entorno están en constante cambio, es necesa-

rio mantener la evaluación de los riesgos actualizada.
• Prevención, reacción y recuperación. Establecer medidas de seguridad de dis-
tinto tipo es fundamental para conseguir el objetivo de seguridad integral.
Evidentemente, el primer paso para evitar problemas de seguridad es contar
con medidas preventivas (como por ejemplo, la instalación de un antivirus
como medida de prevención contra infecciones o el uso de sistemas de
autenticación para evitar accesos no autorizados). Sin embargo, a pesar del
cuidado que se ponga, los incidentes pueden suceder, por lo que es necesario
contar con medidas que permitan reaccionar adecuadamente y minimizar los
daños (por ejemplo, el uso de un sistema de monitorización de la red aler-
tará a los administradores si se produce un acceso no autorizado, y permitirá
tomar acciones para limitar el daño o incluso evitarlo). Asimismo, deben
existir medios para recuperarse de los daños ocasionados por un incidente.
Si, por ejemplo, la intrusión ha ocasionado la eliminación de un documento,
se debería contar con una copia de seguridad que permita recuperar los
datos.
• Líneas de defensa. El conjunto de medidas de seguridad elegidas tienen que
estar implementadas de modo que los sistemas de información cuenten con
distintos niveles de protección, de manera que un incidente vaya encon-
trando dificultades que le impidan hacer todo el daño del que serían capaces
(por ejemplo, para impedir accesos no autorizados a un servidor, se tendrá
un recinto en el que se ubique y donde el acceso al mismo esté controlado
con un registro de entradas y salidas, un mecanismo de autenticación del
acceso, tiempos limitados de conexión, un protocolo de actuación para
cerrar aquellos puertos que sean necesarios o cerrar segmentos de red, etc.).
Este enfoque está alineado con el objetivo de contar con una gestión de la
seguridad integral, y con tener distintos tipos de medidas de seguridad.
• Reevaluación periódica. Para mantener constante un nivel de seguridad
aceptable es necesario revisar continuamente que el nivel de riesgo no ha
variado y que las medidas de seguridad aplicadas funcionan según lo espe-
rado. Hay que realizar una revisión periódica de estos aspectos para ir
haciendo los ajustes necesarios y contar en todo momento con las medidas
de seguridad adecuadas y proporcionales a los sistemas de información y a
su entorno.
• Función diferenciada. La gestión de la seguridad de la información es una
tarea en la que están involucradas muchas personas que, dependiendo de su
perfil y funciones, tienen distintas prioridades. Para no comprometer la segu-
ridad, el ENS ha definido como principio básico que los responsables de la
información, del servicio y de la seguridad sean personas distintas. De esta

manera, cada responsable debe definir los requisitos que aplican a su infor-
mación y a su servicio, y el responsable de seguridad se encargará de aplicar
las acciones oportunas para satisfacer de la mejor manera posible todos esos
requisitos con los medios y las políticas disponibles.
9.3. Requisitos mínimos de seguridad del ENS

El ENS requiere que las organizaciones cuenten con una política formalmente
aprobada y se establezcan las directrices a seguir para gestionar la seguridad en la
organización. Dicha política tiene que reunir una serie de requisitos mínimos que
se detallan a continuación.
9.3.1. Organización e implementación del proceso

de seguridad
La gestión de la seguridad requiere que haya ciertas responsabilidades asignadas
que son fundamentales para que se desarrollen los trabajos correctamente, tales
como el responsable de seguridad, el responsable de la información y el de los
servicios o el comité de seguridad. Pero la responsabilidad de la seguridad de la
información es universal, cada persona debería ser responsable de la información
y de los servicios a los que tiene acceso.
La política debe contemplar todas estas responsabilidades y las líneas de actuación
que se deben observar. Además, debe ser publicada y difundida de manera que
todo el mundo la conozca y se pueda aplicar.
9.3.2. Análisis y gestión de los riesgos

La política recogerá el modo en el que se va a realizar el análisis y la gestión de los
riesgos que afectan a los sistemas de información de la organización. Para el análi-
sis se puede usar cualquier metodología internacionalmente aceptada.
En la práctica, la amplia difusión de la metodología MAGERIT y de PILAR, su
herramienta asociada, hacen que sean las más comúnmente utilizadas en la Admi-
nistración Pública española. Para la gestión de los riesgos se aplicarán medidas de
seguridad que sean proporcionales a los riesgos que se pretenden mitigar, debiendo
compensar en coste y esfuerzo su implementación.
9.3.3. Gestión de personal

El personal es una parte fundamental de los sistemas de información. Cada uno de
ellos tiene responsabilidades en materia de seguridad, acorde con el puesto desem-
peñado. La comunicación de estas responsabilidades, y una adecuada formación y
concienciación en materia de seguridad permitirán una correcta gestión de la
misma.
Además, tendrán que existir normas de seguridad y mecanismos para verificar que
se cumplen los preceptos marcados. Los usuarios estarán identificados en los siste-
mas de manera única para poder supervisar sus acciones y, si se diera el caso, poder
exigirles responsabilidades.
9.3.4. Profesionalidad
Las tareas que implica la gestión de la seguridad serán realizadas por personal cua-
lificado para ello, que deberán contemplar en ellas todo el ciclo de vida de los siste-
mas, desde su compra e instalación inicial hasta su retirada, pasando por su mante-
nimiento. Para ello, es importante que se reciba la formación necesaria que permita
realizar su labor de manera segura.
Cuando se contraten servicios de seguridad externos, se deberá acreditar que dichos
servicios tienen el nivel de seguridad requerido por los sistemas de la entidad.
9.3.5. Autorización y control de los accesos

Uno de los primeros asuntos a tratar cuando se trata de seguridad es la definición
de la política que se va a seguir para autorizar accesos, es decir, qué se va permitir a
cada usuario y cuáles van a ser los criterios para la designación de los permisos. La
recomendación es autorizar el acceso a los servicios y a la información en función
de la necesidad de cada puesto. Además, se deberá tener un mecanismo que per-
mita revisar y anular los privilegios de acceso para evitar incidentes.
9.3.6. Protección de las instalaciones

La seguridad física es el primer paso para garantizar la protección de los servicios y
la información que se gestionan. Para ello, los sistemas que albergan información
deben estar físicamente en otras instalaciones, protegidos contra accesos no autori-
zados y con medidas contra incendios, inundaciones, etc.
9.3.7. Adquisición de nuevos productos de seguridad

Cuando se valoren nuevos productos de seguridad para su adquisición, se debería
tener en mayor consideración aquellos que tengan certificada (ISO/IEC 15408, etc.)
la funcionalidad de seguridad.
9.3.8. Seguridad por defecto

Para limitar los riesgos y evitar problemas de seguridad, se requiere que los siste-
mas sean diseñados y configurados de manera que su uso sea seguro. Esto implica
actuaciones en distintos aspectos:
• Que sólo tengan la funcionalidad necesaria para el uso que se pretende dar al
sistema.
• Que las funciones de operación, administración y registro de actividad sean
las mínimas necesarias.
• Que estas funciones sólo puedan ser realizadas por el personal autorizado
y, para reforzar el control, se pueda restringir el periodo y los lugares de
acceso.
• Que se configure el sistema para que no estén disponibles ni accesibles fun-
ciones que no sean estrictamente necesarias.
• Que el uso del sistema sea sencillo y seguro, de manera que un evento de
seguridad tenga que ser producido deliberadamente por el usuario.
9.3.9. Integridad y actualización del sistema

Para garantizar en todo momento la integridad del sistema, no se podrá instalar
ningún elemento físico ni lógico sin tener una autorización formal previa para ello.
La actualización del sistema se llevará a cabo manteniendo un control permanente
sobre las indicaciones de los fabricantes, las vulnerabilidades y las actualizaciones
que les afecten. El identificar nuevas vulnerabilidades, evaluar su aplicación o no a
los sistemas y ejecutar los cambios que se aprueben hará que se mantenga el nivel
de seguridad del sistema.
9.3.10. Protección de la información almacenada y

en tránsito
Es muy habitual que las medidas de protección de las que goza la información al
inicio de su ciclo de vida, al generarse y gestionarse, se diluyan o desaparezcan
cuando se transmite o almacena. Es fundamental protegerla durante todo su ciclo
de vida, por ello se deben diseñar medidas de seguridad que tengan en cuenta que
muchas veces la información se encuentra en entornos inseguros: equipos portáti-
les, asistentes personales (PDA), dispositivos periféricos, soportes de información
y comunicaciones sobre redes abiertas o con cifrado débil.
Los procedimientos para la recuperación y conservación a largo plazo de los docu-
mentos electrónicos producidos por las Administraciones Públicas en el ámbito de
sus competencias se encuentran sujetos a este requisito.
En este aspecto es donde se amplía de alguna manera el alcance del ENS. Hemos
visto que sus requisitos aplican únicamente a los servicios de administración elec-
trónica, pero aún existe mucha información en soporte no electrónico, que se ha
originado o es el origen de información electrónica, y por lo tanto, deberá estar
protegida como si lo fuera, con la salvedad de que las medidas que se apliquen sean
coherentes con el soporte donde se encuentra.
9.3.11. Prevención ante otros sistemas de información

interconectados
De igual manera que se protege el perímetro físico de un sistema, debe protegerse
el lógico. Como es intrínseco a la administración electrónica el tener los sistemas
internos de la entidad conectados con internet y con otras entidades, este períme-
tro lógico conlleva unos riesgos que deben ser analizados y evaluados, de manera
que se puedan mitigar de manera coherente y proporcional.
9.3.12. Registro de actividad

Para gestionar la seguridad es imprescindible tener identificados a los usuarios y
sus respectivos privilegios en los sistemas de información, ya que es una de las
herramientas principales para impedir accesos no autorizados. Debe complemen-
tarse con el registro de las actividades de los usuarios, de manera que se puedan
identificar accesos fraudulentos o no autorizados y tomar las medidas de correc-
ción que sean necesarias, así como proceder a la sanción del infractor si fuera
necesario. Lógicamente, debe tenerse cuidado a la hora de recopilar estos datos

para no entrar en conflicto con lo estipulado en la Ley Orgánica de Protección de
Datos de carácter personal y sus desarrollos, o invadir la privacidad de los usuarios.
9.3.13. Incidentes de seguridad

La gestión de los incidentes de seguridad es uno de los pilares de cualquier sistema
de gestión de la seguridad. Es inevitable que sucedan incidentes a pesar de las
medidas establecidas, por lo que se necesita contar con un mecanismo que permita,
tanto reaccionar rápidamente para minimizar los daños como luego analizar y
extraer conclusiones, que permitan incorporar mejoras al sistema de gestión, a los
de información, o a todos, para evitar otros incidentes similares.
Como es de rigor en un entorno tan conectado como el que nos ocupa, el ENS
requiere que se cuente con un sistema de detección y reacción frente al código
dañino.
9.3.14. Continuidad de la actividad

El riesgo de que algún incidente grave inutilice o no permita acceder a los
medios habituales de trabajo, por su grave impacto en los servicios que se pres-
tan, requiere de un plan de continuidad que de alguna manera permita seguir
operando. Como mínimo, se dispondrá de copias de seguridad y una serie de
protocolos de actuación.
9.3.15. Mejora continua del proceso de seguridad

La seguridad es un proceso. Para mantener un cierto nivel de seguridad, hay que
estar continuamente revisando, actualizando y mejorando el sistema, o de lo con-
trario, los cambios en el contexto (el personal, la tecnología, nuevas vulnerabili-
dades, etc.) harán que el nivel descienda.
9.3.16. Soporte al cumplimiento

Para cumplir con todos estos requisitos mínimos hay que aplicar las medidas de
seguridad que se detallan en el anexo II del Real Decreto 3/2010 considerando que:
• Deben aplicarse a los activos que constituyen el sistema.
• Deben escogerse según la categoría del sistema.

• Pueden aplicarse otras medidas que se estimen oportunas según los servicios
y la información gestionados y los riesgos identificados mediante el análisis
de riesgos.
• Que no puede haber conflicto con los requisitos de la LOPD.
Si se considera que algún sistema de información no está relacionado con el ámbito

de aplicación del ENS, la entidad podrá excluirlo del sistema de gestión de la
seguridad.
Para facilitar el cumplimiento del ENS, existen infraestructuras y servicios comu-
nes reconocidos en las Administraciones Públicas. Asimismo, como herramientas
de consulta, el Centro Criptológico Nacional (CCN) ha elaborado y difundido
guías de seguridad.
9.4. Otros requisitos

9.4.1. Comunicaciones electrónicas
Evidentemente, las comunicaciones son un aspecto crítico a tener en cuenta en el
momento de diseñar la seguridad de un sistema de información por su sensibili-
dad. El ENS demanda que se controlen las comunicaciones, de manera que las
transmisiones se lleven a cabo sin incidencias, que su contenido llegue íntegro y
que se pueda identificar al remitente y al destinatario de las mismas de manera
inequívoca.
No hay que olvidar que las comunicaciones tienen un valor y eficacia jurídicos
que no se deben perder en ningún momento. Este es el caso de las notificaciones
y publicaciones electrónicas, ya que el ENS exige que se asegure la autenticidad
del organismo que las publica, la integridad de la información publicada, que
conste la fecha y hora de la puesta a disposición del interesado de la resolución o
el acto objeto de publicación o notificación, así como del acceso a su contenido,
además de que se asegure la autenticidad del destinatario de la publicación o
notificación.
Una de las herramientas que se utilizará para garantizar la seguridad de las comu-
nicaciones será la firma electrónica, que protege la autenticidad de quien emite una
comunicación electrónica. Su utilización debe estar regulada mediante una política
y aplicada según lo estipulado en el anexo II del ENS y el Esquema Nacional de
Interoperabilidad.
9.4.2. Auditoría de la seguridad

Para garantizar la adecuación en todo momento del sistema a los requisitos del
ENS, se estipulará la realización de una auditoría cada dos años, como mínimo, o
antes si hay cambios importantes en el sistema de información, que puedan afectar
a las medidas de seguridad requeridas. Esta auditoría deberá servir también como
herramienta de mejora de la eficacia de las medidas de seguridad establecidas.
Deberán emitirse informes que identifiquen las deficiencias y desviaciones del sis-
tema de seguridad respecto a lo establecido en el ENS, que serán presentados al
responsable del sistema para que valore los resultados y adopte las medidas de
corrección adecuadas.
9.4.3. Estado de seguridad de los sistemas

Regularmente, el Comité Sectorial de Administración Electrónica elaborará un
informe en el que se recogerán las principales variables de la seguridad en los siste-
mas de información a los que se refiere el ENS, de forma que permita elaborar un
perfil general del estado de la seguridad en las Administraciones Públicas.
9.4.4. Respuesta a incidentes de seguridad

Para ayudar a dar respuesta a los incidentes de seguridad, el Centro Criptológico
Nacional (CCN) pone a disposición de las entidades el Centro Criptológico Nacio-
nal-Computer Emergency Reaction Team (CCN-CERT). Se denomina CERT a un
grupo de trabajo responsable de desarrollar medidas de prevención y de reacción
ante incidentes de seguridad en los sistemas de información.
Este CCN-CERT prestará a las Administraciones Públicas los siguientes servicios:
• Soporte y coordinación para la resolución de incidentes de seguridad y tratar
vulnerabilidades.
• Investigación y divulgación de las mejores prácticas sobre seguridad de la
información. En este contexto se han desarrollado las series de documentos
Centro Criptológico Nacional-Seguridad de las Tecnologías de Información
y Comunicaciones (CCN-STIC), elaboradas por el Centro Criptológico
Nacional y que se pueden consultar en su sitio web.
• Formación en el campo de la seguridad de las tecnologías de la información.
• Información sobre vulnerabilidades, alertas y avisos de nuevas amenazas.
• Un programa para informar, formar, emitir recomendaciones y proporcionar

herramientas para que cada entidad pueda desarrollar sus propias capacida-
des de respuesta a incidentes de seguridad, actuando el CCN como
coordinador nacional.
9.4.5. Normas de conformidad

El ENS demanda en este aspecto:
• Que se garantice la seguridad de las redes y los registros electrónicos por ser
la primera toma contacto del ciudadano con la administración electrónica.
• Que la seguridad esté presente en todo el ciclo de vida de los servicios y los
sistemas. Para ello, las especificaciones de seguridad deben formar parte de la
planificación de un nuevo servicio o sistema.
• Que exista un mecanismo de control que monitorice y verifique el correcto
seguimiento de las directrices de seguridad, de manera que se pueda garanti-
zar que funciona correctamente. Deben establecerse puntos y elementos de
control para realizar esta tarea.
• Las entidades sujetas al ENS deben hacer públicas, en las correspondientes
sedes electrónicas, las declaraciones de conformidad con el ENS y cualquier
otro distintivo de seguridad que posean como, por ejemplo, la certificación
según la Norma UNE-ISO/IEC 27001.
9.4.6. Actualización
Es un aspecto que ya se ha tratado anteriormente y en el que se insiste en este capí-
tulo. El sistema de seguridad debe estar permanentemente actualizado, mejorán-
dolo con el tiempo para responder a los cambios en los servicios de administración
electrónica, la evolución tecnológica, y los nuevos estándares internacionales sobre
seguridad y auditoría en los sistemas y tecnologías de la información.
9.4.7. Categorización de los sistemas

El ENS describe en su anexo I el modo de proceder para asignar una categoría al
sistema o sistemas que se identifiquen en una entidad. Hay tres categorías, baja,
media y alta, a las que se adscribirán los sistemas en función de la gravedad del
impacto que tendría un incidente que afectara a la seguridad de la información o
de los servicios. Esta categoría determinará las medidas que haya que aplicar al sis-
tema, y por lo tanto, el esfuerzo que habría que dedicar a la seguridad del mismo.
El responsable de cada información o servicio es quien debe realizar las valoración
del impacto de un incidente en la disponibilidad, autenticidad, integridad, confi-
dencialidad o trazabilidad de ese activo, y mantenerlas actualizadas.
El responsable del sistema es quien debe asignar la categoría al mismo.
9.4.8. Formación
Ningún sistema de gestión puede funcionar si no se cuenta con el personal adecua-
damente formado y concienciado. En este caso, es particularmente esencial, ya que
las personas son un activo importante de los sistemas y una fuente de riesgos
importante. El ENS requiere que el personal reciba la formación necesaria que
garantice su cumplimiento.
10 Implementación del ENS
10.1. El plan de adecuación

La implementación del ENS puede dividirse en dos partes:
• La elaboración del plan de adecuación.
• La ejecución de las acciones definidas en dicho plan.
El plan de adecuación lo desarrollará el responsable de seguridad cuando lo haya o

la persona a la que se asigne esta función de forma temporal y debe contener la
siguiente información:
• La política de seguridad. Cada entidad debe contar con una política de segu-
ridad que recoja sus objetivos, el marco legal, los roles y funciones de seguri-
dad, así como los comités de seguridad y las directrices para la gestión de la
documentación, entre otros puntos. Si no posible elaborarla y aprobarla en
esos momentos, debe planificarse como una tarea a realizar en el plan de
mejora.
• Información que se maneja, con su valoración. Se identifica primero la infor-
mación que se utiliza para la prestación de los servicios electrónicos y des-
pués se evalúa en un rango de tres categorías (baja, media y alta) cómo sería
el impacto de un incidente sobre esa información en cada uno de las cinco
dimensiones de seguridad: confidencialidad, integridad, disponibilidad,
autenticidad y trazabilidad. Los criterios generales de valoración del impacto
en cada nivel son:
– Bajos. Cuando las consecuencias de un incidente supongan un perjuicio
limitado sobre los activos o las funciones de la entidad.
– Medios. Cuando las consecuencias de un incidente supongan un perjuicio

grave sobre los activos o las funciones de la entidad, de manera que no
puedan funcionar normalmente, se dañe seriamente algún activo, se haya
incumplido alguna ley o se haya perjudicado a alguna persona.
– Alto. Cuando las consecuencias de un incidente supongan un perjuicio
muy grave sobre los activos o las funciones de la entidad, de manera que
no pueda funcionar, se haya dañado gravemente algún activo o incluso
haya sido destruido, se haya incumplido gravemente alguna ley o se haya
perjudicado irremediablemente a alguna persona.
Si esta valoración la realiza el responsable de seguridad, se considerará provi-
sional y deberá planificarse la valoración por parte de los propietarios de la
información en el plan de mejora.
• Servicios que se prestan, con su valoración. Como en el caso de la información,
hay que identificar los servicios, valorando las cinco dimensiones del mismo
modo, en función de la gravedad del impacto de un incidente en la entidad.
Además de los servicios actualmente prestados, hay que incluir los que van a
ser puestos en marcha, ya que el ENS exige que cualquier servicio que se
comience a prestar debe estar ya cumpliendo con los requisitos, así que deben
analizarse junto con el resto.
• Datos de carácter personal. Será bastante habitual por la naturaleza de los
servicios electrónicos, que se manejen datos de carácter personal. Se identifi-
carán o se hará referencia al Documento de Seguridad de la LOPD.
• Categoría del sistema. Las valoraciones de la información y los servicios
son los datos de partida para decidir la categoría del sistema o los sistemas
identificados. En cada dimensión ésta vendrá dada por el mayor de los
niveles que haya alcanzado en ella. Finalmente, será el mayor de los niveles
alcanzado en cualquiera de las cinco dimensiones. Es decir, un sistema en
el que las cinco dimensiones están valoradas de nivel bajo, será de catego-
ría básica. Si alguna de ellas es de nivel medio y ninguna es alto, será de
categoría media. Si alguna de ellas es de nivel alto, la categoría del sistema
será alta.
Para economizar recursos es preferible desglosar el sistema en tanto subsiste-
mas como sea razonable hacerlo, de manera que las medidas para el nivel
alto, que son más exigentes que para el resto, se apliquen al menor número
de servicios e información posible. Como ejemplo, se puede tomar una sede
electrónica. Si la consideramos como un único sistema, teniendo en cuenta
los requisitos planteados por la Ley 11/2007, la disponibilidad del registro
electrónico tendrá que ser de 24 horas al día, los 365 días del año, por lo
10. Implementación del ENS 151
tanto, se podrá valorar su dimensión de disponibilidad como de nivel alto, y

consecuentemente, la categoría del sistema será alta.
Sin embargo, si desglosamos la sede electrónica en varios subsistemas, por
ejemplo:
– Página web.
– Registro electrónico.
– Notificaciones.
– Servicio de validación de documentos.
– Tablón de anuncios.
Como solamente el registro electrónico tiene ese requisito de disponibilidad,
este subsistema será de nivel alto, pero el resto pueden ser de niveles más
bajos, con el consiguiente ahorro de esfuerzo y recursos.
• Declaración de aplicabilidad de las medidas del anexo II del ENS. Es un requi-
sito formal del ENS, consiste en un listado de las medidas de seguridad a apli-
car al sistema de acuerdo con la categoría del mismo. En el anexo II del ENS
se recogen las 75 medidas de seguridad, con las dimensiones a las que aplican
y en qué medida lo hacen según la categoría del sistema. Por ejemplo, la
medida “op.pl.1, Análisis de riesgos”, aplica al sistema, y si es de nivel bajo
habría que hacer un análisis informal, si fuera de nivel medio uno semiformal
y si fuera de nivel alto uno formal. Otro ejemplo, la medida “mp.if.9, Instala-
ciones alternativas”, afecta a la disponibilidad y no aplicaría a los sistemas de
niveles bajo y medio, pero sí a los de nivel alto. Si hubiera medidas que habría
que aplicar debido al nivel del sistema, pero no se consideran aplicables, habría
que justificar por qué es así. Asimismo, si se usaran otras medidas diferentes de
las propuestas por el ENS, también habría que justificarlas e identificar a cuá-
les sustituyen. Esta declaración estará firmada por el responsable de seguridad.
• Análisis de riesgos. Realizarle tiene como objetivo completar las medidas de
seguridad a las que obliga el ENS con otras que se considere necesarias para
mitigar los riesgos identificados, además de establecer un mapa de riesgos
potenciales y actuales que ponga de manifiesto el progreso en la eliminación
de problemas. Los riesgos residuales, los que quedan tras la aplicación de las
medidas de seguridad seleccionadas, deben ser formalmente aceptados por
los responsables de la información y servicios afectados, o en su defecto, lo
hará el responsable de seguridad.
El ENS exige que la metodología que se use para la realización del análisis
de riesgos sea reconocida internacionalmente. La metodología MAGERIT,
del Ministerio de Administraciones Públicas, así como su herramienta aso-
ciada PILAR, cumplen este requisito dado que está recogida en el inventario
de la European Network and information Security Agency (ENISA). El alto
grado de implementación de MAGERIT y PILAR en la Administración
Pública española, junto con el coste nulo que suponen, hacen que sean la
elección habitual a la hora de decidir la herramienta a utilizar.
• Insuficiencias del sistema. Se realizará un análisis de los requisitos que no se
están cumpliendo, como punto de partida para la definición del plan de
mejora. Estas insuficiencias pueden venir de desviaciones respecto a los dis-
tintos artículos del Real Decreto 3/2010, incumplimientos de las medidas de
seguridad, tal y como se definen en el anexo II, o incumplimientos de los
requisitos exigidos por el Real Decreto 1720/2007 para los datos de carácter
personal tratados por el sistema.
• Plan de mejora seguridad, incluyendo plazos estimados de ejecución. Se
determinarán las acciones a tomar para eliminar o subsanar las insuficiencias
detectadas y se planificará su ejecución, indicando los plazos previstos de eje-
cución, los hitos del proyecto y la estimación de costes.
Una vez elaborado y aprobado el plan de adecuación, la entidad puede publicar su

declaración de conformidad en la sede electrónica, así como otros certificados de
accesibilidad, interoperabilidad, menciones de calidad de cualquiera de las Admi-
nistraciones Públicas (estatal, autonómica y local), de organizaciones internaciona-
les o de organismos privados. Esta declaración ha de ir firmada por el titular del
organismo emisor de la declaración de conformidad, que ha de identificarse con su
nombre completo y cargo que desempeña.
10.2. Adecuación al ENS

La adecuación al ENS pasa por la realización de una serie de tareas que coinciden a
grandes rasgos con las que se vieron previamente para la implementación de un SGSI
según la Norma UNE-ISO/IEC 27001: definir el alcance de la aplicación del ENS,
la política de seguridad, asignar responsabilidades, realizar un análisis de riesgos, etc.
Hay que señalar que, dado que cumplir con el ENS es una obligación legal, no es
posible obviar ninguna de las acciones y documentos que exige.
10.2.1. Planificación
La planificación es la realización del plan de adecuación.
Toda la información necesaria para poder comparar el estado de la seguridad en la

entidad con el estado que pide el ENS, se recopilará durante la realización del plan
de adecuación, que a su vez contendrá el plan de mejora con las acciones a tomar.
Este plan incluirá:
• El desarrollo y la aprobación de una política de seguridad.
• La asignación y aprobación de los responsables de seguridad, de la informa-
ción y de los servicios.
• La definición la normativa de seguridad. Serán documentos que detallen
cómo y quién realizará las distintas tareas y cómo se identificarán y resol-
verán los comportamientos anómalos, tales como procedimientos para la
gestión de incidencias, la monitorización del sistema o el plan de conti-
nuidad.
• La definición y la descripción de los procesos de autorización, formalizando
las autorizaciones que cubran todos los elementos de los sistemas de infor-
mación: instalaciones, equipos, aplicaciones, medios de comunicación, acce-
sos, soportes, etc.
• La implementación de medidas de seguridad.
• La formación al personal de la entidad sobre la política, normativa y proce-
dimientos de seguridad.
• La evaluación de la eficacia de las medidas adoptadas.
• La definición e implementación de los procedimientos para la actualización
de la gestión de la seguridad.
• La realización de una auditoría de seguridad.
10.2.2. Implementación
Partiendo del plan de mejora y de la declaración de aplicabilidad, se desarrollará la
normativa de seguridad, es decir, aquellos procedimientos necesarios para imple-
mentar todos los requisitos que hacen falta para cumplir con los requisitos del ENS.
Estos procedimientos detallarán las distintas tareas, los responsables de su ejecu-
ción y supervisión, así como los mecanismos para identificar y resolver los compor-
tamientos anómalos.
Puede ser necesario desarrollar también instrucciones de trabajo y documentos
modelo que permitan registrar las operaciones descritas en los procedimientos, así
como controlar la resolución de las incidencias.
Otras tareas que se realizarán en esta fase son:

• La elaboración y puesta en marcha de un plan de pruebas y monitorización
del sistema, para controlar la seguridad del mismo.
• La definición y ejecución de un plan de auditorías, en las que se revisarán la
política de seguridad y su cumplimiento, así como el conjunto de riesgos,
normativas, procedimientos y controles establecidos.
• La definición y ejecución de un plan de formación y sensibilización. Se debe-
ría impartir formación a todo el personal de la entidad, de modo que cada
uno conozca cuáles son sus responsabilidades y tareas para proteger la infor-
mación y los servicios que gestione. Es una parte fundamental de la imple-
mentación, tanto por ser imprescindible para cumplir con el ENS como para
garantizar el éxito de las medidas implementadas.
10.2.3. Verificación y validación

El nivel de seguridad debe ser controlado para verificar si las medidas de seguridad
están funcionando correctamente y los resultados son los esperados. Con el tiempo
y los cambios en la organización, puede ser que las adoptadas en un principio no
sean las adecuadas por ser excesivas o insuficientes, no ser eficaces para reducir el
riesgo, etc.
Además del control rutinario, se deben realizar revisiones, como por ejemplo:
• Autoevaluaciones. Llevadas a cabo por el responsable de seguridad, perti-
nentemente documentadas, y en las que se chequeen:
– La validez y vigencia de la política, y la normativa de seguridad.
– La vigencia de la categorización de los sistemas y el análisis de riesgos.
– La validez y vigencia de los controles aplicados.
– La eficacia de los controles.
• Auditorías. Llevadas a cabo por un auditor cualificado e independiente, que
compruebe que las medidas implementadas y la documentación de soporte
cumple con los requisitos del ENS.
Cuando los sistemas son de nivel bajo, una autoevaluación periódica es suficiente,
pero si son de nivel medio o alto están sujetos, como mínimo, a una auditoría cada
dos años.
10.2.4. Actualización y mejora continua

Para cumplir con los requisitos de actualización y mejora continua que plantea el
ENS, se utilizará la información derivada de la gestión de incidencias y los resulta-
dos de las actividades de verificación y validación.
A partir de aquí, se debe derivar a un plan de acción para subsanar los errores
detectados, que justificarán el cumplimiento en este aspecto que requiere el ENS.
11 Ejemplo práctico:
plan de adecuación
11.1. Documentación de la política de seguridad

Aprobación y entrada en vigor. Fecha de la aprobación y entrada en vigor de la
política.
Introducción. Breve descripción de los objetivos de la organización en cuanto a la
seguridad de la información y los medios que se están utilizarán para garantizarla.
Prevención. Declaración de las medidas de seguridad existentes para prevenir
daños a la información o los servicios.
Detección. Declaración de las medidas de seguridad existentes para detectar inci-
dentes que puedan producir daños a la información o los servicios.
Respuesta. Declaración de las medidas de seguridad existentes para dar respuesta a
los incidentes que puedan producir daños a la información o los servicios.
Recuperación. Declaración de las medidas de seguridad existentes para recuperar
la disponibilidad de los servicios y garantizar la continuidad de las actividades de la
entidad.
Alcance. Declaración del alcance de la aplicación del ENS, habitualmente en tér-
minos de los servicios que se prestan en la entidad.
Misión. Declaración de la misión de la entidad en los aspectos de seguridad.
Marco normativo. Declaración de la legislación aplicable a la entidad en el ámbito
de la seguridad de la información.
Organización de la seguridad. Descripción de los principales roles y responsabili-
dades exigidos por el ENS: responsable de servicio, responsable de la información
y responsable de seguridad.
Descripción de la composición de los comités de seguridad y de sus funciones.

Procedimientos de designación. Descripción del mecanismo a utilizar para desig-
nar los responsables descritos anteriormente.
Política de seguridad de la información. Descripción de la gestión de la política,
vigencia, revisión y actualización, y difusión.
Datos de carácter personal. En esta sección se deben identificar los datos de
carácter personal que quedan dentro del ámbito del ENS o hacer referencia al
documento de seguridad.
Gestión de riesgos. Declaración de haber realizado un análisis de riesgos y de la
periodicidad de su revisión y actualización.
Desarrollo de la política de seguridad de la información. Descripción de los
mecanismos por los que se desarrollará la política, como por ejemplo, la normativa
de seguridad y cómo se va a difundir en la organización.
Obligaciones del personal. Descripción de las principales obligaciones del personal,
como por ejemplo, conocer y aplicar la política, y formarse según requerimientos.
Terceras partes. Descripción de los mecanismos para gestionar la seguridad
cuando se presten servicios o se gestione información de terceros, y a la inversa,
cuando terceros presten servicios o gestionen información de la entidad.
11.2. Documentación de la categoría del sistema

11.2.1. Criterios de valoración de los activos
En esta sección se describirán los criterios mediante los que se van a valorar los acti-
vos.
Para el ejemplo se han seguido los criterios definidos en la guía CCN-STIC-803
Esquema Nacional de Seguridad, valoración de los sistemas.
11.2.2. Categorización de sistemas

Para categorizar los sistemas según el ENS, se recomienda seguir los pasos descri-
tos en la guía CCN-STIC-803 Valoración de los sistemas.
Se identificarán los servicios que se prestan y la información que los soporta,
decidiendo para cada uno de ellos, la relevancia para la entidad del impacto de
11. Ejemplo práctico: plan de adecuación 159
un incidente en cada una de las dimensiones de seguridad: disponibilidad (D),

integridad (I) y confidencialidad (C), autenticidad (A) y trazabilidad (T).
En la tabla 11.1 se muestra un ejemplo donde se han incluido los responsables pro-
puestos. Los que se asignen definitivamente quedarán documentados en la política
de seguridad.
Tabla 11.1. Categorización de sistemas
Sistema / Tipo de
Responsable Activos D I C A T Categoría
Subsistema Activo
Sede electrónica
Portal web B B B B B B
Secretaría Información
Información B B B B B
general de la sede
Responsable
Servicios Portal de sede B B B B B
TIC
Consultas y notificaciones B M M M M M
Responsable Expedientes
Información M M M M M
del servicio administrativos
Responsable
Servicios Consultas M M B M M
TIC
Notificaciones M A M M M
Registro electrónico M M A A A A
Secretaría Datos del

Información A M M M M
general registro
Responsable Registro
Servicios A M B M M
TIC general
Tablón oficial B B B B B B
Secretaría Información
Información B B B B B
general del tablón
Responsable Plataforma
Servicios B B B B B
TIC del tablón
11.3. Documentación del análisis de riesgos

11.3.1. Metodología de análisis
En esta sección se indicará la metodología que se va a seguir para realizar el análisis
de riesgos. En este ejemplo, se ha utilizado la herramienta PILAR basada en la
metodología MAGERIT.
11.3.2. Valoración de activos

En este punto se identificarán los activos utilizados para soportar los servicios y la
información, y se valorará su importancia para la entidad en cada una de las cinco
dimensiones de seguridad. Puede verse un ejemplo en la tabla 11.2.
Tabla 11.2. Valoración de activos
Activo D I C A T
Servicios
Portal de la sede B B B B B
Consultas M M B M M
Notificaciones M A M M M
Registro General A M B M M
Plataforma del tablón oficial B B B B B
Información
Información de la sede B B B B B
Expedientes administrativos M M M M M
Datos del registro A M M M M
Información del tablón B B B B B
[HW] Hardware
Servidor de datos A A M M M
Servidor de aplicaciones A A M M M
Puestos de usuario M M M M M
(continúa)
Tabla 11.2. Valoración de activos (continuación)
Activo D I C A T
Red de comunicaciones A A M M M
[SW] Software
Aplicación de gestión A A M M M
Gestión de BD Oracle A A M M M
Ofimática M M M M M
[I] Instalaciones
Sede central M M M M M
CPD alternativo M M M M M
[PE] Personal
Personal propio M M M M M
Personal subcontratado M M M M M
11.3.3. Mapas de riesgos

Con la valoración anterior se realizará un análisis de riesgos, evaluando en primer
lugar el riesgo potencial, que es el que presenta un activo antes de aplicarle ninguna
medida de seguridad y después el riesgo actual, que es el que presentan los activos
considerando las medidas de seguridad (salvaguardas) implementadas en la organi-
zación.
En la tabla 11.3 se muestra un ejemplo de listado de las medidas implementadas y
su grado de madurez.
En la tabla 11.4 se muestran los riesgos potenciales y los actuales de los activos
identificados.
11.3.4. Nivel de riesgo aceptable

A la vista de los riesgos identificados hay que marcar el nivel que se considera acep-
table. En este ejemplo, se considerará que el riesgo aceptable es 4. Se aplicarán
medidas a los riesgos que superen este valor y se asumirán el resto.
Tabla 11.3. Medidas de seguridad implementadas
Nivel de
Medidas
madurez
Marco organizativo 40%
Política de seguridad 50%
Normativa de seguridad 50%
Procedimientos de seguridad 50%
Proceso de autorización 10%
Marco operacional 43%
Planificación 40%
Control de acceso 56%
Explotación 58%
Servicios externos 63%
Continuidad del servicio 10%
Monitorización del sistema 30%
Medidas de protección 44%
Protección de las instalaciones e infraestructuras 70%
Gestión del personal 43%
Protección de los equipos 37%
Protección de las comunicaciones 37%
Protección de los soportes de información 18%
Protección de las aplicaciones informáticas (SW) 50%
Protección de la información 48%
Protección de los servicios 50%

Tabla 11.4. Mapa de riesgos
Potencial Actual
Activo
[D] [I] [C] [A] [T] [D] [I] [C] [A] [T]
[SE] Servicios
Portal de la sede 1,9 1,5 1,9 1,5 1 0,94 0,94 1,4 0,9 0,8
Consultas 3,6 3,3 1,9 3,3 2,8 2,5 2,5 1,4 2,5 2
Notificaciones 3,6 5,1 3,6 3,3 2,8 2,5 4,2 3,1 2,5 2
Registro general 6 3,3 1,9 3,3 2,8 4,8 2,5 1,4 2,5 2
Plataforma del tablón oficial 1,9 1,5 1,9 1,5 1 0,9 0,9 1,4 0,9 0,8
[IN] Información
Información de la sede electrónica 1 1,5 1,9 1,5 1 0,8 1,1 1,5 1,4 0,9
Expedientes administrativos 2,8 3,3 3,6 3,3 2,8 2,2 2,8 3,3 3,2 2,5
Datos del registro electrónico 2,8 3,3 3,6 3,3 2,8 2,2 2,8 3,3 3,2 2,5
Información del tablón de anuncios 1 1,5 1,9 1,5 1 0,8 1,1 1,5 1,4 0,9
[HW] Hardware
Servidor de datos 5,1 3,8 3,3 - - 4,2 2,9 2,5 - -
Servidor de aplicaciones 5,1 3,8 3,3 - - 4,2 2,9 2,5 - -
Puestos de usuario 3,3 2,1 3,3 - - 2,4 1,1 2,5 - -
Red de comunicaciones 5,1 3,8 3,3 - - 4,1 3,1 2,3 - -
[SW] Software
Aplicación de gestión 5,1 5,7 4,5 3,9 3,4 4,3 4,7 3,7 3,4 2,9
Gestión de DB Oracle 5,1 5,7 4,5 3,9 3,4 4,3 4,7 3,7 3,4 2,9
Ofimática 3,3 3,9 3,9 3,3 2,8 2,6 2,9 3,1 2,8 2,3
[L] Instalaciones
Sede central 2,5 2,8 2,8 - - 1,7 1,8 1,8 - -
CPD alternativo 3 2,8 2,8 - - 2,2 1,8 1,8 - -
[P] Personal
Personal propio 2,5 2 2,9 - - 1,9 1,7 2,6 - -
Personal subcontratado 2,5 2 2,9 - - 1,8 1,6 2,6 - -

11.4. Documentación de la declaración de

aplicabilidad
Esta declaración consiste en detallar las medidas de seguridad de entre las mencio-
nadas en el anexo II del ENS, con el estado en el que se encuentran, teniendo en
cuenta las que aplican debido a la categoría de los sistemas y subsistemas, y aque-
llas que se decidan para mitigar los riesgos detectados.
Cada medida de seguridad tendrá uno de los dos estados siguientes:
• No aplica. Control no seleccionado debido a que no es obligatorio según la
categoría del sistema, ni se considera necesario para mitigar los riesgos.
• Aplica. Control seleccionado por requerimiento del ENS para la categoría
del sistema o para mitigar algún riesgo detectado.
En la tabla 11.5 se muestra un ejemplo. A pesar de que por el nivel de los sistemas
no aplicaría, para reducir los riesgos no asumibles, se han seleccionado los siguien-
tes controles que se han señalado como “aplica” en los sistemas de nivel medio:
• “op.mon.2 Sistema de métricas”.
• “mp.if.9 Instalaciones alternativas”.
• “mp.per.9 Personal alternativo”.
• “mp.com.9 Medios alternativos”.
Tabla 11.5. Declaración de aplicabilidad
Dimensiones Tipo de Medida Estado Estado

afectadas medida de seguridad nivel medio nivel alto
org Marco organizativo
categoría org.1 Política de seguridad Aplica Aplica
categoría org.2 Normativa de seguridad Aplica Aplica
categoría org.3 Procedimientos de seguridad Aplica Aplica
categoría org.4 Proceso de autorización Aplica Aplica
op Marco operacional
op.pl Planificación
categoría op.pl.1 Análisis de riesgos Aplica Aplica
(continúa)
Tabla 11.5. Declaración de aplicabilidad (continuación)

categoría op.pl.2 Arquitectura de seguridad Aplica Aplica
categoría op.pl.3 Adquisición de nuevos componentes Aplica Aplica
D op.pl.4 Dimensionamiento/Gestión de capacidades Aplica Aplica
categoría op.pl.5 Componentes certificados n.a. Aplica
op.acc Control de acceso
AT op.acc.1 Identificación Aplica Aplica
ICAT op.acc.2 Requisitos de acceso Aplica Aplica
ICAT op.acc.3 Segregación de funciones y tareas Aplica Aplica
ICAT op.acc.4 Acceso de gestión de derecho des Aplica Aplica
ICAT op.acc.5 Mecanismo de autenticación Aplica Aplica
ICAT op.acc.6 Acceso local (local login) Aplica Aplica
ICAT op.acc.7 Acceso remoto (remote login) Aplica Aplica
op.exp Explotación
categoría op.exp.1 Inventario de activos Aplica Aplica
categoría op.exp.2 Configuración de seguridad Aplica Aplica
categoría op.exp.3 Gestión de la configuración Aplica Aplica
categoría op.exp.4 Mantenimiento Aplica Aplica
categoría op.exp.5 Gestión de cambios Aplica Aplica
categoría op.exp.6 Protección frente a código dañino Aplica Aplica
categoría op.exp.7 Gestión de incidencias Aplica Aplica
T op.exp.8 Registro de la actividad de los usuarios n.a. Aplica
categoría op.exp.9 Registro de la gestión de incidencias Aplica Aplica
T op.exp.10 Protección de los registros de actividad n.a. Aplica
categoría op.exp.11 Protección de claves criptográficas Aplica Aplica
op.ext Servicios externos
categoría op.ext.1 Contratación y acuerdos de nivel de servicio Aplica Aplica
categoría op.ext.2 Gestión diaria Aplica Aplica
D op.ext.9 Medios alternativos n.a. Aplica
(continúa)

op.cont Continuidad del servicio
D op.cont.1 Análisis de impacto Aplica Aplica
D op.cont.2 Plan de continuidad n.a. Aplica
D op.cont.3 Pruebas periódicas n.a. Aplica
op.mon Monitorización del sistema
categoría op.mon.1 Detección de intrusión n.a. Aplica
categoría op.mon.2 Sistema de métricas Aplica Aplica
mp Medidas de protección
mp.if Protección de las instalaciones e infraestructuras
categoría mp.if.1 Áreas separadas y con control de acceso Aplica Aplica
categoría mp.if.2 Identificación de las personas Aplica Aplica
categoría mp.if.3 Acondicionamiento de los locales Aplica Aplica
D mp.if.4 Energía eléctrica Aplica Aplica
D mp.if.5 Protección frente a incendios Aplica Aplica
D mp.if.6 Protección frente a inundaciones Aplica Aplica
categoría mp.if.7 Registro de entrada y salida de equipamiento Aplica Aplica
D mp.if.9 Instalaciones alternativas Aplica Aplica
mp.per Gestión del personal
categoría mp.per.1 Caracterización del puesto de trabajo Aplica Aplica
categoría mp.per.2 Deberes y obligaciones Aplica Aplica
categoría mp.per.3 Concienciación Aplica Aplica
categoría mp.per.4 Formación Aplica Aplica
D mp.per.9 Personal alternativo Aplica Aplica
mp.eq Protección de los equipos
categoría mp.eq.1 Puesto de trabajo despejado Aplica Aplica
A mp.eq.2 Bloqueo de puesto de trabajo Aplica Aplica
categoría mp.eq.3 Protección de equipos portátiles Aplica Aplica
D mp.eq.9 Medios alternativos Aplica Aplica
(continúa)

mp.com Protección de las comunicaciones
categoría mp.com.1 Perímetro seguro Aplica Aplica
C mp.com.2 Protección de la confidencialidad Aplica Aplica
IA mp.com.3 Protección de la autenticidad y de la integridad Aplica Aplica
categoría mp.com.4 Segregación de redes n.a. Aplica
D mp.com.9 Medios alternativos n.a. Aplica
mp.si Protección de los soportes de información
C mp.si.1 Etiquetado Aplica Aplica
IC mp.si.2 Criptografía Aplica Aplica
categoría mp.si.3 Custodia Aplica Aplica
categoría mp.si.4 Transporte Aplica Aplica
C mp.si.5 Borrado y destrucción Aplica Aplica
mp.sw Protección de las aplicaciones informáticas
categoría mp.sw.1 Desarrollo Aplica Aplica
categoría mp.sw.2 Aceptación y puesta en servicio Aplica Aplica
mp.info Protección de la información
categoría mp.info.1 Datos de carácter personal Aplica Aplica
C mp.info.2 Calificación de la información Aplica Aplica
C mp.info.3 Cifrado n.a. Aplica
IA mp.info.4 Firma electrónica Aplica Aplica
T mp.info.5 Sellos de tiempo n.a. Aplica
C mp.info.6 Limpieza de documentos Aplica Aplica
D mp.info.9 Copias de seguridad (back up) Aplica Aplica
mp.s Protección de los servicios
categoría mp.s.1 Protección del correo electrónico Aplica Aplica
categoría mp.s.2 Protección de servicios y aplicaciones web Aplica Aplica
D mp.s.8 Protección frente a la denegación de servicio Aplica Aplica
D mp.s.9 Medios alternativos n.a. Aplica

11.5. Insuficiencias del sistema

En esta sección se documentarán las insuficiencias identificadas respecto a los
requisitos del ENS.
Por ejemplo, el bajo nivel de madurez de algunas de las medidas aplicadas viene
dado por una falta de documentación, por lo que se podría decir que las principa-
les insuficiencias detectadas son:
• Documentación. No hay una gestión documental formal de los aspectos de
seguridad de la información a excepción de lo provisto para cumplir con la
LOPD.
• Formación. El personal ha recibido formación en cuanto a LOPD pero no
se ha impartido sobre otros aspectos de seguridad.
11.6. Plan de mejora

El plan de mejora debe contener las acciones a tomar hasta el plazo marcado por el
Real Decreto 3/2010.
En la tabla 11.6 se muestra un ejemplo.
Tabla 11.6. Plan de mejora
1.er 2.º 1.er 2.º 1.er

ID Acciones semestre semestre semestre semestre semestre
2012 2012 2013 2013 2014
1 Lanzamiento del ENS
1.1 Planificar formación
1.2 Planificar auditorías
2 Documentación del ENS
2.1 Elaboración de la normativa

de seguridad
2.2 Elaboración de procedimientos

de seguridad
2.3 Formalizar la gestión de los

servicios externos
(continúa)
Tabla 11.6. Plan de mejora (continuación)
1.er 2.º 1.er 2.º 1.er

ID Acciones semestre semestre semestre semestre semestre
2012 2012 2013 2013 2014
2.4 Documentar la gestión de la

continuidad
2.5 Establecer métricas de

desempeño
3 Implementación del ENS
3.1 Llevar a cabo acciones de

concienciación y formativas
3.2 Implementar procedimientos de

seguridad
4 Monitorización y supervisión
4.1 Realizar auditorías
4.2 Revisar objetivos
4.3 Revisar el análisis de riesgos
5 Proyecto 5: actualización y
mantenimiento
4.4 Planificar mejoras

Bibliografía
Normas de referencia
Norma UNE- ISO/IEC 27000 Tecnología de la información. Técnicas de seguridad.
Sistemas de Gestión de la Seguridad de la Información (SGSI). Visión de conjunto y
vocabulario.
La aplicación de cualquier norma necesita de un vocabulario claramente defi-
nido, que evite distintas interpretaciones de conceptos técnicos y de gestión.
Norma UNE-ISO/IEC 27001 Tecnología de la información. Técnicas de seguridad.

Sistemas de Gestión de la Seguridad de la Información (SGSI). Requisitos.
En ella se recogen los requisitos para establecer, implementar, documentar y
evaluar un SGSI. Es la norma sobre la que se desarrolla el sistema y la que per-
mite obtener la certificación del mismo por parte de un organismo certificador
independiente. La certificación del sistema de gestión contribuye a fomentar las
actividades de protección de la información en las organizaciones, mejorando
su imagen y generando confianza frente a terceros. En su anexo A, enumera los
objetivos de control y controles que desarrolla la UNE-ISO/IEC 27002 para
que sean seleccionados por las organizaciones en el desarrollo de sus SGSI, esta-
bleciendo así formalmente el nexo de unión entre las dos normas.
Norma UNE-ISO/IEC 27002 Tecnología de la información. Técnicas de seguridad.

Código de buenas prácticas para la gestión de la seguridad de la información.
Esta norma ofrece recomendaciones para realizar la gestión de la seguridad de
la información que pueden utilizarse por los responsables de iniciar, implemen-
tar o mantener la seguridad en una organización. Persigue proporcionar una
base común para desarrollar normas de seguridad y constituir una práctica efi-
caz de la gestión. Esta norma no es certificable.
Norma ISO/IEC 27003 Information technology – Information security management

system implementation guidance.
Es una guía de implementación de un SGSI basado en la Norma ISO/IEC
27001 e información acerca del uso del modelo PDCA y de los requerimientos
de sus diferentes fases.
Norma ISO/IEC 27004 Information technology – Information security management –

Measurement.
Especifica las métricas y las técnicas de medida aplicables para determinar la efi-
cacia de un SGSI y de los controles relacionados. Estas métricas se usan funda-
mentalmente para la medición de los componentes de la fase Do (implementar
y utilizar) del ciclo PDCA.
Norma ISO/IEC 27005 Information technology – Information security risk mana-

gement.
Consiste en una guía de técnicas para la gestión del riesgo de la seguridad de la
información y servirá, por tanto, de apoyo a la Norma UNE-ISO/IEC 27001 y
a la implementación de un SGSI. Recoge partes de ISO/IEC TR 13335.
Norma ISO/IEC 27006 Information technology – Requirements for bodies pro-

viding audit and certification of information security management systems.
Especifica los requisitos para la acreditación de entidades de auditoría y certifi-
cación de sistemas de gestión de seguridad de la información.
Norma ISO/IEC 27007 Information technology – Guidelines for information secu-

rity management systems auditing.
En fase de desarrollo. Consistirá en una guía para realizar una auditoría a un
SGSI.
Norma ISO/IEC 27011 Information technology – Information security management

guidelines for telecommunications organizations based on ISO/IEC 27002.
Es una guía de gestión de seguridad de la información específica para telecomu-
nicaciones, elaborada a partir de una Recomendación de la UIT (Unión Inter-
nacional de Telecomunicaciones).
Bibliografía 173
Norma ISO/IEC FCD 27032 Information technology – Guidelines for cybersecurity

En fase de desarrollo. Consistirá en una guía relativa a la ciberseguridad.
Serie ISO/IEC 27033 Information technology – Network security

Dividida en 7 partes: gestión de seguridad de redes, arquitectura de seguridad
de redes, escenarios de redes de referencia, aseguramiento de las comunicacio-
nes entre redes mediante gateways, acceso remoto, aseguramiento de comunica-
ciones en redes mediante VPNs y diseño e implementación de seguridad en
redes. Provendrá de la revisión, ampliación y renumeración de ISO 18028.
Serie ISO/IEC 27034 Information technology – Network security.

Se ha publicado la primera parte, y el resto está en desarrollo. Será en una guía
de seguridad en aplicaciones.
Informe UNE 71501-1 IN Tecnología de la Información (TI). Guía para la gestión

de la seguridad de TI. Parte 1: Conceptos y modelos para la seguridad de TI.
Este informe proporciona una visión general de los conceptos fundamentales y
de los modelos utilizados para describir la gestión de seguridad de TI.
Informe UNE 71501-2 IN Tecnología de la información (TI). Guía para la gestión

de la seguridad de TI. Parte 2: Gestión y planificación de la seguridad de TI.
Se describen varios aspectos de gestión y planificación de la seguridad de TI.
Informe UNE 71501-3 IN Tecnología de la información (TI). Guía para la gestión

de la seguridad de TI. Parte 3: Técnicas para la gestión de la seguridad de TI.
Esta norma describe varias técnicas de seguridad indicadas para distintas fases
de un proyecto, desde la planificación hasta la explotación, pasando por la
implementación.
Informe UNE 66172:2003 Directrices para la justificación y desarrollo de normas de

sistemas de gestión.
ISO/IEC 15408 Information technology – Security techniques – Evaluation criteria

for IT security.
UNE-ISO GUIA 73:2010 IN Gestión del riesgo. Vocabulario.

Legislación
Ley 11/2007, de 22 de junio, de acceso electrónico de los ciudadanos a los Servi-
cios Públicos. Su objeto es establecer la política de seguridad en la utilización de
medios electrónicos, y está constituido por principios básicos y requisitos míni-
mos que permitan una protección adecuada de la información.
Real Decreto 3/2010, de 8 de enero, por el que se regula el Esquema Nacional de
Seguridad en el ámbito de la Administración Electrónica.
Real Decreto 4/2010, de 8 de enero, por el que se regula el Esquema Nacional de
Interoperabilidad en el ámbito de la Administración Electrónica.
Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter
Personal.
Real Decreto 1720/2007, de 21 de diciembre, por el que se aprueba el Reglamento
de desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de protección de
datos de carácter personal.
Otros documentos
CCN-STIC-201 Estructura de seguridad. Enero 2009.
CCN-STIC-402 Organización y gestión TIC. Diciembre 2006.
CCN-STIC-801 Responsabilidades en el Esquema Nacional de Seguridad. Febrero
2010.
CCN-STIC-802 Auditoría del Esquema Nacional de Seguridad. Junio 2010.
CCN-STIC-803 Valoración de sistemas en el Esquema Nacional de Seguridad.
Enero 2011.
CCN-STIC-804 Medidas de implantación del Esquema Nacional de Seguridad
(borrador). Octubre 2011.
CCN-STIC-805 Política de seguridad del Esquema Nacional de Seguridad. Sep-
tiembre 2011.
CCN-STIC-806 Plan de adecuación del Esquema Nacional de Seguridad. Enero
2011.
CCN-STIC-807 Criptología de empleo en el Esquema Nacional de Seguridad.
Septiembre 2011.
Bibliografía 175
CCN-STIC-808 Verificación del cumplimiento de las medidas en el Esquema

Nacional de Seguridad. Septiembre 2011.
CCN-STIC-809 Declaración de conformidad del Esquema Nacional de Seguridad
(borrador). Julio 2010.
CCN-STIC-810 Creación de un CERT-CSIRT (borrador). Septiembre 2011.
CCN-STIC-811 Interconexión en el Esquema Nacional de Seguridad (borrador).
Septiembre 2011.
CCN-STIC-812 Seguridad en entornos y aplicaciones web (borrador). Octubre
2011.
CCN-STIC-814 Seguridad en correo electrónico (borrador). Agosto 2011.
CCN-STIC-815 Métricas e indicadores en el Esquema Nacional de Seguridad
(borrador). Diciembre 2011.
Norma Técnica de Interoperabilidad de Documento Electrónico. Resolución de 19
de julio de 2011 de la Secretaría de Estado para la Función Pública.
Norma Técnica de Interoperabilidad de Digitalización de Documentos. Resolu-
ción de 19 de julio de 2011 de la Secretaría de Estado para la Función Pública.
Norma Técnica de Interoperabilidad de Expediente Electrónico. Resolución de 19
de julio de 2011, de la Secretaría de Estado para la Función Pública.
Norma Técnica de Interoperabilidad de Política de Firma Electrónica y de certifi-
cados de la Administración. Resolución de 19 de julio de 201, de la Secretaría
de Estado para la Función Pública.
Norma Técnica de Interoperabilidad de requisitos de conexión a la red de comuni-
caciones de las Administraciones Públicas españolas. Resolución de 19 de julio
de 2011 de la Secretaría de Estado para la Función Pública.
Norma Técnica de Interoperabilidad de Procedimientos de copiado auténtico y
conversión entre documentos electrónicos. Resolución de 19 de julio de 2011
de la Secretaría de Estado para la Función Pública.
Norma Técnica de Interoperabilidad de Modelo de Datos para el Intercambio de
asientos entre las entidades registrales. Resolución de 19 de julio de 2011, de la
Secretaría de Estado para la Función Pública.
CNSS Inst. 4009 National Information Assurance (IA) Glossary. April 2010.
FIPS 200. Minimum Security Requirements for Federal Information and Information
Systems. March 2006.
ISO Guide 73 Risk management – Vocabulary. 2009.

SP 800-12. An Introduction to Computer Security: The NIST Handbook. Special
Publication 800-12. October 1995.
Links de interés
Asociación Española de Normalización (AENOR).
www.aenor.es
European Network and Information Security Agency (ENISA).
www.enisa.europa.eu
Instituto Nacional de Tecnologías de la Comunicación (INTECO).
www.inteco.es
ISMS Forum Spain. Asociación Española para el Fomento de la Seguridad de
la Información.
www.ismsforum.es
MAGERIT – versión 2. Metodología de Análisis y Gestión de Riesgos de los
Sistemas de Información.
www.csi.map.es/csi/pg5m20.htm
Esquema Nacional de Seguridad
https://www.ccn-cert.cni.es
http://administracionelectronica.gob.es/?_nfpb=true&_pageLabel=P4002281
273766578416&langPae=es
Esquema Nacional de Interoperabilidad
http://administracionelectronica.gob.es/?_nfpb=true&_pageLabel=P4001281
273739471793&langPae=es
National Institute of Standards and Technology (NIST).
An Introduction to Computer Security: The NIST Handbook
http://csrc.nist.gov/publications
RED.ES. Documentos emitidos por RED.ES.
www.red.es
START UP. Empresa consultora especializada en diseño e implementación de
sistemas de gestión de seguridad de la información.
www.seguridadinformacion.com
Norma UNE-ISO/IEC 27001:2007
Tecnología de la información.
Técnicas de seguridad.
Sistemas de Gestión de la Seguridad
de la Información (SGSI). Requisitos
QRUPD

81(,62,(&
HVSDxROD
1RYLHPEUH

7Ë78/2 7HFQRORJtDGHODLQIRUPDFLyQ

7pFQLFDVGHVHJXULGDG

6LVWHPDVGH*HVWLyQGHOD6HJXULGDGGHOD,QIRUPDFLyQ6*6,

5HTXLVLWRV

,62,(&

,QIRUPDWLRQ WHFKQRORJ\ 6HFXULW\ WHFKQLTXHV ,QIRUPDWLRQ VHFXULW\ PDQDJHPHQW V\VWHPV 5HTXLUHPHQWV
,62,(&

7HFKQRORJLHV GH O
LQIRUPDWLRQ 7HFKQLTXHV GH VpFXULWp 6\VWqPHV GH JHVWLRQ GH VpFXULWp GH O
LQIRUPDWLRQ
([LJHQFHV,62,(&

&255(6321'(1&,$ (VWDQRUPDHVLGpQWLFDDOD1RUPD,QWHUQDFLRQDO,62,(&

2%6(59$&,21(6 (VWDQRUPDDQXODUi\VXVWLWXLUiDOD1RUPD81(HO

$17(&('(17(6 (VWD QRUPD KD VLGR HODERUDGD SRU HO FRPLWp WpFQLFR $(1&71 7HFQRORJtD GH OD
,QIRUPDFLyQFX\D6HFUHWDUtDGHVHPSHxD$(7,&

(GLWDGDHLPSUHVDSRU$(125 /$62%6(59$&,21(6$(67('2&80(172+$1'(',5,*,56($
'HSyVLWROHJDO0
3iJLQDV

©$(125 &*pQRYD 7HOpIRQR *UXSR
5HSURGXFFLyQSURKLELGD 0$'5,'(VSDxD )D[
6
,62,(&
Ë1',&(
3iJLQD
35Ï/2*2

,1752'8&&,Ï1
*HQHUDOLGDGHV
(QIRTXHSRUSURFHVR
&RPSDWLELOLGDGFRQRWURVVLVWHPDVGHJHVWLyQ

2%-(72<&$032'($3/,&$&,Ï1
*HQHUDOLGDGHV
$SOLFDFLyQ

1250$63$5$&2168/7$

7e50,126<'(),1,&,21(6

6,67(0$'(*(67,Ï1'(/$6(*85,'$''(/$,1)250$&,Ï1
5HTXLVLWRVJHQHUDOHV
&UHDFLyQ\JHVWLyQGHO6*6,
&UHDFLyQGHO6*6,
,PSOHPHQWDFLyQ\RSHUDFLyQGHO6*6,
6XSHUYLVLyQ\UHYLVLyQGHO6*6,
0DQWHQLPLHQWR\PHMRUDGHO6*6,
5HTXLVLWRVGHODGRFXPHQWDFLyQ
*HQHUDOLGDGHV
&RQWUROGHGRFXPHQWRV
&RQWUROGHUHJLVWURV

5(63216$%,/,'$''(/$',5(&&,Ï1
&RPSURPLVRGHODGLUHFFLyQ
*HVWLyQGHORVUHFXUVRV
3URYLVLyQGHORVUHFXUVRV
&RQFLHQFLDFLyQIRUPDFLyQ\FDSDFLWDFLyQ

$8',725Ë$6,17(51$6'(/6*6,

5(9,6,Ï1'(/6*6,325/$',5(&&,Ï1
*HQHUDOLGDGHV
'DWRVLQLFLDOHVGHODUHYLVLyQ
5HVXOWDGRVGHODUHYLVLyQ

0(-25$'(/6*6,
0HMRUDFRQWLQXD
$FFLyQFRUUHFWLYD
$FFLyQSUHYHQWLYD

$1(;2$1RUPDWLYR 2%-(7,926'(&21752/<&21752/(6

$1(;2%,QIRUPDWLYR /2635,1&,3,26'(/$2&'(<(67$
1250$,17(51$&,21$/

$1(;2&,QIRUPDWLYR &255(6321'(1&,$(175(/$61250$6,62
,62<(67$1250$,17(51$&,21$/

%,%/,2*5$)Ë$
,62,(&

35Ï/2*2

,62 2UJDQL]DFLyQ ,QWHUQDFLRQDO GH 1RUPDOL]DFLyQ H ,(& &RPLVLyQ (OHFWURWpFQLFD ,QWHUQDFLRQDO
FRQVWLWX\HQ HO VLVWHPD HVSHFLDOL]DGR SDUD OD QRUPDOL]DFLyQ D QLYHO PXQGLDO /RV RUJDQLVPRV QDFLRQDOHV
TXH VRQ PLHPEURV GH ,62 R ,(& SDUWLFLSDQ HQ HO GHVDUUROOR GH ODV QRUPDV LQWHUQDFLRQDOHV D WUDYpV GH
FRPLWpVWpFQLFRVHVWDEOHFLGRVSRUODVRUJDQL]DFLRQHVUHVSHFWLYDVSDUDUHDOL]DUDFXHUGRVHQFDPSRVHVSHFt
ILFRV GH OD DFWLYLGDG WpFQLFD /RV FRPLWpV WpFQLFRV GH ,62 H ,(& FRODERUDQ HQ ORV FDPSRV GH LQWHUpV
PXWXR 2WUDV RUJDQL]DFLRQHV LQWHUQDFLRQDOHV JXEHUQDPHQWDOHV \ QR JXEHUQDPHQWDOHV HQ FRODERUDFLyQ
FRQ,62H,(&WDPELpQWRPDQSDUWHHQHOWUDEDMR(QHOFDPSRGHODWHFQRORJtDGHODLQIRUPDFLyQ,62H
,(&KDQHVWDEOHFLGRXQFRPLWpWpFQLFRFRQMXQWRHOGHQRPLQDGR,62,(&-7&

/DV QRUPDV LQWHUQDFLRQDOHV VH UHGDFWDQ GH DFXHUGR FRQ ODV UHJODV HVWDEOHFLGDV HQ OD 3DUWH GH ODV
'LUHFWLYDV,62,(&

/DWDUHDSULQFLSDOGHORVFRPLWpVWpFQLFRVHVHODERUDUQRUPDVLQWHUQDFLRQDOHV/RVSUR\HFWRVGHQRUPDV
LQWHUQDFLRQDOHVDGRSWDGRVSRUORVFRPLWpVWpFQLFRVVHHQYtDQDORVRUJDQLVPRVQDFLRQDOHVPLHPEURVSDUD
VX YRWR /D SXEOLFDFLyQ FRPR QRUPD LQWHUQDFLRQDO UHTXLHUH OD DSUREDFLyQ GH DO PHQRV HO GH ORV
RUJDQLVPRVQDFLRQDOHVPLHPEURVFRQGHUHFKRDYRWR

6H OODPD OD DWHQFLyQ VREUH OD SRVLELOLGDG GH TXH DOJXQRV GH ORV HOHPHQWRV GH HVWD QRUPD LQWHUQDFLRQDO
SXHGDQHVWDUVXMHWRVDGHUHFKRVGHSDWHQWH,62H,(&QRDVXPHQODUHVSRQVDELOLGDGGHODLGHQWLILFDFLyQ
GHGLFKRVGHUHFKRVGHSDWHQWH

/D1RUPD,62,(&KDVLGRHODERUDGDSRUHOVXEFRPLWp6&7pFQLFDVGHVHJXULGDGTXHIRUPD
SDUWHGHOFRPLWpWpFQLFRFRQMXQWR,62,(&-7&7HFQRORJtDVGHODLQIRUPDFLyQ

,62,(&
,1752'8&&,Ï1

*HQHUDOLGDGHV
(VWD QRUPD LQWHUQDFLRQDO SURSRUFLRQD XQ PRGHOR SDUD OD FUHDFLyQ LPSOHPHQWDFLyQ RSHUDFLyQ VXSHUYLVLyQ UHYLVLyQ
PDQWHQLPLHQWR\PHMRUDGHXQ6LVWHPDGH*HVWLyQGHOD6HJXULGDGGHOD,QIRUPDFLyQ6*6,/DDGRSFLyQGHXQ6*6,
GHEHUtDVHUIUXWRGHXQDGHFLVLyQHVWUDWpJLFDGHXQDRUJDQL]DFLyQ(OGLVHxR\ODLPSOHPHQWDFLyQGHO6*6,GHSHQGHQGH
ODVQHFHVLGDGHV\REMHWLYRVGHFDGDRUJDQL]DFLyQDVtFRPRGHVXVUHTXLVLWRVGHVHJXULGDGVXVSURFHVRVVXWDPDxR\
HVWUXFWXUD(VSUHYLVLEOHTXHHVWRVIDFWRUHV\ORVVLVWHPDVTXHORVVRSRUWDQFDPELHQFRQHOWLHPSR/RKDELWXDOHVTXHOD
LPSOHPHQWDFLyQGHXQ6*6,VHDMXVWHDODVQHFHVLGDGHVGHODRUJDQL]DFLyQSRUHMHPSORXQDVLWXDFLyQVHQFLOODUHTXLHUH
XQ6*6,VLPSOH

(VWD QRUPD LQWHUQDFLRQDO VLUYH SDUD TXH FXDOTXLHU SDUWH LQWHUHVDGD \D VHD LQWHUQD R H[WHUQD D OD RUJDQL]DFLyQ SXHGD
HIHFWXDUXQDHYDOXDFLyQGHODFRQIRUPLGDG
(QIRTXHSRUSURFHVR
(VWD QRUPD LQWHUQDFLRQDO DGRSWD XQ HQIRTXH SRU SURFHVR SDUD OD FUHDFLyQ LPSOHPHQWDFLyQ RSHUDFLyQ VXSHUYLVLyQ
UHYLVLyQPDQWHQLPLHQWR\PHMRUDGHO6*6,GHXQDRUJDQL]DFLyQ

8QDRUJDQL]DFLyQWLHQHTXHGHILQLU\JHVWLRQDUQXPHURVDVDFWLYLGDGHVSDUDIXQFLRQDUFRQHILFDFLD&XDOTXLHUDFWLYLGDG
TXH XWLOL]D UHFXUVRV \ VH JHVWLRQD GH PRGR TXH SHUPLWH OD WUDQVIRUPDFLyQ GH XQRV HOHPHQWRV GH ³HQWUDGD´ HQ XQRV
HOHPHQWRVGH³VDOLGD´SXHGHFRQVLGHUDUVHXQSURFHVR$PHQXGRODVDOLGDGHXQSURFHVRVHFRQYLHUWHGLUHFWDPHQWHHQOD
HQWUDGDGHOSURFHVRVLJXLHQWH

/DDSOLFDFLyQGHXQFRQMXQWRGHSURFHVRVHQXQDRUJDQL]DFLyQMXQWRFRQODLGHQWLILFDFLyQGHpVWRV\VXVLQWHUDFFLRQHV\
VXJHVWLyQSXHGHFDOLILFDUVHGH³HQIRTXHSRUSURFHVR´

(OHQIRTXHSRUSURFHVRSDUDODJHVWLyQGHODVHJXULGDGGHODLQIRUPDFLyQTXHVHGHVFULEHHQHVWDQRUPDLQWHUQDFLRQDO
DQLPDDORVXVXDULRVDHQIDWL]DUODLPSRUWDQFLDGH

D FRPSUHQGHU ORV UHTXLVLWRV GH VHJXULGDG GH OD LQIRUPDFLyQ GH XQD RUJDQL]DFLyQ \ OD QHFHVLGDG GH HVWDEOHFHU XQD
SROtWLFDGHVHJXULGDGGHODLQIRUPDFLyQ\VXVREMHWLYRV

E LPSOHPHQWDU\RSHUDUORVFRQWUROHVSDUDDGPLQLVWUDUORVULHVJRVGHVHJXULGDGGHODLQIRUPDFLyQGHXQDRUJDQL]DFLyQ
HQHOPDUFRGHVXVULHVJRVHPSUHVDULDOHVJHQHUDOHV

F VXSHUYLVDU\UHYLVDUHOUHQGLPLHQWR\ODHILFDFLDGHO6*6,\

G DVHJXUDUODPHMRUDFRQWLQXDVREUHODEDVHGHODPHGLFLyQREMHWLYD

(VWDQRUPDLQWHUQDFLRQDOVLJXHHOPRGHOR³3ODQLILFDUKDFHUYHULILFDUDFWXDU´3ODQ'R&KHFN$FWFRQRFLGRFRPRPR
GHOR3'&$TXHVHDSOLFDSDUDHVWUXFWXUDUWRGRVORVSURFHVRVGHO6*6,/DILJXUDPXHVWUDFyPRXQ6*6,SDUWLHQGR
GHORVUHTXLVLWRV\H[SHFWDWLYDVGHVHJXULGDGGHODLQIRUPDFLyQGHODVSDUWHVLQWHUHVDGDV\DWUDYpVGHODVDFFLRQHV\SUR
FHVRVQHFHVDULRVSURGXFHORVHOHPHQWRVGHVDOLGDGHVHJXULGDGGHODLQIRUPDFLyQTXHUHVSRQGHQDGLFKRVUHTXLVLWRV\
H[SHFWDWLYDV/DILJXUDLOXVWUDDVLPLVPRORVYtQFXORVFRQORVSURFHVRVTXHVHGHVFULEHQHQORVFDStWXORV\

/DDGRSFLyQGHOPRGHOR3'&$WDPELpQUHIOHMDUiORVSULQFLSLRVGHILQLGRVHQODV'LUHFWULFHVGHOD2&'(TXH
ULJHQODVHJXULGDGGHORVVLVWHPDV\ODVUHGHVGHLQIRUPDFLyQ(VWDQRUPDLQWHUQDFLRQDOSURSRUFLRQDXQPRGHORUREXVWR
SDUDLPSOHPHQWDUORVSULQFLSLRVGHGLFKDVGLUHFWULFHVTXHULJHQODHYDOXDFLyQGHULHVJRVHOGLVHxR\ODLPSOHPHQWDFLyQ
GHODVHJXULGDGDVtFRPRODJHVWLyQ\ODUHHYDOXDFLyQGHODVHJXULGDG

'LUHFWULFHV GH OD 2&'(SDUD OD 6HJXULGDG GH ORV 6LVWHPDV \ 5HGHV GH ,QIRUPDFLyQ ² +DFLD XQDFXOWXUDGHOD VHJXULGDG 3DUtV 2&'(MXOLR
GHZZZRHFGRUJ
,62,(&
(-(03/2UHTXLVLWRGHVHJXULGDG
8QUHTXLVLWRSRGUtDVHUTXHQLQJXQDYLRODFLyQGHODVHJXULGDGGHODLQIRUPDFLyQGHEHSURYRFDUSHUMXLFLRVHFRQyPLFRV
JUDYHV\RFRPSURPHWHUDODRUJDQL]DFLyQ

(-(03/2H[SHFWDWLYDGHVHJXULGDG
(QHOFDVRGHTXHVHSURGXMHUDXQLQFLGHQWHJUDYHFRPRSRUHMHPSORXQDWDTXHLQIRUPiWLFRDOVLWLRZHEGHFRPHUFLR
HOHFWUyQLFRGHXQDRUJDQL]DFLyQGHEHUtDKDEHUSHUVRQDVFRQVXILFLHQWHIRUPDFLyQHQORVSURFHGLPLHQWRVDGHFXDGRVSDUD
PLQLPL]DUODVFRQVHFXHQFLDV

)LJXUD−0RGHOR3'&$DSOLFDGRDORVSURFHVRVGHO6*6,

3ODQLILFDUFUHDFLyQGHO6*6, 'HILQLUODSROtWLFDREMHWLYRVSURFHVRV\SURFHGLPLHQWRVGHO6*6,UHOHYDQWHVSDUD
JHVWLRQDUHOULHVJR\PHMRUDUODVHJXULGDGGHODLQIRUPDFLyQFRQHOILQGHREWHQHU
UHVXOWDGRVDFRUGHVFRQODVSROtWLFDV\REMHWLYRVJHQHUDOHVGHODRUJDQL]DFLyQ
+DFHULPSOHPHQWDFLyQ\ ,PSOHPHQWDU\RSHUDUODSROtWLFDFRQWUROHVSURFHVRV\SURFHGLPLHQWRVGHO6*6,
RSHUDFLyQGHO6*6,
9HULILFDUVXSHUYLVLyQ\UHYLVLyQ (YDOXDU \ HQ VX FDVR PHGLU HO UHQGLPLHQWR GHO SURFHVR FRQWUD OD SROtWLFD ORV
GHO6*6, REMHWLYRV \ OD H[SHULHQFLD SUiFWLFD GHO 6*6, H LQIRUPDU GH ORV UHVXOWDGRV D OD
'LUHFFLyQSDUDVXUHYLVLyQ
$FWXDUPDQWHQLPLHQWR\PHMRUD $GRSWDU PHGLGDV FRUUHFWLYDV \ SUHYHQWLYDV HQ IXQFLyQ GH ORV UHVXOWDGRV GH OD
GHO6*6, DXGLWRUtDLQWHUQDGHO 6*6, \ GHODUHYLVLyQSRUSDUWHGHOD GLUHFFLyQRGHRWUDV
LQIRUPDFLRQHVUHOHYDQWHVSDUDORJUDUODPHMRUDFRQWLQXDGHO6*6,

&RPSDWLELOLGDGFRQRWURVVLVWHPDVGHJHVWLyQ
(VWDQRUPDLQWHUQDFLRQDOVLJXHODVSDXWDVPDUFDGDVHQODV1RUPDV,62H,62SDUDDVHJXUDUXQD
LPSOHPHQWDFLyQLQWHJUDGD\FRQVLVWHQWHFRQODVPHQFLRQDGDVQRUPDVGHJHVWLyQ'HHVWHPRGRXQVLVWHPDGHJHVWLyQ
ELHQFRQFHELGRSXHGHFXPSOLUORVUHTXLVLWRVGHWRGDVHVDVQRUPDV/DWDEOD&PXHVWUDODUHODFLyQHQWUHORVFDStWXORV
GHHVWDQRUPDLQWHUQDFLRQDO\ODV1RUPDV,62H,62

(VWD QRUPD LQWHUQDFLRQDO HVWi GLVHxDGD SDUD SRVLELOLWDU D XQD RUJDQL]DFLyQ HO DGDSWDU VX 6*6, D ORV UHTXLVLWRV GH ORV
VLVWHPDVGHJHVWLyQPHQFLRQDGRV
,62,(&
,03257$17( (VWD SXEOLFDFLyQ QR SUHWHQGH LQFOXLU WRGDV ODV SURYLVLRQHV QHFHVDULDV HQ XQ FRQWUDWR /RV
XVXDULRVGHODQRUPDVRQUHVSRQVDEOHVGHVXFRUUHFWDDSOLFDFLyQ/DFRQIRUPLGDGFRQHVWDQRUPDLQWHUQDFLRQDO
QRRWRUJDLQPXQLGDGIUHQWHDOFXPSOLPLHQWRGHODVREOLJDFLRQHVOHJDOHV
2%-(72<&$032'($3/,&$&,Ï1

*HQHUDOLGDGHV
(VWDQRUPDLQWHUQDFLRQDODEDUFDWRGRWLSRGHRUJDQL]DFLRQHVSRUHMHPSORHPSUHVDVRUJDQLVPRV\HQWHVS~EOLFRVHQWL
GDGHVVLQiQLPRGHOXFUR\HVSHFLILFDORVUHTXLVLWRVSDUDODFUHDFLyQLPSOHPHQWDFLyQRSHUDFLyQVXSHUYLVLyQUHYLVLyQ
PDQWHQLPLHQWR \ PHMRUD GH XQ 6*6, GRFXPHQWDGR HQ HO PDUFR GH ORV ULHVJRV HPSUHVDULDOHV JHQHUDOHV GH OD
RUJDQL]DFLyQ(VSHFLILFDORVUHTXLVLWRVSDUDHOHVWDEOHFLPLHQWRGHFRQWUROHVGHVHJXULGDGDGDSWDGRVDODVQHFHVLGDGHVGH
XQDRUJDQL]DFLyQRGHSDUWHVGHODPLVPD

(O6*6,HVWiGLVHxDGRFRQHOILQGHDVHJXUDUODVHOHFFLyQGHFRQWUROHVGHVHJXULGDGDGHFXDGRV\SURSRUFLRQDGRVTXH
SURWHMDQORVDFWLYRVGHLQIRUPDFLyQ\GHQJDUDQWtDVDODVSDUWHVLQWHUHVDGDV
127$ /DVUHIHUHQFLDDOWpUPLQR³HPSUHVDULDO´RGH³QHJRFLR´HQHVWDQRUPDLQWHUQDFLRQDOGHEHUtDQLQWHUSUHWDUVHHQXQVHQWLGRDPSOLRDEDUFDQGR
DTXHOODVDFWLYLGDGHVTXHVRQHVHQFLDOHVSDUDDOFDQ]DUORVILQHVTXHSHUVLJXHODRUJDQL]DFLyQ
127$ /D1RUPD,62,(&SURSRUFLRQDXQDJXtDGHLPSODQWDFLyQTXHSXHGHXWLOL]DUVHDOGLVHxDUORVFRQWUROHV
$SOLFDFLyQ
/RVUHTXLVLWRVHVWDEOHFLGRVHQHVWDQRUPDLQWHUQDFLRQDOVRQJHQpULFRV\DSOLFDEOHVDWRGDVODVRUJDQL]DFLRQHVFXDOTXLHUD
TXH VHD VX WLSR WDPDxR \ QDWXUDOH]D &XDQGR XQD RUJDQL]DFLyQ GHFODUD TXH FXPSOH HVWD QRUPD LQWHUQDFLRQDO QR VH
DGPLWLUiODH[FOXVLyQGHQLQJXQRGHORVUHTXLVLWRVGHILQLGRVHQORVFDStWXORV\

7RGDH[FOXVLyQGHFRQWUROHVTXHVHFRQVLGHUHQHFHVDULDSDUDFXPSOLUORVFULWHULRVGHDFHSWDFLyQGHOULHVJRQHFHVLWDVHUMXVWLIL
FDGDPHGLDQWHHYLGHQFLDGHTXHORVULHVJRVDVRFLDGRVKDQVLGRDFHSWDGRVSRUODVSHUVRQDVUHVSRQVDEOHV&XDQGRVHH[FOX\D
DOJ~QFRQWUROQRVHDFHSWDUiQLQJXQDGHFODUDFLyQGHFRQIRUPLGDGFRQHVWDQRUPDLQWHUQDFLRQDODPHQRVTXHWDOHVH[FOXVLRQHV
QRDIHFWHQDODFDSDFLGDG\RUHVSRQVDELOLGDGGHODRUJDQL]DFLyQSDUDJDUDQWL]DUODVHJXULGDGGHODLQIRUPDFLyQGHDFXHUGRFRQ
ORVUHTXLVLWRVGHVHJXULGDGGHULYDGRVGHODHYDOXDFLyQGHULHVJRV\GHORVUHTXLVLWRVOHJDOHVRUHJODPHQWDULRVDSOLFDEOHV

127$ (QODPD\RUtDGHORVFDVRVVLXQDRUJDQL]DFLyQWLHQHLPSODQWDGRXQVLVWHPDGHJHVWLyQGHOSURFHVRGHQHJRFLRSRUHMHPSOR ,62R
,62HVSUHIHULEOHFXPSOLUORVUHTXLVLWRVGHHVWDQRUPDLQWHUQDFLRQDOGHQWURGHOVLVWHPDGHJHVWLyQ\DH[LVWHQWH
1250$63$5$&2168/7$
/DVQRUPDVTXHDFRQWLQXDFLyQVHLQGLFDQVRQLQGLVSHQVDEOHVSDUDODDSOLFDFLyQGHHVWDQRUPD3DUDODVUHIHUHQFLDVFRQ
IHFKDVyORVHDSOLFDODHGLFLyQFLWDGD3DUDODVUHIHUHQFLDVVLQIHFKDVHDSOLFDOD~OWLPDHGLFLyQGHODQRUPDLQFOX\HQGR
FXDOTXLHUPRGLILFDFLyQGHpVWD
,62,(&7HFQRORJtDGHODLQIRUPDFLyQ7pFQLFDVGHVHJXULGDG&yGLJRGHEXHQDVSUiFWLFDVSDUDODJHVWLyQ
GHODVHJXULGDGGHODLQIRUPDFLyQ
7e50,126<'(),1,&,21(6
3DUDORVILQHVGHOSUHVHQWHGRFXPHQWRVHDSOLFDQODVVLJXLHQWHVGHILQLFLRQHV

DFWLYR
&XDOTXLHUELHQTXHWLHQHYDORUSDUDODRUJDQL]DFLyQ
>,62,(&@

GLVSRQLELOLGDG
/DSURSLHGDGGHVHUDFFHVLEOH\XWLOL]DEOHSRUXQDHQWLGDGDXWRUL]DGD
>,62,(&@
,62,(&
FRQILGHQFLDOLGDG
/D SURSLHGDG SRU OD TXH OD LQIRUPDFLyQ QR VH SRQH D GLVSRVLFLyQ R VH UHYHOD D LQGLYLGXRV HQWLGDGHV R SURFHVRV QR
DXWRUL]DGRV

>,62,(&@
VHJXULGDGGHODLQIRUPDFLyQ
/DSUHVHUYDFLyQGHODFRQILGHQFLDOLGDGODLQWHJULGDG\ODGLVSRQLELOLGDGGHODLQIRUPDFLyQSXGLHQGRDGHPiVDEDUFDU
RWUDVSURSLHGDGHVFRPRODDXWHQWLFLGDGODUHVSRQVDELOLGDGODILDELOLGDG\HOQRUHSXGLR

>,62,(&@
HYHQWRGHVHJXULGDGGHODLQIRUPDFLyQ
/DRFXUUHQFLDGHWHFWDGDHQXQHVWDGRGHXQVLVWHPDVHUYLFLRRUHGTXHLQGLFDXQDSRVLEOHYLRODFLyQGHODSROtWLFDGH
VHJXULGDGGHODLQIRUPDFLyQXQIDOORGHODVVDOYDJXDUGDVRXQDVLWXDFLyQGHVFRQRFLGDKDVWDHOPRPHQWR\TXHSXHGHVHU
UHOHYDQWHSDUDODVHJXULGDG

>,62,(&75@
LQFLGHQWHGHVHJXULGDGGHODLQIRUPDFLyQ
XQ~QLFRHYHQWRRXQDVHULHGHHYHQWRVGHVHJXULGDGGHODLQIRUPDFLyQLQHVSHUDGRVRQRGHVHDGRVTXHWLHQHQXQDSUR
EDELOLGDGVLJQLILFDWLYDGHFRPSURPHWHUODVRSHUDFLRQHVHPSUHVDULDOHV\GHDPHQD]DUODVHJXULGDGGHODLQIRUPDFLyQ

>,62,(&75@
6LVWHPD GH *HVWLyQ GH OD 6HJXULGDG GH OD ,QIRUPDFLyQ 6*6, >,QIRUPDWLRQ 6HFXULW\ 0DQDJHPHQW 6\VWHP
,606@
/DSDUWHGHOVLVWHPDGHJHVWLyQJHQHUDOEDVDGDHQXQHQIRTXHGHULHVJRHPSUHVDULDOTXHVHHVWDEOHFHSDUDFUHDULPSOH
PHQWDURSHUDUVXSHUYLVDUUHYLVDUPDQWHQHU\PHMRUDUODVHJXULGDGGHODLQIRUPDFLyQ

127$ (OVLVWHPDGHJHVWLyQLQFOX\HODHVWUXFWXUDRUJDQL]DWLYDODVSROtWLFDVODVDFWLYLGDGHVGHSODQLILFDFLyQODVUHVSRQVDELOLGDGHVODVSUiFWLFDVORV
SURFHGLPLHQWRVORVSURFHVRV\ORVUHFXUVRV
LQWHJULGDG
/DSURSLHGDGGHVDOYDJXDUGDUODH[DFWLWXG\FRPSOHWLWXGGHORVDFWLYRV

>,62,(&@
ULHVJRUHVLGXDO
5LHVJRUHPDQHQWHTXHH[LVWHGHVSXpVGHTXHVHKD\DQWRPDGRODVPHGLGDVGHVHJXULGDG

>,62,(&*XLGH@
DFHSWDFLyQGHOULHVJR
/DGHFLVLyQGHDFHSWDUXQULHVJR

>,62,(&*XLGH@
DQiOLVLVGHULHVJRV
8WLOL]DFLyQVLVWHPiWLFDGHODLQIRUPDFLyQGLVSRQLEOHSDUDLGHQWLILFDUSHOLJURV\HVWLPDUORVULHVJRV

>,62,(&*XLGH@
,62,(&
HYDOXDFLyQGHULHVJRV
(OSURFHVRJHQHUDOGHDQiOLVLV\HVWLPDFLyQGHORVULHVJRV
>,62,(&*XLGH@
HVWLPDFLyQGHULHVJRV
(OSURFHVRGHFRPSDUDFLyQGHOULHVJRHVWLPDGRFRQORVFULWHULRVGHULHVJRSDUDDVtGHWHUPLQDUODLPSRUWDQFLDGHOULHVJR
>,62,(&*XLGH@
JHVWLyQGHULHVJRV
$FWLYLGDGHVFRRUGLQDGDVSDUDGLULJLU\FRQWURODUXQDRUJDQL]DFLyQFRQUHVSHFWRDORVULHVJRV
>,62,(&*XLGH@
WUDWDPLHQWRGHULHVJRV
(OSURFHVRGHVHOHFFLyQHLPSOHPHQWDFLyQGHODVPHGLGDVHQFDPLQDGDVDPRGLILFDUORVULHVJRV
>,62,(&*XLGH@

127$ (QHVWDQRUPDLQWHUQDFLRQDOHOWpUPLQR³FRQWURO´VHXWLOL]DFRPRVLQyQLPRGH³PHGLGDGHVHJXULGDG´
GHFODUDFLyQGHDSOLFDELOLGDG
'HFODUDFLyQGRFXPHQWDGDTXHGHVFULEHORVREMHWLYRVGHFRQWURO\ORVFRQWUROHVTXHVRQUHOHYDQWHVSDUDHO6*6,GHOD
RUJDQL]DFLyQ\DSOLFDEOHVDOPLVPR

127$ /RVREMHWLYRVGHFRQWURO\ORVFRQWUROHVVHEDVDQHQORVUHVXOWDGRV\FRQFOXVLRQHVGHODHYDOXDFLyQGHULHVJRV\HQORVSURFHVRVGHWUDWDPLHQWR
GHOULHVJRHQORVUHTXLVLWRVOHJDOHVRUHJODPHQWDULRVHQODVREOLJDFLRQHVFRQWUDFWXDOHV\HQODVQHFHVLGDGHVHPSUHVDULDOHVGHODRUJDQL]DFLyQ
HQPDWHULDGHVHJXULGDGGHODLQIRUPDFLyQ

6,67(0$'(*(67,Ï1'(/$6(*85,'$''(/$,1)250$&,Ï1

5HTXLVLWRVJHQHUDOHV
/DRUJDQL]DFLyQGHEHFUHDULPSOHPHQWDURSHUDUVXSHUYLVDUUHYLVDUPDQWHQHU\PHMRUDUXQ6*6,GRFXPHQWDGRGHQWUR
GHOFRQWH[WRGHODVDFWLYLGDGHVHPSUHVDULDOHVJHQHUDOHVGHODRUJDQL]DFLyQ\GHORVULHVJRVTXHpVWDDIURQWD$HIHFWRVGH
HVWDQRUPDLQWHUQDFLRQDOHOSURFHVRXWLOL]DGRVHEDVDHQHOPRGHOR3'&$GHVFULWRHQODILJXUD

&UHDFLyQGHO6*6,
/DRUJDQL]DFLyQGHEHKDFHUORVLJXLHQWH

D 'HILQLU HO DOFDQFH \ ORV OtPLWHV GHO 6*6, HQ WpUPLQRV GH ODV FDUDFWHUtVWLFDV GH OD DFWLYLGDG HPSUHVDULDO GH OD
RUJDQL]DFLyQVXXELFDFLyQVXVDFWLYRV\WHFQRORJtDLQFOX\HQGRORVGHWDOOHV\ODMXVWLILFDFLyQGHFXDOTXLHUH[FOXVLyQ
GHODOFDQFHYpDVH

E 'HILQLUXQDSROtWLFDGHO6*6,DFRUGHFRQODVFDUDFWHUtVWLFDVGHODDFWLYLGDGHPSUHVDULDOODRUJDQL]DFLyQVXXELFD
FLyQVXVDFWLYRV\WHFQRORJtDTXH
LQFOX\DXQPDUFRSDUDODILMDFLyQGHREMHWLYRV\HVWDEOH]FDXQDRULHQWDFLyQJHQHUDOVREUHODVGLUHFWULFHV\SULQ
FLSLRVGHDFWXDFLyQHQUHODFLyQFRQODVHJXULGDGGHODLQIRUPDFLyQ
WHQJDHQFXHQWDORVUHTXLVLWRVGHODDFWLYLGDGHPSUHVDULDOORVUHTXLVLWRVOHJDOHVRUHJODPHQWDULRV\ODVREOLJDFLR
QHVGHVHJXULGDGFRQWUDFWXDOHV
HVWpDOLQHDGDFRQHOFRQWH[WRGHODHVWUDWHJLDGHJHVWLyQGHULHVJRVGHODRUJDQL]DFLyQFRQWH[WRHQHOTXHWHQGUi
OXJDUODFUHDFLyQ\HOPDQWHQLPLHQWRGHO6*6,
,62,(&
HVWDEOH]FDFULWHULRVGHHVWLPDFLyQGHOULHVJR>YpDVHF@\
VHDDSUREDGDSRUOD'LUHFFLyQ

127$ $HIHFWRVGHHVWDQRUPDLQWHUQDFLRQDOODSROtWLFDGHVHJXULGDGGHODLQIRUPDFLyQVHFRQVLGHUDXQVXEFRQMXQWRGHODSROtWLFDGHO6*6,
(VWDVSROtWLFDVSXHGHQHVWDUGHVFULWDVHQXQ~QLFRGRFXPHQWR

F 'HILQLUHOHQIRTXHGHODHYDOXDFLyQGHULHVJRVGHODRUJDQL]DFLyQ
(VSHFLILFDUXQDPHWRGRORJtDGHHYDOXDFLyQGHULHVJRVDGHFXDGDSDUDHO6*6,ODVQHFHVLGDGHVGHQHJRFLRLGHQWL
ILFDGDVHQPDWHULDGHVHJXULGDGGHODLQIRUPDFLyQGHODHPSUHVD\ORVUHTXLVLWRVOHJDOHV\UHJODPHQWDULRV
'HVDUUROODUFULWHULRVGHDFHSWDFLyQGHULHVJR\ILMDUORVQLYHOHVGHULHVJRDFHSWDEOHV>YpDVHI@

/DPHWRGRORJtDVHOHFFLRQDGDSDUDODHYDOXDFLyQGHULHVJRVGHEHDVHJXUDUTXHODVHYDOXDFLRQHVGHULHVJRVJHQHUHQ
UHVXOWDGRVFRPSDUDEOHV\UHSURGXFLEOHV

127$ +D\GLIHUHQWHVPHWRGRORJtDVSDUDODHYDOXDFLyQGHULHVJRV(QOD1RUPD ,62,(&757HFQRORJtDGHODLQIRUPDFLyQ'LUHF
WULFHVSDUDODJHVWLyQGHODVHJXULGDGGH7,7pFQLFDVGHJHVWLyQGHODVHJXULGDGGH7,VHFRPHQWDQDOJXQRVHMHPSORVGHPHWRGRORJtDV
SDUDODHYDOXDFLyQGHULHVJRV

G ,GHQWLILFDUORVULHVJRV
,GHQWLILFDUORVDFWLYRVTXHHVWiQGHQWURGHOiPELWRGHDSOLFDFLyQGHO6*6,\DORVSURSLHWDULRVGHHVWRVDFWLYRV
,GHQWLILFDUODVDPHQD]DVDTXHHVWiQH[SXHVWRVHVRVDFWLYRV
,GHQWLILFDUODVYXOQHUDELOLGDGHVEDMRODVTXHSRGUtDQDFWXDUGLFKDVDPHQD]DV
,GHQWLILFDUORVLPSDFWRVTXHVREUHORVDFWLYRVSXHGHWHQHUXQDSpUGLGDGHFRQILGHQFLDOLGDGLQWHJULGDG\GLVSRQL
ELOLGDGHQORVPLVPRV

H $QDOL]DU\YDORUDUORVULHVJRV
(YDOXDUORVHIHFWRVHQODDFWLYLGDGHPSUHVDULDOGHODRUJDQL]DFLyQTXHSXGLHUDQGHULYDUVHGHHYHQWXDOHVIDOORVGH
VHJXULGDGWHQLHQGRHQFXHQWDODVFRQVHFXHQFLDVGHXQDSpUGLGDGHFRQILGHQFLDOLGDGLQWHJULGDGRGLVSRQLELOLGDG
GHORVDFWLYRV
(YDOXDUODSUREDELOLGDGGHXQDIRUPDUHDOLVWDGHTXHVHSURGX]FDQIDOORVGHVHJXULGDGDODOX]GHODVDPHQD]DV\
YXOQHUDELOLGDGHVH[LVWHQWHVORVLPSDFWRVDVRFLDGRVDORVDFWLYRV\ORVFRQWUROHVLPSOHPHQWDGRV
(VWLPDUORVQLYHOHVGHULHVJR
'HWHUPLQDUVLORVULHVJRVVRQDFHSWDEOHVRVLUHTXLHUHQXQWUDWDPLHQWRFRQIRUPHDORVFULWHULRVGHDFHSWDFLyQGH
ULHVJRVHVWDEOHFLGRVHQF

I ,GHQWLILFDU\HYDOXDUODVRSFLRQHVSDUDHOWUDWDPLHQWRGHULHVJRV

/DVSRVLEOHVDFFLRQHVDUHDOL]DUHQWUHRWUDVVRQODVVLJXLHQWHV
DSOLFDUFRQWUROHVDGHFXDGRV
DVXPLUORVULHVJRVGHPDQHUDFRQVFLHQWH\REMHWLYDFRQIRUPHDODVSROtWLFDVGHODRUJDQL]DFLyQ\DORVFULWHULRV
GHDFHSWDFLyQGHULHVJRV>YpDVHF@
HYLWDUORVULHVJRV\
WUDQVIHULUORVULHVJRVDVRFLDGRVDODDFWLYLGDGHPSUHVDULDODRWUDVSDUWHVFRPRSRUHMHPSORFRPSDxtDVGHVHJXURV
RSURYHHGRUHV

(OWpUPLQR³SURSLHWDULR´VHUHILHUHDXQLQGLYLGXRRXQDHQWLGDGDOTXHVHOHKDDVLJQDGRODUHVSRQVDELOLGDGDGPLQLVWUDWLYDSDUDHOFRQWUROGHOD
SURGXFFLyQ HO GHVDUUROOR HO PDQWHQLPLHQWR HO XVR \ OD VHJXULGDG GH ORV DFWLYRV (O WpUPLQR ³SURSLHWDULR´ QR VLJQLILFD TXH OD SHUVRQD WHQJD
UHDOPHQWHDOJ~QGHUHFKRGHSURSLHGDGVREUHHODFWLYR
,62,(&
J 6HOHFFLRQDUORVREMHWLYRVGHFRQWURO\ORVFRQWUROHVSDUDHOWUDWDPLHQWRGHORVULHVJRV

/RV REMHWLYRV GH FRQWURO \ ORV FRQWUROHV GHEHQ VHOHFFLRQDUVH H LPSOHPHQWDUVH SDUD FXPSOLU ORV UHTXLVLWRV LGHQWL
ILFDGRVHQODHYDOXDFLyQGHULHVJRV\HQHOSURFHVRGHWUDWDPLHQWRGHULHVJRV(VWDVHOHFFLyQGHEHWHQHUHQFXHQWDORV
FULWHULRVGHDFHSWDFLyQGHULHVJRV>YpDVHF@DGHPiVGHORVUHTXLVLWRVOHJDOHVUHJODPHQWDULRV\FRQWUDFWXDOHV

/RVREMHWLYRVGHFRQWURO\ORVFRQWUROHVGHODQH[R$GHEHQVHOHFFLRQDUVHFRPRSDUWHGHHVWHSURFHVRHQODPHGLGDHQ
TXHVLUYDQSDUDVDWLVIDFHUORVUHTXLVLWRVLGHQWLILFDGRV

/RVREMHWLYRVGHFRQWURO\ORVFRQWUROHVHQXPHUDGRVHQHODQH[R$QRVRQH[KDXVWLYRVSRUORTXHSXHGHQVHOHFFLR
QDUVHRWURVREMHWLYRVGHFRQWURO\RWURVFRQWUROHVDGLFLRQDOHV

127$ (ODQH[R$FRQWLHQHXQDOLVWDFRPSOHWDGHREMHWLYRVGHFRQWURO\FRQWUROHVTXHVHKDQFRQVLGHUDGRFRP~QPHQWHUHOHYDQWHVHQODVRUJDQL
]DFLRQHV(ODQH[R$SURSRUFLRQDDORVXVXDULRVGHHVWDQRUPDLQWHUQDFLRQDOXQSXQWRGHSDUWLGDSDUDVHOHFFLRQDUORVFRQWUROHVJDUDQ
WL]DQGRTXHQRVHSDVDQSRUDOWRLPSRUWDQWHVRSFLRQHVGHFRQWURO

K 2EWHQHUODDSUREDFLyQSRUSDUWHGHOD'LUHFFLyQGHORVULHVJRVUHVLGXDOHVSURSXHVWRV

L 2EWHQHUODDXWRUL]DFLyQGHOD'LUHFFLyQSDUDLPSOHPHQWDU\RSHUDUHO6*6,

M (ODERUDUXQDGHFODUDFLyQGHDSOLFDELOLGDG

8QDGHFODUDFLyQGHDSOLFDELOLGDGGHEHLQFOXLUORVLJXLHQWH
ORVREMHWLYRVGHFRQWURO\ORVFRQWUROHVVHOHFFLRQDGRVHQJ\ODVMXVWLILFDFLRQHVGHVXVHOHFFLyQ
ORVREMHWLYRVGHFRQWURO\ORVFRQWUROHVDFWXDOPHQWHLPSOHPHQWDGRV>YpDVHH@\
ODH[FOXVLyQGHFXDOTXLHUREMHWLYRGHFRQWURO\FRQWUROGHODQH[R$\ODMXVWLILFDFLyQGHHVWDH[FOXVLyQ

127$ /DGHFODUDFLyQGHDSOLFDELOLGDGSURSRUFLRQDXQUHVXPHQGHODVGHFLVLRQHVUHODWLYDVDOWUDWDPLHQWRGHORVULHVJRV/DMXVWLILFDFLyQGHODV
H[FOXVLRQHVIDFLOLWDXQDFRPSUREDFLyQFUX]DGDGHTXHQRVHKDRPLWLGRLQDGYHUWLGDPHQWHQLQJ~QFRQWURO

,PSOHPHQWDFLyQ\RSHUDFLyQGHO6*6,
/DRUJDQL]DFLyQGHEHKDFHUORTXHVHLQGLFDDFRQWLQXDFLyQ
D )RUPXODUXQSODQGHWUDWDPLHQWRGHULHVJRVTXHLGHQWLILTXHODVDFFLRQHVGHOD'LUHFFLyQORVUHFXUVRVODVUHVSRQVD
ELOLGDGHV\ODVSULRULGDGHVDGHFXDGRVSDUDJHVWLRQDUORVULHVJRVGHODVHJXULGDGGHODLQIRUPDFLyQYpDVH
E ,PSOHPHQWDUHOSODQGHWUDWDPLHQWRGHULHVJRVSDUDORJUDUORVREMHWLYRVGHFRQWUROLGHQWLILFDGRVTXHWHQJDHQFXHQWD
ODILQDQFLDFLyQ\ODDVLJQDFLyQGHIXQFLRQHV\UHVSRQVDELOLGDGHV
F ,PSOHPHQWDUORVFRQWUROHVVHOHFFLRQDGRVHQJSDUDFXPSOLUORVREMHWLYRVGHFRQWURO
G 'HILQLUHOPRGRGHPHGLUODHILFDFLDGHORVFRQWUROHVRGHORVJUXSRVGHFRQWUROHVVHOHFFLRQDGRV\HVSHFLILFDUFyPR
WLHQHQ TXH XVDUVH HVWDV PHGLFLRQHV SDUD HYDOXDU OD HILFDFLD GH ORV FRQWUROHV GH FDUD D SURGXFLU XQRV UHVXOWDGRV
FRPSDUDEOHV\UHSURGXFLEOHV>YpDVHF@
127$ /DPHGLFLyQGHODHILFDFLDGHORVFRQWUROHVSHUPLWHDORVGLUHFWLYRV\DOSHUVRQDOGHWHUPLQDUKDVWDTXpSXQWRORVFRQWUROHVFXPSOHQORV
REMHWLYRVGHFRQWUROSODQLILFDGRV
H ,PSOHPHQWDUSURJUDPDVGHIRUPDFLyQ\GHFRQFLHQFLDFLyQYpDVH
I *HVWLRQDUODRSHUDFLyQGHO6*6,
J *HVWLRQDUORVUHFXUVRVGHO6*6,YpDVH
K ,PSOHPHQWDUSURFHGLPLHQWRV\RWURVFRQWUROHVTXHSHUPLWDQXQDGHWHFFLyQWHPSUDQDGHHYHQWRVGHVHJXULGDG\XQD
UHVSXHVWDDQWHFXDOTXLHULQFLGHQWHGHVHJXULGDG>YpDVHD@
,62,(&
6XSHUYLVLyQ\UHYLVLyQGHO6*6,
/DRUJDQL]DFLyQGHEHKDFHUORTXHVHLQGLFDDFRQWLQXDFLyQ

D (MHFXWDUSURFHGLPLHQWRVGHVXSHUYLVLyQ\UHYLVLyQDVtFRPRRWURVPHFDQLVPRVGHFRQWUROSDUD
GHWHFWDUORDQWHVSRVLEOHORVHUURUHVHQORVUHVXOWDGRVGHOSURFHVDGR
LGHQWLILFDUORDQWHVSRVLEOHODVGHELOLGDGHVGHOVLVWHPDGHVHJXULGDGDVtFRPRHODSURYHFKDPLHQWRGHpVWDVWDQWR
FRQRVLQp[LWR\ORVLQFLGHQWHV
SHUPLWLUDOD'LUHFFLyQGHWHUPLQDUVLODVDFWLYLGDGHVGHVHJXULGDGGHOHJDGDVHQRWUDVSHUVRQDVROOHYDGDVDFDER
SRUPHGLRVLQIRUPiWLFRVRDWUDYpVGHWHFQRORJtDVGHODLQIRUPDFLyQGDQORVUHVXOWDGRVHVSHUDGRV
D\XGDU D GHWHFWDU HYHQWRV GH VHJXULGDG \ SRU WDQWR D SUHYHQLU LQFLGHQWHV GH VHJXULGDG PHGLDQWH HO XVR GH
LQGLFDGRUHV\
GHWHUPLQDUVLODVDFFLRQHVWRPDGDVSDUDUHVROYHUXQDYLRODFLyQGHODVHJXULGDGKDQVLGRHILFDFHV

E 5HDOL]DU UHYLVLRQHV SHULyGLFDV GH OD HILFDFLD GHO 6*6, WHQLHQGR HQ FXHQWD ORV UHVXOWDGRV GH ODV DXGLWRUtDV GH
VHJXULGDGORVLQFLGHQWHVORVUHVXOWDGRVGHODVPHGLFLRQHVGHODHILFDFLDODVVXJHUHQFLDVDVtFRPRORVFRPHQWDULRV
GHWRGDVODVSDUWHVLQWHUHVDGDV(VWDVUHYLVLRQHVLQFOX\HQHOFXPSOLPLHQWRGHODSROtWLFD\GHORVREMHWLYRVGHO6*6,
\ODUHYLVLyQGHORVFRQWUROHVGHVHJXULGDG

F 0HGLUODHILFDFLDGHORVFRQWUROHVSDUDYHULILFDUVLVHKDQFXPSOLGRORVUHTXLVLWRVGHVHJXULGDG

G 5HYLVDUODVHYDOXDFLRQHVGHULHVJRVHQLQWHUYDORVSODQLILFDGRV\UHYLVDUORVULHVJRVUHVLGXDOHV\ORVQLYHOHVGHULHVJR
DFHSWDEOHVTXHKDQVLGRLGHQWLILFDGRVWHQLHQGRHQFXHQWDORVFDPELRVHQ
ODRUJDQL]DFLyQ
ODWHFQRORJtD
ORVREMHWLYRV\UHTXLVLWRVHPSUHVDULDOHV
ODVDPHQD]DVLGHQWLILFDGDV
ODHILFDFLDGHORVFRQWUROHVLPSOHPHQWDGRV\
ORV IDFWRUHV H[WHUQRV FRPR SRU HMHPSOR ORV FDPELRV GHO HQWRUQR OHJDO R UHJODPHQWDULR GH ODV REOLJDFLRQHV
FRQWUDFWXDOHV\GHOFOLPDVRFLDO

H 5HDOL]DUODVDXGLWRUtDVLQWHUQDVGHO6*6,HQLQWHUYDORVSODQLILFDGRVYpDVH

127$ /DVDXGLWRUtDVLQWHUQDVDYHFHVGHQRPLQDGDVDXGLWRUtDVSRUSULPHUDSDUWHODVOOHYDDFDERODSURSLDRUJDQL]DFLyQRELHQVHUHDOL]DQSRU
HQFDUJRGHpVWDFRQILQHVLQWHUQRV

I 5HDOL]DU SRU SDUWH GH OD 'LUHFFLyQ XQD UHYLVLyQ GHO 6*6, FRQ FDUiFWHU UHJXODU SDUD DVHJXUDU TXH HO iPELWR GH
DSOLFDFLyQVLJXHVLHQGRDGHFXDGR\TXHVHLGHQWLILFDQPHMRUDVGHOSURFHVRGHO6*6,YpDVH

J $FWXDOL]DUORVSODQHVGHVHJXULGDGWHQLHQGRHQFXHQWDODVFRQFOXVLRQHVGHODVDFWLYLGDGHVGHVXSHUYLVLyQ\UHYLVLyQ

K 5HJLVWUDUODVDFFLRQHVHLQFLGHQFLDVTXHSXGLHUDQDIHFWDUDODHILFDFLDRDOIXQFLRQDPLHQWRGHO6*6,YpDVH

0DQWHQLPLHQWR\PHMRUDGHO6*6,
5HJXODUPHQWHODRUJDQL]DFLyQGHEHKDFHUORTXHVHLQGLFDDFRQWLQXDFLyQ

D ,PSOHPHQWDUHQHO6*6,ODVPHMRUDVLGHQWLILFDGDV

E $SOLFDUODVPHGLGDVFRUUHFWLYDV\SUHYHQWLYDVDGHFXDGDVGHDFXHUGRFRQORVDSDUWDGRV\VREUHODEDVHGHOD
H[SHULHQFLDHQPDWHULDGHVHJXULGDGGHODSURSLDRUJDQL]DFLyQ\GHRWUDVRUJDQL]DFLRQHV
,62,(&
F &RPXQLFDUODVDFFLRQHV\PHMRUDVDWRGDVODVSDUWHVLQWHUHVDGDVFRQXQQLYHOGHGHWDOOHDFRUGHFRQODVFLUFXQVWDQFLDV

G $VHJXUDUTXHODVPHMRUDVDOFDQFHQORVREMHWLYRVSUHYLVWRV
5HTXLVLWRVGHODGRFXPHQWDFLyQ

*HQHUDOLGDGHV
/DGRFXPHQWDFLyQGHEHLQFOXLUODVGHFLVLRQHVGHOD'LUHFFLyQMXQWRFRQORVUHJLVWURVUHFRUGVGHODVPLVPDVGHELHQGR
TXHGDU FRQVWDQFLD GH TXH ODV DFFLRQHV GDQ UHVSXHVWD D ODV GHFLVLRQHV \ D ODV SROtWLFDV DGRSWDGDV \ JDUDQWL]DQGR TXH
GLFKRVGRFXPHQWRV\ORVFRUUHVSRQGLHQWHVUHJLVWURVHVWiQGLVSRQLEOHV

127$1$&,21$/ 6HJ~Q UHFRJH OD 1RUPD 81(,62 HO LQJOpV SRVHH WUHV WpUPLQRV GLVWLQWRV GRFXPHQWV UHFRUGV \ DUFKLYHV SDUD
GHVLJQDUORTXHHQFDVWHOODQRFRPRHQHOUHVWRGHOHQJXDVODWLQDVFXHQWDFRQXQD~QLFDYR]GRFXPHQWRV$VtGRFXPHQWHV
HO HTXLYDOHQWH GH GRFXPHQWR HQ VX VLJQLILFDGR JHQpULFR FRPR PHUD LQIRUPDFLyQ UHJLVWUDGD 3RU HO FRQWUDULR ORV WpUPLQRV
UHFRUGV\DUFKLYHVGHVLJQDQGHPDQHUDHVSHFtILFDDDTXHOORVGRFXPHQWRVSURGXFLGRVFRPRSUXHED\UHIOHMRGHODVDFWLYLGDGHV
GHODRUJDQL]DFLyQTXHORVKDFUHDGRUHVHUYiQGRVHHOHPSOHRGHHVWH~OWLPRDORVGRFXPHQWRVGHFDUiFWHUKLVWyULFR

127$1$&,21$/ 8QUHJLVWURGLVSRQLEOHHVDTXpOTXHSXHGHVHUORFDOL]DGRUHFXSHUDGRSUHVHQWDGRHLQWHUSUHWDGR

(V LPSRUWDQWH SRGHU GHPRVWUDU OD UHODFLyQ GH ORV FRQWUROHV VHOHFFLRQDGRV FRQ ORV UHVXOWDGRV GH ORV SURFHVRV GH
HYDOXDFLyQ\GHWUDWDPLHQWRGHULHVJRV\SRUWDQWRFRQODSROtWLFD\REMHWLYRVGHO6*6,

/DGRFXPHQWDFLyQGHO6*6,GHEHLQFOXLU
D GHFODUDFLRQHVGRFXPHQWDGDVGHODSROtWLFD>YpDVHE@\GHORVREMHWLYRVGHO6*6,
E HODOFDQFHGHO6*6,>YpDVHD@
F ORVSURFHGLPLHQWRV\PHFDQLVPRVGHFRQWUROTXHVRSRUWDQDO6*6,
G XQDGHVFULSFLyQGHODPHWRGRORJtDGHHYDOXDFLyQGHULHVJRV>YpDVHF@
H HOLQIRUPHGHHYDOXDFLyQGHULHVJRV>YpDVHFDJ@
I HOSODQGHWUDWDPLHQWRGHULHVJRV>YpDVHE@
J ORVSURFHGLPLHQWRVGRFXPHQWDGRVTXHQHFHVLWDODRUJDQL]DFLyQSDUDDVHJXUDUXQDFRUUHFWDSODQLILFDFLyQRSHUDFLyQ\
FRQWURO GH VXV SURFHVRV GH VHJXULGDG GH OD LQIRUPDFLyQ \ SDUD GHVFULELU FyPR PHGLU OD HILFDFLD GH ORV FRQWUROHV
>YpDVHF@
K ORVUHJLVWURVUHTXHULGRVSRUHVWDQRUPDLQWHUQDFLRQDOYpDVH\
L ODGHFODUDFLyQGHDSOLFDELOLGDG

127$ &XDQGR HQ HVWD QRUPD LQWHUQDFLRQDO DSDUHFH HO WpUPLQR ³SURFHGLPLHQWR GRFXPHQWDGR´ VLJQLILFD TXH HO SURFHGLPLHQWR VH FUHD VH
GRFXPHQWDVHLPSOHPHQWD\VHPDQWLHQH

127$ /DH[WHQVLyQGHODGRFXPHQWDFLyQGHO6*6,SXHGHGLIHULUGHXQDRUJDQL]DFLyQDRWUDGHELGRD
− HOWDPDxR\WLSRGHDFWLYLGDGHVGHODRUJDQL]DFLyQ\
− HODOFDQFH\ODFRPSOHMLGDGGHORVUHTXLVLWRVGHVHJXULGDG\GHOVLVWHPDTXHVHHVWiJHVWLRQDQGR

127$ /RVGRFXPHQWRV\UHJLVWURVSXHGHQHVWDUHQFXDOTXLHUIRUPDWRRWLSRGHPHGLR

&RQWUROGHGRFXPHQWRV
/RV GRFXPHQWRV H[LJLGRV SRU HO 6*6, YpDVH GHEHQ HVWDU SURWHJLGRV \ FRQWURODGRV 6H GHEH HVWDEOHFHU XQ
SURFHGLPLHQWRGRFXPHQWDGRSDUDGHILQLUODVDFFLRQHVGHJHVWLyQQHFHVDULDVSDUD

D DSUREDUHQIRUPDORVGRFXPHQWRVSUHYLDPHQWHDVXGLVWULEXFLyQ
,62,(&
E UHYLVDUDFWXDOL]DU\YROYHUDDSUREDUORVGRFXPHQWRVVHJ~QYD\DVLHQGRQHFHVDULR

F DVHJXUDUTXHHVWiQLGHQWLILFDGRVORVFDPELRVDVtFRPRHOHVWDGRGHOGRFXPHQWRTXHFRQWLHQHOD~OWLPDUHYLVLyQ

G DVHJXUDUTXHODVYHUVLRQHVFRUUHVSRQGLHQWHVGHORVGRFXPHQWRVHVWiQGLVSRQLEOHV

H DVHJXUDUTXHORVGRFXPHQWRVSHUPDQHFHQOHJLEOHV\IiFLOPHQWHLGHQWLILFDEOHV

I DVHJXUDU TXH ORV GRFXPHQWRV HVWiQ GLVSRQLEOHV SDUD WRGR DTXHO TXH ORV QHFHVLWD \ VH WUDQVILHUHQ DOPDFHQDQ \ VH
GHVWUX\HQGHDFXHUGRFRQORVSURFHGLPLHQWRVDSOLFDEOHVDVXFODVLILFDFLyQ

J DVHJXUDUTXHORVGRFXPHQWRVSURFHGHQWHVGHOH[WHULRUHVWiQLGHQWLILFDGRV

K DVHJXUDUTXHODGLVWULEXFLyQGHORVGRFXPHQWRVHVWiFRQWURODGD

L SUHYHQLUHOXVRQRLQWHQFLRQDGRGHGRFXPHQWRVREVROHWRV\

M DSOLFDUXQDLGHQWLILFDFLyQDGHFXDGDDORVGRFXPHQWRVREVROHWRVTXHVRQUHWHQLGRVFRQDOJ~QSURSyVLWR

&RQWUROGHUHJLVWURV
6HGHEHQFUHDU\PDQWHQHUUHJLVWURVSDUDSURSRUFLRQDUHYLGHQFLDVGHODFRQIRUPLGDGFRQORVUHTXLVLWRV\GHOIXQFLRQD
PLHQWRHILFD]GHO6*6,'LFKRVUHJLVWURVGHEHQHVWDSURWHJLGRV\FRQWURODGRV(O6*6,GHEHWHQHUHQFXHQWDFXDOTXLHU
UHTXLVLWROHJDORUHJXODWRULRDSOLFDEOHDVtFRPRODVREOLJDFLRQHVFRQWUDFWXDOHV/RVUHJLVWURVGHEHQSHUPDQHFHUOHJLEOHV
IiFLOPHQWH LGHQWLILFDEOHV \ UHFXSHUDEOHV /RV FRQWUROHV QHFHVDULRV SDUD OD LGHQWLILFDFLyQ DOPDFHQDPLHQWR SURWHFFLyQ
UHFXSHUDFLyQUHWHQFLyQ\GLVSRVLFLyQGHORVUHJLVWURVGHEHQHVWDUGRFXPHQWDGRVHLPSOHPHQWDGRV

'HEHQFRQVHUYDUVHORVUHJLVWURVGHOGHVDUUROORGHOSURFHVRVHJ~QVHLQGLFDHQ\GHWRGRVORVVXFHVRVGHULYDGRVGH
LQFLGHQWHVGHVHJXULGDGVLJQLILFDWLYRVUHODWLYRVDO6*6,

(-(03/2
(MHPSORVGHUHJLVWURVVRQHOOLEURGHYLVLWDVORVLQIRUPHVGHDXGLWRUtD\ORVIRUPXODULRVGHDXWRUL]DFLyQGHDFFHVRFXP
SOLPHQWDGRV

5(63216$%,/,'$''(/$',5(&&,Ï1

&RPSURPLVRGHOD'LUHFFLyQ
/D 'LUHFFLyQ GHEH VXPLQLVWUDU HYLGHQFLDV GH VX FRPSURPLVR SDUD FUHDU LPSOHPHQWDU RSHUDU VXSHUYLVDU UHYLVDU
PDQWHQHU\PHMRUDUHO6*6,DWUDYpVGHODVVLJXLHQWHVDFFLRQHV
D IRUPXODQGRODSROtWLFDGHO6*6,
E YHODQGRSRUHOHVWDEOHFLPLHQWRGHORVREMHWLYRV\SODQHVGHO6*6,
F HVWDEOHFLHQGRORVUROHV\UHVSRQVDELOLGDGHVHQPDWHULDGHVHJXULGDGGHODLQIRUPDFLyQ
G FRPXQLFDQGRDODRUJDQL]DFLyQODLPSRUWDQFLDGHFXPSOLUORVREMHWLYRV\ODSROtWLFDGHVHJXULGDGGHODLQIRUPDFLyQ
VXVUHVSRQVDELOLGDGHVOHJDOHV\ODQHFHVLGDGGHODPHMRUDFRQWLQXD
H SURSRUFLRQDQGR UHFXUVRV VXILFLHQWHV SDUD FUHDU LPSOHPHQWDU RSHUDU VXSHUYLVDU UHYLVDU PDQWHQHU \ PHMRUDU HO
6*6,YpDVH
I GHFLGLHQGRORVFULWHULRVGHDFHSWDFLyQGHULHVJRV\ORVQLYHOHVDFHSWDEOHVGHULHVJR
J YHODQGRSRUTXHVHUHDOLFHQODVDXGLWRUtDVLQWHUQDVGHO6*6,YpDVH\
K GLULJLHQGRODVUHYLVLRQHVGHO6*6,YpDVH
,62,(&
*HVWLyQGHORVUHFXUVRV

3URYLVLyQGHORVUHFXUVRV
/DRUJDQL]DFLyQGHEHGHWHUPLQDU\SURSRUFLRQDUORVUHFXUVRVQHFHVDULRVSDUD
D HVWDEOHFHULPSOHPHQWDURSHUDUVXSHUYLVDUUHYLVDUPDQWHQHU\PHMRUDUHO6*6,
E DVHJXUDUTXHORVSURFHGLPLHQWRVGHVHJXULGDGGHODLQIRUPDFLyQUHVSRQGHQDORVUHTXLVLWRVHPSUHVDULDOHV
F LGHQWLILFDU\FXPSOLUORVUHTXLVLWRVOHJDOHV\UHJODPHQWDULRVDVtFRPRODVREOLJDFLRQHVGHVHJXULGDGFRQWUDFWXDOHV
G PDQWHQHUODVHJXULGDGDGHFXDGDPHGLDQWHODDSOLFDFLyQFRUUHFWDGHWRGRVORVFRQWUROHVLPSODQWDGRV
H OOHYDUDFDERUHYLVLRQHVFXDQGRVHDQQHFHVDULDV\UHDFFLRQDUHQEDVHDORVUHVXOWDGRVGHHVWDVUHYLVLRQHV\
I FXDQGRVHUHTXLHUDPHMRUDUODHILFDFLDGHO6*6,

/DRUJDQL]DFLyQGHEHDVHJXUDUVHGHTXHWRGRHOSHUVRQDODOTXHVHOHKD\DQDVLJQDGRUHVSRQVDELOLGDGHVGHILQLGDVHQHO
6*6,VHDFRPSHWHQWHSDUDOOHYDUDFDERODVWDUHDVUHTXHULGDVDWUDYpVGH
D GHWHUPLQDUODVFRPSHWHQFLDVQHFHVDULDVSDUDHOSHUVRQDOTXHOOHYDDFDERWUDEDMRVTXHDIHFWHQDO6*6,
E LPSDUWLU IRUPDFLyQ R UHDOL]DURWUDV DFFLRQHV SRU HMHPSOR OD FRQWUDWDFLyQ GH SHUVRQDO FRPSHWHQWH SDUD VDWLVIDFHU
HVWDVQHFHVLGDGHV
F HYDOXDUODHILFDFLDGHODVDFFLRQHVUHDOL]DGDV\
G PDQWHQHUUHJLVWURVGHHGXFDFLyQIRUPDFLyQDSWLWXGHVH[SHULHQFLD\FXDOLILFDFLRQHVYpDVH

/DRUJDQL]DFLyQGHEHDVHJXUDUVHWDPELpQGHTXHWRGRHOSHUVRQDODIHFWDGRVHDFRQVFLHQWHGHODWUDVFHQGHQFLD\GHOD
LPSRUWDQFLDGHODVDFWLYLGDGHVGHVHJXULGDGGHODLQIRUPDFLyQ\GHVXFRQWULEXFLyQDORVREMHWLYRVGHO6*6,

$8',725Ë$6,17(51$6'(/6*6,
/DRUJDQL]DFLyQGHEHUHDOL]DUDXGLWRUtDVLQWHUQDVGHO6*6,DLQWHUYDORVSODQLILFDGRVSDUDGHWHUPLQDUVLORVREMHWLYRVGH
FRQWUROORVFRQWUROHVORVSURFHVRV\ORVSURFHGLPLHQWRVGHHVWH6*6,
D FXPSOHQORVUHTXLVLWRVGHHVWDQRUPDLQWHUQDFLRQDODVtFRPRODOHJLVODFLyQ\QRUPDWLYDDSOLFDEOHV
E FXPSOHQORVUHTXLVLWRVGHVHJXULGDGGHODLQIRUPDFLyQLGHQWLILFDGRV
F VHLPSODQWDQ\VHPDQWLHQHQGHIRUPDHIHFWLYD\
G GDQHOUHVXOWDGRHVSHUDGR

6HGHEHSODQLILFDUXQSURJUDPDGHDXGLWRUtDVWHQLHQGRHQFXHQWDHOHVWDGRHLPSRUWDQFLDGHORVSURFHVRV\ODViUHDVD
DXGLWDUDVtFRPRORVUHVXOWDGRVGHODVDXGLWRUtDVSUHYLDV6HGHEHQGHILQLUORVFULWHULRVHODOFDQFHODIUHFXHQFLD\ORV
PpWRGRVGHDXGLWRUtD/DVHOHFFLyQGHDXGLWRUHV\ODGLUHFFLyQGHODVDXGLWRUtDVGHEHJDUDQWL]DUODREMHWLYLGDGHLPSDU
FLDOLGDGGHOSURFHVRGHDXGLWRUtD/RVDXGLWRUHVQRGHEHQDXGLWDUVXSURSLRWUDEDMR

/DVUHVSRQVDELOLGDGHV \ORVUHTXLVLWRVSDUDODSODQLILFDFLyQUHDOL]DFLyQGHODVDXGLWRUtDVODLQIRUPDFLyQGHORVUHVXO
WDGRV\HOPDQWHQLPLHQWRGHORVUHJLVWURVYpDVHGHEHQHVWDUGHILQLGRVHQXQSURFHGLPLHQWRGRFXPHQWDGR

(O UHVSRQVDEOH GHO iUHD DXGLWDGD GHEH YHODU SRU TXH VH UHDOLFHQ DFFLRQHV SDUD HOLPLQDU VLQ GHPRUDV LQGHELGDV ODV
GLVFRQIRUPLGDGHVGHWHFWDGDV\VXVFDXVDV/DVDFWLYLGDGHVGHVHJXLPLHQWRGHEHQLQFOXLUODYHULILFDFLyQGHODVDFFLRQHV
UHDOL]DGDV\ORVLQIRUPHVGHORVUHVXOWDGRVGHODYHULILFDFLyQYpDVH

127$ /D1RUPD,62'LUHFWULFHVSDUDODDXGLWRUtDGHORVVLVWHPDVGHJHVWLyQGHODFDOLGDG\RDPELHQWDOSURSRUFLRQDRULHQWDFLRQHV
~WLOHVSDUDUHDOL]DUODVDXGLWRUtDVLQWHUQDVGHO6*6,
,62,(&
5(9,6,Ï1'(/6*6,325/$',5(&&,Ï1

*HQHUDOLGDGHV
/D'LUHFFLyQGHEHUHYLVDUHO6*6,GHODRUJDQL]DFLyQDLQWHUYDORVSODQLILFDGRVDOPHQRVXQDYH]DODxRSDUDDVHJXUDU
TXHVHPDQWLHQHVXFRQYHQLHQFLDDGHFXDFLyQ\HILFDFLD(VWDUHYLVLyQGHEHFRQWHPSODUODVRSRUWXQLGDGHVGHPHMRUD\OD
QHFHVLGDGGHFDPELRVHQHO6*6,LQFOX\HQGRODSROtWLFD\ORVREMHWLYRVGHVHJXULGDGGHODLQIRUPDFLyQ/RVUHVXOWDGRV
GHODVUHYLVLRQHVGHEHQHVWDUFODUDPHQWHGRFXPHQWDGRV\VHGHEHQPDQWHQHUORVUHJLVWURVYpDVH
'DWRVLQLFLDOHVGHODUHYLVLyQ
/RVGDWRVXWLOL]DGRVSRUOD'LUHFFLyQSDUDODUHYLVLyQGHEHQLQFOXLU
D ORVUHVXOWDGRVGHODVDXGLWRUtDV\UHYLVLRQHVGHO6*6,
E ORVFRPHQWDULRVGHODVSDUWHVLQWHUHVDGDV
F ODV WpFQLFDV SURGXFWRV R SURFHGLPLHQWRV TXH SRGUtDQ XWLOL]DUVH GHQWUR GH OD RUJDQL]DFLyQ SDUD PHMRUDU HO
FRPSRUWDPLHQWR\ODHILFDFLDGHO6*6,
G HOHVWDGRGHODVDFFLRQHVSUHYHQWLYDVRFRUUHFWLYDV
H ODVYXOQHUDELOLGDGHVRDPHQD]DVQRDERUGDGDVDGHFXDGDPHQWHHQODHYDOXDFLyQGHULHVJRVSUHYLD
I ORVUHVXOWDGRVGHODVPHGLFLRQHVGHODHILFDFLD
J ODVDFFLRQHVGHVHJXLPLHQWRGHODVUHYLVLRQHVDQWHULRUHV
K FXDOTXLHUFDPELRTXHSXGLHUDDIHFWDUDO6*6,\
L ODVUHFRPHQGDFLRQHVGHPHMRUD
5HVXOWDGRVGHODUHYLVLyQ
/RVUHVXOWDGRVGHODUHYLVLyQUHDOL]DGDSRUOD'LUHFFLyQGHEHQLQFOXLUFXDOTXLHUGHFLVLyQ\DFFLyQUHODWLYDVD

D ODPHMRUDGHODHILFDFLDGHO6*6,

E ODDFWXDOL]DFLyQGHODHYDOXDFLyQGHULHVJRV\GHOSODQGHWUDWDPLHQWRGHULHVJRV

F OD PRGLILFDFLyQ GH ORV SURFHGLPLHQWRV \ FRQWUROHV TXH DIHFWDQ D OD VHJXULGDG GH OD LQIRUPDFLyQ FXDQGR VHD
QHFHVDULRSDUDUHVSRQGHUDORVHYHQWRVLQWHUQRVRH[WHUQRVTXHSXHGHQDIHFWDUDO6*6,LQFOX\HQGRORVFDPELRVHQ
ORVUHTXLVLWRVGHOQHJRFLR
ORVUHTXLVLWRVGHVHJXULGDG
ORVSURFHVRVGHQHJRFLRTXHDIHFWDQDORVUHTXLVLWRVGHQHJRFLRH[LVWHQWHV
ORVUHTXLVLWRVOHJDOHVRUHJODPHQWDULRV
ODVREOLJDFLRQHVFRQWUDFWXDOHV\
ORVQLYHOHVGHULHVJR\RORVFULWHULRVGHDFHSWDFLyQGHORVULHVJRV

G ODVQHFHVLGDGHVGHUHFXUVRV

H ODPHMRUDHQHOPRGRGHPHGLUODHILFDFLDGHORVFRQWUROHV
,62,(&
0(-25$'(/6*6,

0HMRUDFRQWLQXD
/DRUJDQL]DFLyQGHEHPHMRUDUGHPDQHUDFRQWLQXDODHILFDFLDGHO6*6,PHGLDQWHHOXVRGHODSROtWLFD\GHORVREMHWLYRV
GHVHJXULGDGGHODLQIRUPDFLyQGHORVUHVXOWDGRVGHODVDXGLWRUtDVGHODQiOLVLVGHODPRQLWRUL]DFLyQGHHYHQWRVGHODV
DFFLRQHVFRUUHFWLYDV\SUHYHQWLYDV\GHODVUHYLVLRQHVGHOD'LUHFFLyQYpDVH
$FFLyQFRUUHFWLYD
/DRUJDQL]DFLyQGHEHUHDOL]DUDFFLRQHVSDUDHOLPLQDUODFDXVDGHODVQRFRQIRUPLGDGHVFRQORVUHTXLVLWRVGHO6*6,DILQ
GHHYLWDUTXHYXHOYDQDSURGXFLUVH(OSURFHGLPLHQWRGRFXPHQWDGRSDUDODVDFFLRQHVFRUUHFWLYDVGHEHGHILQLUORVUHTXL
VLWRVSDUD

D LGHQWLILFDUODVQRFRQIRUPLGDGHV

E GHWHUPLQDUODVFDXVDVGHODVQRFRQIRUPLGDGHV

F HYDOXDUODQHFHVLGDGGHDGRSWDUDFFLRQHVSDUDDVHJXUDUVHGHTXHODVQRFRQIRUPLGDGHVQRYXHOYDQDSURGXFLUVH

G GHWHUPLQDUHLPSODQWDUODVDFFLRQHVFRUUHFWLYDVQHFHVDULDV

H UHJLVWUDUORVUHVXOWDGRVGHODVDFFLRQHVUHDOL]DGDVYpDVH\

I UHYLVDUODVDFFLRQHVFRUUHFWLYDVUHDOL]DGDV
$FFLyQSUHYHQWLYD
/DRUJDQL]DFLyQGHEHGHWHUPLQDUODVDFFLRQHVQHFHVDULDVSDUDHOLPLQDUODFDXVDGHODVSRVLEOHVQRFRQIRUPLGDGHVFRQ
ORV UHTXLVLWRV GHO 6*6, SDUD HYLWDU TXH pVWDV YXHOYDQ D SURGXFLUVH /DV DFFLRQHV SUHYHQWLYDV DGRSWDGDV GHEHQ VHU
DSURSLDGDV HQ UHODFLyQ D ORV HIHFWRV GH ORV SUREOHPDV SRWHQFLDOHV (O SURFHGLPLHQWR GRFXPHQWDGR SDUD ODV DFFLRQHV
SUHYHQWLYDVGHEHGHILQLUORVUHTXLVLWRVSDUD

D LGHQWLILFDUODVSRVLEOHVQRFRQIRUPLGDGHV\VXVFDXVDV

E HYDOXDUODQHFHVLGDGGHDGRSWDUDFFLRQHVSDUDSUHYHQLUODRFXUUHQFLDGHQRFRQIRUPLGDGHV

F GHWHUPLQDUHLPSOHPHQWDUODVDFFLRQHVSUHYHQWLYDVQHFHVDULDV

G UHJLVWUDUORVUHVXOWDGRVGHODVDFFLRQHVDGRSWDGDVYpDVH\

H UHYLVDUODVDFFLRQHVSUHYHQWLYDVDGRSWDGDV

/DRUJDQL]DFLyQGHEHLGHQWLILFDUORVFDPELRVHQORVULHVJRVDVtFRPRORVUHTXLVLWRVGHODVDFFLRQHVSUHYHQWLYDVFHQ
WUDQGRODDWHQFLyQHQORVULHVJRVTXHKD\DQVXIULGRFDPELRVVLJQLILFDWLYRV

/DSULRULGDGGHODVDFFLRQHVSUHYHQWLYDVGHEHGHWHUPLQDUVHEDViQGRVHHQORVUHVXOWDGRVGHODHYDOXDFLyQGHULHVJRV

127$ $FWXDUSDUDSUHYHQLUODVQRFRQIRUPLGDGHVVXHOHVHUPiVUHQWDEOHTXHUHDOL]DUDFFLRQHVFRUUHFWLYDV

,62,(&
$1(;2$1RUPDWLYR

2%-(7,926'(&21752/<&21752/(6

/RVREMHWLYRVGHFRQWURO\ORVFRQWUROHVLQGLFDGRVHQODWDEOD$WLHQHQFRUUHVSRQGHQFLDGLUHFWDFRQORVHVWDEOHFLGRVHQ
OD1RUPD,62,(&FDStWXORVD/DVOLVWDVGHODWDEOD$QRVRQH[KDXVWLYDV\XQDRUJDQL]DFLyQSXHGH
FRQVLGHUDUTXHVRQQHFHVDULRVREMHWLYRVGHFRQWURO\FRQWUROHVDGLFLRQDOHV/RVREMHWLYRVGHFRQWURO\ORVFRQWUROHVTXH
ILJXUDQHQHVWDVWDEODVGHEHQVHUVHOHFFLRQDGRVFRPRSDUWHGHOSURFHVRGHO6*6,HVSHFLILFDGRHQHODSDUWDGR

/RVFDStWXORVDGHOD1RUPD,62,(&RIUHFHQDVHVRUDPLHQWRSDUDODLPSODQWDFLyQMXQWRFRQXQDJXtD
GHEXHQDVSUiFWLFDVGHDSR\RDORVFRQWUROHVHVSHFLILFDGRVHQORVSXQWRV$KDVWD$

7DEOD$−2EMHWLYRVGHFRQWURO\FRQWUROHV

$3ROtWLFDGHVHJXULGDG
$3ROtWLFDGHVHJXULGDGGHODLQIRUPDFLyQ
2EMHWLYR3URSRUFLRQDULQGLFDFLRQHVSDUDODJHVWLyQ\VRSRUWHGHODVHJXULGDGGHODLQIRUPDFLyQGHDFXHUGRFRQORV
UHTXLVLWRVHPSUHVDULDOHV\FRQODOHJLVODFLyQ\ODVQRUPDWLYDVDSOLFDEOHV
&RQWURO/D'LUHFFLyQGHEHDSUREDUXQGRFXPHQWRGHSR
'RFXPHQWRGHSROtWLFDGHVHJXULGDGGHOD
$ OtWLFDGHVHJXULGDGGHODLQIRUPDFLyQSXEOLFDUOR\GLVWUL
LQIRUPDFLyQ
EXLUORDWRGRVORVHPSOHDGRV\WHUFHURVDIHFWDGRV
&RQWURO/DSROtWLFDGHVHJXULGDGGHODLQIRUPDFLyQGHEH
5HYLVLyQGHODSROtWLFDGHVHJXULGDGHOD UHYLVDUVHDLQWHUYDORVSODQLILFDGRVRVLHPSUHTXHVHSUR
$
LQIRUPDFLyQ GX]FDQFDPELRVVLJQLILFDWLYRVDILQGHDVHJXUDUTXHVH
PDQWHQJDVXLGRQHLGDGDGHFXDFLyQ\HILFDFLD
$$VSHFWRVRUJDQL]DWLYRVGHODVHJXULGDGGHODLQIRUPDFLyQ
$2UJDQL]DFLyQLQWHUQD
2EMHWLYR*HVWLRQDUODVHJXULGDGGHODLQIRUPDFLyQGHQWURGHODRUJDQL]DFLyQ
&RQWURO/D'LUHFFLyQGHEHSUHVWDUXQDSR\RDFWLYRDOD
VHJXULGDGGHQWURGHODRUJDQL]DFLyQDWUDYpVGHGLUHFWULFHV
&RPLWpGHJHVWLyQGHVHJXULGDGGHOD
$ FODUDVXQFRPSURPLVRGHPRVWUDGRDVLJQDFLRQHVH[SOtFLWDV
LQIRUPDFLyQ
\HOUHFRQRFLPLHQWRGHODVUHVSRQVDELOLGDGHVGHVHJXULGDG
GHODLQIRUPDFLyQ
&RQWURO/DVDFWLYLGDGHVUHODWLYDVDODVHJXULGDGGHODLQ
&RRUGLQDFLyQGHODVHJXULGDGGHOD IRUPDFLyQGHEHQVHUFRRUGLQDGDVHQWUHORVUHSUHVHQWDQWHV
$
LQIRUPDFLyQ GHODVGLIHUHQWHVSDUWHVGHODRUJDQL]DFLyQFRQVXVFRUUHV
SRQGLHQWHVUROHV\IXQFLRQHVGHWUDEDMR
$ $VLJQDFLyQGHUHVSRQVDELOLGDGHVUHODWLYDVD &RQWURO'HEHQGHILQLUVHFODUDPHQWHWRGDVODVUHVSRQVDEL
ODVHJXULGDGGHODLQIRUPDFLyQ OLGDGHVUHODWLYDVDODVHJXULGDGGHODLQIRUPDFLyQ
&RQWURO3DUDFDGDQXHYRUHFXUVRGHSURFHVDGRGHODLQ
3URFHVRGHDXWRUL]DFLyQGHUHFXUVRVSDUDHO
$ IRUPDFLyQGHEHGHILQLUVHHLPSODQWDUVHXQSURFHVRGH
SURFHVDGRGHODLQIRUPDFLyQ
DXWRUL]DFLyQSRUSDUWHGHOD'LUHFFLyQ
&RQWURO'HEHGHWHUPLQDUVH\UHYLVDUVHSHULyGLFDPHQWHOD
QHFHVLGDGGHHVWDEOHFHUDFXHUGRVGHFRQILGHQFLDOLGDGRQR
$ $FXHUGRVGHFRQILGHQFLDOLGDG
UHYHODFLyQTXHUHIOHMHQODVQHFHVLGDGHVGHODRUJDQL]DFLyQ
SDUDODSURWHFFLyQGHODLQIRUPDFLyQ
,62,(&
$ &RQWURO'HEHQPDQWHQHUVHORVFRQWDFWRVDGHFXDGRVFRQ
&RQWDFWRFRQODVDXWRULGDGHV
ODVDXWRULGDGHVFRPSHWHQWHV
&RQWURO'HEHQPDQWHQHUVHORVFRQWDFWRVDSURSLDGRVFRQ
$ &RQWDFWRFRQJUXSRVGHHVSHFLDOLQWHUpV JUXSRVGHLQWHUpVHVSHFLDOXRWURVIRURV\DVRFLDFLRQHV
SURIHVLRQDOHVHVSHFLDOL]DGRVHQVHJXULGDG
&RQWURO(OHQIRTXHGHODRUJDQL]DFLyQSDUDODJHVWLyQGHOD
VHJXULGDGGHODLQIRUPDFLyQ\VXLPSODQWDFLyQHVGHFLU
ORVREMHWLYRVGHFRQWUROORVFRQWUROHVODVSROtWLFDVORV
5HYLVLyQLQGHSHQGLHQWHGHODVHJXULGDGGH
$ SURFHVRV\ORVSURFHGLPLHQWRVSDUDODVHJXULGDGGHOD
ODLQIRUPDFLyQ
LQIRUPDFLyQGHEHVRPHWHUVHDXQDUHYLVLyQLQGHSHQGLHQWH
DLQWHUYDORVSODQLILFDGRVRVLHPSUHTXHVHSURGX]FDQ
FDPELRVVLJQLILFDWLYRVHQODLPSODQWDFLyQGHODVHJXULGDG
$7HUFHURV
2EMHWLYR0DQWHQHUODVHJXULGDGGHODLQIRUPDFLyQGHODRUJDQL]DFLyQ\GHORVGLVSRVLWLYRVGHSURFHVDGRGHOD
LQIRUPDFLyQTXHVRQREMHWRGHDFFHVRWUDWDPLHQWRFRPXQLFDFLyQRJHVWLyQSRUWHUFHURV
&RQWURO'HEHQLGHQWLILFDUVHORVULHVJRVSDUDODLQIRUPD
FLyQ\SDUDORVGLVSRVLWLYRVGHSURFHVDGRGHODLQIRUPDFLyQ
,GHQWLILFDFLyQGHORVULHVJRVGHULYDGRVGHO
$ GHODRUJDQL]DFLyQGHULYDGRVGHORVSURFHVRVGHQHJRFLR
DFFHVRGHWHUFHURV
TXHUHTXLHUDQGHWHUFHURVHLPSODQWDUORVFRQWUROHV
DSURSLDGRVDQWHVGHRWRUJDUHODFFHVR
&RQWURO$QWHVGHRWRUJDUDFFHVRDORVFOLHQWHVDORVDFWLYRV
7UDWDPLHQWRGHODVHJXULGDGHQODUHODFLyQ
$ RDODLQIRUPDFLyQGHODRUJDQL]DFLyQGHEHQWUDWDUVHWRGRV
FRQORVFOLHQWHV
ORVUHTXLVLWRVGHVHJXULGDGLGHQWLILFDGRV
&RQWURO/RVDFXHUGRVFRQWHUFHURVTXHFRQOOHYHQDFFHVR
WUDWDPLHQWRFRPXQLFDFLyQRJHVWLyQELHQGHOD
LQIRUPDFLyQGHODRUJDQL]DFLyQRGHORVUHFXUVRVGH
7UDWDPLHQWRGHODVHJXULGDGHQFRQWUDWRV
$ WUDWDPLHQWRGHODLQIRUPDFLyQRELHQODLQFRUSRUDFLyQGH
FRQWHUFHURV
SURGXFWRVRVHUYLFLRVDORVUHFXUVRVGHWUDWDPLHQWRGHOD
LQIRUPDFLyQGHEHQFXEULUWRGRVORVUHTXLVLWRVGHVHJXULGDG
SHUWLQHQWHV
$*HVWLyQGHDFWLYRV
$5HVSRQVDELOLGDGVREUHORVDFWLYRV
2EMHWLYR&RQVHJXLU\PDQWHQHUXQDSURWHFFLyQDGHFXDGDGHORVDFWLYRVGHODRUJDQL]DFLyQ
&RQWURO7RGRVORVDFWLYRVGHEHQHVWDUFODUDPHQWHLGHQWLIL
$ ,QYHQWDULRGHDFWLYRV FDGRV\GHEHHODERUDUVH\PDQWHQHUVHXQLQYHQWDULRGH
WRGRVORVDFWLYRVLPSRUWDQWHV
&RQWURO7RGDODLQIRUPDFLyQ\DFWLYRVDVRFLDGRVFRQORV
UHFXUVRVSDUDHOWUDWDPLHQWRGHODLQIRUPDFLyQGHEHQWHQHU
$ 3URSLHGDGGHORVDFWLYRV
XQSURSLHWDULRTXHIRUPHSDUWHGHODRUJDQL]DFLyQ\KD\D
VLGRGHVLJQDGRFRPRSURSLHWDULR
&RQWURO6HGHEHQLGHQWLILFDUGRFXPHQWDUHLPSODQWDUODV
UHJODVSDUDHOXVRDFHSWDEOHGHODLQIRUPDFLyQ\ORVDFWLYRV
$ 8VRDFHSWDEOHGHORVDFWLYRV
DVRFLDGRVFRQORVUHFXUVRVSDUDHOSURFHVDGRGHOD
LQIRUPDFLyQ

([SOLFDFLyQ(OWpUPLQR³SURSLHWDULR´VHUHILHUHDODSHUVRQDRHQWLGDGDODTXHVHOHKDDVLJQDGRODUHVSRQVDELOLGDGDGPLQLVWUDWLYDGHOFRQWUROGH
ODSURGXFFLyQGHVDUUROORPDQWHQLPLHQWRXVR\VHJXULGDGGHORVDFWLYRV(OWpUPLQR³SURSLHWDULR´QRVLJQLILFDTXHODSHUVRQDWHQJDUHDOPHQWH
DOJ~QGHUHFKRGHSURSLHGDGVREUHHODFWLYR
,62,(&
$&ODVLILFDFLyQGHODLQIRUPDFLyQ
2EMHWLYR$VHJXUDUTXHODLQIRUPDFLyQUHFLEHXQQLYHODGHFXDGRGHSURWHFFLyQ
&RQWURO/DLQIRUPDFLyQGHEHVHUFODVLILFDGDVHJ~QVX
$ 'LUHFWULFHVGHFODVLILFDFLyQ YDORUORVUHTXLVLWRVOHJDOHVODVHQVLELOLGDG\ODFULWLFLGDG
SDUDODRUJDQL]DFLyQ
&RQWURO6HGHEHGHVDUUROODUHLPSODQWDUXQFRQMXQWR
DGHFXDGRGHSURFHGLPLHQWRVSDUDHWLTXHWDU\PDQHMDUOD
$ (WLTXHWDGR\PDQLSXODGRGHODLQIRUPDFLyQ
LQIRUPDFLyQGHDFXHUGRFRQHOHVTXHPDGHFODVLILFDFLyQ
DGRSWDGRSRUODRUJDQL]DFLyQ
$6HJXULGDGOLJDGDDORVUHFXUVRVKXPDQRV
$$QWHVGHOHPSOHR
2EMHWLYR$VHJXUDUTXHORVHPSOHDGRVORVFRQWUDWLVWDV\ORVWHUFHURVHQWLHQGHQVXVUHVSRQVDELOLGDGHV\VRQDGHFXDGRV
SDUDOOHYDUDFDERODVIXQFLRQHVTXHOHVFRUUHVSRQGHQDVtFRPRSDUDUHGXFLUHOULHVJRGHURERIUDXGHRGHXVR
LQGHELGRGHORVUHFXUVRV
&RQWURO/DVIXQFLRQHV\UHVSRQVDELOLGDGHVGHVHJXULGDGGH
ORVHPSOHDGRVFRQWUDWLVWDV\WHUFHURVVHGHEHQGHILQLU\
$ )XQFLRQHV\UHVSRQVDELOLGDGHV
GRFXPHQWDUGHDFXHUGRFRQODSROtWLFDGHVHJXULGDGGHOD
LQIRUPDFLyQGHODRUJDQL]DFLyQ
&RQWURO/DFRPSUREDFLyQGHORVDQWHFHGHQWHVGHWRGRVORV
FDQGLGDWRVDOSXHVWRGHWUDEDMRGHORVFRQWUDWLVWDVRGHORV
WHUFHURVVHGHEHOOHYDUDFDERGHDFXHUGRFRQODVOHJLVOD
$ ,QYHVWLJDFLyQGHDQWHFHGHQWHV FLRQHVQRUPDWLYDV\FyGLJRVpWLFRVTXHVHDQGHDSOLFDFLyQ
\GHXQDPDQHUDSURSRUFLRQDGDDORVUHTXLVLWRVGHO
QHJRFLRODFODVLILFDFLyQGHODLQIRUPDFLyQDODTXHVH
DFFHGH\ORVULHVJRVFRQVLGHUDGRV
&RQWURO&RPRSDUWHGHVXVREOLJDFLRQHVFRQWUDFWXDOHVORV
HPSOHDGRVORVFRQWUDWLVWDV\ORVWHUFHURVGHEHQDFHSWDU\
$ 7pUPLQRV\FRQGLFLRQHVGHFRQWUDWDFLyQ ILUPDUORVWpUPLQRV\FRQGLFLRQHVGHVXFRQWUDWRGHWUDEDMR
TXHGHEHHVWDEOHFHUVXVUHVSRQVDELOLGDGHV\ODVGHODRU
JDQL]DFLyQHQORUHODWLYRDVHJXULGDGGHODLQIRUPDFLyQ
$'XUDQWHHOHPSOHR
2EMHWLYR$VHJXUDUTXHWRGRVORVHPSOHDGRVFRQWUDWLVWDV\WHUFHURVVRQFRQVFLHQWHVGHODVDPHQD]DV\SUREOHPDVTXH
DIHFWDQDODVHJXULGDGGHODLQIRUPDFLyQ\GHVXVUHVSRQVDELOLGDGHV\REOLJDFLRQHV\GHTXHHVWiQSUHSDUDGRVSDUD
FXPSOLUODSROtWLFDGHVHJXULGDGGHODRUJDQL]DFLyQHQHOGHVDUUROORKDELWXDOGHVXWUDEDMR\SDUDUHGXFLUHOULHVJRGH
HUURUKXPDQR
&RQWURO/D'LUHFFLyQGHEHH[LJLUDORVHPSOHDGRVFRQ
WUDWLVWDV\WHUFHURVTXHDSOLTXHQODVHJXULGDGGHDFXHUGR
$ 5HVSRQVDELOLGDGHVGHOD'LUHFFLyQ
FRQODVSROtWLFDV\SURFHGLPLHQWRVHVWDEOHFLGRVHQOD
RUJDQL]DFLyQ
&RQWURO7RGRVORVHPSOHDGRVGHODRUJDQL]DFLyQ\FXDQGR
FRUUHVSRQGDORVFRQWUDWLVWDV\WHUFHURVGHEHQUHFLELUXQD
$ DGHFXDGDFRQFLHQFLDFLyQ\IRUPDFLyQFRQDFWXDOL]DFLRQHV
HQVHJXULGDGGHODLQIRUPDFLyQ
SHULyGLFDVVREUHODVSROtWLFDV\SURFHGLPLHQWRVGHODRUJD
QL]DFLyQVHJ~QFRUUHVSRQGDFRQVXSXHVWRGHWUDEDMR

([SOLFDFLyQ/DSDODEUD³HPSOHR´XWLOL]DGDHQHVWHGRFXPHQWRKDFHUHIHUHQFLDDGLVWLQWDVVLWXDFLRQHVFRQWUDWDFLyQGHSHUVRQDOWHPSRUDORGHODU
JDGXUDFLyQQRPEUDPLHQWRGHFDUJRVFDPELRGHFDUJRVDVLJQDFLyQGHFRQWUDWLVWDV\WHUPLQDFLyQGHFXDOTXLHUDGHHVWRVDFXHUGRVRFRPSUR
PLVRV
,62,(&
&RQWURO'HEHH[LVWLUXQSURFHVRGLVFLSOLQDULRIRUPDOSDUD
$ 3URFHVRGLVFLSOLQDULR ORVHPSOHDGRVTXHKD\DQSURYRFDGRDOJXQDYLRODFLyQGHOD
VHJXULGDG
$&HVHGHOHPSOHRRFDPELRGHSXHVWRGHWUDEDMR
2EMHWLYR$VHJXUDUTXHORVHPSOHDGRVFRQWUDWLVWDV\WHUFHURVDEDQGRQDQODRUJDQL]DFLyQRFDPELDQGHSXHVWRGH
WUDEDMRGHXQDPDQHUDRUGHQDGD
&RQWURO/DVUHVSRQVDELOLGDGHVSDUDSURFHGHUDOFHVHHQHO
$ 5HVSRQVDELOLGDGGHOFHVHRFDPELR HPSOHRRDOFDPELRGHSXHVWRGHWUDEDMRGHEHQHVWDU
FODUDPHQWHGHILQLGDV\DVLJQDGDV
&RQWURO7RGRVORVHPSOHDGRVFRQWUDWLVWDV\WHUFHURVGH
$ 'HYROXFLyQGHDFWLYRV EHQGHYROYHUWRGRVDFWLYRVGHODRUJDQL]DFLyQTXHHVWpQHQ
VXSRGHUDOILQDOL]DUVXHPSOHRFRQWUDWRRDFXHUGR
&RQWURO/RVGHUHFKRVGHDFFHVRDODLQIRUPDFLyQ\DORV
UHFXUVRVGHWUDWDPLHQWRGHODLQIRUPDFLyQGHWRGRVORV
$ 5HWLUDGDGHORVGHUHFKRVGHDFFHVR HPSOHDGRVFRQWUDWLVWDV\WHUFHURVGHEHQVHUUHWLUDGRVDOD
ILQDOL]DFLyQGHOHPSOHRGHOFRQWUDWRRGHODFXHUGRRELHQ
GHEHQVHUDGDSWDGRVDORVFDPELRVSURGXFLGRV
$6HJXULGDGItVLFD\DPELHQWDO
$ÈUHDVVHJXUDV
2EMHWLYR3UHYHQLUORVDFFHVRVItVLFRVQRDXWRUL]DGRVORVGDxRV\ODVLQWURPLVLRQHVHQODVLQVWDODFLRQHV\HQOD
LQIRUPDFLyQGHODRUJDQL]DFLyQ
&RQWURO6HGHEHQXWLOL]DUSHUtPHWURVGHVHJXULGDG
EDUUHUDVPXURVSXHUWDVGHHQWUDGDFRQFRQWURODWUDYpVGH
$ 3HUtPHWURGHVHJXULGDGItVLFD WDUMHWDRSXHVWRVGHFRQWUROSDUDSURWHJHUODViUHDVTXH
FRQWLHQHQODLQIRUPDFLyQ\ORVUHFXUVRVGHWUDWDPLHQWRGH
ODLQIRUPDFLyQ
&RQWURO/DViUHDVVHJXUDVGHEHQHVWDUSURWHJLGDVSRU
$ &RQWUROHVItVLFRVGHHQWUDGD FRQWUROHVGHHQWUDGDDGHFXDGRVSDUDDVHJXUDUTXH
~QLFDPHQWHVHSHUPLWHHODFFHVRDOSHUVRQDODXWRUL]DGR
6HJXULGDGGHRILFLQDVGHVSDFKRVH &RQWURO6HGHEHQGLVHxDU\DSOLFDUODVPHGLGDVGHVH
$
LQVWDODFLRQHV JXULGDGItVLFDSDUDODVRILFLQDVGHVSDFKRVHLQVWDODFLRQHV
&RQWURO6HGHEHGLVHxDU\DSOLFDUXQDSURWHFFLyQItVLFD
3URWHFFLyQFRQWUDODVDPHQD]DVH[WHUQDV\ FRQWUDHOGDxRFDXVDGRSRUIXHJRLQXQGDFLyQWHUUHPRWR
$
GHRULJHQDPELHQWDO H[SORVLyQUHYXHOWDVVRFLDOHV\RWUDVIRUPDVGHGHVDVWUHV
QDWXUDOHVRSURYRFDGRVSRUHOKRPEUH
&RQWURO6HGHEHQGLVHxDUHLPSODQWDUXQDSURWHFFLyQItVLFD
$ 7UDEDMRHQiUHDVVHJXUDV
\XQDVHULHGHGLUHFWULFHVSDUDWUDEDMDUHQODViUHDVVHJXUDV
&RQWURO'HEHQFRQWURODUVHORVSXQWRVGHDFFHVRWDOHV
FRPRODViUHDVGHFDUJD\GHVFDUJD\RWURVSXQWRVDWUDYpV
ÈUHDVGHDFFHVRS~EOLFR\GHFDUJD\ GHORVTXHSHUVRQDOQRDXWRUL]DGRSXHGHDFFHGHUDODV
$
GHVFDUJD LQVWDODFLRQHV\VLHVSRVLEOHGLFKRVSXQWRVVHGHEHQDLVODU
GHORVUHFXUVRVGHWUDWDPLHQWRGHODLQIRUPDFLyQSDUDHYLWDU
ORVDFFHVRVQRDXWRUL]DGRV
$6HJXULGDGGHORVHTXLSRV
2EMHWLYR(YLWDUSpUGLGDVGDxRVURERVRFLUFXQVWDQFLDVTXHSRQJDQHQSHOLJURORVDFWLYRVRTXHSXHGDQSURYRFDUOD
LQWHUUXSFLyQGHODVDFWLYLGDGHVGHODRUJDQL]DFLyQ
,62,(&
&RQWURO/RVHTXLSRVGHEHQVLWXDUVHRSURWHJHUVHGHIRUPD
TXHVHUHGX]FDQORVULHVJRVGHULYDGRVGHODVDPHQD]DV\
$ (PSOD]DPLHQWR\SURWHFFLyQGHHTXLSRV
SHOLJURVGHRULJHQDPELHQWDODVtFRPRODVRFDVLRQHVGHTXH
VHSURGX]FDQDFFHVRVQRDXWRUL]DGRV
&RQWURO/RVHTXLSRVGHEHQHVWDUSURWHJLGRVFRQWUDIDOORV
$ ,QVWDODFLRQHVGHVXPLQLVWUR GHDOLPHQWDFLyQ\RWUDVDQRPDOtDVFDXVDGDVSRUIDOORVHQ
ODVLQVWDODFLRQHVGHVXPLQLVWUR
&RQWURO(OFDEOHDGRHOpFWULFR\GHWHOHFRPXQLFDFLRQHVTXH
$ 6HJXULGDGGHOFDEOHDGR WUDQVPLWHGDWRVRTXHGDVRSRUWHDORVVHUYLFLRVGHLQIRUPD
FLyQGHEHHVWDUSURWHJLGRIUHQWHDLQWHUFHSWDFLRQHVRGDxRV
&RQWURO/RVHTXLSRVGHEHQUHFLELUXQPDQWHQLPLHQWR
$ 0DQWHQLPLHQWRGHORVHTXLSRV
FRUUHFWRTXHDVHJXUHVXGLVSRQLELOLGDG\VXLQWHJULGDG
&RQWURO7HQLHQGRHQFXHQWDORVGLIHUHQWHVULHVJRVTXH
6HJXULGDGGHORVHTXLSRVIXHUDGHODV FRQOOHYDWUDEDMDUIXHUDGHODVLQVWDODFLRQHVGHODRUJDQL]D
$
LQVWDODFLRQHV FLyQGHEHQDSOLFDUVHPHGLGDVGHVHJXULGDGDORVHTXLSRV
VLWXDGRVIXHUDGLFKDVLQVWDODFLRQHV
&RQWURO7RGRVORVVRSRUWHVGHDOPDFHQDPLHQWRGHEHQVHU
FRPSUREDGRVSDUDFRQILUPDUTXHWRGRGDWRVHQVLEOH\WRGDV
$ 5HXWLOL]DFLyQRUHWLUDGDVHJXUDGHHTXLSRV
ODVOLFHQFLDVGHVRIWZDUHVHKDQHOLPLQDGRRELHQVHKDQ
UHFDUJDGRGHPDQHUDVHJXUDDQWHVGHVXUHWLUDGD
&RQWURO/RVHTXLSRVODLQIRUPDFLyQRHOVRIWZDUHQR
5HWLUDGDGHPDWHULDOHVSURSLHGDGGHOD
$ GHEHQVDFDUVHGHODVLQVWDODFLRQHVVLQXQDDXWRUL]DFLyQ
HPSUHVD
SUHYLD
$*HVWLyQGHFRPXQLFDFLRQHV\RSHUDFLRQHV
$5HVSRQVDELOLGDGHV\SURFHGLPLHQWRVGHRSHUDFLyQ
2EMHWLYR$VHJXUDUHOIXQFLRQDPLHQWRFRUUHFWR\VHJXURGHORVUHFXUVRVGHSURFHVDPLHQWRGHODLQIRUPDFLyQ
&RQWURO'HEHQGRFXPHQWDUVH\PDQWHQHUVHORVSURFHGL
'RFXPHQWDFLyQGHORVSURFHGLPLHQWRVGH
$ PLHQWRVGHRSHUDFLyQ\SRQHUVHDGLVSRVLFLyQGHWRGRVORV
RSHUDFLyQ
XVXDULRVTXHORVQHFHVLWHQ
&RQWURO'HEHQFRQWURODUVHORVFDPELRVHQORVUHFXUVRV\
$ *HVWLyQGHFDPELRV
ORVVLVWHPDVGHWUDWDPLHQWRGHODLQIRUPDFLyQ
&RQWURO/DVWDUHDV\iUHDVGHUHVSRQVDELOLGDGGHEHQ
VHJUHJDUVHSDUDUHGXFLUODSRVLELOLGDGGHTXHVHSURGX]FDQ
$ 6HJUHJDFLyQGHWDUHDV
PRGLILFDFLRQHVQRDXWRUL]DGDVRQRLQWHQFLRQDGDVRXVRV
LQGHELGRVGHORVDFWLYRVGHODRUJDQL]DFLyQ
&RQWURO'HEHQVHSDUDUVHORVUHFXUVRVGHGHVDUUROORGH
6HSDUDFLyQGHORVUHFXUVRVGHGHVDUUROOR
$ SUXHEDV\GHRSHUDFLyQSDUDUHGXFLUORVULHVJRVGHDFFHVR
SUXHED\RSHUDFLyQ
QRDXWRUL]DGRRORVFDPELRVHQHOVLVWHPDRSHUDWLYR
$*HVWLyQGHODSURYLVLyQGHVHUYLFLRVSRUWHUFHURV
2EMHWLYR,PSODQWDU\PDQWHQHUHOQLYHODSURSLDGRGHVHJXULGDGGHODLQIRUPDFLyQHQODSURYLVLyQGHOVHUYLFLRHQFRQ
VRQDQFLDFRQORVDFXHUGRVGHSURYLVLyQGHVHUYLFLRVSRUWHUFHURV
&RQWURO6HGHEHFRPSUREDUTXHORVFRQWUROHVGHVHJXUL
GDGODVGHILQLFLRQHVGHORVVHUYLFLRV\ORVQLYHOHVGHSURYL
$ 3URYLVLyQGHVHUYLFLRV VLyQLQFOXLGRVHQHODFXHUGRGHSURYLVLyQGHVHUYLFLRVSRU
WHUFHURVKDQVLGRLPSODQWDGRVSXHVWRVHQRSHUDFLyQ\VRQ
PDQWHQLGRVSRUSDUWHGHXQWHUFHUR
,62,(&
&RQWURO/RVVHUYLFLRVLQIRUPHV\UHJLVWURVSURSRUFLRQD
6XSHUYLVLyQ\UHYLVLyQGHORVVHUYLFLRV GRVSRUXQWHUFHURGHEHQVHUREMHWRGHVXSHUYLVLyQ\
$
SUHVWDGRVSRUWHUFHURV UHYLVLyQSHULyGLFDV\WDPELpQGHEHQOOHYDUVHDFDER
DXGLWRULDVSHULyGLFDV
&RQWURO6HGHEHQJHVWLRQDUORVFDPELRVHQODSURYLVLyQGH
ORVVHUYLFLRVLQFOX\HQGRHOPDQWHQLPLHQWR\ODPHMRUDGH
*HVWLyQGHFDPELRVHQORVVHUYLFLRV ODVSROtWLFDVORVSURFHGLPLHQWRV\ORVFRQWUROHVGHVHJXUL
$
SUHVWDGRVSRUWHUFHURV GDGGHODLQIRUPDFLyQH[LVWHQWHVWHQLHQGRHQFXHQWDOD
FULWLFLGDGGHORVSURFHVRV\VLVWHPDVGHOQHJRFLRDIHFWDGRV
DVtFRPRODUHHYDOXDFLyQGHORVULHVJRV
$3ODQLILFDFLyQ\DFHSWDFLyQGHOVLVWHPD
2EMHWLYR0LQLPL]DUHOULHVJRGHIDOORVGHORVVLVWHPDV
&RQWURO/DXWLOL]DFLyQGHORVUHFXUVRVVHGHEHVXSHUYLVDU\
DMXVWDUDVtFRPRUHDOL]DUSUR\HFFLRQHVGHORVUHTXLVLWRV
$ *HVWLyQGHFDSDFLGDGHV
IXWXURVGHFDSDFLGDGSDUDJDUDQWL]DUHOFRPSRUWDPLHQWR
UHTXHULGRGHOVLVWHPD
&RQWURO6HGHEHQHVWDEOHFHUORVFULWHULRVSDUDODDFHSWD
FLyQGHQXHYRVVLVWHPDVGHLQIRUPDFLyQGHODVDFWXDOL]D
$ $FHSWDFLyQGHOVLVWHPD FLRQHV\GHQXHYDVYHUVLRQHVGHORVPLVPRV\VHGHEHQ
OOHYDUDFDERSUXHEDVDGHFXDGDVGHORVVLVWHPDVGXUDQWHHO
GHVDUUROOR\SUHYLDPHQWHDODDFHSWDFLyQ
$3URWHFFLyQFRQWUDFyGLJRPDOLFLRVR\GHVFDUJDEOH
2EMHWLYR3URWHJHUODLQWHJULGDGGHOVRIWZDUH\GHODLQIRUPDFLyQ
&RQWURO6HGHEHQLPSODQWDUORVFRQWUROHVGHGHWHFFLyQ
SUHYHQFLyQ\UHFXSHUDFLyQTXHVLUYDQFRPRSURWHFFLyQ
$ &RQWUROHVFRQWUDHOFyGLJRPDOLFLRVR
FRQWUDFyGLJRPDOLFLRVR\VHGHEHQLPSODQWDUSURFHGL
PLHQWRVDGHFXDGRVGHFRQFLHQFLDFLyQGHOXVXDULR
&RQWURO&XDQGRVHDXWRULFHHOXVRGHFyGLJRGHVFDUJDGR
HQHOFOLHQWH-DYD6FULSW9%6FULSWDSSOHWVGH-DYD
&RQWUROHVFRQWUDHOFyGLJRGHVFDUJDGRHQHO DSSOHWVFRQWUROHV$FWLYH;HWFODFRQILJXUDFLyQGHEH
$
FOLHQWH JDUDQWL]DUTXHGLFKRFyGLJRDXWRUL]DGRIXQFLRQDGH
DFXHUGRFRQXQDSROtWLFDGHVHJXULGDGFODUDPHQWHGHILQLGD
\VHGHEHHYLWDUTXHVHHMHFXWHHOFyGLJRQRDXWRUL]DGR
$&RSLDVGHVHJXULGDG
2EMHWLYR0DQWHQHUODLQWHJULGDG\GLVSRQLELOLGDGGHODLQIRUPDFLyQ\GHORVUHFXUVRVGHWUDWDPLHQWRGHODLQIRUPDFLyQ
&RQWURO6HGHEHQUHDOL]DUFRSLDVGHVHJXULGDGGHODLQIRU
$ &RSLDVGHVHJXULGDGGHODLQIRUPDFLyQ PDFLyQ\GHOVRIWZDUH\VHGHEHQSUREDUSHULyGLFDPHQWH
FRQFRQIRUPHDODSROtWLFDGHFRSLDVGHVHJXULGDGDFRUGDGD
$*HVWLyQGHODVHJXULGDGGHODVUHGHV
2EMHWLYR$VHJXUDUODSURWHFFLyQGHODLQIRUPDFLyQHQODVUHGHV\ODSURWHFFLyQGHODLQIUDHVWUXFWXUDGHVRSRUWH
&RQWURO/DVUHGHVGHEHQHVWDUDGHFXDGDPHQWHJHVWLRQDGDV
\FRQWURODGDVSDUDTXHHVWpQSURWHJLGDVIUHQWHDSRVLEOHV
$ &RQWUROHVGHUHG DPHQD]DV\SDUDPDQWHQHUODVHJXULGDGGHORVVLVWHPDV\
GHODVDSOLFDFLRQHVTXHXWLOL]DQHVWDVUHGHVLQFOX\HQGROD
LQIRUPDFLyQHQWUiQVLWR
,62,(&
&RQWURO6HGHEHQLGHQWLILFDUODVFDUDFWHUtVWLFDVGHVHJXUL
GDGORVQLYHOHVGHVHUYLFLR\ORVUHTXLVLWRVGHJHVWLyQGH
$ 6HJXULGDGGHORVVHUYLFLRVGHUHG WRGRVORVVHUYLFLRVGHUHG\VHGHEHQLQFOXLUHQWRGRDFXHU
GRGHVHUYLFLRVGHUHGWDQWRVLHVWRVVHUYLFLRVVHSUHVWDQ
GHQWURGHODRUJDQL]DFLyQFRPRVLVHVXEFRQWUDWDQ
$0DQLSXODFLyQGHORVVRSRUWHV
2EMHWLYR(YLWDUODUHYHODFLyQPRGLILFDFLyQUHWLUDGDRGHVWUXFFLyQQRDXWRUL]DGDGHORVDFWLYRV\ODLQWHUUXSFLyQGH
ODVDFWLYLGDGHVGHODRUJDQL]DFLyQ
&RQWURO6HGHEHQHVWDEOHFHUSURFHGLPLHQWRVSDUDOD
$ *HVWLyQGHVRSRUWHVH[WUDtEOHV
JHVWLyQGHORVVRSRUWHVH[WUDtEOHV
&RQWURO/RVVRSRUWHVGHEHQVHUUHWLUDGRVGHIRUPDVHJXUD
$ 5HWLUDGDGHVRSRUWHV FXDQGR\DQRYD\DQDVHUQHFHVDULRVPHGLDQWHORVSURFH
GLPLHQWRVIRUPDOHVHVWDEOHFLGRV
&RQWURO'HEHQHVWDEOHFHUVHSURFHGLPLHQWRVSDUDODPDQL
3URFHGLPLHQWRVGHPDQLSXODFLyQGHOD SXODFLyQ\HODOPDFHQDPLHQWRGHODLQIRUPDFLyQGHPRGR
$
LQIRUPDFLyQ TXHVHSURWHMDGLFKDLQIRUPDFLyQFRQWUDODUHYHODFLyQQR
DXWRUL]DGDRHOXVRLQGHELGR
&RQWURO/DGRFXPHQWDFLyQGHOVLVWHPDGHEHHVWDU
$ 6HJXULGDGGHODGRFXPHQWDFLyQGHOVLVWHPD
SURWHJLGDFRQWUDDFFHVRVQRDXWRUL]DGRV
$,QWHUFDPELRGHLQIRUPDFLyQ
2EMHWLYR0DQWHQHUODVHJXULGDGGHODLQIRUPDFLyQ\GHOVRIWZDUHLQWHUFDPELDGRVGHQWURGHXQDRUJDQL]DFLyQ\FRQXQ
WHUFHUR
&RQWURO'HEHQHVWDEOHFHUVHSROtWLFDVSURFHGLPLHQWRV\
3ROtWLFDV\SURFHGLPLHQWRVGHLQWHUFDPELR FRQWUROHVIRUPDOHVTXHSURWHMDQHOLQWHUFDPELRGHLQIRU
$
GHLQIRUPDFLyQ PDFLyQPHGLDQWHHOXVRGHWRGRWLSRGHUHFXUVRVGH
FRPXQLFDFLyQ
&RQWURO'HEHQHVWDEOHFHUVHDFXHUGRVSDUDHOLQWHUFDPELR
$ $FXHUGRVGHLQWHUFDPELR GHLQIRUPDFLyQ\GHOVRIWZDUHHQWUHODRUJDQL]DFLyQ\ORV
WHUFHURV
&RQWURO'XUDQWHHOWUDQVSRUWHIXHUDGHORVOtPLWHVItVLFRV
GHODRUJDQL]DFLyQORVVRSRUWHVTXHFRQWHQJDQLQIRUPDFLyQ
$ 6RSRUWHVItVLFRVHQWUiQVLWR
GHEHQHVWDUSURWHJLGRVFRQWUDDFFHVRVQRDXWRUL]DGRVXVRV
LQGHELGRVRGHWHULRUR
&RQWURO/DLQIRUPDFLyQTXHVHDREMHWRGHPHQVDMHUtD
$ 0HQVDMHUtDHOHFWUyQLFD
HOHFWUyQLFDGHEHHVWDUDGHFXDGDPHQWHSURWHJLGD
&RQWURO'HEHQIRUPXODUVHHLPSODQWDUVHSROtWLFDV\SUR
$ 6LVWHPDVGHLQIRUPDFLyQHPSUHVDULDOHV FHGLPLHQWRVSDUDSURWHJHUODLQIRUPDFLyQDVRFLDGDDOD
LQWHUFRQH[LyQGHORVVLVWHPDVGHLQIRUPDFLyQHPSUHVDULDOHV
$6HUYLFLRVGHFRPHUFLRHOHFWUyQLFR
2EMHWLYR*DUDQWL]DUODVHJXULGDGGHORVVHUYLFLRVGHFRPHUFLRHOHFWUyQLFR\HOXVRVHJXURGHORVPLVPRV
&RQWURO/DLQIRUPDFLyQLQFOXLGDHQHOFRPHUFLRHOHFWUy
QLFRTXHVHWUDQVPLWDDWUDYpVGHUHGHVS~EOLFDVGHEHSUR
$ &RPHUFLRHOHFWUyQLFR WHJHUVHFRQWUDODVDFWLYLGDGHVIUDXGXOHQWDVODVGLVSXWDV
FRQWUDFWXDOHV\ODUHYHODFLyQRPRGLILFDFLyQQRDXWRUL]DGD
GHGLFKDLQIRUPDFLyQ
,62,(&
&RQWURO/DLQIRUPDFLyQFRQWHQLGDHQODVWUDQVDFFLRQHVHQ
OtQHDGHEHHVWDUSURWHJLGDSDUDHYLWDUWUDQVPLVLRQHVLQFRP
$ 7UDQVDFFLRQHVHQOtQHD SOHWDVHUURUHVGHGLUHFFLRQDPLHQWRDOWHUDFLRQHVQRDXWRUL
]DGDVGHORVPHQVDMHVODUHYHODFLyQODGXSOLFDFLyQROD
UHSURGXFFLyQQRDXWRUL]DGDVGHOPHQVDMH
&RQWURO/DLQWHJULGDGGHODLQIRUPDFLyQSXHVWDDGLVSRVL
$ ,QIRUPDFLyQSXHVWDDGLVSRVLFLyQS~EOLFD FLyQS~EOLFDVHGHEHSURWHJHUSDUDHYLWDUPRGLILFDFLRQHVQR
DXWRUL]DGDV
$6XSHUYLVLyQ
2EMHWLYR'HWHFWDUODVDFWLYLGDGHVGHSURFHVDPLHQWRGHODLQIRUPDFLyQQRDXWRUL]DGDV
&RQWURO6HGHEHQUHDOL]DUUHJLVWURVGHDXGLWRULDGHODV
DFWLYLGDGHVGHORVXVXDULRVODVH[FHSFLRQHV\HYHQWRVGH
VHJXULGDGGHODLQIRUPDFLyQ\VHGHEHQPDQWHQHUHVWRV
$ 5HJLVWURGHDXGLWRULDV
UHJLVWURVGXUDQWHXQSHULRGRDFRUGDGRSDUDVHUYLUFRPR
SUXHEDHQLQYHVWLJDFLRQHVIXWXUDV\HQODVXSHUYLVLyQGHO
FRQWUROGHDFFHVR
&RQWURO6HGHEHQHVWDEOHFHUSURFHGLPLHQWRVSDUDVXSHUYL
VDUHOXVRGHORVUHFXUVRVGHSURFHVDPLHQWRGHOD
$ 6XSHUYLVLyQGHOXVRGHOVLVWHPD
LQIRUPDFLyQ\VHGHEHQUHYLVDUSHULyGLFDPHQWHORV
UHVXOWDGRVGHODVDFWLYLGDGHVGHVXSHUYLVLyQ
&RQWURO/RVGLVSRVLWLYRVGHUHJLVWUR\ODLQIRUPDFLyQGH
3URWHFFLyQGHODLQIRUPDFLyQGHORV
$ ORVUHJLVWURVGHEHQHVWDUSURWHJLGRVFRQWUDPDQLSXODFLRQHV
UHJLVWURV
LQGHELGDV\DFFHVRVQRDXWRUL]DGRV
&RQWURO6HGHEHQUHJLVWUDUODVDFWLYLGDGHVGHO
$ 5HJLVWURVGHDGPLQLVWUDFLyQ\RSHUDFLyQ
DGPLQLVWUDGRUGHOVLVWHPD\GHODRSHUDFLyQGHOVLVWHPD
&RQWURO/RVIDOORVGHEHQVHUUHJLVWUDGRV\DQDOL]DGRV\VH
$ 5HJLVWURGHIDOORV
GHEHQWRPDUODVFRUUHVSRQGLHQWHVDFFLRQHV
&RQWURO/RVUHORMHVGHWRGRVORVVLVWHPDVGH
SURFHVDPLHQWRGHODLQIRUPDFLyQGHQWURGHXQD
$ 6LQFURQL]DFLyQGHOUHORM
RUJDQL]DFLyQRGHXQGRPLQLRGHVHJXULGDGGHEHQHVWDU
VLQFURQL]DGRVFRQXQDSUHFLVLyQGHWLHPSRDFRUGDGD
$&RQWUROGHDFFHVR
$5HTXLVLWRVGHQHJRFLRSDUDHOFRQWUROGHDFFHVR
2EMHWLYR&RQWURODUHODFFHVRDODLQIRUPDFLyQ
&RQWURO6HGHEHHVWDEOHFHUGRFXPHQWDU\UHYLVDUXQD
$ 3ROtWLFDGHFRQWUROGHDFFHVR SROtWLFDGHFRQWUROGHDFFHVREDVDGDHQORVUHTXLVLWRV
HPSUHVDULDOHV\GHVHJXULGDGSDUDHODFFHVR
$*HVWLyQGHDFFHVRGHXVXDULR
2EMHWLYR$VHJXUDUHODFFHVRGHXQXVXDULRDXWRUL]DGR\SUHYHQLUHODFFHVRQRDXWRUL]DGRDORVVLVWHPDVGHLQIRUPDFLyQ
&RQWURO'HEHHVWDEOHFHUVHXQSURFHGLPLHQWRIRUPDOGH
$ 5HJLVWURGHXVXDULR UHJLVWUR\GHDQXODFLyQGHXVXDULRVSDUDFRQFHGHU\UHYRFDU
HODFFHVRDWRGRVORVVLVWHPDV\VHUYLFLRVGHLQIRUPDFLyQ
&RQWURO/DDVLJQDFLyQ\HOXVRGHSULYLOHJLRVGHEHQHVWDU
$ *HVWLyQGHSULYLOHJLRV
UHVWULQJLGRV\FRQWURODGRV
&RQWURO/DDVLJQDFLyQGHFRQWUDVHxDVGHEHVHUFRQWURODGD
$ *HVWLyQGHFRQWUDVHxDVGHXVXDULR
DWUDYpVGHXQSURFHVRGHJHVWLyQIRUPDO
,62,(&
&RQWURO/D'LUHFFLyQGHEHUHYLVDUORVGHUHFKRVGHDFFHVR
5HYLVLyQGHORVGHUHFKRVGHDFFHVRGH
$ GHXVXDULRDLQWHUYDORVUHJXODUHV\XWLOL]DQGRXQSURFHVR
XVXDULR
IRUPDO
$5HVSRQVDELOLGDGHVGHXVXDULR
2EMHWLYR3UHYHQLUHODFFHVRGHXVXDULRVQRDXWRUL]DGRVDVtFRPRHYLWDUHOTXHVHFRPSURPHWDRVHSURGX]FDHOURER
GHODLQIRUPDFLyQRGHORVUHFXUVRVGHSURFHVDPLHQWRGHODLQIRUPDFLyQ
&RQWURO6HGHEHUHTXHULUDORVXVXDULRVHOVHJXLUODV
$ 8VRGHFRQWUDVHxD EXHQDVSUiFWLFDVGHVHJXULGDGHQODVHOHFFLyQ\HOXVRGH
ODVFRQWUDVHxDV
&RQWURO/RVXVXDULRVGHEHQDVHJXUDUVHGHTXHHOHTXLSR
$ (TXLSRGHXVXDULRGHVDWHQGLGR
GHVDWHQGLGRWLHQHODSURWHFFLyQDGHFXDGD
&RQWURO'HEHDGRSWDUVHXQDSROtWLFDGHSXHVWRGHWUDEDMR
3ROtWLFDGHSXHVWRGHWUDEDMRGHVSHMDGR\ GHVSHMDGRGHSDSHOHV\GHVRSRUWHVGHDOPDFHQDPLHQWR
$
SDQWDOODOLPSLD H[WUDtEOHVMXQWRFRQXQDSROtWLFDGHSDQWDOODOLPSLDSDUDORV
UHFXUVRVGHSURFHVDPLHQWRGHODLQIRUPDFLyQ
$&RQWUROGHDFFHVRDODUHG
2EMHWLYR3UHYHQLUHODFFHVRQRDXWRUL]DGRDORVVHUYLFLRVHQUHG
&RQWURO6HGHEHSURSRUFLRQDUDORVXVXDULRV~QLFDPHQWHHO
$ 3ROtWLFDGHXVRGHORVVHUYLFLRVHQUHG DFFHVRDORVVHUYLFLRVSDUDTXHORVTXHKD\DQVLGR
HVSHFtILFDPHQWHDXWRUL]DGRV
&RQWURO6HGHEHQXWLOL]DUORVPpWRGRVDSURSLDGRVGH
$XWHQWLFDFLyQGHXVXDULRSDUDFRQH[LRQHV
$ DXWHQWLFDFLyQSDUDFRQWURODUHODFFHVRGHORVXVXDULRV
H[WHUQDV
UHPRWRV
&RQWURO/DLGHQWLILFDFLyQDXWRPiWLFDGHORVHTXLSRVVH
GHEHFRQVLGHUDUFRPRXQPHGLRGHDXWHQWLFDFLyQGHODV
$ ,GHQWLILFDFLyQGHORVHTXLSRVHQODVUHGHV
FRQH[LRQHVSURYHQLHQWHVGHORFDOL]DFLRQHV\HTXLSRV
HVSHFtILFRV
'LDJQyVWLFRUHPRWR\SURWHFFLyQGHORV &RQWURO6HGHEHFRQWURODUHODFFHVRItVLFR\OyJLFRDORV
$
SXHUWRVGHFRQILJXUDFLyQ SXHUWRVGHGLDJQyVWLFR\GHFRQILJXUDFLyQ
&RQWURO/RVJUXSRVGHVHUYLFLRVGHLQIRUPDFLyQXVXDULRV
$ 6HJUHJDFLyQGHODVUHGHV
\VLVWHPDVGHLQIRUPDFLyQGHEHQHVWDUVHJUHJDGRVHQUHGHV
&RQWURO(QUHGHVFRPSDUWLGDVHVSHFLDOPHQWHHQDTXHOODV
TXHWUDVSDVHQODVIURQWHUDVGHODRUJDQL]DFLyQGHEHUHV
WULQJLUVHODFDSDFLGDGGHORVXVXDULRVSDUDFRQHFWDUVHDOD
$ &RQWUROGHODFRQH[LyQDODUHG
UHGHVWRGHEHKDFHUVHGHDFXHUGRDODSROtWLFDGHFRQWUROGH
DFFHVR\DORVUHTXLVLWRVGHODVDSOLFDFLRQHVGHOQHJRFLR
YpDVH
&RQWURO6HGHEHQLPSODQWDUFRQWUROHVGHHQFDPLQDPLHQWR
URXWLQJGHUHGHVSDUDDVHJXUDUTXHODVFRQH[LRQHVGHORV
$ &RQWUROGHHQFDPLQDPLHQWRURXWLQJGHUHG
RUGHQDGRUHV\ORVIOXMRVGHLQIRUPDFLyQQRYLRODQODSROtWL
FDGHFRQWUROGHDFFHVRGHODVDSOLFDFLRQHVHPSUHVDULDOHV
$&RQWUROGHDFFHVRDOVLVWHPDRSHUDWLYR
2EMHWLYR3UHYHQLUHODFFHVRQRDXWRUL]DGRDORVVLVWHPDVRSHUDWLYRV
&RQWURO(ODFFHVRDORVVLVWHPDVRSHUDWLYRVVHGHEHFRQ
$ 3URFHGLPLHQWRVVHJXURVGHLQLFLRGHVHVLyQ WURODUSRUPHGLRGHXQSURFHGLPLHQWRVHJXURGHLQLFLRGH
VHVLyQ
,62,(&
&RQWURO7RGRVORVXVXDULRVGHEHQWHQHUXQLGHQWLILFDGRU
~QLFR,'GHXVXDULRSDUDVXXVRSHUVRQDO\H[FOXVLYR\
$ ,GHQWLILFDFLyQ\DXWHQWLFDFLyQGHXVXDULR
VHGHEHHOHJLUXQDWpFQLFDDGHFXDGDGHDXWHQWLFDFLyQSDUD
FRQILUPDUODLGHQWLGDGVROLFLWDGDGHOXVXDULR
&RQWURO/RVVLVWHPDVSDUDODJHVWLyQGHFRQWUDVHxDVGHEHQ
$ 6LVWHPDGHJHVWLyQGHFRQWUDVHxDV
VHULQWHUDFWLYRV\HVWDEOHFHUFRQWUDVHxDVVHJXUDV\UREXVWDV
&RQWURO6HGHEHUHVWULQJLU\FRQWURODUULJXURVDPHQWHHOXVR
$ 8VRGHORVUHFXUVRVGHOVLVWHPD GHSURJUDPDV\XWLOLGDGHVTXHSXHGDQVHUFDSDFHVGHLQYD
OLGDUORVFRQWUROHVGHOVLVWHPD\GHODDSOLFDFLyQ
&RQWURO/DVVHVLRQHVLQDFWLYDVGHEHQFHUUDUVHGHVSXpVGH
$ 'HVFRQH[LyQDXWRPiWLFDGHVHVLyQ
XQSHULRGRGHLQDFWLYLGDGGHILQLGR
&RQWURO3DUDSURSRUFLRQDUVHJXULGDGDGLFLRQDODODVDSOLFD
$ /LPLWDFLyQGHOWLHPSRGHFRQH[LyQ FLRQHVGHDOWRULHVJRVHGHEHQXWLOL]DUUHVWULFFLRQHVHQORV
WLHPSRVGHFRQH[LyQ
$&RQWUROGHDFFHVRDODVDSOLFDFLRQHV\DODLQIRUPDFLyQ
2EMHWLYR3UHYHQLUHODFFHVRQRDXWRUL]DGRDODLQIRUPDFLyQTXHFRQWLHQHQODVDSOLFDFLRQHV
&RQWURO6HGHEHUHVWULQJLUHODFFHVRDODLQIRUPDFLyQ\D
$ 5HVWULFFLyQGHODFFHVRDODLQIRUPDFLyQ ODVDSOLFDFLRQHVDORVXVXDULRV\DOSHUVRQDOGHVRSRUWHGH
DFXHUGRFRQODSROtWLFDGHFRQWUROGHDFFHVRGHILQLGD
&RQWURO/RVVLVWHPDVVHQVLEOHVGHEHQWHQHUXQHQWRUQRGH
$ $LVODPLHQWRGHVLVWHPDVVHQVLEOHV
RUGHQDGRUHVGHGLFDGRVDLVODGRV
$2UGHQDGRUHVSRUWiWLOHV\WHOHWUDEDMR
2EMHWLYR*DUDQWL]DUODVHJXULGDGGHODLQIRUPDFLyQFXDQGRVHXWLOL]DQRUGHQDGRUHVSRUWiWLOHV\VHUYLFLRVGHWHOHWUDEDMR
&RQWURO6HGHEHLPSODQWDUXQDSROtWLFDIRUPDO\VHGHEHQ
2UGHQDGRUHVSRUWiWLOHV\FRPXQLFDFLRQHV DGRSWDUODVPHGLGDVGHVHJXULGDGDGHFXDGDVGHSURWHFFLyQ
$
PyYLOHV FRQWUDORVULHVJRVGHODXWLOL]DFLyQGHRUGHQDGRUHVSRUWiWL
OHV\FRPXQLFDFLRQHVPyYLOHV
&RQWURO6HGHEHUHGDFWDUHLPSODQWDUXQDSROtWLFDGHDFWL
$ 7HOHWUDEDMR YLGDGHVGHWHOHWUDEDMRDVtFRPRORVSODQHV\SURFHGLPLHQ
WRVGHRSHUDFLyQFRUUHVSRQGLHQWHV
$$GTXLVLFLyQGHVDUUROOR\PDQWHQLPLHQWRGHORVVLVWHPDVGHLQIRUPDFLyQ
$5HTXLVLWRVGHVHJXULGDGGHORVVLVWHPDVGHLQIRUPDFLyQ
2EMHWLYR*DUDQWL]DUTXHODVHJXULGDGHVWiLQWHJUDGDHQORVVLVWHPDVGHLQIRUPDFLyQ
&RQWURO(QODVGHFODUDFLRQHVGHORVUHTXLVLWRVGHQHJRFLR
$QiOLVLV\HVSHFLILFDFLyQGHORVUHTXLVLWRV SDUDORVQXHYRVVLVWHPDVGHLQIRUPDFLyQRSDUDPHMRUDVGH
$
GHVHJXULGDG ORVVLVWHPDVGHLQIRUPDFLyQ\DH[LVWHQWHVVHGHEHQHVSHFL
ILFDUORVUHTXLVLWRVGHORVFRQWUROHVGHVHJXULGDG
$7UDWDPLHQWRFRUUHFWRGHODVDSOLFDFLRQHV
2EMHWLYR(YLWDUHUURUHVSpUGLGDVPRGLILFDFLRQHVQRDXWRUL]DGDVRXVRVLQGHELGRVGHODLQIRUPDFLyQHQODVDSOLFDFLRQHV
&RQWURO/DLQWURGXFFLyQGHGDWRVHQODVDSOLFDFLRQHVGHEH
$ 9DOLGDFLyQGHORVGDWRVGHHQWUDGD YDOLGDUVHSDUDJDUDQWL]DUTXHGLFKRVGDWRVVRQFRUUHFWRV\
DGHFXDGRV
,62,(&
&RQWURO3DUDGHWHFWDUFXDOTXLHUFRUUXSFLyQGHODLQIRU
PDFLyQGHELGDDHUURUHVGHSURFHVDPLHQWRRDFWRVLQWHQFLR
$ &RQWUROGHOSURFHVDPLHQWRLQWHUQR
QDGRVVHGHEHQLQFRUSRUDUFRPSUREDFLRQHVGHYDOLGDFLyQ
HQODVDSOLFDFLRQHV
&RQWURO6HGHEHQLGHQWLILFDUORVUHTXLVLWRVSDUDJDUDQWL]DU
ODDXWHQWLFLGDG\SDUDSURWHJHUODLQWHJULGDGGHORVPHQVD
$ ,QWHJULGDGGHORVPHQVDMHV
MHVHQODVDSOLFDFLRQHV\VHGHEHQLGHQWLILFDUHLPSODQWDU
ORVFRQWUROHVDGHFXDGRV
&RQWURO/RVGDWRVGHVDOLGDGHXQDDSOLFDFLyQVHGHEHQ
$ 9DOLGDFLyQGHORVGDWRVGHVDOLGD YDOLGDUSDUDJDUDQWL]DUTXHHOWUDWDPLHQWRGHODLQIRUPDFLyQ
DOPDFHQDGDHVFRUUHFWR\DGHFXDGRDODVFLUFXQVWDQFLDV
$&RQWUROHVFULSWRJUiILFRV
2EMHWLYR3URWHJHUODFRQILGHQFLDOLGDGODDXWHQWLFLGDGRODLQWHJULGDGGHODLQIRUPDFLyQSRUPHGLRVFULSWRJUiILFRV
&RQWURO6HGHEHIRUPXODUHLPSODQWDUXQDSROtWLFDSDUDHO
3ROtWLFDGHXVRGHORVFRQWUROHV
$ XVRGHORVFRQWUROHVFULSWRJUiILFRVSDUDSURWHJHUOD
FULSWRJUiILFRV
LQIRUPDFLyQ
&RQWURO'HEHLPSODQWDUVHXQVLVWHPDGHJHVWLyQGHFODYHV
$ *HVWLyQGHFODYHV SDUDGDUVRSRUWHDOXVRGHWpFQLFDVFULSWRJUiILFDVSRUSDUWH
GHODRUJDQL]DFLyQ
$6HJXULGDGGHORVDUFKLYRVGHVLVWHPD
2EMHWLYR*DUDQWL]DUODVHJXULGDGGHORVDUFKLYRVGHVLVWHPD
&RQWURO'HEHQHVWDULPSODQWDGRVSURFHGLPLHQWRVSDUD
$ &RQWUROGHOVRIWZDUHHQH[SORWDFLyQ FRQWURODUODLQVWDODFLyQGHVRIWZDUHHQORVVLVWHPDV
RSHUDWLYRV
3URWHFFLyQGHORVGDWRVGHSUXHEDGHO &RQWURO/RVGDWRVGHSUXHEDVHGHEHQVHOHFFLRQDUFRQ
$
VLVWHPD FXLGDGR\GHEHQHVWDUSURWHJLGRV\FRQWURODGRV
&RQWUROGHDFFHVRDOFyGLJRIXHQWHGHORV &RQWURO6HGHEHUHVWULQJLUHODFFHVRDOFyGLJRIXHQWHGHORV
$
SURJUDPDV SURJUDPDV
$6HJXULGDGHQORVSURFHVRVGHGHVDUUROOR\VRSRUWH
2EMHWLYR0DQWHQHUODVHJXULGDGGHOVRIWZDUH\GHODLQIRUPDFLyQGHODVDSOLFDFLRQHV
&RQWURO/DLPSODQWDFLyQGHFDPELRVGHEHFRQWURODUVH
$ 3URFHGLPLHQWRVGHFRQWUROGHFDPELRV PHGLDQWHHOXVRGHSURFHGLPLHQWRVIRUPDOHVGHFRQWUROGH
FDPELRV
&RQWURO&XDQGRVHPRGLILTXHQORVVLVWHPDVRSHUDWLYRVODV
5HYLVLyQWpFQLFDGHODVDSOLFDFLRQHVWUDV DSOLFDFLRQHVHPSUHVDULDOHVFUtWLFDVGHEHQVHUUHYLVDGDV\
$
HIHFWXDUFDPELRVHQHOVLVWHPDRSHUDWLYR SUREDGDVSDUDJDUDQWL]DUTXHQRH[LVWHQHIHFWRVDGYHUVRV
HQODVRSHUDFLRQHVRHQODVHJXULGDGGHODRUJDQL]DFLyQ
&RQWURO6HGHEHQGHVDFRQVHMDUODVPRGLILFDFLRQHVHQORV
5HVWULFFLRQHVDORVFDPELRVHQORVSDTXHWHV SDTXHWHVGHVRIWZDUHOLPLWiQGRVHDORVFDPELRV
$
GHVRIWZDUH QHFHVDULRV\WRGRVORVFDPELRVGHEHQVHUREMHWRGHXQ
FRQWUROULJXURVR
&RQWURO'HEHQHYLWDUVHODVVLWXDFLRQHVTXHSHUPLWDQTXH
$ )XJDVGHLQIRUPDFLyQ
VHSURGX]FDQIXJDVGHLQIRUPDFLyQ
&RQWURO/DH[WHUQDOL]DFLyQGHOGHVDUUROORGHVRIWZDUHGHEH
$ ([WHUQDOL]DFLyQGHOGHVDUUROORGHVRIWZDUH
VHUVXSHUYLVDGD\FRQWURODGDSRUODRUJDQL]DFLyQ
,62,(&
$*HVWLyQGHODYXOQHUDELOLGDGWpFQLFD
2EMHWLYR5HGXFLUORVULHVJRVUHVXOWDQWHVGHODH[SORWDFLyQGHODVYXOQHUDELOLGDGHVWpFQLFDVSXEOLFDGDV
&RQWURO6HGHEHREWHQHULQIRUPDFLyQRSRUWXQDDFHUFDGH
ODVYXOQHUDELOLGDGHVWpFQLFDVGHORVVLVWHPDVGHLQIRUPD
$ &RQWUROGHODVYXOQHUDELOLGDGHVWpFQLFDV FLyQTXHHVWiQVLHQGRXWLOL]DGRVHYDOXDUODH[SRVLFLyQGH
ODRUJDQL]DFLyQDGLFKDVYXOQHUDELOLGDGHV\DGRSWDUODV
PHGLGDVDGHFXDGDVSDUDDIURQWDUHOULHVJRDVRFLDGR
$*HVWLyQGHLQFLGHQWHVGHVHJXULGDGGHODLQIRUPDFLyQ
$1RWLILFDFLyQGHHYHQWRV\SXQWRVGpELOHVGHODVHJXULGDGGHODLQIRUPDFLyQ
2EMHWLYR$VHJXUDUVHGHTXHORVHYHQWRV\ODVYXOQHUDELOLGDGHVGHODVHJXULGDGGHODLQIRUPDFLyQDVRFLDGRVFRQORV
VLVWHPDVGHLQIRUPDFLyQVHFRPXQLFDQGHPDQHUDTXHVHDSRVLEOHHPSUHQGHUODVDFFLRQHVFRUUHFWLYDVRSRUWXQDV
&RQWURO/RVHYHQWRVGHVHJXULGDGGHODLQIRUPDFLyQVH
1RWLILFDFLyQGHORVHYHQWRVGHVHJXULGDGGH
$ GHEHQQRWLILFDUDWUDYpVGHORVFDQDOHVDGHFXDGRVGH
ODLQIRUPDFLyQ
JHVWLyQORDQWHVSRVLEOH
&RQWURO7RGRVORVHPSOHDGRVFRQWUDWLVWDV\WHUFHURVTXH
VHDQXVXDULRVGHORVVLVWHPDV\VHUYLFLRVGHLQIRUPDFLyQ
1RWLILFDFLyQGHORVSXQWRVGpELOHVGHOD
$ GHEHQHVWDUREOLJDGRVDDQRWDU\QRWLILFDUFXDOTXLHUSXQWR
VHJXULGDG
GpELOTXHREVHUYHQRTXHVRVSHFKHQH[LVWDHQGLFKRV
VLVWHPDVRVHUYLFLRV
$*HVWLyQGHLQFLGHQWHVGHVHJXULGDGGHODLQIRUPDFLyQ\PHMRUDV
2EMHWLYR*DUDQWL]DUTXHVHDSOLFDXQHQIRTXHFRKHUHQWH\HIHFWLYRDODJHVWLyQGHORVLQFLGHQWHVGHVHJXULGDGGHOD
LQIRUPDFLyQ
&RQWURO6HGHEHQHVWDEOHFHUODVUHVSRQVDELOLGDGHV\
SURFHGLPLHQWRVGHJHVWLyQSDUDJDUDQWL]DUXQDUHVSXHVWD
$ 5HVSRQVDELOLGDGHV\SURFHGLPLHQWRV
UiSLGDHIHFWLYD\RUGHQDGDDORVLQFLGHQWHVGHVHJXULGDGGH
ODLQIRUPDFLyQ
&RQWURO'HEHQH[LVWLUPHFDQLVPRVTXHSHUPLWDQFXDQWL
$SUHQGL]DMHGHORVLQFLGHQWHVGHVHJXULGDG
$ ILFDU\VXSHUYLVDUORVWLSRVYRO~PHQHV\FRVWHVGHORV
GHODLQIRUPDFLyQ
LQFLGHQWHVGHVHJXULGDGGHODLQIRUPDFLyQ
&RQWURO&XDQGRVHHPSUHQGDXQDDFFLyQFRQWUDXQDSHU
VRQDXRUJDQL]DFLyQGHVSXpVGHXQLQFLGHQWHGHVHJXULGDG
GHODLQIRUPDFLyQTXHLPSOLTXHDFFLRQHVOHJDOHVWDQWR
$ 5HFRSLODFLyQGHHYLGHQFLDV
FLYLOHVFRPRSHQDOHVGHEHQUHFRSLODUVHODVHYLGHQFLDV
FRQVHUYDUVH\SUHVHQWDUVHFRQIRUPHDODVQRUPDV
HVWDEOHFLGDVHQODMXULVGLFFLyQFRUUHVSRQGLHQWH
$*HVWLyQGHODFRQWLQXLGDGGHOQHJRFLR
$$VSHFWRVGHVHJXULGDGGHODLQIRUPDFLyQHQODJHVWLyQGHODFRQWLQXLGDGGHOQHJRFLR
2EMHWLYR&RQWUDUUHVWDUODVLQWHUUXSFLRQHVGHODVDFWLYLGDGHVHPSUHVDULDOHV\SURWHJHUORVSURFHVRVFUtWLFRVGHQHJRFLR
GHORVHIHFWRVGHULYDGRVGHIDOORVLPSRUWDQWHVRFDWDVWUyILFRVGHORVVLVWHPDVGHLQIRUPDFLyQDVtFRPRJDUDQWL]DUVX
RSRUWXQDUHDQXGDFLyQ
&RQWURO'HEHGHVDUUROODUVH\PDQWHQHUVHXQSURFHVRSDUD
,QFOXVLyQGHODVHJXULGDGGHODLQIRUPDFLyQ
ODFRQWLQXLGDGGHOQHJRFLRHQWRGDODRUJDQL]DFLyQTXH
$ HQHOSURFHVRGHJHVWLyQGHODFRQWLQXLGDG
JHVWLRQHORVUHTXLVLWRVGHVHJXULGDGGHODLQIRUPDFLyQ
GHOQHJRFLR
QHFHVDULRVSDUDODFRQWLQXLGDGGHOQHJRFLR
,62,(&
&RQWURO'HEHQLGHQWLILFDUVHORVHYHQWRVTXHSXHGDQFDXVDU
&RQWLQXLGDGGHOQHJRFLR\HYDOXDFLyQGH LQWHUUXSFLRQHVHQORVSURFHVRVGHQHJRFLRDVtFRPRODSUR
$
ULHVJRV EDELOLGDGGHTXHVHSURGX]FDQWDOHVLQWHUUXSFLRQHVVXVHIHF
WRV\VXVFRQVHFXHQFLDVSDUDODVHJXULGDGGHODLQIRUPDFLyQ
&RQWURO'HEHQGHVDUUROODUVHHLPSODQWDUVHSODQHVSDUD
'HVDUUROORHLPSODQWDFLyQGHSODQHVGH PDQWHQHURUHVWDXUDUODVRSHUDFLRQHV\JDUDQWL]DUOD
$ FRQWLQXLGDGTXHLQFOX\DQODVHJXULGDGGHOD GLVSRQLELOLGDGGHODLQIRUPDFLyQHQHOQLYHO\HQHOWLHPSR
LQIRUPDFLyQ UHTXHULGRVGHVSXpVGHXQDLQWHUUXSFLyQRXQIDOORGHORV
SURFHVRVGHQHJRFLRFUtWLFRV
&RQWURO'HEHPDQWHQHUVHXQ~QLFRPDUFRGHUHIHUHQFLD
SDUDORVSODQHVGHFRQWLQXLGDGGHOQHJRFLRSDUDDVHJXUDU
0DUFRGHUHIHUHQFLDSDUDODSODQLILFDFLyQGH TXHWRGRVORVSODQHVVHDQFRKHUHQWHVSDUDFXPSOLUORV
$
ODFRQWLQXLGDGGHOQHJRFLR UHTXLVLWRVGHVHJXULGDGGHODLQIRUPDFLyQGHPDQHUD
FRQVLVWHQWH\SDUDLGHQWLILFDUODVSULRULGDGHVGHUHDOL]DFLyQ
GHSUXHEDV\GHPDQWHQLPLHQWR
&RQWURO/RVSODQHVGHFRQWLQXLGDGGHOQHJRFLRGHEHQ
3UXHEDVPDQWHQLPLHQWR\UHHYDOXDFLyQGH
$ SUREDUVH\DFWXDOL]DUVHSHULyGLFDPHQWHSDUDDVHJXUDUTXH
ORVSODQHVGHFRQWLQXLGDGGHOQHJRFLR
HVWiQDOGtD\TXHVRQHIHFWLYRV
$&XPSOLPLHQWR
$&XPSOLPLHQWRGHORVUHTXLVLWRVOHJDOHV
2EMHWLYR(YLWDULQFXPSOLPLHQWRVGHODVOH\HVRGHODVREOLJDFLRQHVOHJDOHVUHJODPHQWDULDVRFRQWUDFWXDOHV\GHORV
UHTXLVLWRVGHVHJXULGDG
&RQWURO7RGRVORVUHTXLVLWRVSHUWLQHQWHVWDQWROHJDOHVFRPR
UHJODPHQWDULRVRFRQWUDFWXDOHV\HOHQIRTXHGHODRUJDQL]D
$ ,GHQWLILFDFLyQGHODOHJLVODFLyQDSOLFDEOH FLyQSDUDFXPSOLUGLFKRVUHTXLVLWRVGHEHQHVWDUGHILQLGRV
GRFXPHQWDGRV\PDQWHQHUVHDFWXDOL]DGRVGHIRUPDH[SOtFLWR
SDUDFDGDVLVWHPDGHLQIRUPDFLyQGHODRUJDQL]DFLyQ
&RQWURO'HEHQLPSODQWDUVHSURFHGLPLHQWRVDGHFXDGRVSDUD
JDUDQWL]DUHOFXPSOLPLHQWRGHORVUHTXLVLWRVOHJDOHVUHJOD
'HUHFKRVGHSURSLHGDGLQWHOHFWXDO'3,
$ PHQWDULRV\FRQWUDFWXDOHVVREUHHOXVRGHPDWHULDOFRQUHV
>,QWHOOHFWXDO3URSHUW\5LJKWV,35@
SHFWRDOFXDOSXHGDQH[LVWLUGHUHFKRVGHSURSLHGDGLQWHOHF
WXDO\VREUHHOXVRGHSURGXFWRVGHVRIWZDUHSURSLHWDULR
&RQWURO/RVGRFXPHQWRVLPSRUWDQWHVGHEHQHVWDUSURWHJL
3URWHFFLyQGHORVGRFXPHQWRVGHOD GRVFRQWUDODSpUGLGDGHVWUXFFLyQ\IDOVLILFDFLyQGHDFXHU
$
RUJDQL]DFLyQ GRFRQORVUHTXLVLWRVOHJDOHVUHJXODWRULRVFRQWUDFWXDOHV\
HPSUHVDULDOHV
&RQWURO'HEHJDUDQWL]DUVHODSURWHFFLyQ\ODSULYDFLGDGGH
3URWHFFLyQGHGDWRV\SULYDFLGDGGHOD
$ ORVGDWRVVHJ~QVHUHTXLHUDHQODOHJLVODFLyQ\ODVUHJXODFLR
LQIRUPDFLyQSHUVRQDO
QHV\HQVXFDVRHQODVFOiXVXODVFRQWUDFWXDOHVSHUWLQHQWHV
&RQWURO6HGHEHLPSHGLUTXHORVXVXDULRVXWLOLFHQORV
3UHYHQFLyQGHOXVRLQGHELGRGHORVUHFXUVRV
$ UHFXUVRVGHWUDWDPLHQWRGHODLQIRUPDFLyQSDUDILQHVQR
GHWUDWDPLHQWRGHODLQIRUPDFLyQ
DXWRUL]DGRV

127$1$&,21$/ 6HJ~Q UHFRJH OD 1RUPD 81(,62 HO LQJOpV SRVHH WUHV WpUPLQRV GLVWLQWRV GRFXPHQWV UHFRUGV \ DUFKLYHV SDUD
GHVLJQDUORTXHHQFDVWHOODQRFRPRHQHOUHVWRGHOHQJXDVODWLQDVFXHQWDFRQXQD~QLFDYR]GRFXPHQWRV$VtGRFXPHQWHV
HOHTXLYDOHQWHGHGRFXPHQWRHQVXVLJQLILFDGRJHQpULFRFRPRPHUDLQIRUPDFLyQUHJLVWUDGD3RUHOFRQWUDULRORVWpUPLQRV
UHFRUGV \ DUFKLYHV GHVLJQDQ GH PDQHUD HVSHFtILFD D DTXHOORV GRFXPHQWRV SURGXFLGRV FRPR SUXHED \ UHIOHMR GH ODV
DFWLYLGDGHV GH OD RUJDQL]DFLyQ TXH ORV KD FUHDGR UHVHUYiQGRVH HO HPSOHR GH HVWH ~OWLPR D ORV GRFXPHQWRV GH FDUiFWHU
KLVWyULFR
,62,(&
&RQWURO/RVFRQWUROHVFULSWRJUiILFRVVHGHEHQXWLOL]DUGH
$ 5HJXODFLyQGHORVFRQWUROHVFULSWRJUiILFRV DFXHUGRFRQWRGRVORVFRQWUDWRVOH\HV\UHJXODFLRQHV
SHUWLQHQWHV
$&XPSOLPLHQWRGHODVSROtWLFDV\QRUPDVGHVHJXULGDG\FXPSOLPLHQWRWpFQLFR
2EMHWLYR$VHJXUDUTXHORVVLVWHPDVFXPSOHQODVSROtWLFDV\QRUPDVGHVHJXULGDGGHODRUJDQL]DFLyQ
&RQWURO/RVGLUHFWRUHVGHEHQDVHJXUDUVHGHTXHWRGRVORV
&XPSOLPLHQWRGHODVSROtWLFDV\QRUPDVGH SURFHGLPLHQWRVGHVHJXULGDGGHQWURGHVXiUHDGHUHVSRQVD
$
VHJXULGDG ELOLGDGVHUHDOL]DQFRUUHFWDPHQWHFRQHOILQGHFXPSOLUODV
SROtWLFDV\QRUPDVGHVHJXULGDG
&RQWURO'HEHFRPSUREDUVHSHULyGLFDPHQWHTXHORVVLVWH
$ &RPSUREDFLyQGHOFXPSOLPLHQWRWpFQLFR PDVGHLQIRUPDFLyQFXPSOHQODVQRUPDVGHDSOLFDFLyQGH
ODVHJXULGDG
$&RQVLGHUDFLRQHVVREUHODDXGLWRULDGHORVVLVWHPDVGHLQIRUPDFLyQ
2EMHWLYR/RJUDUTXHHOSURFHVRGHDXGLWRULDGHORVVLVWHPDVGHLQIRUPDFLyQDOFDQFHODPi[LPDHILFDFLDFRQODVPtQL
PDVLQWHUIHUHQFLDV
&RQWURO/RVUHTXLVLWRV\ODVDFWLYLGDGHVGHDXGLWRULDTXH
LPSOLTXHQFRPSUREDFLRQHVHQORVVLVWHPDVRSHUDWLYRVGH
&RQWUROHVGHDXGLWRULDGHORVVLVWHPDVGH
$ EHQVHUFXLGDGRVDPHQWHSODQLILFDGRV\DFRUGDGRVSDUD
LQIRUPDFLyQ
PLQLPL]DUHOULHVJRGHLQWHUUXSFLRQHVHQORVSURFHVRVGH
HPSUHVDULDOHV
&RQWURO(ODFFHVRDODVKHUUDPLHQWDVGHDXGLWRULDGHORV
3URWHFFLyQGHODVKHUUDPLHQWDVGHDXGLWRULD
$ VLVWHPDVGHLQIRUPDFLyQGHEHHVWDUSURWHJLGRSDUDHYLWDU
GHORVVLVWHPDVGHLQIRUPDFLyQ
FXDOTXLHUSRVLEOHSHOLJURRXVRLQGHELGR

,62,(&
$1(;2%,QIRUPDWLYR

/2635,1&,3,26'(/$2&'(<(67$1250$,17(51$&,21$/

/RV SULQFLSLRV UHFRJLGRV HQ ODV 'LUHFWULFHV GH OD 2&'( SDUD OD VHJXULGDG GH ORV VLVWHPDV \ UHGHV GH LQIRUPDFLyQ VH
DSOLFDQ D WRGDV ODV SROtWLFDV \ D WRGRV ORV QLYHOHV GH RSHUDFLyQ TXH ULJHQ OD VHJXULGDG GH ORV VLVWHPDV \ UHGHV GH
LQIRUPDFLyQ(VWDQRUPDLQWHUQDFLRQDOFRQVWLWX\HHOPDUFRGHOVLVWHPDGHJHVWLyQGHODVHJXULGDGGHODLQIRUPDFLyQSDUD
LPSOHPHQWDUDOJXQRVGHORVSULQFLSLRVGHOD2&'(XWLOL]DQGRHOPRGHOR3'&$\ORVSURFHVRVGHVFULWRVHQORVFDStWX
ORV\VHJ~QVHLQGLFDHQODWDEOD%

7DEOD%−/RVSULQFLSLRVGHOD2&'(\HOPRGHOR3'&$

3ULQFLSLRGHOD2&'( 3URFHVRGHO6*6,\IDVHGHO3'&$FRUUHVSRQGLHQWHV
&RQFLHQFLDFLyQ (VWDDFWLYLGDGHVSDUWHGHODIDVH+DFHU'R
YpDQVH\
/RVSDUWLFLSDQWHVGHEHQFRQFLHQFLDUVHGHODQHFHVLGDGGHJD
UDQWL]DUODVHJXULGDGGHORVVLVWHPDV\UHGHVGHLQIRUPDFLyQ\
VDEHUTXpSXHGHQKDFHUHOORVSDUDPHMRUDUODVHJXULGDG
5HVSRQVDELOLGDG (VWDDFWLYLGDGHVSDUWHGHODIDVH+DFHU'R
YpDQVH\
7RGRVORVSDUWLFLSDQWHVVRQUHVSRQVDEOHVGHODVHJXULGDGGH
ORVVLVWHPDV\UHGHVGHLQIRUPDFLyQ
5HVSXHVWD (VWRHVHQSDUWHXQDDFWLYLGDGGHVXSHUYLVLyQGHODIDVH
9HULILFDU&KHFNYpDVH\D\XQDDFWL
/RVSDUWLFLSDQWHVGHEHQDFWXDUGHIRUPDRSRUWXQD\ YLGDGGHUHVSXHVWDGHODIDVH$FWXDU$FWYpDVH
FRRUGLQDGDSDUDSUHYHQLUGHWHFWDU\UHVSRQGHUDORV \D7DPELpQSXHGHWHQHUTXHYHUFRQDOJXQRV
LQFLGHQWHVGHVHJXULGDG DVSHFWRVGHODVIDVHV3ODQLILFDU3ODQ\9HULILFDU
&KHFN
(YDOXDFLyQGHULHVJRV (VWDDFWLYLGDGHVSDUWHGHODIDVH3ODQLILFDU3ODQ
YpDVH\ODUHHYDOXDFLyQGHOULHVJRHVSDUWHGHOD
/RVSDUWLFLSDQWHVGHEHQOOHYDUDFDERHYDOXDFLRQHVGH IDVH9HULILFDU&KHFNYpDVH\D
ULHVJRV
'LVHxRHLPSODQWDFLyQGHODVHJXULGDG 8QDYH]TXHILQDOL]DGDODHYDOXDFLyQGHULHVJRVVHVH
OHFFLRQDQORVFRQWUROHVSDUDHOWUDWDPLHQWRGHORVULHVJRV
/RVSDUWLFLSDQWHVGHEHQLQFRUSRUDUODVHJXULGDGFRPRXQ FRPRSDUWHGHODIDVH3ODQLILFDU3ODQYpDVH/D
HOHPHQWRHVHQFLDOGHORVVLVWHPDV\UHGHVGHLQIRUPDFLyQ IDVH+DFHU'RYpDVH\FRPSUHQGHOD
LPSODQWDFLyQ\HOXVRRSHUDWLYRGHHVWRVFRQWUROHV
*HVWLyQGHODVHJXULGDG /DJHVWLyQGHOULHVJRHVXQSURFHVRTXHLQFOX\HOD
SUHYHQFLyQGHWHFFLyQ\UHVSXHVWDDORVLQFLGHQWHV\OD
/RVSDUWLFLSDQWHVGHEHQDGRSWDUFULWHULRVGHWDOODGRVGH JHVWLyQFRQWLQXDGDGHODVHJXULGDG7RGRVHVWRVDVSHFWRV
PDQWHQLPLHQWRUHYLVLyQ\DXGLWRUtD HVWiQFRPSUHQGLGRVHQODVIDVHV3ODQLILFDU3ODQ
+DFHU'R9HULILFDU&KHFN\$FWXDU$FW
5HHYDOXDFLyQ /DUHHYDOXDFLyQGHODVHJXULGDGGHODLQIRUPDFLyQHV
SDUWHGHODIDVH9HULILFDU&KHFNYpDVH\D
/RVSDUWLFLSDQWHVGHEHQUHYLVDU\UHHYDOXDUODVHJXULGDGGH HQODFXDOGHEHQOOHYDUVHDFDERUHYLVLRQHVSHULy
ORVVLVWHPDV\UHGHVGHLQIRUPDFLyQ\HIHFWXDUODV GLFDVSDUDFRPSUREDUODHILFDFLDGHOVLVWHPDGHJHVWLyQ
PRGLILFDFLRQHVDSURSLDGDVGHODVSROtWLFDVSUiFWLFDV GHVHJXULGDGGHODLQIRUPDFLyQ\ODPHMRUDGHODVHJX
PHGLGDV\SURFHGLPLHQWRVGHVHJXULGDG ULGDGHVSDUWHGHODIDVH$FWXDU$FWYpDVH\
D
,62,(&
$1(;2&,QIRUPDWLYR

&255(6321'(1&,$(175(/$61250$6,62,62
<(67$1250$,17(51$&,21$/

/DWDEOD&PXHVWUDODFRUUHVSRQGHQFLDHQWUHODVQRUPDV,62H,62\HVWDQRUPDLQWHUQDFLRQDO

7DEOD&−&RUUHVSRQGHQFLDHQWUHODVQRUPDV,62H,62\HVWDQRUPDLQWHUQDFLRQDO

(VWDQRUPDLQWHUQDFLRQDO ,62 ,62
,QWURGXFFLyQ ,QWURGXFFLyQ ,QWURGXFFLyQ
*HQHUDOLGDGHV *HQHUDOLGDGHV
(QIRTXHGHOSURFHVR (QIRTXHGHOSURFHVR
5HODFLyQFRQOD1RUPD,62
&RPSDWLELOLGDGFRQRWURV &RPSDWLELOLGDGFRQRWURVVLVWHPDV
VLVWHPDVGHJHVWLyQ GHJHVWLyQ
2EMHWR\FDPSRGHDSOLFDFLyQ 2EMHWR\FDPSRGHDSOLFDFLyQ 2EMHWR\FDPSRGHDSOLFDFLyQ
$SOLFDFLyQ $SOLFDFLyQ
1RUPDVSDUDFRQVXOWD 1RUPDVSDUDFRQVXOWD 1RUPDVSDUDFRQVXOWD
7pUPLQRV\GHILQLFLRQHV 7pUPLQRV\GHILQLFLRQHV 7pUPLQRV\GHILQLFLRQHV
6HJXULGDGGHODLQIRUPDFLyQ 6LVWHPDGHJHVWLyQGHODFDOLGDG 6LVWHPDGHJHVWLyQGHORVUHTXL
VLWRVGHO6*$
5HTXLVLWRVJHQHUDOHV 5HTXLVLWRVJHQHUDOHV 5HTXLVLWRVJHQHUDOHV
&UHDFLyQGHO6*6,
,PSODQWDFLyQ\RSHUDFLyQGHO ,PSODQWDFLyQ\RSHUDFLyQ
6*6,
6XSHUYLVLyQ\UHYLVLyQGHO 6XSHUYLVLyQ\PHGLFLyQGHORV 6XSHUYLVLyQ\PHGLFLyQ
6*6, SURFHVRV
6XSHUYLVLyQ\PHGLFLyQGHO
SURGXFWR
0DQWHQLPLHQWR\PHMRUDGHO
6*6,
5HTXLVLWRVGHODGRFXPHQWDFLyQ 5HTXLVLWRVGHGRFXPHQWDFLyQ
0DQXDOGHFDOLGDG
&RQWUROGHGRFXPHQWRV &RQWUROGHGRFXPHQWRV &RQWUROGHGRFXPHQWDFLyQ
&RQWUROGHUHJLVWURV &RQWUROGHUHJLVWURV &RQWUROGHUHJLVWURV
,62,(&
(VWDQRUPDLQWHUQDFLRQDO ,62 ,62

5HVSRQVDELOLGDGGHOD'LUHFFLyQ 5HVSRQVDELOLGDGGHOD'LUHFFLyQ
&RPSURPLVRGHOD'LUHFFLyQ &RPSURPLVRGHOD'LUHFFLyQ
2ULHQWDFLyQDOFOLHQWH
3ROtWLFDGHFDOLGDG 3ROtWLFDDPELHQWDO
3ODQLILFDFLyQ 3ODQLILFDFLyQ
5HVSRQVDELOLGDGDXWRULGDG\
FRPXQLFDFLyQ
*HVWLyQGHORVUHFXUVRV *HVWLyQGHORVUHFXUVRV
3URYLVLyQGHORVUHFXUVRV 3URYLVLyQGHORVUHFXUVRV
5HFXUVRVKXPDQRV
&RQFLHQFLDFLyQIRUPDFLyQ\ &RPSHWHQFLDFRQFLHQFLDFLyQ\ &RPSHWHQFLDIRUPDFLyQ\
FRPSHWHQFLD IRUPDFLyQ FRQFLHQFLDFLyQ
,QIUDHVWUXFWXUD
(QWRUQRGHWUDEDMR
$XGLWRUtDVLQWHUQDVGHO6*6, $XGLWRUtDLQWHUQD $XGLWRUtDLQWHUQD
5HYLVLyQGHO6*6,SRUOD 5HYLVLyQSRUOD'LUHFFLyQ 5HYLVLyQSRUOD'LUHFFLyQ
'LUHFFLyQ
'DWRVLQLFLDOHVGHODUHYLVLyQ 'DWRVLQLFLDOHVGHODUHYLVLyQ
5HVXOWDGRVGHODUHYLVLyQ 5HVXOWDGRVGHODUHYLVLyQ
0HMRUDGHO6*6, 0HMRUD
0HMRUDFRQWLQXD 0HMRUDFRQWLQXD
$FFLyQFRUUHFWLYD $FFLRQHVFRUUHFWLYDV 'LVFRQIRUPLGDGDFFLyQ
FRUUHFWLYD\DFFLyQSUHYHQWLYD
$FFLyQSUHYHQWLYD $FFLRQHVSUHYHQWLYDV
$QH[R$2EMHWLYRVGHFRQWURO\ $QH[R$*XtDGHXVRGHHVWD
FRQWUROHV QRUPDLQWHUQDFLRQDO
$QH[R%/RVSULQFLSLRVGHOD
2&'(\HVWDQRUPDLQWHUQDFLRQDO
$QH[R&&RUUHVSRQGHQFLDHQWUH $QH[R$&RUUHVSRQGHQFLDHQWUHODV $QH[R%&RUUHVSRQGHQFLDHQWUH
ODV1RUPDV,62H 1RUPDV,62H ODV1RUPDV,62H
,62\HVWDQRUPD ,62 ,62
LQWHUQDFLRQDO

,62,(&
%,%/,2*5$)Ë$

3XEOLFDFLRQHVGHQRUPDV

>@ ,626LVWHPDVGHJHVWLyQGHODFDOLGDG5HTXLVLWRV

>@ ,62,(&7HFQRORJtDVGHODLQIRUPDFLyQ7pFQLFDVGHVHJXULGDG*HVWLyQGHODVHJXULGDGGHODV
WHFQRORJtDVGHODLQIRUPDFLyQ\ODVFRPXQLFDFLRQHV3DUWH&RQFHSWRV\PRGHORVSDUDODJHVWLyQGHODVHJXUL
GDGGHODVWHFQRORJtDVGHODLQIRUPDFLyQ\ODVFRPXQLFDFLRQHV

>@ ,62,(&757HFQRORJtDVGHODLQIRUPDFLyQ'LUHFWULFHVSDUDODJHVWLyQGHODVHJXULGDGGHODV7,
3DUWH7pFQLFDVSDUDODJHVWLyQGHODVHJXULGDGGHODV7,

>@ ,62,(&757HFQRORJtDVGHODLQIRUPDFLyQ'LUHFWULFHVSDUDODJHVWLyQGHODVHJXULGDGGHODV7,
3DUWH6HOHFFLyQGHVDOYDJXDUGLDV

>@ ,626LVWHPDVGHJHVWLyQDPELHQWDO5HTXLVLWRV\RULHQWDFLRQHVGHXVR

>@ ,62,(& 75 7HFQRORJtDV GH OD LQIRUPDFLyQ 7pFQLFDV GH VHJXULGDG *HVWLyQ GH LQFLGHQWHV GH
VHJXULGDGGHODLQIRUPDFLyQ

>@ ,62'LUHFWULFHVSDUDDXGLWRUtDVGHFDOLGDGRGHVLVWHPDVGHJHVWLyQDPELHQWDO

>@ ,62,(& *XtD 5HTXLVLWRV JHQHUDOHV SDUD HQWLGDGHV HQFDUJDGDV GH OD HYDOXDFLyQ \ FHUWLILFDFLyQ R
UHJLVWURGHVLVWHPDVGHFDOLGDG

>@ ,62,(&*XtD*HVWLyQGHULHVJRV9RFDEXODULR'LUHFWULFHVGHXVRHQQRUPDV

2WUDVSXEOLFDFLRQHV

>@ 2&'( 'LUHFWULFHV SDUD OD VHJXULGDG GH ORV VLVWHPDV \ UHGHV GH LQIRUPDFLyQ +DFLD XQD FXOWXUD GH OD
VHJXULGDG3DUtV2&'(MXOLRGHZZZRHFGRUJ

>@ 1,6763*XtDGHJHVWLyQGHULHVJRVSDUDVLVWHPDVGHWHFQRORJtDVGHODLQIRUPDFLyQ

>@ 'HPLQJ:(2XWRIWKH&ULVLV&DPEULGJH0DVV0,7&HQWHUIRU$GYDQFHG(QJLQHHULQJ6WXG\

Sobre los autores
Luis Gómez Fernández es licenciado en Económicas por la Facultad de Económicas

de la Universidad de Oviedo. Ha desempeñado diversos cargos directivos, tanto en
la Administración Pública como la empresa privada, hasta la creación de su propia
empresa que, actualmente, es un referente en seguridad de la información y servicios
de TI.
Ana Andrés Álvarez es ingeniera de software por la University of Salford, Certified
Information Systems Auditor (CISA) y Certified Information Security Management
(CISM). Tiene una dilatada carrera profesional desempeñada en el área de sistemas
de gestión y mejora de procesos, y especialmente, en proyectos de seguridad de la
información, servicios de TI y auditorías de sistemas de gestión.

Guía de Aplicación de La Norma UNE-ISOIEC 27001 Sobre Segurida PDF

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

Guía de Aplicación de La Norma UNE-ISOIEC 27001 Sobre Segurida PDF

Cargado por

Copyright:

Formatos disponibles

Guía de aplicación de la Norma UNE-ISO/IEC 27001

sobre seguridad en sistemas

Luis Gómez Fernández y Ana Andrés Álvarez

© AENOR (Asociación Española de Normalización y Certificación), 2012

Objeto de esta guía . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1. Introducción a los Sistemas de Gestión de Seguridad de

2. Comprender la Norma UNE-ISO/IEC 27001 . . . . . . . . . . . . . . . . . . . . . 23

2.2.4. Identificación de los activos de información . . . . . . . . . . . . 28

3. Comprender la Norma UNE-ISO/IEC 27002 . . . . . . . . . . . . . . . . . . . . . 45

3.8. Control de acceso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

4. Definición e implementación de un SGSI . . . . . . . . . . . . . . . . . . . . . . . . 73

6. Relación entre los apartados de la norma y la documentación del sistema . . 93

7. Correspondencia entre las Normas UNE-EN ISO 9001:2008,

8. Caso práctico: modelo de SGSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

8.2.2. Inventario de activos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

9. Comprender el Esquema Nacional de Seguridad (ENS) . . . . . . . . . . . . . 137

10. Implementación del ENS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

10.2.3. Verificación y validación . . . . . . . . . . . . . . . . . . . . . . . . . . 154

11. Ejemplo práctico: plan de adecuación . . . . . . . . . . . . . . . . . . . . . . . . . . 157

12. Bibliografía . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

Norma UNE-ISO/IEC 27001:2007 Tecnología de la información. Técnicas de

La información es el principal activo de muchas organizaciones y precisa ser prote-

La seguridad total es inalcanzable, pero mediante el proceso de mejora continua

El objeto de esta publicación es facilitar la comprensión de los diversos conceptos

1.1. Definición de un SGSI

comprensibles para la mayoría de la gente, y que para explicarla en detalle sea

1.2. El ciclo de mejora continua

• Act. Es la fase en la que se mantiene y mejora el SGSI, decidiendo y efec-

La mejora continua es un proceso en sí mismo. Debe entenderse como la mejora

Tomar acciones correctivas

Revisar y auditar el SGSI Check Do Implementar el SGSI

Figura 1.1. Ciclo PDCA

1.3. La Norma UNE-ISO/IEC 27001

1.3.2. Objeto y campo de aplicación de la norma

1.4. La Norma UNE-ISO/IEC 27002

1.4.2. Objeto y campo de aplicación

1.5. El Esquema Nacional de Seguridad (ENS)

la protección de la información y de los servicios en el ámbito de la administración

1.5.2. Objeto y campo de aplicación

1.6. Términos y definiciones

• Evento de seguridad de la información

• Incidente de seguridad de la información

• Sistema de Gestión de la Seguridad de la Información (SGSI) [Information

• Aceptación del riesgo

La seguridad no es el resultado de un proceso, es un proceso en sí mismo. Se con-

2.1. Requisitos generales del sistema de gestión

Lo que la norma reclama es que exista un sistema documentado (política, análisis

Figura 2.1. Niveles de documentación

2.2. Establecimiento y gestión del SGSI

Figura 2.2. Requisitos del SGSI

proponer opciones y tomar decisiones. Es fundamental no comprometer recursos

• Las decisiones de la dirección respecto a los riesgos identificados, así como

Analizar los riesgos

Tratar los riesgos

Figura 2.3. Establecer el SGSI

2.2.2. Definición del alcance del SGSI

hay que tener en cuenta que dimensionar correctamente el proyecto es fundamental

2.2.3. Definición de la política de seguridad

2.2.4. Identificación de los activos de información

2.2.5. Definición del enfoque del análisis de riesgos

2.2.6. Cómo escoger la metodología del análisis

2.2.7. Tratamiento de los riesgos

2.2.8. Selección de controles