Security incident response plan

QR Branding API — GDPR Art. 33-34

---

1. Objective

To set out a structured procedure for detecting, responding to and notifying security breaches affecting personal data, in compliance with the requirements of GDPR Art. 33 (notification to the supervisory authority) and Art. 34 (communication to data subjects).

---

2. Definitions

---

3. Incident classification

Level 1 — Critical (personal data breach)

• Exposure of QR content containing personal data (vCards, emails, phone numbers)
• Exposure of users' AI prompts
• Leakage of API keys (RapidAPI, LLM providers)
• Unauthorized access to Application Insights containing user data
• Supply chain compromise (malicious NuGet dependency)

Level 2 — High (security incident with no confirmed personal data involved)

• Successful exploitation of a vulnerability (SSRF, injection, etc.)
• Sustained denial of service
• Compromise of the CI/CD pipeline (GitHub Actions)
• Unauthorized access to Azure App Settings or secrets
• Anomalous LLM provider behavior (responses containing other users' data)

Level 3 — Medium (contained incident)

• Attack attempts detected and blocked by rate limiting
• Vulnerability scanning detected
• Dependency with a published CVE (no confirmed exploitation)
• Service degradation due to resource abuse

Level 4 — Low (informational event)

• Failed authentication attempts
• Normal rate limit triggers
• Performance alerts (cold starts, timeouts)

---

4. Response procedure

Phase 1: Detection and triage (T0 → T0+1h)

Phase 2: Containment (T0+1h → T0+4h)

Phase 3: GDPR notification (where applicable)

Art. 33 — Notification to the supervisory authority (within 72h of T0)

Only required if the breach poses a risk to the rights and freedoms of individuals.

Content of the notification:

1. Nature of the breach (which data, estimated number of data subjects)
2. Controller's contact details
3. Likely consequences of the breach
4. Measures taken or proposed to address it

When notification is NOT required:

• Availability incidents (DoS) with no data exposure
• Attack attempts that were successfully blocked
• Incidents affecting only non-personal data (configuration, code)

QR Branding context: Because the service is stateless and does not store personal data, most incidents do not constitute a personal data breach. The exceptions would be:

• Exposure of Application Insights logs containing request metadata
• Interception of traffic in transit (unlikely with TLS)
• Anomalous LLM provider behavior exposing other users' prompts

Art. 34 — Communication to data subjects

Only required if the breach poses a high risk to rights and freedoms.

Not required if:

• The data was encrypted or anonymized
• Measures have been taken that ensure the risk is no longer likely to materialize
• It would involve disproportionate effort (in which case a public communication is made)

Phase 4: Eradication and recovery (T0+4h → T0+48h)

Phase 5: Post-incident (T0+48h → T0+2 weeks)

---

5. Incident log (Art. 33(5))

Every incident must be logged, whether or not it requires notification to the authority. The log must include:

---

6. Key contacts

Supervisory authorities (reference)

---

7. Drills

At least one incident response drill per year will be carried out to:

• Verify that the procedure works
• Measure response times
• Identify gaps in capabilities or communication
• Familiarize the team with the process

---

Document generated on 2026-03-08. Next scheduled review: 2026-09-08.