Cumplimiento

QuéDefinir contra qué se evalúa la organización: qué sistemas entran en el alcance y qué controles aplican, por escrito y de forma defendible. Este documento es la referencia contra la que se contrastan la auditoría y las obligaciones del proveedor.

CómoUn documento de alcance mantenido con el sistema de gestión, revisado a calendario y con un responsable que responda de él, de forma que cualquiera pueda contrastarlo contra el esquema que le aplique.

CómoUn documento corto que diga qué sistemas y datos entran y quién responde de ellos, partiendo de la plantilla del cliente o del esquema en lugar de redactarlo desde cero. Lo importante es poder acreditarlo cuando el cliente lo solicite.

• Clasificación de la información y los servicios según el impacto de un incidenteLa información y los servicios clasificados por el impacto de un incidente, con la escala del esquema que aplique y reevaluación periódica.
• Declaración de aplicabilidad firmada, con el estado de cada medida aplicable y la justificación de las descartadasLa Declaración de Aplicabilidad firmada (documento distinto del alcance: lista los controles y su porqué), con cada control aplicable y su estado de implantación, cada descarte justificado y cada medida compensatoria trazada a la que sustituye. RDL 12/2018

QuéPoder demostrar a un tercero lo que se ha hecho, en sus dos versiones: la conformidad de la organización, que se audita y se certifica, y la del producto, que se evalúa, se documenta y se marca antes de venderlo. Es el expediente que convierte el cumplimiento en algo oponible a un cliente, a un pliego o a un supervisor.

CómoUn repositorio de evidencias al día, una relación estable con quien evalúa desde fuera y el calendario de la acreditación gestionado como un compromiso más del negocio. El dueño lo fija cada norma: el sistema de gestión de la organización, o quien responde del producto.

CómoSin función de cumplimiento interna: el expediente lo mantiene quien lleva la seguridad, suele bastar responder los cuestionarios del cliente con las evidencias ordenadas, y el trabajo de acreditación se apoya en un consultor externo por campaña. Con un límite: el certificado del proveedor cloud cubre lo que hace el proveedor, no lo que se monta encima, y presentarlo como propio no supera la primera auditoría del cliente.

• Auditoría o evaluación de la conformidad por un tercero independiente, con la periodicidad de la normaAuditoría por tercero independiente con la periodicidad que fije la norma, planificada y con las evidencias listas antes de que llegue. RDL 12/2018
• Certificación o distintivo en un esquema reconocido, con validez temporal y renovaciónCertificado o distintivo en un esquema reconocido, con la validez vigilada y la renovación planificada. RDL 12/2018CSA
• Vía de evaluación de la conformidad elegida y documentada según la clase de riesgoLa vía de evaluación elegida y documentada según la clase de riesgo: autoevaluación donde se permite, organismo notificado donde no. REDCSAAI ActCRA
• Documentación técnica y declaración de conformidad conservadas y a disposición de la autoridadEl expediente técnico completo y la declaración firmada, conservados el plazo exigido y recuperables en días cuando la autoridad los pida, no reconstruidos a posteriori. REDCSAAI ActCRA
• Marcado o declaración pública de conformidad antes de comercializarEl marcado o la declaración emitidos como último paso del proceso de conformidad, con un control que impida que una versión salga al mercado sin él. REDCSAAI ActCRA
• Criterio y punto de control para decidir cuándo un cambio es una modificación sustancial que reabre la conformidadUn punto de control en la gestión de cambios que decida cuándo una modificación es sustancial y reabre la conformidad. REDCSAAI ActCRA

En el sector público español la seguridad del tratamiento no se diseña desde cero: se implanta aplicando a cada tratamiento de datos personales las medidas del Esquema Nacional de Seguridad que correspondan a su categoría, y la misma exigencia se traslada por contrato a quien preste el servicio, con el nivel de la Administración de origen.

• Aplicar a los tratamientos de datos personales las medidas que correspondan del Esquema Nacional de Seguridad RGPD
• Trasladar esa exigencia a concesionarios y contratistas, con las medidas de la Administración de origen RGPD

Tratar el certificado como algo que hay que mantener vivo y no como un documento archivado: alguien vigila la información de vulnerabilidad del producto certificado y sus dependencias, y también la garantía que el certificado declara. Cuando aparece una falta de conformidad, el reloj de treinta días para proponer medidas correctoras corre desde que lo dice el organismo de certificación, así que la capacidad de responder tiene que existir antes. Y cuando el certificado se suspende, hay que poder identificar y alcanzar a los compradores de los productos afectados, y publicar la información, en cuestión de días.

• Vigilancia continua de la información de vulnerabilidad del producto certificado y de sus dependencias conocidas CSA
• Vigilancia de la garantía declarada en el certificado y cooperación con el organismo de certificación y la autoridad nacional CSA
• Capacidad de proponer medidas correctoras en el plazo máximo de treinta días desde que se comunica la falta de conformidad CSA
• Lista de compradores alcanzable y aviso público preparado para el caso de suspensión del certificado CSA
• Registros de la certificación y muestra del producto conservados al menos cinco años tras la retirada CSA

QuéLlevar la ciberseguridad al órgano de gobierno: que la seguridad tenga dueño con autoridad, atención regular de la dirección y rastro documental de lo que se decide.

CómoUna estructura de gobierno dimensionada al tamaño de la organización (comité de seguridad, funciones delegadas) con presupuesto propio y un canal estable entre quien opera la seguridad y quien responde de ella.

CómoSin comité: las funciones recaen en la gerencia y se ejercen en la reunión que ya existe, no en un órgano nuevo. Lo que la norma atribuya a un órgano o a un cargo sigue siendo suyo aunque el equipo sean dos personas, y asignárselo al proveedor externo que administra los sistemas rompe la independencia que se le exige.

• Aprobación de las medidas de gestión de riesgos por el órgano de direcciónLas medidas pasan por el órgano de dirección y su aprobación queda en acta: la aprobación formal es requisito de validez del marco. RDL 12/2018NIS2
• Supervisión de su aplicación por la propia direcciónSeguimiento periódico en la agenda de la dirección, con un cuadro de mando que traduzca el riesgo a lenguaje de negocio y permita preguntar por lo que no avanza. NIS2
• Responsabilidad personal de los miembros por el incumplimientoLas actas permiten identificar quién decidió qué y con qué información, las funciones delegadas constan por escrito, y consta igualmente que la delegación no traslada la responsabilidad. NIS2
• Responsable de seguridad designado, con independencia y acceso a la direcciónUn responsable de seguridad nombrado formalmente, independiente de quien opera los sistemas, con acceso directo a la dirección y con recursos asignados; comunicado a la autoridad y actuando como punto de contacto con ella y con el CSIRT cuando la norma lo exige. RDL 12/2018
• Evidencia documental que permita demostrar el cumplimiento ante la autoridadCada medida con su evidencia archivada (decisión, criterio, fecha y responsable), lista para enseñarse sin reconstruirla a posteriori. RGPD
• Informe periódico del estado de la ciberseguridad a la autoridadPresentación con calendario propio del estado de los controles y del riesgo residual a la autoridad que supervisa: una entrega activa, no evidencia archivada a disposición de quien la pida.

