Saltar al contenido
OS Domains
Regulation

NIS2 conforme con notificación interna en 12 horas.

OS Domains opera como entidad importante en el sector de infraestructura digital bajo NIS2 (Directiva (UE) 2022/2555), registrada en CERT.at como CSIRT nacional austriaco, con las diez medidas técnicas y organizativas del artículo 21 implementadas dentro de un SGSI alineado a ISO 27001:2022. Para clientes regulados el valor es evidencia de cadena de suministro a demanda: una autoevaluación del artículo 21 en una página, la evidencia de controles ISO 27001 y pre-certificación (criterios SOC 2) que la respalda, y un aviso temprano de incidente en 24 horas que alimenta la propia notificación del artículo 23 del cliente a su CSIRT nacional. La postura está construida para plegarse en el expediente de riesgo de proveedores del cliente y no para afirmarse en una llamada de ventas, porque bajo el artículo 20 la ausencia de esa evidencia es la exposición personal del directivo.

La Directiva (UE) 2022/2555 (NIS2) eleva el listón de ciberseguridad para 18 sectores europeos y endurece el régimen sancionador con multas de hasta 10 millones de euros y responsabilidad personal de directivos. Si tu empresa tiene 50+ empleados o factura más de 10 millones de euros y operas en sectores como infraestructura digital, energía, banca, sanidad o administración pública, NIS2 te aplica. España transpuso parcialmente con Real Decreto-ley 7/2025 y mantiene en tramitación la Ley de Coordinación y Gobernanza de la Ciberseguridad, pero las obligaciones europeas son exigibles independientemente del estado de la transposición nacional.

OS Domains opera como entidad importante bajo el Anexo II, con criterios de entidad esencial aplicados a toda la infraestructura. Nuestro compromiso contractual es notificarte una incidencia en 12 horas para que te quede margen para tu notificación temprana de 24 horas a la autoridad competente.

En breve

  • Clasificada como entidad importante en infraestructura digital bajo NIS2, registrada en CERT.at y reportando bajo la NISG 2024 austriaca.
  • Las diez medidas del artículo 21 mapean a controles concretos dentro de un SGSI alineado a ISO 27001:2022, con una autoevaluación de una página que el cliente pliega en su propio expediente de cumplimiento.
  • La cascada del artículo 23 alimenta el reloj del cliente: aviso temprano bien dentro de las 24 h, objetivo operativo de 30 minutos desde la confirmación, luego evaluación a 72 h e informe final a 1 mes.
  • Cifras de continuidad enunciadas y probadas: RPO 6 horas, RTO 4 horas, backups cifrados de 35 días y pruebas de restauración trimestrales.
  • DORA es lex specialis bajo el artículo 4(1) de NIS2, así que un cliente financiero sigue DORA para los deberes compartidos de riesgo TIC y reporte de incidentes y se le considera cumpliendo las obligaciones equivalentes de NIS2.
Cifras clave
Directiva (UE)
2022/2555
Multa máx. entidad esencial
10M€ o 2% facturación
Notificación temprana
24 horas
Plazo total notificación
24h / 72h / 1 mes

¿Qué exige NIS2 y por qué te aplica?

La Directiva (UE) 2022/2555, conocida como NIS2, sustituyó a la NIS1 de 2016 y endureció el régimen europeo de ciberseguridad. Te aplica si tu organización tiene 50+ empleados o factura más de 10 millones de euros y opera en uno de los 18 sectores incluidos en sus Anexos I y II (energía, transporte, finanzas, salud, agua, infraestructuras digitales, administración pública, servicios postales, gestión de residuos, industria química, alimentaria, servicios digitales, investigación científica, seguridad privada y otros). Las obligaciones del artículo 21 incluyen análisis de riesgos, gestión de incidentes, continuidad de negocio, seguridad de la cadena de suministro, criptografía, control de accesos, formación y notificación de incidentes en plazos armonizados de 24 horas (notificación temprana), 72 horas (notificación inicial) y 1 mes (informe final).

