Modulo 01. Cumplimiento y gestion del riesgo

Objetivo del modulo

Entender el cumplimiento como una capacidad continua basada en riesgo, ownership y evidencias, no como una preparacion puntual para auditorias.

Resultados esperados

• Relacionar requisito, activo, riesgo, control y evidencia en un modelo coherente.
• Distinguir cumplimiento formal (documentos) de cumplimiento efectivo (controles operativos verificables).
• Disenar una aproximacion inicial de gestion de riesgos aplicada a marcos normativos como ENS, GDPR e ISO 27001.
• Identificar los roles clave en un programa de cumplimiento.

Desarrollo teorico

Compliance util no significa acumular politicas, rellenar checklists ni presentar documentacion al auditor una vez al ano. Significa demostrar de forma continua que la organizacion conoce sus activos criticos, entiende sus riesgos, aplica controles proporcionales, asigna responsabilidades claras y conserva evidencias verificables. Cuando esto falta, el cumplimiento se convierte en teatro documental: existen normas y procedimientos aprobados por direccion, pero no conectan con la operacion real ni con el riesgo que supuestamente pretenden reducir. El resultado es una organizacion que aprueba auditorias formales pero sigue expuesta a amenazas reales.

La gestion del riesgo es el puente entre el requisito normativo y el control operativo. Ningun marco serio (ENS, GDPR, ISO 27001) se interpreta correctamente si se ignoran criticidad, contexto, amenazas, impacto y dependencias. La pregunta correcta no es solo "que dice la norma", sino "que quiero proteger, frente a que amenaza, con que probabilidad, que impacto tendria y como demuestro que mi control funciona". Esta aproximacion basada en riesgo es comun a los tres marcos principales que se estudian en este curso.

El ciclo de gestion de riesgos sigue un patron establecido que puede resumirse en cinco pasos: (1) identificacion de activos y procesos criticos, (2) identificacion de amenazas y vulnerabilidades relevantes, (3) evaluacion de riesgo combinando probabilidad e impacto, (4) tratamiento del riesgo mediante controles (mitigar, transferir, aceptar o evitar), y (5) monitorizacion y revision periodica. Este ciclo no es lineal sino iterativo: un cambio en la infraestructura, un nuevo servicio, un incidente de seguridad o una actualizacion normativa puede obligar a reevaluar riesgos que se consideraban aceptados.

La evaluacion de riesgos puede seguir metodologias cualitativas (matrices de probabilidad-impacto con escalas como alto/medio/bajo), cuantitativas (calculo numerico de perdida anual esperada) o mixtas. Para organizaciones que empiezan, la aproximacion cualitativa suele ser mas practica porque no requiere datos historicos detallados. La metodologia MAGERIT, recomendada en el contexto del ENS, define un proceso estructurado de analisis y gestion de riesgos con catalogo de amenazas y salvaguardas. ISO 27005 ofrece un marco generico de gestion de riesgos de seguridad de la informacion alineado con ISO 27001. Independientemente de la metodologia, lo que importa es que el analisis sea repetible, documentado y vinculado a decisiones reales de control.

Un concepto clave es la diferencia entre riesgo inherente y riesgo residual. El riesgo inherente es el que existe antes de aplicar ningun control. El riesgo residual es el que queda despues de implementar las medidas de tratamiento. La direccion de la organizacion debe aceptar formalmente el riesgo residual, lo que significa que entiende que riesgos quedan abiertos y por que. Si el riesgo residual supera la tolerancia definida, se necesitan controles adicionales o decisiones estrategicas (cambiar la tecnologia, externalizar el servicio, eliminar el proceso).

El control es la medida concreta que reduce el riesgo. Puede ser tecnico (MFA, cifrado, firewall, EDR), organizativo (politica de acceso, procedimiento de altas y bajas, revision de permisos), fisico (control de acceso a CPD, CCTV) o contractual (clausulas con proveedores, SLAs de seguridad). Cada control necesita tres atributos para ser verificable: un owner (persona responsable), una periodicidad (con que frecuencia se ejecuta o revisa) y una evidencia (como se demuestra que el control existe y funciona). Un control sin estos tres atributos es un control declarativo que puede no existir en la practica.

La evidencia es lo que convierte cumplimiento declarativo en cumplimiento demostrable. Las evidencias pueden ser: configuraciones del sistema (capturas de pantalla, exports de politicas), logs de auditoria, tickets de revision de accesos, actas de comite de seguridad, informes de vulnerabilidades, resultados de pruebas de restauracion, registros de formacion y concienciacion, contratos con clausulas de seguridad firmados, o resultados de tests de penetracion. La clave es que la evidencia sea trazable (se puede vincular al control), temporal (tiene fecha) y verificable (un auditor puede comprobarla de forma independiente).

