Cyber Resilience Act · 2026/2027

Respuesta a incidentes de la CRA: propietarios, plazos y evidencia de presentación de informes

Autor: Piotr AdamskiRevisión operativa y de seguridad: Brillnet C-Team

Contenido informativo. No sustituye asesoramiento jurídico individual ni evaluación de conformidad.

Comprueba el ámbito CRA y descarga tu evaluación

Desde el 11 de septiembre de 2026, los fabricantes incluidos en CRA deben notificar vulnerabilidades explotadas activamente e incidentes graves que afecten a la seguridad de productos con elementos digitales. La alerta temprana vence en 24 horas desde tomar conocimiento y la notificación completa en 72 horas.

El principal riesgo operativo no es la falta de formulario. Es no tener T0 acordado, responsable de decisión, cobertura de sustitución, fuentes fiables y registro que explique la clasificación del evento.

Calendario de notificación

Etapa Plazo Qué controlar
Toma de conocimiento T0 marca de tiempo, fuente y persona que recibe
Alerta temprana en 24 h información exigida por CRA/SRP en esta etapa
Notificación completa en 72 h información adicional de evento e impacto
Informe final: vulnerabilidad explotada activamente como máximo 14 días tras disponer de una medida correctora corrección y resultado de la gestión
Informe final: incidente grave en 1 mes desde la notificación de 72 horas evolución, impacto, acciones y resultado

Verifica siempre las instrucciones actuales de la plataforma única CRA. Orientaciones operativas y portal pueden evolucionar más rápido que el propio reglamento.

No toda vulnerabilidad activa notificación del artículo 14

CRA se refiere a una vulnerabilidad explotada activamente, no a cada hallazgo de un escáner. «Incidente grave» también es concepto normativo, no sinónimo de cualquier solicitud de seguridad marcada como prioritaria.

Un buen flujo separa:

  1. detección o recepción de información;
  2. triaje técnico;
  3. evaluación de criterios normativos;
  4. decisión de una persona responsable;
  5. preparación de notificación;
  6. presentación por el canal adecuado;
  7. corrección, seguimiento e informe final.

Etiquetar automáticamente un hallazgo «notificable CRA» sin aprobación humana crea riesgos de falsos positivos y de notificaciones omitidas.

Define responsabilidades antes de empezar la cuenta

Una función llamada «Equipo de seguridad» no basta. Para cada producto, identifica:

  • quién recibe información de vulnerabilidades o incidentes;
  • quién realiza triaje técnico;
  • responsable del producto;
  • quién aprueba la clasificación normativa;
  • quién presenta mediante SRP;
  • sustituto de cada función con plazos críticos;
  • vía de escalado fuera de horario exigida por producto y modelo operativo.

Si alguien acumula funciones, regístralo expresamente. Un equipo pequeño puede funcionar; una responsabilidad ambigua no.

Qué registrar en T0

Crea el primer registro antes de que la conversación se centre en si el evento es «realmente grave». Conserva al menos:

  • momento exacto de toma de conocimiento;
  • fuente de información;
  • producto y versión;
  • comunicante o sistema de detección;
  • descripción breve de lo observado;
  • persona que recibió la información;
  • vínculo al artefacto de origen o evidencia.

Sin ese registro, horas después la organización puede no determinar cuándo empezó realmente el plazo legal.

Secuencia operativa práctica

1. Registrar

Abre un caso y conserva el informe original. No sobrescribas la fuente mientras evoluciona la comprensión.

2. Hacer triaje

Confirma producto afectado, versión, ámbito técnico, efectos conocidos y evidencias. Separa hechos confirmados de hipótesis.

3. Clasificar

Registra motivos a favor y en contra de notificar. La decisión identifica aprobador y hora de aprobación.

4. Presentar la alerta de 24 horas

Prepárala con la información disponible en ese momento. No esperes a terminar la causa raíz cuando el plazo legal ya corre.

5. Presentar la notificación de 72 horas

Completa la información exigida por el proceso SRP actual.

6. Corregir y comunicar

Conecta ingeniería, versiones, actualizaciones de seguridad y comunicación al cliente con el mismo caso.

7. Completar el informe final

Cierra solo cuando se hayan registrado resultado, acciones, evidencias de verificación e informe final exigido.

Ensaya antes de un evento real

