# Plazos de notificación (FAQ)

> 35 preguntas sobre Plazos de notificación, en lenguaje claro: qué comprobar, qué muestra NetSenX y qué no ve un sensor.

Source page: https://netsenx.com/es/faq/reporting

## ¿Cuándo empieza el plazo de 24 horas de NIS2?

Cuando la entidad tiene conocimiento del incidente significativo, no cuando el incidente empezó. El artículo 23, apartado 4, cuenta desde ese momento tanto la alerta temprana (24 horas) como la notificación del incidente (72 horas).

https://netsenx.com/es/faq/when-does-the-nis2-24-hour-clock-start

## ¿Qué debe incluir una alerta temprana de NIS2?

Según el artículo 23, apartado 4, letra a), la alerta temprana indica, en su caso, si se sospecha que el incidente significativo se debe a actos ilícitos o malintencionados y si podría tener un impacto transfronterizo. Los detalles llegan en la notificación de 72 horas.

https://netsenx.com/es/faq/what-has-to-be-in-a-nis2-early-warning

## ¿El informe final vence un mes después del incidente?

No: un mes después del envío de la notificación del incidente. Si el incidente sigue en curso en ese momento, se presenta en su lugar un informe de situación, y el informe final en el mes siguiente a la gestión del incidente.

https://netsenx.com/es/faq/is-the-final-report-due-one-month-after-the-incident

## ¿Son distintos los plazos para los prestadores de servicios de confianza?

Sí. Un prestador de servicios de confianza notifica los incidentes significativos que afectan a la prestación de sus servicios de confianza en las 24 horas siguientes a tener conocimiento de ellos, en lugar de 72 horas.

https://netsenx.com/es/faq/are-the-deadlines-different-for-trust-service-providers

## ¿En qué plazo hay que notificar una brecha de datos según el RGPD?

Según el artículo 33 del RGPD, el responsable notifica la violación de la seguridad de los datos personales a la autoridad de control sin dilación indebida y, de ser posible, a más tardar 72 horas después de tener constancia de ella, salvo que sea improbable que constituya un riesgo para las personas. Según el artículo 34, cuando sea probable que entrañe un alto riesgo, debe comunicarse sin dilación indebida a los afectados. NetSenX prepara para su DPD una notificación del artículo 33; la decisión y el envío siguen siendo suyos.

https://netsenx.com/es/faq/how-fast-must-a-gdpr-breach-be-reported

## ¿Qué exige el CRA cuando se explota una vulnerabilidad?

El artículo 14 del Reglamento de Ciberresiliencia obliga a los fabricantes de productos con elementos digitales a notificar, en varias fases, las vulnerabilidades explotadas activamente en sus productos y los incidentes graves que afecten a la seguridad de esos productos. Para las fases, sus plazos y quién recibe las notificaciones, véase el Reglamento (UE) 2024/2847, artículo 14. Estas obligaciones de notificación se aplican desde el 11 de septiembre de 2026. Afectan a los fabricantes, no a las empresas que solo usan los productos, aunque el propio incidente de un usuario puede tener que notificarse según NIS2 o el RGPD.

https://netsenx.com/es/faq/what-does-the-cra-require-when-a-vulnerability-is-exploited

## ¿Se nos aplica DORA?

DORA, el Reglamento de resiliencia operativa digital (Reglamento (UE) 2022/2554), se aplica desde el 17 de enero de 2025 a las entidades financieras, como bancos, aseguradoras, empresas de servicios de inversión y entidades de pago, y a los proveedores terceros críticos de servicios TIC designados conforme a él. El artículo 19 obliga a las entidades financieras a notificar a su autoridad competente los incidentes graves relacionados con las TIC, con una notificación inicial, un informe intermedio y un informe final; los plazos los fijan normas técnicas adoptadas según el artículo 20. Para una entidad financiera, las normas de DORA sobre incidentes TIC prevalecen sobre las generales de NIS2. Si presta servicios TIC a una entidad financiera, DORA le llega a través del contrato: el artículo 30 enumera las cláusulas que deben contener esos contratos, entre ellas la asistencia en incidentes, los derechos de auditoría y los planes de salida. Espere preguntas detalladas y cláusulas de sus clientes financieros.

https://netsenx.com/es/faq/does-dora-apply-to-us

