Continuidad del negocio y recuperación ante desastres

9.1 Resumen y propósito

Este capítulo define las obligaciones de continuidad del negocio y recuperación ante desastres (BCDR) que rigen la prestación de la Plataforma ProjectVIEW ERP por parte del Proveedor. Establece la estrategia de copias de seguridad, la arquitectura de replicación, los procedimientos de conmutación por error, los objetivos de tiempo de recuperación, los compromisos de redundancia de datos y los requisitos de planificación de continuidad que garantizan que los Datos del Cliente permanezcan disponibles, duraderos y recuperables durante todo el Plazo de Suscripción.

El Sistema de Gestión de la Continuidad del Negocio (BCMS) del Proveedor está alineado con ISO 22301:2019 (Seguridad y resiliencia — Sistemas de gestión de la continuidad del negocio) y se basa en NIST SP 800-34 Rev. 1 (Contingency Planning Guide for Federal Information Systems) y en el Microsoft Cloud Enterprise Business Continuity Management (EBCM) Programme. Este capítulo complementa los compromisos de disponibilidad definidos en Chapter 3 (Acuerdo de nivel de servicio), los controles de seguridad de la infraestructura descritos en Chapter 8 (Seguridad de la información y confidencialidad) y las disposiciones de protección de datos de Chapter 7 (Protección de datos y privacidad).

Cada entorno soberano privado dedicado del Cliente se aprovisiona con controles de continuidad de defensa en profundidad que abarcan las capas de cómputo, base de datos, almacenamiento y red, garantizando que ningún punto único de fallo pueda provocar pérdida de datos o una interrupción prolongada del servicio más allá del Objetivo de Punto de Recuperación (RPO) y del Objetivo de Tiempo de Recuperación (RTO) contratados.

9.2 Alcance

Este capítulo cubre:

• (a) Objetivos de recuperación: Compromisos contractualmente vinculantes de RPO y RTO para todas las capas de la Plataforma.
• (b) Gestión de copias de seguridad: Programación de copias, períodos de retención, verificación de integridad y procedimientos de restauración para máquinas virtuales, bases de datos y artefactos de aplicación.
• (c) Redundancia y replicación de datos: Opciones de replicación de Azure Storage (LRS, ZRS, GRS), réplicas de lectura de base de datos y arquitectura de conmutación por error geo-redundante.
• (d) Recuperación ante desastres: Procedimientos de conmutación por error, activación de la región secundaria, protocolos de comunicación y flujos de trabajo de restauración del servicio.
• (e) Planificación de la continuidad del negocio: Análisis de Impacto en el Negocio (BIA), mantenimiento del plan de continuidad, calendarios de simulacros de DR y procedimientos de revisión posterior al incidente.
• (f) Propiedad y portabilidad de los datos: Derechos de propiedad sobre los datos del cliente, mecanismos de exportación de datos, obligaciones de gestión de registros y soporte para e-discovery.
• (g) Funciones y responsabilidades: Asignación RACI entre las organizaciones del Proveedor y del Cliente para todas las actividades de BCDR. Este capítulo no cubre los controles de seguridad a nivel de aplicación (véase Chapter 8), el tratamiento de datos personales (véase Chapter 7) ni los flujos de trabajo de soporte operativo (véase Chapter 4).

9.3 Alineación con estándares y marcos de referencia

El programa de BCDR del Proveedor está alineado con los siguientes estándares y marcos de referencia reconocidos internacionalmente:

9.4 Objetivos de recuperación

Los siguientes objetivos de recuperación contractualmente vinculantes se aplican a cada entorno soberano privado dedicado de cada Cliente. Estos objetivos definen la pérdida máxima tolerable de datos (RPO) y el tiempo de inactividad máximo tolerable (RTO) para cada nivel de la Plataforma:

Cuando el Cliente haya optado por la Enhanced DR Option (servidor secundario con réplicas de base de datos de solo lectura y replicación de alta frecuencia en intervalos de hasta 15 minutos), el RTO del nivel de base de datos se reduce a 1 hora, ya que la VM secundaria asume el rol primario con una pérdida mínima de datos y de tiempo. La Enhanced DR Option está sujeta a tarifas de suscripción adicionales, según se establece en el Contrato Comercial aplicable.

