Procédure de réponse aux incidents de confidentialité — WeInspect

Version v1.0 — 2026-05-04 Conformément à la Loi 25 (RLRQ c P-39.1) art. 3.5 à 3.8 — obligation de notification dans les meilleurs délais.

Ce document est un runbook opérationnel. Il décrit qui fait quoi, dans quel ordre, dans quels délais, lorsqu'un incident de confidentialité touche WeInspect. Il est destiné au DPO, au responsable du projet, et aux personnes ayant des accès admin / production. Une version résumée en langage clair est publiée sur /transparence/incidents.

0. Qu'est-ce qu'un « incident de confidentialité » au sens de la Loi 25

Loi 25 art. 3.6 :

« Constitue un incident de confidentialité :

1° l'accès non autorisé par la loi à un renseignement personnel ;

2° l'utilisation non autorisée par la loi d'un renseignement personnel ;

3° la communication non autorisée par la loi d'un renseignement personnel ;

4° la perte d'un renseignement personnel ou toute autre atteinte à la protection d'un tel renseignement. »

Exemples concrets pour WeInspect :

• Compte inspecteur compromis et utilisé par un tiers
• Faille RLS exposant inspections d'un user à un autre
• Vol/perte d'un appareil contenant données prod (laptop dev, téléphone admin)
• Sous-traitant (Supabase, Stripe, Anthropic, etc.) annonce un incident le concernant
• Erreur d'envoi : PDF d'un client envoyé au mauvais destinataire
• Bug logiciel exposant temporairement des données via URL prévisible
• Attaque DoS qui par effet collatéral expose des logs verbeux contenant PII
• Phishing réussi sur un membre de l'équipe avec accès console admin

Ce qui n'est PAS un incident :

• Tentative d'attaque bloquée (à logger, pas à notifier)
• Accès légitime mais inhabituel (à enquêter, pas notifier sauf confirmation)
• Demande légale gouvernementale formelle (procédure différente — voir §10)

1. Rôles et responsabilités

| Rôle | Personne | Responsabilité incident | |---|---|---| | Incident Commander (IC) | DPO | Coordination, décisions, communication CAI | | Backup IC | Le responsable du projet | Si DPO indisponible >2h | | Tech Lead | À nommer (le responsable du projet par défaut) | Investigation technique, mitigation immédiate | | Comm Lead | Le responsable du projet + ressource externe au besoin | Communication utilisateurs, presse, témoins | | Legal | Avocat externe ([CABINET]) | Conseil juridique conformité Loi 25, recours | | Sous-traitants concernés | Selon DPA signé avec chacun | Coopération investigation, fourniture preuves |

Tous joignables 24/7 dans les 4 premières heures d'un incident matériel.

2. Phases de réponse

Phase 1 — Détection et triage initial (T+0 à T+1h)

Sources possibles de détection :

• Alerte automatisée monitoring (Supabase, Stripe, Sentry mobile)
• Rapport utilisateur (formulaire /aide/signaler-securite, courriel DPO)
• Découverte interne (audit, dev, test)
• Notification d'un sous-traitant
• Découverte par chercheur en sécurité (voir security-vulnerability-policy.md)
• Signalement par un tiers (presse, CAI, autre)

Actions T+0 à T+1h :

1. Enregistrer l'incident dans le journal (template ci-dessous)
2. Évaluer la nature : confirmé / suspect / faux positif
3. Si confirmé ou suspect : escalade IC + Backup IC par téléphone (pas seulement courriel)
4. Snapshot forensique : geler les logs pertinents (Supabase audit, Netlify, Stripe webhooks) avant qu'ils ne soient écrasés par rotation

Template entrée journal :

ID : INC-AAAA-MM-DD-NNN
Date détection : 2026-XX-XX HH:MM (fuseau)
Source : [ex: alerte Supabase RLS]
Description initiale : [court résumé factuel]
Statut : [détecté | en cours | contenu | résolu | clos]
IC : [nom]
Données potentiellement touchées : [catégories]
Personnes potentiellement touchées : [nombre estimé, profil]

Phase 2 — Confinement (T+1h à T+4h)

Objectif : stopper l'hémorragie, pas tout réparer. Différer la cause racine si nécessaire.

Actions de confinement par catégorie :