## ¿Qué se considera un incidente significativo según NIS2?

Un incidente que ha causado o puede causar una perturbación operativa grave de sus servicios o pérdidas económicas para su empresa, o que ha afectado o puede afectar a otras personas u organizaciones causándoles perjuicios materiales o inmateriales considerables. Ese es el criterio del artículo 23, apartado 3, y solo hay que notificar los incidentes significativos. «Puede causar» significa que no se espera a que el daño ocurra. Para ciertos proveedores digitales, como los de nube, DNS y servicios gestionados, el Reglamento de Ejecución (UE) 2024/2690 fija umbrales más precisos; para los demás, las leyes y autoridades nacionales pueden publicar orientaciones. Fije de antemano, en su procedimiento de incidentes, qué criterios usará, como servicios caídos durante cierto tiempo, datos de clientes afectados o un actor criminal implicado, y quién decide. NetSenX sigue los plazos una vez que usted decide; la decisión es suya.

https://netsenx.com/es/faq/what-counts-as-a-significant-incident-under-nis2

## ¿Hay que notificar según NIS2 un ataque fallido o bloqueado?

Normalmente no como incidente significativo, aunque puede serlo, y siempre puede notificarse de forma voluntaria. La obligación del artículo 23 se refiere a los incidentes significativos: los que causaron, o pudieron causar, una perturbación grave, pérdidas económicas o daños considerables a terceros. Un ataque detenido antes de tener efecto no suele cumplir ese criterio, pero uno que estuvo muy cerca, por ejemplo un ransomware detectado cuando ya había llegado al servidor de copias, puede cumplirlo. NIS2 distingue también los cuasiincidentes y las ciberamenazas significativas, y el artículo 30 permite notificarlos voluntariamente, lo que ayuda al CSIRT a avisar a otros. Anote cada caso así en su registro de incidentes con su razonamiento, para poder explicar después por qué notificó o no. NetSenX conserva las alertas que respaldan cada decisión.

https://netsenx.com/es/faq/is-a-blocked-attack-reportable-under-nis2

## ¿Cómo puede un equipo pequeño cumplir el plazo de 24 horas de la alerta temprana de NIS2?

Preparando de antemano todo lo que no depende del incidente. La alerta temprana del artículo 23, apartado 4, letra a), es breve: dice que se ha producido un incidente significativo y, en su caso, si se sospecha que se debe a actos ilícitos o malintencionados y si podría tener efectos transfronterizos. Los detalles llegan en la notificación a las 72 horas. Prepare, pues, una plantilla de una página, el canal de notificación y el acceso a su CSIRT o autoridad nacional, una persona designada y un suplente autorizados a enviarla, y una regla interna sobre quién decide que un incidente es significativo. Haga un ensayo al año. Los equipos pequeños pierden casi todo el tiempo averiguando qué pasó, así que asegúrese de que las alertas lleguen a alguien de noche y en fin de semana. NetSenX pone en marcha el reloj de plazos por incidente y guarda en un solo lugar las alertas con hora, equipos y destinos.

https://netsenx.com/es/faq/how-can-a-small-team-meet-the-nis2-24-hour-deadline

## ¿Qué debemos tener listo antes de que venza el plazo de 24 horas de NIS2?

Una breve lista de hechos, un canal preparado y una persona autorizada para enviarla. Para la alerta temprana en sí necesita: la hora en que tuvo conocimiento del incidente; una descripción sencilla de lo afectado hasta el momento; si sospecha un acto malintencionado o ilícito; y si podrían verse afectados otros países. Para la notificación de las 72 horas que sigue, empiece a reunir enseguida: gravedad e impacto, sistemas y servicios afectados, indicadores de compromiso como direcciones maliciosas o huellas de archivos, y las medidas adoptadas. Lleve desde el primer minuto una cronología de quién hizo qué. Compruebe si hay datos personales en juego, porque puede correr en paralelo una notificación del RGPD. NetSenX aporta la parte de red de esa cronología: la primera conexión inusual, los equipos implicados, los destinos y volúmenes, y los plazos del artículo 23 contados desde el momento de conocimiento que usted registra.

https://netsenx.com/es/faq/what-should-we-have-ready-before-the-nis2-24-hour-deadline

## ¿Tenemos que informar a nuestros propios clientes de un incidente NIS2?

