Gobernanza de los períodos de soporte de seguridad del Reglamento de Ciberresiliencia de la UE con ISO 27001

Son las 08:20 de un martes y el responsable de producto de una pasarela B2B conectada recibe un mensaje de un cliente regulado: “Confirmen el período de soporte de seguridad para la versión 4.6 del firmware, el SLA de respuesta ante vulnerabilidades y si el dispositivo seguirá siendo apto para actualizaciones de seguridad durante nuestro contrato de servicio de cinco años”.

A las 09:00, Compras ha reenviado un cuestionario de diligencia debida de DORA. A las 10:15, Asesoría Jurídica pregunta si el período de soporte anunciado es coherente con los contratos de clientes. A las 11:00, el CISO participa en una revisión del riesgo de proveedores NIS2 porque el producto lo utiliza un proveedor de servicios gestionados en la UE. Después de comer, Privacidad pregunta si una biblioteca de API sin soporte dentro del producto podría afectar a la seguridad de los datos personales conforme al RGPD.

La verdad incómoda aparece rápido. La empresa tiene una hoja de ruta, un proceso de parcheado, un calendario de versiones y un portal de soporte a clientes, pero no dispone de evidencias gobernadas sobre el período de soporte de seguridad.

Esa deficiencia importa. En virtud del Reglamento de Ciberresiliencia de la UE, el período de soporte de seguridad no es solo una etiqueta de producto. Es un compromiso de ciclo de vida que afecta a la gestión de vulnerabilidades, la disponibilidad de actualizaciones, la gestión del riesgo derivado de dependencias de proveedores, la comunicación con clientes, las declaraciones contractuales y la vigilancia poscomercialización. Para proveedores SaaS, fabricantes de dispositivos, editores de software, proveedores de servicios en la nube y proveedores de servicios de TIC, el período de soporte se convierte en un objeto de cumplimiento que auditores y compradores regulados verificarán.

La respuesta práctica no es otra hoja de cálculo de cumplimiento desconectada. La respuesta es gobernar el período de soporte de seguridad dentro de un Sistema de Gestión de la Seguridad de la Información (SGSI) ISO/IEC 27001:2022 y, a continuación, mapear las mismas evidencias con NIS2, DORA, RGPD, NIST CSF 2.0 y expectativas de auditoría de estilo COBIT.

Ese es el modelo operativo de Clarysec: usar el SGSI como motor de evidencias, usar políticas exigibles para definir responsabilidades, usar Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint para construir trazabilidad y usar Zenith Controls: The Cross-Compliance Guide Zenith Controls como brújula de cumplimiento cruzado.

Por qué el período de soporte de seguridad es ahora un objeto de auditoría

Un período de soporte de seguridad responde a una pregunta sencilla: ¿durante cuánto tiempo proporcionará el fabricante actualizaciones de seguridad, remediación de vulnerabilidades, orientaciones de mitigación y soporte relacionado al cliente para un producto o una versión del producto?

En la práctica, esa respuesta depende de muchas piezas móviles:

• Arquitectura y mantenibilidad del producto
• Soporte de componentes de terceros y dependencias de código abierto
• Compromisos de proveedores y de servicios en la nube
• Procesos de recepción y registro de vulnerabilidades, triaje, remediación y divulgación
• Capacidad de ingeniería de versiones y pruebas
• Condiciones contractuales con clientes y obligaciones regulatorias
• Flujos de respuesta a incidentes y notificación a destinatarios del servicio
• Conservación de evidencias y registros de aprobación

Si un fabricante promete cinco años de soporte de seguridad, pero una biblioteca criptográfica crítica queda sin soporte a los tres años, el período de soporte se convierte en una decisión de riesgo. Si un cliente es una entidad financiera sujeta a DORA, ese mismo período de soporte pasa a formar parte del aseguramiento de terceros de TIC. Si el producto trata datos personales, el software sin soporte puede formar parte de la responsabilidad proactiva sobre la seguridad del tratamiento conforme al RGPD. Si el producto da soporte a una entidad esencial o importante conforme a NIS2, la seguridad del ciclo de vida se convierte en una cuestión de seguridad de la cadena de suministro.

