Conformidade em cibersegurança 2026: uma violação, muitos prazos de notificação

Pensa numa empresa SaaS europeia com clientes na UE, nos Estados Unidos, no Brasil e na Índia. Uma única intrusão pode pôr a correr um prazo de seis horas na Índia, um de 24 horas com a NIS2, um de 72 horas com o RGPD, um de três dias úteis no Brasil e prazos de 30 dias em vários estados dos EUA, cada um com o seu próprio gatilho, destinatário e conteúdo.

A seguir: esses prazos num só sítio e, depois, o que tem de existir antes: marcas temporais demonstráveis, triagem, uma matriz de notificação, tratamento de provas e um ensaio. Isto é orientação de engenharia, não aconselhamento jurídico: é o teu advogado quem decide se, quando e o que notificar.

Primeira pergunta: de quem é o prazo?

A maior parte dos dados que uma empresa SaaS B2B guarda pertence aos seus clientes. Para esses dados és subcontratante (RGPD), operador (LGPD) ou business associate (HIPAA), e os prazos perante os reguladores são dos teus clientes. O teu trabalho é avisá-los a tempo:

• Artigo 33.º, n.º 2, do RGPD: notifica o responsável pelo tratamento sem demora injustificada. O Comité Europeu para a Proteção de Dados considera que o responsável toma conhecimento assim que o avisas, por isso o teu atraso come-lhe as 72 horas.
• HIPAA: notifica a entidade abrangida sem atraso injustificado e no prazo de 60 dias de calendário a contar da descoberta.
• DORA: nunca reportas a um supervisor, mas os contratos com entidades financeiras têm de te obrigar a prestar assistência em incidentes de TIC (artigo 30.º, n.º 2, alínea f)), e o teu cliente pode ter quatro horas a partir do momento em que o classifica como grave.
• Os teus acordos de subcontratação: muitos fixam um número de horas. Esse número é o teu prazo real.

Para os teus próprios dados (contactos de contas, faturação, colaboradores, leads) és o responsável pelo tratamento, e os prazos abaixo são teus. Há um regime que ignora esta divisão: as perguntas frequentes da CERT-In dizem que qualquer entidade que detete um incidente tem de o reportar, e que esse dever não se transfere por contrato.

Os prazos da UE: RGPD, NIS2 e DORA

Artigo 33.º do RGPD, a autoridade de controlo. O gatilho é tomar conhecimento de uma violação de dados pessoais, que o CEPD interpreta como um grau razoável de certeza de que houve dados pessoais comprometidos, depois de uma breve investigação inicial. Notifica sem demora injustificada e, sempre que possível, no prazo de 72 horas, a menos que a violação não seja suscetível de resultar num risco para as pessoas. Conteúdo: a natureza da violação, o número aproximado de pessoas e de registos, um ponto de contacto, as consequências prováveis e as medidas tomadas. A informação pode ser dada por fases.

Artigo 34.º do RGPD, as pessoas afetadas. Quando o risco é elevado, sem demora injustificada e em linguagem clara; não é obrigatório se os dados eram ininteligíveis para o atacante, por exemplo por estarem cifrados.

Artigo 23.º da NIS2. Aplica-se a entidades essenciais e importantes: sobretudo organizações de média dimensão ou maiores dos setores dos anexos I e II. Os considerandos da diretiva incluem o SaaS entre os modelos de serviço de computação em nuvem, por isso uma empresa SaaS dessa dimensão pode estar abrangida. Perante um incidente significativo, o CSIRT nacional ou a autoridade competente recebe:

• Um alerta precoce no prazo de 24 horas a contar do conhecimento: suspeita-se de uma ação maliciosa? pode haver impacto transfronteiriço?
• Uma notificação do incidente no prazo de 72 horas: avaliação inicial da gravidade e do impacto, indicadores de comprometimento.
• Um relatório final no prazo de um mês após a notificação do incidente: causa raiz, mitigação, impacto transfronteiriço.

