Plan de respuesta a incidentes de seguridad
QR Branding API — RGPD Art. 33-34
| Campo | Valor |
|---|---|
| Responsable | QR Branding (Quartzon) |
| Fecha | 2026-03-08 |
| Versión | 1.0 |
| Próxima revisión | 2026-09-08 |
1. Objetivo
Establecer un procedimiento estructurado para detectar y notificar las violaciones de la seguridad que afecten a datos personales, y responder a ellas, cumpliendo los requisitos del Art. 33 (notificación a la autoridad de control) y del Art. 34 (comunicación a los interesados) del RGPD.
2. Definiciones
| Término | Definición |
|---|---|
| Violación de la seguridad de los datos personales (brecha) | Toda violación de la seguridad que ocasione la destrucción, pérdida o alteración accidental o ilícita de datos personales, o la comunicación o el acceso no autorizados a dichos datos (Art. 4(12) RGPD) |
| Incidente de seguridad | Cualquier evento que comprometa la confidencialidad, la integridad o la disponibilidad del sistema, afecte o no a datos personales |
| Tiempo cero (T0) | Momento en que se detecta el incidente o se tiene conocimiento de él |
3. Clasificación de incidentes
Nivel 1 — Crítico (brecha de datos personales)
- Exposición de contenido QR con datos personales (vCards, emails, teléfonos)
- Exposición de prompts de IA de los usuarios
- Filtración de claves de API (RapidAPI, proveedores LLM)
- Acceso no autorizado a Application Insights con datos de usuarios
- Compromiso de la cadena de suministro (dependencia NuGet maliciosa)
Nivel 2 — Alto (incidente de seguridad sin datos personales confirmados)
- Explotación con éxito de una vulnerabilidad (SSRF, inyección, etc.)
- Denegación de servicio sostenida
- Compromiso del pipeline de CI/CD (GitHub Actions)
- Acceso no autorizado a Azure App Settings o a los secretos
- Comportamiento anómalo de un proveedor LLM (respuestas con datos de otros usuarios)
Nivel 3 — Medio (incidente contenido)
- Intentos de ataque detectados y bloqueados por el límite de peticiones
- Escaneo de vulnerabilidades detectado
- Dependencia con un CVE publicado (sin explotación confirmada)
- Degradación del servicio por abuso de recursos
Nivel 4 — Bajo (evento informativo)
- Intentos de autenticación fallidos
- Activaciones normales del límite de peticiones
- Alertas de rendimiento (arranques en frío, timeouts)
4. Procedimiento de respuesta
Fase 1: Detección y triaje (T0 → T0+1h)
| Paso | Acción | Responsable |
|---|---|---|
| 1.1 | Identificar el origen de la alerta (Application Insights, GitHub Security Advisories, aviso de un usuario, monitorización) | Equipo técnico |
| 1.2 | Clasificar el incidente según los niveles (sección 3) | Equipo técnico |
| 1.3 | Documentar qué se detectó, cuándo, cómo y el alcance estimado | Equipo técnico |
| 1.4 | Si es de nivel 1 o 2: escalarlo de inmediato al responsable de protección de datos | Equipo técnico |
Fase 2: Contención (T0+1h → T0+4h)
| Paso | Acción |
|---|---|
| 2.1 | Contención inmediata, según el tipo de incidente: |
| - Clave de API filtrada → rotarla de inmediato en Azure App Settings y en el proveedor | |
| - Vulnerabilidad explotada → desplegar un hotfix o deshabilitar el endpoint afectado | |
| - SSRF/inyección → bloquear el patrón de ataque en la validación | |
| - CI/CD comprometido → revocar los tokens de GitHub y auditar los commits recientes | |
| 2.2 | Preservar las evidencias (logs de Application Insights, capturas de la configuración) |
| 2.3 | Verificar que la contención es efectiva |
| 2.4 | Evaluar si hay datos personales afectados → determinar si es una brecha en el sentido del RGPD |
Fase 3: Notificación conforme al RGPD (si procede)
Art. 33 — Notificación a la autoridad de control (en un plazo de 72h desde T0)
Solo es obligatoria si la brecha supone un riesgo para los derechos y libertades de las personas.
Contenido de la notificación:
- Naturaleza de la brecha (qué datos y cuántos interesados, de forma estimada)
- Datos de contacto del responsable
- Consecuencias probables de la brecha
- Medidas adoptadas o propuestas para ponerle remedio
Cuándo NO es necesario notificar:
- Incidentes de disponibilidad (DoS) sin exposición de datos
- Intentos de ataque bloqueados con éxito
- Incidentes que solo afectan a datos no personales (configuración, código)
Contexto de QR Branding: Como el servicio es sin estado y no almacena datos personales, la mayoría de los incidentes no constituyen una brecha de datos personales. Las excepciones serían:
- Exposición de logs de Application Insights que contengan metadatos de peticiones
- Interceptación del tráfico en tránsito (improbable con TLS)
- Comportamiento anómalo de un proveedor LLM que exponga prompts de otros usuarios
Art. 34 — Comunicación a los interesados
Solo es obligatoria si la brecha supone un alto riesgo para los derechos y libertades.
No es necesaria si:
- Los datos estaban cifrados o anonimizados
- Se han adoptado medidas que garantizan que el riesgo ya no llegará a materializarse
- Supondría un esfuerzo desproporcionado (en ese caso, se hace una comunicación pública)
Fase 4: Erradicación y recuperación (T0+4h → T0+48h)
| Paso | Acción |
|---|---|
| 4.1 | Identificar y eliminar la causa raíz |
| 4.2 | Aplicar parches o correcciones permanentes |
| 4.3 | Ejecutar los tests de regresión |
| 4.4 | Desplegar en producción mediante CI/CD (GitHub Actions → Azure) |
| 4.5 | Verificar que la corrección es efectiva en producción |
| 4.6 | Vigilar de cerca durante las 48-72h siguientes a la corrección |
Fase 5: Postincidente (T0+48h → T0+2 semanas)
| Paso | Acción |
|---|---|
| 5.1 | Documentar el incidente completo (cronología, impacto, respuesta) |
| 5.2 | Realizar el análisis de causa raíz (Root Cause Analysis) |
| 5.3 | Identificar mejoras preventivas |
| 5.4 | Actualizar la DPIA si el incidente revela riesgos no contemplados |
| 5.5 | Actualizar este plan si se detectan carencias en el procedimiento |
| 5.6 | Compartir las lecciones aprendidas (sin datos sensibles) |
5. Registro de incidentes (Art. 33(5))
Todos los incidentes deben registrarse, requieran o no notificación a la autoridad. El registro debe incluir:
| Campo | Descripción |
|---|---|
| ID del incidente | Identificador único (INC-YYYY-NNN) |
| Fecha y hora de detección | T0 |
| Fecha y hora de contención | Fin de la fase 2 |
| Clasificación | Nivel 1-4 |
| Descripción | Qué ocurrió |
| Datos afectados | Categorías de datos personales implicadas (si procede) |
| Interesados afectados | Número estimado |
| Causa raíz | Resultado del RCA |
| Medidas adoptadas | Acciones de contención y corrección |
| Notificación a la autoridad | Sí/No, fecha, referencia |
| Comunicación a los interesados | Sí/No, fecha, medio |
| Resolución | Estado final y fecha de cierre |
6. Contactos clave
| Rol | Contacto |
|---|---|
| Responsable técnico | Equipo de QR Branding |
| Privacidad/DPO | support@qr-branding.com |
| Plataforma RapidAPI | Soporte de RapidAPI |
| Soporte de Microsoft Azure | Portal de Azure |
Autoridades de control (referencia)
| País | Autoridad | Web |
|---|---|---|
| España | AEPD | aepd.es |
| UE (general) | EDPB | edpb.europa.eu |
7. Simulacros
Se realizará al menos un simulacro anual de respuesta a incidentes para:
- Verificar que el procedimiento funciona
- Medir los tiempos de respuesta
- Identificar carencias de capacidades o de comunicación
- Familiarizar al equipo con el proceso
Documento generado el 2026-03-08. Próxima revisión programada: 2026-09-08.