A veces. Según el artículo 23, apartado 1, cuando proceda, las entidades incluidas notifican sin demora indebida a los destinatarios de sus servicios los incidentes significativos que puedan afectar negativamente a la prestación de esos servicios. Según el artículo 23, apartado 2, cuando sea aplicable, las entidades comunican además a los destinatarios potencialmente afectados por una ciberamenaza significativa las medidas que pueden adoptar y, cuando proceda, la propia amenaza. Las autoridades también pueden ordenar esa información. La ley nacional fija el detalle: en Alemania, el BSI puede ordenar informar a los destinatarios (artículo 35, apartado 1, de la BSIG), y las entidades de sectores como finanzas, infraestructura digital y gestión de servicios TIC deben informarles de ciberamenazas significativas (artículo 35, apartado 2). Los contratos y el RGPD pueden añadir obligaciones propias. Prepare una plantilla de mensaje para clientes dentro del plan de respuesta.

https://netsenx.com/es/faq/do-we-have-to-tell-customers-about-a-nis2-incident

## ¿Hay que notificar un ataque de ransomware según el RGPD?

A menudo sí, si hubo datos personales afectados, aunque no se robara nada. El RGPD define en su artículo 4, punto 12, la violación de la seguridad de los datos personales como toda violación de la seguridad que ocasione la destrucción, pérdida o alteración accidental o ilícita de datos personales, o la comunicación o acceso no autorizados a ellos. El cifrado por ransomware deja los datos no disponibles, lo que es una violación de la disponibilidad, y los atacantes suelen copiar los datos antes de cifrar. Según el artículo 33, el responsable notifica a la autoridad de control sin dilación indebida y, de ser posible, en las 72 horas siguientes a tener constancia, salvo que sea improbable que la violación suponga un riesgo para las personas, por ejemplo porque una copia reciente lo restauró todo rápido y nada salió de la red. Documente el razonamiento en ambos casos. NetSenX puede mostrar si antes del cifrado salieron subidas inusuales desde equipos vigilados, algo que importa para esa valoración.

https://netsenx.com/es/faq/do-we-have-to-report-ransomware-under-the-gdpr

## ¿Hay que notificar igualmente si los datos robados estaban cifrados?

Puede que a la autoridad, pero a menudo no a los afectados. El artículo 34, apartado 3, letra a), del RGPD exime de comunicarlo a las personas si el responsable había aplicado medidas, como el cifrado, que hagan los datos ininteligibles para quien no esté autorizado. La notificación a la autoridad de control del artículo 33 es una cuestión aparte: es necesaria salvo que sea improbable que la violación suponga un riesgo para las personas, y eso depende de la solidez del cifrado, de si también se expuso la clave y de si los datos siguen disponibles para usted. Si la clave estaba en el mismo portátil robado, o el cifrado era débil, trate los datos como expuestos. Anote qué datos estaban cifrados, cómo y dónde estaban las claves. Las pruebas de red sobre qué salió, y cuándo, ayudan a su delegado de protección de datos a decidir.

https://netsenx.com/es/faq/if-stolen-data-was-encrypted-must-we-still-notify

## ¿Podemos notificar por fases o tarde si no llegamos a la notificación del RGPD en 72 horas?

Sí, por fases, y tarde solo con motivos. El artículo 33, apartado 4, del RGPD permite facilitar la información de forma gradual, sin dilación indebida adicional, cuando no sea posible facilitarla toda a la vez, y el artículo 33, apartado 1, exige que una notificación hecha pasadas 72 horas vaya acompañada de los motivos del retraso. Así que no espere a tener el cuadro completo: envíe dentro del plazo una notificación inicial con lo que sepa, la naturaleza de la violación, las consecuencias probables, las medidas adoptadas y el contacto de su delegado de protección de datos, y complétela según vayan llegando los hechos. Deje constancia de cuándo tuvo conocimiento y de por qué alguna parte llegó después. Las autoridades suelen ofrecer formularios en línea que admiten ampliaciones, como la AEPD en España. NetSenX prepara una notificación del artículo 33 para su delegado de protección de datos a partir de los datos del incidente; presentarla le corresponde a usted.

https://netsenx.com/es/faq/we-cannot-meet-72-hours-can-we-notify-in-phases

## ¿Cuándo empieza a contar el plazo de 72 horas del RGPD?

