Plano de resposta a incidentes de segurança

API do QR Branding — Art. 33-34 do RGPD

---

1. Objetivo

Estabelecer um procedimento estruturado para detectar, responder e notificar violações de segurança que afetem dados pessoais, em conformidade com os requisitos do Art. 33 (notificação à autoridade de controle) e do Art. 34 (comunicação aos titulares) do RGPD.

---

2. Definições

---

3. Classificação de incidentes

Nível 1 — Crítico (violação de dados pessoais)

• Exposição de conteúdo de QR com dados pessoais (vCards, e-mails, números de telefone)
• Exposição dos prompts de IA dos usuários
• Vazamento de chaves de API (RapidAPI, provedores de LLM)
• Acesso não autorizado ao Application Insights com dados de usuários
• Comprometimento da cadeia de suprimentos (dependência maliciosa do NuGet)

Nível 2 — Alto (incidente de segurança sem envolvimento confirmado de dados pessoais)

• Exploração bem-sucedida de uma vulnerabilidade (SSRF, injeção etc.)
• Negação de serviço sustentada
• Comprometimento do pipeline de CI/CD (GitHub Actions)
• Acesso não autorizado às App Settings ou aos secrets do Azure
• Comportamento anômalo de um provedor de LLM (respostas com dados de outros usuários)

Nível 3 — Médio (incidente contido)

• Tentativas de ataque detectadas e bloqueadas pela limitação de requisições
• Varredura de vulnerabilidades detectada
• Dependência com CVE publicado (sem exploração confirmada)
• Degradação do serviço por abuso de recursos

Nível 4 — Baixo (evento informativo)

• Tentativas de autenticação malsucedidas
• Acionamentos normais do limite de requisições
• Alertas de desempenho (cold starts, timeouts)

---

4. Procedimento de resposta

Fase 1: Detecção e triagem (T0 → T0+1h)

Fase 2: Contenção (T0+1h → T0+4h)

Fase 3: Notificação do RGPD (quando aplicável)

Art. 33 — Notificação à autoridade de controle (em até 72h a partir de T0)

Só é exigida se a violação representar um risco para os direitos e liberdades das pessoas.

Conteúdo da notificação:

1. Natureza da violação (quais dados, número estimado de titulares)
2. Dados de contato do controlador
3. Consequências prováveis da violação
4. Medidas adotadas ou propostas para remediá-la

Quando a notificação NÃO é exigida:

• Incidentes de disponibilidade (DoS) sem exposição de dados
• Tentativas de ataque bloqueadas com sucesso
• Incidentes que afetam apenas dados não pessoais (configuração, código)

Contexto do QR Branding: Como o serviço é stateless e não armazena dados pessoais, a maioria dos incidentes não constitui uma violação de dados pessoais. As exceções seriam:

• Exposição de logs do Application Insights com metadados das requisições
• Interceptação do tráfego em trânsito (improvável com TLS)
• Comportamento anômalo de um provedor de LLM que exponha prompts de outros usuários

Art. 34 — Comunicação aos titulares

Só é exigida se a violação representar um risco elevado para os direitos e liberdades.

Não é exigida se:

• Os dados estavam criptografados ou anonimizados
• Foram adotadas medidas que garantem que o risco já não é suscetível de se concretizar
• Implicar um esforço desproporcional (nesse caso, faz-se uma comunicação pública)

Fase 4: Erradicação e recuperação (T0+4h → T0+48h)

Fase 5: Pós-incidente (T0+48h → T0+2 semanas)

---

5. Registro de incidentes (Art. 33(5))

Todo incidente deve ser registrado, exija ou não notificação à autoridade. O registro deve incluir:

---

6. Contatos principais

Autoridades de controle (referência)

---

7. Simulações

Será realizada pelo menos uma simulação de resposta a incidentes por ano para:

• Verificar se o procedimento funciona
• Medir os tempos de resposta
• Identificar lacunas de capacidade ou de comunicação
• Familiarizar a equipe com o processo

---

Documento gerado em 2026-03-08. Próxima revisão programada: 2026-09-08.