Los marcos normativos principales que se abordan en este curso comparten esta logica basada en riesgo aunque con enfoques distintos:

• El ENS (Esquema Nacional de Seguridad) aplica a la administracion publica espanola y a los proveedores que les prestan servicios. Categoriza los sistemas en basico, medio y alto segun el impacto potencial, y define medidas de seguridad proporcionales. Su enfoque es top-down desde la clasificacion del sistema.

• El GDPR (Reglamento General de Proteccion de Datos) aplica a cualquier organizacion que trate datos personales de residentes de la UE. Su enfoque se centra en los principios de tratamiento (licitud, limitacion de finalidad, minimizacion, exactitud, limitacion de conservacion, integridad y confidencialidad), los derechos de los interesados y la obligacion de accountability (responsabilidad proactiva). Los articulos 25 (proteccion de datos desde el diseno), 32 (seguridad del tratamiento), 33-34 (notificacion de brechas) y 35 (evaluacion de impacto) son especialmente relevantes para profesionales de seguridad.

• ISO 27001 es el estandar internacional de sistemas de gestion de seguridad de la informacion (SGSI). Define requisitos para establecer, implementar, mantener y mejorar continuamente un SGSI. El Anexo A proporciona un catalogo de controles de referencia (actualizado en la version 2022) que la organizacion selecciona segun su analisis de riesgos mediante la Declaracion de Aplicabilidad (SoA).

Los tres marcos comparten la necesidad de analisis de riesgos, controles proporcionados, evidencias y mejora continua. Un programa de compliance maduro puede integrar los tres marcos en un sistema unificado de gestion, evitando duplicidades de controles y evidencias.

Los roles clave en un programa de cumplimiento incluyen: el responsable de seguridad de la informacion (CISO o equivalente), el delegado de proteccion de datos (DPO, obligatorio en ciertos supuestos del GDPR), los propietarios de activos o procesos, los responsables de controles, el comite de seguridad y la alta direccion que acepta riesgos y provee recursos. Sin asignacion clara de roles, el cumplimiento se diluye y nadie responde cuando un control falla.

Contenido ampliado

Puntos clave

• El riesgo da contexto al cumplimiento: la misma norma se aplica de forma distinta segun el activo, la amenaza y el impacto.
• Politica sin evidencia sostenida no demuestra control real; es cumplimiento declarativo.
• Cada control necesita owner, periodicidad y evidencia verificable para ser auditable.
• ENS, GDPR e ISO 27001 comparten logica basada en riesgo aunque con enfoques y alcances distintos.
• El riesgo residual debe aceptarse formalmente por la direccion, no ignorarse.
• Un programa de compliance maduro integra marcos para evitar duplicidades.

Checklist operativa

• Identificar requisitos normativos aplicables por servicio, sistema o proceso.
• Relacionarlos con activos criticos, datos tratados y riesgos concretos.
• Definir controles con owner, periodicidad y evidencia para cada riesgo relevante.
• Determinar que evidencia probara la eficacia del control ante un auditor.
• Establecer un ciclo de revision de riesgos (al menos anual o ante cambios significativos).
• Documentar el riesgo residual y obtener aceptacion formal de la direccion.
• Asignar roles: responsable de seguridad, DPO si aplica, propietarios de activos, responsables de controles.

Errores frecuentes

• Tratar cumplimiento como proyecto puntual de auditoria en vez de capacidad continua.
• Crear controles sin responsable, sin periodicidad y sin mecanismo de evidencia.
• Confundir documento firmado con control efectivamente implantado y verificado.
• Aplicar la misma intensidad de control a todos los activos sin diferenciar por riesgo.
• No revisar riesgos cuando cambia la infraestructura, los servicios o el contexto de amenazas.
• Acumular politicas que nadie lee ni aplica, generando una falsa sensacion de cumplimiento.
• No obtener aceptacion formal de la direccion sobre el riesgo residual.

Practica sugerida

Construye una tabla de gestion de riesgos para una organizacion ficticia que opera un servicio web con datos personales. Incluye: (1) cinco activos criticos, (2) una amenaza principal para cada activo, (3) evaluacion de riesgo inherente (probabilidad e impacto), (4) un control para cada riesgo con owner, periodicidad y tipo de evidencia, (5) evaluacion de riesgo residual despues de aplicar el control. Identifica que marcos normativos aplican (ENS si es administracion publica, GDPR por datos personales, ISO 27001 si busca certificacion) y como se solapan los requisitos.