Estado de transposición en España.

España no cumplió el plazo de transposición del 17 de octubre de 2024. En enero de 2025 el Consejo de Ministros aprobó el Anteproyecto de Ley de Coordinación y Gobernanza de la Ciberseguridad, y en mayo de 2025 la Comisión Europea envió a España un dictamen motivado por la transposición incompleta, paso previo a un recurso ante el TJUE. El Real Decreto-ley 7/2025 transpuso parcialmente la directiva, pero la ley orgánica completa sigue en tramitación parlamentaria. El retraso no exonera a las empresas: las obligaciones de NIS2 son exigibles por el derecho UE directo en los aspectos que no requieren ejecución y, en cualquier caso, los clientes y supervisores europeos están aplicando criterios coherentes con la directiva sin esperar la transposición plena.

¿Cómo se cumplen las 10 medidas del artículo 21?

El artículo 21.2 de NIS2 enumera 10 medidas técnicas, operativas y organizativas mínimas: políticas de análisis de riesgos y de seguridad de la información, gestión de incidentes, continuidad de negocio y gestión de crisis, seguridad de la cadena de suministro, seguridad en la adquisición y desarrollo de sistemas, políticas y procedimientos para evaluar la eficacia, prácticas básicas de higiene cibernética y formación en ciberseguridad, criptografía y cuando proceda cifrado, seguridad de los recursos humanos, control de acceso y gestión de activos, y autenticación multifactor o continua. Como proveedor de email infraestructura UE, todas estas medidas afectan al servicio que prestamos: el cifrado SMTP STARTTLS y TLS 1.3 obligatorio, el control de acceso al panel con MFA por defecto, la segmentación de red entre clientes, los pentests anuales, el plan de continuidad activo entre PoPs europeos.

¿Qué multas y qué responsabilidad de directivos introduce NIS2?

NIS2 introduce dos niveles de multa según la categoría de entidad: hasta 10 millones de euros o 2% de la facturación mundial (la cifra mayor) para entidades esenciales, y hasta 7 millones de euros o 1,4% para entidades importantes. La novedad relevante es la responsabilidad personal de los órganos de dirección: los administradores deben aprobar y supervisar las medidas de gestión de riesgos, y pueden ser objeto de inhabilitación temporal en casos de infracciones graves y reiteradas. Para entidades esenciales el régimen de supervisión es proactivo (inspecciones in situ programadas, auditorías obligatorias); para entidades importantes es reactivo (sólo tras una infracción notificada). La autoridad competente española está pendiente de definición final con la transposición completa, pero el diseño institucional incluye un Centro Nacional de Ciberseguridad coordinador y autoridades sectoriales según ámbito (CCN-CERT para sector público, INCIBE-CERT para sector privado, CNPIC para infraestructuras críticas).

¿Cómo funciona tu notificación de incidentes del artículo 23?

Cuando un incidente significativo afecta a los datos de cliente o a la disponibilidad del servicio, nuestro incident commander dispara una cascada de notificación. Aviso temprano interno a los clientes afectados en las 24 horas siguientes a la detección, plazo que normalmente batimos porque el objetivo operativo es de 30 minutos desde la confirmación. Evaluación inicial con hechos materiales en 72 horas, incluyendo alcance del impacto, hipótesis de causa raíz y mitigaciones activas. Informe final en 1 mes con análisis completo de causa raíz, lecciones aprendidas y acciones correctivas. Los clientes en sectores de entidad esencial o importante pueden apoyarse en nuestra línea temporal de notificación para alimentar su propia notificación del artículo 23 de NIS2 al CSIRT nacional.

La obligación de cadena de suministro convierte la postura de tu proveedor en tu problema.