NIS2 hace explícito este ángulo de gobernanza. Article 20 exige que los órganos de dirección de entidades esenciales e importantes aprueben las medidas de gestión de riesgos de ciberseguridad, supervisen su implantación y reciban formación. Article 21 exige medidas técnicas, operativas y organizativas adecuadas y proporcionadas, incluidos análisis de riesgos, gestión de incidentes, continuidad del negocio, seguridad de la cadena de suministro, adquisición segura, desarrollo y mantenimiento seguros, gestión y divulgación de vulnerabilidades, evaluación de la eficacia, higiene cibernética, criptografía, control de acceso, gestión de activos y autenticación. Article 23 añade obligaciones escalonadas de notificación de incidentes significativos.

DORA genera una presión similar para las entidades financieras. Exige gestión del riesgo de las TIC, pruebas de resiliencia operativa digital, gestión de incidentes y gobernanza del riesgo de terceros de TIC. DORA Article 28 cubre los principios de gestión del riesgo de terceros de TIC, y Article 30 exige acuerdos contractuales escritos con descripciones claras del servicio, medidas de seguridad, asistencia en incidentes, derechos de auditoría, derechos de terminación y acuerdos de salida.

El RGPD añade la capa de privacidad. Si el producto trata datos personales, los responsables del tratamiento y encargados del tratamiento necesitan medidas técnicas y organizativas adecuadas conforme a Article 32, claridad contractual conforme a Article 28 y preparación para la evaluación y notificación de brechas de seguridad conforme a Articles 33 and 34.

Por eso el período de soporte de seguridad del CRA debe gobernarse como una familia de controles del SGSI, no tratarse como un campo aislado de gestión de producto.

ISO 27001 como columna vertebral de control para los períodos de soporte de seguridad del CRA

ISO/IEC 27001:2022 es valiosa porque es escalable, basada en riesgos y orientada a sistemas de gestión. Exige que la organización defina el contexto, las partes interesadas, el alcance y los procesos que interactúan, y que traduzca los requisitos legales, regulatorios y contractuales en evaluación de riesgos, tratamiento de riesgos, controles operativos y evidencias ISO/IEC 27001:2022.

Para la gobernanza de los períodos de soporte de seguridad, esto significa que la organización debe:

1. Identificar productos, versiones, módulos, servicios en la nube y dependencias incluidos en el alcance.
2. Identificar a las partes interesadas, incluidos clientes, reguladores, distribuidores, importadores, integradores, encargados del tratamiento, subencargados, socios de respuesta a incidentes y proveedores.
3. Registrar las obligaciones legales, regulatorias y contractuales de soporte.
4. Evaluar los riesgos que podrían impedir el cumplimiento de los compromisos de soporte.
5. Seleccionar controles para gestión de vulnerabilidades, desarrollo seguro, aseguramiento de proveedores, gestión de incidentes, continuidad del negocio, privacidad e información documentada.
6. Crear notas de la Declaración de Aplicabilidad que expliquen por qué aplican los controles.
7. Revisar el período de soporte cuando cambien la arquitectura, las dependencias de proveedores, la exposición a amenazas o los compromisos con clientes.

Zenith Controls identifica tres controles de ISO/IEC 27002:2022 relacionados con este tema como anclajes centrales de este problema de gobernanza: 5.31 Requisitos legales, estatutarios, regulatorios y contractuales; 8.8 Gestión de vulnerabilidades técnicas; y 8.25 Ciclo de vida de desarrollo seguro. No son los únicos controles implicados, pero sí constituyen la columna vertebral de la gobernanza.

La clave es la trazabilidad. Un período de soporte de producto debe poder trazarse desde la obligación hasta el escenario de riesgo, desde el escenario de riesgo hasta los controles seleccionados, desde los controles hasta los requisitos de política, y desde los requisitos de política hasta las evidencias.

Zenith Blueprint, fase de gestión de riesgos, Step 13, describe directamente esta disciplina de trazabilidad:

“Referencias cruzadas con regulaciones: si determinados controles se implantan específicamente para cumplir con el RGPD, NIS2 o DORA, puede indicarlo en el Registro de Riesgos (como parte de la justificación del impacto del riesgo) o en las notas de la SoA.”

Fuente: Zenith Blueprint: An Auditor’s 30-Step Roadmap, fase de gestión de riesgos, Step 13: Planificación del tratamiento de riesgos y Declaración de Aplicabilidad Zenith Blueprint