QuéLa seguridad dentro del ciclo de vida del empleado: comprobaciones al contratar donde proceda, deberes claros durante la relación y salida ordenada.

CómoReglas pactadas con recursos humanos y escritas en los contratos, aplicadas igual al personal propio y al ajeno, con la entrada y la salida como momentos con procedimiento.

CómoSin departamento de recursos humanos: lo lleva la gestoría o quien firma los contratos, apoyado en un contrato tipo y una lista de comprobación en lugar de un procedimiento formal. Se aplica igual al personal ajeno, que a esta escala suele ser la mayoría.

• Seguridad de los recursos humanosComprobación previa proporcional al puesto y dentro de lo que la ley permite (identidad, titulación, experiencia y referencias; los antecedentes penales solo donde una norma lo autorice), confidencialidad y normas de uso firmadas al entrar, revisión de accesos al cambiar de puesto, deberes que sobreviven a la baja, y salida con accesos retirados, activos devueltos y cambiadas las contraseñas compartidas que esa persona conocía. RDL 12/2018NIS2RGPDCSA

Elegir el catálogo de controles contra el que se declara el cumplimiento y dejar escrito cuál es. La norma remite al anexo II del Esquema Nacional de Seguridad de 2010, derogado en 2022, así que en la práctica se trabaja con las 73 medidas del ENS vigente o con un estándar internacional reconocido, y se documenta la equivalencia aplicada para poder defenderla ante la autoridad.

• Catálogo de controles identificado y trazado a la referencia legal RDL 12/2018
• Equivalencia documentada con el catálogo del ENS vigente o con el estándar elegido RDL 12/2018

QuéEl cuerpo normativo de seguridad: qué se protege, quién decide y contra qué criterios se mide todo lo demás, escrito, comunicado a quien tiene que cumplirlo y vivo.

CómoUn cuerpo normativo por capas (política, normativas, procedimientos) gestionado como exige un sistema de gestión tipo ISO 27001 o ENS: versionado, con dueño, publicado donde la plantilla lo encuentre, y con revisión programada y tras los cambios relevantes.

CómoUn cuerpo normativo reducido a lo que la organización va a aplicar realmente: una política y las pocas normas que la sostienen, en lugar de la pirámide documental completa. Las plantillas del sector o del cliente son un punto de partida legítimo.

• Política de seguridad de los sistemas de información aprobada por la direcciónAprobada formalmente por la dirección, con fecha y versión, revisada a calendario y reaprobada tras los cambios relevantes; y entregada a quien tiene que cumplirla con constancia de la entrega, que es lo que la hace oponible. RDL 12/2018NIS2CRA

El documento único con las políticas de seguridad de todas las infraestructuras críticas del operador, certificado desde 2022: ya no basta con tenerlo escrito, hay que acreditar que sus medidas están implantadas. Cubre seguridad física y ciber en el mismo plan.

QuéGobernar el riesgo que entra por los proveedores: el riesgo del proveedor es riesgo propio, la cadena no termina en quien firma el contrato, y la relación completa, desde la selección hasta la terminación, se gestiona con la seguridad integrada.

CómoUn proceso con dueño, integrado en compras y en jurídico: la seguridad participa antes de firmar y durante la vida del contrato, con una intensidad proporcional a la criticidad del servicio prestado.

CómoProporcional y sin herramienta dedicada: un expediente por proveedor, con más profundidad cuanto mayor es su acceso a los datos o al servicio, y especial atención a los que acceden en remoto a los sistemas.

• Criterios de seguridad para seleccionar proveedoresCriterios de seguridad escritos dentro del proceso de compra: qué se exige según la criticidad y qué descarta a un candidato. RDL 12/2018NIS2RGPDCRA
• Cláusulas de seguridad en los contratos con proveedoresCláusulas tipo en los contratos: medidas exigidas, deber de notificar incidentes y condiciones de fin de servicio. NIS2RGPD
• Derecho de auditoría sobre el proveedorDerecho de auditoría pactado, ejercible directamente o mediante certificados e informes de tercero. NIS2RGPD
• Registro vivo de proveedores y de los servicios que prestanUn registro vivo con criticidad y dependencias, que responda en horas a qué proveedor presta qué servicio. NIS2
• Ponderación de la seguridad del proveedor en la decisión de contratar y durante la relaciónLo que se pondera está tasado: las vulnerabilidades propias de ese proveedor, la calidad de sus productos y sus prácticas de desarrollo seguro. Se valora antes de firmar y se vuelve a mirar durante la relación, no solo al renovar. NIS2
• Estrategias de salida documentadas y probadas para los servicios críticosEstrategia de salida documentada y probada para los servicios críticos: cómo migrar o reinternalizar sin que la dependencia del proveedor lo impida.
• Autorización previa de las subcontrataciones y traslado de las mismas obligaciones aguas abajoSubcontratar exige autorización previa y trasladar las mismas obligaciones aguas abajo, con la responsabilidad del proveedor inicial intacta. RGPD
• Comprobación documental de la conformidad de lo que se incorpora o se revende, antes de ponerlo en el mercadoUna puerta de entrada documental: marcado, documentación técnica e identificación comprobados antes de incorporar o revender. REDCRA
• Trazabilidad de quién suministró y a quién se suministró, conservada el plazo que fije la normaRegistro de quién suministró y a quién se suministró, conservado durante el plazo que fije la norma. REDCRA
• Diversificación de proveedores en los servicios críticosEstrategia de contratación que evite depender de un único proveedor en los servicios que sostienen funciones críticas, con el riesgo de concentración valorado antes de firmar.

Poder responder tres preguntas antes de firmar una compra o mover una función de red: si el suministrador está o puede quedar vetado, si el emplazamiento afectado está en la lista clasificada de ubicaciones sensibles, y en qué país va a estar alojado cada elemento crítico. No es gestión de proveedores al uso, porque la decisión no la toma la empresa: la toma el Consejo de Ministros calificando a un suministrador, el Consejo de Seguridad Nacional determinando ubicaciones que no se pueden consultar, y el Ministerio autorizando o denegando cada estación. Lo que sí es de la empresa es la trazabilidad que hace falta para ejecutar una sustitución cuando llegue: saber qué equipo, de qué suministrador, hay en qué elemento y bajo qué contrato, y tener calculado el plazo real de reemplazo frente al mínimo legal de un año.

• Inventario de equipo, programa y servicio auxiliar por elemento de red y por suministrador, con el grupo empresarial al que pertenece cada uno RDL 7/2022
• Consulta previa sobre si un emplazamiento da cobertura a una ubicación sensible, dado que la lista es materia clasificada y no se puede comprobar RDL 7/2022
• Procedimiento de solicitud de autorización de instalación, modificación o adaptación de estaciones, con tres meses de plazo y silencio negativo RDL 7/2022
• Registro del país de alojamiento de cada elemento crítico y de las condiciones que permiten mantenerlo fuera del territorio nacional RDL 7/2022
• Plan de sustitución con plazos y coste estimados, contrastado con el mínimo legal de un año y con los cinco y dos años de la disposición transitoria RDL 7/2022

