Seguridad de la información y confidencialidad

8.1 Resumen y propósito

Este capítulo define las obligaciones de seguridad de la información y confidencialidad que rigen la prestación, por parte del Proveedor, de la Plataforma ProjectVIEW ERP. Establece la arquitectura de seguridad, los controles de autenticación, los estándares de cifrado, las defensas de red, los procedimientos de gestión de vulnerabilidades y las disposiciones de confidencialidad que protegen los Datos del Cliente, la integridad de la Plataforma y la propiedad intelectual exclusiva del Proveedor durante todo el Plazo de Suscripción.

El Sistema de Gestión de la Seguridad de la Información (SGSI) del Proveedor es mantenido por el Departamento de TI y está alineado con ISO/IEC 27001:2022. Este capítulo aborda los controles técnicos de seguridad que complementan las medidas específicas de privacidad descritas en el Capítulo 7 (Protección de Datos y Privacidad) y las medidas de seguridad del soporte operativo descritas en el Capítulo 4 (Soporte y Operaciones del Servicio).

DANAOS Web Enterprise incorpora mecanismos de seguridad en cada capa del stack de la aplicación, desde la capa de presentación (navegador web) pasando por la capa de aplicación (servidor de aplicaciones) hasta la capa de datos (servidor de bases de datos), garantizando que la confidencialidad, la integridad y la disponibilidad, la tríada C.I.A., se apliquen de extremo a extremo dentro del entorno privado soberano dedicado de cada Cliente.

8.2 Alcance

Este capítulo cubre:

• (a) Seguridad de la aplicación de la plataforma: autenticación, autorización, gestión de sesiones, validación de entradas y prácticas de codificación segura integradas en el DANAOS Web Framework.
• (b) Seguridad de la infraestructura: segmentación de red, configuración de cortafuegos, detección de intrusiones, protección frente a DDoS y controles de Web Application Firewall (WAF) aplicados al entorno soberano alojado en Azure de cada Cliente.
• (c) Seguridad de la base de datos: control de acceso, cifrado en reposo y en tránsito, registro de auditoría, gestión de privilegios y supervisión de conexiones para instancias de SQL Server.
• (d) Seguridad operativa: gestión de vulnerabilidades, pruebas de penetración, gestión de parches, seguimiento de cambios y respuesta ante incidentes de seguridad, incidentes ajenos a datos personales; las brechas de Datos Personales se rigen por el §7.15.
• (e) Seguridad del código fuente: protección de la propiedad intelectual, ciclo de vida de desarrollo seguro, control de versiones basado en Git y prácticas de revisión de código que rigen el código propietario del Proveedor.
• (f) Obligaciones de confidencialidad: compromisos recíprocos de confidencialidad, clasificación de la información, restricciones de divulgación y disposiciones de supervivencia.

8.3 Normas y marcos de seguridad

El programa de seguridad del Proveedor se basa en las siguientes normas, marcos y directrices:

ISO/IEC 27001:2022 NIST CSF 2.0 OWASP Top 10 (2021) CIS Azure Foundations Benchmark NIST SP 800-63B-4 Azure Well-Architected Framework

8.4 Seguridad de la aplicación

La plataforma DANAOS ProjectVIEW ERP incorpora los siguientes mecanismos de seguridad en la capa de aplicación para garantizar la confidencialidad e integridad del sistema. Estos controles se aplican a cada instancia del Cliente y pueden ser configurados por los administradores del sistema del Cliente a través del módulo STY (Gestión de usuarios y roles).

8.4.1 Controles de autenticación

8.4.2 Autorización y control de acceso

El módulo de Gestión de usuarios y roles (STY) de la Plataforma aplica un control de acceso granular basado en roles (RBAC) en varios niveles:

• (a) Nivel de módulo: a los usuarios se les concede o deniega el acceso a módulos completos, por ejemplo, PV_07 HRMS– Payroll, PV_08 Accounting, en función de la asignación de su rol.
• (b) Nivel de función: dentro de un módulo, las funciones individuales, por ejemplo, crear pedido de compra, aprobar factura, ver salario, cuentan con permisos independientes.
• (c) Nivel de campo: los campos sensibles dentro de un registro, por ejemplo, importe salarial, cuenta bancaria, documento nacional de identidad, pueden ocultarse o quedar en solo lectura para roles específicos.
• (d) Nivel de registro: la seguridad a nivel de fila restringe la visibilidad en función de la jerarquía organizativa, por ejemplo, los gestores de proyecto solo ven los proyectos asignados; los gestores regionales ven su región.
• (e) Segregación de funciones: la detección de roles en conflicto impide que un mismo usuario tenga roles que generen conflictos de separación de funciones, por ejemplo, creador de la requisición y autoridad aprobadora. El módulo STY alerta a los administradores sobre los conflictos detectados y aplica restricciones basadas en políticas.
• (f) IDs de usuario únicos: a cada cuenta de usuario se le asigna un identificador único. Las cuentas compartidas o genéricas están prohibidas. Todas las acciones son rastreables hasta un usuario individual mediante la traza de auditoría.
• (g) Acceso remoto restringido: los administradores del sistema controlan el acceso remoto por usuario desde la consola de administración; el acceso puede autorizarse o revocarse en cualquier momento.

8.4.3 Seguridad de sesión

• (a) Tokens de sesión: se generan tokens de sesión aleatorios criptográficamente al autenticarse. Los tokens quedan vinculados a la dirección IP y a la cadena de agente de usuario del usuario para evitar el secuestro de sesión.
• (b) Invalidación de sesión: las sesiones se invalidan en caso de cambio de contraseña, suspensión de la cuenta, cierre de sesión explícito o expiración por inactividad.
• (c) Control de sesiones simultáneas: límites configurables del número de sesiones activas simultáneas por cuenta de usuario. Valor predeterminado: una sola sesión activa por usuario (política de último inicio de sesión prevalece).

8.4.4 Validación de entradas y codificación de salida

• (a) Validación del lado del servidor: todas las entradas suministradas por el usuario se validan en el servidor mediante validación basada en listas blancas. La validación del lado del cliente se considera solo una mejora de usabilidad, nunca un control de seguridad.
• (b) Consultas parametrizadas: todas las interacciones con la base de datos utilizan consultas parametrizadas (sentencias preparadas) para prevenir la inyección SQL. La construcción dinámica de SQL a partir de entradas de usuario está prohibida por la norma de codificación segura del Proveedor.
• (c) Codificación de salida: todos los datos renderizados en el navegador se codifican de forma contextual (HTML, JavaScript, URL, CSS, según corresponda) para prevenir la inyección de scripts entre sitios (XSS).
• (d) Content Security Policy (CSP): las cabeceras de respuesta HTTP incluyen una política de seguridad de contenido estricta para mitigar XSS y ataques de inyección de datos.

8.5 Seguridad de la infraestructura

Cada instancia de ProjectVIEW ERP del Cliente se despliega en un entorno soberano privado dedicado sobre Microsoft Azure. Los controles de seguridad de infraestructura descritos a continuación se aplican por inquilino y se alinean con el CIS Azure Foundations Benchmark y con el Azure Well-Architected Security Pillar.

8.5.1 Seguridad de red

• (a) Grupos de seguridad de red (NSG): cada máquina virtual está protegida por NSG que proporcionan funcionalidad de cortafuegos con estado y reglas explícitas de अनुमति/denegación. Política predeterminada: denegar todo el tráfico entrante; permitir solo los puertos de servicio necesarios.
• (b) Web Application Firewall (WAF): Azure WAF se despliega delante de la capa de aplicación para proteger frente a amenazas del OWASP Top 10, incluida la inyección SQL, XSS, CSRF y los ataques de request smuggling.
• (c) Protección frente a DDoS: Azure DDoS Protection Standard está habilitado para todos los entornos de Cliente y ofrece mitigación automática con detección integrada frente a ataques volumétricos, de protocolo y de capa de aplicación.
• (d) Segmentación de red: la capa de datos, la capa de aplicación y la capa de administración se despliegan en subredes separadas con el tráfico entre capas controlado por reglas NSG. La subred de base de datos no es accesible directamente desde Internet.
• (e) VPN y conectividad privada: cuando el Cliente requiere conectividad sitio a sitio, por ejemplo, integración con Active Directory local, se aprovisiona Azure VPN Gateway o ExpressRoute con cifrado IPSec/IKEv2.
• (f) Seguridad DNS: se utilizan zonas Azure Private DNS para evitar la exfiltración de datos basada en DNS. Los registros DNS públicos están protegidos con DNSSEC cuando el registrador lo admite.

8.5.2 Seguridad de cómputo