Para un período de soporte de seguridad del CRA, la Declaración de Aplicabilidad no debería limitarse a decir “la gestión de vulnerabilidades aplica”. Debe explicar que la gestión de vulnerabilidades aplica porque la empresa tiene compromisos de ciclo de vida del CRA, expectativas de NIS2 sobre desarrollo seguro y cadena de suministro, demandas de diligencia debida de clientes sujetos a DORA, obligaciones de seguridad del RGPD cuando se tratan datos personales y promesas contractuales de soporte.

De promesa de soporte a ciclo de vida gobernado

Un período de soporte de seguridad definido por el fabricante debe superar seis pruebas de gobernanza.

Primero, debe estar definido. La organización necesita una taxonomía estándar, como soporte activo, soporte solo de seguridad, soporte ampliado, soporte limitado y sin soporte. Cada estado debe explicar la disponibilidad de actualizaciones, la gestión de vulnerabilidades, la comunicación con clientes y las vías de escalado.

Segundo, debe evaluarse en función del riesgo. Cinco años de soporte para un producto SaaS gestionado en la nube con canales de actualización controlados no equivalen a cinco años para un dispositivo embebido con restricciones en campo, dependencias de chips de terceros y ventanas de despliegue gestionadas por el cliente.

Tercero, debe aprobarse. Producto, seguridad, asesoría jurídica, privacidad, soporte al cliente y la dirección responsable deben aprobar el período base y las excepciones.

Cuarto, debe comunicarse. Los clientes deben comprender la fecha de inicio del soporte, la fecha de finalización, el método de actualización, el canal de reporte de vulnerabilidades, las expectativas de remediación, las consecuencias del fin de soporte y las opciones de extensión disponibles.

Quinto, debe supervisarse. Las dependencias cambian. Los proveedores retiran bibliotecas. Aparecen vulnerabilidades. Los entornos de cliente evolucionan. La gobernanza del período de soporte debe incluir supervisión del ciclo de vida de componentes, revisión de proveedores, fuentes de vulnerabilidades, registros de parches, pruebas de versiones y lecciones aprendidas de incidentes.

Sexto, debe evidenciarse. Si un auditor, regulador o cliente regulado solicita evidencia, la organización debe poder mostrar el Registro de Cumplimiento, el registro de soporte de producto, la evaluación de riesgos, el mapeo de la SoA, el Registro de Vulnerabilidades, los registros de parches, las revisiones de proveedores, las aprobaciones de versiones y los avisos a clientes.

Las políticas de Clarysec lo hacen práctico. La Política de Cumplimiento Legal y Normativo empresarial Política de Cumplimiento Legal y Normativo exige:

“Todas las obligaciones legales y regulatorias deben mapearse con políticas, controles y propietarios específicos dentro del Sistema de Gestión de la Seguridad de la Información (SGSI).”

Fuente: Política de Cumplimiento Legal y Normativo, Requisitos de implementación de la política, cláusula 6.2.1 Política de Cumplimiento Legal y Normativo

Para pymes, la disciplina equivalente comienza con un registro más sencillo. La Política de Cumplimiento Legal y Normativo para pymes Política de Cumplimiento Legal y Normativo - pyme establece:

“El Director General debe mantener un Registro de Cumplimiento sencillo y estructurado que incluya:”

Fuente: Política de Cumplimiento Legal y Normativo para pymes, Requisitos de gobernanza, cláusula 5.1.1 Política de Cumplimiento Legal y Normativo - pyme

Un compromiso de período de soporte debe figurar en el Registro de Cumplimiento si está impulsado por una ley, un contrato de cliente, una regulación sectorial o la expectativa de un comprador regulado. No debe residir únicamente en notas de versión o material de marketing.

Construir un registro de períodos de soporte de seguridad del CRA en un único taller

Imagine un proveedor SaaS que vende un dispositivo conectado de analítica a proveedores logísticos de la UE y clientes del sector financiero. El producto incluye un agente embebido, una API en la nube, una aplicación móvil de administración y varias bibliotecas de código abierto. Ventas quiere prometer cinco años de soporte de seguridad para cada versión principal del dispositivo.

El CISO puede dirigir un taller focalizado con producto, ingeniería, asesoría jurídica, privacidad y gestión de proveedores.

Step 1: Crear el registro de períodos de soporte

Cree una fila por versión de producto e incluya:

• Producto y versión
• Fecha de versión
• Fecha de inicio del soporte
• Fecha estándar de finalización del soporte de seguridad
• Opción de soporte ampliado
• Método de entrega de actualizaciones
• Canal de reporte de vulnerabilidades
• Plazo objetivo para parches críticos
• Rol en el tratamiento de datos, como responsable del tratamiento, encargado del tratamiento o ambos
• Proveedores y componentes críticos
• Sectores de clientes afectados
• Propietario del riesgo
• Fecha de aprobación
• Ubicación de evidencias

Este registro se convierte en información documentada dentro del SGSI. Zenith Blueprint, fase de fundamentos y liderazgo del SGSI, Step 6, establece la expectativa de control documental:

“Los documentos deben contar con una identificación adecuada (un título, quizá un número de documento o identificador único, un autor), un formato apropiado y revisión y aprobación de su idoneidad antes de su uso.”

Fuente: Zenith Blueprint: An Auditor’s 30-Step Roadmap, fase de fundamentos y liderazgo del SGSI, Step 6: Información documentada y construcción de la biblioteca del SGSI Zenith Blueprint

La Política de Gestión de Evidencias e Información Documentada del PIMS empresarial de Clarysec Política de Gestión de Evidencias e Información Documentada del PIMS aplica principios similares de evidencias a la documentación de privacidad:

“[Todos] El Responsable de Privacidad / Responsable del PIMS DEBE asignar un identificador de documento, propietario, número de versión, estado de aprobación, fecha de entrada en vigor y fecha de revisión en REG12 antes de publicar información documentada del PIMS.”

Fuente: Política de Gestión de Evidencias e Información Documentada del PIMS, Creación, aprobación, versionado y publicación, cláusula 4.2.1 Política de Gestión de Evidencias e Información Documentada del PIMS

Aunque el registro de períodos de soporte no sea por defecto un documento de privacidad, aplica la misma disciplina: propietario, versión, aprobación, fecha de entrada en vigor y fecha de revisión.

Step 2: Vincular las promesas de soporte con el tratamiento de riesgos

Para cada versión de producto, cree escenarios de riesgo como:

• Se descubre una vulnerabilidad crítica en una versión soportada, pero no hay capacidad de ingeniería disponible.
• Un componente de terceros queda sin soporte antes de que finalice el período de soporte de seguridad declarado.
• Un proveedor cambia la ubicación del alojamiento o el subcontratista y afecta a la entrega de actualizaciones.
• Una vulnerabilidad afecta a datos personales y activa una evaluación de brecha de privacidad.
• Un cliente financiero regulado exige evidencias de resiliencia de terceros de TIC.

Las cláusulas 6.1.1 a 6.1.3 de ISO/IEC 27001:2022 proporcionan el motor de planificación: identificar riesgos, evaluar probabilidad y consecuencias, asignar propietarios de riesgos, seleccionar tratamientos, comparar los controles seleccionados con el Anexo A, elaborar la Declaración de Aplicabilidad y obtener la aprobación del riesgo residual.

Para el riesgo “componente sin soporte antes de la fecha de fin de soporte”, el registro de riesgos debe incluir los controles 5.31, 8.8 y 8.25 de ISO/IEC 27002:2022, además de controles de proveedores como 5.19 Seguridad de la información en las relaciones con proveedores, 5.20 Tratamiento de la seguridad de la información en los acuerdos con proveedores, 5.21 Gestión de la seguridad de la información en la cadena de suministro de TIC, y 5.22 Seguimiento, revisión y gestión de cambios de los servicios de proveedores.

Step 3: Establecer reglas de evidencias de vulnerabilidades y parches

Un período de soporte solo es creíble si la gestión de vulnerabilidades funciona durante ese período.

La Política de gestión de vulnerabilidades y parches para pymes Política de gestión de vulnerabilidades y parches - pyme establece un requisito exigente para exposición urgente:

“Los parches críticos deben aplicarse en un plazo de 3 días desde su publicación, especialmente en sistemas expuestos a internet”

Fuente: Política de gestión de vulnerabilidades y parches para pymes, Requisitos de implementación de la política, cláusula 6.1.1 Política de gestión de vulnerabilidades y parches - pyme

También exige registros preparados para auditorías:

“Debe mantenerse un registro de parches y revisarse durante auditorías y actividades de respuesta a incidentes”

Fuente: Política de gestión de vulnerabilidades y parches para pymes, Requisitos de gobernanza, cláusula 5.4.1 Política de gestión de vulnerabilidades y parches - pyme

