Plan de réponse aux incidents de sécurité
API QR Branding — art. 33-34 du RGPD
| Champ | Valeur |
|---|---|
| Responsable du traitement | QR Branding (Quartzon) |
| Date | 2026-03-08 |
| Version | 1.0 |
| Prochaine revue | 2026-09-08 |
1. Objectif
Établir une procédure structurée pour détecter les violations de sécurité touchant des données personnelles, y répondre et les notifier, conformément aux exigences de l'art. 33 du RGPD (notification à l'autorité de contrôle) et de l'art. 34 (communication aux personnes concernées).
2. Définitions
| Terme | Définition |
|---|---|
| Violation de données personnelles | Une violation de la sécurité entraînant, de manière accidentelle ou illicite, la destruction, la perte, l'altération ou la divulgation non autorisée de données personnelles (art. 4(12) du RGPD) |
| Incident de sécurité | Tout événement qui compromet la confidentialité, l'intégrité ou la disponibilité du système, qu'il implique ou non des données personnelles |
| Instant zéro (T0) | Le moment où l'incident est détecté ou porté à notre connaissance |
3. Classification des incidents
Niveau 1 — Critique (violation de données personnelles)
- Exposition de contenu de QR contenant des données personnelles (vCard, e-mails, numéros de téléphone)
- Exposition des prompts IA des utilisateurs
- Fuite de clés API (RapidAPI, fournisseurs de LLM)
- Accès non autorisé à Application Insights contenant des données d'utilisateurs
- Compromission de la chaîne d'approvisionnement (dépendance NuGet malveillante)
Niveau 2 — Élevé (incident de sécurité sans données personnelles confirmées)
- Exploitation réussie d'une vulnérabilité (SSRF, injection, etc.)
- Déni de service prolongé
- Compromission du pipeline CI/CD (GitHub Actions)
- Accès non autorisé aux Azure App Settings ou aux secrets
- Comportement anormal d'un fournisseur de LLM (réponses contenant des données d'autres utilisateurs)
Niveau 3 — Moyen (incident contenu)
- Tentatives d'attaque détectées et bloquées par la limitation de débit
- Analyse de vulnérabilités détectée
- Dépendance faisant l'objet d'une CVE publiée (sans exploitation confirmée)
- Dégradation du service due à un abus de ressources
Niveau 4 — Faible (événement informatif)
- Tentatives d'authentification échouées
- Déclenchements normaux de la limite de débit
- Alertes de performance (démarrages à froid, délais dépassés)
4. Procédure de réponse
Phase 1 : détection et tri (T0 → T0+1h)
| Étape | Action | Responsable |
|---|---|---|
| 1.1 | Identifier la source de l'alerte (Application Insights, GitHub Security Advisories, signalement d'un utilisateur, supervision) | Équipe technique |
| 1.2 | Classer l'incident par niveau (section 3) | Équipe technique |
| 1.3 | Documenter ce qui a été détecté, quand, comment, et l'étendue estimée | Équipe technique |
| 1.4 | Niveau 1 ou 2 : escalader immédiatement auprès de la personne chargée de la protection des données | Équipe technique |
Phase 2 : confinement (T0+1h → T0+4h)
| Étape | Action |
|---|---|
| 2.1 | Confinement immédiat, selon le type d'incident : |
| - Clé API divulguée → la renouveler immédiatement dans les Azure App Settings et chez le fournisseur | |
| - Vulnérabilité exploitée → déployer un correctif urgent ou désactiver l'endpoint concerné | |
| - SSRF/injection → bloquer le motif d'attaque dans la validation | |
| - CI/CD compromis → révoquer les tokens GitHub, auditer les commits récents | |
| 2.2 | Préserver les preuves (journaux Application Insights, instantanés de configuration) |
| 2.3 | Vérifier que le confinement est efficace |
| 2.4 | Évaluer si des données personnelles sont touchées → déterminer s'il s'agit d'une violation au sens du RGPD |
Phase 3 : notification au titre du RGPD (le cas échéant)
Art. 33 — Notification à l'autorité de contrôle (dans les 72h suivant T0)
Obligatoire uniquement si la violation présente un risque pour les droits et libertés des personnes.
Contenu de la notification :
- Nature de la violation (quelles données, nombre estimé de personnes concernées)
- Coordonnées du responsable du traitement
- Conséquences probables de la violation
- Mesures prises ou proposées pour y remédier
Cas où la notification n'est PAS obligatoire :
- Incidents de disponibilité (DoS) sans exposition de données
- Tentatives d'attaque bloquées avec succès
- Incidents ne touchant que des données non personnelles (configuration, code)
Contexte de QR Branding : Comme le service est sans état et ne stocke pas de données personnelles, la plupart des incidents ne constituent pas une violation de données personnelles. Les exceptions seraient :
- L'exposition de journaux Application Insights contenant des métadonnées de requêtes
- L'interception du trafic en transit (peu probable avec TLS)
- Un comportement anormal d'un fournisseur de LLM exposant les prompts d'autres utilisateurs
Art. 34 — Communication aux personnes concernées
Obligatoire uniquement si la violation présente un risque élevé pour les droits et libertés.
Non obligatoire si :
- Les données étaient chiffrées ou anonymisées
- Des mesures ont été prises qui garantissent que le risque n'est plus susceptible de se matérialiser
- Elle exigerait des efforts disproportionnés (une communication publique est alors effectuée)
Phase 4 : éradication et rétablissement (T0+4h → T0+48h)
| Étape | Action |
|---|---|
| 4.1 | Identifier et éliminer la cause racine |
| 4.2 | Appliquer des correctifs permanents |
| 4.3 | Exécuter des tests de non-régression |
| 4.4 | Déployer en production via CI/CD (GitHub Actions → Azure) |
| 4.5 | Vérifier que le correctif est efficace en production |
| 4.6 | Surveiller de près pendant 48-72h après le correctif |
Phase 5 : post-incident (T0+48h → T0+2 semaines)
| Étape | Action |
|---|---|
| 5.1 | Documenter l'incident complet (chronologie, impact, réponse) |
| 5.2 | Mener une analyse des causes racines (RCA) |
| 5.3 | Identifier des améliorations préventives |
| 5.4 | Mettre à jour l'AIPD si l'incident révèle des risques non envisagés jusque-là |
| 5.5 | Mettre à jour ce plan si des lacunes de la procédure sont identifiées |
| 5.6 | Partager les enseignements tirés (sans données sensibles) |
5. Registre des incidents (art. 33(5))
Tout incident doit être consigné, qu'il nécessite ou non une notification à l'autorité. Le registre doit comprendre :
| Champ | Description |
|---|---|
| ID de l'incident | Identifiant unique (INC-YYYY-NNN) |
| Date/heure de détection | T0 |
| Date/heure de confinement | Fin de la phase 2 |
| Classification | Niveau 1-4 |
| Description | Ce qui s'est passé |
| Données touchées | Catégories de données personnelles concernées (le cas échéant) |
| Personnes concernées touchées | Nombre estimé |
| Cause racine | Résultat de la RCA |
| Mesures prises | Actions de confinement et de remédiation |
| Notification à l'autorité | Oui/Non, date, référence |
| Communication aux personnes concernées | Oui/Non, date, canal |
| Résolution | État final et date de clôture |
6. Contacts clés
| Rôle | Contact |
|---|---|
| Responsable technique | Équipe QR Branding |
| Confidentialité/DPD | support@qr-branding.com |
| Plateforme RapidAPI | Support RapidAPI |
| Support Microsoft Azure | Portail Azure |
Autorités de contrôle (référence)
| Pays | Autorité | Site web |
|---|---|---|
| Espagne | AEPD | aepd.es |
| UE (général) | CEPD (EDPB) | edpb.europa.eu |
7. Exercices
Au moins un exercice de réponse aux incidents par an sera réalisé pour :
- Vérifier que la procédure fonctionne
- Mesurer les temps de réponse
- Identifier les lacunes en matière de capacités ou de communication
- Familiariser l'équipe avec le processus
Document généré le 2026-03-08. Prochaine revue prévue : 2026-09-08.