QuéUn inventario completo de los activos y de sus dependencias: sin él, el parcheo, la vigilancia y la recuperación operan sobre un parque desconocido.

CómoUna fuente única mantenida como proceso (alta, cambio y baja con autorización), no como foto anual, y conectada a lo que la consume: el parcheo, la vigilancia y la recuperación.

CómoUna lista mantenida (una hoja, o el inventario del MDM si lo hay) de equipos, aplicaciones y servicios contratados. Si se vende software, la SBOM la genera la herramienta de construcción; a mano no se mantiene.

• Inventario y gestión de activos con dueño y criticidadUna CMDB o un inventario con descubrimiento automático que aflore el shadow IT, con dueño y criticidad por activo, y con las interconexiones y dependencias entre activos y con la función de negocio que sostienen: sin ese mapa no se puede determinar qué servicios arrastra el fallo de cada activo. NIS2
• Nomenclatura de materiales del software (SBOM) en formato legible por máquina, con las dependencias de máximo nivelLa lista de materiales del software (SBOM) del producto, regenerada en cada versión, en un formato legible por máquina de los que usa la industria (CycloneDX, SPDX) y cruzada contra los avisos de vulnerabilidad: su valor es responder en horas si el fallo de un componente ajeno afecta al producto. CRA

QuéConocer a qué está expuesto el negocio y decidir qué se acepta y qué se trata: el proceso de gestión de riesgos determina las prioridades del resto de iniciativas.

CómoUn proceso con dueño y calendario propio, apoyado en una metodología reconocida y al día (ISO/IEC 27005:2022, MAGERIT, EBIOS RM) y alimentado por el inventario de activos, con apetito de riesgo declarado; el resultado ordena el plan de seguridad del año.

CómoMetodología ligera y sin herramienta dedicada: una hoja de cálculo con los diez o quince riesgos relevantes, mantenida por quien lleva la seguridad, con la profundidad ajustada a lo que la entidad puede sostener. El resultado documentado se mantiene en todo caso.

• Análisis de riesgos con metodología, criterios y resultados documentadosEl análisis escrito de punta a punta (metodología, criterios, resultados y decisiones), de forma que un tercero pueda seguir el razonamiento. RDL 12/2018NIS2RGPDCERAI ActCRA
• Enfoque de todos los peligros: también físicos, no solo TIEl mapa de amenazas incluye lo físico y lo ambiental (robo, incendio, corte de suministro), no solo lo informático. RDL 12/2018NIS2CER
• Revisión de la evaluación de riesgos al menos anual y ante cambios o incidentes significativosRevisión al menos anual y tras cada cambio o incidente significativo, con rastro de qué cambió entre versiones.
• Evaluación de impacto previa al despliegue de tratamientos o sistemas de alto riesgo, cerrada con las medidas que la sostienenEn alto riesgo, la evaluación se hace antes de desplegar y se cierra con las medidas que la sostienen; se reabre cuando el riesgo cambia. RGPD

QuéTratar las vulnerabilidades como un proceso continuo con responsable y plazos, no como reacciones aisladas: las vulnerabilidades conocidas se gestionan en lugar de acumularse.

CómoUn proceso con dueño, apoyado en herramienta y en fuentes de aviso (boletines, el CERT de referencia), con métricas de lo que queda abierto y de cuánto tarda en cerrarse.

CómoSin herramienta de gestión de vulnerabilidades ni analista dedicado: lo que el proveedor cloud y el sistema operativo ya reportan, más un escaneo externo periódico contratado y los avisos del CERT de referencia suscritos, revisado por una persona con cadencia fija. El plazo que fije la norma se cumple en todo caso; lo que se ajusta es el instrumental.

• Identificación, priorización por riesgo y corrección de vulnerabilidades en plazoEscaneo autenticado y regular de infraestructura y aplicaciones, priorización por explotabilidad real y exposición (catálogo de explotación activa y probabilidad de explotación, KEV y EPSS, no solo la puntuación CVSS) y plazos de corrección atados a esa misma priorización, con excepciones firmadas y con fecha de caducidad. NIS2CSAAI ActCRA
• Vía de divulgación coordinada para quien encuentre una vulnerabilidadUn canal público de entrada para quien encuentre un fallo: security.txt (RFC 9116), política de divulgación publicada con plazos de respuesta y compromiso de no tomar represalias. NIS2CSACRA
• Divulgación hacia fuera de las vulnerabilidades relevantes ya corregidas, a quien tiene que actuarUn aviso de seguridad por vulnerabilidad corregida (componente afectado, impacto, severidad y qué hacer), publicado o dirigido a clientes y contrapartes; solo se puede retrasar hasta que quien lo usa pueda parchear. CSACRA
• Aviso al fabricante o mantenedor del componente de tercero al que se le detecta una vulnerabilidad, compartiendo la correcciónCuando el fallo está en un componente ajeno, se avisa a quien lo mantiene y se le comparte la corrección. CRA

QuéEvaluar si las medidas implantadas son eficaces, no solo si existen, y convertir los resultados de esa evaluación en mejoras aplicadas.

CómoUn cuadro de indicadores de seguridad revisado por el responsable y un registro de acciones correctoras con dueño y fecha, integrado en el ciclo de mejora del sistema de gestión.

CómoSin sistema de gestión formal: lo lleva quien responde de la seguridad, con una hoja fechada y firmada en lugar de un cuadro de mando; esa hoja constituye la evidencia que se presenta al cliente.

• Políticas y procedimientos para evaluar la eficacia de las medidasAutoevaluaciones o revisiones internas con calendario, contra criterios escritos y con los resultados documentados. RDL 12/2018NIS2RGPDAI ActCRA
• Plan de acciones correctoras derivado de las evaluaciones, con dueño, plazo y verificación de que se han aplicadoUn registro de acciones correctoras alimentado por cada evaluación o auditoría: dueño, plazo y una comprobación posterior de que la recomendación se aplicó, no solo de que se aceptó. RDL 12/2018

QuéIdentificar las debilidades propias antes de que lo haga un atacante: un programa de pruebas de seguridad con dueño y presupuesto sobre los sistemas que sustentan el negocio.

CómoLas pruebas tratadas como inversión recurrente, dimensionadas por la madurez de la organización: la planificación y la financiación estables son las que garantizan su ejecución.

CómoTodo contratado externamente, sin capacidad ofensiva propia (hay servicios asequibles por activo), y concentrado en los sistemas que sustentan el servicio. Lo exigido por la norma se prueba en todo caso; lo que cambia es quién lo ejecuta.

