Usamos IA para escribir más rápido, no para decidir qué es verdad. Alguien de Digital Samba ha leído cada línea de este artículo antes que tú.
La llamada de crisis suele ser lo primero que importa cuando empieza un incidente, y a menudo lo último que alguien ha revisado desde el punto de vista de la seguridad. Bajo la NIS2, ese hueco es un hallazgo de auditoría. Si tu organización es una entidad esencial o importante, la Directiva nombra la comunicación por vídeo segura de forma explícita: las mismas expectativas de cifrado, control de accesos y resiliencia que cubren el resto de tu parque ahora cubren la plataforma sobre la que trabaja tu equipo de respuesta a incidentes, y un fallo grave de esa plataforma puede convertirse en sí mismo en notificable.
Índice de contenidos
La NIS2 es la Directiva (UE) 2022/2555, la ley de ciberseguridad revisada de la UE (en su versión española oficial, la Directiva SRI 2), adoptada formalmente el 14 de diciembre de 2022 y publicada en el Diario Oficial el 27 de diciembre de 2022. Sustituyó a la Directiva NIS original de 2016, amplió la lista de sectores cubiertos de 7 a 18 y obligó a los estados miembros a transponerla a su derecho nacional antes del 17 de octubre de 2024, con las obligaciones aplicables a partir del día siguiente.
La Directiva fija una base de medidas de gestión de riesgos de ciberseguridad y de deberes de notificación de incidentes para las entidades «esenciales» e «importantes» de dos grupos de sectores. El primer grupo cubre energía, transporte, banca, infraestructuras de los mercados financieros, salud, agua potable, aguas residuales, infraestructura digital, gestión de servicios TIC, administración pública y espacio: 11 sectores en total. El segundo grupo cubre servicios postales y de mensajería, gestión de residuos, productos químicos, alimentación, fabricación de productos críticos, proveedores digitales y organizaciones de investigación: otros siete, hasta llegar a 18. «Proveedores digitales» aquí significa mercados en línea, motores de búsqueda y plataformas de redes sociales, una categoría más estrecha que los operadores de infraestructura digital del primer grupo.
La categoría en la que cae una organización no es solo cuestión de en qué lista está. Dentro del primer grupo, lo decide el tamaño. El artículo 2 toma las definiciones estándar de tamaño de empresa de la UE, y no funcionan como lo haría una única prueba de «empleados o facturación». La plantilla es una condición propia, y las dos cifras financieras son alternativas entre sí. Una organización cuenta como mediana si tiene menos de 250 empleados y, o bien una facturación de no más de 50 millones de euros, o bien un balance total de no más de 43 millones de euros, y como grande en cuanto supera esos techos. Por debajo del umbral de pequeña empresa (menos de 50 empleados con una facturación o un balance total de no más de 10 millones de euros), una entidad suele quedar fuera de la NIS2 por completo. El artículo 3 aplica entonces esas categorías de tamaño dentro del primer grupo: las organizaciones grandes se clasifican como esenciales y las medianas como importantes. Los dos criterios interactúan de forma incómoda en los márgenes, así que una organización que esté en el límite debería contrastarse con las definiciones en vez de leer a partir de una sola cifra.
Las entidades del segundo grupo se tratan de otra manera: todas cuentan como importantes por defecto, sin importar su tamaño.
Hay aquí una distinción que importa más de lo que parece: la NIS2 es una directiva, no un reglamento. Los números de artículo citados a lo largo de este texto no son en sí mismos la ley que tienes que cumplir. Una directiva fija un objetivo que cada estado miembro transpone a su propia legislación nacional, y es esa norma nacional de transposición, no el texto de la Directiva, lo que te aplicará un regulador o un auditor. La transposición ha sido desigual: varios estados miembros seguían tramitándola bastante después del plazo de octubre de 2024. En España, la Directiva se traspone mediante legislación nacional todavía en tramitación (el anteproyecto de ley de coordinación y gobernanza de la ciberseguridad), y las autoridades de referencia en España son el INCIBE y el CCN. La NIS2 funciona también con un modelo de autoidentificación: una vez que has averiguado dónde estás, se espera que registres tu condición ante tu autoridad nacional competente en vez de esperar a que te lo digan. Confirma tanto esa autoridad como qué norma nacional te aplica, y el estado exacto de la transposición española, antes de dar por sentado nada más de este artículo.
Dos cosas distinguen a la NIS2 del RGPD, que muchos equipos de cumplimiento ya conocen bien. Primero, va sobre la seguridad de las redes y los sistemas de información, no sobre los datos personales en concreto, aunque los dos regímenes se solapan siempre que las videollamadas llevan datos personales. Segundo, introduce una responsabilidad directa y personal para los órganos de dirección (artículo 20), junto con multas que escalan con la facturación mundial (artículo 34).
El artículo 21(2)(j) es explícito: junto con exigir autenticación multifactor o continua, obliga a las entidades a implementar, «cuando proceda», comunicaciones de voz, vídeo y texto seguras y sistemas de comunicación de emergencia seguros. Las videollamadas son donde los equipos de respuesta a incidentes se coordinan durante un ataque de ransomware en directo, donde los miembros del consejo discuten una brecha antes de que se haga pública y donde clínicos, ingenieros o cargos públicos intercambian detalles operativos sensibles. Si ese canal se ve comprometido, la confidencialidad de todo lo que se habla en él también queda comprometida.
Una caída de la videoconferencia puede, en algunos casos, convertirse por sí misma en el «incidente significativo» que dispara el reloj de notificación de la NIS2, aunque el listón del artículo 23(3) es alto: hace falta una perturbación operativa grave o pérdidas económicas para la propia entidad, o daños materiales o inmateriales considerables a otras personas, y es más probable que se alcance cuando el canal de vídeo es central para el servicio regulado de la entidad (una plataforma de telesalud, por ejemplo, en vez de un fabricante cuyo personal simplemente usa el vídeo para hablar entre sí). Por eso la videoconferencia se ha convertido en un área de control nombrada bajo la NIS2, y no en una simple línea de seguridad de fondo. También explica por qué los auditores ahora preguntan cómo se aprovisionan las plataformas de reuniones, y no solo cómo se parchean los portátiles.
Antes de preguntar si tu herramienta de vídeo cumple los requisitos de la NIS2, comprueba si tu proveedor es en sí mismo una entidad dentro del ámbito. El anexo I de la Directiva enumera la infraestructura digital y, por separado, la gestión de servicios TIC (B2B), como sectores cubiertos sin importar el sector del comprador. Los proveedores de servicios de computación en la nube, los operadores de centros de datos, los proveedores de redes de distribución de contenidos y los proveedores de servicios gestionados y de servicios de seguridad gestionados se nombran de forma explícita, y el Reglamento de Ejecución (UE) 2024/2690 de la Comisión fija requisitos técnicos y metodológicos que vinculan directamente a varias de estas categorías. Un puñado de categorías, entre ellas los proveedores de servicios de DNS y los prestadores cualificados de servicios de confianza, se tratan como entidades esenciales sin importar su tamaño. Si un proveedor concreto cuenta como «proveedor de servicios gestionados» o cumple la definición de proveedor de servicios de computación en la nube no siempre es obvio desde fuera, y conviene leer un análisis legal centrado en esa frontera en vez de adivinar.
Una plataforma de videoconferencia que opera su propia infraestructura, en vez de revender la de otro, a menudo cumplirá la definición de proveedor de servicios de computación en la nube en cuanto cruce los umbrales de tamaño del artículo 2 expuestos arriba, con los proveedores grandes como esenciales y los medianos como importantes en este sector. En la práctica, esto significa que tu proveedor puede estar obligado de forma independiente bajo la NIS2, lo que conviene confirmar durante la diligencia debida. Es contexto útil más que un mérito de cumplimiento, eso sí: no hay un esquema de certificación NIS2 al que apuntar como apuntarías al certificado ISO 27001 de un proveedor, y la condición de tu proveedor no reduce la diligencia debida de la cadena de suministro que el artículo 21 te exige a ti como comprador.
El artículo 21(2) establece 10 categorías de medidas de gestión de riesgos que las entidades esenciales e importantes deben aplicar, de forma proporcionada, según su tamaño y su exposición al riesgo. Varias se corresponden directamente con cómo se configura y se usa una herramienta de videoconferencia.
Para el vídeo, esto necesita algo de precisión, porque «cifrado» se usa de forma laxa en todo el sector. El artículo 21(2)(h) exige políticas sobre el uso de la criptografía y, «cuando proceda», del cifrado. Las plataformas basadas en WebRTC cifran la señalización con TLS y los flujos de medios con DTLS-SRTP por defecto. Esto es cifrado de transporte: la conexión entre cada dispositivo y el servidor está protegida, pero el propio servidor de medios descifra y vuelve a cifrar los flujos a medida que los enruta. Eso da al proveedor acceso técnico al audio y al vídeo en claro durante la llamada. El cifrado de extremo a extremo (E2EE) es una propiedad distinta y más fuerte: las claves se generan en el dispositivo del participante y nunca salen de él, así que la infraestructura (servidores de señalización, servidores de medios y proveedores de alojamiento) solo maneja texto cifrado que no puede leer.
La NIS2 no obliga a usar E2EE en todas las llamadas. El artículo 21(2)(h) fija un estándar «apropiado» y proporcionado, así que el control correcto depende de qué se esté hablando. Para las reuniones internas rutinarias, el cifrado de transporte suele bastar. Para las discusiones del consejo, las consultas jurídicas, las llamadas de respuesta a incidentes y cualquier cosa clasificada como incidente significativo bajo el artículo 23, el E2EE cierra el hueco que el cifrado de transporte deja en el servidor. Eso viene con un compromiso que conviene conocer antes de activarlo: como el servidor nunca ve los medios descifrados, no puede producir una grabación, una transcripción ni ningún otro registro de contenido de esa sesión. Los metadatos, como las marcas de tiempo y quién entró o salió y cuándo, se siguen registrando, pero si tu proceso de respuesta a incidentes depende de que el proveedor aporte el contenido de la sesión para la notificación del artículo 23, acuerda con él por adelantado qué pruebas sobrevivirán al E2EE y cuáles no, y elige el control en consecuencia para esa llamada concreta.
La letra j) del artículo 21(2), la misma que cubre las comunicaciones de voz, vídeo y texto seguras, también nombra de forma explícita la autenticación multifactor o continua; los deberes relacionados de control de accesos y de seguridad de los recursos humanos están en la letra i). Para la videoconferencia esto se traduce en permisos por rol que separan a anfitriones, coanfitriones y participantes; una sala de espera para que los usuarios no autenticados no puedan entrar en una sesión en directo sin control; e inicio de sesión único (SSO) con autenticación multifactor (MFA) impuesta en la capa del proveedor de identidad en vez de dejarla a cada usuario. Los enlaces de reunión que se pueden adivinar, reutilizar de forma indefinida o a los que se puede entrar sin la aprobación de un anfitrión son un hallazgo recurrente en las evaluaciones de brechas de la NIS2, precisamente porque socavan una política de control de accesos por lo demás sólida en el resto de la organización.
Una plataforma de vídeo necesita redundancia entre regiones o centros de datos, para que una sola caída no elimine la capacidad de la organización de comunicarse justo en el momento en que un incidente exige coordinación. Esto importa sobre todo durante un ataque de ransomware, cuando el correo y el chat interno pueden estar comprometidos o no ser de fiar, y un canal de vídeo resiliente y alojado de forma independiente se convierte en el método de comunicación de reserva en el que el equipo de crisis se apoya de verdad. El artículo 21(2)(c) cubre la continuidad de negocio, incluidas la gestión de copias de seguridad y la recuperación ante desastres, y la letra a) exige el análisis de riesgos y las políticas de seguridad de los sistemas de información de forma más amplia.
Una brecha o una caída prolongada de la herramienta de videoconferencia usada para la comunicación del consejo, clínica u operativa puede alcanzar el umbral de «incidente significativo» si provoca una perturbación operativa grave, el mismo listón descrito antes en este artículo. El artículo 23 fija un calendario de notificación en tres fases para los incidentes significativos: una alerta temprana en las 24 horas siguientes a tener conocimiento, una notificación de incidente más completa en 72 horas y un informe final en el plazo de un mes desde esa notificación de 72 horas. Las entidades necesitan saber, por adelantado, si su proveedor apoyará con pruebas a tiempo, como registros, marcas de tiempo y datos de las sesiones afectadas, para ese ciclo de notificación. Esperar a que ocurra un incidente para pedir esta información a un proveedor es un punto de fallo común y evitable.
El artículo 21(2)(d) y el artículo 21(3) exigen a las entidades evaluar las prácticas de ciberseguridad de sus proveedores directos, incluida la calidad de sus productos y sus procedimientos de desarrollo seguro. Tu proveedor de videoconferencia entra en esa categoría, y la diligencia debida debería extenderse a sus subencargados (proveedores de alojamiento, operadores de CDN e infraestructura de retransmisión TURN/STUN, los servidores que transportan los medios cuando no se puede establecer una conexión directa entre dispositivos), no solo a la puerta de entrada del proveedor. Los lectores del sector financiero deberían tener en cuenta que esto es más que un estándar paralelo. DORA, el Reglamento de Resiliencia Operativa Digital, está designado por su propio artículo 1(2) como acto de la Unión sectorial a efectos del artículo 4 de la NIS2, y esa disposición desactiva los artículos 21 y 23 de la NIS2 para las entidades dentro del ámbito de DORA. Eso significa que las propias reglas de DORA sustituyen a las medidas de gestión de riesgos de la NIS2, incluida la evaluación de la cadena de suministro descrita aquí, y a sus deberes de notificación de incidentes, en vez de añadir una segunda capa encima. DORA añade también su propio régimen de pruebas de resiliencia y de supervisión de terceros, sin equivalente directo en la NIS2. Las entidades fuera del ámbito de DORA siguen bajo la NIS2.
La responsabilidad de la dirección no es una de las diez medidas del artículo 21(2) vistas arriba. Descansa en el artículo 20, que regula quién firma esas medidas y quién responde por ellas. Un consejo o un directivo que aprueba seguir usando una herramienta de vídeo que carece de MFA, o que almacena grabaciones fuera de las jurisdicciones acordadas, está tomando una decisión de gestión de riesgos de la que ahora es personalmente responsable. El artículo 20 exige a los órganos de dirección aprobar las medidas de gestión de riesgos del artículo 21, supervisar su implementación y recibir formación ellos mismos. Para las entidades esenciales, aunque no para las importantes, lo que está en juego llega más lejos: el artículo 32(5) exige a los estados miembros dar a sus autoridades competentes la potestad de prohibir temporalmente a una persona ejercer responsabilidades de dirección a nivel de director general o de representante legal por incumplimientos graves o reiterados. La Directiva excluye a las entidades de la administración pública de esta potestad concreta. Por lo demás, no es una opción nacional: la Directiva exige que la potestad exista, aunque cada estado miembro implemente el procedimiento a su manera.
La NIS2, el Reglamento de Ciberresiliencia (CRA) y DORA se confunden entre sí porque se solapan en materia, y porque la NIS2 y DORA se adoptaron el mismo día. Gobiernan cosas distintas.
| Norma | Qué gobierna | A quién aplica | Relevancia para la videoconferencia |
|---|---|---|---|
| NIS2 (Directiva (UE) 2022/2555) | Gestión de riesgos de ciberseguridad y notificación de incidentes para las organizaciones | Entidades esenciales e importantes de 18 sectores, incluidas la infraestructura digital y la gestión de servicios TIC | Gobierna cómo la entidad que usa o presta la herramienta de vídeo la protege (artículo 21) |
| Reglamento de Ciberresiliencia (Reglamento (UE) 2024/2847) | Seguridad desde el diseño y gestión de vulnerabilidades para los productos con elementos digitales | Fabricantes, importadores y distribuidores de hardware/software puestos en el mercado de la UE | Puede aplicar al propio software de videoconferencia como producto, al margen de cómo lo opere el comprador. El software entregado y consumido como servicio alojado suele quedar fuera del CRA; la prueba del «tratamiento de datos a distancia» actúa cuando el software va embebido en, o se envía con, un producto puesto en el mercado de la UE, así que la respuesta depende de cómo se empaquete y se venda una herramienta concreta |
| DORA (Reglamento (UE) 2022/2554) | Resiliencia operativa digital para el sector financiero | Bancos, aseguradoras, empresas de inversión, entidades de pago y de criptoactivos, y sus proveedores TIC críticos | Para las entidades financieras dentro de su ámbito, DORA sustituye a las medidas de gestión de riesgos del artículo 21 y a los deberes de notificación del artículo 23 que de otro modo tendrían bajo la NIS2, incluidos los que cubren a un proveedor de vídeo, y añade su propio régimen de pruebas de resiliencia; las entidades fuera del ámbito de DORA siguen bajo la NIS2 |
Una regla práctica útil: la NIS2 pregunta si la organización gestiona bien el riesgo; el CRA pregunta si el producto se construyó de forma segura; DORA pregunta si las operaciones de una entidad financiera, incluidos sus proveedores TIC, pueden resistir una perturbación. Un banco regulado que compra un producto de videoconferencia podría, en principio, tocar los tres.
Una forma neutral respecto al proveedor de evaluar cualquier plataforma es repasar lo siguiente, valorando cada punto por sus propias pruebas y no por las afirmaciones de marketing de un proveedor. La mayor parte se corresponde con el artículo 21, con el apoyo a la notificación de incidentes siguiendo el artículo 23 y el último punto quedando fuera de la NIS2 del todo, por el motivo que se da abajo. Trátalo como un menú que sopesar frente a tu propia evaluación de riesgos y tu tamaño, no como un mínimo uniforme que toda entidad tenga que superar por completo.
Pasar a un proveedor por esta lista y documentar tu razonamiento, incluido lo que juzgues no aplicable y por qué, produce un registro defendible para la aprobación del órgano de dirección que exige el artículo 20. Es también algo muy cercano a la definición práctica de videoconferencia segura que los auditores de la NIS2 buscarán durante una revisión.
El artículo 34 fija niveles mínimos que los estados miembros deben cumplir, aunque las leyes nacionales pueden ir más alto. Las entidades esenciales se enfrentan a multas administrativas de hasta 10 millones de euros o el 2 por ciento del volumen de negocio anual mundial total, lo que sea mayor; las entidades importantes, a hasta 7 millones de euros o el 1,4 por ciento del volumen de negocio. No son sanciones puntuales añadidas encima de la supervisión normal: las entidades esenciales están sujetas a una supervisión proactiva, ex ante, lo que significa que las autoridades nacionales pueden pedir pruebas de cumplimiento sin un incidente previo, mientras que las importantes se supervisan de forma reactiva, normalmente tras una brecha o una queja. Las entidades esenciales cargan también con la exposición a la responsabilidad personal descrita arriba en «Responsabilidad de la dirección»: una posible prohibición temporal de ejercer responsabilidades de dirección bajo el artículo 32(5) por incumplimientos graves o reiterados. Los techos exactos de las multas, el enfoque de aplicación y las disposiciones de responsabilidad personal varían según el estado miembro, así que confirma con tu función de cumplimiento o jurídica los detalles concretos que aplican a tu organización.
Por defecto, las llamadas en la API y el SDK de videoconferencia de Digital Samba usan las protecciones de capa de transporte integradas en WebRTC: TLS para la señalización y DTLS-SRTP para los medios. También ofrecemos cifrado de extremo a extremo opcional para las sesiones en las que esa garantía más fuerte está justificada. Las claves se generan localmente en el dispositivo de cada participante con la Web Crypto API y nunca se transmiten a nuestros servidores ni se almacenan en ellos. Los medios se protegen con AES-128 en modo contador con autenticación HMAC-SHA256, así que, una vez activado, nuestra infraestructura solo reenvía texto cifrado que no puede leer. Esto da a los equipos de seguridad y cumplimiento una elección real que tomar bajo el artículo 21(2)(h), en vez de una postura de cifrado única y fija. El E2EE es un ajuste por sesión, no nuestro estado por defecto, así que decide por adelantado, como con cualquier proveedor, qué sesiones lo necesitan y cuáles necesitan que mantengamos disponible la capacidad de grabación o transcripción en su lugar.
En control de accesos, admitimos permisos por rol, salas de espera y autenticación por API que se integra con la configuración de identidad y SSO existente de una organización, para que la imposición de MFA pueda situarse en la capa del proveedor de identidad como espera el artículo 21(2)(j). Al ser una API REST y un SDK incrustable en vez de una aplicación de consumo fija, nuestra plataforma está pensada para integrarse en las herramientas de gobernanza, registro y gestión de accesos de la propia entidad, lo que apoya el tipo de rastro de pruebas que piden tanto la gestión de riesgos del artículo 21 como la notificación de incidentes del artículo 23.
La residencia de datos en sí es una cuestión de RGPD y de soberanía más que un requisito de la NIS2, pero suele formar parte de la misma conversación de diligencia debida. Nuestra infraestructura de producción se ejecuta en los Países Bajos, con infraestructura de respaldo en Alemania; la capacidad de desbordamiento en picos de demanda incluye un proveedor suizo, cuya ubicación descansa sobre una decisión de adecuación y no sobre la residencia en la UE o el EEE. El tratamiento de datos alineado con el RGPD está integrado en nuestra arquitectura en vez de añadido después.
No tenemos una certificación directa ISO 27001 ni SOC 2 a fecha de hoy. Nuestros controles están documentados, no certificados: el sistema de gestión de seguridad de la información de Digital Samba usa la ISO 27001:2022 como marco de referencia, y estamos trabajando para lograr la certificación formal frente a él. Donde las certificaciones importen en tu proceso de compra, pide a cualquier proveedor, nosotros incluidos, su estado actual y las certificaciones de sus subencargados directamente, en vez de fiarte de afirmaciones de marketing generales.
Para los equipos que construyen una evaluación completa de la NIS2, nuestra guía de seguridad de WebRTC y nuestro explicador del cifrado de extremo a extremo profundizan más en la mecánica de fondo, y nuestro artículo sobre soberanía del dato cubre la parte de soberanía del dato del mismo proceso de diligencia debida.
Sí, de forma indirecta y directa. Indirecta, porque las entidades esenciales e importantes deben proteger las herramientas que su personal usa para la comunicación de voz, vídeo y texto bajo el artículo 21(2)(j). Directa, porque un proveedor de videoconferencia que opera su propia infraestructura de nube a escala puede ser en sí mismo una entidad de infraestructura digital o de servicios TIC dentro del ámbito.
El artículo 21(2) enumera 10 categorías de medidas de gestión de riesgos proporcionadas, varias de las cuales aplican directamente a una plataforma de vídeo: política de criptografía y cifrado, control de accesos y autenticación multifactor, continuidad de negocio y resiliencia, gestión de incidentes y evaluación de la seguridad de la cadena de suministro del propio proveedor.
Depende de cómo se preste el servicio y del tamaño del proveedor. Un proveedor que opera su propia infraestructura de alojamiento puede caer en las categorías de «proveedor de servicios de computación en la nube» o «gestión de servicios TIC» del anexo I, clasificado como esencial en cuanto supera los techos de mediana empresa (250 empleados o más, o una facturación por encima de 50 millones de euros junto con un balance total por encima de 43 millones de euros) e importante por debajo de eso pero por encima del umbral de pequeña empresa. Un proveedor que simplemente revende la infraestructura de otra empresa se evalúa de otra forma, así que conviene confirmarlo por proveedor.
No. El artículo 21(2)(h) exige un uso «apropiado» de la criptografía y del cifrado, no un estándar técnico concreto. El cifrado de transporte (TLS y DTLS-SRTP) es lo que traen por defecto las plataformas basadas en WebRTC y es adecuado para muchos casos de uso; el cifrado de extremo a extremo es un control más fuerte y adicional que las entidades deberían aplicar donde la sensibilidad de la conversación, como asuntos del consejo, respuesta a incidentes y datos regulados, lo justifique.
La NIS2 gobierna cómo una organización dentro del ámbito gestiona el riesgo de ciberseguridad y notifica incidentes. Para las entidades financieras dentro de su ámbito, DORA sustituye las obligaciones de gestión de riesgos y de notificación de incidentes de la NIS2 en vez de situarse junto a ellas, y añade su propio régimen de pruebas de resiliencia y de supervisión de terceros. El Reglamento de Ciberresiliencia gobierna la seguridad del propio producto de software o hardware, y pone obligaciones sobre el fabricante en vez del comprador. Una entidad financiera regulada que compra un producto de videoconferencia podría verse afectada por los tres, según su propia condición y la del proveedor.
Las entidades esenciales e importantes de los 18 sectores enumerados en los anexos I y II de la Directiva (UE) 2022/2555, determinadas por lo general por el sector y por los umbrales de tamaño del artículo 2 (a grandes rasgos, las entidades medianas son importantes y las mayores esenciales, donde mediana significa menos de 250 empleados con una facturación de hasta 50 millones de euros o un balance total de hasta 43 millones de euros; las organizaciones por debajo del umbral de pequeña empresa suelen quedar fuera del ámbito), con ciertas categorías, como los proveedores de servicios de DNS y los prestadores cualificados de servicios de confianza, dentro del ámbito sin importar su tamaño.
Bajo el artículo 34, las entidades esenciales se enfrentan a multas de hasta 10 millones de euros o el 2 por ciento del volumen de negocio anual mundial, lo que sea mayor; las entidades importantes, a hasta 7 millones de euros o el 1,4 por ciento del volumen de negocio. Los estados miembros pueden fijar techos más altos en la ley nacional. El artículo 20 añade responsabilidad personal para los órganos de dirección y, para las entidades esenciales en concreto, el artículo 32(5) permite a las autoridades competentes imponer prohibiciones temporales de dirección en casos de incumplimiento grave o reiterado.
Este artículo ofrece información general y no constituye asesoramiento jurídico. Confirma las obligaciones concretas de tu organización bajo la NIS2, tu clasificación como entidad y tus deberes de notificación con tu función de cumplimiento o jurídica.