• (a) Refuerzo del sistema operativo: todas las máquinas virtuales ejecutan Microsoft Windows Server 2022, reforzado conforme al CIS Windows Server 2022 Benchmark. Se deshabilitan servicios, puertos y funcionalidades innecesarios.
• (b) Gestión de parches: los parches de seguridad se aplican en un plazo de: (i) setenta y dos (72) horas para CVE Críticas/Altas; (ii) treinta (30) días naturales para CVE Medias; (iii) la siguiente ventana de mantenimiento para CVE Bajas. Los parches se prueban en el Entorno de Staging antes de su despliegue en producción.
• (c) Antimalware: la protección de endpoints nativa de la nube (Microsoft Defender for Cloud) está habilitada en todas las máquinas virtuales con análisis en tiempo real, análisis conductual y remediación automática.
• (d) Detección de intrusiones basada en host: Azure Security Centre supervisa la integridad de archivos, la ejecución sospechosa de procesos y las llamadas del sistema anómalas en todas las VM.

8.5.3 Gestión de identidades y secretos

• (a) Azure Key Vault: todas las claves criptográficas, certificados, cadenas de conexión y credenciales de servicio se almacenan en Azure Key Vault con acceso controlado por Azure RBAC y las políticas de acceso de Key Vault.
• (b) Identidades administradas: se utilizan Azure Managed Identities para la autenticación de servicio a servicio siempre que es posible, eliminando la necesidad de credenciales almacenadas en la configuración de la aplicación.
• (c) Rotación de secretos: se aplican políticas automatizadas de rotación de secretos para todas las credenciales de cuentas de servicio y claves API. Periodo máximo de rotación: noventa (90) días naturales.

8.6 Seguridad de la base de datos

La capa de datos de la Plataforma se ejecuta sobre Microsoft SQL Server 2022 (Standard o Enterprise Edition) desplegado en Microsoft Windows Server 2022. Se aplican los siguientes controles de seguridad específicos de base de datos, alineados con el CIS SQL Server 2022 Benchmark:

8.6.1 Acceso y autenticación

• (a) Autenticación de base de datos: SQL Server utiliza el modo de autenticación de Windows (integrado con Active Directory) como método principal de autenticación. La autenticación en modo mixto está deshabilitada salvo que el Cliente la requiera y apruebe expresamente.
• (b) Contraseñas de aplicación: las credenciales de base de datos a nivel de aplicación utilizan contraseñas robustas conformes con la política de composición de contraseñas y se rotan según el calendario de rotación de secretos (§8.5.3).
• (c) Cuentas predeterminadas: todas las cuentas del sistema predeterminadas, por ejemplo, ‘sa’, están debidamente aseguradas por el DBA: las contraseñas predeterminadas se cambian inmediatamente tras el aprovisionamiento; las cuentas predeterminadas innecesarias se deshabilitan o eliminan.
• (d) Control de conexiones: las conexiones a las instancias de base de datos se controlan y supervisan. Solo los servicios autorizados de la capa de aplicación y el personal designado de DBA pueden establecer conexiones. Las cadenas de conexión se almacenan en Azure Key Vault (§8.5.3).
• (e) Capacidad de conexión: los controles a nivel de red restringen la conectividad a la base de datos únicamente a la subred de la capa de aplicación y a los puntos finales de administración autorizados. La conectividad directa desde Internet a la base de datos está prohibida.

8.6.2 Gestión de privilegios

• (a) Permisos y roles mínimos: las cuentas de usuario de la base de datos se aprovisionan con los permisos y roles mínimos necesarios para su función. Se aplica y revisa periódicamente el principio de mínimo privilegio.
• (b) Privilegios del sistema: todos los privilegios de ‘sistema’ se eliminan de las cuentas de usuario salvo que estén explícitamente requeridos y aprobados. Las operaciones privilegiadas requieren una cuenta DBA separada y dedicada con MFA.
• (c) Segregación de funciones: los privilegios de administración de base de datos se segregan de los privilegios de desarrollo de aplicaciones. Los desarrolladores no tienen acceso a la base de datos de producción.
• (d) Revisión de privilegios: revisión trimestral de las asignaciones de privilegios de la base de datos; los privilegios no utilizados o excesivos se revocan. Los resultados de la revisión se documentan y están disponibles para auditoría (§7.11).

8.6.3 Cifrado

