Piano di risposta agli incidenti di sicurezza
API di QR Branding — artt. 33-34 RGPD
| Campo | Valore |
|---|---|
| Titolare del trattamento | QR Branding (Quartzon) |
| Data | 2026-03-08 |
| Versione | 1.0 |
| Prossima revisione | 2026-09-08 |
1. Obiettivo
Definire una procedura strutturata per rilevare, gestire e notificare le violazioni di sicurezza che riguardano dati personali, in conformità ai requisiti dell'art. 33 RGPD (notifica all'autorità di controllo) e dell'art. 34 (comunicazione agli interessati).
2. Definizioni
| Termine | Definizione |
|---|---|
| Violazione dei dati personali | La violazione di sicurezza che comporta accidentalmente o in modo illecito la distruzione, la perdita, la modifica, la divulgazione non autorizzata o l'accesso ai dati personali (art. 4, punto 12, RGPD) |
| Incidente di sicurezza | Qualsiasi evento che comprometta la riservatezza, l'integrità o la disponibilità del sistema, che coinvolga o meno dati personali |
| Tempo zero (T0) | Il momento in cui l'incidente viene rilevato o se ne viene a conoscenza |
3. Classificazione degli incidenti
Livello 1 — Critico (violazione dei dati personali)
- Esposizione di contenuti dei QR con dati personali (vCard, email, numeri di telefono)
- Esposizione dei prompt IA degli utenti
- Fuga di chiavi API (RapidAPI, fornitori di LLM)
- Accesso non autorizzato ad Application Insights contenente dati degli utenti
- Compromissione della supply chain (dipendenza NuGet malevola)
Livello 2 — Alto (incidente di sicurezza senza coinvolgimento confermato di dati personali)
- Sfruttamento riuscito di una vulnerabilità (SSRF, injection, ecc.)
- Negazione del servizio prolungata
- Compromissione della pipeline CI/CD (GitHub Actions)
- Accesso non autorizzato alle Azure App Settings o ai segreti
- Comportamento anomalo di un fornitore di LLM (risposte con dati di altri utenti)
Livello 3 — Medio (incidente contenuto)
- Tentativi di attacco rilevati e bloccati dalla limitazione delle richieste
- Scansione di vulnerabilità rilevata
- Dipendenza con una CVE pubblicata (senza sfruttamento confermato)
- Degrado del servizio dovuto ad abuso delle risorse
Livello 4 — Basso (evento informativo)
- Tentativi di autenticazione falliti
- Normale attivazione del limite di richieste
- Avvisi di prestazione (cold start, timeout)
4. Procedura di risposta
Fase 1: Rilevamento e triage (T0 → T0+1h)
| Passo | Azione | Responsabile |
|---|---|---|
| 1.1 | Identificare l'origine dell'avviso (Application Insights, GitHub Security Advisories, segnalazione di un utente, monitoraggio) | Team tecnico |
| 1.2 | Classificare l'incidente per livello (sezione 3) | Team tecnico |
| 1.3 | Documentare cosa è stato rilevato, quando, come e la portata stimata | Team tecnico |
| 1.4 | Se di livello 1 o 2: segnalare immediatamente alla persona responsabile della protezione dei dati | Team tecnico |
Fase 2: Contenimento (T0+1h → T0+4h)
| Passo | Azione |
|---|---|
| 2.1 | Contenimento immediato, a seconda del tipo di incidente: |
| - Chiave API trapelata → rigenerarla subito nelle Azure App Settings e presso il fornitore | |
| - Vulnerabilità sfruttata → distribuire un hotfix o disattivare l'endpoint interessato | |
| - SSRF/injection → bloccare lo schema di attacco nella convalida | |
| - CI/CD compromessa → revocare i token di GitHub, verificare i commit recenti | |
| 2.2 | Conservare le prove (log di Application Insights, snapshot della configurazione) |
| 2.3 | Verificare che il contenimento sia efficace |
| 2.4 | Valutare se sono coinvolti dati personali → stabilire se si tratta di una violazione ai sensi del RGPD |
Fase 3: Notifica ai sensi del RGPD (se applicabile)
Art. 33 — Notifica all'autorità di controllo (entro 72h da T0)
Necessaria solo se la violazione presenta un rischio per i diritti e le libertà delle persone fisiche.
Contenuto della notifica:
- Natura della violazione (quali dati, numero stimato di interessati)
- Dati di contatto del titolare del trattamento
- Probabili conseguenze della violazione
- Misure adottate o proposte per porvi rimedio
Quando la notifica NON è necessaria:
- Incidenti di disponibilità (DoS) senza esposizione di dati
- Tentativi di attacco bloccati con successo
- Incidenti che riguardano solo dati non personali (configurazione, codice)
Contesto di QR Branding: Poiché il servizio è stateless e non conserva dati personali, la maggior parte degli incidenti non costituisce una violazione dei dati personali. Le eccezioni sarebbero:
- Esposizione di log di Application Insights contenenti metadati delle richieste
- Intercettazione del traffico in transito (improbabile con TLS)
- Comportamento anomalo di un fornitore di LLM che esponga i prompt di altri utenti
Art. 34 — Comunicazione agli interessati
Necessaria solo se la violazione presenta un rischio elevato per i diritti e le libertà.
Non necessaria se:
- I dati erano cifrati o anonimizzati
- Sono state adottate misure che scongiurano il concretizzarsi del rischio
- Richiederebbe sforzi sproporzionati (in tal caso si procede a una comunicazione pubblica)
Fase 4: Eliminazione e ripristino (T0+4h → T0+48h)
| Passo | Azione |
|---|---|
| 4.1 | Identificare ed eliminare la causa principale |
| 4.2 | Applicare patch o correzioni definitive |
| 4.3 | Eseguire test di regressione |
| 4.4 | Distribuire in produzione tramite CI/CD (GitHub Actions → Azure) |
| 4.5 | Verificare che la correzione sia efficace in produzione |
| 4.6 | Monitorare attentamente per 48-72h dopo la correzione |
Fase 5: Post-incidente (T0+48h → T0+2 settimane)
| Passo | Azione |
|---|---|
| 5.1 | Documentare l'incidente in modo completo (cronologia, impatto, risposta) |
| 5.2 | Eseguire un'analisi della causa principale (RCA) |
| 5.3 | Individuare miglioramenti preventivi |
| 5.4 | Aggiornare la DPIA se l'incidente rivela rischi non considerati in precedenza |
| 5.5 | Aggiornare questo piano se emergono lacune nella procedura |
| 5.6 | Condividere le lezioni apprese (senza dati sensibili) |
5. Registro degli incidenti (art. 33, par. 5)
Ogni incidente deve essere registrato, indipendentemente dal fatto che richieda o meno la notifica all'autorità. Il registro deve includere:
| Campo | Descrizione |
|---|---|
| ID dell'incidente | Identificatore univoco (INC-YYYY-NNN) |
| Data/ora del rilevamento | T0 |
| Data/ora del contenimento | Fine della fase 2 |
| Classificazione | Livello 1-4 |
| Descrizione | Cosa è successo |
| Dati coinvolti | Categorie di dati personali interessate (se applicabile) |
| Interessati coinvolti | Numero stimato |
| Causa principale | Esito della RCA |
| Misure adottate | Azioni di contenimento e di rimedio |
| Notifica all'autorità | Sì/No, data, riferimento |
| Comunicazione agli interessati | Sì/No, data, canale |
| Risoluzione | Stato finale e data di chiusura |
6. Contatti principali
| Ruolo | Contatto |
|---|---|
| Responsabile tecnico | Team di QR Branding |
| Privacy/DPO | support@qr-branding.com |
| Piattaforma RapidAPI | Assistenza RapidAPI |
| Assistenza Microsoft Azure | Portale di Azure |
Autorità di controllo (riferimento)
| Paese | Autorità | Sito web |
|---|---|---|
| Spagna | AEPD | aepd.es |
| UE (generale) | EDPB | edpb.europa.eu |
7. Esercitazioni
Si svolgerà almeno un'esercitazione di risposta agli incidenti all'anno per:
- Verificare che la procedura funzioni
- Misurare i tempi di risposta
- Individuare lacune nelle capacità o nella comunicazione
- Familiarizzare il team con il processo
Documento generato il 2026-03-08. Prossima revisione programmata: 2026-09-08.