{"id":1938,"date":"2026-03-25T16:58:01","date_gmt":"2026-03-25T15:58:01","guid":{"rendered":"https:\/\/regulated-devsecops.com\/uncategorized\/nis2-notificacion-de-incidentes-requisitos-de-evidencia-en-pipelines\/"},"modified":"2026-03-26T09:24:07","modified_gmt":"2026-03-26T08:24:07","slug":"nis2-incident-reporting-pipeline-evidence-requirements","status":"publish","type":"post","link":"https:\/\/regulated-devsecops.com\/es\/audit-evidence-es\/nis2-incident-reporting-pipeline-evidence-requirements\/","title":{"rendered":"NIS2 Notificaci\u00f3n de Incidentes \u2014 Requisitos de Evidencia en Pipelines"},"content":{"rendered":"<h2>NIS2 Art\u00edculo 23: Descripci\u00f3n general de los requisitos de notificaci\u00f3n de incidentes<\/h2>\n<p>El Art\u00edculo 23 de NIS2 impone estrictas obligaciones de notificaci\u00f3n de incidentes a las entidades esenciales e importantes. Las organizaciones deben reportar los incidentes significativos a su CSIRT nacional o autoridad competente dentro de plazos estrictos:<\/p>\n<ul>\n<li><strong>Alerta temprana:<\/strong> En un plazo de <strong>24 horas<\/strong> desde que se tenga conocimiento de un incidente significativo<\/li>\n<li><strong>Notificaci\u00f3n del incidente:<\/strong> En un plazo de <strong>72 horas<\/strong>, proporcionando una evaluaci\u00f3n inicial que incluya gravedad e impacto<\/li>\n<li><strong>Informe final:<\/strong> En el plazo de <strong>un mes<\/strong>, incluyendo una descripci\u00f3n detallada, an\u00e1lisis de causa ra\u00edz y medidas de mitigaci\u00f3n aplicadas<\/li>\n<\/ul>\n<p>Para las organizaciones que entregan o mantienen software a trav\u00e9s de pipelines CI\/CD, los registros de pipeline y los registros de despliegue se convierten en <strong>evidencia cr\u00edtica<\/strong> durante la investigaci\u00f3n de incidentes y los informes regulatorios. Los auditores y responsables de cumplimiento deben asegurarse de que los entornos de pipeline est\u00e9n configurados para producir y conservar la evidencia necesaria para cumplir con estas obligaciones.<\/p>\n<h2>C\u00f3mo los registros de pipelines CI\/CD sirven como evidencia de incidentes<\/h2>\n<p>Cuando ocurre un incidente de seguridad \u2014 ya sea un despliegue comprometido, una brecha en la cadena de suministro o un cambio de c\u00f3digo no autorizado \u2014 los investigadores necesitan reconstruir exactamente qu\u00e9 sucedi\u00f3, cu\u00e1ndo y por qui\u00e9n. Los pipelines CI\/CD est\u00e1n en una posici\u00f3n \u00fanica para proporcionar esta evidencia porque se encuentran en la intersecci\u00f3n de los cambios de c\u00f3digo, los procesos de compilaci\u00f3n, los an\u00e1lisis de seguridad y los despliegues en producci\u00f3n.<\/p>\n<p>La evidencia del pipeline permite a las organizaciones:<\/p>\n<ul>\n<li><strong>Establecer cronolog\u00edas:<\/strong> Determinar con precisi\u00f3n cu\u00e1ndo un cambio malicioso o defectuoso entr\u00f3 en el proceso de entrega<\/li>\n<li><strong>Identificar el alcance:<\/strong> Comprender qu\u00e9 artefactos, entornos y servicios se vieron afectados<\/li>\n<li><strong>Demostrar diligencia debida:<\/strong> Mostrar a los reguladores que los controles apropiados (revisiones de c\u00f3digo, an\u00e1lisis de seguridad, puertas de aprobaci\u00f3n) estaban en funcionamiento<\/li>\n<li><strong>Apoyar el an\u00e1lisis de causa ra\u00edz:<\/strong> Rastrear el incidente hasta su origen \u2014 ya sea una dependencia comprometida, un pipeline mal configurado o un error humano<\/li>\n<\/ul>\n<h2>Categor\u00edas de evidencia de pipeline requeridas<\/h2>\n<h3>Cronolog\u00edas de despliegue<\/h3>\n<p>Registros completos de cu\u00e1ndo ocurri\u00f3 cada despliegue, en qu\u00e9 entorno y el resultado (\u00e9xito, fallo, reversi\u00f3n). Estos registros deben incluir marcas de tiempo sincronizadas con una fuente de tiempo fiable.<\/p>\n<h3>Registros de cambios<\/h3>\n<p>Registros que vinculan cada despliegue a cambios de c\u00f3digo espec\u00edficos, incluidos los identificadores de commit, las descripciones de cambios y el autor de cada cambio. Los registros de cambios deben demostrar una cadena ininterrumpida desde el commit de c\u00f3digo hasta el despliegue en producci\u00f3n.<\/p>\n<h3>Registros de aprobaci\u00f3n<\/h3>\n<p>Evidencia de que se obtuvieron las aprobaciones humanas requeridas antes del despliegue. Esto incluye aprobaciones de revisi\u00f3n de c\u00f3digo, aprobaciones del comit\u00e9 asesor de cambios (CAB) donde corresponda, y cualquier autorizaci\u00f3n de cambio de emergencia con justificaci\u00f3n posterior.<\/p>\n<h3>Resultados de an\u00e1lisis de seguridad<\/h3>\n<p>Registros de las puertas de seguridad automatizadas, incluyendo an\u00e1lisis est\u00e1tico, an\u00e1lisis de vulnerabilidades en dependencias, an\u00e1lisis de im\u00e1genes de contenedores y cualquier otra comprobaci\u00f3n de seguridad integrada en el pipeline. Los resultados deben mostrar qu\u00e9 se analiz\u00f3, los hallazgos y si el pipeline continu\u00f3 o fue detenido.<\/p>\n<h3>Procedencia de artefactos<\/h3>\n<p>Registros que establecen el origen e integridad de los artefactos desplegados. Esto incluye registros de compilaci\u00f3n que muestran c\u00f3mo se construyeron los artefactos, sumas de verificaci\u00f3n o firmas que verifican la integridad de los artefactos, y registros de qu\u00e9 c\u00f3digo fuente y dependencias se utilizaron.<\/p>\n<h2>Requisitos de retenci\u00f3n de evidencia<\/h2>\n<p>NIS2 no especifica un periodo de retenci\u00f3n obligatorio \u00fanico para toda la evidencia. Sin embargo, se aplican las siguientes consideraciones:<\/p>\n<ul>\n<li>El <strong>informe final del incidente<\/strong> vence en el plazo de un mes, por lo que toda la evidencia debe estar disponible al menos durante ese periodo<\/li>\n<li>Las autoridades competentes pueden solicitar informaci\u00f3n adicional durante investigaciones de seguimiento, que pueden extenderse mucho m\u00e1s all\u00e1 del periodo de reporte inicial<\/li>\n<li>Las transposiciones de los estados miembros pueden imponer requisitos de retenci\u00f3n espec\u00edficos \u2014 las organizaciones deben verificar su legislaci\u00f3n nacional de implementaci\u00f3n<\/li>\n<li>Como <strong>l\u00ednea base prudente<\/strong>, las organizaciones deben conservar la evidencia del pipeline durante un m\u00ednimo de <strong>24 meses<\/strong> para cubrir los plazos de investigaci\u00f3n, seguimientos regulatorios y posibles procedimientos legales<\/li>\n<\/ul>\n<h2>Mapeo de tipos de incidentes a evidencia de pipeline<\/h2>\n<table>\n<thead>\n<tr>\n<th>Tipo de incidente<\/th>\n<th>Evidencia de pipeline requerida<\/th>\n<th>Periodo de retenci\u00f3n recomendado<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><strong>Despliegue comprometido<\/strong> (c\u00f3digo malicioso llega a producci\u00f3n)<\/td>\n<td>Cronolog\u00eda completa de despliegue; registros de commit y cambios para la versi\u00f3n afectada; registros de aprobaci\u00f3n; resultados de an\u00e1lisis de seguridad (especialmente puertas omitidas); procedencia e integridad de artefactos<\/td>\n<td>M\u00ednimo 24 meses<\/td>\n<\/tr>\n<tr>\n<td><strong>Compromiso de la cadena de suministro<\/strong> (dependencia o imagen base maliciosa)<\/td>\n<td>SBOM para las compilaciones afectadas; registros de actualizaci\u00f3n de dependencias; procedencia de artefactos; registros de acceso al registro; informes de evaluaci\u00f3n de proveedores<\/td>\n<td>M\u00ednimo 24 meses; conservar los SBOM durante el ciclo de vida del software afectado<\/td>\n<\/tr>\n<tr>\n<td><strong>Acceso no autorizado a la infraestructura de pipeline<\/strong><\/td>\n<td>Registros de autenticaci\u00f3n y acceso al pipeline; historial de configuraci\u00f3n RBAC; registros de verificaci\u00f3n MFA; registros de acciones administrativas<\/td>\n<td>M\u00ednimo 24 meses<\/td>\n<\/tr>\n<tr>\n<td><strong>Exposici\u00f3n de datos a trav\u00e9s de registros o artefactos del pipeline<\/strong><\/td>\n<td>Registros de ejecuci\u00f3n del pipeline (para identificar qu\u00e9 datos fueron expuestos); registros de auditor\u00eda de gesti\u00f3n de secretos; registros de acceso al almacenamiento de artefactos<\/td>\n<td>M\u00ednimo 24 meses; puede extenderse seg\u00fan los requisitos de la autoridad de protecci\u00f3n de datos<\/td>\n<\/tr>\n<tr>\n<td><strong>Manipulaci\u00f3n del pipeline<\/strong> (modificaci\u00f3n no autorizada de la configuraci\u00f3n del pipeline)<\/td>\n<td>Historial de cambios de configuraci\u00f3n del pipeline; registros de acceso a la administraci\u00f3n del pipeline; registros de commit para archivos de pipeline como c\u00f3digo; registros de aprobaci\u00f3n para cambios de pipeline<\/td>\n<td>M\u00ednimo 24 meses<\/td>\n<\/tr>\n<tr>\n<td><strong>Fallo de despliegue que causa interrupci\u00f3n del servicio<\/strong><\/td>\n<td>Registros de despliegue incluyendo detalles de errores; registros de reversi\u00f3n; registros de cambios; resultados de pruebas previas al despliegue; resultados de comprobaciones de salud posteriores al despliegue<\/td>\n<td>M\u00ednimo 18 meses<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h2>Lista de verificaci\u00f3n para auditores: preparaci\u00f3n para incidentes en entornos CI\/CD<\/h2>\n<p>Utilice esta lista de verificaci\u00f3n para evaluar si el entorno CI\/CD de una organizaci\u00f3n est\u00e1 preparado para respaldar las obligaciones de notificaci\u00f3n de incidentes de NIS2:<\/p>\n<h3>Generaci\u00f3n de evidencia<\/h3>\n<ul>\n<li>\u2610 Los registros del pipeline capturan el ciclo de vida completo: activaci\u00f3n, compilaci\u00f3n, an\u00e1lisis, aprobaci\u00f3n, despliegue y resultado<\/li>\n<li>\u2610 Cada despliegue est\u00e1 vinculado a un conjunto espec\u00edfico de cambios de c\u00f3digo y aprobaciones<\/li>\n<li>\u2610 Los resultados de los an\u00e1lisis de seguridad se registran y conservan independientemente de las interfaces de las herramientas de pipeline<\/li>\n<li>\u2610 Los registros de procedencia de artefactos (entradas de compilaci\u00f3n, sumas de verificaci\u00f3n, firmas) se generan para cada versi\u00f3n<\/li>\n<li>\u2610 Las marcas de tiempo en todos los componentes del pipeline est\u00e1n sincronizadas con una fuente de tiempo com\u00fan y fiable<\/li>\n<\/ul>\n<h3>Integridad de la evidencia<\/h3>\n<ul>\n<li>\u2610 Los registros del pipeline se almacenan en un almacenamiento de solo adici\u00f3n o inmutable<\/li>\n<li>\u2610 La integridad de los registros puede verificarse (p. ej., mediante sumas de verificaci\u00f3n o encadenamiento criptogr\u00e1fico)<\/li>\n<li>\u2610 El acceso al almacenamiento de registros est\u00e1 restringido y auditado por separado<\/li>\n<li>\u2610 Los administradores del pipeline no pueden eliminar ni modificar los registros hist\u00f3ricos<\/li>\n<\/ul>\n<h3>Retenci\u00f3n de evidencia<\/h3>\n<ul>\n<li>\u2610 Existe una pol\u00edtica de retenci\u00f3n documentada que cubre la evidencia del pipeline CI\/CD<\/li>\n<li>\u2610 Los periodos de retenci\u00f3n cumplen o superan los m\u00ednimos recomendados (24 meses como l\u00ednea base)<\/li>\n<li>\u2610 La retenci\u00f3n se aplica autom\u00e1ticamente \u2014 no depende de intervenci\u00f3n manual<\/li>\n<li>\u2610 La evidencia permanece accesible y legible durante el periodo de retenci\u00f3n (longevidad del formato)<\/li>\n<\/ul>\n<h3>Integraci\u00f3n con la respuesta a incidentes<\/h3>\n<ul>\n<li>\u2610 El plan de respuesta a incidentes hace referencia expl\u00edcita a la evidencia del pipeline CI\/CD y c\u00f3mo acceder a ella<\/li>\n<li>\u2610 Los roles y responsabilidades para la recopilaci\u00f3n de evidencia del pipeline durante incidentes est\u00e1n definidos<\/li>\n<li>\u2610 La organizaci\u00f3n ha probado su capacidad para recuperar y analizar evidencia del pipeline bajo condiciones de incidente<\/li>\n<li>\u2610 Existen rutas de escalada para incidentes que se originan en el pipeline CI\/CD o lo afectan<\/li>\n<\/ul>\n<h3>Preparaci\u00f3n para informes<\/h3>\n<ul>\n<li>\u2610 La organizaci\u00f3n puede producir una cronolog\u00eda de despliegue para cualquier servicio dentro del plazo de alerta temprana de 24 horas<\/li>\n<li>\u2610 Los procedimientos de an\u00e1lisis de causa ra\u00edz incluyen la revisi\u00f3n de registros del pipeline como paso est\u00e1ndar<\/li>\n<li>\u2610 Las plantillas de informes para las autoridades competentes incluyen secciones para evidencia relacionada con el pipeline<\/li>\n<\/ul>\n<h2>Recursos relacionados<\/h2>\n<p>Para la biblioteca completa de recursos de cumplimiento de NIS2, visite nuestro <a href=\"https:\/\/regulated-devsecops.com\/es\/nis2\/\">NIS2 Compliance Hub<\/a>.<\/p>\n<p>Para una descripci\u00f3n general de los principios de arquitectura de seguridad de NIS2 y c\u00f3mo se aplican a la entrega de software, consulte <a href=\"https:\/\/regulated-devsecops.com\/es\/regulatory-frameworks-es\/nis2-security-architecture-explained\/\">NIS2 Security Architecture Explained<\/a>.<\/p>\n<hr\/>\n<h3>Relacionado para auditores<\/h3>\n<ul>\n<li><a href=\"https:\/\/regulated-devsecops.com\/es\/glosario\/\">Glosario<\/a> \u2014 Definiciones en lenguaje sencillo de t\u00e9rminos t\u00e9cnicos<\/li>\n<li><a href=\"https:\/\/regulated-devsecops.com\/es\/regulatory-frameworks-es\/nis2-security-architecture-explained\/\">NIS2 Security Architecture<\/a><\/li>\n<li><a href=\"https:\/\/regulated-devsecops.com\/es\/regulatory-frameworks-es\/continuous-compliance-via-ci-cd\/\">Continuous Compliance via CI\/CD<\/a><\/li>\n<li><a href=\"https:\/\/regulated-devsecops.com\/es\/regulatory-frameworks-es\/how-auditors-actually-review-ci-cd-pipelines\/\">How Auditors Review CI\/CD<\/a><\/li>\n<\/ul>\n<p><em>\u00bfNuevo en la auditor\u00eda CI\/CD? Comience con nuestra <a href=\"https:\/\/regulated-devsecops.com\/es\/por-donde-empezar\/\">Gu\u00eda para Auditores<\/a>.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"<p>El Art\u00edculo 23 de NIS2 impone obligaciones estrictas de notificaci\u00f3n de incidentes. Esta gu\u00eda explica c\u00f3mo los registros de pipelines CI\/CD sirven como evidencia cr\u00edtica para cumplir los plazos de reporte regulatorio.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[131,132,135],"tags":[],"post_folder":[],"class_list":["post-1938","post","type-post","status-publish","format-standard","hentry","category-audit-evidence-es","category-ci-cd-governance-es","category-regulatory-frameworks-es"],"_links":{"self":[{"href":"https:\/\/regulated-devsecops.com\/es\/wp-json\/wp\/v2\/posts\/1938","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/regulated-devsecops.com\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/regulated-devsecops.com\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/regulated-devsecops.com\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/regulated-devsecops.com\/es\/wp-json\/wp\/v2\/comments?post=1938"}],"version-history":[{"count":0,"href":"https:\/\/regulated-devsecops.com\/es\/wp-json\/wp\/v2\/posts\/1938\/revisions"}],"wp:attachment":[{"href":"https:\/\/regulated-devsecops.com\/es\/wp-json\/wp\/v2\/media?parent=1938"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/regulated-devsecops.com\/es\/wp-json\/wp\/v2\/categories?post=1938"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/regulated-devsecops.com\/es\/wp-json\/wp\/v2\/tags?post=1938"},{"taxonomy":"post_folder","embeddable":true,"href":"https:\/\/regulated-devsecops.com\/es\/wp-json\/wp\/v2\/post_folder?post=1938"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}