• (a) Cifrado Transparente de Datos (TDE): TDE está habilitado en todas las instancias de base de datos de producción y preproducción, cifrando los archivos de datos, los archivos de registro y tempdb mediante cifrado AES-256. Los certificados TDE se respaldan y se almacenan en Azure Key Vault.
• (b) Cifrado de copias de seguridad: todas las copias de seguridad de base de datos, completas, diferenciales y del registro de transacciones, se cifran con AES-256 y claves de cifrado específicas del Cliente gestionadas a través de Azure Key Vault.
• (c) Cifrado a nivel de columna: cuando lo exige la política de clasificación de datos del Cliente, se dispone de cifrado a nivel de columna (Always Encrypted) para campos de alta sensibilidad, por ejemplo, documentos nacionales de identidad y números de cuenta bancaria.

8.6.4 Auditoría y registro

• (a) Registro de auditoría: SQL Server Audit captura: (i) todas las operaciones DDL (cambios de esquema); (ii) la actividad de usuarios privilegiados; (iii) los intentos de autenticación fallidos; (iv) las operaciones de exportación de datos y copia masiva; (v) los cambios de permisos. Los registros de auditoría se escriben en un almacenamiento a prueba de alteraciones.
• (b) Retención de registros: Los registros de auditoría de la base de datos se conservan durante un mínimo de doce (12) meses en línea y veinticuatro (24) meses en almacenamiento de archivo. La retención cumple los requisitos regulatorios conforme al RGPD, la PDPL de los EAU y las normas sectoriales aplicables.
• (c) Seguimiento de cambios: SQL Server Change Tracking y Change Data Capture (CDC) están habilitados para proporcionar un inventario completo de las modificaciones de datos con fines de cumplimiento y auditoría.
• (d) Acceso remoto de DBA: La administración remota de bases de datos está restringida a personas identificadas mediante canales cifrados con autenticación multifactor. Todas las sesiones de DBA se registran con trazabilidad completa a nivel de comando de auditoría (§7.8.3).

8.7 Gestión de vulnerabilidades

El Proveedor opera un programa continuo de gestión de vulnerabilidades alineado con las funciones Identify (ID.RA) y Protect (PR.IP) de NIST CSF:

8.7.1 Calendario de evaluaciones

8.7.2 Plazos de remediación

Vulnerabilidades de día cero: Para las vulnerabilidades de día cero activamente explotadas que afecten al stack tecnológico de la Plataforma, el Proveedor aplicará medidas de mitigación de emergencia (por ejemplo, reglas de WAF, aislamiento de red, parcheo virtual) en un plazo de veinticuatro (24) horas, con un parche permanente conforme al SLA de remediación Crítica.

8.8 Supervisión de seguridad e respuesta a incidentes

8.8.1 Supervisión

El Proveedor opera una capacidad de supervisión de seguridad 24/7 utilizando los siguientes componentes:

• (a) SIEM: Security Information and Event Management nativo de la nube (Microsoft Sentinel) agrega registros de todas las capas de infraestructura, aplicación y base de datos. Las reglas de correlación y las detecciones de machine learning identifican patrones anómalos.
• (b) AIOps: Las herramientas de operaciones impulsadas por IA proporcionan detección predictiva de anomalías en métricas de rendimiento, patrones de autenticación y volúmenes de acceso a datos, lo que permite identificar de forma temprana desviaciones relevantes para la seguridad antes de que se conviertan en incidentes.
• (c) Inteligencia de amenazas: El SIEM integra fuentes de inteligencia de amenazas en tiempo real (Microsoft Threat Intelligence, IOCs específicos del sector) para detectar firmas de ataque conocidas e indicadores de compromiso.
• (d) Analítica del comportamiento de usuarios y entidades (UEBA): Se establecen perfiles de comportamiento de referencia para usuarios y cuentas de servicio. Las desviaciones (por ejemplo, ubicaciones de inicio de sesión anómalas, patrones inusuales de acceso a datos, intentos de escalada de privilegios) activan alertas automatizadas.

8.8.2 Respuesta ante incidentes de seguridad

Los incidentes de seguridad que no impliquen Datos Personales se gestionan conforme a esta sección. Las brechas de Datos Personales se rigen por el §7.15. Cuando un incidente se clasifique posteriormente como relacionado con Datos Personales, los procedimientos de notificación de brechas del §7.15 se aplicarán además de las medidas indicadas a continuación.

8.8.3 Notificación al Cliente

El Proveedor notificará al Cliente los incidentes de seguridad que: (i) den lugar a acceso no autorizado real o presunto a los Datos del Cliente; (ii) afecten de manera material a la disponibilidad o integridad de la Plataforma; o

