ISO/IEC 27001:2022 · Normativa de Ciberseguridad
Guía completa de estudio: definiciones, esquemas, controles, análisis de riesgos y test de autoevaluación.
§ 01 — Introducción
La norma ISO/IEC 27001 es el estándar internacional más reconocido para la gestión de la seguridad de la información. Proporciona un marco sistemático para establecer, implementar, mantener y mejorar continuamente un Sistema de Gestión de Seguridad de la Información (SGSI).
Publicada por la Organización Internacional de Normalización (ISO) junto con la Comisión Electrotécnica Internacional (IEC), su versión más reciente es la de 2022, que reorganizó el Anexo A y redujo el número de controles de 114 a 93, agrupándolos en 4 temas en lugar de los 14 dominios anteriores.
El objetivo principal es proteger la confidencialidad, integridad y disponibilidad (la llamada tríada CIA) de la información de una organización, identificando los riesgos y aplicando los controles adecuados para mitigarlos.
El British Standards Institute publica BS 7799, el primer estándar de seguridad de la información que luego inspiró la familia ISO 27000.
Primera versión oficial de la norma ISO 27001. Introduce el modelo PDCA y 133 controles en 11 dominios.
Revisión mayor. 114 controles en 14 dominios. Incorpora la estructura de alto nivel (HLS) para compatibilidad con otras normas ISO.
Versión actual. 93 controles en 4 temas. Añade 11 nuevos controles y moderniza el enfoque para entornos cloud y amenazas actuales.
§ 02 — La Familia
La familia ISO/IEC 27000 es un conjunto de estándares interrelacionados que cubren distintos aspectos de la seguridad de la información. Cada norma aborda un dominio específico, permitiendo a las organizaciones construir un SGSI completo y personalizado.
§ 03 — Glosario
Comprender la terminología exacta es fundamental para trabajar con la norma ISO 27001 y redactar correctamente un SoA. Estos son los conceptos más importantes:
Conjunto de políticas, procedimientos, procesos y controles que una organización implementa para gestionar la seguridad de su información de manera sistemática y continua, en función de sus objetivos de negocio y su apetito de riesgo.
Documento obligatorio del SGSI que enumera todos los controles del Anexo A de la ISO 27001, indicando para cada uno si es aplicable o no, la justificación de la decisión y el estado de implementación. Es la "fotografía" del estado de seguridad de la organización.
Confidencialidad: solo acceden los autorizados. Integridad: la información no se altera sin permiso. Disponibilidad: la información es accesible cuando se necesita. Estos tres principios fundamentan todos los controles de seguridad.
Efecto de la incertidumbre sobre los objetivos de seguridad de la información. Se expresa habitualmente como la combinación entre la probabilidad de que ocurra una amenaza y el impacto que tendría sobre la organización: Riesgo = Probabilidad × Impacto.
Cualquier elemento que tiene valor para la organización y que debe ser protegido. Puede ser tangible (servidores, dispositivos) o intangible (código fuente, datos de clientes, credenciales de acceso, reputación). Los activos son el "qué protegemos".
Causa potencial de un incidente no deseado que puede resultar en daño a la organización o sus sistemas. Las amenazas pueden ser internas o externas, deliberadas (ataque malicioso) o accidentales (error humano, desastre natural).
Debilidad de un activo o control que puede ser explotada por una o más amenazas. Una vulnerabilidad por sí sola no causa daño; necesita ser combinada con una amenaza. Ejemplo: contraseñas débiles (vulnerabilidad) + ataque de fuerza bruta (amenaza).
Medida (técnica, organizativa, física o legal) implementada para modificar el riesgo. Los controles pueden ser preventivos (evitan que ocurra el incidente), detectivos (identifican cuando ocurre) o correctivos (reducen el impacto después de que ocurre).
Modelo de mejora continua sobre el que se basa el SGSI. Planificar: definir el SGSI. Hacer: implementar controles. Verificar: monitorear y auditar. Actuar: mejorar basándose en resultados.
Reglamento europeo (UE 2016/679) que regula el tratamiento de datos personales. Establece obligaciones para los responsables del tratamiento, derechos de los interesados y sanciones de hasta el 4% de la facturación mundial o 20 millones de euros.
Evaluación comparativa entre el estado actual de seguridad de la organización y los requisitos de la norma. Identifica qué controles ya existen, cuáles están parcialmente implementados y cuáles son inexistentes. Base para el plan de implementación.
Solución de seguridad que monitorea continuamente los dispositivos finales (endpoints) para detectar, investigar y responder a amenazas avanzadas como malware, ransomware o comportamientos anómalos. Supera las capacidades del antivirus tradicional.
Enfoque donde las aplicaciones se diseñan y operan completamente en la nube, aprovechando servicios como almacenamiento, bases de datos y computación bajo demanda. Implica una responsabilidad compartida de seguridad con el proveedor cloud.
Anonimización: proceso irreversible que elimina toda posibilidad de identificar a una persona. Seudonimización: sustitución de identificadores directos por un pseudónimo, reversible con información adicional protegida. El RGPD requiere al menos seudonimización en entornos de prueba.
Práctica de gestionar y provisionar infraestructura tecnológica mediante archivos de configuración (código), en lugar de procesos manuales. Permite reproducibilidad, control de versiones y configuraciones seguras y auditables. Herramientas: Terraform, Ansible, CloudFormation.
Nivel de riesgo que una organización está dispuesta a aceptar en la búsqueda de sus objetivos. Determina qué riesgos se tratan, cuáles se transfieren (seguros), cuáles se evitan y cuáles se aceptan. Debe ser definido por la alta dirección.
§ 04 — Modelo
El SGSI se basa en el ciclo de mejora continua Plan-Do-Check-Act (Planificar-Hacer-Verificar-Actuar), también conocido como ciclo de Deming. Este modelo garantiza que la seguridad no sea un proyecto puntual sino un proceso vivo que evoluciona con la organización.
Definir el alcance, política y objetivos del SGSI. Identificar activos, amenazas y riesgos. Seleccionar controles.
Implementar los controles seleccionados. Formación y concienciación. Gestión de operaciones y recursos.
Ejecutar acciones correctivas y preventivas. Comunicar resultados. Actualizar el SGSI y el SoA.
Monitorear, medir y revisar el SGSI. Auditorías internas y externas. Revisión por la dirección.
| Fase | Actividades concretas | Responsable |
|---|---|---|
| PLAN | Identificar activos cloud, evaluar riesgos de repositorios y datos de prueba, redactar el SoA inicial | CTO / CISO |
| DO | Configurar permisos cloud, instalar EDR en dispositivos remotos, aplicar seudonimización en BBDD de prueba | Equipo de DevOps |
| CHECK | Revisar logs de acceso, auditar configuraciones cloud, comprobar actualizaciones de EDR | Responsable de Seguridad |
| ACT | Corregir configuraciones inseguras detectadas, actualizar inventario de activos, mejorar políticas de acceso remoto | Dirección + Equipo técnico |
§ 05 — Documento Central
La Declaración de Aplicabilidad (Statement of Applicability) es un documento obligatorio exigido por la cláusula 6.1.3 de la ISO 27001. Actúa como el nexo entre el análisis de riesgos y los controles implementados.
Establece exactamente qué se protege, con qué medidas y por qué. Permite saber de un vistazo el estado de seguridad completo.
Sin SoA no hay certificación ISO 27001. Los auditores externos lo revisan para verificar que los controles seleccionados son adecuados y coherentes.
No todos los controles aplican a todas las organizaciones. El SoA documenta formalmente qué controles se excluyen y por qué, con argumentación válida.
Permite a la dirección conocer el estado de implementación de cada control y priorizar recursos de inversión en seguridad.
§ 06 — Metodología
El análisis de riesgos es la base sobre la que se construye todo el SGSI y, especialmente, el SoA. La norma no prescribe una metodología específica, pero sí exige que sea sistemática, documentada y repetible.
Aplicar controles de seguridad que reduzcan la probabilidad o el impacto del riesgo a un nivel aceptable. Es la opción más común. Ejemplo: instalar EDR para mitigar el riesgo de malware.
Decidir no realizar la actividad que genera el riesgo. Ejemplo: no usar datos reales en entornos de prueba para evitar el riesgo de fuga de datos personales.
Compartir el riesgo con un tercero, generalmente mediante seguros o cláusulas contractuales. Ejemplo: contratar un seguro de ciberriesgos o exigir SLAs de seguridad al proveedor cloud.
Reconocer conscientemente que el riesgo existe y decidir no actuar, porque el coste del control supera el beneficio o el riesgo está dentro del apetito definido. Debe documentarse formalmente.
| Activo | Amenaza principal | Vulnerabilidad | Riesgo | Tratamiento |
|---|---|---|---|---|
| Código fuente (repositorio cloud) | Robo de propiedad intelectual | Accesos no controlados / credenciales comprometidas | CRÍTICO | Mitigar (A.5.9, A.5.23) |
| Bases de datos de prueba | Fuga de información sensible | Uso de datos reales o mal anonimizados | ALTO | Mitigar (A.8.11) |
| Infraestructura Cloud | Acceso no autorizado | Configuración insegura por defecto | ALTO | Mitigar (A.8.9, A.5.23) |
| Dispositivos remotos | Malware / accesos indebidos | Uso de redes inseguras / dispositivos personales | ALTO | Mitigar (A.8.7) |
§ 07 — Controles ISO 27001:2022
La versión 2022 de ISO 27001 reorganizó sus controles en 4 grandes temas, añadiendo 11 controles nuevos para responder a las amenazas actuales (cloud, DevSecOps, amenazas de datos, privacidad, etc.).
Políticas, roles, responsabilidades, gestión de activos, relaciones con proveedores, continuidad de negocio, cumplimiento legal. Son la base estratégica y de gobernanza del SGSI.
Cribado de personal, términos de empleo, concienciación y formación, responsabilidades post-empleo, acuerdos de confidencialidad, trabajo remoto y reporte de incidentes.
Perímetros de seguridad, acceso físico, seguridad en oficinas, protección ante amenazas físicas y ambientales, trabajo en áreas seguras, escritorios limpios, activos fuera de las instalaciones.
El tema más amplio. Cubre dispositivos de usuario, accesos privilegiados, gestión de claves, malware, redes, desarrollo seguro, gestión de vulnerabilidades, logs y monitoreo, entre otros.
Por qué aplica: La empresa opera con múltiples recursos cloud (repositorios, BBDD, entornos) que deben estar inventariados y con responsables asignados.
Por qué aplica: Todo el negocio depende de proveedores cloud, lo que introduce riesgos específicos de configuración, acceso y disponibilidad.
Por qué aplica: Errores de configuración en entornos cloud o de desarrollo pueden generar accesos indebidos o fugas de información sensible.
Por qué aplica: Los dispositivos remotos de los empleados son un punto crítico de entrada de amenazas como malware o ransomware.
Por qué aplica: Se utilizan datos sensibles (estructuras de historias clínicas) en entornos de prueba, lo que requiere minimizar el riesgo de exposición.
Justificación: Los activos críticos (código fuente, BBDD, entornos) no residen en dispositivos locales sino en infraestructura cloud. Los dispositivos actúan solo como terminales de acceso, reduciendo significativamente el riesgo físico asociado.
Justificación: AppInnovate no dispone de infraestructuras físicas críticas propias (CPDs, servidores locales). Los riesgos ambientales sobre sistemas críticos son responsabilidad del proveedor cloud contratado.
Justificación: La organización no dispone de centros de datos propios. La disponibilidad de servicios como electricidad o climatización es responsabilidad del proveedor cloud, no de AppInnovate.
§ 08 — Caso Práctico
A continuación se presenta la tabla resumen de la Declaración de Aplicabilidad para AppInnovate, una startup de 15 empleados especializada en aplicaciones móviles para el sector sanitario (e-Health), que opera bajo un modelo Cloud Native.
| Control | Descripción | ¿Aplica? | Justificación | Estado |
|---|---|---|---|---|
| A.5.9 | Inventario de activos | Sí | Control necesario para gestionar los recursos cloud | Implementado |
| A.5.23 | Seguridad en servicios cloud | Sí | Dependencia total de proveedores cloud | Implementado |
| A.8.9 | Gestión de la configuración | Sí | Evitar errores de configuración en entornos cloud | En proceso |
| A.8.7 | Protección contra malware | Sí | Riesgos en dispositivos remotos de empleados | Implementado |
| A.8.11 | Enmascaramiento de datos | Sí | Uso de datos sensibles en entornos de prueba | En proceso |
| A.7.9 | Seguridad de activos fuera de instalaciones | No | Los activos críticos están en la nube, no en dispositivos físicos | Excluido |
| A.7.5 | Protección contra amenazas físicas y ambientales | No | Infraestructura gestionada íntegramente por el proveedor cloud | Excluido |
| A.7.11 | Servicios públicos de apoyo | No | Servicios físicos gestionados por el proveedor cloud | Excluido |
Aunque no trabaja con pacientes reales en producción, maneja estructuras de historias clínicas y datos biométricos en entornos de prueba. Esto lo convierte en responsable del tratamiento de datos sensibles (Art. 9 RGPD), obligando a aplicar medidas técnicas y organizativas reforzadas.
Norma específica para seguridad de la información en el sector salud. Complementa a la ISO 27001 con controles adicionales para proteger la información sanitaria (registros médicos, datos biométricos). Recomendable para AppInnovate como referencia sectorial.
La ISO 27017 añade controles específicos para proveedores y usuarios de servicios cloud. La ISO 27018 se centra en la protección de datos personales en cloud. Ambas son muy relevantes para un modelo Cloud Native que maneje datos sanitarios.
§ 09 — Preguntas Frecuentes
§ 10 — Autoevaluación