• Programa de pruebas con alcance, tipos y calendario definidosUn programa escrito con alcance, tipos de prueba y calendario: escaneo continuo, pentesting periódico, revisión de código fuente donde sea viable, pruebas de extremo a extremo y ejercicios de escenario donde el riesgo lo justifique.
• Ejecución por partes independientes, internas o externasLas pruebas las ejecuta quien no responde de lo que se prueba: un tercero contratado, o un equipo interno con recursos propios y separación declarada de quien diseñó y operó el sistema, para evitar el conflicto de interés.
• Prueba anual de los sistemas que sustentan funciones esenciales o importantesLos sistemas que sustentan funciones esenciales o importantes se prueban al menos una vez al año.
• Corrección priorizada de los hallazgos y verificación del cierreLos hallazgos se gestionan como riesgos: priorizados, con dueño, plazo y verificación del cierre.

Una prueba de intrusión guiada por inteligencia de amenazas contra sistemas de producción activos, no contra un entorno de pruebas, solo para las entidades que designe la autoridad competente. Se planifica con meses de antelación: alcance pactado con el supervisor, probadores acreditados y asegurados, y los proveedores de TIC dentro del ejercicio.

• Ejercicio al menos cada tres años sobre sistemas de producción activos DORA
• Alcance validado previamente por la autoridad competente DORA
• Probadores acreditados y con seguro de responsabilidad civil profesional DORA
• Probadores externos en cada tercera prueba si se usan internos, y siempre externos en entidades de crédito significativas DORA
• Participación contractual de los proveedores de TIC en el ejercicio DORA

La cartera no se despliega suelta: va dentro de un sistema de identificación electrónica de nivel de seguridad alto, con la acreditación y verificación de identidad y la autenticación que ese nivel impone, y las decisiones de arquitectura se toman con la seguridad delante en vez de añadirla al final.

• Provisión dentro de un sistema de identificación electrónica de nivel de seguridad alto eIDAS
• Seguridad desde el diseño en la arquitectura de la cartera eIDAS

El servicio de estado del certificado se dimensiona como infraestructura crítica del prestador: la revocación se registra y se publica dentro de las 24 horas siguientes a recibir la solicitud, y la consulta de validez responde en cualquier momento, de forma automatizada y gratuita, también para certificados ya expirados. Es un cuarto reloj de 24 horas y no tiene nada que ver con los incidentes.

• Registro y publicación del estado de revocación en 24 horas desde la solicitud eIDAS
• Consulta de validez o revocación por certificado disponible en todo momento, también tras expirar eIDAS
• Respuesta automatizada, fiable, gratuita y eficiente eIDAS

QuéUn sistema de gestión de identidades y accesos: cada identidad, humana o de máquina, es conocida, se autentica por un punto controlado y pierde el acceso cuando corresponde.

CómoUn directorio o IdP centralizado con SSO como fuente única de identidad, con altas, cambios de puesto y bajas ligados al proceso de recursos humanos. Las identidades de máquina (cuentas de servicio, tokens, claves de API) con dueño, caducidad y custodia en un gestor de secretos, porque habitualmente quedan fuera de los procesos de baja.

CómoEl directorio del proveedor de ofimática (Google Workspace, Microsoft 365) como fuente única: permisos por grupos y bajas el mismo día desde un solo sitio. La MFA va incluida en la suscripción y se activa para todos, y la cuenta de administrador global va separada de la de uso diario, con llave física o aplicación, no con SMS.

• Políticas de control de accesoPolítica de control de acceso con permisos por papel, concesión por circuito de aprobación y recertificación periódica de quién tiene qué. NIS2RGPD
• Autenticación multifactor o continuaAutenticación multifactor obligatoria en correo, acceso remoto y cuentas de administración, con factores resistentes al phishing (FIDO2, llave física o certificado) en las de administración y SMS solo donde no haya otra cosa. La alternativa continua es el acceso condicional que reevalúa la sesión por dispositivo, ubicación y riesgo. NIS2
• Mínimo privilegio y segregación de funcionesPermisos mínimos y funciones segregadas; las cuentas privilegiadas separadas, contadas y bajo PAM con sesiones registradas donde el riesgo lo pida, y el privilegio concedido para una tarea y un plazo concretos antes que de forma permanente.

QuéProtección del espacio físico donde operan los sistemas, un plano que las medidas lógicas no cubren.

CómoMedidas dimensionadas por el análisis de riesgos del emplazamiento (oficina, sala técnica o CPD), y la parte pesada heredada por contrato cuando la infraestructura es del proveedor.

CómoCasi todo heredado: el centro de proceso de datos es del proveedor cloud y su seguridad física se acredita con la certificación del proveedor, que se solicita y se conserva. Lo propio se reduce a la oficina y a los equipos que salen de ella.

• Protección física de centros, instalaciones y equipos afectos al servicioPerímetro, cerraduras, alarma y vigilancia proporcionales a lo que las instalaciones albergan.
• Control y registro del acceso físico a las instalaciones, con identificación de personasAcceso físico con identificación personal y registro: credencial nominativa, revisión periódica de quién la tiene y procedimiento de visitas con acompañamiento. La biometría no es un vehículo equivalente a la tarjeta: es un tratamiento de categoría especial y exige justificar antes por qué no basta con una credencial.
• Acondicionamiento frente a riesgos del entorno: energía, incendio e inundaciónSalas técnicas con SAI y grupo electrógeno probados con carga, climatización redundante, detección temprana de incendio y extinción por agente limpio, y el cableado protegido.
• Registro de entrada y salida de equipamientoLa entrada y la salida de equipamiento registradas, con autorización para sacar soportes.
• Medidas de seguridad física operativas también en situaciones de crisisLas medidas físicas siguen operativas en crisis, también en los estados de alarma, excepción y sitio.

QuéUn programa de concienciación y formación con contenido, calendario y evaluación de resultados, que incorpore a la plantilla a la defensa en lugar de dejarla como el vector de entrada más accesible.

CómoUna plataforma o servicio de formación gestionado como programa, con contenido mantenido, calendario anual y medición del resultado, no una compra puntual de contenidos.

CómoFormación en línea contratada (hay opciones por empleado y mes) en lugar de material y plataforma propios, apoyada en el calendario que trae el proveedor. El coste por persona la hace viable sin equipo interno.

• Formación en ciberseguridad para los miembros del órgano de direcciónSesiones específicas para el órgano de dirección, a su nivel y con registro de asistencia: consejeros formados, no solo informados. NIS2
• Formación regular y equivalente para la plantillaItinerarios por puesto con calendario y evaluación, que alcanzan también al personal ajeno que opera sistemas propios, y con la primera formación antes de entregar los accesos, no en el siguiente ciclo. RDL 12/2018NIS2
• Prácticas básicas de ciberhigienePrácticas básicas sostenidas en la operación diaria (contraseñas, bloqueo, correo, soportes) con recordatorios y comprobaciones periódicas, no únicamente un documento firmado en el alta. NIS2

Aislar el almacén de la cartera del resto de los sistemas del proveedor, instrumentar solo lo imprescindible para operarla y no cruzar esos datos con otros servicios. Y diseñar el protocolo para que no se pueda rastrear, vincular ni correlacionar las transacciones del usuario, ni desde el proveedor ni desde las partes usuarias, salvo que él lo autorice expresamente.