Cuando el responsable tiene constancia de la violación de datos personales, no cuando esta empezó. El artículo 33, apartado 1, cuenta las 72 horas desde que se tiene constancia. Las directrices del Comité Europeo de Protección de Datos consideran que un responsable tiene constancia cuando sabe con un grado razonable de certeza que se ha producido un incidente de seguridad que ha comprometido datos personales. Se admite una breve investigación inicial para establecerlo, pero debe ser rápida; no se puede retrasar la constancia por no mirar. Un encargado que descubre una violación debe avisar al responsable sin dilación indebida (artículo 33, apartado 2), y el plazo del responsable suele empezar cuando se entera. Por eso anote en su registro de incidentes la hora exacta en que alguien concluyó que había datos personales afectados. NetSenX le permite registrar ese momento por incidente y conserva las alertas que muestran cuándo empezó la actividad.

https://netsenx.com/es/faq/when-does-the-gdpr-72-hour-clock-start

## ¿Cómo encajan NIS2, el RGPD y DORA cuando un incidente exige varias notificaciones?

Cada norma tiene su propia notificación, destinatario y plazo, y un mismo incidente puede activar varias. Un incidente significativo en una entidad incluida va al CSIRT o a la autoridad competente según el artículo 23 de NIS2; si afecta a datos personales, el responsable lo notifica además a la autoridad de protección de datos según el artículo 33 del RGPD; una entidad financiera notifica los incidentes graves relacionados con las TIC según el artículo 19 de DORA en lugar de NIS2; y un fabricante de productos puede tener obligaciones por el Reglamento de ciberresiliencia, véase el Reglamento (UE) 2024/2847, artículo 14. Algunos sistemas nacionales ofrecen un portal único, pero no dé por hecho que una notificación lo cubre todo. Lleve un solo expediente del incidente y genere cada notificación a partir de él, para que los hechos coincidan. El artículo 35 de NIS2 pide además a las autoridades NIS2 que informen a las de protección de datos de las violaciones que conozcan. NetSenX sigue los plazos de NIS2 y prepara un borrador de notificación del artículo 33 del RGPD con los mismos datos del incidente.

https://netsenx.com/es/faq/one-incident-several-reports-nis2-gdpr-dora

## ¿Qué es un incidente grave relacionado con las TIC según DORA?

Aquel que una entidad financiera clasifica como grave con los criterios del artículo 18 de DORA y las normas técnicas adoptadas conforme a él. El artículo 18 enumera criterios como el número y la relevancia de los clientes o contrapartes financieras afectados, el importe o número de operaciones afectadas, el impacto en la reputación, la duración y el tiempo de inactividad del servicio, la extensión geográfica, las pérdidas de datos que afectan a la disponibilidad, autenticidad, integridad o confidencialidad, la criticidad de los servicios afectados y el impacto económico. Las normas los convierten en umbrales. Solo hay que notificar los incidentes graves según el artículo 19; las ciberamenazas significativas pueden notificarse voluntariamente. Integre la clasificación en su procedimiento de incidentes, para que la decisión sea rápida, repetible y documentada, y acuerde con sus proveedores TIC cómo le facilitarán los hechos que necesita. Los clientes financieros esperarán lo mismo de sus proveedores.

https://netsenx.com/es/faq/what-is-a-major-ict-incident-under-dora

## ¿Cuáles son los plazos de notificación de incidentes de DORA?

Están en las normas técnicas adoptadas conforme al artículo 20 de DORA, no en el texto del reglamento, así que consulte esas normas y las indicaciones de su autoridad competente para las horas y días exactos. El artículo 19, apartado 4, fija la secuencia: una notificación inicial, un informe intermedio en cuanto la situación del incidente original haya cambiado de forma significativa o haya cambiado su gestión con nueva información, seguido de notificaciones actualizadas cuando proceda, y un informe final cuando se haya completado el análisis de la causa raíz. Las normas fijan también el contenido y las plantillas. Como los plazos están ligados a la detección del incidente y a su clasificación como grave, la rapidez de la clasificación importa tanto como la de redactar. Si es proveedor TIC de una entidad financiera, espere que su contrato le obligue a avisar al cliente con tiempo suficiente para que cumpla esos plazos.

https://netsenx.com/es/faq/what-are-the-dora-incident-reporting-deadlines