Utiliza un escenario realista pero hipotético y verifica:

  • que el equipo sabe dónde crear el registro;
  • que puede identificarse T0;
  • que se conoce a quien aprueba;
  • que hay sustitución;
  • que datos del producto y registros técnicos pueden recogerse rápido;
  • que quien presenta tiene acceso SRP funcional;
  • que el ejercicio deja decisión registrada y acciones de mejora.

El papel de Pulsar GRC

Pulsar conecta incidente o vulnerabilidad con riesgos, acciones, responsables, documentos, evidencias, informes e historial. Riesgos, tareas, documentos, evidencias e informes conservan el contexto de respuestas y decisiones.

Tu organización evalúa si se aplica el artículo 14, aprueba la notificación y la presenta en SRP por el canal adecuado. Preparar registros en Pulsar no sustituye presentar la notificación.

Consulta Pulsar GRC en un flujo operativo

Orientaciones relacionadas

Ejercicio propuesto: un aviso llega cuando la persona responsable no está disponible

Imagina un fabricante de un dispositivo de control con una aplicación asociada. El viernes, un investigador envía información sobre un posible acceso no autorizado. El mensaje llega a una dirección publicada, pero la persona que suele revisarla está de vacaciones. Ingeniería lo descubre el lunes. Este supuesto sirve para probar la recepción y la sustitución; no describe un caso real ni determina por sí mismo si existe obligación de notificar.

La primera pregunta del ejercicio es quién recibió la información y cuándo. Conserva la hora del mensaje y los registros de recepción, sin confundirlos automáticamente con el momento jurídico de toma de conocimiento. La evaluación de ese momento debe quedar razonada por una persona competente. Si el equipo solo guarda la hora de creación del ticket, pierde información que puede cambiar el cálculo del plazo. Registra las horas en una zona horaria común e identifica también la fuente original.

Después, el sustituto confirma el producto y la versión afectados. Si el aviso menciona una biblioteca utilizada en cinco productos, abre una evaluación por cada familia pertinente y vincúlalas al aviso común. Una vulnerabilidad puede ser explotable en un producto y quedar fuera del flujo ejecutable de otro. Esa diferencia exige fundamento técnico; no basta copiar la conclusión del primer producto. Conserva pruebas, condiciones de reproducción y limitaciones del análisis.

El ejercicio termina cuando otra persona puede reconstruir el recorrido sin entrevistar a quienes participaron. Debe encontrar recepción, evaluación, decisión, comunicaciones, medidas correctoras y evidencias de presentación cuando proceda. La rapidez importa, pero una respuesta veloz sin registro tampoco es una respuesta repetible.

Los plazos legales descritos arriba son máximos que deben gestionarse conforme al reglamento. Un equipo puede fijar objetivos internos más breves para conservar margen: confirmar recepción, reunir a las funciones responsables y resolver dudas sobre el canal. Estos objetivos son decisiones organizativas propuestas, no nuevos plazos CRA. Escríbelos en el procedimiento con esa distinción visible.

Evita una regla interna que diga «esperamos hasta disponer de toda la información». Durante un evento, algunos hechos seguirán pendientes. El formulario debe distinguir información confirmada, estimaciones y preguntas abiertas. Quien aprueba verifica que no se presentan hipótesis como certezas y que la falta de una respuesta no bloquea una comunicación exigida. Define quién puede corregir o ampliar información ya enviada y cómo queda registrada esa actualización.

El mismo principio afecta al vocabulario. «Vulnerabilidad crítica» puede ser una prioridad técnica; «explotada activamente» exige una evaluación diferente. El equipo debe conservar la evidencia que respalda cada término. Una puntuación de severidad, por sí sola, no demuestra explotación. Un rumor en redes tampoco equivale a una confirmación. Documentar lo que todavía no se sabe evita que una conversación de urgencia termine convertida en una declaración jurídica incorrecta.

Prepara un expediente que pueda utilizar el sustituto

Para cada producto, conserva una ficha de contacto con nombre del fabricante, identificación del producto, personas autorizadas para decidir y presentar, canales técnicos y responsables de comunicación. La ficha debe tener fecha de verificación. Comprueba la accesibilidad del canal oficial mediante una prueba permitida y sin enviar una notificación ficticia a producción. Un usuario creado hace seis meses no prueba que hoy pueda presentar un informe.

Prepara además una lista de documentos necesarios: descripción del producto, versiones soportadas, contexto de uso, contactos de ingeniería, política de vulnerabilidades y procedimientos de publicación. La lista enlaza fuentes existentes; no obliga a duplicar todos los archivos. Para información sensible, utiliza acceso restringido y una versión de comunicación revisada. Los detalles que permiten explotar un fallo no deben acabar en un correo comercial o en una carpeta compartida con clientes ajenos.