• Separación lógica de los datos de la cartera respecto de cualesquiera otros del proveedor eIDAS
• Ninguna recogida de información de uso innecesaria ni combinación con otros servicios eIDAS
• Marco técnico que impida rastrear, vincular o correlacionar transacciones sin autorización explícita eIDAS

Recae en la Administración, no en el operador: guardar la confidencialidad de los datos del Catálogo Nacional y de los planes, con medidas de seguridad acordes en los sistemas que los manejan.

Diseñar la retención dando por hecho que el servicio puede morir: los registros de lo expedido y lo recibido siguen accesibles y sirviendo de prueba después de cerrar la actividad, y el plan de cese, que dice quién custodia la información y cómo se avisa a los usuarios, se mantiene actualizado y lo verifica el organismo de supervisión.

• Registro accesible de los datos expedidos y recibidos, con retención definida eIDAS
• Información que sobrevive al cese de la actividad y sirve de prueba eIDAS
• Plan de cese actualizado y verificable por el organismo de supervisión eIDAS

QuéUn esquema de copias de seguridad orientado a la recuperación: qué se copia, con qué frecuencia y en cuánto tiempo se restaura, verificado mediante pruebas de restauración periódicas.

CómoUn esquema con dueño, soportes cifrados y protección pensada para que un atacante no llegue también a la copia: inmutabilidad, credenciales de copia fuera del directorio corporativo y retención que cubra más tiempo del que un intruso puede llevar dentro sin que se note. Y pruebas de restauración programadas que midan el tiempo real, incluida la reconstrucción completa de un sistema y no solo la vuelta de un fichero.

CómoLa papelera, el versionado y la retención del SaaS no son una copia: no sobreviven a un administrador comprometido ni a una licencia que caduca. El correo y los ficheros de Microsoft 365 o Google Workspace necesitan copia de un tercero (hay servicios por buzón y mes), y lo irrecuperable (repositorio, contabilidad, ficheros clave) va además fuera del proveedor, con al menos una restauración probada.

• Copias con objetivos de tiempo y de punto de recuperación definidosFrecuencia y retención derivadas de objetivos explícitos de recuperación (RTO y RPO), no del espacio disponible. NIS2RGPD
• Ubicaciones separadas del dato originalAl menos una copia en ubicación separada del original (otra región, otro proveedor o fuera de línea), para que un mismo incidente no se lleve las dos. NIS2
• Pruebas de restauración periódicas que verifiquen la copiaRestauraciones programadas que comprueben la integridad y la exactitud de la copia y midan el tiempo real de recuperación, incluida la reconstrucción completa de un sistema y no solo la vuelta de un fichero. NIS2

QuéProtección del dato en reposo y en tránsito mediante cifrado, gobernada por decisiones documentadas sobre qué se cifra, con qué algoritmos y cómo se custodian las claves.

CómoUna norma técnica que fije qué se cifra, dónde y con qué algoritmos aprobados, aplicada con lo que las plataformas ya traen, y escrita para poder cambiar de algoritmo sin rehacer el sistema: el inventario de usos criptográficos es la base de la transición poscuántica, y el dato de vida larga cifrado hoy está expuesto a su captura y descifrado futuro.

CómoLo que ya dan las plataformas, bien configurado y en todos los dispositivos (incluido el móvil que lleva el correo): se hereda del proveedor lo que él gestiona y se decide solo lo que él no cubre.

• Políticas y procedimientos de uso de la criptografía y el cifradoPolítica de uso del cifrado aplicada: TLS al día en las comunicaciones, cifrado de discos y bases de datos, y algoritmos aprobados por lista. NIS2RGPD
• Comunicaciones de voz, vídeo y texto segurasLos canales de voz, vídeo y mensajería del trabajo, cifrados y aprobados; lo sensible no viaja por canales personales. NIS2
• Sistemas seguros de comunicación de emergencia dentro de la entidadUn canal seguro alternativo para operar en crisis, utilizable aunque el correo o la red corporativa estén comprometidos: instalado y probado antes, con la lista de contactos y las credenciales accesibles fuera de línea, y sin depender del directorio corporativo para entrar. NIS2
• Gestión y custodia del ciclo de vida de las claves criptográficasCiclo de vida completo de las claves (generación, custodia, rotación, revocación, copia y destrucción) en un KMS o un HSM, con la clave separada del dato que cifra, doble control sobre las raíces y acceso contado. La pérdida de la clave supone la pérdida del dato: su copia se verifica periódicamente, igual que una restauración.

Un programa de defensa por familia de amenaza propia de la IA: envenenamiento del conjunto de entrenamiento, envenenamiento de modelos preentrenados, ejemplos adversarios o evasión, ataques a la confidencialidad y defectos del modelo. En cada una hay que cerrar el ciclo completo que pide el texto (prevenir, detectar, combatir, resolver y controlar) y dejar evidencia de cada fase.

• Integridad y procedencia verificadas del conjunto de entrenamiento, con control de cambios sobre el corpus AI Act
• Validación y saneamiento de la entrada, detección de entradas anómalas y pruebas de robustez adversaria AI Act
• Protección de la confidencialidad del modelo y de sus datos: control de acceso, cifrado y límites de consulta frente a la extracción y la inferencia de pertenencia AI Act
• Los defectos del modelo tratados como clase propia de vulnerabilidad, con vía de detección, resolución y seguimiento AI Act
• Los mismos controles extendidos a la infraestructura de TIC subyacente, no solo al modelo AI Act

QuéControles que impiden que el dato se falsifique, se sustraiga, se altere o se elimine sin autorización, y que permiten demostrarlo después: su objetivo es poder acreditar que el dato no ha sido alterado.

CómoApoyado en lo que las plataformas ya traen antes que en desarrollo propio, con el esfuerzo concentrado donde el dato tiene valor probatorio y no en todo por igual.

CómoTodo heredado del propio SaaS: se activa y se comprueba lo que el proveedor ya ofrece en lugar de construirlo. La trazabilidad la da la plataforma si se configura; lo que no se puede delegar es decidir qué datos la necesitan.

• Mecanismos que permitan detectar y demostrar la alteración del datoFirmas, sellos de tiempo o funciones resumen que permitan detectar y demostrar la alteración del dato.
• Medidas contra la falsificación, el robo y la apropiación indebida de datosAcceso restringido, trazas inalterables de quién tocó qué y alertas ante patrones anómalos de uso del dato.
• Controles contra la eliminación o el bloqueo del dato sin derechoEl borrado y el bloqueo bajo permiso y con rastro, y copias que permitan reconstruir el estado anterior.

Proteger los datos clasificados de las propias infraestructuras con los medios y sistemas que fije el reglamento. Es régimen de información clasificada, no seguridad TI general.

QuéProteger el modelo de IA como activo propio, distinto del sistema que lo sirve: los pesos, los conjuntos de datos de entrenamiento y la infraestructura donde el modelo vive, con un dueño identificado y controles específicos frente a los ataques que solo existen en IA.