Resumen de continuidad del negocio de Azure SQL Database

9.5 Gestión de copias de seguridad

El Proveedor mantiene un régimen integral de copias de seguridad que cubre todos los componentes de cada entorno soberano privado dedicado del Cliente. Las operaciones de respaldo se realizan utilizando Azure Backup y las capacidades nativas de copia de seguridad de SQL Server.

9.5.1 Programa de copias de seguridad y retención

A solicitud del Cliente, podrán aprovisionarse copias de seguridad personalizadas de mayor frecuencia, sujetas a tarifas de suscripción adicionales. Todas las frecuencias de copia de seguridad y periodos de retención se documentan en el Anexo de programa de copias de seguridad aplicable, adjunto al Contrato Comercial.

Resumen de Azure Backup Copia de seguridad de SQL Server en Azure

9.5.2 Verificación de la integridad de las copias de seguridad

El Proveedor deberá realizar los siguientes procedimientos de verificación de la integridad de las copias de seguridad:

• (a) Validación automática de suma de comprobación: Cada operación de copia de seguridad genera una suma de comprobación criptográfica (SHA-256). La suma de comprobación se verifica automáticamente al finalizar y se registra en el historial de auditoría de la copia de seguridad.
• (b) Prueba mensual de restauración: Al menos una vez por mes natural, el Proveedor deberá realizar una restauración de prueba de una copia de seguridad de base de datos seleccionada aleatoriamente en un entorno aislado, verificando la integridad de los datos, la integridad referencial y la funcionalidad de la capa de aplicación.
• (c) Simulacro trimestral de restauración de pila completa: Al menos una vez por trimestre natural, el Proveedor deberá realizar una restauración completa de la plataforma (VM + base de datos + aplicación + configuración) en un entorno aislado, simulando un escenario completo de recuperación ante desastres. Los resultados se documentan en el Informe del Simulacro de DR.
• (d) Supervisión y alertas de copias de seguridad: Las alertas de Azure Monitor están configuradas para notificar al equipo de Operaciones en la Nube del Proveedor en un plazo de 15 minutos ante cualquier fallo de copia de seguridad, expiración de tiempo o fallo de la comprobación de integridad. Las copias de seguridad fallidas activan un nuevo intento automático en el plazo de 1 hora.

9.6 Redundancia y replicación de datos

Cada entorno soberano privado dedicado del Cliente aprovecha la arquitectura de redundancia de datos multicapa de Azure para protegerse contra fallos de hardware, fallos de instalaciones y desastres regionales:

De forma predeterminada, cada cuenta de Azure Storage del Cliente se aprovisiona con Geo-Redundant Storage (GRS), manteniendo seis copias de los Datos del Cliente, tres dentro de la región primaria de Azure y tres dentro de una región secundaria geográficamente emparejada. En caso de fallo de la región primaria, Azure Storage realiza automáticamente la conmutación por error a la región secundaria, garantizando la durabilidad de los datos sin intervención manual.

Redundancia de Azure Storage

9.6.1 Replicación de bases de datos

Las bases de datos SQL Server 2022 dentro del entorno de cada Cliente admiten las siguientes configuraciones de replicación:

• (a) Configuración estándar: Copias de seguridad completas diarias con retención de 7 días, almacenadas en GRS. Los registros de transacciones se respaldan según el programa configurado (predeterminado: cada hora; Enhanced DR: cada 15 minutos).
• (b) Configuración Enhanced DR (opcional): Se aprovisiona una instancia secundaria de SQL Server con réplicas de solo lectura de todas las bases de datos del Cliente. La transferencia de registros de alta frecuencia (en intervalos de hasta 15 minutos) garantiza una sincronización de datos casi en tiempo real. En caso de fallo del servidor primario, el servidor secundario asume automáticamente el rol primario, proporcionando continuidad con una pérdida mínima de datos (RPO ≤ 15 minutos) y una recuperación rápida (RTO ≤ 1 hora).
• (c) Cumplimiento de residencia de datos: La replicación de datos se limita a la región geográfica seleccionada por el Cliente, salvo que el Cliente autorice explícitamente por escrito la replicación entre regiones. Los datos no pueden transmitirse fuera del área geográfica seleccionada sin el consentimiento del Cliente, en cumplimiento de los requisitos de transferencia transfronteriza del artículo 44 del RGPD y del artículo 22 de la PDPL de los EAU (véase Chapter 7, §7.14).