Para os fornecedores de cloud, o Regulamento de Execução (UE) 2024/2690 considera significativo qualquer comprometimento dos dados do serviço causado por uma suspeita de ação maliciosa, e um serviço totalmente indisponível durante mais de 30 minutos. A transposição devia estar concluída até 17 de outubro de 2024; em julho de 2026 a Comissão levou quatro Estados-Membros ao Tribunal de Justiça por não terem notificado a transposição completa. Os portais e formulários dependem da lei nacional.

DORA, para entidades financeiras desde 17 de janeiro de 2025. Perante um incidente grave relacionado com as TIC: notificação inicial nas quatro horas seguintes à sua classificação como grave e, no máximo, 24 horas depois de tomar conhecimento; relatório intermédio nas 72 horas seguintes à notificação inicial; relatório final no prazo de um mês após o último relatório intermédio.

Brasil, Índia e Estados Unidos

Brasil: artigo 48.º da LGPD e Resolução CD/ANPD n.º 15/2024. O controlador comunica à ANPD e aos titulares afetados no prazo de três dias úteis a contar do momento em que sabe que o incidente afetou dados pessoais. Isto aplica-se quando o incidente pode afetar significativamente os direitos das pessoas e envolve dados sensíveis, dados de crianças, adolescentes ou idosos, dados financeiros ou de autenticação, dados protegidos por sigilo legal ou profissional, ou uma larga escala. O formulário eletrónico da ANPD, submetido pelo encarregado (o DPO) ou por um representante, cobre doze pontos e pode ser complementado no prazo de 20 dias úteis. Todos os incidentes, comunicados ou não, entram num registo guardado durante pelo menos cinco anos.

Índia: Diretivas da CERT-In de 28 de abril de 2022. Reporta nas seis horas seguintes a detetares um incidente ou a seres informado dele. O anexo I enumera vinte tipos, do acesso não autorizado a ataques a sistemas cloud; as perguntas frequentes incluem as violações e fugas de dados entre os que têm de cumprir as seis horas. Envia o que souberes e acrescenta o resto depois, por email (incident@cert-in.org.in), telefone ou fax. As perguntas frequentes aplicam as Diretivas a qualquer entidade em matéria de ciberincidentes.

Índia: Lei DPDP de 2023 e Regras DPDP de 2025. A regra 7 obriga a informar sem demora cada titular dos dados afetado e o Data Protection Board, e a enviar ao Board um relatório detalhado no prazo de 72 horas. Tal como foi publicada em novembro de 2025, a regra 7 entra em vigor dezoito meses após a publicação, em maio de 2027. Até lá, é a CERT-In que marca o prazo da Índia.

Estados Unidos. Não há uma lei federal única sobre violações de dados; cada estado protege os seus residentes, esteja a tua empresa onde estiver:

• Washington, Nova Iorque, Florida: notifica os residentes sem atraso injustificado e no prazo de 30 dias a contar da descoberta (na Florida, a contar da determinação da violação).
• Utah: sem atraso injustificado, sem um número fixo de dias.
• Reguladores: o procurador-geral de Washington acima de 500 residentes e o Departamento de Assuntos Jurídicos da Florida a partir de 500, ambos em 30 dias; o procurador-geral do Utah a partir de 500; o procurador-geral, o Departamento de Estado e a Polícia Estadual de Nova Iorque; um exemplar do aviso ao procurador-geral da Califórnia acima de 500.

Por setor:

• Formulário 8-K da SEC, ponto 1.05: uma empresa cotada nos EUA decide sobre a materialidade sem atraso injustificado depois da descoberta e, a seguir, submete o formulário em quatro dias úteis. Os emitentes privados estrangeiros usam o formulário 6-K.
• HIPAA: as pessoas no prazo de 60 dias de calendário a contar da descoberta, e o HHS ao mesmo tempo quando há 500 ou mais pessoas afetadas.
• Safeguards Rule da FTC: as instituições financeiras não bancárias notificam a FTC no prazo de 30 dias a contar da descoberta de uma aquisição não autorizada de dados não cifrados de 500 ou mais consumidores.
• CIRCIA: 72 horas para os incidentes abrangidos quando a regra final da CISA entrar em vigor; em novembro de 2026 ainda não entrou, por isso ainda não há nada a reportar.

Quando começa o prazo e como o provas