CómoLa responsabilidad asignada al equipo que desarrolla u opera el modelo, con apoyo del de seguridad: control de acceso a pesos y datos de entrenamiento, y la evaluación adversarial ejecutada por un equipo propio o contratado con experiencia específica en ataques a modelos.

• Evaluación adversarial del modelo, documentada, con protocolos del estado de la técnicaEjercicios de simulación de adversarios contra el modelo (extracción, evasión, envenenamiento, inyección de instrucciones), conforme a protocolos y herramientas del estado de la técnica, con los resultados documentados y las mitigaciones registradas. AI Act
• Protección de los pesos, los datos de entrenamiento y la infraestructura física del modeloControl de acceso y cifrado sobre los pesos y los conjuntos de datos de entrenamiento, registro de los accesos, y endurecimiento de la infraestructura de entrenamiento y servicio del modelo, incluida su dimensión física. AI Act

QuéLa seguridad como requisito de compra y de construcción: exigencias al adquirir, prácticas de desarrollo seguro al construir y mantenimiento con la seguridad dentro durante todo el ciclo de vida.

CómoLa seguridad integrada en el flujo de construir y de comprar, con un criterio de aceptación explícito y un responsable de sostenerlo: su incumplimiento impide el paso a producción o la firma del contrato.

CómoSin equipo de seguridad de producto: se usa lo que la plataforma de desarrollo ya incluye sin coste adicional, y la parte de compra se resuelve en el propio contrato trasladando al proveedor las garantías que el cliente exige aguas arriba.

• Seguridad en la adquisición, el desarrollo y el mantenimiento de sistemasRequisitos de seguridad desde el diseño, análisis estático, de dependencias y de infraestructura como código en la integración continua (SAST, SCA, IaC), rastreo de secretos en el repositorio y en su histórico, revisión de código y pruebas antes de producción, entornos separados sin datos reales en pruebas, y requisitos de seguridad exigidos a lo que se compra. RDL 12/2018NIS2RGPDAI ActCRA
• Verificación de origen e integridad de los componentes y modelos de terceros antes de integrarlosOrigen e integridad verificados antes de integrar un componente o modelo ajeno, mediante firma del artefacto o atestación de su construcción; una suma de verificación publicada junto al artefacto no acredita el origen. En un modelo preentrenado, además, la procedencia de los pesos y su licencia. Todo lo incorporado queda registrado. AI Act
• Configuración por defecto restrictiva en lo que se recoge, se trata, se conserva y se hace accesibleLos valores por defecto de lo que se construye son los más restrictivos: se recoge, se conserva y se expone lo mínimo, y abrir más es una decisión consciente del usuario. RGPD

Sostener una capacidad técnica permanente, no atender un trámite jurídico: una o más interfaces preparadas en todo momento hacia los centros de recepción, con el formato que fije el Ministerio, y la capacidad de deshacer tu propia compresión, cifrado o codificación cuando sea reversible. La monta y la paga el operador.

• Interfaces de entrega preparadas en todo momento hacia los centros de recepción de interceptaciones LGTel
• Formato de entrega conforme al que fije el Ministerio LGTel
• Capacidad de entregar lo interceptado desprovisto del cifrado o la codificación propios cuando sean reversibles LGTel
• Coste de la capacidad a cargo del operador LGTel

QuéLa seguridad dentro del producto que se comercializa, no solo alrededor de los sistemas que se operan: se decide en el diseño y se comprueba antes de la comercialización, cuando el coste de cambio es menor.

CómoRequisitos de seguridad en el diseño, modelado de amenazas por versión y un banco de verificación que repita las comprobaciones en cada versión que sale.

CómoApoyarse en plataformas y componentes ya evaluados en lugar de construir desde cero, y heredar del ecosistema la infraestructura que no compensa montar. El esfuerzo propio se concentra donde el producto hace algo que nadie más hace por él.

• Comercializar sin vulnerabilidades aprovechables conocidasUna puerta en la cadena de construcción que cruza el SBOM de la versión contra las bases de vulnerabilidades y bloquea la publicación: el inventario limpio es condición de salida, y lo que se descarte va justificado por escrito en la documentación técnica. CSACRA
• Configuración segura de fábrica, con posibilidad de restablecer el estado originalSin credenciales por defecto compartidas entre unidades ni interfaces de depuración abiertas: contraseña única por unidad o alta forzada en el primer arranque, y un restablecimiento de fábrica que elimine datos y credenciales de forma efectiva. REDCSACRA
• Control de acceso implantado en el producto, con aviso de los intentos no autorizadosAutenticación exigida por defecto, papeles diferenciados dentro del producto y los intentos fallidos registrados y notificados a quien lo administra, no solo anotados en un registro local sin supervisión. REDCSACRA
• Confidencialidad e integridad de datos, comandos, programas y configuración, con cifrado de última tecnología y aviso de corrupciónCifrado en reposo y en tránsito con algoritmos vigentes, arranque verificado y firmware firmado para que el programa que corre sea el que salió de fábrica, y comprobación de integridad de la configuración con aviso cuando se corrompe. REDCSACRA
• Diseño que limite las interfaces externas y mitigue el aprovechamiento de vulnerabilidadesPuertos, servicios e interfaces cerrados salvo los que el producto necesita para su función, y las mitigaciones de explotación activadas en la compilación (ASLR, DEP, protección de pila, lenguajes con memoria segura donde quepa). CRA
• Disponibilidad de las funciones esenciales ante incidentes y denegación de servicioLas funciones esenciales se degradan de forma controlada sin interrumpirse: límites de tasa, vigilancia interna que reinicia los componentes bloqueados y retorno a un estado seguro tras el incidente. El producto tampoco debe degradar la disponibilidad de los dispositivos y redes conectados ni servir de amplificador de un ataque a terceros. REDCSACRA
• Registro y seguimiento de la actividad interna pertinente, con exclusión voluntaria del usuarioRegistro con marca de tiempo de accesos, cambios de configuración y uso de funciones sensibles, exportable para que el cliente lo lleve a su propia vigilancia, y con la exclusión al alcance del usuario. CSACRA

QuéComprometer por cuánto tiempo se mantiene lo vendido y montar la infraestructura para sostenerlo. Es una decisión de producto y de precio, no una tarea de cumplimiento.

CómoEl soporte tratado como un servicio con dueño, calendario y coste repercutido en el precio del producto, con telemetría de adopción que diga qué parque sigue expuesto.

CómoCon canal simple y sin equipo de mantenimiento dedicado: la entrega apoyada en la infraestructura del ecosistema (tiendas, actualización de la plataforma) en lugar de un canal propio. Lo que se compromete no se rebaja por tamaño; cambia la infraestructura que lo sostiene.