9.7 Procedimientos de recuperación ante desastres

El Proveedor mantiene procedimientos documentados de recuperación ante desastres para cada nivel de la Plataforma. Estos procedimientos se prueban al menos trimestralmente y se actualizan tras cualquier cambio material en la arquitectura de la Plataforma, las capacidades de los servicios de Azure o la configuración del entorno del Cliente.

9.7.1 Clasificación de incidentes y escalamiento

Los eventos de recuperación ante desastres se clasifican según la siguiente taxonomía de gravedad:

9.7.2 Procedimientos de conmutación por error

Los siguientes procedimientos de conmutación por error se ejecutan en secuencia tras la declaración de un evento DR-1 o DR-2:

9.7.3 Conmutación por error a región secundaria

Cuando Microsoft o el CTO del Proveedor declaren irrecuperable la región primaria de Azure, el Proveedor ejecutará una conmutación completa por error a la región secundaria en la región de Azure emparejada geográficamente. Este procedimiento incluye:

• (a) Inicio de la conmutación por error de GRS: Azure Storage realiza automáticamente la conmutación por error a la región secundaria. Las cuentas RA-GRS proporcionan acceso inmediato de lectura a los datos replicados.
• (b) Reaprovisionamiento de VM: Se aprovisionan nuevas máquinas virtuales en la región secundaria a partir del almacén de Azure Backup más reciente (restauración entre regiones habilitada).
• (c) Restauración de la base de datos: Las bases de datos SQL Server se restauran a partir de copias de seguridad georredundantes o, cuando se ha aprovisionado Enhanced DR, desde el servidor de réplica de lectura secundario en la región emparejada.
• (d) Reconfiguración de DNS: Azure Traffic Manager o los registros DNS se actualizan para dirigir todo el tráfico del Cliente a los endpoints de la región secundaria.
• (e) Validación y declaración: Se ejecuta la suite completa de verificación de la aplicación antes de declarar el servicio restaurado desde la región secundaria. El RTO objetivo para una conmutación completa por error a la región secundaria es de 24 horas desde el momento de la declaración de la región primaria. El Cliente será informado al menos cada 2 horas durante el procedimiento de conmutación por error a través del canal de comunicación acordado.

Recuperación ante desastres entre regiones en Azure

9.8 Planificación de la continuidad del negocio

9.8.1 Análisis de Impacto en el Negocio (BIA)

El Proveedor mantiene un Análisis de Impacto en el Negocio para la Plataforma ProjectVIEW ERP que identifica los procesos empresariales críticos, asigna sus dependencias sobre los componentes de la Plataforma y cuantifica el impacto de una interrupción del servicio. El BIA se revisa y actualiza:

• (a) Al menos una vez al año, como parte del ciclo de revisión de la dirección del BCMS.
• (b) Tras cualquier cambio material en la arquitectura de la Plataforma, la configuración de la región de Azure o la topología de despliegue del Cliente.
• (c) Tras cualquier incidente DR-1 o DR-2 que revele brechas en el BIA existente.

El BIA fundamenta la calibración de los objetivos de recuperación (RPO/RTO), las decisiones sobre frecuencia de copias de seguridad y el diseño de la arquitectura de replicación para el entorno de cada Cliente.

9.8.2 Plan de continuidad del negocio (BCP)

El Plan de Continuidad del Negocio del Proveedor documenta los procedimientos, funciones, protocolos de comunicación y asignaciones de recursos necesarios para mantener o restablecer los servicios de la Plataforma durante una interrupción. El BCP incluye:

• (a) Composición del Equipo de Gestión de Crisis (CMT): CTO (director del incidente), responsable de Operaciones en la Nube, responsable de DBA, gestor de cuenta del Cliente y responsable de Comunicaciones.
• (b) Plan de comunicación: Plantillas predefinidas para la notificación al Cliente (alerta inicial, actualización de progreso, aviso de resolución, distribución del PIR), matrices internas de escalamiento y registros de contacto de proveedores (Microsoft Azure Support, registradores de dominios, proveedores de SSL).
• (c) Inventario de recursos: Inventario documentado de todos los recursos de Azure por entorno de Cliente (VM, instancias SQL, cuentas de almacenamiento, componentes de red, secretos de Key Vault), mantenido en la CMDB y validado trimestralmente.
• (d) Procedimientos de sitio alternativo: Procedimientos paso a paso para activar la región secundaria de Azure, incluidas plantillas de infraestructura aprovisionadas previamente (Azure Resource Manager / Bicep) y scripts de despliegue automatizados.
• (e) Continuidad de proveedores: Evaluación de dependencias críticas de terceros (compromisos de SLA de Microsoft Azure, registradores de dominios, autoridades de certificación) y medidas de contingencia para cada una.

9.8.3 Programa de simulacros de DR

El Proveedor realizará simulacros de DR periódicos para validar la eficacia del plan de BCDR y garantizar la preparación operativa:

Todos los resultados de los simulacros se documentan, se conservan durante un mínimo de tres (3) años y se ponen a disposición del Cliente previa solicitud por escrito. Cuando un simulacro revele una desviación de los objetivos contractuales de RPO/RTO, el Proveedor implementará acciones correctivas en un plazo de treinta (30) días naturales y repetirá el simulacro pertinente para confirmar la subsanación.

9.9 Propiedad y portabilidad de los datos del Cliente

El Cliente conserva la propiedad exclusiva y excluyente de todos los Datos del Cliente procesados, almacenados o generados dentro de la Plataforma. El Proveedor no inspecciona, aprueba, supervisa ni reclama ningún derecho de propiedad sobre los Datos del Cliente en ningún momento, ya sea durante el Plazo de Suscripción o tras su expiración o terminación.

Microsoft, como proveedor de la infraestructura subyacente, no sabe qué tipo de datos eligen almacenar los Clientes en Azure y no reclama la propiedad de los datos sobre la información del Cliente introducida en los servicios de Azure.

9.9.1 Exportación de datos y portabilidad

El Proveedor pondrá los Datos del Cliente a disposición para su exportación de la siguiente manera:

• (a) Exportación bajo demanda: El Cliente puede solicitar en cualquier momento, durante el Plazo de Suscripción, una exportación total o parcial de los Datos del Cliente. El Proveedor entregará la exportación en un plazo de dos (2) días hábiles a partir de la recepción de una solicitud escrita válida, en un formato legible por máquina y estándar del sector (archivo de copia de seguridad SQL, CSV, JSON o XML, según se acuerde).
• (b) Exportación por terminación: Al vencimiento o terminación del Framework, el Proveedor pondrá todos los Datos del Cliente a disposición para su exportación en un plazo de dos (2) días hábiles a partir de la solicitud escrita del Cliente, de conformidad con las disposiciones de devolución de datos de Chapter 7, §7.13 (Devolución de datos al terminar). La ventana total de exportación permanecerá abierta durante un mínimo de sesenta (60) días naturales desde la fecha efectiva de terminación.
• (c) Exportación para auditoría y cumplimiento: El Cliente puede solicitar registros de auditoría, registros de acceso y registros de seguimiento de cambios con fines de cumplimiento. Estas exportaciones se proporcionan en un plazo de dos (2) días hábiles desde la solicitud escrita.

9.9.2 Gestión de registros

El Cliente es responsable de identificar sus propios requisitos de conservación de registros de conformidad con la ley aplicable y la normativa del sector. El Proveedor respalda las obligaciones de gestión de registros del Cliente mediante:

