Recuperación ante desastres, continuidad del negocio y respuesta a incidentes
Recuperación ante desastres, continuidad del negocio y respuesta a incidentes de ProcessMind
Fecha de entrada en vigor: 14 de septiembre de 2026
Este documento ofrece un resumen general de los procedimientos de recuperación ante desastres («DR»), continuidad del negocio («BCP») y respuesta a incidentes de seguridad de ProcessMind B.V. para su servicio en la nube. Complementa las Medidas de seguridad, la Política de alojamiento SaaS, el Acuerdo de nivel de servicio y el Anexo sobre tratamiento de datos.
Explica nuestro enfoque actual y no establece objetivos contractuales independientes de tiempo de recuperación, objetivos de punto de recuperación, garantías de durabilidad de los datos, plazos de notificación, niveles de servicio ni estándares de responsabilidad, más allá de lo expresamente establecido en el acuerdo, el DPA o el SLA aplicables.
1. Objetivos y ámbito de aplicación
ProcessMind mantiene estos procedimientos para:
- proteger la confidencialidad, integridad y disponibilidad de los Datos del Cliente durante un evento disruptivo
- restablecer los componentes críticos del servicio de producción tras fallos en los sistemas bajo el control de ProcessMind
- mantener la gestión de incidentes, la comunicación con los clientes y la toma de decisiones operativas durante las interrupciones del servicio
- recuperarse de fallos de infraestructura, implementación, aplicación o capa de datos mediante procedimientos documentados y definiciones de infraestructura controladas por versiones
- identificar y evaluar los Incidentes de Seguridad, contener las amenazas, eliminar las causas raíz, recuperar los sistemas afectados, comunicar lo que corresponda y documentar las lecciones aprendidas
Estos procedimientos se aplican al servicio en la nube de producción de ProcessMind y a los eventos de seguridad que involucren a subencargados del tratamiento o servicios en la nube, en la medida en que afecten al Servicio y estén dentro de la capacidad razonable de ProcessMind para investigarlos y gestionarlos. Los entornos de desarrollo y prueba están segregados y no se consideran objetivos de recuperación para los compromisos de producción destinados a los clientes.
2. Estrategia de resiliencia
2.1 Diseño regional. Los servicios de producción están alojados en AWS EU (Fráncfort, Alemania, eu-central-1). La arquitectura se basa en servicios gestionados de AWS dentro de esa región, que AWS opera en varias zonas de disponibilidad. Actualmente, el clúster de Aurora ejecuta una única instancia de escritura, por lo que la recuperación de la base de datos depende de copias de seguridad automatizadas y de la recuperación a un momento dado, en lugar de una instancia en espera dentro de la región. Actualmente, ProcessMind no opera una segunda región activa para los datos de los clientes.
2.2 Servicios gestionados y sin servidor. ProcessMind utiliza AWS Lambda, Amazon API Gateway, Amazon CloudFront, Amazon Aurora PostgreSQL, Amazon S3, Amazon SQS, Amazon SNS y Amazon CloudWatch. Esto reduce la dependencia de servidores de larga duración gestionados por los clientes y permite la recuperación mediante la reconstrucción desde el código fuente de los componentes de la aplicación y estáticos.
2.3 Separación de entornos. Los entornos de producción y desarrollo funcionan en cuentas de AWS separadas, con bases de datos y pilas de infraestructura independientes. Esto reduce el riesgo de que las actividades de desarrollo afecten a las operaciones de recuperación de producción.
2.4 Supervisión y detección. Las alarmas y los Dashboard de CloudWatch, las alertas de colas de mensajes no entregados, el registro centralizado y la supervisión sintética del servicio facilitan la detección, clasificación y escalamiento de incidentes. También se pueden identificar posibles incidentes mediante solicitudes de asistencia, informes de empleados, notificaciones de proveedores u otros indicios que den lugar a una investigación.
3. Prioridades de recuperación
Durante un incidente grave, las prioridades de recuperación de ProcessMind suelen ser las siguientes:
- Proteger la integridad de los datos de los clientes y evitar daños adicionales.
- Contener el incidente y estabilizar los sistemas afectados.
- Restablecer las vías de acceso principales a producción y los flujos de trabajo críticos.
- Validar el comportamiento del servicio, la integridad de los datos y la supervisión antes de declarar completada la recuperación.
- Comunicar las actualizaciones de estado, el impacto para los clientes y las medidas de seguimiento.
La secuencia exacta puede variar según la naturaleza del incidente, incluso en función de si afecta a la integridad de los datos, al acceso de los clientes, al procesamiento asíncrono o a la infraestructura de soporte.
4. Procedimientos de recuperación ante desastres
4.1 Declaración y coordinación del incidente. Las interrupciones sustanciales del servicio y los incidentes de seguridad se clasifican mediante procedimientos de respuesta a incidentes. ProcessMind designa a un responsable del incidente, limita la participación en la respuesta al personal autorizado, evalúa la gravedad y el alcance, coordina a los responsables técnicos y realiza un seguimiento de las medidas de recuperación hasta que el incidente se resuelva o se reduzca su nivel de gravedad.
4.2 Contención. ProcessMind realiza esfuerzos comercialmente razonables para detener o reducir el impacto en curso antes de iniciar una restauración más amplia. Según el tipo de fallo, las medidas de contención pueden incluir revertir cambios recientes, desactivar las vías afectadas, aislar componentes que funcionen incorrectamente, pausar el procesamiento en segundo plano mientras se realizan comprobaciones de integridad, revocar o rotar credenciales, o bloquear actividades abusivas.
4.3 Erradicación. Una vez estabilizado el impacto inmediato, ProcessMind trabaja para eliminar la causa raíz o el factor contribuyente. Esto puede incluir aplicar correcciones de código o configuración, eliminar artefactos maliciosos, rotar secretos, restaurar una configuración de confianza o cerrar vías de acceso expuestas.
4.4 Recuperación de bases de datos. Aurora PostgreSQL realiza copias de seguridad automatizadas continuas con un período de retención de siete (7) días y admite la recuperación a un momento dado. Si un fallo de la base de datos, un evento de corrupción o un cambio destructivo accidental requiere una restauración, ProcessMind puede restaurar la copia de seguridad adecuada más reciente o la base de datos a un momento seleccionado, validar el entorno restaurado y redirigir el tráfico de la aplicación a la base de datos recuperada.
4.5 Recuperación de objetos y artefactos. Las cargas de archivos de los clientes y los artefactos operativos se almacenan en Amazon S3. El control de versiones está habilitado en el bucket de cargas y en los buckets de recursos para facilitar la recuperación en caso de eliminación o sobrescritura accidental. Los buckets de implementación del sitio web y del frontend se consideran artefactos reproducibles y pueden reconstruirse desde el código fuente en lugar de restaurarse a partir de copias de seguridad.
4.6 Recuperación de cargas de trabajo asíncronas. Las vías de procesamiento asíncrono utilizan colas de mensajes no entregados para conservar los eventos fallidos a efectos de investigación. La recuperación puede incluir volver a intentar procesar los mensajes fallidos, ejecutar de nuevo la lógica de procesamiento o reproducir el trabajo cuando el flujo de trabajo subyacente permita un reprocesamiento seguro.
4.7 Reconstrucción de aplicaciones e infraestructura. La infraestructura se gestiona mediante definiciones de infraestructura como código controladas por versiones. Si es necesario recrear la infraestructura de la aplicación o los recursos estáticos, ProcessMind puede reconstruir y volver a implementar los componentes afectados a partir de definiciones controladas por versiones y artefactos de compilación.
4.8 Validación antes de reanudar el servicio. Antes de cerrar un incidente, ProcessMind valida el estado del servicio mediante las herramientas de supervisión disponibles, los registros, las comprobaciones sintéticas y verificaciones funcionales específicas, y restaura las funciones afectadas utilizando procedimientos validados de implementación, recuperación e infraestructura. Se puede realizar una revisión adicional cuando el incidente haya implicado la restauración de datos o un riesgo para su integridad.
5. Medidas de continuidad del negocio
5.1 Continuidad operativa. ProcessMind mantiene procedimientos operativos documentados para que la gestión de incidentes, la recepción de solicitudes de asistencia de clientes, la respuesta de ingeniería y la toma de decisiones puedan continuar durante eventos disruptivos.
5.2 Comunicaciones. En caso de incidentes sustanciales de producción, ProcessMind realiza esfuerzos comercialmente razonables para proporcionar actualizaciones a través de los canales de asistencia al cliente y, cuando corresponda, de la página pública de estado en processmind.com/status.
5.3 Gestión controlada de cambios. Se utiliza un ciclo de vida de desarrollo de software de defensa en profundidad, con varias capas independientes de validación automatizada, implementaciones controladas, supervisión centralizada y revisiones posteriores a los incidentes, para reducir las interrupciones evitables y mejorar la continuidad con el tiempo.
5.4 Seguridad durante la recuperación. Las acciones de recuperación se llevan a cabo con sujeción a los mismos principios generales de seguridad aplicables durante las operaciones normales, incluido el acceso con privilegios mínimos, el registro de la actividad operativa cuando esté disponible y el acceso controlado a los sistemas y datos de producción.
6. Resumen de copias de seguridad y protección de datos
6.1 Copias de seguridad de bases de datos. Las copias de seguridad automatizadas de Aurora están cifradas y se conservan durante siete (7) días, con recuperación a un momento determinado disponible dentro de ese período de conservación.
6.2 Protecciones de S3. Amazon S3 ofrece una alta durabilidad para los objetos almacenados. Los buckets de datos de clientes que pueden modificarse dependen de la durabilidad y el control de versiones dentro de la región principal. Actualmente, ProcessMind no habilita la replicación de S3 entre regiones para esos buckets.
6.3 Registros y diagnósticos. Los registros, las alarmas y la telemetría centralizados respaldan la investigación de fallos y la validación de la recuperación. Estos mecanismos respaldan las operaciones de continuidad, pero no se presentan por sí mismos como un producto de copia de seguridad independiente.
7. Identificación y clasificación inicial de incidentes
7.1 Evaluación inicial. Los eventos notificados se clasifican inicialmente para determinar si cumplen la definición de Incidente de Seguridad, qué sistemas o datos podrían verse afectados, el alcance y la gravedad probables, y si se requiere una contención inmediata. La preservación de las pruebas se gestiona de manera adecuada a la naturaleza del incidente y a los sistemas implicados.
7.2 Servicio de guardia y escalamiento. ProcessMind mantiene cobertura de guardia para los incidentes de producción, incluida una cobertura 24x7 para los incidentes Críticos (según se definen en el Acuerdo de Nivel de Servicio), de modo que los incidentes puedan reconocerse y clasificarse inicialmente en cualquier momento.
7.3 Documentación. ProcessMind documenta las conclusiones relevantes de las investigaciones, las medidas de respuesta y las decisiones de recuperación para que, una vez ocurrido el incidente, puedan revisarse su cronología y las medidas correctivas resultantes.
8. Comunicaciones y notificaciones
8.1 Comunicación interna. ProcessMind coordina a los responsables de la respuesta, a quienes toman las decisiones y a los canales de asistencia para que la respuesta técnica y la comunicación con los clientes permanezcan coordinadas durante todo el ciclo de vida del incidente.
8.2 Notificación a los clientes. En caso de un Incidente de Seguridad que requiera notificación conforme al DPA o a la legislación aplicable, ProcessMind notificará a los clientes afectados sin dilación indebida y, cuando sea factible, dentro de las setenta y dos (72) horas siguientes a tener conocimiento del incidente. Por lo general, las notificaciones incluyen la naturaleza y el alcance del incidente, las categorías de datos afectadas, si se conocen, las medidas adoptadas para contener y remediar el incidente y, cuando corresponda, las medidas recomendadas a los clientes.
8.3 Actualizaciones continuas. Si el incidente sigue activo o cambian hechos relevantes, ProcessMind proporciona actualizaciones de seguimiento a medida que se dispone de información adicional verificada. En caso de interrupciones más amplias de los servicios de producción, ProcessMind también puede utilizar los canales de asistencia al cliente y, cuando corresponda, la página pública de estado en processmind.com/status.
9. Pruebas, revisión y mantenimiento
ProcessMind revisa estos procedimientos al menos una vez al año y después de incidentes relevantes o cambios arquitectónicos significativos, prueba periódicamente los elementos pertinentes del enfoque de respuesta y recuperación (como la restauración de copias de seguridad, la reconstrucción de implementaciones, la supervisión, las alertas y las comunicaciones sobre incidentes) e incorpora las lecciones aprendidas a sus procedimientos de seguridad, fiabilidad y continuidad.
10. Limitaciones y límites contractuales
Este documento es un resumen de alto nivel y no describe en detalle operativo todos los manuales internos, las vías de escalamiento, los métodos de investigación ni las medidas de gestión de pruebas. No compromete a ProcessMind a adoptar un diseño independiente de conmutación por error entre regiones, a conservar almacenamiento inmutable para todos los buckets modificables ni a ofrecer garantías independientes de RTO/RPO más allá de lo expresamente establecido en el acuerdo o pedido aplicable.
En caso de conflicto entre este documento y el Acuerdo con el Cliente, el Anexo de Tratamiento de Datos, el Acuerdo de Nivel de Servicio o la legislación imperativa aplicables, prevalecerá lo dispuesto en dichas fuentes.