Conviene separar también la comunicación con usuarios de la notificación regulatoria. Pueden requerir responsables, contenido y canales distintos. Mantén ambos flujos ligados al mismo caso para detectar contradicciones, pero no supongas que enviar un aviso al cliente satisface la presentación oficial. Guarda qué se comunicó, a quién, por qué medio y cuándo. Las comunicaciones posteriores deben indicar su relación con las anteriores.

Criterios de aceptación del procedimiento

Una revisión útil comprueba cinco situaciones diferentes. Primero, llega información incompleta y el receptor sabe dónde registrarla. Segundo, el responsable titular no está disponible y el sustituto actúa. Tercero, ingeniería modifica su evaluación inicial y la decisión se actualiza con fundamento. Cuarto, el portal o un canal tiene un problema y el equipo conserva pruebas de los intentos y consulta la vía oficial pertinente. Quinto, la corrección técnica está disponible pero el expediente aún requiere seguimiento.

No des por cerrado el ejercicio al mostrar un procedimiento aprobado. Pide a una persona que no lo redactó localizar el caso, explicar la secuencia y señalar la próxima acción. Si necesita instrucciones verbales adicionales, convierte esa dependencia en una mejora documentada. Asigna responsable y plazo a cada carencia detectada. El objetivo es encontrar errores antes del evento real, no obtener una puntuación cómoda en una simulación.

Control de calidad de la asistencia de IA

La IA puede ayudar a ordenar una cronología o preparar un borrador a partir de fuentes aportadas. La persona que revisa debe comprobar especialmente producto, versión, horas, clasificación y destinatarios. Una inferencia redactada con seguridad sigue siendo una inferencia. No autorices a un borrador a decidir el momento de toma de conocimiento, declarar explotación activa ni presentar información externamente sin aprobación.

Conserva el borrador y la versión aprobada cuando ayuden a explicar cambios materiales. El registro de aprobación indica quién contrastó las fuentes y qué información faltaba. Pulsar puede apoyar ese trabajo documental; el fabricante mantiene la responsabilidad de evaluar y presentar por el canal oficial. Esta separación evita atribuir al software una actuación que debe realizar una persona autorizada.

Ensayar un incidente sin realizar una presentación real

Elija un producto ficticio que su ejercicio asuma que está dentro del alcance de la CRA. Si el ejemplo incluye SaaS o un backend, documente por qué es relevante para ese producto; no asuma que todos los servicios exclusivos del navegador están incluidos en la CRA. Utilice una notificación sintética recibida fuera del horario de oficina, un hallazgo técnico y una decisión que necesita un revisor autorizado.

Registre cuándo los participantes del ejercicio toman conocimiento de los hechos y distinga ese momento de la apertura de un ticket. Designar al investigador, titular de la decisión y sustituto. Realice un seguimiento de qué hechos se establecen y cuáles permanecen bajo revisión. Los plazos del Artículo 14 se relacionan con las condiciones aplicables de conocimiento e información, no simplemente con el momento en que un gerente abre la solicitud.

Mantenga la rama de vulnerabilidad explotada activamente separada de la rama de incidentes graves. Las condiciones de su informe final difieren: el informe de vulnerabilidad incluye una fecha límite vinculada a la disponibilidad de una medida correctiva o mitigadora, mientras que la rama de incidentes graves tiene su propio cronograma de informe final. Utilice el texto legal actual y la guía de informes oficiales para el supuesto identificado.

En Pulsar se elaboran las acciones de ejercicio, titulares, plazos y pruebas sintéticas. Registre la decisión del revisor y cualquier información faltante. Verifique el estado final después de guardar. El resultado útil es un ensayo documentado que expone un sustituto faltante o un requisito de evidencia antes de que ocurra un evento real.

No envíe un ejercicio a ENISA, a un CSIRT o a un cliente real. El registro de Pulsar no es un recibo de presentación oficial y la prueba pública no promete informes automáticos a las autoridades. Mantener un envío real, su canal oficial y su recepción como acciones separadas en un incidente real. Revise el método de pago y los términos de cancelación de la prueba de 14 días antes de registrarse.

Fuentes

CRA para SaaS: alcance, acciones propias y evidencia

Vulnerabilidades de los componentes de IoT: proveedores, decisiones y soluciones

KSC/NIS2 polaco para proveedores de TI: evaluación y registro de acciones