Para entornos empresariales, la Política de gestión de vulnerabilidades y parches empresarial Política de gestión de vulnerabilidades y parches exige:

“El Equipo de Operaciones de Seguridad debe mantener un Registro de Gestión de Vulnerabilidades centralizado, revisado mensualmente por el CISO o autoridad delegada.”

Fuente: Política de gestión de vulnerabilidades y parches, Requisitos de gobernanza, cláusula 5.1 Política de gestión de vulnerabilidades y parches

Zenith Blueprint, fase de controles en acción, Step 19, explica la expectativa operativa detrás del control 8.8 de ISO/IEC 27002:2022:

“Manténgase informado sobre nuevos fallos de seguridad (mediante alertas de proveedores, fuentes CVE, etc.) para su software y hardware. Evalúe cuáles son relevantes (¿usamos este software?, ¿cuán crítico es el fallo?) y aplique con prontitud correcciones o mitigaciones.”

Fuente: Zenith Blueprint: An Auditor’s 30-Step Roadmap, fase de controles en acción, Step 19: Controles tecnológicos I Zenith Blueprint

Cada versión de producto soportada necesita una trazabilidad de evidencias de vulnerabilidades: recepción y registro, análisis de relevancia, severidad, versiones afectadas, plan de remediación, versión corregida, orientaciones de mitigación, comunicación con clientes y aprobación de cierre.

Step 4: Conectar el desarrollo seguro con la duración del soporte

El soporte de seguridad empieza antes de la publicación. Depende de prácticas de desarrollo que hagan mantenible el producto.

La Política de Desarrollo Seguro para pymes Política de Desarrollo Seguro - pyme establece:

“Los componentes deben actualizarse regularmente cuando se publiquen parches de seguridad. Si se identifica una vulnerabilidad crítica, el componente debe actualizarse o sustituirse de inmediato.”

Fuente: Política de Desarrollo Seguro para pymes, Requisitos de implementación de la política, cláusula 6.6.3 Política de Desarrollo Seguro - pyme

La Política de requisitos de seguridad de las aplicaciones para pymes Política de requisitos de seguridad de las aplicaciones - pyme exige que los contratos y requisitos:

“especifiquen obligaciones de divulgación de vulnerabilidades, tiempos de respuesta y aplicación de parches.”

Fuente: Política de requisitos de seguridad de las aplicaciones para pymes, Requisitos de gobernanza, cláusula 5.3.2 Política de requisitos de seguridad de las aplicaciones - pyme

Si la empresa promete soporte hasta 2031, la arquitectura debe permitir actualizaciones mantenibles, sustitución de dependencias, canalizaciones de compilación seguras, pruebas de regresión y versiones de emergencia. Los controles de ISO/IEC 27002:2022 relativos a desarrollo seguro, arquitectura segura, codificación segura, pruebas de seguridad, desarrollo externalizado, separación de entornos y gestión de cambios se convierten en habilitadores del período de soporte.

Un único conjunto de evidencias para CRA, NIS2, DORA y RGPD

Las mismas evidencias del período de soporte pueden satisfacer distintas conversaciones regulatorias, pero cada marco formula la pregunta de manera diferente.

La dependencia de proveedores es a menudo donde fallan los compromisos de soporte. La Política de Gestión del Riesgo de Dependencia de Proveedores empresarial Política de Gestión del Riesgo de Dependencia de Proveedores exige:

“Registro de dependencias de proveedores: la VMO mantendrá un registro actualizado de todos los proveedores críticos, incluidos detalles como servicios/productos proporcionados; si el proveedor es único; proveedores alternativos disponibles o capacidad de sustitución; condiciones contractuales vigentes; y una evaluación del impacto si el proveedor fallara o se viera comprometido.”

Fuente: Política de Gestión del Riesgo de Dependencia de Proveedores, Requisitos de implementación, cláusula 6.1 Política de Gestión del Riesgo de Dependencia de Proveedores

Zenith Blueprint, fase de controles en acción, Step 23, advierte que los auditores inspeccionarán acuerdos con proveedores y evidencias de supervisión de proveedores:

“Los auditores revisarán muestras de contratos o acuerdos de servicio. Buscan cláusulas explícitas de seguridad de la información, como plazos de notificación de brechas de seguridad, restricciones de acceso, obligaciones de tratamiento de datos, requisitos de cifrado o derechos de auditoría.”