| Catégorie incident | Actions immédiates | |---|---| | Compte compromis | Forcer logout global de cet user, révoquer refresh tokens, exiger reset MOT et MFA, notifier user | | Faille RLS | Désactiver feature/endpoint concerné via feature flag, déployer hotfix, déclencher tests RLS étendus | | Vol/perte appareil | Révoquer toutes sessions actives liées, changer credentials VAULT, scanner accès récents | | Erreur envoi (PDF mauvais destinataire) | Révoquer immédiatement le token de partage, contacter destinataire erroné pour suppression, contacter client légitime | | Sous-traitant compromis | Évaluer scope (quelles tables/données ?), basculer si possible vers fournisseur de secours (rare, généralement on subit) | | Attaque active (DDoS, bruteforce) | Activer protections Cloudflare/Netlify, IP banning, rate-limit aggressive | | Bug logiciel exposition | Hotfix urgent, désactiver endpoint concerné si pas fixable en <1h |

Phase 3 — Évaluation du risque de préjudice (T+4h à T+24h)

Loi 25 art. 3.5 al. 2 : la notification est obligatoire si l'incident présente un risque qu'un préjudice sérieux soit causé.

Critères d'évaluation du préjudice sérieux (Loi 25 art. 3.7) :

• a. Sensibilité du renseignement
• b. Conséquences appréhendées de son utilisation
• c. Probabilité qu'il soit utilisé à des fins préjudiciables

Matrice de décision WeInspect :

| Cas | Préjudice sérieux ? | Notification CAI ? | Notification utilisateurs ? | |---|---|---|---| | Mot de passe haché fuité (1 user) | Faible | Non | Oui (changement mot de passe préventif) | | Adresse + téléphone client fuité (10 users) | Moyen | Oui | Oui | | Photos intérieur propriété fuitées | Élevé | Oui | Oui (clients + inspecteurs) | | Audio dictée fuité | Élevé | Oui | Oui | | Coordonnées bancaires (jamais stockées chez nous, déléguées Stripe) | N/A pour nous | Stripe gère | Stripe gère | | Tentative bloquée sans accès réussi | Aucun | Non | Non (logger, pas notifier) | | Sous-traitant annonce fuite affectant données WeInspect | Selon scope | Probablement oui | Probablement oui |

Si décision incertaine : notifier par défaut. La Loi 25 sanctionne l'absence de notification, pas l'excès.

Phase 4 — Notification CAI et utilisateurs (T+24h à T+72h)

Notification CAI (obligatoire, art. 3.5 si préjudice sérieux) :

• Délai légal : « dans les meilleurs délais », typiquement 72h max recommandé (analogie RGPD)
• Canal : formulaire CAI <https://www.cai.gouv.qc.ca/protection-renseignements-personnels/formulaire-avis-incident>
• Information à fournir :

- Description de l'incident (qui, quoi, quand) - Catégories de RP touchés - Nombre de personnes touchées - Mesures prises pour contenir - Risques pour les personnes - Mesures recommandées aux personnes - Coordonnées DPO

Notification utilisateurs (obligatoire si préjudice sérieux) :

• Canaux : courriel direct + notification in-app + page publique /transparence/incidents
• Délai : meilleurs délais après notification CAI
• Contenu (template incident-notification-template.md à produire) :

- Description claire en QC français - Quelles données vous concernant ont été touchées - Risques concrets - Que faire (changer mot de passe, surveiller relevés, etc.) - Comment nous contacter - Lien CAI pour plainte

Pour clients d'inspecteurs (acheteurs) :

• Notifier l'inspecteur (responsable du traitement direct)
• Lui fournir un template de notification à transmettre à ses clients
• Co-notifier nous-mêmes si nous avons les coordonnées (ex: visiteur portail récent)

Phase 5 — Remédiation et clôture (T+72h à T+30j)

• Cause racine : RCA (root cause analysis) documentée
• Correctifs : déploiement, tests, vérification
• Mise à jour DPIA si l'incident révèle un risque non identifié
• Mise à jour de ce playbook si la procédure a montré des failles
• Post-mortem partagé (interne) avec leçons apprises
• Post-mortem publié sur /transparence/incidents/INC-... après stabilisation (signe de transparence apprécié)
• Suivi CAI : répondre aux questions complémentaires, fournir documents demandés
• Statut « clos » uniquement après confirmation : (a) cause racine corrigée, (b) toutes les personnes touchées notifiées, (c) CAI a clôturé son dossier ou n'a pas demandé d'action complémentaire, (d) post-mortem publié.

3. Communication

3.1 Principes