El artículo 21 enumera la seguridad de la cadena de suministro como una de las diez medidas obligatorias, lo que significa que una entidad regulada tiene que gestionar la seguridad de sus proveedores y prestadores de servicios como parte de su propio cumplimiento. Este es el mecanismo por el que NIS2 alcanza a proveedores que no están nombrados en la directiva: a través de los contratos y las exigencias de due diligence de los clientes regulados a los que sirven. Tu proveedor de email infraestructura es parte de tu superficie de ataque y por tanto parte de tu postura NIS2, así que los fallos de seguridad del proveedor se convierten en tu hallazgo en una auditoría. Nos convertimos en un activo de la cadena de suministro en lugar de un hueco siendo auditables a demanda: la lista pública de subprocesadores, las revisiones anuales de seguridad de subprocesadores disponibles bajo NDA, el proceso documentado de coordinación de incidentes y el mapeo del artículo 21 que un cliente puede plegar en su propio expediente de riesgo de proveedores. La misma transparencia que satisface un cuestionario de procurement satisface a un supervisor que revisa tu cadena de suministro, porque hacen la misma pregunta desde sillas distintas. Un proveedor que trata la evidencia de cadena de suministro como un entregable rutinario y no como una petición especial es el que no se convierte en el eslabón débil cuando corre tu propia evaluación.

El reloj de 24 horas es una restricción de diseño operativo, no una línea de política.

El artículo 23 fija una cadencia de reporte en tres etapas: un aviso temprano en las 24 horas siguientes a tener constancia de un incidente significativo, una notificación más completa en 72 horas y un informe final en un mes. La parte difícil es la primera etapa, porque el reloj arranca en el momento de tener constancia, y "significativo" tiene una definición: un incidente que causa o es capaz de causar una perturbación operativa grave, pérdidas financieras o un daño material a terceros. Cumplir ese plazo no es cuestión de tener una política que diga 24 horas; es cuestión de construir el pipeline de detección y confirmación para que el aviso pueda de verdad salir del edificio dentro de la ventana. Nuestra cascada está diseñada para alimentar tu reloj y no el nuestro. El monitoreo automatizado levanta una alerta en minutos, un incident commander confirma el alcance y los clientes afectados reciben un aviso temprano con los hechos materiales bien dentro de las 24 horas, con un objetivo operativo de treinta minutos desde la confirmación. La notificación lleva lo que tu equipo necesita para juzgar si se activa tu propia obligación del artículo 23, porque la evaluación de significatividad para tu organización es tuya y no puedes hacerla sin los hechos. Un proveedor cuyo primer aviso llega en la hora veintitrés ha cumplido técnicamente y en la práctica te ha dejado sin tiempo para cumplir tu propio plazo.

Continuidad de negocio y los objetivos de recuperación que NIS2 espera.

La medida (c) del artículo 21 exige continuidad de negocio y gestión de crisis, y un regulador que la lee quiere números en lugar de tranquilizaciones. Nuestra arquitectura se reparte entre varios puntos de presencia para que la pérdida de uno no tumbe el servicio, los backups se conservan treinta y cinco días y cifrados, y los procedimientos de restauración se prueban cada trimestre en lugar de darse por buenos. Los objetivos de recuperación están enunciados: un objetivo de punto de recuperación de seis horas que acota cuántos datos podría costar un evento en el peor caso, y un objetivo de tiempo de recuperación de cuatro horas que acota cuánto tarda la restauración. La gestión de crisis es un procedimiento documentado con un incident commander nombrado y una ruta de escalado definida, ejercitado en simulacros de mesa dos veces al año para que el plan sea memoria muscular y no una carpeta. Para un cliente, estos objetivos alimentan directamente su propia planificación de continuidad, porque la resiliencia de un canal de email que transporta restablecimientos de contraseña, confirmaciones de pedido y alertas de seguridad es parte del cuadro de riesgo operativo del propio cliente. Un proveedor que puede enunciar su RPO y su RTO y mostrar la evidencia de las pruebas de restauración deja que un cliente escriba un plan de continuidad contra cifras reales, mientras que un proveedor que solo habla de alta disponibilidad deja al cliente adivinando los números que un auditor acabará pidiendo.

¿Dónde se separan NIS2 y DORA para un cliente financiero?