Fuente: Zenith Blueprint: An Auditor’s 30-Step Roadmap, fase de controles en acción, Step 23: Controles organizativos Zenith Blueprint

Para clientes sujetos a DORA, esto es crítico. Los contratos de servicios de TIC que soportan funciones esenciales o importantes necesitan descripciones claras del servicio, condiciones de subcontratación, medidas de seguridad, asistencia en incidentes, derechos de auditoría e inspección, derechos de terminación y acuerdos de transición. Un proveedor que no pueda sostener esos compromisos puede impedir que el fabricante haga una promesa creíble sobre el período de soporte.

Matriz de correspondencia de controles para una gobernanza del período de soporte preparada para auditorías

Esta matriz de correspondencia permite que seguridad, asesoría jurídica, producto y ventas hablen un mismo idioma. El registro de períodos de soporte no es solo evidencia del CRA. Es aseguramiento de proveedores para NIS2, aseguramiento de terceros para DORA, soporte de seguridad del tratamiento para el RGPD y un artefacto de gobernanza para la certificación ISO 27001.

El ángulo de privacidad: cuando lo no soportado deja de ser seguro

La gobernanza del período de soporte de seguridad no es solo una cuestión de ciberseguridad. Si el producto almacena, transmite o trata datos personales, el software sin soporte puede convertirse en un riesgo de privacidad.

El RGPD aplica al tratamiento en el contexto de un establecimiento en la UE y también puede aplicar a organizaciones no establecidas en la UE que ofrecen bienes o servicios a personas en la UE o supervisan su comportamiento. Define los datos personales de forma amplia y trata una brecha de datos personales como una brecha de seguridad que causa destrucción, pérdida, alteración, comunicación no autorizada o acceso accidental o ilícito a datos personales tratados.

Para la gobernanza del período de soporte, los equipos de privacidad deben saber qué versiones de producto tratan información de identificación personal (PII), qué sistemas siguen soportados y si las vulnerabilidades afectan a la confidencialidad, integridad o disponibilidad de los datos personales.

La Política de Control de Acceso y Seguridad de PII empresarial de Clarysec Política de Control de Acceso y Seguridad de PII exige:

“[Ambos] El propietario del sistema / propietario de la aplicación DEBE registrar en REG12 la cobertura de evaluación de vulnerabilidades de los sistemas que tratan información de identificación personal (PII), al menos trimestralmente y después de un cambio técnico sustancial.”

Fuente: Política de Control de Acceso y Seguridad de PII, Configuración segura y gestión de vulnerabilidades, cláusula 4.7.4 Política de Control de Acceso y Seguridad de PII

La Política de Gestión de Privacidad de Encargados, Subencargados y Terceros empresarial Política de Gestión de Privacidad de Encargados, Subencargados y Terceros añade supervisión continua para relaciones de privacidad de alto riesgo:

“[Todos] El responsable de proveedores / compras DEBE supervisar trimestralmente las relaciones activas de alto riesgo con encargados del tratamiento y subencargados, y anualmente otras relaciones activas con encargados del tratamiento y subencargados de PII, frente a las condiciones de diligencia debida, estado contractual, estado de aseguramiento, asuntos abiertos y fechas de revisión en REG08.”

Fuente: Política de Gestión de Privacidad de Encargados, Subencargados y Terceros, Supervisión continua, asistencia, interfaz de comunicación y salida, cláusula 4.5.1 Política de Gestión de Privacidad de Encargados, Subencargados y Terceros

Cuando una vulnerabilidad se convierte en incidente, la Política de Gestión de Incidentes y Brechas de PII empresarial Política de Gestión de Incidentes y Brechas de PII exige una evaluación de criterios de activación multimarco:

“[Condicional] El Responsable de Privacidad / Responsable del PIMS DEBE evaluar los criterios de activación de notificación legales, sectoriales, del sector financiero, de ciberseguridad, contractuales, de cliente y de destinatario del servicio aplicables para cada incidente de datos personales de alto impacto y registrar el resultado de aplicabilidad en REG01, REG08 y REG10.”

Fuente: Política de Gestión de Incidentes y Brechas de PII, Clasificación y evaluación de brechas, cláusula 4.2.6 Política de Gestión de Incidentes y Brechas de PII

Este es el solapamiento práctico entre los compromisos de soporte del CRA, la comunicación de incidentes NIS2, la gestión de incidentes graves de TIC de DORA y la responsabilidad proactiva ante brechas conforme al RGPD.

