8 min. de lectura Actualizado: 22.04.2026

La Ley de Implementación NIS2 está en vigor desde el 6 de diciembre de 2025, el Bundestag aprobó la Ley Marco KRITIS el 29 de enero de 2026. El BSI ha publicado el catálogo de criterios revisado C5:2026 para la computación en la nube segura. Los operadores de nube en Alemania deben leer ahora estos tres marcos normativos de forma conjunta, en lugar de abordar cada uno por separado. Quien no conciba la tríada como una unidad duplica los costes de cumplimiento y construye estructuras paralelas que nadie querrá mantener.

Lo más importante en resumen

• Tres marcos normativos simultáneos: La Ley de Implementación NIS2 (en vigor desde el 06.12.2025), la Ley Marco KRITIS (Bundestag 29.01.2026) y el catálogo BSI C5:2026 se aplican en paralelo a los operadores de nube con relevancia KRITIS (Gobierno federal sobre la implementación de NIS2).
• Afectación escalonada: Más de 30.000 empresas en Alemania quedan sujetas a nuevas obligaciones de seguridad ampliadas. Los operadores de nube se ven interpelados en muchos casos de forma triple: como entidad importante o especialmente importante, como instalación KRITIS y como encargado del tratamiento para terceros.
• C5:2026 reajustado: El catálogo revisado del BSI comprende 168 criterios en 17 áreas temáticas, con nuevos requisitos sobre gestión de contenedores, criptografía post-cuántica y computación confidencial.
• La multi-nube es posible, pero no neutral: AWS, Microsoft Azure y Google Cloud cuentan con certificaciones C5, pero el alcance por servicio difiere. Quien utilice varios hiperescaladores debe clarificar, para cada carga de trabajo KRITIS, qué alcance de nube resulta aplicable.
• El margen de tiempo es estrecho: Las obligaciones de registro y notificación de NIS2 están ya activadas; las primeras inspecciones del BSI basadas en los nuevos marcos comenzarán en el verano de 2026.

RelacionadoArquitectura de inferencia de IA para DACH 2026  /  Reshoring en la mediana empresa

Qué se aplica exactamente y desde cuándo

¿Qué es KRITIS en sentido regulatorio? KRITIS designa las infraestructuras críticas cuyo fallo o deterioro provocaría graves desabastecimientos o amenazas a la seguridad pública. Los sectores incluyen energía, agua, alimentación, TI y telecomunicaciones, salud, finanzas y seguros, transporte y tráfico, así como Estado y administración. El legislador define umbrales por sector a partir de los cuales una instalación se considera KRITIS y asume las obligaciones correspondientes.

La ley de transposición de NIS2 ha ampliado considerablemente el círculo de destinatarios. Junto a los operadores KRITIS clásicos, las entidades especialmente importantes e importantes también quedan sujetas a obligaciones de seguridad reforzadas, lo que según los análisis del BSI y del portal especializado OpenKRITIS afecta a unas 30.000 empresas en Alemania. Para los operadores de nube esto es relevante porque en muchos casos tanto gestionan su propia infraestructura TI como crítica, como prestan servicios a otras entidades KRITIS.

La ley marco KRITIS, aprobada por el Bundestag el 29 de enero de 2026, complementa la perspectiva con la resiliencia física. Mientras que NIS2 pone el foco en la ciberseguridad, la ley marco apunta a la protección frente a riesgos naturales, sabotaje y amenazas híbridas. Para los operadores de centros de datos esto es una referencia clave: la seguridad de las instalaciones, el control de acceso y el suministro eléctrico de emergencia reciben un marco regulatorio adicional.

Fuente: BSI Bundesamt für Sicherheit in der Informationstechnik, OpenKRITIS, a fecha de abril de 2026.

Qué hay de nuevo en C5:2026

El catálogo de criterios C5 del BSI es desde 2016 el marco de referencia para la computación en la nube segura en Alemania. La versión revisada C5:2026 reestructura los ámbitos de auditoría e incorpora tres temas que en las versiones anteriores estaban ausentes o solo aparecían de forma marginal. En primer lugar, la gestión de contenedores: los requisitos sobre seguridad en tiempo de ejecución, análisis de imágenes y políticas de red se han ampliado y formulado de manera más explícita. En segundo lugar, la criptografía post-cuántica: los operadores de nube deben presentar una hoja de ruta documentada para la migración de datos sensibles de larga duración. En tercer lugar, la computación confidencial: para cargas de trabajo de alta clasificación de protección, el uso de entornos de confianza respaldados por hardware, como los Trusted Execution Environments, se incorpora al catálogo de criterios.

Para los operadores de nube con relevancia KRITIS, C5 ya no es una certificación voluntaria, sino el estándar industrial de facto. Los proveedores de servicios sanitarios deben presentar una certificación C5 desde julio de 2024 en virtud de la Ley Digital, y otros sectores regulados siguen el mismo camino en la práctica. La auditoría la realizan auditores que, tras una verificación exitosa, acreditan el cumplimiento de los criterios.

