Reprise après sinistre, continuité des activités et réponse aux incidents
Reprise après sinistre, continuité des activités et réponse aux incidents de ProcessMind
Date d’entrée en vigueur : 14 septembre 2026
Le présent document fournit un résumé général des procédures de reprise après sinistre (« DR »), de continuité des activités (« BCP ») et de réponse aux incidents de sécurité de ProcessMind B.V. pour son service cloud. Il complète les Mesures de sécurité, la Politique d’hébergement SaaS, l’Accord de niveau de service et l’Avenant relatif au traitement des données.
Il expose notre approche actuelle et ne crée pas d’objectifs contractuels distincts en matière de délai de reprise, de point de reprise, de garanties de durabilité des données, de délais de notification, de niveaux de service ou de normes de responsabilité, au-delà de ce qui est expressément prévu dans le contrat applicable, l’avenant relatif au traitement des données ou l’accord de niveau de service.
1. Objectifs et champ d’application
ProcessMind maintient ces procédures afin de :
- protéger la confidentialité, l’intégrité et la disponibilité des Données client pendant un événement perturbateur
- rétablir les composants essentiels du service de production après des défaillances des systèmes contrôlés par ProcessMind
- assurer la poursuite de la gestion des incidents, des communications avec les clients et de la prise de décisions opérationnelles pendant les interruptions de service
- rétablir le service après des défaillances de l’infrastructure, du déploiement, de l’application ou de la couche de données au moyen de procédures documentées et de définitions d’infrastructure gérées dans le contrôle de version
- identifier et évaluer les Incidents de sécurité, contenir les menaces, éliminer les causes profondes, rétablir les systèmes affectés, communiquer lorsque cela est requis et tirer les enseignements de l’incident
Ces procédures s’appliquent au service cloud de production de ProcessMind et aux événements de sécurité impliquant des sous-traitants ultérieurs ou des services cloud, dans la mesure où ils affectent le Service et relèvent de la capacité raisonnable de ProcessMind à enquêter et à intervenir. Les environnements de développement et de test sont isolés et ne sont pas considérés comme des cibles de reprise au titre des engagements de production destinés aux clients.
2. Stratégie de résilience
2.1 Conception régionale. Les services de production sont hébergés dans AWS EU (Francfort, Allemagne, eu-central-1). L’architecture repose sur des services gérés par AWS dans cette région, qu’AWS exploite sur plusieurs zones de disponibilité. Le cluster Aurora exécute actuellement une seule instance d’écriture ; la reprise de la base de données repose donc sur des sauvegardes automatisées et une restauration à un instant donné, plutôt que sur une instance de secours dans la région. ProcessMind n’exploite actuellement aucune deuxième région active pour les données des clients.
2.2 Services gérés et sans serveur. ProcessMind s’appuie sur AWS Lambda, Amazon API Gateway, Amazon CloudFront, Amazon Aurora PostgreSQL, Amazon S3, Amazon SQS, Amazon SNS et Amazon CloudWatch. Cela réduit la dépendance à l’égard de serveurs de longue durée gérés par les clients et permet de reconstruire à partir du code source les composants applicatifs et statiques.
2.3 Séparation des environnements. Les environnements de production et de développement fonctionnent dans des comptes AWS distincts, avec des bases de données et des piles d’infrastructure séparées. Cela réduit le risque que les activités de développement affectent les opérations de reprise de la production.
2.4 Surveillance et détection. Les alarmes et tableaux de bord CloudWatch, les alertes de files d’attente de lettres mortes, la journalisation centralisée et la surveillance synthétique des services contribuent à la détection, au triage et à l’escalade des incidents. Les incidents potentiels peuvent également être identifiés à la suite de demandes d’assistance, de signalements d’employés, de notifications de fournisseurs ou d’autres déclencheurs d’enquête.
3. Priorités de reprise
Lors d’un incident majeur, les priorités de reprise de ProcessMind sont généralement les suivantes :
- Protéger l’intégrité des données des clients et prévenir tout dommage supplémentaire.
- Contenir l’incident et stabiliser les systèmes affectés.
- Rétablir les voies d’accès essentielles à la production et les flux de travail critiques.
- Valider le fonctionnement du service, l’intégrité des données et la surveillance avant de déclarer la reprise achevée.
- Communiquer les mises à jour de situation, les répercussions pour les clients et les mesures de suivi.
L’ordre exact peut varier selon la nature de l’incident, notamment selon qu’il affecte l’intégrité des données, l’accès des clients, le traitement asynchrone ou l’infrastructure de soutien.
4. Procédures de reprise après sinistre
4.1 Déclaration et coordination de l’incident. Les interruptions de service substantielles et les incidents de sécurité sont soumis à un triage conformément aux procédures de réponse aux incidents. ProcessMind désigne un responsable de l’incident, limite la participation à la réponse au personnel autorisé, évalue la gravité et la portée de l’incident, coordonne les intervenants techniques et suit les mesures de reprise jusqu’à la résolution ou à la rétrogradation de l’incident.
4.2 Confinement. ProcessMind déploie des efforts commercialement raisonnables pour arrêter ou réduire les répercussions en cours avant d’entamer un rétablissement plus large. Selon le mode de défaillance, les mesures de confinement peuvent inclure l’annulation des modifications récentes, la désactivation des voies affectées, l’isolement des composants défectueux, la suspension du traitement en arrière-plan pendant les vérifications d’intégrité, la révocation ou la rotation des identifiants, ou le blocage des activités abusives.
4.3 Éradication. Une fois les répercussions immédiates stabilisées, ProcessMind s’efforce d’éliminer la cause profonde ou le facteur contributif. Cela peut inclure l’application de correctifs au code ou à la configuration, la suppression d’éléments malveillants, la rotation des secrets, le rétablissement d’une configuration fiable ou la fermeture des voies d’accès exposées.
4.4 Reprise de la base de données. Aurora PostgreSQL effectue des sauvegardes automatisées en continu, conservées pendant sept (7) jours, et prend en charge la restauration à un instant donné. Si une défaillance au niveau de la base de données, un événement de corruption ou une modification destructive accidentelle nécessite une restauration, ProcessMind peut restaurer la sauvegarde appropriée la plus récente ou la base de données à un instant donné sélectionné, valider l’environnement restauré et rediriger le trafic de l’application vers la base de données rétablie.
4.5 Restauration des objets et artefacts. Les fichiers téléversés par les clients et les artefacts opérationnels sont stockés dans Amazon S3. La gestion des versions est activée sur le compartiment de téléversement et les compartiments de ressources afin de permettre la reprise après une suppression ou un écrasement accidentel. Les compartiments de déploiement du site Web et de l’interface frontale sont considérés comme des artefacts reproductibles et peuvent être reconstruits à partir du code source plutôt que restaurés à partir de sauvegardes.
4.6 Reprise des charges de travail asynchrones. Les voies de traitement asynchrone utilisent des files d’attente de lettres mortes pour conserver les événements ayant échoué aux fins d’enquête. La reprise peut inclure une nouvelle tentative de traitement des messages ayant échoué, la réexécution de la logique de traitement ou la relecture des tâches lorsque le flux de travail sous-jacent permet un retraitement sûr.
4.7 Reconstruction de l’application et de l’infrastructure. L’infrastructure est gérée au moyen de définitions d’infrastructure en tant que code, gérées dans le contrôle de version. Si l’infrastructure de l’application ou les ressources statiques doivent être recréées, ProcessMind peut reconstruire et redéployer les composants affectés à partir des définitions gérées dans le contrôle de version et des artefacts de compilation.
4.8 Validation avant la remise en service. Avant de clore un incident, ProcessMind valide l’état du service au moyen des outils de surveillance, des journaux, des vérifications synthétiques et de contrôles fonctionnels ciblés disponibles, et rétablit les fonctionnalités affectées en appliquant des procédures validées de déploiement, de reprise et d’infrastructure. Un examen supplémentaire peut être effectué lorsque l’incident a impliqué une restauration de données ou un risque pour l’intégrité des données.
5. Mesures de continuité des activités
5.1 Continuité opérationnelle. ProcessMind tient à jour des procédures opérationnelles documentées afin que la gestion des incidents, la réception des demandes d’assistance des clients, l’intervention des équipes d’ingénierie et la prise de décisions puissent se poursuivre pendant les événements perturbateurs.
5.2 Communications. En cas d’incidents de production substantiels, ProcessMind déploie des efforts commercialement raisonnables pour fournir des mises à jour par l’intermédiaire des canaux d’assistance à la clientèle et, le cas échéant, de la page publique d’état du service à l’adresse processmind.com/status.
5.3 Gestion contrôlée des modifications. Un cycle de développement logiciel reposant sur une défense en profondeur, comprenant plusieurs couches indépendantes de validation automatisée, des déploiements contrôlés, une surveillance centralisée et un examen après incident, est utilisé pour réduire les interruptions évitables et améliorer la continuité au fil du temps.
5.4 Sécurité pendant la reprise. Les mesures de reprise sont exécutées conformément aux mêmes principes généraux de sécurité que ceux applicables en fonctionnement normal, notamment l’accès selon le principe du moindre privilège, la journalisation des activités opérationnelles lorsqu’elle est disponible et le contrôle de l’accès aux systèmes et aux données de production.
6. Synthèse des sauvegardes et de la protection des données
6.1 Sauvegardes des bases de données. Les sauvegardes automatisées Aurora sont chiffrées et conservées pendant sept (7) jours, avec une possibilité de restauration à un instant donné pendant cette période de conservation.
6.2 Protections S3. Amazon S3 offre une grande durabilité pour les objets stockés. Les compartiments de données client modifiables reposent sur la durabilité et la gestion des versions dans la région principale. ProcessMind n’active actuellement pas la réplication interrégionale S3 pour ces compartiments.
6.3 Journaux et diagnostics. Les journaux centralisés, les alarmes et la télémétrie facilitent l’analyse des défaillances et la validation de la reprise. Ces mécanismes contribuent aux opérations de continuité, mais ne sont pas présentés en tant que produit de sauvegarde distinct.
7. Identification et tri des incidents
7.1 Évaluation initiale. Les événements signalés font l’objet d’un tri afin de déterminer s’ils répondent à la définition d’un incident de sécurité, quels systèmes ou données peuvent être concernés, quelle en est l’étendue et la gravité probables, et si un confinement immédiat est nécessaire. La préservation des éléments de preuve est effectuée d’une manière adaptée à la nature de l’incident et aux systèmes concernés.
7.2 Astreinte et escalade. ProcessMind assure une couverture d’astreinte pour les incidents de production, y compris une couverture 24 h/24 et 7 j/7 pour les incidents critiques (tels que définis dans l’accord de niveau de service), afin que les incidents puissent être pris en compte et triés à tout moment.
7.3 Documentation. ProcessMind consigne les conclusions importantes des enquêtes, les mesures de réponse et les décisions de reprise afin que la chronologie de l’incident et les mesures correctives qui en résultent puissent être examinées après l’événement.
8. Communications et notifications
8.1 Communication interne. ProcessMind coordonne les intervenants, les décideurs et les canaux d’assistance afin que la réponse technique et la communication avec les clients restent alignées tout au long du cycle de vie de l’incident.
8.2 Notification des clients. En cas d’incident de sécurité nécessitant une notification au titre de l’avenant relatif au traitement des données (DPA) ou du droit applicable, ProcessMind informe les clients concernés sans retard injustifié et, lorsque cela est possible, dans les soixante-douze (72) heures suivant la prise de connaissance de l’incident. Les notifications comprennent généralement la nature et l’étendue de l’incident, les catégories de données concernées si elles sont connues, les mesures prises pour contenir et corriger l’incident, ainsi que les mesures recommandées aux clients, le cas échéant.
8.3 Mises à jour continues. Lorsque l’incident est toujours en cours ou que des faits importants évoluent, ProcessMind fournit des mises à jour complémentaires à mesure que des informations vérifiées supplémentaires sont disponibles. En cas d’interruptions plus générales des services de production, ProcessMind peut également utiliser les canaux d’assistance client et, le cas échéant, la page publique d’état des services à l’adresse processmind.com/status.
9. Tests, examen et maintenance
ProcessMind examine ces procédures au moins une fois par an et après tout incident important ou changement architectural majeur, teste périodiquement les éléments pertinents de son approche de réponse et de reprise (tels que la restauration des sauvegardes, la reconstruction du déploiement, la surveillance, les alertes et les communications relatives aux incidents), et intègre les enseignements tirés à ses procédures de sécurité, de fiabilité et de continuité.
10. Limites et périmètre contractuel
Le présent document constitue une synthèse générale et ne décrit pas en détail chaque procédure opérationnelle interne, voie d’escalade, méthode d’enquête ou étape de traitement des éléments de preuve. Il n’engage pas ProcessMind à mettre en place une conception distincte de basculement interrégional, une conservation sur stockage immuable pour tous les compartiments modifiables, ni des garanties indépendantes de RTO/RPO au-delà de ce qui est expressément stipulé dans le contrat ou la commande applicable.
En cas de conflit entre le présent document et le contrat client, l’avenant relatif au traitement des données, l’accord de niveau de service ou une disposition légale impérative applicable, ces derniers prévalent.