• (iii) impliquen la intervención de las fuerzas del orden en relación con el entorno del Cliente. La notificación se realizará dentro de los plazos alineados con la severidad del incidente y con los SLA de notificación de brechas definidos en el §7.15.1.

8.9 Ciclo de vida de desarrollo seguro (SDLC)

El Proveedor sigue un SDLC seguro alineado con el Software Assurance Maturity Model (SAMM) de OWASP y el Security Development Lifecycle (SDL) de Microsoft:

• (a) Modelado de amenazas: Las nuevas funcionalidades y los cambios significativos se someten a modelado de amenazas durante el diseño. Se utiliza la metodología STRIDE para identificar amenazas; DREAD se utiliza para priorizar el riesgo.
• (b) Estándares de codificación segura: Los desarrolladores siguen el estándar de codificación segura del Proveedor (basado en OWASP Secure Coding Practices) que cubre validación de entradas, codificación de salidas, autenticación, gestión de sesiones, tratamiento de errores y criptografía.
• (c) Static Application Security Testing (SAST): El SAST automatizado se ejecuta en cada commit de código. Los hallazgos de severidad Alta/Crítica bloquean la compilación hasta su resolución.
• (d) Dynamic Application Security Testing (DAST): El DAST se ejecuta contra el entorno de staging antes de cada despliegue en producción. El análisis se centra en los controles OWASP Top 10 y ASVS Level 2.
• (e) Software Composition Analysis (SCA): Todas las dependencias de terceros se analizan en cada compilación para detectar vulnerabilidades conocidas (CVE) y el cumplimiento de licencias. Los componentes con CVE Críticas/Altas sin parchear quedan bloqueados.
• (f) Revisión de código: Todos los cambios de código de producción requieren revisión y aprobación por pares antes de fusionarse en la rama Master. Los cambios sensibles desde el punto de vista de seguridad (autenticación, criptografía, lógica de control de acceso) requieren revisión por un security champion designado.
• (g) Control de versiones: Control de versiones basado en Git con modelo de ramas Master/Client/Working (§4.7). Todos los commits están firmados y son trazables a desarrolladores individuales. Está prohibido hacer force-push a Master.

8.10 Protección del código fuente

El código fuente del Proveedor constituye propiedad intelectual exclusiva y está sujeto a las siguientes protecciones:

• (a) Restricción de acceso: Los repositorios de código fuente solo son accesibles para el personal de desarrollo autorizado del Proveedor. El personal del Cliente no tiene acceso al código fuente salvo que se firme un acuerdo independiente de custodia de código fuente.
• (b) Custodia de código fuente: A solicitud del Cliente, el Proveedor suscribirá un acuerdo de custodia de código fuente con un agente de custodia externo de reconocido prestigio. Las condiciones de liberación suelen incluir: insolvencia del Proveedor, incumplimiento material de este Marco, o discontinuación de la Plataforma sin un producto sucesor adecuado.
• (c) Arquitectura de cliente ligero: La Plataforma funciona como una aplicación web de cliente ligero. No se distribuye a los dispositivos del Cliente ningún código fuente propietario, binarios compilados ni lógica de aplicación. Todo el procesamiento de la aplicación se realiza en el servidor dentro del entorno soberano del Cliente.
• (d) Ofuscación: El JavaScript y CSS del lado del cliente entregados al navegador se minimizan y ofuscan. Los mapas de código fuente no se exponen en los despliegues de producción.
• (e) Sin obligación de código abierto: El Proveedor garantiza que el uso de componentes de código abierto no genere una obligación de divulgar código fuente propietario (por ejemplo, contaminación por licencias copyleft). Todos los componentes de código abierto se validan en cuanto a compatibilidad de licencias antes de su adopción.

8.11 Obligaciones de confidencialidad

8.11.1 Clasificación de la información

Toda la información intercambiada entre las Partes se clasifica de acuerdo con el siguiente esquema:

8.11.2 Compromisos mutuos de confidencialidad

Cada Parte se compromete frente a la otra a que:

• (a) Mantendrá confidencial toda la Información Confidencial de la Parte divulgadora y no la divulgará a ningún tercero sin el consentimiento previo por escrito de la Parte divulgadora.
• (b) Utilizará la Información Confidencial exclusivamente para el cumplimiento de sus obligaciones o el ejercicio de sus derechos en virtud de este Marco.
• (c) Limitará la divulgación de la Información Confidencial a aquellos de sus empleados, agentes o subencargados que necesiten conocer la información a efectos de este Marco y que estén sujetos a obligaciones de confidencialidad no menos restrictivas que las contenidas en el presente documento.
• (d) Aplicará el mismo grado de diligencia para proteger la Información Confidencial de la Parte divulgadora que aplica a su propia información confidencial, pero en ningún caso inferior a una diligencia razonable.
• (e) Notificará sin demora a la Parte divulgadora cualquier divulgación o uso no autorizado, real o presunto, de la Información Confidencial.