Una entidad financiera que lee esta página suele estar sujeta a la vez a NIS2 y DORA, y los dos no se apilan de forma arbitraria. DORA es lex specialis bajo el artículo 4(1) de NIS2, lo que significa que para las obligaciones de gestión de riesgo TIC y de reporte de incidentes que ambos marcos comparten, una entidad financiera sigue DORA y se la considera como que ha cumplido los deberes equivalentes de NIS2. La banca y las infraestructuras de los mercados financieros quedaron fuera de los sectores centrales de NIS2 precisamente porque DORA gobierna su resiliencia operativa en términos más específicos. Para una fintech o un banco que elige proveedor de email, esto decide qué línea temporal de reporte y qué obligaciones de registro vinculan: las reglas de reporte de incidentes de DORA y los requisitos del Registro de Información, en lugar de la cascada del artículo 23 de NIS2, aunque las expectativas de seguridad subyacentes estén muy alineadas. Mantenemos la misma evidencia en cualquier caso, y nuestra página de DORA cubre las particularidades del sector financiero, pero la división vale la pena enunciarla aquí para que un comprador financiero no ensamble un expediente NIS2 cuando DORA es el marco que su supervisor aplicará de verdad.

Cómo lo resolvemos

Las capacidades específicas que importan para este caso.

01

Notificación en plazos NIS2

Comprometidos contractualmente a notificarte un incidente que te obligue a notificar bajo NIS2 en 12 horas desde nuestra detección, dejándote 12 horas de margen para tu notificación temprana de 24 horas a la autoridad competente.

02

Cláusulas de cadena de suministro

El plan Enterprise incluye cláusulas alineadas con el artículo 21.2.d (seguridad de la cadena de suministro): inventario de subencargados, mapeo de dependencias críticas, derecho de auditoría sobre proveedores nuestros, plan de salida documentado.

03

Cifrado obligatorio extremo a extremo

TLS 1.3 obligatorio en API y SMTP entrante, TLS oportunista para SMTP saliente con escalado a obligatorio donde el destinatario lo soporte. Almacenamiento cifrado AES-256 con HSM gestionado. No hay nivel de servicio sin cifrado por diseño.

04

MFA por defecto en panel

El portal de cliente requiere MFA desde el primer acceso (TOTP, WebAuthn, o llaves de seguridad FIDO2). No se puede deshabilitar. El acceso a la API usa keys con scoping granular y rotación obligatoria cada 90 días para cuentas con privilegios admin.

05

Pentest anual con informe ejecutivo

Pentest externo anual por firma independiente acreditada CCN-STIC. Resumen ejecutivo disponible bajo NDA. Hallazgos críticos remediados en 30 días, altos en 90 días, todos los demás en el plan de gestión del año siguiente.

06

Continuidad entre PoPs UE

La infraestructura está distribuida en 7 PoPs UE con failover automatizado entre datacenters. RPO objetivo de 1 minuto para la cola de envío, RTO de 5 minutos. Pruebas trimestrales documentadas con simulacros completos de pérdida de un PoP completo.

Retos habituales

Lo que vemos fallar y cómo lo arreglamos.

Identificar si eres entidad esencial o importante

No es trivial: el Anexo I define sectores "de alta criticidad" (energía, transporte, banca, sanidad, infraestructura digital, AAPP, espacio) y el Anexo II los "otros sectores críticos" (servicios postales, gestión de residuos, química, alimentación, servicios digitales, investigación). Una empresa SaaS B2B típica suele estar en Anexo II (servicios digitales) salvo que también opere DNS, registro TLD, registrar de IP o servicios de confianza cualificados, en cuyo caso está en Anexo I. La clasificación determina si la supervisión es proactiva o reactiva.

Cadena de suministro: qué exigir a tus proveedores

El artículo 21.2.d obliga a evaluar la seguridad de los productos y servicios adquiridos. Para email infraestructura esto se traduce en cláusulas contractuales sobre certificaciones (ISO 27001 mínimo), derecho de auditoría, notificación de incidentes con tu plazo (no el plazo del proveedor), continuidad documentada, plan de salida. Si tu proveedor actual no te firma estas cláusulas, NIS2 es razón legítima para migrar.