## ¿Dónde se presentan las notificaciones de vulnerabilidades del Reglamento de ciberresiliencia?

A través de la plataforma única de notificación que ENISA gestiona para el Reglamento de ciberresiliencia. Según el artículo 14 del Reglamento (UE) 2024/2847, los fabricantes de productos con elementos digitales notifican por esa plataforma las vulnerabilidades activamente explotadas de sus productos y los incidentes graves que afecten a su seguridad; la notificación llega al CSIRT designado como coordinador en el Estado miembro del establecimiento principal del fabricante y a ENISA. Para las etapas, plazos y contenidos, véase el Reglamento (UE) 2024/2847, artículo 14. Estas obligaciones afectan a los fabricantes, incluidas las empresas de software que comercializan productos en la UE, no a las empresas que solo usan los productos. Los usuarios pueden tener sus propias notificaciones de NIS2 o del RGPD tras el mismo suceso. Si desarrolla software, establezca un proceso de gestión de vulnerabilidades y decida quién accede a la plataforma antes de necesitarlo.

https://netsenx.com/es/faq/where-are-cra-vulnerability-reports-submitted

## ¿Debemos denunciar un incidente cibernético a la policía además de notificarlo al regulador?

A menudo sí, pero es una decisión distinta de las notificaciones regulatorias. Un ataque de ransomware, un robo de datos, un fraude o una extorsión suelen ser delitos, y una denuncia puede ayudar con la reclamación al seguro, con el banco que intenta recuperar una transferencia fraudulenta y con investigaciones que vinculan su caso con otros; algunas aseguradoras piden el número de denuncia. Denunciar a la policía no sustituye las notificaciones al CSIRT, a la autoridad competente o a la de protección de datos, y estas no sustituyen la denuncia. Muchos países tienen unidades especializadas en ciberdelincuencia o formularios en línea; en España, INCIBE ofrece además orientación a las empresas. Antes de denunciar, acuerde con sus abogados y su empresa de respuesta a incidentes qué pruebas entregar y cómo conservarlas, para no destruir lo que necesitan los investigadores. La alerta temprana de NIS2 ya pregunta si sospecha un acto ilícito o malintencionado; su respuesta y la denuncia deben ser coherentes.

https://netsenx.com/es/faq/should-we-report-a-cyber-incident-to-the-police

## ¿Qué información debe contener una notificación de incidente a las autoridades?

Lo básico es igual en todas partes: qué pasó, cuándo, qué se vio afectado, qué gravedad tiene, qué ha hecho y con quién contactar. Según el artículo 23, apartado 4, de NIS2, la alerta temprana indica si se sospecha un acto malintencionado o ilícito y si el incidente podría tener efectos transfronterizos; la notificación a las 72 horas añade una evaluación inicial de la gravedad y el impacto y, si se dispone de ellos, indicadores de compromiso; y el informe final añade una descripción detallada, el tipo de amenaza o la causa raíz, las medidas de mitigación y los efectos transfronterizos. Según el artículo 33, apartado 3, del RGPD, la notificación describe la naturaleza de la violación, las categorías y el número aproximado de personas y registros, las consecuencias probables, las medidas adoptadas y el contacto del delegado de protección de datos. Separe con claridad hechos y suposiciones. NetSenX aporta desde la red horas, equipos, destinos y volúmenes.

https://netsenx.com/es/faq/what-should-an-incident-report-contain

## ¿Hay que notificar un incidente que ya está resuelto?

Sí, si fue significativo o supuso una violación de datos personales que deba notificarse; solucionarlo no elimina la obligación. El artículo 23 de NIS2 vincula la obligación de notificar al incidente significativo, siga o no en curso, y los plazos corren desde que se tuvo conocimiento de él. Si solo ahora descubre que la caída del mes pasado fue un ataque, el reloj empieza con ese descubrimiento, y debe notificar con prontitud explicando la cronología. Según el RGPD, una violación que pueda suponer un riesgo para las personas debe notificarse aunque ya esté contenida; contenerla puede reducir el riesgo e influir en lo que escriba. Un incidente resuelto suele poder notificarse directamente con los hechos ya conocidos, pero siga el formato de su autoridad. Anote por separado las fechas en que ocurrió, en que tuvo conocimiento y en que se resolvió.