Preguntas de autoevaluacion

• ¿Que diferencia hay entre un control disenado y un control sostenido con evidencia?
• ¿Por que el riesgo cambia la forma de aplicar un mismo requisito normativo?
• ¿Que evidencias considerarias mas solidas que una simple politica aprobada?
• ¿Que tienen en comun ENS, GDPR e ISO 27001 en cuanto a enfoque de riesgo?
• ¿Por que la direccion debe aceptar formalmente el riesgo residual?

Cierre

El cumplimiento madura cuando deja de ser una coleccion de documentos y se convierte en un sistema observable de control, evidencia y mejora continua. La gestion del riesgo es el hilo conductor que conecta requisitos normativos con decisiones operativas reales.

Modulo 02. ENS: enfoque, medidas y aplicacion

Objetivo del modulo

Entender cómo el Esquema Nacional de Seguridad traduce la protección de servicios públicos o de su ecosistema a principios, requisitos y medidas concretas.

Resultados esperados

• Explicar categorías, dimensiones y niveles del ENS.
• Relacionar medidas con sistemas y servicios reales.
• Evitar aplicar el ENS como checklist sin contexto.

Desarrollo teorico

El Esquema Nacional de Seguridad (ENS), regulado en España por el Real Decreto 311/2022 que actualizó el marco anterior de 2010, establece los principios básicos, requisitos mínimos y un conjunto estructurado de medidas de seguridad para garantizar la protección adecuada de la información tratada y los servicios prestados por medios electrónicos en el ámbito del sector público y de las organizaciones que interactúan con él. Su lógica no es la de un catálogo genérico de controles que se aplican indiscriminadamente, sino la de un marco adaptativo donde la intensidad de las medidas depende del contexto, el impacto potencial y la categorización del sistema.

El punto de partida del ENS son las cinco dimensiones de seguridad: disponibilidad, autenticidad, integridad, confidencialidad y trazabilidad. Cada sistema o servicio debe evaluarse en función del impacto que tendría una pérdida o degradación en cada una de estas dimensiones. No todos los sistemas necesitan el mismo nivel de protección en todas las dimensiones. Un portal informativo público puede necesitar alta disponibilidad pero confidencialidad baja, mientras que un sistema de gestión de expedientes con datos sensibles necesitará confidencialidad alta y trazabilidad exhaustiva. Esta evaluación por dimensiones es la base sobre la que se construye todo el enfoque del ENS.

La categorización del sistema es el paso más determinante de todo el proceso. El ENS establece tres categorías: Básica, Media y Alta. La categoría se determina evaluando el nivel de impacto en cada una de las cinco dimensiones y tomando el más alto como referencia. El nivel de impacto puede ser bajo, medio o alto según las consecuencias que tendría un incidente de seguridad que afectara a esa dimensión: impacto en los derechos de los ciudadanos, en la capacidad de la organización para cumplir sus funciones, en los activos de la organización o en la conformidad legal. Una categorización correcta requiere entender el servicio en profundidad: qué hace, a quién afecta, qué datos trata, qué procesos soporta, qué dependencias tiene y qué consecuencias reales tendría una interrupción, una alteración o una fuga de información. El error clásico es categorizar de forma optimista para rebajar las exigencias de medidas, lo que deja al sistema desprotegido frente a riesgos que debería cubrir.

Los principios básicos del ENS incluyen la seguridad como proceso integral, la gestión del riesgo como fundamento, la prevención, la detección, la respuesta y la conservación, la existencia de líneas de defensa, la reevaluación periódica y la proporcionalidad. Estos principios no son solo declaraciones abstractas: condicionan cómo debe diseñarse y operarse la seguridad del sistema. El principio de proporcionalidad, por ejemplo, establece que las medidas deben ser adecuadas al riesgo real, evitando tanto la sobreprotección innecesaria como la desprotección negligente. El principio de reevaluación periódica exige que la seguridad no se trate como un estado estático que se alcanza una vez, sino como un proceso continuo que debe revisarse ante cambios en el sistema, en las amenazas o en el contexto normativo.