• (a) Políticas de retención configurables: La Plataforma admite reglas de retención de datos configurables a nivel de aplicación, lo que permite al Cliente definir periodos de retención para distintas categorías de registros.
• (b) Conservación del historial de auditoría: Las políticas de retención de Azure Storage y el seguimiento de cambios de SQL Server proporcionan un historial de auditoría inmutable de todas las modificaciones de datos. Los registros de auditoría se conservan durante un periodo mínimo acordado en el Contrato Comercial (predeterminado: siete años).
• (c) Exportación para archivo externo: El Cliente puede exportar datos e informes de auditoría para archivo externo en cualquier momento durante el Plazo de Suscripción. El Proveedor facilitará la exportación masiva en formatos estándar previa solicitud escrita.

9.9.3 Descubrimiento electrónico (e-Discovery)

El Cliente es responsable de cumplir con los requisitos de e-discovery en el uso de la Plataforma. El Proveedor respaldará las obligaciones de e-discovery del Cliente mediante:

• (a) Órdenes de preservación de datos: A solicitud escrita del Cliente que cite un requisito de conservación por litigio o de investigación regulatoria, el Proveedor impondrá una orden de preservación sobre los Datos del Cliente especificados, suspendiendo toda eliminación automatizada y la aplicación de las políticas de retención para los conjuntos de datos afectados.
• (b) Exportación de datos para e-discovery: El Proveedor exportará y entregará los conjuntos de datos especificados en un formato adecuado para la revisión de e-discovery (incluidos los metadatos y las trazas de auditoría) dentro de dos (2) Días Hábiles a partir de la solicitud de retención por preservación.
• (c) Documentación de cadena de custodia: El Proveedor proporcionará documentación de cadena de custodia para todas las exportaciones de e-discovery, certificando la integridad y la completitud de los datos exportados.

9.10 Resiliencia de la plataforma Azure

El Proveedor aprovecha las siguientes capacidades de resiliencia nativas de Azure dentro del entorno soberano privado dedicado de cada Cliente:

• (a) Zonas de disponibilidad: Cuando estén disponibles en la región de Azure seleccionada por el Cliente, los recursos críticos (VM, discos administrados, equilibradores de carga) se implementan en varias Zonas de disponibilidad para protegerse frente a la falla de una sola zona.
• (b) Azure Resource Health: Supervisa la salud de las VM y comprueba si los recursos funcionan como se espera, detectando problemas conocidos de la plataforma Azure que afectan a los recursos existentes. Las alertas se enrutan al equipo de Operaciones en la Nube a través de Azure Monitor.
• (c) Azure Backup Vault: Gestión centralizada de copias de seguridad con capacidad de restauración entre regiones, protección de eliminación temporal (14 días) y autorización de varios usuarios para operaciones críticas de eliminación de copias de seguridad.
• (d) Bloqueos de recursos de Azure: Se aplican bloqueos CanNotDelete y ReadOnly a todos los recursos de producción para evitar la eliminación o modificación accidental o maliciosa de componentes críticos de la infraestructura.
• (e) Protección DDoS de Azure: La protección DDoS de nivel Standard está habilitada en todas las redes virtuales del Cliente, proporcionando mitigación automática de ataques con telemetría en tiempo real e informes posteriores al ataque.
• (f) Azure Key Vault: Las claves de cifrado, los secretos y los certificados se almacenan en Azure Key Vault con eliminación temporal y protección contra purga habilitadas, garantizando que el material criptográfico pueda recuperarse incluso en caso de eliminación accidental.

Resumen de Azure Availability Zones Resumen de Azure Resource Health Arquitectura de Azure Backup

9.11 Responsabilidades del Cliente

El Cliente reconoce y acepta las siguientes responsabilidades en apoyo del programa BCDR:

• (a) Designación de contactos: El Cliente designará y mantendrá al menos dos (2) contactos autorizados para las comunicaciones relacionadas con DR, incluidos los datos de contacto de emergencia fuera del horario laboral. Los datos de contacto se actualizarán dentro de los cinco (5) Días Hábiles siguientes a cualquier cambio de personal.
• (b) Participación en simulacros de DR: El Cliente hará esfuerzos razonables para participar en los Simulacros anuales de Conmutación a la Región Secundaria y en los Ejercicios de Mesa trimestrales, proporcionando comentarios sobre la eficacia de la comunicación y la precisión del impacto en el negocio.
• (c) Especificación de la política de retención: El Cliente especificará por escrito sus requisitos de retención de datos durante la incorporación y los actualizará según sea necesario. El Proveedor configurará en consecuencia las políticas de retención de la Plataforma.
• (d) Validación de la exportación de datos: Tras cualquier operación de exportación de datos, ya sea bajo demanda o por terminación, el Cliente verificará la integridad y la completitud de los datos exportados dentro de la ventana de validación acordada. La falta de objeción sobre la integridad de los datos dentro de la ventana de validación constituirá la aceptación de la exportación.
• (e) Planificación de la continuidad del usuario final: El Cliente es responsable de su propia planificación interna de continuidad del negocio, incluida la comunicación a los usuarios finales, los procedimientos manuales de respaldo y las dependencias de sistemas internos que quedan fuera del alcance de la Plataforma.

9.12 Mejora continua

El programa BCDR del Proveedor está sujeto a un ciclo de mejora continua alineado con la metodología Planificar-Hacer-Verificar-Actuar (PDCA) prescrita por ISO 22301:2019:

• (a) Planificar: Revisión anual del BIA, calibración de los objetivos de recuperación y actualización del plan BCDR en función de los cambios en la Plataforma, las capacidades de Azure y los requisitos del Cliente.
• (b) Hacer: Ejecución de los programas de copias de seguridad, las configuraciones de replicación y el programa de simulacros de DR definidos en este capítulo.
• (c) Verificar: Supervisión de las tasas de éxito de las copias de seguridad, los resultados de los simulacros de DR (RPO/RTO medidos frente al objetivo), las revisiones posteriores al incidente y los comentarios del Cliente.
• (d) Actuar: Implementación de las acciones correctivas, las mejoras de arquitectura y los refinamientos de procedimiento identificados durante la fase Verificar. Todas las mejoras se registran en el Registro de Mejoras de BCDR y se informan en la reunión trimestral de Revisión del Servicio (véase Chapter 4, §4.10).

9.13 Garantía de software de por vida

El Proveedor garantiza que la Plataforma, durante toda la duración del Plazo de Suscripción y cualquier renovación del mismo (el “ Periodo de Garantía ”):

• (a) Conformidad: funcionará sustancialmente de acuerdo con las especificaciones, la funcionalidad y los niveles de servicio descritos en este Marco y en el Contrato Comercial aplicable;
• (b) Corrección de defectos: estará libre de defectos materiales que impidan al Cliente utilizar la Plataforma para los fines comerciales previstos. Cualquier defecto confirmado será corregido por el Proveedor sin coste adicional para el Cliente dentro de los objetivos aplicables de respuesta y resolución del SLA definidos en Chapter 3;
• (c) Vigencia de versión: permanecerá en una pila tecnológica actualmente admitida y mantenida. El Proveedor actualizará de forma proactiva todos los componentes COTS subyacentes (motor de base de datos, marco de aplicación, sistema operativo, middleware) a versiones admitidas por el proveedor dentro del ciclo de lanzamiento definido en la Sección 4.7;
• (d) Mantenimiento de seguridad: recibirá parches de seguridad continuos durante todo el Periodo de Garantía, incluida la corrección de vulnerabilidades Críticas y Altas dentro de los plazos especificados en Chapter 8;
• (e) Sin degradación: mantendrá características de rendimiento que cumplan o superen los objetivos de SLO y de recuperación (RPO/RTO) definidos en este Marco. El Proveedor no introducirá cambios que degraden sustancialmente el rendimiento de la Plataforma sin la aprobación del Cliente. Esta garantía es una garantía de por vida coextensiva con la Suscripción activa del Cliente. No expira, no se reduce en alcance ni requiere renovación por separado. La garantía sobrevive a las transiciones de versión conforme a Chapter 10 y se aplica igualmente a la versión sucesora desde su fecha de Disponibilidad General.