https://netsenx.com/es/faq/can-we-report-an-incident-that-is-already-resolved

## ¿Qué reduce una multa del RGPD tras una brecha de datos?

Sobre todo lo que hizo antes y después: notificar a tiempo, mitigar de verdad y cooperar. El artículo 83, apartado 2, del RGPD enumera los factores que valoran las autoridades, entre ellos la naturaleza, gravedad y duración de la infracción, su carácter intencionado o negligente, las medidas tomadas para paliar los daños a las personas, las medidas técnicas y organizativas ya aplicadas, las infracciones anteriores, el grado de cooperación con la autoridad, las categorías de datos afectadas y la forma en que la autoridad tuvo conocimiento de la infracción, en particular si usted la notificó. Para las infracciones más graves, las multas pueden llegar a 20 millones de euros o al 4 % del volumen de negocios anual mundial según el artículo 83, apartado 5. En la práctica: notificar a tiempo con hechos, demostrar las medidas de seguridad existentes, contener la brecha rápido, informar a los afectados cuando proceda y documentar cada paso. NetSenX ayuda con la cronología y con un borrador del artículo 33 para su delegado de protección de datos.

https://netsenx.com/es/faq/what-reduces-a-gdpr-fine-after-a-data-breach

## ¿Puede NetSenX preparar una notificación de brecha del artículo 33 del RGPD?

Sí, como borrador para su delegado de protección de datos; decidir y presentarla le corresponde a usted. Con los datos del incidente, NetSenX prepara un borrador con lo que muestra la red: cuándo se detectó el problema y qué equipos y destinos intervinieron. El artículo 33, apartado 3, pide además información que solo usted tiene, como las categorías y el número aproximado de personas y registros afectados, las consecuencias probables, las medidas adoptadas y los datos de contacto del delegado. Las pruebas de red tienen límites: NetSenX ve conexiones, volúmenes y destinos, no qué archivos o registros salieron, así que el delegado debe completar el contenido con otras fuentes. El borrador ahorra tiempo el viernes por la noche, cuando corre el plazo de 72 horas, y mantiene los hechos coherentes con sus notificaciones de NIS2. Revíselo, complételo y preséntelo usted mismo ante su autoridad de control.

https://netsenx.com/es/faq/can-netsenx-prepare-a-gdpr-article-33-notification

## ¿Ayuda el registro de auditoría de una herramienta de seguridad con los controles generales de TI?

Sí, en la parte de los controles que afecta a la propia herramienta. Los auditores de cuentas y los auditores de ISO o SOC 2 prueban los controles generales de TI: quién tiene acceso a los sistemas, cómo se aprueban y registran los cambios y cómo se vigilan la operación y los incidentes. El registro de auditoría de una herramienta de seguridad aporta pruebas de su propia parte: quién tiene cuentas, quién cambió los ajustes de detección o las reglas de aviso, quién cerró o decidió cada alerta, y cuándo. En todos los planes, NetSenX lleva ese registro de auditoría, con una conservación que crece con el plan. No registra cambios en su ERP, sus servidores de archivos u otros sistemas, que necesitan sus propios registros. Exporte el extracto del periodo auditado y combínelo con sus revisiones de accesos y tickets de cambio, para que el auditor vea un relato coherente.

https://netsenx.com/es/faq/does-a-security-tools-audit-log-help-with-it-general-controls

## ¿Cómo demostramos quién cambió un ajuste de seguridad y cuándo?

Con un registro de auditoría que anote cada cambio, quién lo hizo y cuándo, guardado donde no pueda editarse en silencio. En sus propios sistemas, eso significa activar el registro de cambios en cortafuegos, servicios de directorio, consolas en la nube y herramientas de seguridad, enviar los registros a un lugar central con acceso restringido y vincular los cambios a tickets aprobados. Las cuentas de administrador compartidas hacen imposible la prueba, así que dé a cada persona su propia cuenta nominativa con autenticación multifactor. Revise los registros en busca de cambios inesperados, sobre todo fuera del horario laboral. En el propio NetSenX, el registro de auditoría de todos los planes anota quién cambió ajustes de detección, reglas de aviso o miembros del equipo y quién decidió sobre las alertas, con marca de tiempo; puede exportar el extracto para un auditor. Cubre los cambios hechos en NetSenX, no los ajustes de sus otros sistemas.