O RGPD e a NIS2 falam em «tomar conhecimento», a CERT-In em «detetar», a ANPD em saber que houve dados pessoais afetados, a HIPAA e a FTC na «descoberta» por qualquer colaborador, e a HIPAA inclui o que uma diligência razoável teria revelado. A SEC começa a contar na decisão sobre a materialidade, e o DORA na classificação. Cada um tem de ser uma marca temporal defensável:

• Uma só base de tempo. Guarda em UTC. A CERT-In exige relógios que não se desviem dos servidores de hora nacionais da Índia, aceita UTC e pede que registes o fuso horário; o Regulamento de Execução (UE) 2024/2690 pede fontes de tempo sincronizadas. Cria um alerta para qualquer host em que timedatectl show -p NTPSynchronized --value deixe de imprimir yes.
• Um único registo do incidente, com um campo por gatilho e por envio, porque o relatório final da NIS2 e os relatórios seguintes do DORA contam a partir do que submeteste:

# all times UTC, from NTP-synchronized hosts
id: INC-2026-0142
declared_at: 2026-11-17T10:05:00Z
triggers:
  first_alert_at: 2026-11-17T09:12:44Z          # explain any gap to noticed_at
  noticed_at: 2026-11-17T09:40:00Z              # CERT-In
  aware_significant_at: 2026-11-17T11:15:00Z    # NIS2
  aware_personal_data_at: 2026-11-17T14:30:00Z  # GDPR, LGPD, US states
  classified_major_at: null                     # DORA, financial entities
  materiality_determined_at: null               # SEC, if US-listed
submitted:
  certin_report_at: null
  nis2_early_warning_at: null
  nis2_notification_at: null                    # final report due one month later
  controller_notices: []                        # per customer: deadline, sent_at

As autoridades vão perguntar pelo intervalo entre first_alert_at e noticed_at. Se os alertas ficam à espera da manhã, as seis horas desaparecem antes de alguém os ler; fechar esse intervalo é para isso que servem as operações de NOC 24/7.

Triagem: que prazos estão a correr?

Faz isto na primeira hora e sempre que os factos mudarem:

1. 1Há algo a reportar? O acesso não autorizado está na lista da CERT-In. As entidades abrangidas pela NIS2 verificam os critérios de incidente significativo.
2. 2Há dados pessoais afetados? Confidencialidade, integridade ou disponibilidade. Alguns incidentes nem tocam na tua infraestrutura, como os dados de clientes colados num chatbot de IA gratuito.
3. 3Em que papel? Conteúdo de clientes (subcontratante) ou os teus próprios dados (responsável).
4. 4Onde vivem as pessoas? Precisas de um mapa de dados por país, e por estado nos EUA, feito de antemão. Sem ele, todas as jurisdições entram em jogo.
5. 5Que setores? Clientes que são entidades financeiras, saúde nos EUA, credores não bancários, e se és uma entidade abrangida pela NIS2.
6. 6Estás cotado nos EUA? Arranca com o processo de materialidade.

O resultado são os prazos em curso, com o vencimento em UTC. Calcula-os, não os faças à mão sob pressão:

#!/usr/bin/env bash
# clocks.sh: first-wave deadlines, an estimate counsel confirms.
# Needs GNU date; the holiday file has one YYYY-MM-DD per line.
set -euo pipefail

NOTICED_AT="2026-11-17T09:40:00Z"             # CERT-In
AWARE_SIGNIFICANT_AT="2026-11-17T11:15:00Z"   # NIS2
AWARE_PERSONAL_DATA_AT="2026-11-17T14:30:00Z" # GDPR, LGPD, US states
BR_HOLIDAYS="holidays-br.txt"
[[ -r "$BR_HOLIDAYS" ]] || { echo "missing $BR_HOLIDAYS" >&2; exit 1; }

plus_hours() {
  date -u -d "@$(( $(date -u -d "$1" +%s) + $2 * 3600 ))" +%Y-%m-%dT%H:%MZ
}

# Count from the next local day in the regulator's time zone,
# skipping weekends and listed holidays.
plus_business_days() {
  local day n=0
  day=$(TZ="$3" date -d "$1" +%F)
  while (( n < $2 )); do
    day=$(date -u -d "$day +1 day" +%F)
    (( $(date -u -d "$day" +%u) >= 6 )) && continue
    grep -qx "$day" "$4" && continue
    n=$((n + 1))
  done
  echo "$day (end of day, $3)"
}