Cómo auditan los auditores el mismo proceso de período de soporte

Un proceso sólido de gobernanza del período de soporte debe resistir varios estilos de auditoría. Las evidencias no cambian mucho, pero sí la perspectiva del auditor.

NIST CSF 2.0 es útil como capa de comunicación porque su función GOVERN incluye obligaciones legales, regulatorias, contractuales y de privacidad, objetivos de gestión del riesgo, apetito de riesgo, roles, políticas y supervisión. Sus resultados de cadena de suministro cubren estrategia de proveedores, criticidad, contratos, diligencia debida, supervisión, coordinación de incidentes y disposiciones de fin de relación.

Los auditores de estilo COBIT e ISACA suelen centrarse en el diseño de la gobernanza: quién es propietario de la decisión, qué proceso está definido, qué métricas demuestran desempeño, cómo se aprueban las excepciones y cómo se gestiona la mejora continua.

La Política de Seguridad de la Información empresarial de Clarysec Política de Seguridad de la Información recoge el principio de auditabilidad:

“Todos los controles implantados deberán ser auditables, estar respaldados por procedimientos documentados y por evidencias conservadas de su operación.”

Fuente: Política de Seguridad de la Información, Requisitos de implementación de la política, cláusula 6.6.1 Política de Seguridad de la Información

Esa es la frase que todo período de soporte de seguridad debe poder satisfacer.

Ampliar, reducir o finalizar el soporte sin crear un falso aseguramiento

Los momentos de gobernanza más difíciles no se producen en el lanzamiento del producto. Se producen cuando la realidad cambia.

Puede ser necesario ampliar el soporte porque clientes regulados dependen del producto, la migración no es viable o un cliente sectorial tiene necesidades contractuales de continuidad. Puede ser necesario acortar o restringir el soporte porque un proveedor retira el mantenimiento de seguridad, un componente se vuelve imposible de parchear, una plataforma alcanza límites técnicos o la arquitectura del producto no puede soportar de forma segura una clase de vulnerabilidad.

Un cambio controlado del período de soporte debe incluir:

• Desencadenante de cambio, como fin de vida del proveedor, vulnerabilidad crítica, contrato de cliente o cambio regulatorio
• Productos, versiones, clientes y sectores afectados
• Análisis de impacto en datos personales y servicios críticos
• Revisión de viabilidad de proveedores y componentes
• Evaluación de riesgos y decisión sobre riesgo residual
• Registro de períodos de soporte actualizado
• Aviso a clientes y posición contractual actualizados
• Notas de la SoA actualizadas cuando cambien controles u obligaciones
• Aprobación de la dirección y fecha de revisión

La Política de divulgación coordinada de vulnerabilidades empresarial Política de divulgación coordinada de vulnerabilidades resulta útil cuando el cambio está impulsado por una vulnerabilidad:

“Se desarrollará un plan de remediación o mitigación para todas las vulnerabilidades confirmadas. La implementación de la corrección se priorizará en función de la severidad. Por ejemplo, las vulnerabilidades críticas se corregirán o mitigarán en un plazo de 14 días cuando sea viable, o antes cuando se detecte explotación activa, mientras que las incidencias de menor severidad se abordarán en un plazo razonable.”

Fuente: Política de divulgación coordinada de vulnerabilidades, Requisitos de implementación, cláusula 6.6 Política de divulgación coordinada de vulnerabilidades

Si no puede entregarse de inmediato una corrección completa, pueden ser aceptables temporalmente controles compensatorios, funcionalidad deshabilitada, mayor supervisión u orientación de configuración para clientes, pero la decisión debe documentarse y comunicarse.

Lista de verificación práctica de Clarysec para la preparación del período de soporte

Use esta lista de verificación antes de publicar o renovar cualquier compromiso de período de soporte de seguridad del CRA.