Gestionar reportes a múltiples autoridades

Una brecha grande puede obligarte a notificar simultáneamente a la AEPD (artículo 33 RGPD), a la autoridad sectorial NIS2 (CCN, INCIBE o sectorial), al supervisor financiero si aplica (Banco de España bajo DORA), al INCIBE-CERT, y a clientes/proveedores contractualmente. Tener proveedores que documenten su parte de la cadena con timestamps precisos te ahorra horas críticas en las primeras 24-72 horas.

Preguntas frecuentes

Las preguntas que más nos hacen.

01

¿Vosotros sois entidad esencial bajo NIS2?

OS Domains GmbH está clasificada como entidad importante bajo el Anexo II de NIS2 en la categoría de proveedores de servicios digitales (subapartado servicios de centros de datos / servicios gestionados). Algunos de nuestros servicios (registro de dominios y DNS) están en el Anexo I (sectores de alta criticidad), por lo que parte de la organización está bajo el régimen de supervisión proactivo. Operamos con criterios de entidad esencial en toda la infraestructura aunque formalmente sólo una parte lo sea.

02

¿Cómo encajan vuestros plazos con los míos?

NIS2 obliga al cliente afectado a notificar a la autoridad competente a las 24 horas (notificación temprana), a las 72 horas (notificación inicial) y a 1 mes (informe final). Nos comprometemos a notificarte en 12 horas desde nuestra detección si la incidencia puede activar tu obligación, dejándote 12 horas de margen para la notificación temprana. Las notificaciones de 72h y 1 mes incluyen aportes técnicos por nuestro lado en menos de 48 horas tras petición.

03

¿Tenéis ENS (Esquema Nacional de Seguridad)?

No directamente, porque ENS aplica a las administraciones públicas españolas y a sus proveedores cuando contratan servicios. Si nuestros clientes son administraciones públicas obligadas a ENS, podemos proporcionar la documentación equivalente: nuestra certificación ISO 27001:2022 cubre los controles mapeados al ENS nivel ALTO en una matriz que entregamos a petición.

04

¿Cubrís la formación de empleados que exige el artículo 21?

Hacemos formación interna anual obligatoria para todo el personal: 8 horas para roles no técnicos, 16 horas para ingeniería y operaciones, 24 horas para personal con acceso privilegiado. La formación incluye phishing simulado mensual, mejores prácticas, protocolos de respuesta a incidentes y RGPD. Los registros de asistencia y resultados están disponibles para auditoría.

05

¿Aceptaríais una auditoría in situ por mi parte?

Sí en plan Enterprise, una vez al año, con preaviso de 30 días, alcance acordado por escrito y sujeto a NDA mutuo. La auditoría puede cubrir la implementación de las 10 medidas del artículo 21.2, los registros de incidentes, las pruebas de continuidad, los logs de acceso al sistema. Es lo que esperamos de cualquier cliente que sea entidad esencial NIS2 y necesite demostrar evidencias a su autoridad competente.

06

¿Y si vuestra autoridad competente os multa? ¿Me lo notificáis?

Sí, contractualmente. Cualquier sanción material de la autoridad competente NIS2 austriaca o de cualquier otra autoridad europea que afecte a nuestros servicios se comunica al cliente en un plazo de 30 días. No hemos sido objeto de ninguna sanción NIS2 ni NIS1. La transparencia sobre este punto es habitual en nuestros DPA Enterprise.

Hablamos

Agenda una llamada técnica de 45 minutos con un ingeniero.

Sin SDR, sin comisiones, sin rondas de cualificación. Cuéntanos lo que necesitas, te decimos si encajamos, y te llevas una recomendación sea cual sea la respuesta.

Teléfono +43 1 205 11 80 Lun–Vie · 9–18 CET
Email [email protected] Respuesta media 4h en horario laboral
Oficina Fleischmarkt 1, 1010 Wien Con cita previa