echo "CERT-In report          $(plus_hours "$NOTICED_AT" 6)"
echo "NIS2 early warning      $(plus_hours "$AWARE_SIGNIFICANT_AT" 24)"
echo "NIS2 notification       $(plus_hours "$AWARE_SIGNIFICANT_AT" 72)"
echo "GDPR authority          $(plus_hours "$AWARE_PERSONAL_DATA_AT" 72)"
echo "LGPD ANPD and subjects  $(plus_business_days "$AWARE_PERSONAL_DATA_AT" 3 America/Sao_Paulo "$BR_HOLIDAYS")"
echo "WA, NY, FL residents    $(plus_hours "$AWARE_PERSONAL_DATA_AT" $((30 * 24)))"

Exemplo prático: com estes dados de entrada, a CERT-In vence às 15:40 UTC da mesma terça-feira e o RGPD na sexta-feira às 14:30 UTC. A data da LGPD é segunda-feira, 23 de novembro, porque sexta-feira, 20 de novembro, é feriado nacional no Brasil. O teu advogado confirma como se contam os dias úteis.

A matriz de notificação, escrita de antemão

Uma entrada por destinatário, acordada antes de qualquer incidente, por esta ordem: prazo, gatilho, conteúdo mínimo, quem envia, modelo.

• Clientes cujos dados tratas: as horas de cada acordo de subcontratação, a contar da confirmação de que os dados deles foram atingidos; o que aconteceu, que tenants e conjuntos de dados, a janela temporal, as medidas, um contacto; customer success; um aviso por tenant.
• Clientes que são entidades financeiras: horas contratuais dimensionadas para os limites do DORA deles; os factos de que a notificação inicial deles precisa; o gestor da conta; uma ficha de factos.
• CERT-In: seis horas a contar da deteção; o que sabes até ao momento; o teu ponto de contacto designado; o formulário de reporte da CERT-In.
• Autoridade da NIS2: 24 e 72 horas a contar do conhecimento e, depois, um mês a contar da notificação; o conteúdo do artigo 23.º, n.º 4; o responsável de segurança; o portal nacional.
• Autoridade de controlo principal do RGPD: 72 horas a contar do conhecimento; o conteúdo do artigo 33.º, n.º 3; o DPO; o formulário online da autoridade.
• ANPD: três dias úteis a contar do momento em que sabes que houve dados pessoais afetados; os doze pontos; o encarregado; o formulário eletrónico da ANPD.
• Pessoas afetadas: com o RGPD, quando o risco é elevado; com a LGPD, em três dias úteis; nos estados dos EUA, dentro dos respetivos limites; avisos em linguagem clara em cada língua, aprovados pelo advogado.
• Reguladores dos EUA: os procuradores-gerais conforme cada estado exigir; a SEC em quatro dias úteis a contar de uma decisão de materialidade.

Não sabes quais destes prazos conseguirias cumprir hoje? Pede uma avaliação gratuita da preparação para incidentes: fazemos a triagem com o teu mapa de dados, verificamos as marcas temporais e a retenção de logs face aos teus prazos e entregamos-te uma matriz de notificação com as lacunas assinaladas.

Logs e provas que tens de ter prontos já

A retenção que as regras fixam:

• CERT-In: logs de todos os sistemas TIC durante 180 dias contínuos. A Diretiva diz que dentro da jurisdição indiana; as perguntas frequentes permitem guardá-los no estrangeiro se os conseguires apresentar num prazo razoável.
• Brasil, artigo 15.º do Marco Civil da Internet: os fornecedores de aplicações que operam como empresa guardam os registos de acesso (data, hora, endereço IP) durante seis meses.
• ANPD: o registo de incidentes, pelo menos cinco anos.
• Artigo 33.º, n.º 5, do RGPD: documenta todas as violações, notificadas ou não.
• HIPAA: a documentação obrigatória, seis anos.
• Regras DPDP, regra 6: logs durante um ano, a partir de maio de 2027.