Los requisitos mínimos del ENS definen las obligaciones que toda organización sujeta al esquema debe cumplir: organización e implantación del proceso de seguridad, análisis y gestión de riesgos, gestión de personal, profesionalidad, autorización y control de accesos, protección de instalaciones, adquisición de productos y servicios, seguridad por defecto, integridad y actualización del sistema, protección de la información almacenada y en tránsito, prevención ante otros sistemas interconectados, registro de actividad, incidentes de seguridad, continuidad de la actividad y mejora continua. Cada requisito mínimo se concreta en una o varias medidas del Anexo II del ENS.

Las medidas de seguridad del ENS se organizan en tres marcos: marco organizativo, marco operacional y medidas de protección. El marco organizativo incluye la política de seguridad, la normativa interna y los procedimientos operativos. No se trata de tener documentos bonitos, sino de que la organización tenga definidas y comunicadas las reglas del juego en materia de seguridad. El marco operacional cubre aspectos como planificación, análisis de riesgos, gestión de la configuración, mantenimiento, gestión de cambios, protección de comunicaciones, monitorización y gestión de incidentes. Las medidas de protección abordan instalaciones, personal, equipos, comunicaciones, soportes de información, aplicaciones, servicios y protección de la información.

Cada medida del ENS especifica requisitos diferenciados según la categoría del sistema. Una medida puede aplicarse de forma básica en un sistema de categoría Básica y de forma reforzada en un sistema de categoría Alta. Por ejemplo, la medida de control de acceso exige autenticación en todos los niveles, pero la categoría Alta puede requerir autenticación multifactor y registro detallado de todos los intentos de acceso. Esta gradación es fundamental para aplicar el ENS con proporcionalidad: las medidas se intensifican donde el riesgo lo justifica.

La aplicación práctica del ENS requiere un enfoque secuencial. Primero se identifica el sistema y sus dependencias, incluyendo servicios de terceros y proveedores cloud que pueden estar dentro del alcance. Después se evalúa el impacto en cada dimensión y se determina la categoría. A continuación se realiza un análisis de riesgos que identifique las amenazas relevantes, las vulnerabilidades existentes y los riesgos residuales. Con el análisis de riesgos como base, se seleccionan y adaptan las medidas del Anexo II según la categoría del sistema. Finalmente, se implementan las medidas, se generan las evidencias de implantación y se establece un ciclo de revisión periódica.

Un aspecto que muchas organizaciones subestiman es la gestión de proveedores y dependencias externas en el contexto del ENS. Si un sistema categorizado como Alto depende de un servicio cloud de un tercero, ese proveedor debe ofrecer garantías de seguridad compatibles con la categoría del sistema. El ENS permite la certificación de conformidad por parte de proveedores, y las organizaciones deben verificar que sus proveedores críticos cumplen los requisitos aplicables. Ignorar las dependencias de terceros es una de las causas más frecuentes de incumplimiento real en organizaciones que, sobre el papel, tienen todas las medidas implementadas internamente.

La auditoría ENS verifica que las medidas declaradas se implementan realmente y que las evidencias lo demuestran. Las organizaciones con sistemas de categoría Media o Alta deben someterse a auditorías periódicas realizadas por entidades acreditadas. La auditoría evalúa tanto la documentación como la operación real: no basta con tener políticas escritas si los controles no se ejecutan en la práctica. Prepararse para una auditoría ENS implica mantener un repositorio de evidencias actualizado, poder demostrar la periodicidad de los controles y tener un plan de tratamiento para las desviaciones detectadas.

Contenido ampliado

Puntos clave

• El ENS se aplica sobre servicios y sistemas concretos, no en abstracto.
• La categoría condiciona la intensidad del control.
• El enfoque correcto empieza por análisis y contexto, no por checklist.

Checklist operativa

• Definir el sistema y sus dependencias.
• Evaluar impacto para categorizar correctamente.
• Mapear medidas según aplicabilidad y madurez.
• Preparar evidencias de implantación y revisión.

Errores frecuentes

• Categorizar de forma optimista para "rebajar" medidas.
• Copiar controles sin relacionarlos con el sistema real.
• No revisar si las dependencias de terceros también afectan al cumplimiento.

Practica sugerida

Categoriza un portal de tramitación electrónica ficticio y propone medidas ENS prioritarias según su impacto y criticidad.

Preguntas de autoevaluacion

• ¿Por qué la categoría del sistema es tan importante?
• ¿Qué pasaría si aplicas medidas sin haber entendido el servicio?
• ¿Qué tipos de evidencia pedirías en una revisión ENS?

Cierre

El ENS aporta valor cuando traduce la protección del servicio a medidas razonadas y demostrables, no cuando se usa como inventario mecánico de controles.