• ¿El producto y la versión figuran en el registro de períodos de soporte?
• ¿La fecha de fin de soporte está aprobada por producto, seguridad y la dirección responsable?
• ¿Los factores legales, regulatorios y contractuales están mapeados en el Registro de Cumplimiento?
• ¿El escenario de riesgo del período de soporte está incluido en el Registro de Riesgos?
• ¿Los controles están mapeados en la Declaración de Aplicabilidad, incluidos 5.31, 8.8 y 8.25 cuando corresponda?
• ¿Los proveedores y componentes críticos están mapeados en el registro de dependencias de proveedores?
• ¿Existe evidencia de que los componentes pueden parchearse o sustituirse durante el período de soporte?
• ¿Están definidas las responsabilidades de recepción y registro, triaje, remediación y divulgación de vulnerabilidades?
• ¿Los SLA de parches críticos están alineados con la política y los contratos de clientes?
• ¿Se conservan los registros de parches, registros de versiones y decisiones sobre vulnerabilidades?
• ¿Los sistemas con datos personales cuentan con evidencias de evaluación de vulnerabilidades cuando se trata PII?
• ¿Los avisos a clientes, declaraciones de soporte y términos contractuales son coherentes?
• ¿Existe un proceso para ampliar, reducir o finalizar el soporte con aprobación de riesgos?
• ¿Las revisiones por la dirección reciben entradas sobre riesgos del período de soporte, proveedores, vulnerabilidades e incidentes?
• ¿Pueden producirse evidencias en un plazo de 48 horas para una auditoría de cliente o un requerimiento de una autoridad reguladora?

La Política de Supervisión, Auditoría y Mejora del PIMS empresarial Política de Supervisión, Auditoría y Mejora del PIMS refuerza la disciplina de revisión por la dirección para programas de privacidad:

“[Ambos] La Alta Dirección DEBE revisar en REG12, durante cada revisión por la dirección, las entradas relativas a no conformidades del PIMS, acciones correctivas, resultados de supervisión, resultados de auditoría, riesgos de privacidad, aseguramiento de proveedores y cambios en partes interesadas.”

Fuente: Política de Supervisión, Auditoría y Mejora del PIMS, Revisión por la dirección del PIMS, cláusula 4.3.5 Política de Supervisión, Auditoría y Mejora del PIMS

Para la gobernanza del período de soporte de seguridad, debe aplicarse la misma cadencia de revisión en todo el SGSI: vulnerabilidades, desempeño de parches, aseguramiento de proveedores, compromisos con clientes, incidentes, excepciones de soporte y acciones correctivas deben alimentar la revisión por la dirección.

Hacer defendible el período de soporte de seguridad

El Reglamento de Ciberresiliencia de la UE cambia la psicología de la seguridad del producto. Empuja a fabricantes y proveedores de software a pensar más allá del día de publicación. El período de soporte de seguridad se convierte en una promesa de ciclo de vida que debe diseñarse, gobernarse, supervisarse y evidenciarse.

Para los CISO, la lección es clara: no permita que el período de soporte resida solo en marketing de producto. Para los responsables de cumplimiento, no construyan un silo separado de evidencias del CRA. Para los auditores, prueben si los compromisos de soporte son trazables a riesgos, controles, proveedores, incidentes y aprobaciones documentadas. Para los propietarios de negocio, recuerden que un período de soporte creíble puede convertirse en una ventaja de mercado, especialmente al vender a sectores regulados por NIS2, entidades financieras sujetas a DORA y clientes sensibles a la privacidad.

Clarysec ayuda a las organizaciones a operativizarlo mediante:

• Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint para construir trazabilidad del SGSI, información documentada, mapeo de la SoA y preparación para auditorías
• Zenith Controls: The Cross-Compliance Guide Zenith Controls para mapear controles ISO/IEC 27002:2022 con NIS2, DORA, RGPD, NIST CSF 2.0 y expectativas de auditoría
• Paquetes de políticas empresariales y para pymes sobre gestión de vulnerabilidades, desarrollo seguro, cumplimiento legal, dependencia de proveedores, evidencias de privacidad y respuesta a incidentes
• Registros prácticos y flujos de trabajo de evidencias que convierten las promesas de períodos de soporte en gobernanza auditable

Su siguiente paso es sencillo: elija una versión de producto emblemática y construya su expediente de evidencias del período de soporte de seguridad. Mapee la obligación, apruebe el período de soporte, pruebe el proceso de vulnerabilidades, valide las dependencias de proveedores, confirme la comunicación con clientes y conserve los registros.

Si puede defender un producto, puede escalar el modelo. Si no puede defender un producto, la deficiencia no es documentación. Es gobernanza.

Descargue Zenith Blueprint, use Zenith Controls para mapear sus evidencias o solicite una evaluación de preparación de Clarysec para convertir los períodos de soporte de seguridad del CRA en gobernanza ISO 27001 preparada para auditorías.