Exclusiones: La garantía no cubre defectos derivados de (i) modificaciones del Cliente a la Plataforma fuera del proceso de gestión de cambios del Proveedor; (ii) uso de la Plataforma de manera incompatible con su documentación; (iii) software o hardware de terceros no suministrado ni aprobado por el Proveedor; o (iv) Eventos de Fuerza Mayor.

9.14 Depósito en fideicomiso del código fuente

Para proporcionar al Cliente una garantía de continuidad a largo plazo, el Proveedor mantendrá un acuerdo de depósito en fideicomiso del código fuente de la siguiente manera:

9.14.1 Depósito en fideicomiso

• (a) Agente de custodia: El Proveedor designará a un agente de custodia independiente y de buena reputación, tercero ajeno (el “Agente de custodia”), para conservar el código fuente de la Plataforma. La identidad del Agente de custodia se divulgará al Cliente a solicitud de este.
• (b) Contenido del depósito: El depósito en fideicomiso incluirá: (i) el código fuente completo de la Plataforma; (ii) scripts de compilación e instrucciones de compilación; (iii) esquemas de base de datos y scripts de migración; (iv) manifiestos de dependencias de terceros y documentación de licencias; (v) documentación de arquitectura del sistema; y (vi) procedimientos de despliegue suficientes para permitir que un profesional competente de software compile, despliegue y opere la Plataforma.
• (c) Frecuencia de actualización: El depósito en fideicomiso se actualizará dentro de los treinta (30) días siguientes a cada lanzamiento de versión principal (Actualización mayor) y al menos una vez por trimestre natural para las versiones incrementales (Actualizaciones).
• (d) Verificación: El Agente de custodia realizará una verificación anual del depósito para confirmar su completitud y capacidad de compilación. Se proporcionará al Cliente, a solicitud de este, un certificado resumido de verificación.

9.14.2 Condiciones de liberación

El Agente de custodia liberará el código fuente depositado al Cliente cuando se produzca cualquiera de las siguientes condiciones de liberación:

• (a) Insolvencia: El Proveedor entra en liquidación, administración concursal, intervención judicial o cualquier procedimiento de insolvencia análogo en cualquier jurisdicción;
• (b) Cese de actividad: El Proveedor cesa en su actividad empresarial o en la práctica totalidad de ella;
• (c) Incumplimiento material: El Proveedor incurre en un incumplimiento material de este Marco que permanece sin subsanar durante sesenta (60) días siguientes a la notificación escrita del Cliente;
• (d) Descontinuación: El Proveedor descontinúa de forma permanente la Plataforma sin proporcionar un producto sucesor o una vía de transición comercialmente razonable.

9.14.3 Derechos del Cliente tras la liberación

Tras la liberación del código fuente depositado, se concederá al Cliente una licencia no exclusiva, no transferible e irrevocable para usar, compilar, modificar e implementar el código fuente exclusivamente con el fin de continuar operando la Plataforma para los propios fines internos de negocio del Cliente. Esta licencia no incluirá el derecho a redistribuir, sublicenciar ni explotar comercialmente el código fuente.

9.14.4 Costes

Los costes de establecer y mantener el acuerdo de depósito en fideicomiso, incluidos los honorarios del Agente de custodia, las actualizaciones del depósito y la verificación anual, serán asumidos por el Cliente. El Proveedor facilitará la configuración inicial con el Agente de custodia y cooperará con todas las actividades de depósito y verificación, pero el Cliente será el único responsable de los honorarios del Agente de custodia y de cualquier coste asociado durante todo el Plazo de Suscripción.

9.15 Roles y responsabilidades (matriz RACI)

La siguiente matriz RACI asigna responsabilidades para las actividades clave de BCDR entre los roles del Proveedor y del Cliente:

Leyenda: R = Responsable (ejecuta la actividad) · A = Aprobador/Responsable último (autoridad de decisión final) · C = Consultado (aporta información antes de la decisión) · I = Informado (notificado después de la decisión).

9.16 Registro de procesos

El siguiente registro de procesos cataloga todos los procesos formales definidos en este capítulo. A cada proceso se le asigna un identificador único, condición de activación, responsable de ejecución, aprobador responsable, resultado esperado y referencia cruzada a la sección rectora.

9.17 Esquema de flujo del proceso

El siguiente ciclo de vida de nueve etapas ilustra el flujo integral de la gestión de la continuidad del negocio y la recuperación ante desastres dentro del programa BCDR del Proveedor:

① Análisis de impacto en el negocio y evaluación de riesgos → ② Desarrollo del plan de continuidad del negocio y de DR → ③ Copias de seguridad y replicación

Configuración

↓

④ Supervisión y detección → ⑤ Clasificación y escalado de incidentes → ⑥ Conmutación y recuperación

Ejecución

↓

⑦ Restauración y verificación del servicio → ⑧ Revisión posterior al incidente e informe PIR → ⑨ Mejora continua

y programa de simulacros

Etapa ① Análisis de impacto en el negocio y evaluación de riesgos: El Análisis anual de Impacto en el Negocio identifica los procesos críticos, mapea las dependencias de la Plataforma y cuantifica el impacto de la interrupción. Las clasificaciones de prioridad de recuperación y los objetivos RPO/RTO se calibran en función de los resultados del BIA (P-9.01).

Etapa ② Desarrollo del plan de continuidad del negocio y de DR: El Plan de Continuidad del Negocio y los procedimientos de DR se desarrollan o actualizan en función de los hallazgos del BIA, incorporando la composición del CMT, las plantillas de comunicación, los inventarios de recursos y los procedimientos de activación de la región secundaria (P-9.02).

Etapa ③ Configuración de copias de seguridad y replicación: Las programaciones de copias de seguridad, las políticas de retención y la arquitectura de replicación (LRS/ZRS/GRS/RA-GRS) se configuran para cada entorno del Cliente. Se aprovisionan réplicas de lectura de DR mejoradas cuando así se elija (P-9.03).

Etapa ④ Supervisión y detección: Azure Monitor, SIEM y Resource Health supervisan continuamente todos los componentes de la Plataforma. La finalización e integridad de las copias de seguridad se verifican automáticamente con alertas en caso de fallo (P-9.04, P-9.05, P-9.06).

Etapa ⑤ Clasificación y escalado de incidentes: Los incidentes detectados se clasifican (DR-1 a DR-4) y se escalan según la taxonomía de severidad. Los plazos de notificación al Cliente se activan en función del nivel de severidad (P-9.07, P-9.08).

Etapa ⑥ Ejecución de conmutación y recuperación: La conmutación de la base de datos, la restauración de la VM y la verificación de la aplicación se ejecutan en secuencia conforme a la tabla de procedimientos de conmutación. La conmutación a la región secundaria se activa para eventos DR-1 cuando la región primaria es irrecuperable (P-9.09 a P-9.11, P-9.14).

Etapa ⑦ Restauración y verificación del servicio: El servicio se declara restaurado una vez completadas todas las fases de recuperación. El reloj del SLA se reanuda y se mantiene una supervisión intensificada durante 72 horas. Se verifica el cambio de DNS/red (P-9.12).

Etapa ⑧ Revisión posterior al incidente e informe PIR: El Análisis de Causa Raíz se lleva a cabo dentro de los 5 Días Hábiles. El Informe Posterior al Incidente se entrega al Cliente con las acciones correctivas, las actualizaciones del plan BCDR y las lecciones aprendidas (P-9.13).

Etapa ⑨ Mejora continua y programa de simulacros: Los simulacros de DR (de mesa, de componente, de pila completa, regionales) se ejecutan conforme al programa programado. Las desviaciones respecto de los objetivos RPO/RTO activan acciones correctivas registradas en el Registro de Mejoras. El ciclo PDCA vuelve a la Etapa ① (P-9.15, P-9.18).