8.11.3 Exclusiones

Las obligaciones de confidencialidad no se aplicarán a la información que:

• (a) Sea o pase a ser de dominio público sin culpa de la Parte receptora.
• (b) Ya era conocida por la Parte receptora en el momento de la divulgación, según lo demuestren registros escritos.
• (c) Sea desarrollada de forma independiente por la Parte receptora sin referencia a la Información Confidencial.
• (d) Se obtenga lícitamente de un tercero sin restricción de divulgación.
• (e) Deba divulgarse por ley, reglamento o mandato judicial aplicable, siempre que la Parte receptora dé aviso previo por escrito a la Parte divulgadora (en la medida legalmente permitida) y coopere en cualquier intento de obtener un tratamiento protector.

8.11.4 Supervivencia

Las obligaciones de confidencialidad establecidas en esta sección sobrevivirán a la terminación o expiración de este Marco durante un período de cinco (5) años, salvo en lo relativo a los secretos comerciales, que estarán protegidos mientras sigan siendo secretos comerciales conforme a la legislación aplicable.

8.12 Eliminación de accesos

8.12.1 Eliminación de accesos a sistemas

Cuando cambie el puesto de un empleado del Proveedor o finalice su relación laboral, todo el acceso a los sistemas se elimina en:

• (a) Despido involuntario o motivo de seguridad: Revocación inmediata (en un plazo de 1 hora) de todas las credenciales del sistema, acceso VPN, permisos de Key Vault y acceso físico a las instalaciones.
• (b) Salida planificada: El acceso se revoca el último día laborable. Todos los dispositivos propiedad del Proveedor se devuelven y se borran.
• (c) Cambio de puesto: El acceso se ajusta en un plazo de un (1) día hábil para reflejar los requisitos de privilegio del nuevo puesto. Se eliminan los privilegios excedentes del puesto anterior.

8.12.2 Eliminación de accesos a aplicaciones

Cuando cambie el puesto de un usuario final del Cliente o abandone la organización del Cliente:

• (a) Responsabilidad del Cliente: El administrador del sistema del Cliente (o Champion) es responsable de deshabilitar o modificar las cuentas de usuario dentro del módulo STY.
• (b) Soporte del Proveedor: Cuando el Cliente requiera asistencia del Proveedor (por ejemplo, desactivación masiva, bloqueo de emergencia), se deberá abrir una solicitud de servicio P2 (§4.3) y procesarla dentro del SLA aplicable.
• (c) Detección de cuentas inactivas: La Plataforma marca las cuentas que no tienen actividad de inicio de sesión durante más de noventa (90) días naturales. Las cuentas marcadas se informan al administrador del Cliente para su revisión y posible desactivación.

8.13 Registro de procesos

La siguiente tabla enumera los procesos contractuales y operativos regulados por este capítulo. A cada proceso se le asigna un identificador único, una condición de activación, un responsable de ejecución, un aprobador, el resultado previsto y una referencia cruzada a la sección aplicable.

8.14 Esquema de flujo de procesos

El siguiente diagrama ilustra el ciclo de vida de la seguridad de la información desde la evaluación de riesgos hasta la supervisión continua y la respuesta a incidentes.

① Evaluación de riesgos del SGSI → ② Arquitectura y controles de seguridad → ③ Desarrollo y despliegue seguros

▼

④ Gestión de vulnerabilidades → ⑤ Supervisión continua (SIEM / AIOps) → ⑥ Control de acceso y revisiones

▼

⑦ Detección y respuesta a incidentes → ⑧ Revisión posterior al incidente y mejora → ⑨ Auditoría y certificación de cumplimiento

Bucle continuo: La etapa ⑨ (Auditoría y certificación) retroalimenta la etapa ① (Evaluación de riesgos) a través del ciclo de mejora continua del SGSI (Planificar-Hacer-Verificar-Actuar). Las etapas ④-⑦ operan de forma continua con análisis automatizados semanales y supervisión SIEM en tiempo real. Las pruebas de penetración anuales y las auditorías de certificación aportan una garantía independiente.