Quando um incidente começa, copia antes que alguém limpe o que quer que seja:

#!/usr/bin/env bash
# preserve.sh INCIDENT_ID PATH...: copy, timestamp and hash evidence on first touch.
set -euo pipefail
id="$1"; shift
dest="${EVIDENCE_ROOT:-/srv/evidence}/$id/$(date -u +%Y%m%dT%H%M%SZ)-$(hostname -s)"
mkdir -p "$dest"
{
  echo "incident: $id"
  echo "host: $(hostname -f 2>/dev/null || hostname)"
  echo "collected_by: $(id -un)"
  echo "collected_at_utc: $(date -u +%Y-%m-%dT%H:%M:%SZ)"
  echo "ntp_synchronized: $(timedatectl show -p NTPSynchronized --value 2>/dev/null || echo unknown)"
} > "$dest/MANIFEST"
for src in "$@"; do
  tar -C "$(dirname "$src")" -czf "$dest/$(basename "$src").tar.gz" "$(basename "$src")"
done
(cd "$dest" && sha256sum -- * > SHA256SUMS)
chmod -R a-w "$dest"
echo "$dest"

Depois envia-o para armazenamento de objetos com bloqueio de retenção numa conta separada, o mesmo padrão que mantém os backups e a recuperação de desastres fora do alcance de um atacante. Mais tarde, sha256sum -c SHA256SUMS mostra que nada mudou.

Um exercício de mesa de 90 minutos contra o relógio

Usa o teu registo, a tua matriz e os teus modelos reais, e alguém a secretariar que anote em UTC a hora de cada decisão. Cada injeção faz avançar o relógio:

1. 1Minutos 0-20, T+0: uma tarefa de exportação correu durante a noite com uma conta de serviço que nunca exporta; saíram 4 GB para um endereço desconhecido. Esperado: declarar o incidente, abrir o registo, preservar provas, fazer a triagem, decidir sobre a CERT-In.
2. 2Minutos 20-40, T+6h: a análise forense confirma que a exportação continha nomes, emails e hashes de palavras-passe de utilizadores na Alemanha, no Brasil, na Índia e no estado de Washington. Esperado: CERT-In já notificada (estava?), avisos aos clientes redigidos, a data da LGPD calculada.
3. 3Minutos 40-60, T+24h: um cliente bancário classificou-o como grave e quer factos; liga um jornalista. Esperado: alerta precoce da NIS2 enviado se estiveres abrangido, uma única ficha de factos aprovada.
4. 4Minutos 60-75, T+72h: aparece uma amostra num site de fugas de dados. Esperado: notificação da NIS2 submetida, a do RGPD a vencer dentro de horas (o prazo dela começou em T+6h), o artigo 34.º e os critérios da LGPD reavaliados (dados de autenticação são um deles), avisos nos EUA planeados.
5. 5Minutos 75-90, balanço: compara cada prazo com o momento em que o respetivo rascunho ficou pronto. Cada falha passa a ser um ticket com dono.

Uma única base de controlos para vários regimes

Os prazos mudam; os controlos quase não. Relógios sincronizados, logs centralizados com retenção, controlo de acessos, restauros testados, um plano de incidentes ensaiado e contratos com cláusulas de notificação servem todos os regimes acima. O nosso playbook de SOC 2 para startups transforma cada controlo numa tarefa de engenharia com a respetiva prova; em Kubernetes, vê como automatizar as provas de conformidade em Kubernetes.

Avaliação gratuita da preparação para incidentes

Se os teus clientes estão em várias jurisdições, a nossa equipa de cibersegurança verifica sem custos se conseguirias cumprir todos os prazos. Cobre:

• Triagem e mapa de dados: que regimes se aplicam a que conjuntos de dados e em que papel.
• Marcas temporais e logs: a sincronização dos relógios, o registo do incidente e a retenção face a cada regime.
• Preparação para notificar: a matriz, os modelos e as horas contratuais, testados numa linha temporal comprimida.

Recebes uma lista escrita das lacunas entre a tua configuração e os prazos que se aplicam a ti, sem qualquer compromisso. Pede a tua avaliação gratuita da preparação para incidentes ou conhece as nossas operações de NOC 24/7.