• Transparence : ne pas minimiser, ne pas dramatiser, dire ce qu'on sait + ce qu'on ne sait pas
• Rapidité > formulation parfaite (mieux vaut une notification incomplète à T+24h qu'une parfaite à T+10j)
• QC français accessible + EN
• Aucune communication aux médias sans alignement IC + responsable du projet + Legal
• Pas de spéculation : si on ne sait pas, on dit qu'on ne sait pas

3.2 Templates à pré-rédiger (incl. dans la version v1.1 de ce doc)

• T1-internal-alert.md — alerte interne IC + équipe
• T2-cai-notification.md — formulaire CAI structuré
• T3-user-notification-low-severity.md — courriel utilisateur incident faible
• T4-user-notification-high-severity.md — courriel utilisateur incident grave
• T5-buyer-via-inspector.md — template à fournir à l'inspecteur pour ses clients
• T6-press-statement.md — déclaration presse minimale
• T7-postmortem-public.md — squelette post-mortem /transparence/incidents/

À produire en S35 phase 2 (pas bloquant ouverture mais doit exister avant lancement public).

4. Drill annuel

Une simulation incident est exécutée chaque année (cible : septembre) :

• Scénario inventé tenu secret par un facilitateur (le responsable du projet ou un tiers)
• Équipe doit dérouler ce playbook réellement (sauf notifications externes réelles, simulées en interne)
• Mesure de temps : T+0, T+1h, T+4h, T+24h, T+72h
• Post-drill : rétrospective, mise à jour playbook
• Documenté dans /docs/incidents/drill-AAAA.md

5. Métriques

À tracker pour chaque incident :

• Time to detect (TTD) : entre survenue et détection
• Time to contain (TTC) : entre détection et confinement
• Time to notify CAI (TTN-CAI)
• Time to notify users (TTN-user)
• Time to resolve (TTR)
• Number of users impacted
• Categories of data impacted

Cibles internes :

• TTD < 4h pour incident actif (alerte automatisée)
• TTC < 4h pour confinement primaire
• TTN-CAI < 72h
• TTN-user < 24h après TTN-CAI

6. Politiques connexes

• DPIA : dpia-2026-05-04.md
• Politique de confidentialité (art. dédié à la sécurité) : privacy-policy.fr.md §10
• Sous-traitants : subprocessors-list.md
• Politique signalement vulnérabilités externes : security-vulnerability-policy.md

7. Contacts externes

• CAI (formulaire en ligne) : <https://www.cai.gouv.qc.ca>
• Anthropic Trust & Safety : <https://www.anthropic.com/contact>
• OpenAI Trust & Safety : <https://help.openai.com/>
• Stripe Disputes & Compliance : <https://support.stripe.com/>
• Resend Support : <https://resend.com/contact>

8. Coopération avec les sous-traitants

Chaque DPA signé avec un sous-traitant inclut une clause de notification d'incident affectant des données WeInspect. Délai contractuel typique : 24-48h. Si un sous-traitant nous notifie, on déclenche immédiatement ce playbook et on évalue notre propre obligation de notification CAI/utilisateurs.

9. Conservation des preuves

Pour chaque incident, conservation minimum 7 ans (alignement obligation Loi 25 audit) :

• Journal incident
• Captures logs forensiques
• Communications externes (CAI, users)
• Rapport post-mortem

Stockage : repo git privé weinspect-incidents (chiffré, accès limité DPO + responsable du projet + avocat).

10. Demandes légales gouvernementales

Procédure distincte de la procédure incident :

1. Toute demande gouvernementale (ARC, ministère, force publique) reçue → ne pas répondre immédiatement
2. Vérifier la légitimité (mandat valide, juridiction compétente)
3. Consulter avocat externe avant toute fourniture de données
4. Si légalement obligé de fournir : minimiser le scope (only what's mandated), informer l'utilisateur concerné si la loi le permet (gag order absent)
5. Logger toutes ces demandes ; rapport annuel agrégé publié sur /transparence/transparence-gouvernementale (pattern Apple/Google transparency report)

11. Mise à jour de ce playbook

À chaque :

• Incident matériel (post-mortem)
• Drill annuel
• Changement majeur de fournisseur ou de produit
• Évolution Loi 25 ou jurisprudence
• Demande CAI

Versioning : v1.0 — 2026-05-04 ; bump à chaque modif. Historique conservé dans repo.

---

Statut : v1.0 draft Claude. À valider par DPO + avocat externe avant entrée en service. À tester via drill avant lancement public 2026-11-04.