https://netsenx.com/es/faq/how-do-we-prove-who-changed-a-security-setting

## ¿Cómo mostramos a un auditor qué partes de la red se vigilan?

Con una declaración de cobertura sencilla respaldada por pruebas, incluidos los huecos. Enumere cada sede y segmento de red, si lo vigila un sensor o un agente, desde cuándo y qué cubre; después indique lo que no se vigila, como el wifi de invitados, una delegación o un entorno en la nube, y cómo lo gestiona de otra forma. Adjunte pruebas: la lista de sensores, una alerta reciente de cada segmento vigilado y el mapa de red. Los auditores confían más en una declaración honesta con huecos conocidos que en una afirmación de cobertura total que se cae a la primera pregunta. En NetSenX, un agente en el puerto espejo de un switch (SPAN) o en un TAP de red vigila todo un segmento, y el panel muestra qué agentes funcionan dónde; el tráfico de un segmento que no se replica queda fuera de la vista, y NetSenX no finge lo contrario.

https://netsenx.com/es/faq/how-do-we-show-an-auditor-which-parts-of-the-network-are-monitored

## ¿Qué se pierde la detección de red si un segmento no se replica?

Todo lo que ocurre solo dentro de ese segmento. Un sensor ve el tráfico que recibe; si un puerto del switch no se replica hacia él y no hay agente en los equipos de ese segmento, las conexiones entre dispositivos del segmento, como un atacante que pasa de un PC al servidor de archivos de al lado, quedan invisibles. Puede que siga viendo el tráfico que sale del segmento por un punto vigilado, hacia internet u otra sede, pero los pasos internos de una intrusión suelen ser justo lo que necesita ver. Decida según el riesgo: replique primero los segmentos con servidores, administración, finanzas, RR. HH. y producción, y después el resto. Donde replicar no sea práctico, ejecute el agente en los propios equipos importantes. NetSenX muestra qué segmentos vigilan sus sensores y agentes, para que los huecos se vean.

https://netsenx.com/es/faq/what-does-network-detection-miss-if-a-segment-is-not-mirrored

## ¿Qué debe contener un registro de incidentes para una auditoría de NIS2?

Lo suficiente para reconstruir cada incidente y cada decisión sin depender de la memoria de nadie. En cada entrada: una referencia única; cuándo empezó el incidente, cuándo y con qué se detectó, y cuándo se calificó como significativo o no; una breve descripción y los sistemas, servicios y datos afectados; la valoración de la gravedad y quién la hizo; si se notificó, a quién y a qué horas, con copia de las notificaciones; los pasos de contención, erradicación y recuperación con horas y responsables; la causa raíz; y las lecciones y cambios posteriores. Registre también los cuasiincidentes, con el motivo por el que no se notificaron. Mantenga el registro protegido frente a manipulaciones y con acceso controlado. NetSenX aporta automáticamente la parte de red: alertas con hora, equipos y destinos, plazos NIS2 por incidente y el registro de auditoría de quién decidió qué.

https://netsenx.com/es/faq/what-should-an-incident-log-contain-for-a-nis2-audit

## ¿Cómo mostramos a un auditor qué decidimos en cada alerta de seguridad?

Con un registro que vincule cada alerta a una decisión, una persona, una hora y un motivo. Los auditores quieren ver que las alertas no desaparecen: cada una se revisó, se clasificó como inofensiva, en investigación o incidente, y se cerró con una explicación. Una hoja de cálculo sirve para unas pocas alertas, pero falla al crecer el volumen y es fácil rellenarla a posteriori. Use, siempre que pueda, el flujo de la propia herramienta, escriba motivos breves en lugar de estados de una palabra y revise cada trimestre una muestra de alertas cerradas para comprobar la calidad de las decisiones. En NetSenX, las decisiones de los analistas sobre las alertas quedan en el registro de auditoría en todos los planes, con quién decidió y cuándo; desde el plan Starter puede exportar informes PDF para el auditor.

https://netsenx.com/es/faq/how-do-we-show-an-auditor-what-we-decided-on-each-alert

## ¿Cuánto tiempo hay que conservar los registros de incidentes de seguridad?