• Período de soporte definido y publicado con mes y año en el momento de la compraLa fecha de fin de soporte decidida en el plan de producto y publicada donde el comprador la ve antes de comprar: ficha, embalaje e información que acompaña al producto, no solo en la documentación técnica. CSACRA
• Actualizaciones publicadas disponibles durante el plazo que fije la normaUn archivo de descargas versionado y firmado que sigue operativo cuando el producto ya no se comercializa: cada actualización publicada se conserva y sigue descargable durante el plazo, no solo la última. CRA
• Actualizaciones de seguridad automáticas por defecto, con exclusión voluntaria y opción de posponerlasCanal de actualización activado de fábrica y con reversión (doble partición o equivalente) para que una actualización fallida no deje el aparato inservible; la exclusión y la posposición, explícitas y al alcance del usuario. CRA
• Actualizaciones de seguridad entregadas separadas de las de funcionalidadRamas de mantenimiento separadas de la rama de desarrollo, para poder publicar el parche sobre la versión que el cliente tiene sin obligarle a asumir cambios funcionales ni a migrar. CRA
• Mecanismos de distribución segura de las actualizacionesFirma de código con la clave en HSM y verificación de esa firma en el propio dispositivo antes de instalar, con protección contra la vuelta a una versión anterior vulnerable: la verificación en destino es la que hace efectiva la firma del canal. CRA
• Actualizaciones de seguridad difundidas sin demora y de forma gratuitaEl parche de seguridad se descarga sin suscripción de mantenimiento vigente, sin registro previo y sin distinción por contrato: cobrar por él solo cabe en producto a medida con usuario profesional. CRA

Diseñar dos flujos con un nivel de servicio distinto del resto de la red: la llamada a los servicios de emergencia y la transmisión de alertas públicas no admiten interrupción ni en fallo catastrófico ni en fuerza mayor. Alimentación, rutas y capacidad reservadas para ellos, y ensayo del escenario que tumba todo lo demás.

• Acceso sin interrupciones a los servicios de emergencia LGTel
• Transmisión ininterrumpida de las alertas públicas LGTel
• Nivel de servicio separado del de voz e internet, donde el listón solo es «la mayor disponibilidad posible» LGTel

Un plan por cada infraestructura crítica, con las medidas permanentes y las temporales, también certificado. Es la bajada del PSO al terreno de cada activo, físico y ciber juntos.

• Un plan por cada infraestructura crítica designada Ley PIC
• Medidas permanentes y medidas temporales de protección Ley PIC
• Certificación de la implantación Ley PIC

QuéProteger el perímetro y ordenar el interior de la red: sin segmentación, un único compromiso puede extenderse al conjunto de los sistemas.

CómoUna arquitectura de red documentada y mantenida, con las decisiones de filtrado y de acceso escritas y revisadas, de forma que el tráfico permitido responda a decisiones y no a configuraciones heredadas.

CómoSobre el equipamiento existente (el router del proveedor, lo que la plataforma cloud incluye) en lugar de dispositivos dedicados, con opciones sin coste para el acceso remoto. La decisión no se hereda: la arquitectura, aunque sea mínima, se documenta y se revisa igualmente.

• Protección del perímetro frente a redes públicas y no confiablesCortafuegos y filtrado frente a redes públicas y no confiables, con el acceso remoto por VPN o ZTNA con MFA. El propio equipo de borde es el punto de entrada más explotado de los últimos años: prioridad máxima de parcheo y su panel de administración nunca expuesto a internet. Filtrado también de salida y de DNS, que es donde se detecta el mando y control.
• Segmentación y separación de flujos de información en la redRed segmentada por zonas según criticidad, con el tráfico entre ellas denegado por defecto, abierto por excepción documentada y vigilado; la administración de la infraestructura en una red aparte, que es lo que corta el salto hacia hipervisores, copias y directorio.
• Análisis y control de cada interconexión con sistemas de tercerosCada interconexión con terceros con su expediente: análisis de riesgo, control en el punto de unión y revisión periódica.

Diseñar el sistema para que aguante errores, fallos e incoherencias propios y del entorno, incluidos los que nacen de su interacción con personas u otros sistemas. La vía que nombra el texto es la redundancia técnica: copias y planes de prevención contra fallos que detengan el sistema de forma segura ante una anomalía o cuando opere fuera de los límites predeterminados.

• Medidas técnicas y organizativas de resiliencia frente a errores, fallos e incoherencias AI Act
• Redundancia técnica y plan de prevención contra fallos, con parada segura fuera de los límites predeterminados AI Act
• En sistemas que siguen aprendiendo en producción, control y subsanación de los bucles de retroalimentación AI Act

QuéCapacidad de observar de forma continua lo que ocurre en sistemas, redes y servicios, sostenida como un servicio con responsable y no como una herramienta desatendida.

CómoLa vigilancia contratada o desplegada según la madurez de la organización (propia, gestionada o híbrida), con la cobertura decidida desde el riesgo y documentada (qué entra, qué queda fuera y por qué), de forma que los puntos ciegos sean decisiones registradas y no descubrimientos del análisis posterior de un incidente.

CómoLa vigilancia se contrata en lugar de construirse: un servicio de detección gestionado (MDR) o las alertas nativas del proveedor cloud y de la ofimática, comprobando la retención del plan contratado (la de serie es de semanas y las solicitudes de evidencia llegan meses después), con la responsabilidad fuera de horario definida por escrito y el permiso de aislar un equipo pactado de antemano. Un centro de operaciones propio no es sostenible a esta escala; la obligación de detectar se mantiene.

• Detección y análisis de anomalías e indicios de incidenteSIEM o servicio gestionado con casos de uso mantenidos, sobre tres fuentes que hoy no son opcionales: puesto y servidor (EDR), identidad (inicios de sesión, cambios de privilegio, concesiones a aplicaciones) y el plano de control del cloud y del SaaS. El ataque que no pasa por un equipo gestionado (robo de sesión, consentimiento abusivo, regla de reenvío) solo se ve en las dos últimas. RDL 12/2018NIS2RGPD
• Registro de la actividad con retención suficiente, protegido frente a alteración y con los relojes sincronizadosQué eventos se registran, decidido desde el riesgo (identidad, administración, acceso al dato, red y puesto), con retención definida y cumplida, los registros fuera del alcance de quien administra el sistema que los genera y una fuente de tiempo común: condiciones necesarias para reconstruir los hechos y acreditarlos. RDL 12/2018NIS2

QuéLa capacidad de gestionar un incidente de seguridad de principio a fin, desde la detección del primer indicio hasta la recuperación de la operación normal.

CómoUn equipo designado (propio, CSIRT contratado o retainer de respuesta), guardias y escalado definidos, criterio escrito sobre qué se preserva antes de tocar nada, un canal de coordinación que siga operativo si caen los sistemas propios, y simulacros periódicos que prueben la capacidad antes de necesitarla.

CómoSin equipo de guardia propio: un servicio de respuesta contratado o el CERT de referencia como capacidad externa, y dentro solo la decisión de cuándo activarlo. Lo que la norma obligue a registrar no tiene versión reducida, y los contactos de emergencia se conservan en papel, fuera del sistema que puede estar cifrado.