En la práctica, esto significa para los equipos de nube en la región DACH: quienes utilizan certificaciones C5 para cumplir los requisitos de sus clientes deben integrar los nuevos temas de 2026 en su propio ciclo de auditoría. Quienes revisan las certificaciones de sus proveedores deben comprobar con atención si se basan en la versión 2026 o en la versión anterior. Los plazos de transición están fijados en el catálogo y varían según el tema.

Qué significa Multi-Cloud en este contexto

Los tres hiperescaladores AWS, Microsoft Azure y Google Cloud disponen de certificaciones C5 para servicios esenciales, aunque no de forma exhaustiva. Cada proveedor define por servicio y región qué certificados aplican y cuáles no. Para una carga de trabajo KRITIS distribuida entre varios hiperescaladores, la comparación de alcances no es, por tanto, una mera formalidad.

Un ejemplo concreto. Quien opere un sistema de gestión de pacientes en Alemania necesita una certificación C5 para toda la cadena. Si la base de datos y la aplicación corren en AWS Frankfurt, la capa de análisis en Azure Germany-West-Central y determinados volúmenes de copia de seguridad fluyen a través de Google Cloud Europe-West3, las certificaciones deben estar disponibles por servicio. Si falta alguna, toda la carga de trabajo queda fuera de la conformidad C5 hasta que el proveedor cierre la brecha o el subsistema sea migrado.

Paralelamente, la ley paraguas KRITIS actúa a nivel de ubicación. Quien opere su entorno de producción principal en un centro de datos de Frankfurt con clasificación de ubicación conocida y el Disaster-Recovery en Irlanda, debe incluir el emplazamiento de DR en el análisis de resiliencia, aunque no se utilice de forma primaria. La combinación de obligaciones NIS2 (ciberseguridad), ley paraguas KRITIS (resiliencia física) y criterios C5 (auditoría específica de nube) genera una matriz que debe elaborarse individualmente para cada carga de trabajo KRITIS.

Comparativa de los tres marcos normativos

El plan de implementación pragmático

Para los operadores de nube con relevancia KRITIS, en la práctica ha demostrado su eficacia un plan de cinco pasos que trata los tres marcos normativos como paquetes de trabajo relacionados. Primero, el inventario. Qué cargas de trabajo se ejecutan dónde, qué clasificación tienen y qué proveedores están involucrados. Sin este inventario, cada paso siguiente se da a ciegas.

Segundo, la clasificación de los destinatarios. Si la propia organización cae bajo NIS2 como entidad KRITIS, importante o especialmente importante, y dónde aplica adicionalmente la ley marco KRITIS. La clasificación determina la profundidad de las obligaciones, el ritmo de reporte y las modalidades de registro.

Tercero, la matriz de proveedores. Qué servicio cloud dispone de qué certificado C5, en qué versión y con qué alcance. En este punto, la mayoría de los proyectos acaban en la práctica en una hoja de cálculo Excel que debe actualizarse con cada nuevo lanzamiento de servicio. Las herramientas GRC especializadas eliminan este paso de trabajo, pero no son gratuitas.

Cuarto, la armonización de políticas. Las propias directrices internas de protección de acceso, respuesta a incidentes, clasificación de datos y copias de seguridad deben cotejarse con los requisitos de los tres marcos normativos. En muchas organizaciones existen políticas históricamente consolidadas que regulan varios temas en paralelo y resultan inconsistentes en sus intersecciones. Un sprint de armonización lo resuelve y ahorra un tiempo considerable de discusión en auditorías posteriores.

Quinto, el ritmo de auditoría. Quien utilice certificados C5 planifica el ciclo de revisión con el auditor. Quien ejecute el reporte NIS2 aclara el ritmo con el BSI. Quien cumpla las obligaciones de la ley marco KRITIS planifica ejercicios de resiliencia. Mantener tres ciclos en paralelo en una planificación anual es logísticamente exigente, pero manejable si un equipo GRC tiene la titularidad de los plazos.

Lo que falla sistemáticamente en la práctica

Dos errores se repiten una y otra vez en la consultoría. El primero es la organización paralela. Un equipo gestiona NIS2, otro C5, un tercero la ley paraguas KRITIS. Nadie ve las intersecciones. El resultado son listas de activos gestionadas tres veces, procesos de incidentes contradictorios y una factura de cumplimiento innecesariamente elevada. Quien planifica los tres ámbitos de forma conjunta desde el principio ahorra, según análisis internos de grandes operadores de centros de datos, entre un 20 y un 40 por ciento de los esfuerzos.

El segundo error afecta a la dependencia de proveedores. Un operador cloud que basa su certificación en un servicio del hyperscaler, que a su vez utiliza una certificación previa, se queda en el momento crítico sin confirmación actualizada si el hyperscaler modifica el alcance del servicio. Estos cambios se producen con más frecuencia de lo que las empresas esperan, porque los catálogos cloud crecen de forma dinámica. Un derecho contractual de notificación de cambios con el proveedor se ha convertido por ello en estándar, aunque no está implantado en todas partes.