NIS2 no fija un plazo único, así que decídalo usted y deje escrito el motivo. Varias normas apuntan en la misma dirección. El RGPD obliga a documentar toda violación de datos personales (artículo 33, apartado 5) para que la autoridad pueda verificar el cumplimiento, lo que implica conservar el registro mientras esa comprobación pueda razonablemente llegar. Los supervisores de NIS2 pueden pedir pruebas de incidentes y notificaciones pasados, las aseguradoras pueden examinar un siniestro mucho después y los plazos de prescripción de las acciones contractuales y de responsabilidad duran años en muchos países. Las normas sectoriales y nacionales pueden fijar plazos propios. Un enfoque habitual es guardar varios años el registro de incidentes y las notificaciones, y menos tiempo los registros en bruto, borrando los datos personales que ya no hagan falta. La conservación del historial de alertas y del registro de auditoría de NetSenX depende del plan; exporte lo que deba guardar más tiempo.

https://netsenx.com/es/faq/how-long-must-we-keep-security-incident-records

## ¿Se puede generar automáticamente un mapa de red a partir del tráfico para un auditor?

Sí, de los segmentos vigilados, y suele ser más exacto que un diagrama dibujado. Un mapa construido con el tráfico observado muestra qué equipos existen, los nombres que anuncian y quién habla con quién, incluidas conexiones que nadie documentó, como un puesto que llega a un servidor al que no debería o la sesión remota de un proveedor. No muestra lo que nunca envía tráfico, los segmentos sin sensor ni el diseño previsto, así que conserve su diagrama de arquitectura y compruébelo con el mapa observado. En todos los planes, NetSenX construye ese mapa de red con el tráfico vigilado, con la primera y la última vez que se vio cada equipo. Antes de enseñarlo a un auditor externo, piense en lo que revela: los nombres de equipos pueden incluir nombres de empleados y el mapa describe su estructura interna, así que muéstrelo en pantalla o con un acuerdo de confidencialidad.

https://netsenx.com/es/faq/can-a-network-map-be-generated-automatically-for-an-auditor

## ¿Hay que documentar las brechas de datos que decidimos no notificar?

Sí. El artículo 33, apartado 5, del RGPD obliga al responsable a documentar toda violación de la seguridad de los datos personales, incluidos los hechos, sus efectos y las medidas correctivas adoptadas, se haya notificado o no a la autoridad de control. El objetivo es que la autoridad pueda verificar después el cumplimiento, incluida su decisión de que una violación no suponía probablemente un riesgo para las personas. Así que, para cada violación, anote qué pasó, qué datos y personas se vieron afectados, por qué concluyó que había que notificar o no, quién lo decidió y cuándo, y qué cambió. Llévelo en un registro de violaciones separado del registro de incidentes de seguridad pero vinculado a él. Las autoridades pueden pedirlo en una inspección o tras una reclamación, y la falta de registro de una brecha no notificada queda peor que la propia brecha. NetSenX conserva las pruebas de alertas de cada entrada durante el plazo de su plan.

https://netsenx.com/es/faq/must-we-document-data-breaches-we-do-not-report

## ¿Cuándo hay que comunicar una brecha de datos a las personas afectadas?

Cuando sea probable que la violación entrañe un alto riesgo para sus derechos y libertades. El artículo 34 del RGPD obliga entonces al responsable a comunicárselo sin dilación indebida, en un lenguaje claro y sencillo, describiendo la naturaleza de la violación, las consecuencias probables, las medidas adoptadas o propuestas y el contacto del delegado de protección de datos. Alto riesgo suele significar datos que pueden causar un daño real, como documentos de identidad, datos bancarios o de salud, contraseñas o información que permita fraudes. El artículo 34, apartado 3, prevé excepciones: los datos se hicieron ininteligibles, por ejemplo con un cifrado sólido; medidas posteriores hacen improbable que se materialice el alto riesgo; o las comunicaciones individuales supondrían un esfuerzo desproporcionado, en cuyo caso se opta por una comunicación pública. La autoridad de control también puede exigir que se informe. Indique a las personas qué hacer, como cambiar contraseñas o desconfiar de mensajes de phishing.

https://netsenx.com/es/faq/when-must-we-tell-affected-people-about-a-data-breach

Información general, no asesoramiento jurídico. Las leyes nacionales pueden completar los textos de la UE citados aquí, por ejemplo con plazos, formularios o canales de notificación: consulte las normas de su país.

FAQ: https://netsenx.com/es/faq