• Proceso de gestión de incidentes de extremo a extremo, con papeles asignadosPlaybooks por tipo de incidente del primer aviso al cierre, con las fases de contener, erradicar y restablecer explícitas, y con quién declara el incidente y quién puede ordenar aislar o apagar, también fuera de horario. RDL 12/2018NIS2RGPD
• Criterios de clasificación de incidentesCriterios de severidad y de tipo, escritos y calibrados contra los umbrales de notificación de las normas que aplican, y aplicables en menos de una hora por quien esté de guardia: en varias normas el reloj no arranca al detectar, sino al clasificar. RDL 12/2018NIS2RGPDCRA
• Canal para que empleados, proveedores y clientes reporten sospechasUna vía publicada donde quien avisa espera encontrarla, sin represalias, con acuse de recibo y traza de cada aviso, y con supervisión también fuera de horario y en fin de semana. RDL 12/2018NIS2RGPDCRA
• Revisión posterior al incidenteRevisión tras cada incidente que supere el umbral de severidad ya definido, con causa raíz y acciones que vuelven a los playbooks y al análisis de riesgos con dueño y fecha. RDL 12/2018NIS2RGPD
• Registro interno de todos los incidentes, se notifiquen o no, con hechos, efectos y medidas adoptadasUn registro único y fuera del correo, con las horas de detección, conocimiento, clasificación y notificación de cada caso, y con el motivo escrito cuando se decide no notificar: las marcas de tiempo constituyen la evidencia del cumplimiento del plazo. RGPD
• Pruebas periódicas de los procedimientos de respuestaEjercicio del procedimiento de gestión de incidentes contra un escenario, con resultado documentado y correcciones incorporadas al procedimiento.

Capacidades, directrices internas, planes de preparación y personal destinados a intervenir en la detección y la mitigación de una crisis que atraviesa fronteras, bajo la coordinación de la autoridad competente del Estado en que se notificó primero el ciberataque. Es trabajo dirigido hacia fuera de la organización, distinto del plan de crisis interno: cooperación entre los puntos de contacto únicos de las entidades afectadas mientras dura el ataque, e investigación conjunta con la autoridad de las causas raíz de una crisis simultánea de electricidad para determinar en qué medida procede de un ciberataque.

• Capacidades, directrices internas y planes de preparación para intervenir en una crisis transfronteriza NCCS
• Personal identificado y disponible para esa intervención NCCS
• Cooperación entre los puntos de contacto únicos de las entidades afectadas durante el ciberataque NCCS
• Investigación conjunta con la autoridad competente de las causas raíz de una crisis simultánea de electricidad NCCS

QuéSaber a quién, qué y en cuánto tiempo hay que notificar un incidente, y poder hacerlo bajo presión y con los relojes en contra.

CómoUn procedimiento con responsables designados y suplentes, el asesor jurídico y comunicación dentro del circuito, y ensayos que comprueben si el procedimiento funciona bajo presión. Cada reloj arranca en un hecho distinto (conocer el incidente, clasificarlo o que ocurra), así que alguien declara ese momento y queda anotado; y un mismo incidente suele exigir varias notificaciones simultáneas, que deben ser coherentes entre sí.

CómoSin equipo de guardia ni jurídico interno: el procedimiento lo mantiene quien lleva la seguridad y el apoyo legal se contrata por horas. Y tener presente que suele haber más de un destinatario obligado: la AEPD si hay datos personales, INCIBE-CERT como CSIRT de referencia del sector privado, y el cliente, cuyo plazo contractual suele ser más corto que el de la norma. El certificado de la sede electrónica, en manos de alguien que sepa usarlo antes del incidente.

• Notificación de incidentes a la autoridad o al CSIRT en los plazos de la normaEl canal oficial de cada autoridad o CSIRT dado de alta y probado con antelación, con sus credenciales y certificados en manos de más de una persona, y la cascada completa en el calendario: casi ninguna norma se cierra con un solo envío, y los informes intermedios y finales vencen semanas después del incidente. RDL 12/2018NIS2RGPDAI ActCRA
• Aviso a los destinatarios o afectados cuando el incidente pueda tocarlesPlantilla que ya diga lo que piden las normas (qué ha pasado, a quién preguntar, qué consecuencias tiene y qué debe hacer quien lo recibe), una vía capaz de llegar a todos aunque el correo corporativo esté caído, y el criterio de cuándo procede decidido antes: en varias normas el aviso se dispara por amenaza, sin incidente todavía. NIS2RGPDCRA

El runbook de la cartera invierte el orden habitual: ante una violación que afecte a su fiabilidad lo primero es apagar, suspender la provisión y el uso, y contar viene después. El interruptor tiene que existir y estar ensayado, porque desde la suspensión corren 24 horas para las medidas correctoras y otras 24 para informar. Y si a los tres meses no está subsanado, se retiran las carteras y se revoca su validez.

• Suspensión de la provisión y el uso de la cartera, ejecutable sin dilación eIDAS
• Medidas correctoras en 24 horas desde la suspensión eIDAS
• Aviso a usuarios, partes usuarias, puntos de contacto únicos y Comisión en 24 horas desde la suspensión eIDAS
• Retirada y revocación de la validez si la violación no se subsana en tres meses eIDAS

QuéLa capacidad de seguir prestando el servicio cuando algo grande falla y de volver a la normalidad con orden, decidida y preparada antes de necesitarla.

CómoUn programa con responsable y presupuesto, revisado tras cada incidente, ejercicio o cambio relevante en los servicios; la eficacia de los planes solo se acredita mediante ejercicios.

CómoSin programa formal ni presupuesto propio: lo sostiene quien lleva la operación, con un ensayo anual sobre el papel en lugar de conmutaciones reales. Elegir bien las garantías del propio SaaS (SLA, copias, regiones) ayuda, aunque el SLA solo compensa económicamente la interrupción: la recuperación ante la pérdida del proveedor sigue siendo responsabilidad propia.

• Plan de continuidad y de recuperación ante desastrePlanes documentados con responsables, dependencias y pasos de vuelta, accesibles también con los sistemas caídos. RDL 12/2018NIS2RGPD
• Análisis de impacto en el negocioUn BIA que fije por servicio el tiempo máximo de parada admisible (RTO) y la pérdida de datos admisible (RPO). La clasificación mide el impacto de un incidente; el BIA, cuánto tiempo se sostiene la operación sin el servicio. NIS2
• Proceso de gestión de crisis, con quién decide y con qué umbral se activaUn comité con umbral de activación escrito, árbol de llamadas con suplentes y medios de contacto que no dependan de los sistemas caídos. NIS2
• Comunicación de la crisis y del avance de la recuperación a clientes y al públicoPortavocía designada por nombre, mensajes preparados por escenario y actualizaciones del avance mientras dura la recuperación, a clientes, contrapartes y público.
• Pruebas periódicas de los planes de continuidad y de recuperaciónLos planes se prueban al menos una vez al año y tras cada cambio relevante, con escenarios que lleguen a la conmutación real y no se queden en el papel; lo que falla en la prueba entra al plan con dueño y fecha.
• Redundancia y tolerancia a fallos en la arquitectura del servicioRutas, réplicas, zonas y medios alternativos para los servicios que el análisis marque como intocables, comprobando que las dos patas no comparten punto de fallo (mismo proveedor, misma zona, mismo operador).