Una tercera cuestión se subestima con frecuencia: qué KPIs internos reflejan el cumplimiento. El cumplimiento de un proceso sin métricas es un tema de auditoría en el próximo ciclo. Quien dispone del tiempo de respuesta ante incidentes, el tiempo entre la disponibilidad de un parche y su despliegue, la cobertura de certificación por carga de trabajo y el número de hallazgos abiertos en una estructura de dashboard común, puede rendir cuentas ante el consejo de supervisión y el BSI. Sin estos datos, el cumplimiento se queda en lo narrativo.

Una cuarta brecha se manifiesta en la documentación de las cadenas de notificación. NIS2 exige una alerta temprana en 24 horas, una notificación de incidente en 72 horas y un informe final en el plazo de un mes. La ley paraguas KRITIS añade vías de notificación para eventos físicos. Quien no ha ejercitado las rutas de escalada pierde en el momento crítico horas en coordinación que necesita para el análisis y la contención. Un ejercicio de tabletop semestral con los departamentos jurídico y de comunicación es por ello parte fija de una organización de cumplimiento madura, no un complemento opcional.

Un quinto aspecto afecta a la interfaz con el asegurador. Las condiciones de las pólizas de ciberriesgo se han endurecido notablemente en los últimos 18 meses. Los aseguradores preguntan hoy en la negociación de la póliza y en la entrevista de auditoría por la versión del certificado C5, la clasificación NIS2 y los tiempos documentados de respuesta ante incidentes. Quien no tiene estos documentos a mano arriesga recargos en la prima o reducciones de cobertura en caso de siniestro.

Conclusión

La ley de implementación de NIS2, la ley paraguas KRITIS y el BSI C5:2026 no son un trío de casillas que marcar, sino un marco regulatorio integrado para operadores cloud con relevancia KRITIS. Quien trata los tres marcos como una unidad reduce esfuerzo y riesgo al mismo tiempo. Quien los gestiona por separado construye estructuras paralelas que colapsan en la auditoría. El plan de implementación hasta otoño es ajustado, pero factible si el inventario, la matriz de proveedores y la armonización de políticas arrancan ahora. La diferencia entre un operador cloud bien y mal preparado será visible en el cuarto trimestre de 2026, cuando se ejecuten los primeros ciclos de auditoría completos.

Preguntas frecuentes

¿Debe cada startup cloud implementar ahora la tríada de compliance?

No, los umbrales de transposición de NIS2 y el reglamento KRITIS delimitan el ámbito de aplicación según tamaño, sector y valores de referencia. Para los proveedores más pequeños sin relación con KRITIS, siguen aplicándose únicamente las obligaciones generales de seguridad informática derivadas del RGPD y la normativa de telecomunicaciones. La tríada resulta relevante a partir de la categoría de entidad importante, entidad especialmente importante o instalación KRITIS.

¿Qué sectores se ven especialmente afectados?

Sanidad, sector financiero, energía, transporte y administración pública se encuentran en el centro de las obligaciones ampliadas. Los operadores cloud que prestan servicios a estos sectores quedan frecuentemente dentro del ámbito de aplicación de forma indirecta, porque sus clientes exigen certificaciones y acreditaciones que el operador solo puede facilitar si implementa él mismo la tríada.

¿Basta con la certificación C5 del hyperscaler para el propio cumplimiento normativo?

No. La certificación C5 del hyperscaler cubre la infraestructura base, no la propia aplicación, la propia clasificación de datos ni los propios procesos. Los operadores cloud necesitan habitualmente una certificación combinada que integre sus propios servicios y los componentes cloud utilizados.

¿Qué relación existe entre la ley marco KRITIS y NIS2?

NIS2 aborda la ciberseguridad, mientras que la ley marco regula la resiliencia física. En la aplicación práctica, la gestión de incidentes, el análisis de riesgos y las obligaciones de notificación se solapan. Quien construya un proceso que cumpla ambos marcos simultáneamente ahorra trabajo duplicado y reduce el riesgo de notificaciones contradictorias.

¿Qué significa la criptografía post-cuántica en el contexto de C5?

C5:2026 exige una hoja de ruta documentada para datos sensibles de larga vida útil. Esto no significa que todos los algoritmos actualmente en uso deban sustituirse de inmediato. Significa que los operadores cloud deben presentar un plan sobre cómo migrar a los procedimientos resistentes a la computación cuántica aprobados por NIST, qué datos tienen prioridad y qué plazos de transición se aplican.

Más de la red MBF Media

• La brecha de Vercel como caso de OAuth supply chain en SecurityToday
• Lista de verificación para CIOs sobre GenAI en producción en Digital Chiefs
• EU Digital Omnibus en el trílogo en MyBusinessFuture

Fuente imagen de portada: Pexels / Brett Sayles (px:5480781)