--- title: "Notificación del Cyber Resilience Act: guía operativa de 24 y 72 horas" canonical: https://wavect.io/es/blog/cyber-resilience-act-reporting-playbook-2026/ language: es description: "Notificaciones CRA: plazos de 24/72 horas, informes finales distintos para vulnerabilidades e incidentes graves, responsables y pruebas de envío." image: "https://wavect.io/img/blog/headers/header_cyber-resilience-act-reporting-playbook-2026.png" author: ["Kevin Riedl"] published: "2026-08-24" updated: "2026-10-05" reviewed: "2026-10-05" --- # Notificación del Cyber Resilience Act: guía operativa de 24 y 72 horas [**Volver**](/es/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/es/team/kevin-riedl/) [Kevin Riedl](/es/team/kevin-riedl/) https://linkedin.com/in/wsdt 9 min de lectura · 24 de agosto de 2026 Última revisión 5 de octubre de 2026 [**Siguiente**](/es/blog/eu-battery-passport-software-architecture-2027/) Resumen A 5 de octubre de 2026, las obligaciones de notificación del CRA para fabricantes ya se aplican. Las vulnerabilidades explotadas activamente y los incidentes graves exigen una alerta en 24 horas y una notificación en 72 horas desde que se tiene conocimiento. El informe final vence 14 días después de estar disponible una medida correctora para vulnerabilidades, pero un mes después de la notificación de 72 horas para incidentes graves. **A 5 de octubre de 2026, las obligaciones de notificación del CRA para fabricantes ya se aplican. Las vulnerabilidades explotadas activamente y los incidentes graves exigen una alerta en 24 horas y una notificación en 72 horas desde que se tiene conocimiento. El informe final vence 14 días después de estar disponible una medida correctora para vulnerabilidades, pero un mes después de la notificación de 72 horas para incidentes graves.** Las obligaciones de los fabricantes se aplican desde el 11 de septiembre de 2026. Esta guía técnica las convierte en un proceso operativo, no en un proyecto para un plazo futuro. No es asesoramiento jurídico: verifica el ámbito del producto, el papel del operador económico y el supuesto notificable con profesionales cualificados. Las recomendaciones de implementación no son obligaciones legales adicionales. ## ¿Qué plazo corresponde a cada notificación? | Etapa | Inicio y plazo | Evidencia operativa | | --- | --- | --- | | **Alerta temprana: ambas categorías** | Dentro de las 24 horas desde que se tiene conocimiento | Conservar el momento de conocimiento, categoría, hechos iniciales y justificante. | | **Notificación: ambas categorías** | Dentro de las 72 horas desde el conocimiento, no desde la alerta temprana | Añadir productos afectados, evaluación y medidas disponibles. | | **Final: vulnerabilidad explotada activamente** | Como máximo 14 días después de estar disponible una medida correctora | Registrar la disponibilidad de la medida, la corrección y el envío final. | | **Final: incidente grave** | Dentro de un mes desde la notificación de 72 horas | Conservar ese envío, el vencimiento por mes natural y la evaluación final. | ## ¿Quién controla el conocimiento y la escalada? Asigna una persona responsable del incidente y una suplencia disponible. No retrases artificialmente el conocimiento hasta la aprobación de un ticket o la publicación de un CVE. Registra qué se sabía, quién lo sabía y cuándo; escala las dudas sobre el supuesto legal sin esperar una atribución perfecta. - Unifica los avisos de investigadores, clientes, proveedores, CSIRT y monitorización. - Distingue primera observación, conocimiento de la organización, escalada interna y cada envío externo. Guarda fechas UTC y sus evidencias. - Evalúa por separado el ámbito y el supuesto: un hallazgo del escáner no equivale automáticamente a explotación activa o incidente grave. Documenta decisión y responsable. ## ¿Qué debe contener el registro del incidente? Usa un identificador duradero para todas las etapas. Separa hechos confirmados de hipótesis y asigna un responsable a cada incertidumbre relevante. Este esquema es un control técnico recomendado, no una afirmación de que todos los campos sean obligatorios en el formulario externo. - Registra producto y versión afectados, papel del fabricante, países, categoría, indicios de explotación o gravedad, conocimiento y los dos plazos iniciales. - Para vulnerabilidades, registra la disponibilidad de la medida correctora. Para incidentes graves, el momento de la notificación de 72 horas. Calcula el plazo final desde el campo correspondiente. - Conserva evidencias, revisiones de evaluación, responsables, decisiones de mitigación y despliegue, comunicaciones, contenido enviado y justificantes. - Limita detalles sensibles de explotación y datos personales. Define accesos, conservación proporcionada y una vista depurada para colaborar. ## ¿Dónde se notifica y cómo se ensaya? La Single Reporting Platform de ENISA está operativa desde el 11 de septiembre de 2026. Usa las instrucciones oficiales de acceso y uso, sin presuponer una API pública de envío. Prepara ya accesos autorizados y suplencias; separa el registro interno del formulario externo. - Comprueba acceso, responsabilidades y ruta CSIRT aplicable con las instrucciones oficiales. - Ensaya internamente dos casos: vulnerabilidad explotada e incidente grave. No envíes incidentes ficticios al canal real de notificación. - Prueba cobertura de fines de semana y ausencias, pérdida de acceso, retrasos de proveedores y conservación de justificantes. ## Comprobaciones operativas para completar ahora 1. Confirma productos incluidos, responsabilidades del fabricante, responsable del incidente y suplencia. 2. Verifica el acceso oficial y conserva instrucciones actualizadas en el procedimiento de incidentes. 3. Implementa el momento de conocimiento y controles separados de 24 horas, 72 horas y cierre por categoría. 4. Conecta la recepción con inventario, versiones y correcciones; prueba permisos y recuperación de evidencias. 5. Ensaya ambas categorías, cierra las carencias y programa ejercicios periódicos. Un proyecto de mejora no suspende los plazos de notificación. ## Preguntas sobre notificaciones CRA ### ¿Ya se aplican las obligaciones de los fabricantes? Sí, desde el 11 de septiembre de 2026. Revisamos esta página el 5 de octubre de 2026; ya no es una guía de preparación para un plazo futuro. ### ¿Las 24 y 72 horas se cuentan consecutivamente? No. Ambos plazos parten del conocimiento. La notificación vence a las 72 horas desde ese momento, no 72 horas después de la alerta temprana. ### ¿Todos los informes finales vencen en 14 días? No. Esa regla corresponde a vulnerabilidades explotadas activamente desde la disponibilidad de una medida correctora. Para incidentes graves es un mes desde la notificación de 72 horas. ### ¿Los administradores de software de código abierto tienen la misma fecha? No. La Comisión indica el 11 de diciembre de 2027 para sus obligaciones del artículo 24.3. No confundas ese papel con un fabricante por el mero hecho de incluir software de código abierto. ### ¿La alerta temprana necesita un análisis de causa raíz terminado? No. Conserva los hechos disponibles, identifica incertidumbres y amplía la notificación en las etapas posteriores. Buscar pruebas completas no debe bloquear una escalada oportuna. ### ¿Esta guía certifica el cumplimiento legal? No. Describe una implementación técnica. El ámbito, papel, clasificación del incidente y obligaciones concretas siguen necesitando una evaluación jurídica adecuada. ## Reflexiones finales La prioridad es ejecutar con fiabilidad: un registro de evidencias, responsabilidad con suplencia y reglas de cierre distintas por categoría. Conecta notificación, corrección y comunicación al cliente sin esperar un análisis retrospectivo perfecto. ## Fuentes primarias 1. [Comisión Europea: obligaciones de notificación CRA](https://digital-strategy.ec.europa.eu/en/policies/cra-reporting). Fechas de fabricantes y administradores; categorías y plazos 2. [ENISA: Single Reporting Platform](https://www.enisa.europa.eu/topics/product-security/vulnerability-services/eu-incident-response-and-cyber-crisis-management/single-reporting-platform-srp). Acceso oficial, instrucciones y recursos de notificación 3. [Comisión Europea: orientaciones de aplicación del CRA](https://digital-strategy.ec.europa.eu/en/library/commission-publishes-new-guidance-support-timely-cyber-resilience-act-implementation). Ámbito y aplicación; consultar la sección vigente de notificación ## También te puede gustar.. [**Benchmark de mantenimiento de software** Planifica capacidad para seguridad, dependencias, observabilidad y soporte.](/es/blog/software-maintenance-cost-benchmark-dach-saas/) [**Wavect frente a agencias** Compara modelos para ingeniería crítica de cumplimiento.](/es/compare/wavect-vs-dev-agencies/) Gobernanza y regulación de IA ## Qué leer después Seguridad, políticas, cumplimiento y controles para una adopción responsable. [Empieza aquí**Coste del EU AI Act para startups: alcance antes que presupuesto**](/es/blog/eu-ai-act-compliance-cost-startup/) - [Responsabilidad por software: checklist de evidencia](/es/blog/eu-product-liability-software-evidence-2026/) - [AI Bill of Materials: CycloneDX frente a SPDX](/es/blog/ai-bill-of-materials-cyclonedx-spdx-2026/) - [Pasarelas de seudonimización para LLM: ¿el prompt sale del ámbito del RGPD?](/es/blog/llm-pseudonymization-gateway-gdpr-2026/) - [Análisis de Semantica 2026: ¿Puede explicar cada decisión de un agente de IA?](/es/blog/semantica-ai-agent-decision-provenance/) - [Firma de Contratos con Agentes de IA: Guía QES eIDAS](/es/blog/ai-agent-eidas-signature-integration/) [Artículo siguiente**Responsabilidad por software: checklist de evidencia**](/es/blog/eu-product-liability-software-evidence-2026/) [**Volver**](/es/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/es/team/kevin-riedl/) [Kevin Riedl](/es/team/kevin-riedl/) https://linkedin.com/in/wsdt 9 min de lectura · 24 de agosto de 2026 Última revisión 5 de octubre de 2026 [**Siguiente**](/es/blog/eu-battery-passport-software-architecture-2027/)